02-01-2022, 03:39 PM
Hi Jesse! Thanks for thoughtful and quick reply!
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.
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 ; )
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.
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 : ).
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 : )
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 .... ; )
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!
Quote: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.
Quote: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 ; )
Quote: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.
Quote: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 : ).
Quote: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 : )
Quote: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 .... ; )
Quote: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!