Scale change issue

[Dirk Offringa]

Hi, received my new NDLR yesterday, it's a pretty cool device, nice addition to my toolbox! And congrats for the UI, that's really well thought out, such a tiny screen yet very managable.

I ran into an issue though: in the chord sequencer, when I change scale, there's a hiccup: it looks like a "notes off" message is sent a quarter note before the change, which is too early

Here's an example of what happens. It's 128 BPM, a classic chord progression ||: Minor I - III - V - VII - Isus4 - Major I :||

Sorry didn't have a camera to record the screen, so you have a nice pic of the bridge over the river that crosses my village instead, but it's clearly audible. Happens on all 4 parts but one of the parts having a long release, it sounds like if a pad is not affected but it actually is (you can hear the release at the end of the video, it a motif actually not a pad)

I'm running the NDLR on external clock on midi Din port B.

I have been able to make it work smoothly once or twice, but I could not reproduce it: I suspect this is related to start/stop/continue messages

Any advice/suggestions would be welcome.

Cheers
Dirk

[Jesse Johannesen]

I'll add this to the list of bug sightings and see if there's a good solution to the issue next time we take a look at NDLR firmware. Thanks for finding this and giving a good description of what might be happening that may make it easier to track down.
Jesse

[kpatzsc]

I've noticed the same thing and was going to report it, though I've only played with the chord sequencer once so far.

I also found stuck notes were a happening a lot more when using the chord sequencer, usually on the pad. I almost never get them without using it.

Another thing that isn't necessarily a bug but would be nice to implement: when the drone is set to change based on chord, it doesn't change until the next note-on in the drone (so, once per bar or beat, depending on the drone pattern). I think the "pad quantize" setting should apply to all parts, or the drone at the very least... you want drone and pad to change together in most cases.

[Dirk Offringa]

---

I'll add this to the list of bug sightings and see if there's a good solution to the issue next time we take a look at NDLR firmware. Thanks for finding this and giving a good description of what might be happening that may make it easier to track down.
Jesse

I found the issue: the NDLR issues "all notes off" (CC#123) messages followed by regular "note off" messages which causes the system to hiccup. Filtering out CC#123 fixes the issue. Also, when the NDLR stops, CC#123  is issued on all 16 channels, causing everything that might be running elsewhere to silence too, depending on your routing. I am not sure if this is a good idea. One might want to stop and start the NDLR while playing live on other midi instruments, and unsolicited "all notes off" messages are unwanted of course.

If the NDLR is the only controller in the system, that could be of some interest, but in a more elaborated set-up it might just interfere with other stuff. I believe that the NDLR should issue "all notes off" messages only on request (panic button) and make sure the system is robust enough not to generate hung notes.

cheers
Dirk

EDIT 1: Every once in a while, when the NDLR is stopped (I use ext sync DIN B) it forgets to send "note off " messages, resulting in hung notes. That was not obvious because of the preceding CC#123 but now the I filtered that CC out, it's a bit annoying. As said above, the system needs to be rock solid , not needing these CC#123 messages ;-)

EDIT 2: CC#123 is not processed with real-time priority by most devices (like note on-note off's). It's a "panic" message. Each device has a specific way to react on such a message and can take time to recover. So it should not be used otherwise......

[Gonzinigonz]

Been looking at all this myself.
I've setup a whole bunch of control clips on the Akai Force that send CC's to change parameters on the fly.
I was hoping to do live key changes but found this dropout thing as well. Also changing scale / mode does it.
It also does it off the front panel anyway so I'm not surprised it does the same remotely with CC's.
Maybe a limitation of what's possible with the hardware or how you have to code these things?
For me i can record the events into the Force and edit it later to tidy things up so have a work around.

[Dirk Offringa]

Been looking at all this myself.
I've setup a whole bunch of control clips on the Akai Force that send CC's to change parameters on the fly.
I was hoping to do live key changes but found this dropout thing as well. Also changing scale / mode does it.
It also does it off the front panel anyway so I'm not surprised it does the same remotely with CC's.
Maybe a limitation of what's possible with the hardware or how you have to code these things?
For me i can record the events into the Force and edit it later to tidy things up so have a work around.

As I said in my previous post, I identified the issue, it's solved by filltering out CC#123. I have filtered it ou on my midi router (iCM4+) but you can do it with a midi processor (the cheapest one in the RK-OO2 cable from retrokits). Ultimately this "all notes off" thing should be solved with a NDLR firmware update but we can work around it this way. It's a major (npi) issue though.

[Gonzinigonz]

So i read.
I can't filter out anything on the Force as is. Got it connected via USB. The Forces midi implementation is seriously lacking at present.
Only workaround i could probably do it here with what's available is to connect the NDLR directly to the laptop via USB and use something like Midiox to filter out CC#123 then pass onto the Force using the 5 pin.
I notice also when you set a part running from stop it sends a note off directly followed by a note on. I guess that desirable though and not caused me any issues so far.

NPI? What's that?

[Dirk Offringa]

NPI = No Pun Intended. Filtering with MidiOx would work, with a bit of latency perhaps.

[Gonzinigonz]

Oh...!
Maybe a bit of latency but I'll try it and see what happens....
So it ends up Akai decided to allow an option to filter out all notes off in the system menu, couldn't believe it!!!
Got its own check box.
Midiox worked great as well, just messing about with midi cables and 2 USB midi interfaces with more midi cables between it all.
Now its back on USB straight into the Force.
Now I've just got to figure out why the pad track stops sending notes after the motifs start running....

[Ghostz_of_Moar]

hey thanks for the intel. I find the timing a bit sloppy as well and my work around was to stop sending any note on/note off signals to the NDLR for now if I can help it. Instead I use the midi cc's 26(chord degree),27(chord type),69(chord inversion),73(key),74(mode/scale) and 59(humanize)

I also "plant" the chord degree(#26) down and "pin" the other attributes either before or after the "pinned" trigger. it makes for a messier timeline but it brought the timing changes I was looking to hear.

let me know how it goes.