CWITEC

elcallio · Post by **elcallio** » Thu Jan 24, 2013 9:38 pm

Hello all.
I've been busy working on the FX section of the TX Pro, coming along nicely, but I've sort of run info a question that I need to figure out;

How should automation really work?

For those who are not wholly up to date, today there are 32 volume + pan parameters for the 32 first program slots + 64 assignable automation parameters that can be used for modulation in one or more groups.
There are some less great aspects with this though. The first is that since slots can change order or be deleted, the automation of slot volume/pan would change (or break really) if you deleted a previous slot, or rearranged the order.
The second is how the automation setting of params works. Now a set param call from the host just updates the param value, bypassing undo et all, yet the UI is not updated etc etc. Yet, changing the value in the UI will not send automation to the host.

What I'm thinking is to change the system to instead let you select individual parameters for automation, i.e right-click the param in the UI and select an automation parameter to control the value. Henceforth, the effective value of the parameter (in both processing and UI) will be (if automation is active) the value set by the host. Correspondingly, changing the value in the UI will send automation to the host.
The automation settings are saved with the performance (all such params are on the perf level - slot values, fx settings etc).

As I see it, the only downside is that anyone who has been using slot automation earlier will have to redo that setup.

So, thoughts? Does this sound like a good system? It will be a little horrible to implement, but I imagine that it will make automation much sweeter.

(Please note that this will not change how automation parameters as modulation sources work, but it will change automation to have 96 general purpose params instead).

makerprofaze · Post by **makerprofaze** » Thu Jan 24, 2013 11:27 pm

Are you saying that the Volume and Pan automations will become user-selectable fully assignable modulation/automation points? (32+64=96)?

I like this ALOT - and redoing slot automation is really a minor thing to gain ability and power. I actually never realized that GUI values weren't updating the linked automation parameters in the host.

Automated knobs not visually moving has always been "strange"

[edit] uhh... no chance of having 128 host automations? I figure this is the time to ask.

dexterbella · Post by **dexterbella** » Fri Jan 25, 2013 12:22 am

I think this proposed change to automation seems like a more common sense and usable system than the current one. Having to redo the setup in any existing projects seems worth it in the long run.

Crackbaby · Post by **Crackbaby** » Fri Jan 25, 2013 7:38 am

Change to new way

I've done some setups, but nothing i can't change. If i understand this right, every parameter will be up for automation from the host? With correct naming (like "slot 1 filter res")?

elcallio · Post by **elcallio** » Fri Jan 25, 2013 8:24 am

Crackbaby wrote:Change to new way I've done some setups, but nothing i can't change. If i understand this right, every parameter will be up for automation from the host? With correct naming (like "slot 1 filter res")?

No, group parameters will not be automatable, since they instead respond to modulation. But fx settings, slot vol/pan/send/mute/transpose etc will be. I.e "global" parameters.

lalo · Post by **lalo** » Wed Feb 06, 2013 5:34 pm

elcallio wrote: No, group parameters will not be automatable, since they instead respond to modulation. But fx settings, slot vol/pan/send/mute/transpose etc will be. I.e "global" parameters.

But having global parameters for group to be automated would be great.
Think of a whole sampled drum kit.
Every piece of the kit on its individual note will have its own filter settings or adsr settings or wathever. But if you need to get i.e. a LP filter on the whole kit or just put the whole kit ADSR decay value very short...well automatable group parameters come into play in this very common situations...

a.

elcallio · Post by **elcallio** » Sat Feb 09, 2013 1:09 am

I hear what you are saying, but it is really a different deal: You want soundfont style program vs. zone sound parameters, either additive or overriding. This has its pros, cons and merits. It is however not the same as controlling group parameters via automation.
Modulation and external controllers / automation as modulation source works just as well to have "one parameter" to control filter or whatnot. Just select all the groups and do the sound + mod setup -> presto, same sound mangling.
The point is rather that control over group sound parameters are _relative_ (as in modulation, yes), not absolute, which is what automation entails.

Anyhow, I have a working version of the TX with assignable automation for performance parameters (slots + fx). Works really neat, with UI -> DAW / DAW -> UI instant update etc + neatly named parameters. Stay tuned for a release this weekend.

Crackbaby · Post by **Crackbaby** » Sat Feb 09, 2013 9:27 am

Looking forward to it!

Did you do anything about the fixed pitch and allowing modulating it? For using pitch bend etc on drumsounds.

elcallio · Post by **elcallio** » Sat Feb 09, 2013 12:27 pm

Crackbaby wrote:Looking forward to it!

Did you do anything about the fixed pitch and allowing modulating it? For using pitch bend etc on drumsounds.

I'm on the fence of which route to take:

1.) Keep "pitch" as it is (scaled with keyscale). add a "pitch (raw)" which is not
2.) Change "pitch" to be pure "cents", add a "pitch (key)" that scales with key scale
3.) Same as 2.) but ignore key scale altogether.

I am leaning towards 1.) since it minimizes fallout so to say,

CWITEC

KVR Audio

Re-vamping automation for non-group aspects