"Megadrum Config Tool" released

[elrules]

I will check it

Can you tell me if you used a 32 inputs Megadrum?
Have you tested this new version with a non secure bootloader?
I would like to discard other possible problems.

[dmitri]

I will check it

Can you tell me if you used a 32 inputs Megadrum?
Have you tested this new version with a non secure bootloader?
I would like to discard other possible problems.

I tested it with a 32 inputs version on Atmega32 and only with a secure bootloader.

[elrules]

I added a 1 second wait time between the confirrmation sysex and the firmware itself. Does it work?

[dmitri]

Still the same error.

[Ken Forgettable]

Can a future version of MCT send parameter changes as soon as the mouse button is released from the edit – that is in real time (without having a 'To MD' button)?

I think 'Write in slot 1' should stay as a manual operation though.

[r0bbie]

Can a future version of MCT send parameter changes as soon as the mouse button is released from the edit – that is in real time (without having a 'To MD' button)?

I think 'Write in slot 1' should stay as a manual operation though.

+1

Should we stick with V1.5 until this issue with the firmware update is solved?
I'm kind of scared now to test dmitri's firmware with positional sensing.

[elrules]

I have been testing MCT connecting its MIDI output to a midi input in MIDI-OX

I have seen than in all the code, the data array length corresponds always to the size of the SYX file, that is, if the SYX file is for example 42600 bytes, then the data in the application, after applying all the changes, just before sending it through the midi output, is exactly 42600. But in MIDI-OX I only receive a part of those bytes, sometimes 30000, sometimes 5000, sometimes even less... That's odd. I have checked what I have modified from version 1.5 to version 1.6, and I cannot see anything that may have broken the update firmware thing.

I wanted to ask you something, dmitri, Is the size of the new version SYX file bigger than previous firmware versions? Maybe it is not due to that, but shit! I still have no clue what the fuck is happening

Anyway, while people can still configure Megadrum, I`m happy, because that is the main purpose of MCT. Firmware update is only an extra feature, but anyway, I would like to fix it.

I am starting now thinking that it would be a good idea to publish the source code, so other developers can help solve this kind of problems and also help improving it...

FOR NOW, PLEASE USE MIDI-OX TO UPDATE YOUR MEGADRUM!

[dmitri]

Hi elrules,

The size of the latest firmware is slightly bigger, but then it doesn't work with old .syx files either. If I watch with MIDI-OX what MCT does when trying to update firmware then I can see it sends the 'erase' SysEx but it doesn't send a single byte of the firmware and shows straight away the error 'Error trying to send the sysex file'.

[elrules]

Maybe the MidiPort.dll file is corrupted or something. Everything works just fine till you make the sending through the MIDI output. In that single line of code, it doesn´t do what it´s intended to do.

I will download again the MidiPort and recompile again, to see what happens

EDIT: that this message says something to you?
F0 70 00 05 F7

I am always getting this just after receiving a chunk of bytes from the firmware and nothing more is received then


EDIT 2: after coinfiguring input buffer in midi-ox to 60000 bytes, i still get the same sysex at the end, but i get a popup message in midi-ox telling me:

Bytes reported by low-level input: 46427
Bytes copied into the receiver buffer: 12288

What could this mean?

EDIT 3: dmitri, when you get the error when sending firmware, do you also get in the Application Log a message saying:
Trying to send BIG SYSEX message
The error was: blablabla ?
if so, what appears in blablabla?

[Ken Forgettable]

I am starting now thinking that it would be a good idea to publish the source code

From third place you'll be the first past the winning line

Bytes reported by low-level input: 46427
Bytes copied into the receiver buffer: 12288

Could it mean Midi-OX has received a correctly terminated SysEx along with what it thinks is trailing junk? Does offset 12288 contain F0 70 00 05 F7 – if so it could be either a sequence generated from Dimtri's compiler or a malformed 'Request for firmware version data' with missing SysEx chain ID – I dunno...

I tried MidiPort from v1.5 with v1.6 - no joy.

Tried v1.5 again now this doesn't work - Does it work for anyone?

No hardware or bootloader changes to my Synthex v2.8 and no chance on my box of an online Java update so I think Web start security/cache is broken - maybe using a different project type would show this up.