Help with Control Change composition / latency

[Kid Yoshi]

I'm trying to get my head around using control changes to swap things like change key / mode / inversion etc. 

When I make a control change a new note is triggered at the same time. However it feels like CC's are processed with latency so when I'm making multiple Control Changes, because they are not happening together then I get a bunch of notes (one for the scale, one for the mode, one for inversion etc). In general it sounds like a mess and the thing is, as the sequence loops it's not consistent which also lends me to think that the CC's are not either being sent together (source) or received & processed together (NDLR).

I've tried this with both an Octatrack and my DAW (Bitwig) and I get the same problem which makes me think it's the NDLR.

It could of course be me not understanding this correctly... help!

[Jesse Johannesen]

So it may be a little of column A a little of column B, I'm not a MIDI programmer, but through my role in support here I've heard that different MIDI messages have different levels of priority, and in some cases different devices treat these differently which can create issues which are device dependent (one example is changing scales in the chord sequencer, which give some devices problems and works fine for others). Then for some situations it could be the order things are happening, like for instance with chord type changes, if the chord type change note comes in after the chord degree change note, it waits for the next chord degree note message to take effect, which if you aren't aware of it can make it seem like it's not working. It works better if you time the chord type change just before the chord degree change, for instance. It may work this way too for the Scale changes too, although I haven't noticed that myself, you may try it sequencing it that way just to see if it helps.

[Kid Yoshi]

So it may be a little of column A a little of column B, I'm not a MIDI programmer, but through my role in support here I've heard that different MIDI messages have different levels of priority, and in some cases different devices treat these differently which can create issues which are device dependent (one example is changing scales in the chord sequencer, which give some devices problems and works fine for others). Then for some situations it could be the order things are happening, like for instance with chord type changes, if the chord type change note comes in after the chord degree change note, it waits for the next chord degree note message to take effect, which if you aren't aware of it can make it seem like it's not working. It works better if you time the chord type change just before the chord degree change, for instance. It may work this way too for the Scale changes too, although I haven't noticed that myself, you may try it sequencing it that way just to see if it helps.

Yeah, I was thinking about sending the CC changes earlier - but it seems that the CC messages are triggering notes themselves. So if I change Scale via CC then new notes are played even though the previous Chord Degree is still playing. In reality, I want that to be a silent update so when the Chord Degree changes the Scale setting is ready in place.

I tried with the Octatrack and my DAW and both seem to trigger notes to play on NDLR when the CC's are sent. But... this doesn't seem right nor how you are suggesting. I can't tell if I'm doing it wrong or if the note actually plays by default when a CC change is made 

[Jesse Johannesen]

Could be that new notes are available to the pool of notes for the PAD part, that seems like a distinct possibility. I would try using a pad part with a long attack and see if it becomes less problematic? Let me mull this over and see if I can get mine to do it. I'll let you know what I find out.
Jesse

[Kid Yoshi]

OK so I did another test, this time with a Squarp Pyramid connected directly to the NDLR. I had a single track set to send 2x CC 73 values (Key). If I monitor the Midi Out data from the Pyramid it confirms that only CC 73 (Value of 1) and CC 73 (Value of 3) are being sent. No note data.

But, when the NDLR receives these CC messages the Key is changed but a note is also sent from the NDLR to my synth.

Digging in further it appears that some CC Data makes the NDLR fire a note whilst others do not. Changing Key does, changing Chord Type does not. The NDLR adds noticeable latency to any updates made via CC changes. So if you go fully CC and set your Chord Degree with CCs (instead of NoteOn) then the Pads are not in sync with the Motifs and Drone patterns.

If you go the other route, and use NoteOn to set the Chord Degree's then the CC changes need to be offset by at least 1/16th note for them to happen in time with the NoteOn messages. This is ok if using a CC value that doesn't trigger a note. However changing the CC of a parameter that does send out a note (like Key Change) means this needs to be placed EXACTLY on the sequencer so the note from that and the note from the NoteOn are in sync with each other - which is pretty difficult and very fiddly.

So some thoughts and critique...

The CC latency is unacceptable, the NDLR is all about Midi and it provides a very comprehensive way to control it via CC. With this in mind, the CC updates need to be accurate and in sync. I've tried this with an Octatrack (it has questionable latency itself when it comes to Midi CC), with Bitwig (pretty rock steady) and Pyramid (very accurate). In all instances using CC fully to sequence the NDLR results in sync issues with the other NDLR parts.

However, it appears using NoteOn is very accurate and plays in sync with Drone and the Motifs. So using NoteOn messages would be usable IF other CC actions didn't trigger notes. In my opinion, only CC 26 (Chord Degree) should play back a note from NDLR. Everything else should be like a layer of influence to that for note value/Chord Degree. This way other things like Key Change would only influence the underlying Chord Degree instead of triggering an out-of-sync new note. The issue of trying to sync the double notes goes away, it still means offsetting midi CC earlier in time to prep the NDLR ahead of the next NoteOn but that's workable (if a little painful).

I don't know what the status is with NDLR updates but I hope this could be addressed.

Overall, I just feel a little frustrated and disappointed. It's an inspiring little box capable of some really incredible music composition, but it has to sync well with sequencers. (I know I could use NDLR as the main clock source and use the Chord Sequencer but that has it's own bugs which mess up timing - which I made a post about the other day).

*sigh*

[Jesse Johannesen]

Hey Yoshi, I still would like to know if the notes you are experiencing during key changes are on the pad part or on other parts. If you are able to test that let me know. I'm going to plug mine in right now and see if I can reproduce this on my device.
Jesse

[Kid Yoshi]

Hey Yoshi, I still would like to know if the notes you are experiencing during key changes are on the pad part or on other parts. If you are able to test that let me know. I'm going to plug mine in right now and see if I can reproduce this on my device.
Jesse

They're on the pad part. Changing key (via CC) will broadcast notes on the Pad channel and those notes hit out of sync with placed Notes since there is some latency between CC and Notes. 

I think my breakdown above is pretty much as it is, I played with the NDLR this weekend and it worked ok as long as I accounted for the quirks outlined above. Changing key works if I change Preset (with the new key) via a Program Change. The only issue is, it's a straight jump where I would prefer a smoother key change by leading up to the new key change 1 bar early.

As I mention, if the only CC change that generated notes was CC26 and all other CCs simply make data changes but do not produce notes then that would be the best scenario. Of course, having CCs processed on beat would be even better... 

[Dirk Offringa]

Isn't that just like pattern sync between midi devices? For instance, if you use the OT as master, and have other sequencers running in sync, if you want pattern changes on all devices to be in sync with the Octatrack pattern changes, you need to program the PC's (or whatever is needed by the slaved devices) on the last beat of a OT pattern, not exactly on the 1st beat, otherwise the patterns on the slave devices are just cued until the next bar. Unless there's a direct jump function on the slave devices, but you'll still miss the notes that are programmed exactly on beat 1, tick 1. Syncing patterns between midi devices is tricky stuff.

[Ghostz_of_Moar]

Hey Yoshi, I still would like to know if the notes you are experiencing during key changes are on the pad part or on other parts. If you are able to test that let me know. I'm going to plug mine in right now and see if I can reproduce this on my device.
Jesse

They're on the pad part. Changing key (via CC) will broadcast notes on the Pad channel and those notes hit out of sync with placed Notes since there is some latency between CC and Notes. 

I think my breakdown above is pretty much as it is, I played with the NDLR this weekend and it worked ok as long as I accounted for the quirks outlined above. Changing key works if I change Preset (with the new key) via a Program Change. The only issue is, it's a straight jump where I would prefer a smoother key change by leading up to the new key change 1 bar early.

As I mention, if the only CC change that generated notes was CC26 and all other CCs simply make data changes but do not produce notes then that would be the best scenario. Of course, having CCs processed on beat would be even better... 

I agree 1000% with you. Now I just use the chord sequencer to do a key modulation because it seems more efficient...but then I still have sync issue.

It would be great to have the option for the keys to be played when doing a key modulation or when changing the position of the chord....but I think that the NDLR’s design doesn’t see this as anything more than an arbitrary ambient pad on 1/8th or 1/4 notes vs a tool for precision placement of harmonic clusters of notes. 

So this translates into risky business when there is a parent clock that the NDLR is running off of and there is a drum machine running off of that same parent clock in a parallel scheme.

Good for ambient? It can be.

Good for the solid sync necessary to address other genres? There are still fundamental challenges in how the unit keeps time in a subordinate sense. As in 1/4 and 1/8 note lags and deviations are immediately sensed in the music composition and it can be a real stress performing live when things go south because of these unplanned and unprovoked deviations. 

And it really should not be that hard to see and maintain a consistent eye on.

I would gladly sacrifice the number of pads voices en lieu of precision pad note placement options and a rhythm editor for the pads(so we could have chord stabs)

[Jesse Johannesen]

The newest NDLR FW fixes the timing issues in CC controlled parameter changes, as well as the timing issues I was seeing in the Chord Seq. I would love it if those of you who have some experience with these issues would give this fw a go and see if it solves that problem for you.
Thanks,
Jesse