02-01-2022, 06:53 AM
Hi P,
Thanks for the feedback, while I can understand the frustration, I can assure you the project is not abandoned, we have a made 3 updates to the code since new years in fact. The fact of the matter is that we are currently not making any new NDLR units due to parts shortages, and there is a question of how much time does it make sense to spend on solving problems in a device that we are not currently seeing any income from. There is a correct answer that is non zero, and so we are spending time on it, it's just that there are other things to do as well that will contribute to allowing us to keep our jobs.
I'm happy to take a look at some of these issues and see if I can find a way to get them in front of the developer. There are some things that will likely be fixable but others that are probably going to be architecture dependent and not fixable without rewriting everything.
Let's take a look at some of these things and see if we can figure out what might be potentially solvable.
- MAJOR BUG: When NDLR is configured to receive clock from USB 1 it will send out clock signal causing tempo to double on all other devices !
This is a new issue to me, but I will test it and see if I can recreate the issue, I don't think this would be too hard to fix. The NDLR is set up to pass MIDI from USB1 to downstream devices on DIN A, so it's likely that it's just missing a line of code to block the clock when set to external clock.
There is another bug (this actually may be the same thing) where multiple MIDI connections to the NDLR (ie from the same DAW) will cause the clock to multiply when all ports are set to receive clock. There is a setting in the boot menu that selects clock from Port1 or 1-4 and it's possible that switching to 1 will solve this for you. It's worth a try at any rate. To get into that menu press and hold [SHIFT + MENU] as you power the device, pressing the appropriate play/pause button will toggle the selection and you can save and finish booting by pressing the Panic button
- BUG: All notes play incredibly low, changing position has no effect. Everything returns to normal when pressing any of the Chords (I - VII).
This is something I've noticed. The NDLR starts up in an unknown state where no Chord Degree is selected, and only adds notes to the pool once a chord button is pressed. I'm not sure what is causing the issue but it does seem like something that could be solved with minimal effort. I'll see what I can do.
- BUG: Notes keep playing (stuck) if stopping at the right time. And with ARPs it's very often that time.
This sounds to me like you're running the NDLR with an external clock. When run this way, the NDLR only advances it's internal machinations when the clock is received, so if a note is on when clock stops coming in then that note stays on until such time as it receives the clock tick that would turn it off. Pressing Shift and Panic will cancel all active notes in cases where a note continues to play past when you would like.
- BUG/UX: Disarming all Parts does not work logically. If I explicitly disable them when (ext) clock is not running and then start external sequencer which starts sending clock and play message they are enabled again. Why can I even toggle these (stopped) if it has no effect? If I turn them of I want them to be off.
I'll have to think about this one. If I understand what you're saying is that if all parts are stopped, and the NDLR receives a transport Play message, then all parts start playing, which is what I would expect would be the desired result. If they didn't start I would probably receive a very large amount of salty emails asking why they don't start.
To create a separate Start behavior for each part based on individual play pause states would require a very large edit of the device architecture and is not something that would be likely to occur and may also not be possible due to the shortage of non volatile memory left available for the device at this point.
I suggest that it may be possible to some of the way to what you're aiming for with mutes, either physically on a mixer, or via MIDI CC in a DAW. You could even set up the MIDI controller page of the NDLR to control those CCs if you put your mind to it.
- BUG/UX: Using external sequencer to trigger Chord changes is nice, but it is guaranteed to mess your patterns once you go into edit screen.
Yeah this is kind of a pain. I would really like there to be an off switch for this functionality. It's probably doable but would be more work than some of the other things listed and as such will probably be lower on the likelihood of completion scale.
- UX: Dark blue text on black background. Really hard to read. Please use light blue.
It would be cool if there was a boot menu sub screen to select the color values for each type of sprite. This would probably not be a super quick fix, though so it's less likely to get done.
- UX: Pots and buttons miss clicks often. Yes I've read about the detentless encoders in early versions. Not an acceptable excuse.
This is something we're in the process of addressing. Not a quick fix, but it's a priority. I would expect this to be fixed this year.
- UX: Setting Tie / Rest in Rhythm editor is definition of pain. Scrolling 129 values with the two Tie / Rest mixed in with encoders which miss clicks often. This could be easily remedied if shift + left rotation would go directly to Rest and shift + right rotation to Tie (or other way around). That way nobody has to hunt those. Easy and quick.
Great idea. I would love to see this implemented. Let's see what Steve says.
- UX: Going into pattern editor, mod matrix etc is behind seemingly unnecessary complicated key combination. Shift + menu and then clicking encoder. Why not just shift + encoder? That would be available unless I'm missing something.
True, but it's consistent with the way the menu works. I guarantee that if I were to change this now, it would piss someone else off. There's always going to be someone who doesn't like how the knobs work no matter what you do.
So I will take a look at the Clock thing and see if I can confirm it as a bug, and will pass this along to Steve to see what we might address. Of course I'm just the support guy so I can't make any promises other than I'll try my best. In the mean time I would ask that you consider that this is a forum that we provide so that our users have access to support, from me and from each other, and when I log in to find a post with such a salty title it make it really stressful to do my job. I would really appreciate it if you would take a minute to edit the title of this post to be something less negative. Constructive criticism is welcome, and important, even, and it's possible that this post may have an impact on making the NDLR a better device, but it would be nice if that could happen without sapping the crew's morale in the process.
All the best,
Jesse
Thanks for the feedback, while I can understand the frustration, I can assure you the project is not abandoned, we have a made 3 updates to the code since new years in fact. The fact of the matter is that we are currently not making any new NDLR units due to parts shortages, and there is a question of how much time does it make sense to spend on solving problems in a device that we are not currently seeing any income from. There is a correct answer that is non zero, and so we are spending time on it, it's just that there are other things to do as well that will contribute to allowing us to keep our jobs.
I'm happy to take a look at some of these issues and see if I can find a way to get them in front of the developer. There are some things that will likely be fixable but others that are probably going to be architecture dependent and not fixable without rewriting everything.
Let's take a look at some of these things and see if we can figure out what might be potentially solvable.
- MAJOR BUG: When NDLR is configured to receive clock from USB 1 it will send out clock signal causing tempo to double on all other devices !
This is a new issue to me, but I will test it and see if I can recreate the issue, I don't think this would be too hard to fix. The NDLR is set up to pass MIDI from USB1 to downstream devices on DIN A, so it's likely that it's just missing a line of code to block the clock when set to external clock.
There is another bug (this actually may be the same thing) where multiple MIDI connections to the NDLR (ie from the same DAW) will cause the clock to multiply when all ports are set to receive clock. There is a setting in the boot menu that selects clock from Port1 or 1-4 and it's possible that switching to 1 will solve this for you. It's worth a try at any rate. To get into that menu press and hold [SHIFT + MENU] as you power the device, pressing the appropriate play/pause button will toggle the selection and you can save and finish booting by pressing the Panic button
- BUG: All notes play incredibly low, changing position has no effect. Everything returns to normal when pressing any of the Chords (I - VII).
This is something I've noticed. The NDLR starts up in an unknown state where no Chord Degree is selected, and only adds notes to the pool once a chord button is pressed. I'm not sure what is causing the issue but it does seem like something that could be solved with minimal effort. I'll see what I can do.
- BUG: Notes keep playing (stuck) if stopping at the right time. And with ARPs it's very often that time.
This sounds to me like you're running the NDLR with an external clock. When run this way, the NDLR only advances it's internal machinations when the clock is received, so if a note is on when clock stops coming in then that note stays on until such time as it receives the clock tick that would turn it off. Pressing Shift and Panic will cancel all active notes in cases where a note continues to play past when you would like.
- BUG/UX: Disarming all Parts does not work logically. If I explicitly disable them when (ext) clock is not running and then start external sequencer which starts sending clock and play message they are enabled again. Why can I even toggle these (stopped) if it has no effect? If I turn them of I want them to be off.
I'll have to think about this one. If I understand what you're saying is that if all parts are stopped, and the NDLR receives a transport Play message, then all parts start playing, which is what I would expect would be the desired result. If they didn't start I would probably receive a very large amount of salty emails asking why they don't start.
To create a separate Start behavior for each part based on individual play pause states would require a very large edit of the device architecture and is not something that would be likely to occur and may also not be possible due to the shortage of non volatile memory left available for the device at this point.
I suggest that it may be possible to some of the way to what you're aiming for with mutes, either physically on a mixer, or via MIDI CC in a DAW. You could even set up the MIDI controller page of the NDLR to control those CCs if you put your mind to it.
- BUG/UX: Using external sequencer to trigger Chord changes is nice, but it is guaranteed to mess your patterns once you go into edit screen.
Yeah this is kind of a pain. I would really like there to be an off switch for this functionality. It's probably doable but would be more work than some of the other things listed and as such will probably be lower on the likelihood of completion scale.
- UX: Dark blue text on black background. Really hard to read. Please use light blue.
It would be cool if there was a boot menu sub screen to select the color values for each type of sprite. This would probably not be a super quick fix, though so it's less likely to get done.
- UX: Pots and buttons miss clicks often. Yes I've read about the detentless encoders in early versions. Not an acceptable excuse.
This is something we're in the process of addressing. Not a quick fix, but it's a priority. I would expect this to be fixed this year.
- UX: Setting Tie / Rest in Rhythm editor is definition of pain. Scrolling 129 values with the two Tie / Rest mixed in with encoders which miss clicks often. This could be easily remedied if shift + left rotation would go directly to Rest and shift + right rotation to Tie (or other way around). That way nobody has to hunt those. Easy and quick.
Great idea. I would love to see this implemented. Let's see what Steve says.
- UX: Going into pattern editor, mod matrix etc is behind seemingly unnecessary complicated key combination. Shift + menu and then clicking encoder. Why not just shift + encoder? That would be available unless I'm missing something.
True, but it's consistent with the way the menu works. I guarantee that if I were to change this now, it would piss someone else off. There's always going to be someone who doesn't like how the knobs work no matter what you do.
So I will take a look at the Clock thing and see if I can confirm it as a bug, and will pass this along to Steve to see what we might address. Of course I'm just the support guy so I can't make any promises other than I'll try my best. In the mean time I would ask that you consider that this is a forum that we provide so that our users have access to support, from me and from each other, and when I log in to find a post with such a salty title it make it really stressful to do my job. I would really appreciate it if you would take a minute to edit the title of this post to be something less negative. Constructive criticism is welcome, and important, even, and it's possible that this post may have an impact on making the NDLR a better device, but it would be nice if that could happen without sapping the crew's morale in the process.
All the best,
Jesse