NDLR 2.0 ?

[Carlbark]

Hi!

I have seen many feature requests being answered with the device being almost out of flash memory, meaning the feature might not be possible to add due to hardware limitations.
As it stands currently, four encoders shift-pages are unused, and two of them even have printed labes (settings 4 and 5). How will they be expanded given the memory constraints?

Will there be a hardware revision with more memory to allow future expansion? Will existing owners be able to buy a memory addon? Are you planning a new version all together with perhaps more alterations (a larger screen, less clicky buttons, capacity sensitive encoders perhaps?)? I understand you are busy finishing the MRCC but it does make sense continuing building the NDLR platform after that as you already have a very engaged and happy customer base. Perhaps you can even offer a small discount to previous backers for the new version should you use i.e. kickstarter.

[Royce]

Hi!

I have seen many feature requests being answered with the device being almost out of flash memory, meaning the feature might not be possible to add due to hardware limitations.
As it stands currently, four encoders shift-pages are unused, and two of them even have printed labes (settings 4 and 5). How will they be expanded given the memory constraints?

Will there be a hardware revision with more memory to allow future expansion? Will existing owners be able to buy a memory addon? Are you planning a new version all together with perhaps more alterations (a larger screen, less clicky buttons, capacity sensitive encoders perhaps?)? I understand you are busy finishing the MRCC but it does make sense continuing building the NDLR platform after that as you already have a very engaged and happy customer base. Perhaps you can even offer a small discount to previous backers for the new version should you use i.e. kickstarter.

I was wondering if a solution to the running out of parameter space might be be the reduction of Presets from 8 to, say, 6 or even 4.
The presets are the largest single element in the NDLR
As the Library program is getting close to finished and real time Preset dumps directly to the buffer from it are possible perhaps this could solve the memory shortage issue.

Does any one use all 8 presets regularly for gigs or projects?
For these times you would have to have a computer with the library program with you, which is a pain I know.
It takes away from the NDLR setup's ability to be computer free, which is one of its big pluses, but would you trade that for more features ?

Any of other elements are also real time transferable so it could be 1 Sequence or just 10 Patterns and 10 Rhythms in memory and dump any number of these elements from the computer in real time.

Just a thought
Royce

[0xF0]

I'm totally cool trading preset count for features.

[Carlbark]

Great idea Royce! And thank you for your hard work with the librarian!

I would also trade preset slots for features. Still, it makes me wonder how much memory you could actually free up and how much space that is required to cater for most of the requested features.

[Jesse Johannesen]

Great idea Royce! And thank you for your hard work with the librarian!

I would also trade preset slots for features. Still, it makes me wonder how much memory you could actually free up and how much space that is required to cater for most of the requested features.

Good question, to give a little insight into save slot data, for every feature that is an on off choice it takes 1 bit, plus 1 bit for each save slot (x8) for each feature that has multiple choices you need enough bits to accommodate those (if pad range has 32 possible settings for instance you would need 5 bits) and 8 times that number for the saves (40 bits total for our pad range demo) The NDLR saves basically every setting for the save slots, so as you can see it adds up.

While the idea sounds enticing, it would require a major redesign of the software architecture which isn't something I can see likely at this point. Not to say it won't ever happen, just that I wouldn't plan around it. I'll log it as a feature request though and run it past Steve next time we get together.

[Royce]

Good question, to give a little insight into save slot data, for every feature that is an on off choice it takes 1 bit, plus 1 bit for each save slot (x8) for each feature that has multiple choices you need enough bits to accommodate those (if pad range has 32 possible settings for instance you would need 5 bits) and 8 times that number for the saves (40 bits total for our pad range demo) The NDLR saves basically every setting for the save slots, so as you can see it adds up.

While the idea sounds enticing, it would require a major redesign of the software architecture which isn't something I can see likely at this point. Not to say it won't ever happen, just that I wouldn't plan around it. I'll log it as a feature request though and run it past Steve next time we get together.

Sorry Jesse, I didn't realise that was the internal structure for the data.
You have obviously jammed it all into a really small space.

Looks like the NDLR is as it stands, which is a great device.

Royce