If @joebot would pay you by the hour, he would have posted the gig file long ago.
Hello Mr. Mechanic, I would like you to repair my car, but without looking under the hood… 
2 Likes
Yeah, my version of this is,
Dr. I’m not well, please cure me — no, I won’t tell you my symptoms
2 Likes
Ok, here we are…
- Way too many elements for an easy optimization progress - you made it harder than it had to be (for yourself and also for me) → My advice for the future: start at a small scale and first then, when this works, go for the “real dimensions” of your project!
- I found a wild mix of widget settings regarding “Initial values” and “Reset on activate”… that way you always got some value changes when switching rackspaces. Same here: Start with only one group of widgets, make your settings properly, then, if all is correctly set and working, duplicate them (the widget settings will be copied as well)
- I separated the former "SetFading()" function into a "StartFading()" and a "StopFading()" function. That way it is easier to make a distinct decision wether to Start or Stop/Reset already in the "On WidgetValueChanged()" callback. Now you can also stop a fading manually and it will be reset to the starting value. You could also make a “panic/reset” widget by just using a loop which runs through the array indices an calls the "StopFading()" function… might be useful too.
1 Like
1 and 2: Yes, of course, you are correct, always start small with a proof of concept, then duplicate out to the full scale of your project. (And this applies pretty much to all projects in life, no?) I did do this, in fact. I started with just 3 sets of faders/buttons, the minimum amount that I thought would make sense to understand how arrays and indexing worked (see my originally posted code at the top of this thread). And they were all identical in terms of their initial values/reset on activate settings. I only expanded out to 14 once it was working, albeit in-elegantly, with where we left it yesterday (and it seems I was not as careful as I should have been when expanding). So, that should not have effected the issue I was having in any way, which I noticed with just the 3 fader proof of concept. The root cause seems to be that GP sends out widget value events on gig load, regardless of what settings you choose in Value tab of widget settings - either ‘Last Saved’ or ‘This Value’. (And if that’s not the case, I’d love to understand that section better). And that is what necessitated adding an if/then statement in the On WidgetValueChanged callback, which allows us to only call certain functions when the widget button is either on or off. Anyway - yes, start small, get it to work, then expand. Always good advice to remember.
3. Ahhhhhh ok, I see. A few things:
A) Duh. I didn’t remember that StartValue[ ] is ALREADY a global variable! Of course it can be used in any function, you just need to re-declare the indexing variable (Ai : integer). Feeling new levels of stupid:)
B) I like the StopFading function, it makes perfect sense. The only thing I am changing is, I am adding a SetWidgetValue(BypassButtonFX[Ai], 100) line before the SetWidgetValue(BypassButtonFX[Ai], 0) line, so that whenever you stop fading and return to default value, you clear out whatever sound is in that plugin. Otherwise, you run the risk of slamming back to full volume with an intense effect that is still ringing out in the plug-in, which is generally not a very musical/pleasing sound. A quick bypass/unbypass can also sound jarring, but it’s the lesser of 2 evils, from my POV.
C) I see that you added StartValue[i] = GetWidgetValue(ReturnFaderFX[I]) to the initialization block, which is also very elegant and smart! Now, with that done, do we still need StartValue[Ai] = GetWidgetValue(ReturnFaderFX[Ai]) inside the StartFading function? The only purpose I can see for that would be if we changed the level (value) of the Return Fader after initializing on start up. And since I will be removing the TouchOSC controller for that fader from my touch screen (the original motivation for this WHOLE project), it will only be possible to change it with the mouse, which I won’t be doing. So, I THINK this line is now redundant? I’ll test removing it to see.
D) Adding a RampLength global variable is also elegant and smart, easier to adjust. Makes me realize I could also one day add custom fade-out times for each fader if I wanted to, but that’s a project for a different day:)
E) Well, you’ve really gone above and beyond here throughout this process. I appreciate it tremendously, I’ve learned a huge amount about how GPScript works, and I hope this thread will be helpful to others on the forum as well. Cheers, and THANK YOU.
Seems as it’s working now as expected… great! 
Probably it’s redundant right now, same as the Running[Ai] boolean… if i see right, there is nowhere a test for the “running state” left, it’s just beeing changed from true to false and back, but no one seems to care anymore. These are things you’d just have to check… remove it, if it still works, then great… again some lines less. 
No problem, it’s your rackspace, you can do whatever you want. 
That’s great!
In fact i am learning too when i try to understand and maybe optimize other peoples stuff.
That’s the main purpose of a forum like this. 
Well… you’re welcome. 
Some people can be happy that don’t have to do this for a living, but only do it for fun… sometimes they had to pay a high bill for my services. 
…but luckily i earn my money with honest work! 
2 Likes
are you suggesting that giving advice here is dishonest work??? 
I would never dare… 
EDIT:
It’s not work, it’s a pleasure! 
2 Likes
…and so much appreciated!
1 Like