Would you like a complete redesign of MCT?

[rockdude]

v1.83 can send too many bytes to MegaDrum - I mean: after certain operations it will send the expected data followed by extra junk bytes (the transmission size is larger than expected). I have observed this with non SysEx (ie firmware) data.

I was afraid something like that was happening. I think we found that out while trying to find a solution to Mac version.

By the way, yesterday I said YES to a really good job offer, better than the one I had before. So, in about a week I will be back to work again. I will be in charge of developing a Blackberry app on my own. It will be kind of a first test of my skills.

I will post soon how it is going

Good luck on your new job!

[jman 31]

Yep. I hope it goes good for you.

[rockdude]

By the way, yesterday I said YES to a really good job offer, better than the one I had before. So, in about a week I will be back to work again. I will be in charge of developing a Blackberry app on my own. It will be kind of a first test of my skills.
I will post soon how it is going

Hi Elrules!
I just wanted to know how your new work is going and if there's something new cooking for MCT?

It would be really cool if the development of a new MCT got started...or that the old one is updated. I think we need something fresh now that we've got encrypted firmware and added functionality such as positional sensing and more hihat settings.

As I've said before, I can help with graphics and ideas. Now that we've got positional sensing and more hihat notes it would be very user friendly to add a graphical way of tweaking those features in MCT. The hihat notes for transitions between different levels of openness would be awesome to be able to tweak in similar fashion as in BFD2:

[juanla]

yes i thinks it will be great a redesing of MTC,
and if is possible that have new languajes like spanish will be much better,

thanks

[davem]

I had actually been giving this some considerable thought over the last few weeks. It seems to me like if we are to redesign and reimplement MCT, it should be done in something other than Java. Given all of the problems I've had trying to come up with some solution for the Mac users, let alone problems on Windows and Linux, I'm not convinced it is the correct cross-platform solution that we're all after for something which can be counted on to work reliably.

Since reliable cross-platform MIDI support is really essential, I suggest we use RtMidi. It is a pretty simple C++ wrapper which works on the three main platforms (Windows, Linux and Mac). I would hazard a guess that it's quite a bit faster than Java too (although in many instances the MIDI backend uses compiled code anyway). For the interface, Qt seems like an ideal choice, given that I know from first-hand experience that it produces executables which work very well cross-platform.

Even if nobody else agrees, I still may consider doing this myself since I think it's pretty important. Granted it will take some time since I have other projects (non-MegaDrum related), but it seems like it would solve a lot of issues (including those which are performance-related) if we just moved away from Java.

[rockdude]

I had actually been giving this some considerable thought over the last few weeks. It seems to me like if we are to redesign and reimplement MCT, it should be done in something other than Java. Given all of the problems I've had trying to come up with some solution for the Mac users, let alone problems on Windows and Linux, I'm not convinced it is the correct cross-platform solution that we're all after for something which can be counted on to work reliably.

Since reliable cross-platform MIDI support is really essential, I suggest we use RtMidi. It is a pretty simple C++ wrapper which works on the three main platforms (Windows, Linux and Mac). I would hazard a guess that it's quite a bit faster than Java too (although in many instances the MIDI backend uses compiled code anyway). For the interface, Qt seems like an ideal choice, given that I know from first-hand experience that it produces executables which work very well cross-platform.

Even if nobody else agrees, I still may consider doing this myself since I think it's pretty important. Granted it will take some time since I have other projects (non-MegaDrum related), but it seems like it would solve a lot of issues (including those which are performance-related) if we just moved away from Java.

Good call Davem! I'm really excited someone is ready for some action regardless of what code it's written in. But I'm with you on C++. It's very good for cross platform software. I'm here to help as much as I can in all possible ways. I'm not that well versed in coding anymore although I still carry a basic understanding of programming, but I'm good with graphics and usability (part of my education and nowadays work). And I have a lot of ideas and suggestions. Just tell me when you're ready to start!

[davem]

A quick update: I'm in the process now of writing an underlying library, libmegadrum. Its purpose is to use RtMidi to abstract the MegaDrum away a little bit from the underlying MIDI interface. This way, it can remain separate from MCT, and can therefore be used on any other applications; for example, it should be possible to write a command-line program to update the firmware. Another advantage is that if something is wrong with the communications, we can simply test libmegadrum as opposed to stripping out MCT.

So far progress is good, although the interface is still under a lot of flux at the moment. However I have rudimentary communication between MD and a test program. I'm hoping to have this mostly completed by the end of the week, and then move onto MCT. This is actually turning out to be quite a fun project, so I expect my progress to be reasonably quick. Hopefully I will get the code online so everyone can chip in, if they feel like it.

[fuzzysnuggleduck]

A quick update: I'm in the process now of writing an underlying library, libmegadrum. Its purpose is to use RtMidi to abstract the MegaDrum away a little bit from the underlying MIDI interface. This way, it can remain separate from MCT, and can therefore be used on any other applications; for example, it should be possible to write a command-line program to update the firmware. Another advantage is that if something is wrong with the communications, we can simply test libmegadrum as opposed to stripping out MCT.

So far progress is good, although the interface is still under a lot of flux at the moment. However I have rudimentary communication between MD and a test program. I'm hoping to have this mostly completed by the end of the week, and then move onto MCT. This is actually turning out to be quite a fun project, so I expect my progress to be reasonably quick. Hopefully I will get the code online so everyone can chip in, if they feel like it.

That's awesome! Thanks for putting some much effort into this!

I do however have to say that I was unable to make Dmitri's firmware update utility using RtMIDI work on my Mac as well Maybe the timing on Mac is just uber sensitive and it's not RtMIDI's fault at all (more like the way it was used) but I was discouraged when that also didn't work on my Mac.

I've got my fingers crossed...

[rockdude]

Way to go Davem! I'm jumping of excitement right now
Keep up the good work and keep us updated about your progress!
Maybe elrules can chime in on the work when he's got time and you've got the code ready for sharing...and you know that I'm here too.

[einkahumor]

I do however have to say that I was unable to make Dmitri's firmware update utility using RtMIDI work on my Mac as well Maybe the timing on Mac is just uber sensitive and it's not RtMIDI's fault at all (more like the way it was used) but I was discouraged when that also didn't work on my Mac.

I never got the update program working on Mac OS X either. I did however manage to update using the Win version through Parallels Desktop but I'd really like not having to run Windows on my Mac. It just doesn't feel right.