Introduction of snapshot system, where you can store and then instantly recall parameter states. Main goal to have it for devices, perhaps as a panel like modulators or remote controls, but a stretch goal to also have global snapshots that can store and recall overall project states.
Additionally settings could be added for snapshot fade-in time, and snapshot editor with list of parameters saved and their values, where you can delete parameters from snapshot or add them.
Here’s first rough mockup idea:
What problem(s) would this feature resolve?
Mostly ability to instantly switch parameter states is needed for live performance, but it can also be utilized for performing into arrangement and to have quickly accessible ‘sub-presets’ for your presets and devices. It can also simplify automation where you need to switch multiple parameters at once.
How does this feature fit in Bitwig as a product?
New UI elements needs to be implemented, but nothing dramatic.
Is there already an alternative way to achieve this on Bitwig?
No. The main difference with switching presets is that presets can host any number of modulators and devices within nested chains, so loading time for preset can be pretty long even on fastest machines. Snapshots however would operate within existing preset or device only, affecting only parameters already present, with no need to reload any devices or modulators.
Could it be implemented using Bitwig components or APIs, without Bitwig team’s support?
Could it be provided by a VST or something else reasonably integrated with Bitwig?
VSTs can use program switches, but that’s not something you can use for native devices.
Are there other products that offer this feature?
Ableton Live did implement simplified snapshot system, where it stores only states of mapped Macros. But what described here is closer to Usine Hollyhock implementation, where each rack (track), patch (device) and even project itself can have snapshots, and then in it’s modular environment you can use module that can store and recall states for snapshot system of current patch (could use same idea for Grid).
Relevant links (optional)
7 posts were split to a new topic: [Draft discussion] Snapshot system
Picked up nano pack 3 from toybox audio, which is a set of blocks for reaktor player. Super design, nothing too complex but in combination really powerful.
The snapshot system is cracking: by keeping the number of snapshots on a particular module low (8) and chainable (snapshots modulating snapshots), it keeps everything manageable *and open-ended.
hi i wish to have the possibility to switch from one snapshot to the next in timeframes (seconds) or in beats (e.g. 1 bar, 4 bars,1/8…dotted an so on)
this would it make possible to hear new sounds, as it morphs, that you never expected before and also have never programmed before.
i think this could really be something, when changes made in long fading times…e.g. for pads, ambient and so on
this is built in in the GRM-Tools
as you can see on the mockup, I did include idea of having either arbitrary or beat-synced fade time
This is so important for Bitwig . we need more votes on this feature .
I like the sound of this quite a bit, and so… have my last vote. Might this topic also somewhat overlap or relate to the “undo feature for 3rd party plugins” topic?
realistically there’s no overlap to plugin undo feature, other than the fact that DAW needs to keep track of plugin parameters anyway. but I guess snapshot system can just link to different plugin state instead
I like this idea. This would come very useful to save the settings once you have found something that is good and then create variations of it. I usualyl forget what the settings were at the beginnings so i would end up looking for the sweet spots again and again.
Agreed. This is a vital request that would be an immense help— especially to live performers, remixers and sound designers.
This is already available in Maschine (64 snapshot limit) and Akai Force (hundreds of snapshots possible) . Bitwig and Ableton are missing this (though Ableton has a simple 16 snapshot feature for racks).
Liveset development time would be dramatically reduced as snapshots could be used as decision points for morphing sets into completely new directions.
Likewise, this would greatly enhance remixing and sound design workflows.
All said, this feature would be a major time saver and workflow enhancer.
I think it would be important that user can decide which parameters are stored. All or just some.
One way how I would like to use such feature would be to have some snapshots in an array and then apply some snapshot. The snapshot could be chosen to be for example
- next snapshot
- previous snapshot
- random snapshot (like round robin feature already in Bitwig’s drummachine device)
Yes. 100% additionally would love to be able to use the API to access. Like save & Recall for a basic pass. But also being able to get and set snapshot data manually in the api would allow for some great tools to morph between snapshots using the api.
although I’ve said ‘No’ under ‘can it be implemented with existing API’ I only implied the way snapshots would be user-configurable on devices, but actually I don’t know, maybe it is possible to make an extension that would be able to create and recall snapshots based on remote controls pages. if it’s possible to randomise and manipulate remote control params on different pages, then I wouldn’t be surprised if snapshot system could be made this way as well. but I bet it’s a lot of work and to this day afaik nobody tried.
I have made several extensions that save parameter states. So far my implementations are fairly dicey, especially if the parameters get resorted, renamed, deleted or added… it can create some 0s in the parameter sets and forcing you to want to restart the preset building from scratch. Still once a parameter bank is finalized and it works.
Expect an OSC extension from me in the coming weeks demonstrating this along with the ability to transition from one parameter set to another via crossfader. I could use some help testing and debugging.
The first iteration will focus on project remotes but am building it with the intention to be adapted to any number of TrackRemotes/CursorTracks/Devices. I’m also working to abstract it enough so you could easily port it to another control surface.