Incoming MIDI buffering

[danatkorg]

The ability to receive data and buffer it until it can be consumed by the main process is pretty simple to implement (comp sci undergrads learn how to do this stuff pretty early on - it's standard interrupt handling) and I can't imagine any reason why a high end environment like the Kronos doesn't do this as a matter of course. That is why I asked if this was a known issue/bug.

Comp sci undergrads might also know that buffers are pretty much required for MIDI instruments, and that what you are describing does not mean that buffering is not being done.

Internally, many messages may be created and processed (by KARMA, for instance) in the moments after a Combi is selected. In my experience, even with much simpler synths, it's always been standard practice to insert delays between program change messages and CCs. That would be my recommendation in this case as well.

I'm always happy to hear about people using Max/MSP. I first used Max back in 1989 or thereabouts - well before the "MSP" part of the equation!

- Dan

[dhjdhj]

Well, first of, you wouldn't be filling it up with notes, although your last might COULD be a note if, for example the note was intended to start some kind of ambient sound.

But you're really thinking about it inside out. The goal is to have the synth be able to reset to its next sound but not lose any of the extra initialization (volume, expression, maybe even some real-time sysex) messages that are sent immediately after to modify that sound before the synth is actually played.

An interrupt driven buffer is simply the mechanism one uses to store the pending messages until the synth is ready to respond to them. Parsing the byte stream into MIDI events is done upstream, it's not an issue.


@Dan Clearly buffering has to be done unless the synth really can poll/respond in real-time, which is of course is unlikely. However, for a start, I have KARMA turned off globally, I never use that stuff. But even if there's a bunch of messages being created internally during start up, that's still no reason for external messages to not be held up and then processed when the initialization is completed.




Uh, yeah --- that's precisely why I ASKED in my initial thread if buffering is being done. It should be, but I'm seeing symptoms that would suggest that MIDI messages arriving immediately after a program change are being lost and I don't think that should be happening. Lost or improper handling of messages after a PC would explain this. If you're confirming that buffering is being done such that subsequent MIDI messages don't get lost, then why aren't those subsequent MIDI messages being handled? Are they being processed to early, while the synth is still resetting to the new sound? If so, then I would argue that that's a bug.

what you are describing does not mean that buffering is not being done

Actually, with simpler synths, particularly older ones that are slower, it would be even more necessary to have decent buffering. The standard practice of delays is a historical hack because buffering wasn't being handled properly and shouldn't be needed in a modern complex synth like an Oasys or Kronos. How is one supposed to know how long the delay should be? What if some sounds only take 1/2 second to initialize and others take 3 seconds....is one supposed to always have a delay of 3 seconds just in case? Buffering and responding to external MIDI after everything else is initialized makes the process completely deterministic, that doesn't seem like an unreasonable behavior.

even with much simpler synths, it's always been standard practice to insert delays

[danatkorg]

If you're confirming that buffering is being done such that subsequent MIDI messages don't get lost, then why aren't those subsequent MIDI messages being handled? Are they being processed to early, while the synth is still resetting to the new sound? If so, then I would argue that that's a bug.

I understand that you're a developer, so you'll know that it's not always feasible to develop an implementation which is perfect for all possible use-cases - and sometimes one use-case trades off against another. For instance, if we were to delay processing of all MIDI for some period of time after a Combi was selected just because some controllers might be overwritten, that could introduce problems for other users - who might simply want to play notes.

Theoretically it should be possible to figure out which MIDI events might be overwritten (based on KARMA settings, controller resets etc.) and delay only those events, but that might introduce other problems, and also might not be practical to implement.

In the meantime, inserting an empirically-determined delay into the Max/MSP patch seems like the right approach.

Btw, the Security Project is awesome.

Best regards,

Dan

[dhjdhj]

Dan, I don't understand the issue with delaying MIDI at all. I'm just saying that the combi should finish its own initialization before it starts processing external MIDI. I don't understand what it would mean to start playing notes before the combi has finished initializing. Wouldn't one have essentially the same kind of problem trying to respond to a note as to a CC, I.e. you could get an unexpected result because the combi is not ready.

In any case, I am using a delay but I wish I didn't have to.

Glad you like Security Project....just played first gig of tour in Milwaukee. Off to Chicago tomorrow then trying to figure out how we get to Philadelphia with the snow storm

[Shakil]

In any case, I am using a delay but I wish I didn't have to.

How much delay are you using?

[dhjdhj]

Only about 500ms now.

But I wasted a lot of time debugging my own code before I figured out that the problem was with the Kronos.

[Shakil]

Only about 500ms now.

But I wasted a lot of time debugging my own code before I figured out that the problem was with the Kronos.

Hmm, IMHO, I don't think there is any other workstation that would have behaved differently.

Think of it this way... when you send a combi change message, that is a very high level command. There are a lot of sub commands to change programs on each part, reload IFXs, levels.. etc. If you had sent all those commands from your code, you would have put them one after another. And would have given enough time to load.

KRONOS is doing all that for you in less than 500ms. So, I don't there is a problem with KRONOS in this scenario.

Also, you could move the command 500ms ahead in time, if it's being sent between songs. So, you levels will be as you need when you hit keys at 1st tick of the measure.

[dhjdhj]

I understand but this misses the point. It's fine that the Kronos does all that initialization.

That doesn't mean that it should just lose stuff sent from a DAW....indeed the stuff sent from the DAW should be considered higher priority in some sense. It's supposed to override whatever initialization was done by the workstation.

What difference does it make that other workstations don't do this either, that's not an excuse --- let Korg be the first to do it ----

[Shakil]

But, I don't think it's losing stuff..

I think this is what's happening...

tick 1 combi change
tick 2 volume cc on channel 1 by your code - volume set
tick 3 volume change on channel 1 from combi - volume overwritten.