more slots to save setting

[funktree]

I know Darryl said that the NDLR chip has some limitations with memory when I asked  to save more than 8 “System" setups 
I’m not sure if “teensy” is on a separate board inside of the NDLR. If yes then we could just pop-in a more powerful teensy board.  
If teensy is on the main PCB then I would pay (kickstarter) for “upgrade” to better CPU with more memory. SO we can get less latency when using as MIDI THRU and get more setup slots. And I would call them session slots. 

Also the setup slots could be alphanumeric (yes I know more bytes per slot) so I can have them as SONGS or sessions. 

How about having "floating storage boundaries"  for the biggest memory consumers: rhythmic pattern, melody pattern, setup slots
For example I hardly use melodic patterns, But I do a lot of rhythmic patters so I could use more memory for rhythms and setup slots) 

Thanks!

[Darryl]

The Teensy is down on the board, but good thought. What we need is a super bit twiddler to make a library to partition and address the flash memory on the K20 as storage. That was the original plan, we have lots of free flash space. Apparently it is complex and risky. Someone even posted some test code a while back, but it was pulled due to not wanting novices bricking their Teensys. We would love to see that code. The Teensy LC essentially does this as it has no embedded eeprom, so we thought we could pull it off.

Having a floating boundy is a really interesting idea. I'll have to talk to Steve about how much bigger the Rhythm patterns are vs the arp patterns. The Rhythm patterns are 2x the steps, so could be 2x the size.

[funktree]

Darryl, Thanks

IF I understand correctly you'd essentially ‘rewrite’ the firmware in order to save a preset Correct ? Not bad but risky then you could use memory that you use for preset in different way. I would also like to reprogram at least 10 rhythmic patterns with more ties and rests and perhaps more dynamic changes.

I like to hear that there is “hidden memory" memory. But if you need to do some "monkey business” hacking to access it then the NDLR might become less stable. am I correct ?

[Darryl]

The method would involve a partitioning of the flash space, which is a supported feature of our NXP MCU. In this configuration the program flash space would shrink. The rest of the space would look like flash storage. So the data storage area would not be overwritten by the code flash procedure. If done properly it should be completely safe, but to maintain usability for the maker community and Arduino compatibility, this is considered too risky to put in novice hands. It would be easy to overwrite things, for instance, like the "write protect" bit, so you could never do another firmware update. Based on forum threads we've read this is why PJRC hasn't supported releasing a method to do this. However, for an embedded solution like The NDLR, once implemented and tested, it would be fine.

[funktree]

Here is What drives me nuts ( I took big step back to describe this)

the NDLR to me is like modular extension to hardware synths. To me, this is very valuable proposition and with the mod matrix, NDLR can really produce entire melody line. I’ve done it it works!

So seeing the value now I would spend more $$ for features etc. Either more memory, potential micro SD card slot
But I know you couldn’t originally do this to keep the price down.

So, ... If teensy was on a raised board we could “solder” a micro SD card reader to get 1-2GB extra storage with a micro SD. That would be plenty to save anything what do you think ? Is there a possibility like this ? I know you have to load all libraries to read/write the card but I don’t need to swap the card ever. Just help teensy with memory.

There could be a few users that could do it and then others could go to friends they use for “repairs & soldering” . We'd buy the kit from you, a fork for code with SD reader blah blah ...

[Darryl]

There's no teensy on a board in there, so not so easy to hack. If we had brought out SPI pins to a header then adding a SPI flash part would be possible.