Bugs and UX frustrations

[paranoidi]

I have been trying to use the ndlr with my setup for the past 6 months or so but it just is extremely disappointing and frustrating experience to the point I do not want to use it.

I haven't even learned most of the functionality because these issues are making the device pretty much useless. Most of them have been reported here on the forums but no fixes / improvements have been implemented.

Issues:

- 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 !
- BUG: All notes play incredibly low, changing position has no effect. Everything returns to normal when pressing any of the Chords (I - VII).
- BUG: Notes keep playing (stuck) if stopping at the right time. And with ARPs it's very often that time.
- 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.
- 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.
- UX: Dark blue text on black background. Really hard to read. Please use light blue.
- UX: Pots and buttons miss clicks often. Yes I've read about the detentless encoders in early versions. Not an acceptable excuse.
- 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.
- 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.

I really like the idea, but it's very hard to like the execution here. Apologies for being quite negative here. Any help on any of the issues is greatly appreciated.

Have you considered open sourcing the firmware if you are no longer actively developing it?

[Jesse Johannesen]

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

[paranoidi]

Hi Jesse! Thanks for thoughtful and quick reply!

This is a new issue to me, but I will test it and see if I can recreate the issue ... 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.

This solved the biggest issue for me! I was very surprised that there weren't any "clock out" settings in the menus.

I still think this is broken since by default it will mess up things pretty badly when using external clock. The existing "Clk out" option should probably just have "Off" value. Makes sense and would not even need new UI elements which are pain to add.

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

Yeah, I've read this explanation from the forums before. It would not be hard to handle stop message and send necessary note off messages. All other sequencers that I am familiar with work like this. Is there any practical reason for this behaviour? If not, then this seems like lazy coding or unhandled case if you want to put it more nicely ; )

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. 

The issue is that the way UI / Part states are illogical and work in very confusing way. The underlying issue is just that the UI part states do not reflect the hidden play state which is enabled when Play message is received.

Example:

Let's say you're playing with only motiv-1 and press stop. What happens is that ALL parts are displayed as inactive in the UI. If you press play ONLY the motiv-1 will start playing. There is NO way for user to know (except remember) what happens when you press play.

What's even more confusing is that if you enable motiv-2 when stopped. UI will show that motiv-2 is blue .. and what happens when you press play? Motiv-1 AND motiv-2 start playing.

Do you see the problem here? There is hidden state for each part which is not displayed to user at all when play is stopped.

What I am saying, just make it so that there is no hidden Play state which is combined with what you set in stopped state. It should be "what you see is what you get".

I can not think any reason anyone would prefer it to work in any other way. It fulfills all same use cases but when stopped you will actually see the parts that are enabled when play starts. AND you can toggle them off if you do NOT want them to start. Which was my issue.

It would be cool if there was a boot menu sub screen to select the color values for each type of sprite

Yeah, but that's a lot of work. Just search and replace #0000FF with #0077FF (or your embedded equivalent) or change the constant in code if you've done it right : ).

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.

Very much true. And keep in mind both methods can be enabled at the same time. No need to take out old way. Unless you have thought about using that shortcut in future features it would be nice as it allows accessing the most used features quickly. I don't know about everyone else, but I'm much more likely to access patterns than midi channels settings when using the device so the menu is already bass awkwards and there is no fixing that since everyone has gotten used to it. Shift + pot is a good solution that does not change existing uses at all. Give it some thought : )

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.

Sorry for being salty, you've been super helpful here. I'm still not exactly jumping from the joy with the device, but at least biggest issue seems to be resolved. And I am hopeful that with few updates I don't have to buy teensy board and start coding myself .... ; )

I can assure you the project is not abandoned, we have a made 3 updates to the code since new years in fact.

That's good to hear. I may have been too pessimistic when I read from some post that new updates are unlikely to happen. I haven't found newer firmware than .79 which is 7 months old. 

Keep polishing the firmware, I think it's about 90% there already. But those finishing touches count a lot!

[Raphie]

Ext clock works fine, a double clock means you are merging clocks from 2 sources. This might not be obvious at first, but for sure you have another source somewhere, feeding clock to to NDLR. there can be only 1 device sending clock, or having clock on internal.
ALL other devices must have clk on ext.

[Thark]

I never have any clock problems too, Raphie. I have a large herd of synths and am careful about which is sending clock signals. In fact, most of the time it’s just my DAW that’s doing the clocking. 

Keith

[oldgearguy]

the Conductive Labs-approved solution is of course to buy an MRCC and use that to filter out any unwanted clock messages.   

   

[cee-]

No, the customer-approved solution is, of course: no bugfixes, no further deals...