Problem whack-a-mole with NDLR

[natehorn]

I'm beginning to become a little frustrated with NDLR as I keep encountering issues which seem like bugs.

Instead of making music I've spent my whole morning playing whack-a-mole with NDLR, it seems with every restart one problem goes away and another one surfaces.

Firstly USB MIDI data wasn't leaving the NDLR at all - I fiddled, restarted and the only thing that resolved the issue was loading an init style save, which although had all the same midi settings (i double checked) seemed to magically fix the issue.

Then my pad wasn't working correctly, with the MIDI data the NDLR giving me being several octaves too low and needing to be transposed to even be audible. I randomly hit one of the chord change buttons which fixed this issue - seems that the pad somehow slipped into its own lane.

Carry on with my creative persuits, get a decent groove going but now I find that one of my motiffs isn't changing with chord changes. Everything else is but 1 motiff plays exactly the same notes whatever chord cahnge button I press. Restart NDLR and this problem goes away.

I really love what this device can do but I'm finding my first week is filled with trouble-shooting, stuck midi notes, software bugs and the need to constantly restart NDLR to see if issues go away.

Bit gutted tbh - is this a similar experience to what others have?

[Dirk Offringa]

Hi, Have you checked if you're not producing a midiloop somewhere, or if one of your external devices isn't sending midi data to the NDLR on the NDLR's control channel?

[Darryl]

Sorry about the trouble getting things working with The NDLR. I know it can be frustrating to get a new piece of gear integrated, and it doesn't help to have things changing unexpectedly. Do you have anything plugged into The NDLR's MIDI inputs or could it be receiving MIDI on USB? It sounds a lot like its getting CC messages that could change its parameters. When you restart The NDLR whatever changes were received would be gone. There's no way to disable The NDLR control channel, but make sure its not set to the same channel as KB Trans (settings menu 1).

The motif pattern setting Patt Note Type: chromatic-fixed is what would cause the motif to not change with the chord. If it happens again, before restarting The NDLR, check the Pattern editor screen to see if the motif was set to chromatic. If its changed, that's a sure sign The NDLR is receiving data from something.

There no case in which The NDLR will leave notes on. We've monitored the output extensively and have never seen a case where there isn't a note off following a note on. However, the time between note off and the next note on is very short. Its MIDI spec compliant, but some synths can't handle it. The latest FW on the Open Beta FW forum adds a short delay between note off and the next note on. This might help with stuck notes on a problematic synth. In any case, you should try updating to that firmware if you haven't got the latest already.

[natehorn]

Hi guys. I have a digitakt connected to the NDLR in - but the only mapped CC is for the chord changes and it's not sequenced/sending anything right now (I had it sequencing chord changes yesterday and all was working fine). I have the default settings for the control and keyboard channels (and most other settings). I am sending start/stop to the digitakt via the MIDIB on the NDLR - would this cause a 'loop' (thinking now I assume it can't as I'm using MIDIA for the tracks, all MIDIB should be outputting from NDLR is transport right?)? I'm not sure how this could be avoided.

I was fiddling with the pattern editor so that's probably the issue with that motif! Thanks for the tip, I hadn't even noticed that setting so could well have changed something by mistake.

Setting up the midi configuration has been a bit of challenge - but I have successful sessions and then get plagued with these bugs so whatever it is it's not consistent.

Right now my my Subharmonicon is reacting to every track sent from the NDLR (but only on a specific save), even after restarting the sub, and even though the sub is fixed to a specific MIDI channel. If I send MIDI data from my digitakt to Subharmonicon then it will only play on the right channel. So seems very much like NDLR is sending all track data out on that midi channel.... for some reason.

[natehorn]

Done a little more testing and the issue does indeed seem to be with the Digitakt involvement, but I can't quite workout how or why. But removing it from the equation entirely seems to resolve some of the issues I'm butting up against this morning. Having turned it back on now I'm not currently facing that odd Subharmonicon issue, so this must be some kind of loop I guess?

I have the digitakt sending MIDI to the NDLR, into INA so I can control NDLR parameters (it's not currently doing anything though). NDLR is sending out tracks to USB and to OUTA, and is also sending transport to OUTB, which goes to Digitakt.

My assumption is that due to that setup that Digitakt shouldn't receiving any track data (which is only on OUTA), and I assume that NDLR doesn't forward its own control data out of its ports (in fact I'm sure I remember eading that), so I don't think that there's a loop there is there?

Digitakt is also sending clock/transport out of its SyncB port in the form of DIN24, that goes straight to Pamela's New Workout. That also means that NDLR will be receiving transport from Digitakt via its other port (because it's a global setting to send transport/clock), but the clock is set to internal on NDLR and my understanding is NDLR has no implementation for inbound transport - and so I can't see where a loop is occuring at any point.

[natehorn]

Things seem fairly stable at the minute. I've been fiddling with settings. I turned off the Auto midi channel on the digitakt (which was using 15, although I assume NDLR wouldn't pass its control data thru?) and I turned off transport-send from the digitakt too as I'm temporarily clocking Pam from NDLR's CV out. This isn't ideal longterm as I need the start/stop message for Pam but I can work around it temporarily until I work out where this gremlin is. I also don't see why this would help as digitakt sending transport to NDLR should do nothing as far as I can tell, and even if it's passing it thru nothing receiving it would trip up because of it.

Maybe it's the direction the wind is blowing.

[Jesse Johannesen]

I have a digitakt here, I will take a stab at controlling the NDLR with it this week and run the midi through a midi monitor to see if there's errant CC data being sent out. That seems like the most likely scenario. Sorry you're dealing with this headache.
Jesse

[natehorn]

I appreciate that MIDI has its issues! I'm at the point where I think that I've gained confidence in the NDLR and have started to suspect it is the Digitakt setup that caused some weirdness - still experimenting but things seem OK right now. I have a Blokas MidiHub on its way (which I think is going to pair fantastically with the NDLR) I can only imagine the additional headaches that's going to cause me haha!

Had a great jam this morning I'm in love with NDLR again.

[Dirk Offringa]

I have a digitakt here, I will take a stab at controlling the NDLR with it this week and run the midi through a midi monitor to see if there's errant CC data being sent out. That seems like the most likely scenario. Sorry you're dealing with this headache.
Jesse

Checking what data is being sent/received with a midi monitor is obviously the way to debug this issue. There's rogue midi data being sent/bounced, IMHO. Be careful with LFO's on the Digitakt, BTW. I have a Digitone and a Subharmonicon as well,  but it's all part of a fairly complex set-up I have worked on for a couple of years now, using the filtering capabilities of my iConnectivity interfaces whenever I encounter this sort of (almost unavoidable) problems. Good luck, hope you get it sorted out (I'm confident you will).

[Jesse Johannesen]

I hooked up Digitakt sending MIDI CCs to the MRCC (MIDI monitor) then out to NDLR on the NDLR Ctrl channel. I'm not seeing any errant messages firing through, and while I'm not sending the NDLR to anything to play music (it's just past 5am and I'm in an apartment) the NDLR appears to be behaving as expected. I am sending CCs 26,27,73, and 74 (Chord degree, Chord type, Key, and Scale/mode). I initially noticed it was sending note data for note#60, and realized that I had to use function to convert the trigs to green/yellow control trigs (no note). Now that I have this set up, if you want to give me a better picture of what you're sending (and what specifically is getting altered) I can take a stab at getting it reproduced. Just so I don't miss anything can you give me a list of bullet points to follow to recreate the issue?
Jesse