www.megadrum.info

Is there need or room in the megadrum ecosystem for another config tool like MCT?

Dmitri has documented the SysEx stuff. Have a go!

Development of the config tool will simplify the project and leave new users less prone to making mistakes, but unless it is open source how to maintain and support it?

Along with a few others here it seems, the first thing I did after assembling my megadrum was erase the firmware. The next thing I did was see how far down the garden I could drop kick the buttons. Just as I started to write my own bootloader up popped the Erase SysEx idea but, determined to have a headless megadrum I spent more time developing the bootloader to work without any button input.

Nearly done it occurred to me that I didn't need a bootloader at all so started looking at using the PIC as a programmer - I figured that a header board would do the business but dumped the idea in favour of a completely new PCB because I wanted by now to try and clock the AVR using a PIC io line. Besides I wanted to remove the unused regulator, the opto isotator and the LCD.

All in all I've really enjoyed the whole thing ...not sure anyone else has though

Yes, an open source license was the first feature on my list. I know I don't have enough energy to maintain it myself forever. I don't even really play the drums. Second feature, I think I would choose a language like python that makes it easy to hack on with out compiling. Now as far as actual features I can't think of any improvements over MCT. And that is the reason I ask because I hate to create any division and duplication of effort on such a simple project in a community this size. Don't want to step on anybody's toes.

Why not join further development of the MCT instead? Bundling of resources and all that good stuff.

I would much prefer this. MCT already looks like it is meant to do 100% of what's needed. I've seen a few mentions of open sourcing MCT on the forum, but I haven't found the source yet. I may have missed it. My forum skillz are lacking.

I looked into doing midi communication with python for a bit this morning. In the past I've used portmidi via pyportmidi. Looks like there is a native python portmidi wrapper now (portmidizero). But I was unable to test it because my platform's (ubuntu) portmidi libraries are not compiled correctly. Perhaps python is a bad choice because of the complexities of getting midi working on all platforms.

I guess a second choice would be to build on the java platform. Not necessarily java, maybe jruby, jython or scala, whatever. Of course if we were going to build on the java platform that makes contributing to MCT all the more a better idea.

Have you PMed Elrules? Even if he doesn't fully open source it, I don't think he would mind another programmer looking at it. It seems like he has been really beating his head against the wall for this firmware update issue.

He already posted some of that code
viewtopic.php?f=4&t=386&start=40

Ey guys, turning MCT into open source is a great idea. I was planning to do that, more now that I am stuck with this firmware update error. The only thing I need is a web tool or any other method you can suggest so we can add/modify code, revise it, and release new versions.

Can anyone propose something for that?

Use something like http://www.sourceforge.net. They support open source projects by hosting your code and giving you some basic CVS or SVN access, I believe.

Spend a little time thinking about which license you might want to release it with as well as there a ton of different licenses out there each with their own strengths and weaknesses. GPL is fairly default but understand what it's about before you GPL your code.

Yeah, an SVN repository on Sourceforge or Google Code would be great. Been some time since I last did something with Java, but I surely would love to take a look at the MCT code and maybe contribute a bit as well.

Never used Sourceforge, but Google Code lets you give project members write access to the repository and the public has read access. The latter would be entirely sufficient for just taking a look at it and maybe send in the odd patch every now and then.

Oh, and use SVN! CVS sucks.

elrules,

I'm very happy to hear that you are considering opening the source of MCT.

I've used both sourceforge and googlecode in the past. Sourceforge used to be a little unreliable and difficult to use, but they've done a bunch of remodeling. Google code is very minimalist and simple to use. Both google and sf support SVN but if you haven't yet taken the time to learn a source code management tool I would recommend looking at one of the distributed variety. Both google and sf have added support for DVCS tools like git, hg and bzr. Google supports only mercurial (hg) and I only have experience with git. But HG it must be reasonable, large open source projects like python and firefox are using it after investigating all of the options.

Edit: did I read in the forums that you were using netbeans? Looks like netbeans uses mercurial for version control too.