Config Tool for Mac user (hopefully a temporary post!!)

[elrules]

Settings were saved correctly, the bug was when opening the options dialog. It read sysexwaittime in the pad threshold textbox.

Now I have fixed it

[kimouette]

Settings were saved correctly, the bug was when opening the options dialog. It read sysexwaittime in the pad threshold textbox.

Now I have fixed it

That's right, the bug is fixed. It now saves the setting correctly.

I really wish I could give you good news about the sysex wait time option under Mac Os X, but unfortunately it did not solve the problem. I've tried almost every wait time value, and it still doesn't allow the messages to be sent to MCT like they should.

In the meantime, may I ask if MD COULD be able to send a signal to the MCT to "inform" it that the "process" is completed and that it is now ready to receive new instructions?
I dont know if that could be worked out via the firmware (or another way), but that could solve the possible desynchronization between the MD and MCT.

This coming friday I'll test the MidiJava5 procedure you have suggested.
Fingers crossed!

[elrules]

Take into account that the MidiJava5 is a custom library, with custom methods to send messages, so you first have to test the example given in the MidiJava5 package. If it works, then I could consider writing specific new code for MacOS.

But I think the best way to follow is the mmj, as it works -nearly- perfect.

So, to sum up everything about your tests, what is exactly the action or actions that doesn't work and in which situations?

[kimouette]

With the mmj library this is the conclusion :

Firmware update : Works


All Megadrum settings :
- Send to MD : Doesn't work
- Load from MD : Works
- Save to file : Works
- Load from file :Works


Actions for hihat pedal settings :
- Send to MD : Works only if no action is previously loaded from or sent to MD (otherwise I have to deconnect MD and close MCT to be able to send a new HH setting to MD)
- Load from MD : Works
- Save to file : Works
- Load from file :Works


Actions for selected pad settings:
- Send to MD : Works
- Load from MD : Works
- Save to file : Works
- Load from file :Works


Drum maps:
- Save to file : Works
- Load from file :Works



** Midi log and application log work. But the application log will not show any failure message even though the transfer failes.

** One little detail I should mention though... there seems to be a problem with the (sorry I have no idea how to call it in english!, look at the picture to see what I'm talking about) with the "pointer box". I mean each of the little boxes where you can simply slide the cursor to select a value.

Image 6.png

It happens when I drag my mouse pointer over some of these, they remain open even though I shut down MCT!! That's weird. Unless I click on them, they just stay there!

** A little bug appeared when I updated to the latest 1.3 version... it's about the hihat pedal setting. For some reason low and high level values are kind of "linked" together. I mean, they are no longer independant... nomatter which one I modify, the other value follows. For exemple, when I open MCT hihat Low level is set to 64 and High to 65, if I change Low to 220,Hhigh level will follow and reach 119.

[elrules]

With your conclusions I consider MCT as "compatible with MacOSX but with some issues".
It is really strange that only hihat settings are problematic. I will have to check what can be happening.

About the graphical issues, it is normal. I must recognize the show/hide algorithm for sliders is not very good It shows the slider when the mouse passes over the textbox. And it hides it if you exit them. If you pass the mouse very quickly the mouse out event is not well registered so the slider stays shown. To hide it you have to pass the mouse over it or click it and exit it.

Hihat levels were always linked, since version 1.0. But High Level should be always higher than low level

[kimouette]

I just cant avoid woundering again if it would be possible to prevent the processor overflow while sending all the settings to MCT... maybe not with a delay, but with an answer coming FROM the MD?

About Javamidi5 :

I ran into some difficulties while trying to run the "Main" test class for the javamidi libs. And since I never did any java development before...

Here are all the details:

Firstly, when compiling MidiPort.java and MidiportException.java, I ran into an "unchecked call to addElement" for a vector object. Found this was probably due to some java version incompatibility so I passed -source 1.4 to solve the problem.

Beside the need to pass the -d ./jmidi option for the jmidi package to be created, everything else went fine on those two files.

Then, along with the source incompatibility and the need to set the classpath option to ./jmidi, compiling Main.java and InputThread.java raised some errors because of deprecated string function calls, which I replaced.

Finally, everything compiled properly.

Then came the test.

"java -classpath ./jmidi Main -simple" raised a linkage error as it didn't found MidiPort in the system. (I already copied it into all relevant system paths). After some searches, I found and guessed that the MidiPort binary provided with the sources was most probably a jni dynamic lib so I renamed it accordingly to the osX standards: libMidiPort.jnilib

Still got the linkage error but this time, java seemed to recognize libMidiPort.jnilib

Tried to set LD_LIBRARY_PATH to where my libMidiPort.jnilib was located, tried to pass the explicit path as a java system variable as "-Djava.library.path=/System/Library/Java/Extensions/",
tried to purge the whole Main.java file and enter an explicit: System.load("path/to/libMidiPort.jnilib") - which raised the same linkage error... no success.

Perhaps the MidiPort binary was compiled for an intel mac. (In that case, I could recompile it from the provided C sources but I don't have any C compiler/linker/etc at hand for the moment.) Perhaps I forgot something in the process... However, considering the many deprecated instructions and the dependency on the now dead and buried OMS, my opinion is that perhaps I
should forget about this lib.

[elrules]

It's sad to hear that. The we should follow the mmj lib way, as it is nearly working perfect. Don't know about that strange overflow. Maybe it is not an overflow and it is another kind of problem.

Is there any tool like MIDI-OX in Mac? That way you could connect virtually MCT to that MIDI-OX clone and send it messages, to see if all of them arrive.

Something is failing in the sending method. The rest of the code can't be the problem. In the sending call, it passes the sysex message and a timetamp. Now the timestamp is sent as -1 (which means that no timstamp is sent). Maybe setting it to a correct value helps. Not really sure. When I have studied how to pass coherent timestamps I will PM you to make some tests.

[kimouette]

Is there any tool like MIDI-OX in Mac? That way you could connect virtually MCT to that MIDI-OX clone and send it messages, to see if all of them arrive.

Here's what I tried...

- Open MidiMonitor
- Plug MD
- Checked "Act as a destination for other programs" and " "Spy on output to destinations" in MidiMonitor
- Open MCT
- Set "Sysex time" to 115 in MCT
- For the test, I look at the default setting :
Hihat pedal :
- Auto value : yes
- Low level : 527
- Hi Level : 390
Kick
- Auto value : yes
- Hi Level : 64
- Retrigger : 8

- In MCT, I change all the previous values :
Hihat pedal :
- Auto value : No
- Low level : 75
- Hi Level : 76
Kick
- Auto value : No
- Hi Level : 83
- Retrigger : 12

- Then, in MCT I choose "Actions/All Megadrum settings/Send to Megadrum

Results :

Nothing has changed in MD. All the default values are still there, NO parameter change has been taking into account.

In less than 7 seconds I get the following results in MidiMonitor (see the 2 following printscreens to get the entire list of results)

Image 1.png

Image 2.png

Then, I close EVERYTHING and unplug MD.

I follow the exact same procedure, except in MCT configuration, I set Sysex time to 1000 instead of 115.

Still no results on the MD side. The following results took something like 42 seconds (instead of 7 seconds) to be sent.

Image 3.png

Image 4.png

If I count correctly, 39 sysex messages were sent while Sysex time was set to 115
and 46 sysex messages were sent while sysex time was set to 1000.

I have no idea what these results mean exactly, and still dont know how to solve the problem!!

[elrules]

MCT should send 48 sysex requests while performing the get-all-settings action. (misc + hihat + kick + 3*(head+rim+3rdZone)), and therefore, receive 48 sysex responses from MD. MCT does its job. But it seems like if your MD is not responding well to those requests.

Dmitri, help!!! is there any reason why MD could not respond to sysex requests?

[dmitri]

Dmitri, help!!! is there any reason why MD could not respond to sysex requests?

I can only think of one thing - malformed sysex messages.