Hi...my NDLR x 2 FW 1.073 is crashing alot

[Jesse Johannesen]

Update:

Technical error found in the manual pg. 57

For the Pad track.

midi cc 18 chooses the midi PORT usb, midi all, midi a or b, etc.
Midi cc 19 chooses the midi channel 1-16

In the manual it is currently vice versa.

Stability is improving but still no optimal settings for rock solid operation*.

I’m wondering if it’s data overflow that causes it to choke but it doesn’t make sense due to the comparative modernity of this sequencer to others.

By rock solid I mean performance ready for a festival or concert where 1000+ people paid 20 dollars or more and the sequencer isn’t seen as a weak link in the chain. My vision is to be able to use the octatrack in tandem with the NDLR units to sculpt out of groove based on harmonics and that happens from ground zero(no data) or have saved sets of triggers and p-locks.


Benefits? (Good news)

The octatrack and each NDLR are tempo independent and the NDLR’s can grab their tempo from the octatrack via midi cc or clock or run independent. The octatracks triggers allow for then pad’s to have a precise responsiveness which combines the play/pause with the position. Combined with the strum there are so,e great stabs, runs and glissandos happening with great nuance and not a whole lot of effort. I could use the mv8800 for this but the truth is the octatrack is more efficient and easier to manage space wise.

The midi select channel option is incredibly useful for my setup...because I can have 3 different voices loaded on the dsynth found on the Spectralis. Each having an octave switch, filter setting and an arpeggiator switch. By placing a triggerless parameter lock I can develop an array of extremely rhythmic harmonic tones based on switching the pad’s midi channel from 13-16. The only other way to achieve this would be to manually go to settings and switching it myself...but then I lose the functionality timing and refining the patch settings for each of the d-synths.

I am glad you're finding a little more stability, I am still not sure whether or not what we're dealing with here is a hardware issue, a firmware bug, or if we're dealing with a data bandwidth issue, however I am leaning more towards 1, or 2. I think we need to do a few things to figure that out:
1. we need to check the firmware and make sure you're using the newest available option, and in some cases we've seen instability caused by corrupt save states so I am going to suggest doing a factory reset after the update. (press and hold [shift + menu] while power cycling to enter boot menu then press the PAD play/pause button to reset the eeprom. You will lose save data, but it may be that is the cause of your issues so we have to check.
2. we need to simplify the setup and see if we can get both of the units to fail under the same conditions individually (I know you mentioned coming back to find them both frozen, but I would like to see it happen more than once on unit 2), so crank up that pad voice count and lets see how number 2 does under fire.
3 I still need to test the Octatrack and see if I can get mine to crash under similar conditions, so far I have been using MIDIox to send all the CCs you've listed and no amount of modulation one at a time is causing me any issues, besides an occasional hung note when adjusting polychain live. I should also say that the NDLR shouldn't have bandwidth problems for something like this as it can pass loads of data through without issue in my experience.

I may need to take a stab at it with the OT tomorrow as I have been working now all day and I need some rest.
Best of luck!
Jesse