how much memory does it take to hold open a preset while it's being edited

I mean on the device. Like how much memory does it take to juggle all the knob positions while it's up and running, but before you saved the preset. On a lot of Elektron boxes you don't have to save the project over and over, if you loose power or just turn it off without saving, it's exactly where you left it when you turn it back on. You can always reload from the preset, but it boots with the changes made since the last save without having to have saved it. It just feels really good to be able to flip the power switch off like on an amp or pedal board, having made a bunch of tweaks, pop it back on a few hours later and it feels very hardware esque, it's 100% computer DSP but all the tweaks and changes you had made load up right the way you left it, as if it were 100% hardware, it's just a really cool feeling.
 
shatteredsquare said:
I mean on the device. Like how much memory does it take to juggle all the knob positions while it's up and running, but before you saved the preset. On a lot of Elektron boxes you don't have to save the project over and over, if you loose power or just turn it off without saving, it's exactly where you left it when you turn it back on. You can always reload from the preset, but it boots with the changes made since the last save without having to have saved it. It just feels really good to be able to flip the power switch off like on an amp or pedal board, having made a bunch of tweaks, pop it back on a few hours later and it feels very hardware esque, it's 100% computer DSP but all the tweaks and changes you had made load up right the way you left it, as if it were 100% hardware, it's just a really cool feeling.
Click to expand...
Sounds more to me like the device you're describing is saving the full preset as you edit it (i.e. they've probably got enough bytes of user/factory preset space carved off to fit one preset, and when you load a preset it's copied to those set aside blocks and then saved for every value update). When the device boots it must always load from the blocks of mapped memory where this occurs, that way when you browse to preset +1 it actually goes to the memory location of where it originally would have loaded from and offsets by amount of blocks for a preset, then loads that into this chunk of memory where presets autosave all the time. You then preset -1 and it goes back to the original and loads it into the persistent store. If you actually click "Save", it probably copies the bytes from he persistent store and overwrites whatever was in the original location, so it appears to be overwriting "itself", but it's not.

So lets just say for sake of argument it takes 65,536 bytes to store a preset (I don't know this to be true, but lets just go with it for back of the napkin math sake), and there are 512 presets that your device can store, so that's 32 MBs of flash storage for presets soldered to the board somewhere. Now on our "Teh Kewlz Tonez" device we're manufacturing here at "Armchair Experts Inc" we, the design committee, elect to set aside the top 2^16 bytes for this "active preset location" feature, and you the end user pick preset #7, it copies bytes 524,287 through 589,823 to block 0-65535, you work with it, it constantly saves, you power down the unit, you power on the unit. Now, it doesn't go to memory location 524,287, and read in the next 65,536 bytes (as it currently might in something like that AFX), it instead goes to location 0, and reads in the first 65,536 bytes which is whatever was active the last time you had the device on, and we just tells the user it's "Preset # 7" so they don't get confused that it's says "Preset # -1" on startup.

"Hey, prefect", you say, "that's exactly what I want, great modification!". Cool, unfortunately, now we can only store 511 total user/factory presets in the 32 MB chip we sourced for this task when we originally parted out the board, not 512. "Add extra mems!!", you cry. We could, but the guys in accounting ran the numbers, and that's going to cost and extra $1.50 per unit (in part, installation time, amortized cost of redesigning the entire board layout, etc, whatever), and we're projecting moving 10 million units... that 15 million dollar loss in sales projections is going to be non-trivial for Armchair Experts Inc perspective I'm afraid, it's really going to impact the decision making process when we evaluate implementing this feature.

;)
 
@h.c.e has the right answer to the question you didn't ask in the first post but apparently wanted to know.

The short version is "It would take ones presets worth of storage space to save an edited copy of the preset to permanent storage as well as keeping the original one saved. And the easiest place to find that storage space would be to replace once of your preset saving slots with this temporary storage space. And you'd have to save it every time you made a change so that you could power down without saving.

So it'd be cool, but a bit of a hard one to add after the fact since you'd be asking everyone to give up their final preset slot. Also it might slow down the editing experience running the save operation after each knob twist. And you'd have to think about how you make controlled parameters work (like the wah position coming from your foot pedal). When it's just in memory you can just keep over-writing it and not worry about it polluting the saved preset, but now you've got to make sure you're not saving a new copy every time the pedal moves. Or ever millisecond where the LFO changed a value on some other parameter.

And the chunk of flash storage you're writing this temporary preset to is now suddenly going to get overwritten dozes of times every time you're using the device instead of only when you save changes to that specific preset. Flash storage has a lifetime before it wears out. Through normal use where you just read presets and occasional write them when you're intentionally saving them you won't put a lot of wear on that section of the chip. But always loading every preset into the same chunk of the chip and then re-writing it every time any knob was touched would put a lot of wear on that one specific part of the chip. Now maybe you need a maintenance task that dynamically changes which chunk of chip you use of this to spread out the wear. Or some means of recovery if one part of the chip does wear out. Maybe you keep removing the last available preset slot and it becomes a marker for how much you use your device.

Interesting thought experiment.
 
I imagine:
  • The III's flash memory must have some expansion capacity as FAS implements new features into presets and each preset size expands by a bit.
  • Sometimes removing a feature or simplifying patches can reduce preset size and also free some space
Thus there is likely enough space in flash memory for a special "last edited preset" to be saved that could be restored upon power up.

A reason why this might not be good feature: On the last edited preset I make a change that locks the unit (due to a bug). If this gets saved then on power up it gets loaded and locks again.
 
Last edited:
IronSean said:
And the chunk of flash storage you're writing this temporary preset to is now suddenly going to get overwritten dozes of times every time you're using the device instead of only when you save changes to that specific preset. Flash storage has a lifetime before it wears out.
Click to expand...

True, but most flash controllers implement Wear Leveling. So if the available space in storage is significantly larger than a single preset, there's likely no issue as even w/o wear leveling, flash can handle 3k-10k writes.
 
yyz67 said:
True, but most flash controllers implement Wear Leveling. So if the available space in storage is significantly larger than a single preset, there's likely no issue as even w/o wear leveling, flash can handle 3k-10k writes.
Click to expand...
But 3000 isn't a high number if every knob twist on every preset edit, every scene change, and every preset change you ever do gets written automatically to the same preset slot like in the proposed implementation. Whereas with the current implementation where you only write a preset when you manually save 3000 is plenty even if there was no wear leveling in effect.

I guess I was just spit-balling, and thinking that the drastic increase in writes like for that feature would mean you start having to consider things like flash wear in a way you could ignore before.
 
Elektron uses a cache to hold changes, it's just a matter of not wiping it on power down. It's still not saved saved when you boot back up, it's just where you left it
 
@shatteredsquare a cache is just a generic name for something that holds the contents of a request so future requests can be made faster. But it's not like Fractal "wipes its memory" when it powers down. The memory gets reset because without power it doesn't persist. Like computer RAM. For them to "not wipe it", they have to be saving it somewhere that's persistent after a power cycle then loading it again when it powers back up. It's not "saving" in the way you, as a user, save a preset manually to a place you choose so you can load it later. But on the inside, it's "saving" it somewhere, somehow, so that it can be loaded the next time it boots up to where you left off.
 
You must log in or register to reply here.
Back
Top Bottom