SOLVED: Loading setups Librarian only works sporadically

With latest firmware 20 and VST v..41 setups only load now and then. Hardware presets work fine, but not loading and saving from / to librarian.

The way it works now is not at all close to be releaseable I would say - it is very unpredictable. The setup loads to the plug-in LCD display every time but is only transmitted to the synth now and then (one time out of 5 I would say. If I save a preset to hard disk as a setting in the librarian the sound is totally different when I load it.

I can see that the plug-in sends a sysex to the synth every time I load from the librarian. But it seems like the synth only responds to it now and then. Actually quite often the plug-in sends a sysex twice for each double-click I do to load preset.

What could be the reason for the synth not changing preset?

kr
Morten

New info. I tried to capture the sysex sent to the synth from the plug-in that does not change the sound using MIDI monitor. Then I saved that to a file and send it to the synth using SYSEX librarian and then the synth changes sound instantly every time. So it seems to be a transmission or reception issue - but since it works fine every time using sysex librarian it seems like a plugin error and not a MIDI card or Synth problem?

If I move the synth to direct USB instead it always changes sound instantly (using the stand alone editor) - so can be MIDI DIN related.

I wonder, how come the Sub37 sometimes sends a Start or stop message back after having changed sound (by sending the sysex)? Testing back on DIN MIDI the synth only seems to change sound when a stop or start message has been sent back from the synth. Does not really make sense to me but not really a MIDI expert as such.

this part happens when a preset is loaded which has the arp/sequencer on…
but you can control whether this is sent or not, on the MIDI menu (3.4) Clock Options>SEND ST/STP: OFF will turn off sending start/stop when the arp or sequencer is turned on or off.

regarding why presets don’t change… this is an unusual result, I feel there must be some other confounding factor.
what type of DIN MIDI interface are you using?
Is anything plugged into any of the CV/Gate input jacks?

if the name on the LCD changes to the new preset name then the preset was received… if the sound doesn’t change audibly when you play notes, something is odd… is local control on or off? for that matter how are you triggering notes, to determine that the sound hasn’t changed… via MIDI from outside the Sub 37, or by playing its own keyboard? Thanks for any extra detail.

For my part I tested here using DIN and always had the sub 37 respond to every preset I sent it from the editor with nothing sporadic… I’m using an iConnectMIDI4+ MIDI interface which seems to be rather excellent; I guess it’s possible there could be problems on another interface that I might not see here…

Did some more testing and think I have narrowed in on the issue. I am using the iConnectivity iConnectAudio4+.

To debug I tried to connect the Sub37 using the USB Host (HST) port on the ICA box instead. Then it showed same problems as on DIN.

Then I went back to the DIN setup but connected DIN MIDI OUT on the ICA+ directly to the DIN MIDI IN on the ICA+ to see if I got the right stuff through the port. And suprise. The SYSEX messages are “destroyed” - sometimes they are full and ok (rarely) but often they are shorter. See attached image and I have attached an output and resulting input SYSEX.

This seems like the issue lies with the ICA+ MIDI and I have to debug that instead. Funny you do not have problems with the iConnectivity 4 you are using (the non-audio version)

/Morten
Screen Shot 2016-02-22 at 19.54.32.png
Archive.zip (776 Bytes)

this is an interesting result!

I just tried the iCMIDI4+ Host port over here and am getting the same consistent success I was having via DIN.

However, I also tried connecting the DIN1 output directly to DIN1 input, setting the editor to output via DIN and then scrolling through some User Library presets in the Editor…

this output each preset sysex to the DIN out which then of course was piped right back to the DIN in.

in MIDI Monitor, I am still seeing more frequent success than in your example, but if I scroll a lot of presets quickly I start to see some failures too; truncated sysex like in your screenshot.

I have a contact at iConnectivity; I’ll email him to see if this is something they’re working on, or if we need to throttle our sending speed to get better performance, or what. I assume we’re already outputting MIDI at only standard DIN speeds, but maybe we have to go even slower…?

The iConnectivityA4+ should be able to handle standard MIDI speed, if not they should fix it. The 31250 bps can fit 1500 times on a USB connection (480,000,000 bps). I have also filed a report at iConnectivity.

Have talked to iConnectivity and they could not reproduce the issue. I tried as they, to send the SYSEX messages out on DIN and loop back to DIN MIDI in using SysEx Librarian (at full speed) instead of the Sub37 VST. In that case no data is lost. So it seems like it is only when the Sub37 editor sends SYSEX messages through the iConnectivity there are issues. I do not have similar issues with other editors (e.g. SoundTower for Tetra 4 and the DSI Evolver).

If I send from the editor to another USB-MIDI interface (MidiMate 2 port interface) and insert that DIN out plug in the iConnectivity DIN in, then nothing is lost either.

So again - it seems like there is a conflict between the Sub37 editor and iConnectiviyAudio+.

If I send the SYSEX messages from the plugin to IAC bus and back - nothing is lost either.

Can there be any difference in how you send SYSEX to a MIDI port and how SYSEX player does? Thought it was all handled by the Core MIDI libraries on OS X?

Did you get any further with your contact at iConnectivity? Is it OK to send them the editor to test with?

iConnectivity have reproduced the SYSEX byte loss problem and here are their findings:

My firmware engineer looked at the USB stream (using Beagle) and could see that the Sub37 app is sending the whole sysex message over 2 microframes whereas SysexLibrarian sends the same sysex message in 3 pieces with 82 ms between each chunk. Sub37 is sending the data a bit too fast for iCA4, a buffer somewhere is getting overloaded. He will try and remedy this but it will be a few days before I can get to this.

So not sure if it would be better to send sysex like SysexLibrarian?

Yes, it’s definitely OK to send them the editor.

When I got in touch it seemed you’d gotten there first, so I contributed my bit of info to the same ongoing investigation.

If the problem is isolated to our app, then it seems we need to investigate further here at Moog.

This works now after I received an updated Beta firmware from iConnectivity. So no issues with your VST