Hi. I’m aiming to send a CC value (e.g. from MIDI CC Inject) and a MIDI chord (notes) (e.g. from Chord Palette) out to the same destination.
I would like the CC value to deterministically precede the MIDI chord.
Is it possible to arrange that?
All of this I want to tie to the DAW transport, so that when playback starts, the CC value and the Notes immediately go down the line, CC first.
So far, in all my attempts, the notes go out first.
Does it actually create an audible artifact? Had not thought about it before..
CC 14 127 turns on KARMA. (CC 14 0 turns KARMA off)
So, yeah, the sound is completely different! 
How about using the MIDI Delay node to hold the notes back slightly to give the CCs a chance to exit?
Interesting idea, thanks guys!
It does work, but sub-optimally. If I raise the delay enough (e.g. 30 ms) to reliably cause the CC to precede the notes, I effectively make all the chord notes late by that much at every barline for the entire composition. This is undesirable.
Maybe put the notes delay into some logic that so that the delay is inline only when the song position is 0 (or whenever you want to send the CC and notes together). After the KARMA is on, bypass the delay so that the notes stay synced with the transport. Would that work?
Interesting idea, thanks. I’ll try to gin that up and see how it behaves.
Yeah, I understand, but if the midi messages are processed together in one packet, I thought it might not happen. The midi delay danny suggested is the way to go. I have been using it to offset starts by a few seconds when generating different tracks from notes in a chord… but maybe not for you..
And the MIDI Delay has a Bypass input that should (have not tested myself) effectively eliminate the delay when not needed.
Ah. That’s an interesting idea!
Is there anything in this what could you help out? catching the gate event to send the stored value into the CC inject., using it to send the new CC value (I emulate this with an LFO for this, just for testing).
At least i get CC before the note’s and having the midi delay at 10ms. Most of the time i need to experience the issue to solve it. so since i don’t got a lot done with it yet i don’t had any problems to solve so this is the only one i could think of right now.
Thanks Danny, I will refer to your picture as a future reference.
Right now what I’m noticing is that when I click the Stop button in Bitwig, returning the Bitwig transport to 1.1.1.00, then position, bar, beat etc. in the Transport node do not reset themselves at that point. This shuts down an approach I was attempting (but hardly exhausts the possibilities, I’m sure!).
Thanks again Danny!
Your output goes to 0 when I stop the transport in Bitwig, else it is non-zero.
I connected that to the ‘MIDI Delay’ Bypass and I see the bypass happening during playback and ending when I stop the transport.
At the 0 point, when I start the transport, the un-bypassed ‘MIDI Delay’ seems to be active for long enough to do the delay and put the first chord notes after the CC.
This should mean no further delay at later barlines. Good!
I don’t know if delaying the chord notes 30 ms (in this case) at the very start will ultimately be an issue for perfectly clean MIDI and audio recording of the KARMA output from the beginning, but that level of detailed testing awaits another day.
I’ll call this a solution (at least for now). Thanks so much!
Hey guys, I’ve made a change so that when MIDI events land at the same moment, CCs and other controls always go out before the notes.
Thanks for the delay ideas, they work as a workaround. But when timing matters, as it usually does in music, the real fix is sending things in the right order. So if you run into anything else like this, let me know and I’ll look into it.
About the Transport on Stop: Bitwig only tells plugins where the playhead is while it is playing. Danny’s trick of gating Position with Playing is a good way to get 0 while stopped.
The change will be in the next version, which I hope to release soon, maybe tomorrow.
Thanks Mario!
