04-07-2020, 03:41 PM
(This post was last modified: 04-07-2020, 04:21 PM by kastenbalg.)
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.
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.