Chord sequencer feedback

[kastenbalg]

On firmware 1.1.066, arming a chord sequence and then starting any individual part or combination of parts with midi CC#'s 85-88 does NOT start the chord sequence. Stopping all parts with individual CC#'s 85-88 stops the chord sequence if it is already running, though.

By contrast, starting an individual part or combination of parts on the front interface of the NDLR starts an armed chord sequence, and stopping them all from the front interface stops the sequence.

This is a strange inconsistency.

Starting all the parts with the new-to-firmware 1.1.066 midi CC# 90 does start an armed chord sequence, and stopping them all with it stops it. I assume this is the correct behavior; it is useful to me. I just got that to work and it feels like a huge victory.

Let me explain.

I am hoping to be able to use an external sequencer to start and stop chord sequences on the NDLR. The NDLR's internal chord sequencer is less 'glitchy' than sending the NDLR chord changes through midi when modulating through many different keys; the NDLR's chord sequencer is easy to program, also, compared to sending the NDLR key and mode changes with midi CC's. An external sequencer for starting and stopping the chord sequences is still helpful. Starting the NDLR's chord sequencer with another sequencer that I can cue anywhere in a bar and have it start right on the next bar allows for easier timing live. I can also program the external sequencer to stop the chord sequence automatically if I wish.

Now that I have midi CC# 90 to do this, I'm delighted. Would like to see the individual midi CC#'s do the same thing. A little more versatile.

If you could spare a midi CC# to arm or disarm the chord sequence, that would also be helpful. While I am here asking for a pony, why just five internal sequences? Why not more?

Using the NLDR's chord sequencer to 'play a song' is not too useful to me and seems a little bit more than what the NDLR should do. Every song is different and I have other sequencers for things like that. But using the chord sequencer to store a few templates of modulations and fire them off live with automatic arpeggiation is an exciting idea and a better fit for the NDLR's concept.

The CC start messages not starting the chord sequencer seems like a bug. I'll see if I can repro it and get it in the queue to be resolved. I'll also add a request to put a cc on the arm disarm as that seems like great addition to the functionality. Thanks for the great feedback. Cheers!
Jesse

Thanks, your fast response was very encouraging.

Although this is not directly related to the chord sequencer, I found an almost definite bug related to CC #90. Seems to belong in this thread.

My NDLR appears to think that whenever I turn all the parts on with this CC, this happens on a beat. It is not that the parts are quantized to come in on the beat closest to the change, which would make musical sense. Instead, they can come in sooner. When this happens, the CC change also changes where the NDLR thinks the beat is. If you count 4/4 as '1 and 2 and 3 and 4 and,' you can accidentally move the NDLR to the 'and' of the beat, which the NDLR will now think IS the beat. Other sequencers in your setup likely disagree... Besides that your pad quantization, all your patterns, everything really, are now off.

This unwelcome side effect is visible on the front display.

Watch the tempo indicator closely while turning on the parts with CC #90. That flashing circle next to the tempo that turns blue on the downbeat and red on all other beats can change when the parts come on from being triggered with CC# 90. If the CC change is received on or close enough to the beat, the tempo indicator will not change when the parts are turned on. If the CC change is received not close enough, there is a brief 'double flash' of two beats where the NDLR switches the beat to the off beat as it starts the parts. The NDLR remains synced to the clock but is now on the off beat. Everything else the NDLR outputs follows suit.

This can be fixed by turning the parts off and on again until you get luckier timing. Regardless, I am almost sure turning on parts should not affect the NDLR clock sync. I would never want the NDLR's clock to move this way; a mandatory quantized start would be better. Happy to help if anyone needs more info to reproduce this.

[kastenbalg]

More succinctly, maybe the issue is that starting the clock might sometimes start the parts (if they are already enabled but there is no clock), but enabling the parts should never start the clock.

[Jesse Johannesen]

More succinctly, maybe the issue is that starting the clock might sometimes start the parts (if they are already enabled but there is no clock), but enabling the parts should never start the clock.

Hi kastenbalg, I hope you're doing well. Lets see if I understand the situation:

CC90 (which  is the Start Pause ALL message, although it seems to be missing from the manual, I'll have to look into that...), when used to start all causes the parts to start immediately resetting the clock to a one downbeat, and when this occurs downstream midi devices are left out of sync with the new clock.

I wasn't involved with the coding for this implementation, but what I think is happening, is that the CC is just doing the exact thing that pressing the Pause/Play ALL button does, which is to reset the clock to 1, set all parts to the beginning, and begin all parts, so it seems like it's doing all that stuff. I can see where having the ability to enable all parts on the next downbeat would be helpful, I'll add a feature request to the list to see if that's possible.

I'll think about this a little more, too, and let you know if I think of anything else.

Take care,
Jesse Johannesen

[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.

[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

[kastenbalg]

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.

Yes, this is correct, I think. I envisioned it happening this way and being something I could work around. You are right that this would not loop well. If I am also sequencing the NDLR from this track, there is an extra 'blank' bar. This would work for starting a chord sequencer sequence on the NDLR itself, but the track could only do that or the sequence would be ruined on the first loop.

I still like the idea of a way to start the NDLR on the next downbeat, but doing it that way is not a great fix for my situation.

Thinking about how to send the CC start in advance... only thing I can come up with offhand is using two octatrack tracks both on the control channel, one to start the NDLR with that first p-lock CC trig microtimed early (so really at the end of the track), and another to sequence the NDLR once it started. The first track could be shorter than the second, and the second could have a longer delay to start in the octatrack itself. Lined up so the first track reaches its loop and sends the CC start just before the second begins the sequence. Simultaneously start both tracks and in theory that would work. This uses two midi tracks but I potentially get four parts back. Reasonable trade off.

I am going to give this a try. If it works I have a fix.

I am quite impressed by your idea of changing the behavior of the start button when synced to external clock. If the button started on next downbeat when synced to external clock, that would accomplish the same thing as two octatrack tracks, but I think it is even better. It saves me a track, but also I could see this working well when slaved to other sequencers. You would cue the NDLR much like an octatrack midi track, on it's own panel, right before you were about to play it.

Starting all on the NDLR before the octatrack is a lot less flexible than I would like. The main problem is that once the octa is going, I am only synced to do one thing with the NDLR. If I ever stop it (say to reconfigure it) while the octa is still playing, I have the same risk of offbeat sync if I ever restart it. Hope that one thing the NDLR did was important, because it is too risky to use it again without a complete restart of both.

This is where the 'start on next downbeat if slaved' behavior for the button would be useful. I could bring the NDLR back in at a predictable time with the button on its interface. Exactly like the special start midi track on the octa would do, but without using any track. No need to bother with CC's at all, either, though there would be no harm in a CC available to do the same thing. If the button itself had the changed behavior, maybe just use the same CC, I don't know.

If the front panel button started on the next downbeat when synced to external clock, it would also be reliable to first cue a track I wanted to sequence the NDLR from, and then bring in the NDLR from it's own interface when I was ready for it to send notes. No extra blank bar needed, although I might have to cue both using two hands if I did not want to wait for my track to loop.

Starting the NDLR with its own button is also potentially a good transition to its interface, as that would be a natural time to start using its other knobs. 

The ultimate version of this delayed start button feature would be to be able to tell it how long to wait to start after a press. Like the elektron plays free tracks can be set up. More fancy than I want, but I could see people asking for this if they had the feature in the first place. I really want it to always start on a downbeat to start the drone and pad in the right place, so maybe just specifying number of bars would be best. If it could only do next downbeat I would still use it. People might want more time for whatever reason.

I only see upsides to this, have to hand it to you. Great idea!

[kastenbalg]

So I could not get CC #90 to work reliably, even with microtiming.



Microtiming fixes the start (the octatrack appears not to do what it is documented to do, if you set the plays free track to a delayed start, the first trig happens at the beginning of the track and the NDLR gets it). I had this first trig sending the p-lock CC start microtimed to -1/24. This seemed to fix the start.




Starting and stopping the NDLR and then starting it again with CC #90 was not reliable. In my tests it seemed like I could switch the clock to the offbeat depending on when I stopped the NDLR with CC #90. If this is true, it is even worse than a start moving the clock. It's another situation where I am confused why anyone would want that. I seemed to be able to keep the clock in the same place on by editing the microtimed -1/24 start trig p-lock to be a stop. That is too fiddly for me for performance, and I am not dedicating still a third track to stopping the NDLR.




I came up with a workaround.




Since my main concern was the drone timing, I started testing it individually to hear it better. Neither CC #86, which starts the drone, nor the button which starts the drone, move the clock. If I have the drone set to play on the downbeat, an individual start brings it in on the next downbeat every time, regardless of when in the bar I send the start or push the button. No fiddly timing, just does what I wanted CC #90 to do. So the workaround is to start the drone individually and not use CC #90.




We now come full circle back to the chord sequencer.




The issue that remains is what I was originally griping about. Although the individual part buttons appear to start an armed chord sequence, CC #86 does not start an armed chord sequence. Don't think any of the other individual CC's do either. Hopefully this is something that gets fixed in the future.



So the right thing for me to do for now to start an armed chord sequence is to use the drone button on the interface. Bam, sequence starts on downbeat with correct drone timing.




We talked about adding a CC for arming / disarming the chord sequence. That would still be useful for working with an external midi sequencer.




The NDLR's behavior on disarming a running chord sequence is a little strange, too. It seems to keep going after disarm. I want it to stop right on the current sequence step. Keep the parts playing on the current harmony. My sequences are one-way modulations, not loops. 'Stop where you are, do not make any more sequence steps, and reset the sequence' is a logical default.





I could imagine people wanting other behaviors, such as 'after disarm finish full remaining chord sequence and go back to first step,' 'after disarm finish full remaining chord sequence and stop on final step,' 'after disarm finish remaining chord sequence letter and go back to first step of letter,' 'after disarm go back to first step of current letter when current step finishes,' 'after disarm finish remaining chord sequence letter and stop on final step,' 'after disarm go to final step of letter when current step finishes,' etc.




These all seem like special cases compared to the intuitive, 'when I disarm a sequence I am not in a sequence anymore and there are no more sequence steps, but parts don't turn off because there are separate controls for that.' After that, I would expect rearming the sequence to start it from the beginning.



Even if I have the option of an external sequencer, the internal chord sequences are still helpful. I can treat the NDLR as a little bank of one-shot sequences that can be reused across different synth settings. The musical harmonies (the NDLR's forte) may be the same, but other things can be dramatically different downstream. Plus I do not have to program another sequencer or synth with the kind of in-key arpeggios the motifs can do.



Thanks much for the thoughtful replies.

[derp]

Has anyone figured out how to reset the sequencer yet? Thanks!

[Jesse Johannesen]

I believe the only way currently is to disable and re-enable the chord seq in the chord seq menu. I have asked for some changes that would allow a button combo from the main page menu to do so, but it is not implemented at this time.
Jesse

[noodleeater]

would love a way to make an external program change with the bottom of the chord changer screen so I can repeat patterns but with a diff sound. 

like

a1    a2    a1
332   32   99   <program changes>