Steppy automation recording on OSX

I have a problem which i have also seen on other juce plug-ins on the market.
When i record automation it results in a steppy signal, as if the message que is waiting too long to send the messages.
I tried tracking my parameter changes, and found out they are all being sent on time to logic (i-e, sendAUEvent() is being called on time.

Since my project has over 100 parameters, i have also noticed this automation lag increases as the parameter index goes up.

I tried to see if this is an issue with Logic - and tested other plug-ins. All the juce plug-ins i tested showed this behavior while other non juce plug-ins worked flawlessly generating smooth accurate automation recordings.
i also tried to run in release mode
Does anyone have a clue on the matter?

Jules and I just tried this in Logic and it looks fine to us. Exactly how does this manifest itself.

This could be down to your UI drawing; perhaps your drawing is inherently expensive or you are over-repainting. Try recording the automation from the generic editor in View: Editor > Controls?

If that improves it then it’s probably the drawing.

I’ve had this before and had success with using the OpenGL renderer, but that’s not always an option. Somehow optimising repainting should help if this is the issue.

Have you checked out Jules’ summit talk? (Last bullet point in Part 1):

1 Like

We tested it with the GenericAudioProcessorEditor

Do you have kAudioUnitParameterFlag_IsHighResolution set? Not doing so can result in very “steppy” automation.

See Fix for quantization of automation data by Logic

Support for doing this via macro JucePlugin_AUHighResolutionParameters was added in commit [6c662a7]

1 Like

@fabian - i think this video should give you a good idea:
https://www.youtube.com/watch?v=JNNkSo6lvRA

@martinrobinson-2 - the editor->controls works well obviously. However my drawing functions are at the moment very very simple(prototype phase), and even when i remove the automation timer, and get the minimum amount of paint calls, the automation recording does not improve. The automation playback is flawless. I also find it very strange that the higher the control index the more lag i get. Thank you so much for the link i will be watching this now.

@frankfilipanits - yes i have visited that post, and even though this is related to level quantization, and my problem is related to time “quantization” (well not really quantization in this case but you get the idea), i still enabled it because i find it useful. It does not solve the issue though.

Actually, if you look at the post you have mentioned, it seems that @chkn has the same problem as me from the looks of the image he posted, and from the 3-4 juce based plug-ins i have tested, they all suffer from the same issue. it is especially apparent when you compare to NI stuff, or logic’s internal plug-ins…

1 Like

perhaps i should add, that on plug-ins with few parameters, this is harder to see. automation seems to work well - but ni and logic still create more detailed automation recordings

give us some numbers: what is a reasonable amount of automated parameters that you see it is triggering the issue? 10? 100? 1000?

The Juce guys have tested it and saw no such effects, perhaps because they weren’t using an automation index high enough?

We were using 20 parameters.

From the video it doesn’t look like drawing is the issue as the dial movement is smooth. Is your begin/end gesture logic all correct?

@yfede my synth has just over 100 parameters, but it is very noticeable even at controller 30+. Were the juce guys able to recreate the issue with serum for instance? because if it works on their computer and not on mine then this could be the issue. however i am worried that if it happens on my computer it will happen on other’s as well. and the fact that other makes create a much nicer automation recording. It is still noticable at 20 if you a/b test against other makes.

@martinrobinson-2 I am sending the begin/end gestures correctly, and although it does not seem like a redraw issue, it does feel like a message thread inside logic is being blocked. i also tried to send begin and end gestures with every drag movement but the result is worse, which is also an indication of a thread being blocked.

I will be investigating more and let you know my findings…

Allright - a few findings:

  1. I think this has to do with the mouse thread or timer. I often use a software called “sharemouse” to share the mouse between my PC and Mac. When i use the software (ie control the osx mouse via my pc over lan) the automation behaves as expected (although not as nice as NI’s but its at least acceptable). but when i switch over to using the mouse directly on my mac - it gets steppy again and updates mostly when i stop the mouse.

  2. this doesn’t have much to do with parameter index after all, i have tried changing the order of my controls and the lag keeps following them around, thing is - i am still not sure why there is such a difference between the controls, all that is different between them is the paint function, and the laggy controls stay laggy even when i comment out the paint function. but this remains to be seen since i can still run more tests on this phenomena.

  3. just for anyone bumping into this thread looking for answers, settng isMetaParameter() to true, worsens this lag. so does calling begin and end gestures for every move. these should be obvious, but it could be an issue if overlooked.

one more update:
I found out the reason why some controls worked better than others. Controls that are quantized into steps naturally produce less value changes, and this load the thread less.
Obviously quantizing some controls is a good idea, but it still isnt a solution to the problem.
So this has nothing to do with the index of the control as ive mentioned earlier.
The strange thing is that all of the au calls in and out of the plug-in seem to occur on time, but then logic would write all the automation’s buffer only when that thread became unlocked, all at the same time-stamp.
drawing looks fine, sound is fine, only automation writing suffers.
This is driving me nuts :sob:

Here is a video of the juce demo plug-in doing the same thing…

https://www.youtube.com/watch?v=3fUftKmqsGA

I am using OSX 10.11.4 With logic 10.2.4, on a macbook pro mid2010 with 8gb ram and an ssd hd. its not even sweating when i turn the knobs.
i wonder how massive does it so smoothly.
will soon check out more daws to see the situation.

If this happens to me, it is probably happening to more.

1 Like

Ouch! You’re absolutely right. Though nothing to do with the parameters as such. It seems commenting out the line (line 129 in PluginEditor.cpp) where it updates the play head time, gets rid of the problem. I’ll investigate this more on Monday. This is why I didn’t see this in my 60 parameter test plug-in.

1 Like

@fabian
Thank you for taking a look.
getting rid of the timer function does not fix the problem for me. i have commented line 129 (as i have tried to do with my own plug-in) and the result is the same.
this is the line i commented just to make sure were talking about the same issue:
//updateTimecodeDisplay (getProcessor().lastPosInfo);

the only way i can get a semi-decent automation recording out of these controls is to share my mouse over lan. I tried changing mice to see if its an issue with a specific mouse driver, but it happens to all mice connected to the USB port. It also happens with the trackpad.

Have you tried this with the juce demo plugin. If yes, then this would mean it’s machine dependant :frowning:

Yes i have,
There is nothing special about my machine, its a mac after all. but i will reinstall my system from scratch and will let you know if that was it.

Please don’t waste your time doing that! Fabian didn’t mean that there was something broken in your OS! He just meant that this must be something else going on that’s non-obvious, and we’d need to find out what’s different in the way you’re using it so we can reproduce it.

2 Likes

I experienced the same behavior

1 Like