Automation not working in Studio One 3


#1

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?


Missing Parameters In Logic X Automation Menu
#2

Arg. Studio One 3 won’t automate parameters in AU plugins if generateAUParameterIDForIndex() returns a value greater than 0x7FFF. Any way to work around this without busting everybody’s plugins?

Example of parameter IDs that don’t work for me: “resolution” and “downsample”


#3

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.


When the JUCE team introduces breaking bugs in plug-ins
#4

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


#5

The boundary is actually at 0x7FFFFFFF, and it is indeed a problem with a mismatch of a uint and an int.

The AudioUnit spec allows unsigned 32bit integers so I suspect it’s a problem on Studio One’s side. This doesn’t help us very much though.


#6

@fabian, @t0m

while you’re at it, you might also revisit this issue:

I haven’t reproduced it with the latest versions of FCPX and JUCE though.


#7

I think the changes I made will have fixed this issue too.


Automation issue in Final Cut Pro X
#8

Great to hear!

I’ll add a note to that thread once I have verified it.


#9

I haven’t released my plugin yet, so an extra define would work for me. I don’t want to add it myself however, and be stuck using a custom version of juce forever.


#10

Does anybody have a developer contact at Presonus?


#11

I’ve contacted a developer at Presonus. In the meantime there is a fix for this on the develop branch.


#12

I think you have a typo in your VST3 version. You calculate paramHash but down’t use it for anything.


#13

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.


#14

@G-Mon Thanks this is now fixed.

@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.


New config flag in JUCE 4.3.1 is ON by default
#15

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?


#16

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 [1], for anything else you should be using the FAILED macro [2] 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 :slight_smile: - so there is some confusion on what is right here.

[1] This is not strictly allowed by .COM but many variants of .COM use this
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms693474(v=vs.85).aspx


#17

Does anyone have the information, if this is fixed now in Studio One 3?


#18

The presonus team have been working on a fix and plan to release it later this year. In the meantime, for new plug-ins, you’ll need to use JUCE_USE_STUDIO_ONE_COMPATIBLE_PARAMETERS=1


#19

FYI, the release notes to the latest version of Studio One 3 (3.3.4, released February 21, 2017) seems to mention that they have fixed this:

[macOS] AU automation broken for large param IDs

I haven’t checked myself though, because I don’t have any plug-in that had problematic param ids.