Add automation clips capability to automation lanes in the arrangement view similar to FL Studio and Reason. Currently, automation is linked to the track or a clip that’s shared with the notes and other parameters. This feature suggestion is to decouple the automation from the current clips and have the ability to add separate clips for each automation lane.
The full wishlist:
Ability to loop clips
Ability to slice/join
Ability to color clips
Ability to mute clips
Ability to add common default shapes - Ramp up/down, LFO, etc.
Ability to resize (scale) the clips and its events with a modifier key - like Audio
Ability to comp clips with take lanes. Envision an automation shape library that could be dragged into take lanes and comped together. This would be hugely creative.
Ability to drag clips between different device automation lanes - similar to Reason. This could factor in the min/max values of the initial parameter and scale to the parameter it’s being dropped on e.g. 0-127 > 0-10 would keep the same relative automation curve adjusted to the new values.
It makes for a much simpler and modern workflow to treat automation as clips similar to Midi and Audio data. Instead of having to select automation nodes, you can group them into clips. Then duplicating, moving, etc is simple and quick.
How does this feature fit in Bitwig as a product?
It would speed up our workflows by enabling an automation clip library with reusable shapes.
Is there already an alternative way to achieve this on Bitwig?
Thanks. I had seen that before and it doesn’t quite solve the issue and feature I’m proposing – exposing automation in a lane that’s actually not tied to a midi/audio region
The two automation lanes all contain the same automation curve which I drew once. Using the resize, reverse, and duplicate commands, you can easily manipulate that one shape to create a range of automation easily.
After some tinkering, I found a workaround that accomplishes the workflow but it also illustrates how much simpler it would be to have this capability baked in.
Device Group Track (Midi CC mappings to parameters)
1. Notes (Inst - note output to group)
2. CC (Inst - note output to group)
3. CC (Inst - note output to group)
with announcement of arrangement as well as piano roll improvements in next big update, I think it’s worth revisiting this FR as well as some other related ideas.
The problem with current clip automations is that it’s not obvious when some automations belong to a clip or track level, when just viewing from arranger as is, and quite often when you move a clip that has automation under it, it leaves a mess behind as you move it to different places.
So I think a good solution to that problem, as well as implementation of original FR post would be:
to have clip-level automation color-coded, existing in parallel with track level automation, with absolute automation overriding whatever is on track level where clip stands, and relative automations do the typical modulation-like behavior, displaying projected resulting automation.
option to attach/detach clip automation from note/audio clip and make it exist on automation lane, as automation clip
naturally, that means ability to create automation clips separately, either inserting blank ones like with regular clips, or consolidating from existing track automation within time selection.
ability to drag just automation clip from clips in clip launcher to arranger.
ability to drag clip automations to other tracks for supported/same kind of parameter. needs to be a parameter with same type, range and scale of values.
ability to copy automation clip from any type to macro modulator automation lane, converting range to usual % scale.
and as a bonus, such automation clips could use ‘sample accurate’ option basically they would act at same accuracy as modulators, which is currently missing from automation in general, and I understand the reasons behind automation interpolation, and that option for switching whole automation behavior from interpolation to precise wouldn’t be a good thing either. but when it’s local like that, it should be lighter on resources and more manageable, only applied where it’s actually needed.
basically they would act at same accuracy as modulators, which is currently missing from automation in general, and I understand the reasons behind automation interpolation, and that option for switching whole automation behavior from interpolation to precise wouldn’t be a good thing either. but when it’s local like that, it should be lighter on resources and more manageable, only applied where it’s actually needed.