Chord sequencer feedback

[Jesse Johannesen]

I'll try to confirm whether the play all / pause all button does the same thing. CC #90 definitely appears to reset the clock.

Downstream midi devices are not out of sync. The NDLR is slaved to another sequencer's clock; so are they. Nothing is receiving clock from the NDLR in this setup. I first had it blocked with a midi processor, now I just have it turned off from the boot menu. When the NDLR's clock is reset on parts start, it can get out of sync with the master clock, in the sense that beats turn into offbeats. So the NDLR starts sending midi notes late. This does affect downstream. Some of those notes are getting further arpeggiated on receipt and the results of the delay are unexpected in a bad way.

When I have the NDLR slaved like this, I have already told it where the downbeat is with a midi transport start from the sequencer (octatrack). So its clock is already synced, even though no parts are turned on yet. Again, turning on the parts messes this up depending on when they are turned on.

Specifically, I am trying to start the parts with the first trig on a plays free track on the octatrack p-locked to CC #90 at the appropriate value. With the current behavior of the NDLR, sometimes this CC arrives a little too late and throws the NDLR clock off as also late. I would microtime the trig to send earlier, but I cannot, because it is the first trig of the track - microtiming that one 'earlier' moves it to the end of the track. I don't want to wait for the whole track to play and only start the NDLR when it loops. This works but almost defeats the purpose. This track is potentially long, sending the NDLR a bunch of stuff while my hands are free to use other controls. I want to trig that track and have the NDLR fire up quickly, like any other synth. Trying to avoid bringing other equipment into this, but elsewhere I think you said you had an octatrack so this explanation might help.

It's up to the designers to decide what the right behavior is on CC #90 start, but my take is that shifting the NDLR clock half a beat forward and starting the parts at that time is a wrong behavior, at least when slaved to external clock. If CC #90 arriving after the external clock tick means we missed the opportunity to start right now, why not start on the next downbeat instead? This would be a nice predictable behavior, and also easy to document.

Different people may want different behavior. If I were using the internal clock, maybe then I would want starting the parts to start everything, including reset the clock. If the NDLR internal clock was the master, I can see how that type of start might be useful to sync downstream devices. Synced to an external clock this behavior is undesirable, either as a CC or from the front panel, because it requires split second timing to avoid messing the clock up.

Timing deserves much thought! Thank you!!

---

Some slow tempo experiments appear to confirm that the play / pause button on the front panel exhibits the same clock-shifting behavior on starting parts that I have been complaining about for CC #90.

So here's how I worded the request:

In addition to CC 90 (Start/PauseALL) it would be useful to have a CC to enable all to start on the next Down beat

**WHAT:**

CC 90 is sometimes problematic when the NDLR is being slaved. If the CC is evaluated a couple of micro steps off the clocks fall out of sync with the Master, causing trouble downstream. it would be nice to be able to have a CC, in addition to CC90, which would look for the next down beat to Enable ALL without affecting the clock, or alternatively set a variable to switch behavior.

My concern is that if the issue is that the CC arrives after the note info in the data stream, as seems to be the case, won't there be a new problem (albeit less disruptive), namely that the note stream will now start 1 bar after the Master, leaving things out of phase without being off beat? If you play an 8 bar pattern on the octatrack and note 1 has a CC90 p lock, then if the NDLR gets that after the start message by any amount, then the NDLR (in the above solution) would then wait until bar 1 finished to begin playing, and it's 8th bar would be finishing up with the 9th bar of the octatrack.

It seems like it would still be necessary to manage the event before hand. If we keep the octatrack as master, some scenarios that would work include press start all before starting the octatrack, or maybe changing the behavior of the physical button as well (so it doesn't reset clock and will enable ALL on the next downbeat), when being externally clocked, this way it would be something you would have to do by hand only at the start of the pattern, and you could have a microtimed p lock at the end of the pattern to ensure it syncs up on the next run through. I don't know if that's an option, but it seems like it would be an improvement to the overall functionality. I can't think of a scenario where the NDLR is being slaved, where you would want to send start messages that would reset the clock of a downstream device. I will put it to the guys and see what they think.

Let me know if that makes sense,
Jesse