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

[Jesse Johannesen]

So I did a 48 hr test of my Octa and NDLR at 240BPM blasting 5 CCs and using internal MOD Matrix on top of that and didn't crash once. (I did get some hung notes though). I think it might be time to try it using your exact project. Is there a chance you could email me your Octatrack project so I could load it on my machine and see if it makes my NDLR crash? You could send it to Support@conductivelabs.com

Jesse

Did you use red triggers or just cc automation?

Did you check the timing of the cc commands in relationship to the commands on the NDLR?

The exact project isn’t that hard.

128 bpm 

16 red triggers on the CTRL channel which trigger the note on/off

Parameter locks to the key to choose chord degree C-B (chords I-VII)

That’s is the first test.

Again if you would like for me to film this and post it in a shared environment I have no issue with doing so.

I will check on the octatrack but I did switch the NDLRs over to the mv8800.

---

Also. on the MV8800 the crashing is exponential less than the mv8800...and mostly occurs when I am sending the note on/off cc data from mv8800 and using the NDLR's controls for live edits...even then the crashing is occasional...once a session max(8-10 hours).

with the Octatrack...the note on/off (red triggers) gave me the most trouble.

the issue I had with cc automation on the green triggers was the timing was inconsistent/inaccurate...and if I used lots of cc automation it would crash the NDLR as well.

I did have sessions where in which I was able to let it run for a night(with the green trigless on the OT)...and I thought I was in the clear...and then when I begin to build on the pattern the NDLR would freeze...this would happen when I would look for happy accidents in modulation by changing the time scale in different tracks (have one track play for NDLR CTRL at 1/4 speed against the track for PAD play at full speed.)

I will look into wrapping the OT project up and mailing it to you because there are no samples in it so it should be really light.

I am ok with using the NDLR with the MV8800 ...though it is much bulkier at least its stable and the NDLR units are much more responsive with the note on/off. Stability wise it is like night and day.

I'm glad you're gaining stability with the MV8800, that is encouraging. Since I am not having issues with my NDLR and Octa, I'm wondering if there's a setting on the device which is causing problems? Are you using the same MIDI cable for all these tests? have we ruled that out yet?

Yeah, my test had 8th notes for the red trigs changing chord degree, then green trigless trigs for the chord shape, and 4 other CCs you mentioned being problematic (29,30,31,79 and one other I think they were, but I documented it in a recent reply, it would be better if we had kept this all in one thread but what are you gonna do, right?) 

I can't remember if we have tried factory resetting the NDLR yet, we have occasionally seen corrupt save data cause crashing, I think I may have suggested it a ways back, but I'm not sure about that. To reset the device you press and hold [shift+menu] while powering up which brings you to the boot menu. Press the Pad button to factory reset and panic to continue with the boot process. This will wipe out your saves, but may or may not help with stability. It's definitely worth a shot. 

I'll look forward to that project file. Hopefully that will make my NDLR crash and we can work on figuring out why.

Jesse

[Ghostz_of_Moar]

So I did a 48 hr test of my Octa and NDLR at 240BPM blasting 5 CCs and using internal MOD Matrix on top of that and didn't crash once. (I did get some hung notes though). I think it might be time to try it using your exact project. Is there a chance you could email me your Octatrack project so I could load it on my machine and see if it makes my NDLR crash? You could send it to Support@conductivelabs.com

Jesse

Did you use red triggers or just cc automation?

Did you check the timing of the cc commands in relationship to the commands on the NDLR?

The exact project isn’t that hard.

128 bpm 

16 red triggers on the CTRL channel which trigger the note on/off

Parameter locks to the key to choose chord degree C-B (chords I-VII)

That’s is the first test.

Again if you would like for me to film this and post it in a shared environment I have no issue with doing so.

I will check on the octatrack but I did switch the NDLRs over to the mv8800.

---

Also. on the MV8800 the crashing is exponential less than the mv8800...and mostly occurs when I am sending the note on/off cc data from mv8800 and using the NDLR's controls for live edits...even then the crashing is occasional...once a session max(8-10 hours).

with the Octatrack...the note on/off (red triggers) gave me the most trouble.

the issue I had with cc automation on the green triggers was the timing was inconsistent/inaccurate...and if I used lots of cc automation it would crash the NDLR as well.

I did have sessions where in which I was able to let it run for a night(with the green trigless on the OT)...and I thought I was in the clear...and then when I begin to build on the pattern the NDLR would freeze...this would happen when I would look for happy accidents in modulation by changing the time scale in different tracks (have one track play for NDLR CTRL at 1/4 speed against the track for PAD play at full speed.)

I will look into wrapping the OT project up and mailing it to you because there are no samples in it so it should be really light.

I am ok with using the NDLR with the MV8800 ...though it is much bulkier at least its stable and the NDLR units are much more responsive with the note on/off. Stability wise it is like night and day.

I'm glad you're gaining stability with the MV8800, that is encouraging. Since I am not having issues with my NDLR and Octa, I'm wondering if there's a setting on the device which is causing problems? Are you using the same MIDI cable for all these tests? have we ruled that out yet?

Yeah, my test had 8th notes for the red trigs changing chord degree, then green trigless trigs for the chord shape, and 4 other CCs you mentioned being problematic (29,30,31,79 and one other I think they were, but I documented it in a recent reply, it would be better if we had kept this all in one thread but what are you gonna do, right?) 

I can't remember if we have tried factory resetting the NDLR yet, we have occasionally seen corrupt save data cause crashing, I think I may have suggested it a ways back, but I'm not sure about that. To reset the device you press and hold [shift+menu] while powering up which brings you to the boot menu. Press the Pad button to factory reset and panic to continue with the boot process. This will wipe out your saves, but may or may not help with stability. It's definitely worth a shot. 

I'll look forward to that project file. Hopefully that will make my NDLR crash and we can work on figuring out why.

Jesse

hey no worries. Also I did do a factory reset several times as well as save + load the data.

I did start a convo in another thread because the mv8800 provided a stable solution that justified the purchase of both NDLRs. The second thread was intended not as a bug support but more as a "this sequencer works well(enough...always room for improvement...lol) with the NDLR.  I will get the project file from the octatrack lined  up for you by this weekend.

congratulations on getting vaccinated and I am sorry you felt a bit under the weather.

I cant wait to get mine so I can one day dream of raw dawgin' some air in a shared environment without being of risk to myself or anyone else.

thanks again for your attentiveness in this matter.

[Ghostz_of_Moar]

Hey quick question. When I started using 1/8th note on/off assignments on my mv8800(chords I-VII) , this did crash the NDLR. I have the NDLR pad quantization set to off...because I thought the mv8800/octatrack would handle that.

After turning the pad Quantization to 1/8th note, then the freezing subsided.

The previous patterns used 1 bar to 1/4 note intervals(no pad quantization)....

This could be mitigated by doubling The NDLR bpm by a factor of 2....and “fooling” the quantization 1/8th note function to 16th notes...

I did record 3 videos to document the freezing of the NDLR.

[wolf]

Sorry to keep this thread going... I got my NDLR (FW 1.1.073 / SNr. 13.0144.2010) about 5 months ago. Similar to the issues described above, but in a much simpler setting, my NDLR occasionally crashed.

The setting: master keys (good old Korg M1) or my DAW (Cubase 11 Artist, same with Cubase 10 AI before that) are controlling the NDLR. The NDLR gets fed a chord progression via black keys/white keys on channel 15. The crashes are too rare to notice any similarities for sure. But it seems that chord changes happening too fast or too often might lead to the crash.

During the past month or so, the NDLR crashed about four or five times (reboot). I didn't use it that often before, so it's no wonder it's happening now. Even now, I'm playing it about 15 hours a week, not more.

It's no big issue for me, but I thought I'd share it - in particular, since there are more incidents with other units.

[Jesse Johannesen]

Sorry to keep this thread going... I got my NDLR (FW 1.1.073 / SNr. 13.0144.2010) about 5 months ago. Similar to the issues described above, but in a much simpler setting, my NDLR occasionally crashed.

The setting: master keys (good old Korg M1) or my DAW (Cubase 11 Artist, same with Cubase 10 AI before that) are controlling the NDLR. The NDLR gets fed a chord progression via black keys/white keys on channel 15. The crashes are too rare to notice any similarities for sure. But it seems that chord changes happening too fast or too often might lead to the crash.

During the past month or so, the NDLR crashed about four or five times (reboot). I didn't use it that often before, so it's no wonder it's happening now. Even now, I'm playing it about 15 hours a week, not more.

It's no big issue for me, but I thought I'd share it - in particular, since there are more incidents with other units.

Thanks for the info, I would love to figure this out as I can't seem to recreate the issue here. Can you tell me if the NDLR was receiving midi via the USB, Din port or both in these events? 
Jesse

[wolf]

Sorry to keep this thread going... I got my NDLR (FW 1.1.073 / SNr. 13.0144.2010) about 5 months ago. Similar to the issues described above, but in a much simpler setting, my NDLR occasionally crashed.

The setting: master keys (good old Korg M1) or my DAW (Cubase 11 Artist, same with Cubase 10 AI before that) are controlling the NDLR. The NDLR gets fed a chord progression via black keys/white keys on channel 15. The crashes are too rare to notice any similarities for sure. But it seems that chord changes happening too fast or too often might lead to the crash.

During the past month or so, the NDLR crashed about four or five times (reboot). I didn't use it that often before, so it's no wonder it's happening now. Even now, I'm playing it about 15 hours a week, not more.

It's no big issue for me, but I thought I'd share it - in particular, since there are more incidents with other units.

Thanks for the info, I would love to figure this out as I can't seem to recreate the issue here. Can you tell me if the NDLR was receiving midi via the USB, Din port or both in these events? 
Jesse

Thanks Jesse.

Yes. Every crash has been happening within the same setting:

- Cubase 10/11 was/is the host.

- All Midi-DIN signals are exchanged via an emagic AMT8 Midi hub.
- All other (USB-compatible) musical devices are USB-connected via a hub (active, with power supply). The USB hub is no musical, but a computer device.
- The M1 (master keyboard), is connected to this USB hub via a Midi-to-USB cable.
- Also, the NDLR's USB port is connected to the USB hub.
- Cubase is Midi-connected (DIN) to the AMT8 via a Steinberg UR44 audio interface.

- Mostly, NDLR receives ch15 on DIN A (Cubase/UR44 -> emagic AMT8 -> NDLR), and in at least one case of crashing from the M1 (-> M1-DIN -> USB hub -> Mac -> emagic AMT8 -> NDLR).
- All NDLR signals are sent via USB to various instruments (hardware/external & VST).

There is no additional Midi-thru or similar box between any hardware or the AMT8.
The computer is a MacMini 2018 (Catalina, 10.15.5), 3GHz 6-core Intel Core i5, 32GB RAM.

I will try to run some more tests to narrow it down and, most of all, to recreate it.

One additional bit of information: It's not about bpm. bpm has always been at 90. So, no crazy fast techno.

[Jesse Johannesen]

I can't see anything from your setup that would suggest a problem. This seems to suggest a bug somewhere that we haven't been able to pin down. Keep your eyes peeled and let me know if you find a pattern to the crashing, or if you notice a change in frequency. I'll talk to our team and let them know what's going on, and take some more time to poke at mine to see if I can make it crash. I wish we had a quick fix, but it's so hard to solve these things until it becomes clear what is actually happening.
Jesse

[wolf]

I can't see anything from your setup that would suggest a problem. This seems to suggest a bug somewhere that we haven't been able to pin down. Keep your eyes peeled and let me know if you find a pattern to the crashing, or if you notice a change in frequency. I'll talk to our team and let them know what's going on, and take some more time to poke at mine to see if I can make it crash. I wish we had a quick fix, but it's so hard to solve these things until it becomes clear what is actually happening.
Jesse

Thanks a lot, Jesse. I know pretty well how hard it is to track down a bug or an issue when you can't reproduce it (did quite a bit of coding and QR in my life).

For the last weeks, I mainly worked NDLR-less... as soon as I'm back to tracks with the NDLR involved, I sure will keep an eye on that.

[Ghostz_of_Moar]

I can't see anything from your setup that would suggest a problem. This seems to suggest a bug somewhere that we haven't been able to pin down. Keep your eyes peeled and let me know if you find a pattern to the crashing, or if you notice a change in frequency. I'll talk to our team and let them know what's going on, and take some more time to poke at mine to see if I can make it crash. I wish we had a quick fix, but it's so hard to solve these things until it becomes clear what is actually happening.
Jesse

Hello.

The main issue I have with the NDLR is with automating the chord triggers from an external source.

When I try to trigger faster than an 1/8th it caused an overflow.

even with sticking to 1/8th notes it would crash occasionally.

So if I plop down a line of external commands that trigger the chord every 16th note then within a few minutes it will fail and then the NDRL will have to be rebooted.

I guess this is why in the menu the user is given a choice between : 1/4 note, 1/8 note and no quantization.

Which is sad because if this did not crash the unit with an overload we could do rhythmic keyboards stabs and vamps quite easily...the kind of articulations we find in funk and soul genres.

I haven't checked in because I got busy with life but the issue is still there and I am not looking to make the product look bad or the question the programmer's efficacy in such said matters.

The other issue I have with the Chord/Pad function is how we can have a massive wall of 24 voices but very very little control over the velocity dynamics of those voices...sure they are in the same key/scale but without weighting the velocity on most of my systems it sounds like trash because the triggered frequencies are going full bore all at once. I sure would love a large spread of possible notes while being able to trigger a strictly set number of voices.

So for now with the chord triggers I tend to use a voice count of 2-5 and make my own strum by changing the chord position manually or via automation because currently the strum implementation only seems to go in one direction at a set array of time divisions.

it's still fun to use...its just stuff I had to learn that wasn't made available on the site, the ads, or the manuals.

[MKS30]

I can confirm continuous crashes and have identified the issue (at least for me)

It's the DIN Midi buffers that are corrupting, USB can take anything you throw at it

*update: with NDLR Cntl it's still crashing with only USB, but a fair bit less than using DIN

Question: Can the DIN buffers be enlarged via firmware or are we stuck with old school overruns?