OK, did some testing with this - looks very good! It seems that during the setup of a song, Cantabile will will actively refresh the bound plugin parameters, so re-sending bound values isn’t necessary.
I created a binding from Smoothie’s output value to the rack’s MIDI output, and it did send the correct MIDI output value at the start of the song without any change to the input parameter, so that’s good - no unpredictable starting of songs…
Actually, Cantabile seems to refresh the current value of the output a couple of times on loading - I’m getting six MIDI messages with the same value when loading a song (without any Song-OnLoad initialization binding). Doesn’t hurt for this use case, but may be interesting for @brad…
I used Cantabile’s binding mechanism of converting the output value to MIDI instead of using Smoothie’s built-in MIDI output, in order to be sure that Cantabile would actually read and output the current Smoothie output value without the input parameter changing. I guess Smoothie wouldn’t output any MIDI if the input doesn’t change, so using Cantabile bindings seems to be the better choice to make sure initialization of my song works.
Here is the latest version of my Smoothie rack for anyone who’d like to try it: Smoothie 1.zip (3.3 KB)
I guess Smoothie wouldn’t output any MIDI if the input doesn’t change
Correct – VST3 plugins only receive parameter change info from the host, so SmoothieVST can’t initiate any CC outputs until a parameter actually changes. (It doesn’t have any visibility into song or rack states/loads, etc., which are the province of the host.)
I wonder how much it would take to convince @brad to build Smoothie-like behaviour into Cantabile, so a plugin wasn’t needed. So values modified by state changes, such as faders, can have a rate of change parameter. I wonder if this would fit cleanly into Cantabile’s architecture?
Yes - one of the highest priorities on my Cantabile wishlist - @brad has hinted that the new bindings architecture may enable something like this in the future…
I nearly mentioned something about this in one of my previous replies here, but decided not to because I didn’t want to prematurely get people’s hopes up. It’s definitely high on my list and might tackle it after this next batch of smaller changes.
The discussion here has inspired me to share some of my other creations with the community. Maybe some of these are also worthy of feature addition consideration if they prove popular.
I made some improvements to the Smoothie rack. It still works the same. The changes were on the limit switches and better instruction comments in the rack. Here is the update. Note you need to have the Smoothie VST3 installed for it to work.
Hi Dave (and Hamlen). I’ve finally gotten around to testing this out as I’m re-configuring my Cantabile sets after nearly 7 years of flawless performance (so thanks Brad too). Just having a little “moment” in trying to get the “speed” of the fades saved against each song using your SMOOTHIE rack.
I am using a substantially reduced version of the rack as I only really need a One-shot fade out and a Reset so pretty much just using OUTPUT 1 for your rack with some reconfiguring of CCs etc. However even though I can see the Output Gain of OUTPUT1 (being used for Speed of fades) State Behaviour is stored with Gain Level in both State and Exported, anytime I switched song I noticed it always returned to the “default” setting.
After some investigation (admittedly by someone who struggles with all the terminology and features of states and bindings etc) I think its due to the Song On-Load->Re-send Bound Values which is in turn resetting the Reset Speed Binding on every Song Load. The only test was by turning this Reset Speed off which definitely did the trick but I’m not sure if I’m missing something in the way you configured the rack to store the speed of the fades. I have it working but just thought I’d ask the question.
Thanks for spotting that. It’s definitely a conflict and a mistake. I will have to investigate it and see what’s up. The speed and other bindings are set up to save the value to the song file and restore it when the song is next loaded and it was working at a point a while back. FWIW what version are you using? Thanks again for the heads up.
Hi Dave… I’m pretty sure is was SMOOTHIE Rack Version 3. I did make some customisations, probably all unnecessary to be honest; just reducing the amount of racks (OUTPUT 2 - 8 I removed along with the “Stack” state and corresponding Stack Bindings just as I didn’t really understand these) as I knew I only needed one so made it easier to navigate). All the other settings like the assigned target and “type” (e.g. Slider, Switch, One-Shot) all saved with the songs, only the speed that seemed to reset on song switch/load. Its a great rack you’ve created (really easy to use) using a great VST… Thank you!!!
I figured out my error. I had it all working well but added a mechanism to reset the speed on each output rack using it’s Enable/Disable button and it was conflicting with other things I had built and resetting the saved setting from the song file right after the rack would load. I retooled the rack so that there is a single reset button for all the speeds at the top of the list above the output racks inside the Smoothie rack. I had been having similar surprises in my rig and am very thankful you pointed this out. I am posting the new corrected version. Go ahead and remove whatever you did before, it should not matter. Let me know if it works now.
Hi Dave… Well I’m not entirely sure what you did but what I can tell you is it works like a dream! I don’t think I’ll bother with any of my customisations other than maybe switching the CC’s where needed to match my spare controller buttons. You sir are an absolute diamond! thank you!!!
