There is one thing that I find very annoying: Modules that aren’t remembering their state after power off. I have a few of them and it feels unnatural. I have this great case where I plug in all my cables to define a new instrument each time and these cables are staying as long as I let them plugged in. Also all the knobs and switches aren’t changing automatically after I turn the case off…
So why are some modules resetting? It drives me nuts and I even let it run over night 2 times, simply because I didn’t want to lose my work… One could say it wouldn’t be much of a problem but I would need to either write down the following and/or save each module manually (which takes some time for some modules and works differently with every module):
Rene: Selected quantized notes, selected mode, etc. (a total of 64 possible values…) or saving
Yarns: All selected settings, melodies, etc. or saving and loading
Braids: Selected mode
Frames All placed frames or saving
Peaks: Is remembering (yay!) but in expert mode it only remembers the first 4 parameters. I’m using it most of the time in expert mode so
Maths: Cycle on/off
DPO: Selected mode of vco a
uScale: Selected/entered scales and settings or saving and loading
I don’t know. It somehow looses the magic „I craft my own instrument while patching“ a bit and gives me some annoying work.
I can’t see any advantages why the modules behaving like this. Is it technically because of slow saving? I can’t imagine… I would rather prefer If they could remember their state and if I need to manually init their settings or save them to additional saving slots.
Someone wrote on muffwiggler:
For me part of the magic of the modular is that I have physical modules that are in some physical state that I can set and manipulate using my physical hands. If I wanted to have to set things up again after a power cycle is use a computer!
Maybe I’m the only one that finds this annoying.
State has to be saved somehow. If you use a battery it runs out, if you use flash memory it wears out.
The reason why there is no permanent autosaving on some of my modules is that it would either be too slow (and would cause a little freeze every time something is changed) and/or that users can create a very high number of changes per second (scrolling fast through all modes in Braids for example), which would reduce the life-span of the module given the finite number of read/write cycles of flash. RAM and a tiny battery would be a more future-proof solutions, but it has its disadvantages too.
Ah okay. Thanks for the explanation.
How about monitoring supply voltage and/or Brown Out and then save when the end is near?
I’m not sure how feasible it is but it’s a cool idea!
Not feasible on the PicAxe without a 500µF+ Cap…… but maybe - in rare occasions - ARMs might be faster
Another idea: Start a timer each time the user is doing something. Wait for 30-60 seconds of no user changes and save.
Of course if the user is powering the case off directly after turning the knob the changes won’t be saved, but still better than manually saving.
never tried it myself but i read on the uC forum that it can be achieved by using a big cap.
Drop in supply votage is detected and the power stored in the cap is used to perform a final save before the module shuts down.
Id be pi**ed off if i turn a knob and jam and sometime after theres a glitch.
Main objective is deliver your outputs undisturbed, no matter what happens - and if i don’t touch the module and it glitches more or less unpredictably . . . . imagine you sitting in a plane and the engines glitch, just because they have to send their status update
> Wait for 30-60 seconds of no user changes and save.
Some people make drone music and happily leave a module doing its thing without any knob tweak for a few minutes.
What has it to do with my statement? I simply mean the module waits for the last user interaction and counts to 30-60. Then it saves. If the user moves some knobs during counting you reset the timer.
SSD drives have a super-capacitor for committing buffered data to flash upon power down.
Ah okay. Now I understand. Sorry
Mungo modules support a zoom feature for many of their knobs - it is triggered by a button which communicates with all Mungo modules by hijacking the CV bus line on the Eurorack power cable, which is rarely used by anything other than a few Doepfer modules. A state storage module has recently been announced which makes even more interesting use of this de facto digital comms bus. Such a module solves the persistent state problem, as well as allowing on-the-fly switching and sequencing of module states. MI digital modules could be engineered to support this standard, or a better standard if it is inadequate. At the very least, the standard could include a “save your state” command, which when received causes modules all modules to save their state to internal persistent storage. The you could have a SAVE button for your entire rack, which you press before powering down - or if your power supply is intelligent and has a soft-switch, it sends it for you before powering itself down.
Before you know it, your Eurorack case will have a low-latency 40Gbit/s InfiniBand network in it.
Now thats finally a brilliant idea to use the excess 2 lines. Pull the Gate high means Save. That easy.
Will implement this asap ……
- you can sell a 95€ “Memory Commander” Module with just a button
Module parameters will be stored using this:
Nah. Thats magnetic you old HERETIC!
Real Modularists use this:
And theres a handy translation table for Eurorack / 5U / Buchla: