Has anybody encountered an issue where Studio One 3 won’t play automation for some parameters? I’m not getting any calls into my plugin to set the parameter value. This is only for the AU version of the plugin, VST is fine.
Some of my plugins, all parameters work fine, others some or none work. Anybody run into this before?
Yes @t0m noticed this a few days back. We can fix this in JUCE but then all automation data of currently available JUCE plug-ins would become invalid if plug-in vendors update their JUCE version.
We would probably need to introduce yet another preprocessor define to force JUCE to use the current param IDs and - in absence of this define (for new projects) - only use values which are lower than 0x7fff. Just dumb that we already have a preprocessor define which does something very similar JUCE_USE_FORCE_LEGACY_PARAM_IDS.
To be honest this seems like a Studio One bug to me.
perhaps this time the macro could be JUCE_USE_SIGNED_PARAM_IDS, the fact that it rejects param ids higher than 0x7FFF, looks to me like a problem of rejection of all those that would be negative if interpreted as signed 16-bit int
I just saw the fix on the develop branch and I’m sorry to say I think this is a bad idea. Breaking automation for all hosts just to work around a bug in one host is not reasonable. If I read correctly, this change will be applied automagically unless the developer sees it and chooses to disable it. This bug really should be fixed by the host developer and if you need to make a workaround, please restrict the fix to the faulty host only.
Or admit it was a bad idea to use negative parameter indexes in the first place and name the fix and the ProJucer change better.
just my 2 c
P.S.: I also quite dislike having host-specific fixes show up in ProJucer like that. There are quite a few of those in Juce, but they don’t show up as settings and are only applied to specific hosts.
@pflugshaupt I share your pain. I know this is not optimal but it’s hard to come up with anything better. Here’s the problem, if I only enable the fix when the developer explicitly enables it, then experience tells me that no-one will enable it - and even new plug-ins in the future will still be reporting negative parameter ids. This means that there will never be a good time to enable it by default and now is as good as any.
I believe that most plug-in vendors are more likely to test the saving and loading of automation data, than to test a specific DAW (in this case Studio One). Therefore, plug-in vendors who are updating their plug-ins to newer JUCE versions are unlikely to release a plug-in with the workaround enabled anyway. A quick forum search for them will inform them that they need to disable the workaround.
Additionally, many plug-in vendors who already released plug-ins with older JUCE versions will be using the legacy parameter ids anyway. The Studio One problem does not exist for legacy parameter ids, so I think the studio one workaround will not affect that many developers.
You are right that this is a Studio One problem. However, even if they fix it, it will take a while until it’s integrated into a proper release and even then, many customers will be using old versions of Studio One (check the JUCE forum on how many bug reports we have for Ableton Live 8).
BTW: I’ve been trying to contact Presonus for months now (support, direct e-mail, linkedin, …) and I can’t get hold of anyone. If anybody has a contact at Presonus (or works at Presonus), please, kindly ask them to contact me!!
Update: Pesonus team have contacted me and will fix this issue in an upcoming release.
Ok… but why don’t you patch only if the host is studio one? I don’t understand why automation in all hosts needs to break because of this fix. Are you worried other hosts might also have issues with negative numbers?
Well the reason is that it is a bit debatable if this is in fact a Studio One bug - at least for VST3 (the same bug occurs for VST 3 plug-ins). VST3 uses a mostly .COM compatible plug-in interface (see the COM_COMPATIBLE define in VST3) and there are methods in VST3 that return a ParamID (for example IParamValueQueue::getParameterId). However, in .COM, every method’s return value must somehow be able to indicate failure: for pointers, failure is indicated by a null ptr , for anything else you should be using the FAILED macro  which simply tests if the return-value is negative, i.e. tests if the most significant bit is set. Therefore, according to .COM, negative parameter ids would not be valid parameter ids.
On the other hand ParamID is defined as a uint32 indicating that the full range can be used. So it’s a bit unclear if a parameter id with a set signed bit is a valid parameter id. I’d tend to argue that this should be ok as the docs do not mention the sign bit anywhere in VST3 docs. But in any case, I think it is best to avoid negative parameter ids as some DAW developers clearly don’t agree - so there is some confusion on what is right here.