Serious bug: sysex out of order

[Paul DeRocco]

I'm doing MIDI sequencing with the current Cakewalk. I have a track that begins with a SysxData event followed by a bunch of Control events for initialization. The other tracks just have Control events at the beginning.

I'm looking at the actual MIDI going out the wire. I'm not entirely surprised to see that events on the same tick from different tracks are interleaved randomly. And I'm happy to report that the controls go out in order on each track. But I'm also seeing that the block of sysex is sometimes sent out later, after all the other controls in that same track.

This makes no sense. It's behaving as though sysex is sent via some separate thread. Some argument can be made that the order of things on the same tick in different tracks should be undefined, but on the same track?

Frankly, I think events on the same tick in different tracks should be done in track order, so that all events on a track that are on the same tick are always sent contiguously. But that's a secondary issue. Having events completely out of order is bogus.

 

[msmcleod]

For small sysex events (e.g. switching to XG mode or setting input volume / effects on external in's on an XG device), having them in the track should be fine, but for larger one's you're better off using sysex banks.

When I used hardware MIDI devices, I had a 16K block of sysex with my custom patches in it on my basic template. As they were saved as sysex blocks, I'd get prompted to send on project load. That way I could get them sent once, and use them for the rest of my session.

If you really need to send them out every time, you can insert a sysex bank event in your MIDI track using the event list. As Cakewalk sees this as one event, it will be sent in one go rather than interleaving it.

[Paul DeRocco]

These are Sysex events recorded from an instrument, which uses a Sysex containing program data followed by an NRPN to load that data into a particular channel for playing. It sends this in lieu of a program change if you start a recording (signaled by MIDI Start) with a program that has been edited but not saved. The idea is that on playback, you get the correct modified version of the program, rather than the stored version.

These messages come out of the instrument correctly, and they're recorded correctly, but just not played back correctly. I don't see any reason why storing the Sysex into a "sysex bank", and then putting that into the event list, would behave any differently, since it's still a non-channelized thing that is apparently handled as part of a separate stream from the channelized messages.

My solution is simply not to use that feature of the instrument, and always start with an unedited program. So that's not really a problem for me, but it does expose something that is wrong with the program, which should be fixed.

Is there an official bug tracker that people can post to, or can we only use the forum, and hope someone from BandLab notices it?

 

[bvideo]

support@cakewalk.com, for reporting, but no tracking that I know of.

It sounds like a bug. Can it be isolated to the playback of just one track or does there need to be a stream from multiple tracks?

Generally, people find that those initializing MIDI messages need to be spaced out in time in front of all the notes, otherwise the first notes are all skewed depending on how long the synths take to engage program changes, not just sysex messages. The same might be said for controls & program changes on the same track, namely leaving time after a patch change before the next control. (I come from a world of dino-synths, so maybe today's synths process patch changes or sysex instantly.) Also, MIDI is pretty slow, on the order of  just over 3 bytes per ms. That's 1.6 bytes per Sonar's tick at 120 bpm. So putting a sysex in there is guaranteed to delay some of the other messages "on the same tick". Still, order is certainly important.