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.