QUESTION/HELP

[ChrisHooker]

I guess I don't really understand the purpose of having multiple knobs if they are always set to the same value. Why not just have only one knob in that case?

If you're looking for a linkable solution, such as RJ described, I've attached an example I worked up. You can add as many knobs to the system as you like, and link/unlink at whim. The knobs can start out at different values, then link and move proportionally. If a knob in the group hits 0 or 1, it does not prevent the others from continuing their sweep. Boundaries will be limited to 0-1 on the outputs, but relationships (beyond boundaries and back again) are maintained until MouseUp. Once the mouse button is lifted up, the knob will be set to that boundary, and subsequent movements back into range will begin immediately. I'm not sure how that will play with automation (I have not tried it yet).

[RJHollins]

Very interesting solution ChrisHooker !

Works quite nice. Thanks for posting and sharing.

RJ

[Spogg]

Very nice implementation Chris!

Cheers

Spogg

[BobF]

Hello Chris,

Thanks for posting this, very cool.

Hope to see more from you in the future!

Cheers, BobF.....

[ChrisHooker]

Thanks guys.
Unfortunately, testing the automation reveals some issues. I tested by connecting a knob/oscillator in place of the "Set" wireless connection inside the Knob Control, and it gives unexpected results. The automation will not cause an offset in any linked knobs (just the one being automated); clicking link off/on after automating can cause jumps; you can't overwrite the automation by manually moving the control... I'm a bit lost with all that. /Or tired... or both.
If someone is willing to do some improvements, have at it!

[ChrisHooker]

Leaving things half-completed bugs the heck outta me...
I revised the file above with the following changes:

-Fixed a glaring mistake on the knob output (was not supplying correct value due to trigger blockers).

-Fixed the jumping value issue when linking/unlinking.

-Fixed(?) automation to allow manual usage to override playback automation. I've actually never played around with automation testing in SynthMaker/Flowstone, so I don't know how it SHOULD look, but when feeding the knobs oscillating values in place of automation from the Preset's "Set" connection, and then trying to manually override by dragging the knob with the mouse, it would result in a very glitchy knob. Now the manual movements SHOULD completely override the automation. Perhaps in a host, the Parameter primitive would take care of this automatically, but I don't know.

I have not yet figured out how to get automation in one knob to affect a linked knob proportionally. Currently, automation only affects the knob that the automation was written to, whether linked or not while reading the automation. (If linked while writing automation, then all linked knobs should also write their own automation, and thus each would play back their own individual automations as well.) The gist of this: you currently can't for example draw automation in your host as a smooth ramp for one knob and have all the linked knobs automatically follow as well. I will try to fix this, but not tonight.

-I've also made even more spaghetti inside the knob (sorry).

[ChrisHooker]

On second thought...
What would happen if two knobs were linked and each write automation... if automation on any one (linked) knob affected relative levels of any knobs linked to it, each would cause an additional offset in the other, adding to each own's automation. ...Or perhaps if using a last changed primitive, the automation and offset would fight each other.

...I think it may be best to leave automation un-linked. ...Thoughts?

[Duckett]

Just wanted to say many thanks to Chris Hooker for this .fsm- wish I had any answers/insights about automation... I'll bash away at it and report back.

[trogluddite]

...I think it may be best to leave automation un-linked. ...Thoughts?

After a few attempts in the past at building linked controls, I came to pretty much the same conclusion.

As soon as you introduce VST automation, you face the problem of automation for different controls 'fighting' each other, or having to very carefully manage which controls you enable automation recording for in the DAW. It can even lead to the linked controls updating each other in an infinite loop if you're not careful! Due to rounding errors in calculations, even using 'changed' primitives doesn't help much.

It will work if the schematic builder or user decides on one of the controls to be a 'master', and only records automation data for that one, but this makes it a bit opaque what the automation represents and means that you then can't tweak the automation independently for each control when you need to.

In the end, I decided that linking should be a GUI feature only, with each control recording independent automation data, and the controls unlinked for automation playback. I'm sure that's not the only solution, but it seemed to me the only one which works in a way that's intuitive for people who are used to how VST automation usually works.