Korg Forums

If a program change is sent to the Kronos (that will change the currently loaded Combi) and then a CC Vol (7) change is sent to one of the MIDI channels immediately after (i.e, no delay between PC event and CC event beyond MIDI data rate), will the CC event be buffered and applied once the Combi has switched, or does it get lost?

I'm having a problem in my live environment where I'm not getting the correct volume and I'm wondering if I need to insert a delay between the time the PC event is sent and when the CC event is sent.

Thanks,
D

dhj- a little more information might be in order. What is communicating the Combi change with the Kronos? What is generating the CC#7?

Not sure it really matters how the events are being created. It's actually being done programmatically through MaxMSP

But it could just be a DAW. Imagine a track that contains a program change at one tick and a CC event at the very next tick such that when you play the track those so events go out at the highest possible MIDI rate. If multiple MIDI channels are in use (e.g. A combi with different sounds on each channel) then there would be multiple CC events sent out as fast as possible after the program change.

The Kronos must first change the patch and then respond to the CC events. The question is whether the Kronos can buffer the CC event (indeed multiple CC events) while it is still loading a new Combi

Stick a small delay in.

I understand I can so that but I hate doing such things if it is not necessary. So my question still stands...was the software designed so that incoming MIDI data is buffered if the system is not ready to process it?

I would say that if it doesn't work then no it isn't!

In that case could Korg be convinced to take 256 bytes from the 3Gb to use as a buffer to solve this problem?

I was going to recommend the Cycling '74 forums, but i see you've already been there. Looks like some pretty heady stuff. In the big picture, what are you trying to achieve? A large multi-keyboard setup with multi media and MIDI control of everything?

I think it may not be getting lost, it may be getting overwritten by the settings in the Combi.

A tick depending on the tempo may be too quick for KRONOS to load full Combi. So, I would either set the volumes you need in the combi itself, or give it a few ticks for letting the combi load completely.

Ever though about trying CC#11 (Expression)?

First, thank you all for responses and suggestion, they are really appreciated. I'm actually out on a tour now so have little time to respond to messages. But I wanted to comment on a few things.

First of all, I understand completely that I can add artificial delays (and I'm doing that now) but that's really a band-aid with which I'm stuck if it is in fact the case that the Kronos can't handle the rapid receipt of the PC and CC events.

I don't understand the comment about the ticks being too quick.....actually, let me rephrase that completely ---- I understand what's going on but it seems to me that when the Kronos needs a bit of time to respond to a PC, subequent events should be buffered and then handled when the Kronos is ready. So while the Kronos is initializing the Combi, setting volumes (and other parameters), subsequent events should be getting buffered and then handled when the Combi is fully initialized.

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.

@Shakil The reason I can't set the volumes to what I want inside the combi is complex but suffice it to say that it's because all the parameters need to be controlled from my host environment and when things are changed there, the values need to be remembered for next time.

@ronnfigg Yes, I'm running a custom-built MaxMSP environment to control a live keyboard rig and integrate with VSTs running on a laptop. It's similar to what Apple MainStage does except without the bugs( ) and it now has a lot more capability than MainStage so I can't go back. There's a more complete description of that environment on my blog if you're interested.

http://deskew.com/blog/?p=81


Thanks again for the responses.

Holy cow I just read that of and wow for someone who doesn't know anything about midi it sure sounds like it was initially an integration setup nightmare, but fun! Once set up and programmed is it fairly swift to move reset up and configure the way you want?

dhj- I just read your blog. Wow! like I said- this is some pretty heady stuff. I remember when I first heard about MIDI, I thought- wow this is going to make things really easy for keyboard players. you just put me back into the Stone Age! do you have any links where I can see videos/ hear audio of what you are doing?

@ronnfigg

There is an 8-minute promo video taken from our first show which was at B.B. Kings in NYC a few months ago. You can probably figure out which parts are coming from my keyboard rig.

http://www.youtube.com/watch?v=PG4R8VKdxRk



@Bertotti
Actually, dealing with the problems with MainStage was a nightmare. Once I bit the bullet and decided to switch to MaxMSP, it was pretty smooth and it evolved significantly (including major redesigns) over the last year. I built a lot of objects so that I could work at a really high level most of the time and these days, it's really trivial to build a patcher that will do arbitrary layering, splitting, routing, as well as lots of useful transforms such as transpose, velocity remapping, auto sustainers (great for pink floyd stuff) and easily rerouting aftertouch to pitchbend or to an arbitrary CC, etc.
The way it works now is that when I select a new song to play (which I do from an iPad), MaxMSP will load the appropriate patcher with the routings, send out program change to external hardware (Kronos and Nord these days), send out the appropriate CC events, load the needed VSTs and their patches etc. It was while making some changes to how the above worked that I ran into the problem with the Kronos. For a while I was sure it was my code (always suspect one's own code first!) but then figured out that it had to be the Kronos.

MaxMSP is a wonderful environment and I strongly recommend it to anyone interested in manipulating MIDI and audio (and even video in recent years)

interesting.

But if you had a MIDI message buffer and filled it up with note and commands, what would it sound like?

Other words; If I was to fill up the buffer full of notes and send a CC#7 and program (or combi) change followed by more notes, I might get a blast of notes right after the command was executed, timing would go to hell. Better to just not play the out of time notes.

And how would the buffer know what type of data it contains, notes, velocities, CC#'s, clock ticks?

Seems to me, a midi buffer may not always be the right choice in a real time performance.