the difference here is that proposed snapshot system would change values in absolute manner (more akin to ableton’s snapshots that are tied to macros), which is why I’ve proposed a fade time setting (in ms/s or synced) to create crossfades from one snapshot to another. but thinking about it practically, there needs to be a better method, you don’t want to always apply linear fade from one whole preset to another.
in some capacity we can already create ‘snapshots’ via modulation system, but it’s tedious and not something universal that you can slap onto any device. things would be a bit simpler if we could have persistent memory across various Grid modules like Array, because those module’s memory get wiped when project or preset reloads.
The Morph device family provide tools for creating track snapshots, performing real/time settings interpolation among snapshots, making device presets and morphing among them, use of multiple sends as a single multi-effect, modulation of any parameter pair in a XY spring panel, free editable envelope modulation, 2-dimensional LFO and XY control through gamepads or joysticks. As long as device parameters can be automated in Ableton Live, they can be interpolated by Morph devices (with rack interpolation limited to macro levels).
Or am I missing something?
Funny that this isn’t already everywhere. I proposed this to Renoise daw over 20 years ago and the user community and the dev shot it down.
M4L simply takes over parameters that are exposed for automation for given devices. which means you can’t edit those parameters directly anymore, only through those Morph devices. and as I’ve said, due to not being native implementation there’s a risk of having established parameter links and whole snapshots getting lost upon crash (like if you use it to control parameters of VST that doesn’t like it for some reason). I had this issue before with just basic LFO modulations and other mappings done via M4L devices, where crashes would typically mean 100% loss of all the mappings and settings of said M4L devices upon project recovery. but that’s just Ableton’s quirk of not having max/msp really as integrated into the DAW as it seems to be. idk about 12 though, but the point is that grafted on system is not something you can really count on, especially when handling snapshots, that can carry tons of parameter changes at once. This can get tricky and why most dev’s don’t want to deal with this.
In Hollyhock Usine it’s on user to make sure you don’t save every single parameter of every module into snapshot even if you only really need to save few parameters. if you carelessly leave every parameter to be saved, you’ll eventually run into big freeze ups when recalling snapshots, especially when doing project-wide ones.
You make some fair points, this needs careful planning. Like generally specific overrides generic, manual overrides automatic. So if there would be automation or modulation in place, what should happen when there’s a conflict with the snapshot, either when the snapshot change is automated along a curve, or adjusted manually.
Edit: So if the snapsot would take priority, maybe the system could sample the current parameter values and interpolate from those when it activates. And then there could be an automatable button to hand the control back to automation over a time frame, along a curve. Modulations should bot be a problem, because they’re relative.
perhaps the coolest way to implement snapshots would be if it was being able to read the actual current value, and then save it in the memory, and apply that snapshot as relative modulation from current absolute value to whatever was in the snapshot. and so you could then use other modulators to apply these snapshots gradually with whatever curve or motion you want. I need to think of a new mockup for that
Yeah, that’s what I was getting to, sounds reasonable in an environment where the values can be whatever when the snapshot modulation kicks in. So we leave relative modulations out of the equation, they do what they do, but we need to handle automation conflicts, and that might be done best with a snapshot amount parameter.
Like then you can have even xy pads and whatever with with different snapsots, and the ongoing automation becomes just another value in the calculation. Then you can return to full automation control from snapshots by reducing the snapshot amount to zero with the time and curve or automation shape you wish to, or even manually if you’re performing. Would this make any sense?