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

[Ghostz_of_Moar]

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

Hey! Good mawnin’ !

Due to using the Octatrack to hold the majority of the cc data, I could give two shits and a pickle about the NDLR save data, lol. 

I have performed a factory reset and I’m testing the first unit now. 

I’m hoping that was indeed the issue.

And unfortunately there was indeed another crash.

I believe I will have to do a reinstall on the firmware, even though it says I’m up to date.


(Good news)


By using the octatrack as a means to automate an aspect of the NDLR, I can go back to to the NDLR and adjust the knob and get rubber band/flea flicker improvisations.

So in this case it’s the pad position being modulated. I can pretty much twist the knob and raise the timbre and it will shunt back to the original pattern.

---

Firmware verified at 1.1.073 with the nice clicky pots that I can push in.

[Jesse Johannesen]

Interesting read... keep it coming. I have a Octatrack too, but I use a Pyramid for midi duties, but never mind , I share your concerns , this thread is useful, thanks

Thanks I’m still hunting down glitches and I have only heard good things about the pyramid sequencer. I have other sequencers as well, but my decision on using the OT is mostly for the arranger/song view.

The key thing to appreciate about the NDLR sequencing strategy is the fact that almost everything is in midi cc’s...and with a bit of coordination and planning we can enjoy a certain degree of tactical improvisation by placing pinpoint parameter locks on the sequencer and then in the case of the OT turn the entire track off, switch to the NDLR , keep flowing and then re engage the octatrack in either song or pattern mode.

So far it’s best when I stay with 5-6 voices on the paid, btwa.

The midi cc solution could be better. It’s not a lot of fun needle nosing midi cc of 1-7 versus having 1-7 averaged across 0-127

---

I noticed that CC#26 changes the chord degree, but also the motif2 midiport. That's a weird implementation. Could that be related?

Dirk it this was an issue it must have been cleared up in a FW update a while back, I just tested it on my unit and it only changes the Chord Degree for me. I recommend taking a second to get updated to the most recent firmware. In fact come to think of it, that should have been my first recommendation for this whole thread. I'm still getting caught up with reading the thread, but Ghostz, if you haven't yet, I would suggest you check if your FW is up to date too.

Jesse

Hello, my NDLR arrived with 1.1.073 

Am I missing an update because I thought I was fully updated...

Nope, that's the current version, scratch that.

I see what you mean about needle nosing, but changing that now would be complicated (people have put time into creating editors etc). I don't want to try and sell you a solution, but that is one of the things that the MRCC router does, it can scale incoming CCs to a smaller (or larger) range, and map them from one to the other actually too.

I'll get back to you later with my results of my OctaTest.
Jesse

[Ghostz_of_Moar]

Interesting read... keep it coming. I have a Octatrack too, but I use a Pyramid for midi duties, but never mind , I share your concerns , this thread is useful, thanks

Thanks I’m still hunting down glitches and I have only heard good things about the pyramid sequencer. I have other sequencers as well, but my decision on using the OT is mostly for the arranger/song view.

The key thing to appreciate about the NDLR sequencing strategy is the fact that almost everything is in midi cc’s...and with a bit of coordination and planning we can enjoy a certain degree of tactical improvisation by placing pinpoint parameter locks on the sequencer and then in the case of the OT turn the entire track off, switch to the NDLR , keep flowing and then re engage the octatrack in either song or pattern mode.

So far it’s best when I stay with 5-6 voices on the paid, btwa.

The midi cc solution could be better. It’s not a lot of fun needle nosing midi cc of 1-7 versus having 1-7 averaged across 0-127

---

I noticed that CC#26 changes the chord degree, but also the motif2 midiport. That's a weird implementation. Could that be related?

Dirk it this was an issue it must have been cleared up in a FW update a while back, I just tested it on my unit and it only changes the Chord Degree for me. I recommend taking a second to get updated to the most recent firmware. In fact come to think of it, that should have been my first recommendation for this whole thread. I'm still getting caught up with reading the thread, but Ghostz, if you haven't yet, I would suggest you check if your FW is up to date too.

Jesse

Hello, my NDLR arrived with 1.1.073 

Am I missing an update because I thought I was fully updated...

Nope, that's the current version, scratch that.

I see what you mean about needle nosing, but changing that now would be complicated (people have put time into creating editors etc). I don't want to try and sell you a solution, but that is one of the things that the MRCC router does, it can scale incoming CCs to a smaller (or larger) range, and map them from one to the other actually too.

I'll get back to you later with my results of my OctaTest.
Jesse

Oh I was planning on getting the midi router later on due to the sheer size of my setup and my needs. 

Thanks for getting back to me.

ALSO....before I forget.

I’m putting midi triggers(red) on the octatrack’s T1, which define chords I-VII ...this triggers the pad track voicing automatically. everywhere else I use trigless triggers(green) to automate midi cc values which then point.

(Good News)

There are some alternate playback methods for the midi tracks which could inadvertently lead to more happy accidental automation of the NDLR. Up until now all the midi tracks are starting at the same time....but on page 66 of the OT manual there is the “play free” option....which could indeed open some new dimensions up....

[Ghostz_of_Moar]

Update:

On the Octatrack I experienced more stability by using trigless trigs(the green ones) when I used standard midi note on/off triggers it would invariably freeze up the NDLR, so instead I went with CC automation and avoided the note on off.

there is a bit of lag when sending chord and degree changes. its just not as tight as I would expect out of a normal sequencer. So I can parameter lock a chord type change, but then to change the other chord or pad attributes, I find myself putting those triggers a step before the chord type trigger as a work around. I find this is doable but not ideal...mainly because the sequencers timeline is a bit more cluttered...versus having a neat set of macro cc's sent to automate the NDLR.

this strategy has also resulted in less hung notes on the Spectralis D-synth. so far.

So currently to get cc automation right is to place the not just a midi cc trig to set the desired change in attribute....but also placing it prior to the Chord type and also setting another midi cc trig to return the attribute to its prior setting.

fingers crossed to have a no crash day as I automate the spread, range, and strum attributes.

[Jesse Johannesen]

Update:

On the Octatrack I experienced more stability by using trigless trigs(the green ones) when I used standard midi note on/off triggers it would invariably freeze up the NDLR, so instead I went with CC automation and avoided the note on off.

there is a bit of lag when sending chord and degree changes. its just not as tight as I would expect out of a normal sequencer. So I can parameter lock a chord type change, but then to change the other chord or pad attributes, I find myself putting those triggers a step before the chord type trigger as a work around. I find this is doable but not ideal...mainly because the sequencers timeline is a bit more cluttered...versus having a neat set of macro cc's sent to automate the NDLR.

this strategy has also resulted in less hung notes on the Spectralis D-synth. so far.

So currently to get cc automation right is to place the not just a midi cc trig to set the desired change in attribute....but also placing it prior to the Chord type and also setting another midi cc trig to return the attribute to its prior setting.

fingers crossed to have a no crash day as I automate the spread, range, and strum attributes.

This makes sense, as that is exactly how those changes take place. If you press a chord type button, it waits to execute the change until the next Chord degree is selected. That can be the same chord degree or a different chord degree. You will see the chord shape change appear in blue, then turn white when the chord degree is selected.
I'm just starting to set up my octatrack to test this, would you care to give me some of the parameters of your project so that I can try to get the same setup as much as possible?
Especially interested in making it crash, so not the stuff that's working well please

Jesse

[Ghostz_of_Moar]

Update:

On the Octatrack I experienced more stability by using trigless trigs(the green ones) when I used standard midi note on/off triggers it would invariably freeze up the NDLR, so instead I went with CC automation and avoided the note on off.

there is a bit of lag when sending chord and degree changes. its just not as tight as I would expect out of a normal sequencer. So I can parameter lock a chord type change, but then to change the other chord or pad attributes, I find myself putting those triggers a step before the chord type trigger as a work around. I find this is doable but not ideal...mainly because the sequencers timeline is a bit more cluttered...versus having a neat set of macro cc's sent to automate the NDLR.

this strategy has also resulted in less hung notes on the Spectralis D-synth. so far.

So currently to get cc automation right is to place the not just a midi cc trig to set the desired change in attribute....but also placing it prior to the Chord type and also setting another midi cc trig to return the attribute to its prior setting.

fingers crossed to have a no crash day as I automate the spread, range, and strum attributes.

This makes sense, as that is exactly how those changes take place. If you press a chord type button, it waits to execute the change until the next Chord degree is selected. That can be the same chord degree or a different chord degree. You will see the chord shape change appear in blue, then turn white when the chord degree is selected.
I'm just starting to set up my octatrack to test this, would you care to give me some of the parameters of your project so that I can try to get the same setup as much as possible?
Especially interested in making it crash, so not the stuff that's working well please

Jesse

Ok on t1 midi I would place normal trigs(red) to set the I-VII chords....and when I started applying green trigs elsewhere, the freezes happened mainly when I cc’d the spread and range values, but also the poly chain pad.

Today when I used no red triggers and only green there was no freezing, for instance.

[Ghostz_of_Moar]

Happy Holiday if you celebrate.

Empirically speaking...the note on/note off triggers(red) on my Octatrack were definitely causing some sort of freeze up on the NDLR. A strict diet of midi cc parameter locks from the Octatrack(function + trig location) has allowed for much much smoother sailing in regards to automating aspects of the NDLR. I believe the NDLR froze once in the last 48 hours...versus once every 5-45 minutes. This works for both slow tempos and fast tempos working with just the CTRL track and Pad track assignments...and what makes me happy is that there is a workflow to programming in chord structures , progressions and even modulations found in my music literature. The added bonus of 4 of the octatrack's tracks being a snug fit for 1 NDLR means that the OT can easily hold a template and control 2 NDLR sequencers as a midi controller.

I am now cautiously optimistic and will begin to engage other midi cc attributes on the other tracks to do a load test to see how things go.

(somewhat bad but bearable news)

1) timing on sending these commands is not always as tight as I would like. and due to note on/off being unavailable due to stability concerns, there isn't quite the same sense of precision one is accustomed to with note on/off using the octatrack...so if I wanted 16 16th note vamps the red triggers do this fine and then its a matter of setting the chord degree. when a trigless trig strategy is employed then I max out at 8 8th note vamps...Micro-timing still works...but having to cc pad active +64 means that I have to follow up with a pad inactive trigless trig @ -63....which does affect how the octatrack could be used to trigger "stabs" and "vamps" onto the pad track...tracks do have independent time/scale assignments...but yeah note on/off definitely have their advantages.

2) I feel like triggering the pad track sometimes needs 2-3 triggers due to timing issues. one trigger should be able to encapsulate a chonk of midi cc's and it all happen lickety split and the NDLR not miss anything...instead I place triggers...I know that a midi cc occasionally gets missed...and so to deal with that I oft place it before or after the trigger that arms the pad's track. (if this is a limitation of the processor I get it...and I can wait for the sequel...if this is a limitation of the firmware I get it and I can wait for a performance update)

3) There is still the issue of hung notes and I have tried to use the Panic button on the NDLR, Spectralis and Octatrack to no avail. It just sounds like a really faint hung note that doesnt respond to the VCA but I know its there because it goes away once I turn the main volume down. It just happens and my only recourse is to go to the affected Spectralis and reload the song data...I will keep an eye out for it with the rest of my rig.

[Dirk Offringa]

"There is still the issue of hung notes and I have tried to use the Panic button on the NDLR, Spectralis and Octatrack to no avail. It just sounds like a really faint hung note that doesnt respond to the VCA but I know its there because it goes away once I turn the main volume down. It just happens and my only recourse is to go to the affected Spectralis and reload the song data...I will keep an eye out for it with the rest of my rig."

I experience the same phenomenon with a DSI Tetr4

[Ghostz_of_Moar]

sadly the freezing has returned.

I am fortunate enough to have two NDLR units in close proximity to one another and this allows me to jump the cables from one droid to the other. I have also tried to reseat midi cables and switch out the cables in hopes that the problem was more mundane....no dice.

Akai ME30P is used as a 4 in 8 out midi patchbay.

The Octatrack mk1 is the control sequencer. 

Having 2 NDLRs and an octatrack should be a match made in heaven.

T1 and T5 are the CTRL tracks for NDLR A and NDLR B(due to the Spectralis having midi tracks reserved for 13-16, I have opt'd to use keyboard ctrl for track channel 1, and track channel 2 and 3 for the CTRL)

Octatrack's cc assign pg 1(T1, T5) is for cc 85,86,87,88...which provides the on/off switch for the pad, drone, motif1 and motif2

Octatrack's cc assign pg 2(T1, T5) is cc 26(chord degree),27(chord type),73(key/circle of 5th),74(mode/scale),59(humanize),72(tempo)

Octatrack pg 1(T2,T6) is where the Drone's cc CTRL attributes are stored.
cc 20(midi channel assignment), cc 32 drone position, cc 33 drone type, cc 34 drone trigger

Octatrack pg 2(T2,T6) is where the Pad's cc CTRL attributes are stored.
OT knob A - cc 19(midi channel), OT knob B-  cc 28(pad position), OT knob C - cc 29(pad strum), OT knob D - cc 30(pad range),OT knob E -  cc 63(pad velocity), OT knob F - cc31 (pad spread)

The NDLR receive transport and cc data from midi in B(as per manual/firmware requirements)....which goes to the midi patchbay and then to Spectralis A(NDLR#1) and C(NDLR#2)....from there the Midi thru port is used to send data to Spectralis B(NDLR#1) and D(NDLR#2)....and from there the Spectralis thru(B and D) ports are sending transport data to Roland R8(a and b).

When the NDLR freezes the Spectralis can get a hung note but other wise doesnt care...aside from having to reload the song data.

The Roland R8 sends a "ERROR: midi buffer Full" flag...which cannot be exited until the NDLR has been reinitialized.

Furthermore.

another bug found:

If I saved my settings to a different chord type...i.e. 7th...after saving it reverts to triad...this is happening after saving and rebooting.

and mind you I do not believe the Octatrack is sending an obnoxious amount of data to the NDLR...its not like I am sending ease-in and ease-out automation data or pitch bend data. I am just sending cc pulse data to coordinate the the NDLR as an arranger/conductor.

the good news?

2 NDLRs and an Octatrack have proved to be an ideal format for conducting/arranging harmonic motion theory. I have no problem whatsoever conceptualizing and implementing so many lost concepts in a rather organic and fluid manner. The problem with the Octatrack is that its monophonic sequencer lines are limited but with 2 NDLR's its a becomes a juggernaut. Also being able to CTRL the track assignment of the the sequencer's is also of value because for me I can automate the pad assignments and switch between a string and arpeggio and a horn stab...and that goes for each track...so it becomes pleasing in the same way braids and recursive behavior pleases our sensibilities.

---

also: regarding the freeze/full midi buffer : I would not so much as mind it lagging/caching and then catching back up versus a full on crash, freeze, please reboot me.

[Ghostz_of_Moar]

So I went back to using note on/off triggers(red)....and when I would parameter lock in C4-B4...this would invariably cause the NDLR to crash...and it's depressing because the NDLR is the most responsive using note on/off...So I would put a 1-2 bar sequence of 1/8th notes and this would cause the NDLR to freeze as I would try to cycle between Chord I-VII....there are no added setting beyond a note change.

The next work around was to use the Octatrack trigless triggers(green) cc 85 in combination with cc 26-27. the big problem here is that in order for the NDLR to catch all the midi cc triggers...I have to slow the midi track to 1/8th or 1/4 the Octatrack's BPM. I have also witnessed patterns loaded with green(trigless trigs) that can actually overload and freeze the NDLR...So in order for the NDLR to keep up with the OT using trigless trigs it is best to work in quarter notes for now...where the bulk of messages are 1-4, 5-8, 9-12, 13-16...and by serializing the instructions sent to the NDLR...there is less of a chance to bork the session and cause a need to reboot the sequencer.

The OT is only sending transport data(no clock)...and the only midi output track assignments are those going to the NDLR. C-link on the NDLR is set to OFF.

I have not checked on whether or not this is happening with the other NDLR parts...but it keeps me having to use the a sequencer because I want the drone and the motifs to be operating in the same key, the same chord type and the same chord degree.l

---

its really frustrating and understandably causes anxiety because I can see the NDLR putting out the notes exactly as I want them for my purposes...its just when I use an external sequencer to do so by dictation it eventually crashes after a few minutes...

Solutions/workarounds/investigations

1) Chord sequencer on the NDRL with trigless trigs on the Octatrack...but then I lose the agility of the Octatrack's sequencer.

2) record into the Spectralis Dsynth as a midi buffer/motif with quantize set to 1/4 to 1/16th. The drawback of using motifs with the Spectralis is that their max length is 16 bars and can be shortened 1/4 note and transposed...that is it...so for me this is a signficant loss of "pliancy"

3) Use the MV8800 as a sequencer to try and send note on/off and CC(the benefit being longer patterns...but the workflow is a bit more plain and mundane...with still no real guarantee on stability.