Are you suggesting the one parameter widget would hold values for every variation? e.g. comma separated list?
No, I was thinking one “parameter widget” to correspond with each widget you want to fade.
I had a momentary lapse of reason, though. I was thinking you could have different labels for different variations, but it doesn’t work that way. You’d have to change the widget value to the “fade to” level. You could still encode parameters like “fade time” into the widget label, but it would have to be the same for all variations.
Finally got a chance to play with this - it works pretty well and gets pretty close to what I want, with a few little gotchas. To bind the dials into local rackspace parameters I made another dial and used the Widget Link; there might be an easier method but this let me at least test the use cases.
I set up a somewhat adversarial test case with a synth macro and while the fade works well, it does actually jump on the initial variation change. You can see it both in the plugin dials but can also hear it if the parameter is one that causes an obvious shift. I haven’t had time to play around with if there’s some other method of grabbing and changing the values before GP itself gets to them, or perhaps if there’s just a way to add a slight lag/separation from the linked widget value itself. There’s certainly a lot of convenience if you can map a widget once and set it for both the variation values and have it be the one that smoothly moves, but again if any logic is reused in the global rackspace it would be acceptable to also have something like one widget for setting and a separate one for binding to the smooth parameter.
I’ll play with it some more soon but this is definitely putting me on the right track, thanks again!
1 Like
I am very interested in the possibilities that this script presents and have been trying this Gig file out in GigPerformerPro 5.1.4 on my 2012 MBPro.
In the above example you are making changes by mouse clicking on the variations and rackspaces; this is working for me.
Scrolling with the up/down arrows amongst the variations in rackspace1, instead of clicking, retains the original settings as expected. Scrolling in rackspace1 with the up/down arrows to variation2, clicking on any other rackspace, then clicking to return to rackspace1, opens variation2 with the original settings, also as expected.
I find that there is problem when scrolling between rackspace1/variation2 and the next rackspace2/default. The default, or first variation in the case that there is more than one, will lose it’s settings and assume the settings of the previous rackspace/variation. The same happens in reverse, scrolling back from the first variation of any rackspace to the last of any rackspace next to it.
I tried adding rackspace next/previous widgets and the same behavior occurs.
Have others experienced this?
Simon.
I have posted an update of my modifications here:
Transitioning-morphing input sources in the Global Rackspace through rackspace variations
Simon
1 Like