Little sluggishness in UI objects when automating with param

[alfonso73]

Hi, here's a patch with a simple slider controlled by a param in PlugData VST3. If you use the param slider (or the relative automation coming from the host) you can see that the slider movement is kind of sluggish. Can some Juce things be improved? Is there some interference between audio and UI threads? Given that some glitch are audible when PlugData UI is open and not when is closed i guess that some audio/GUI interference is present. And this brings me to another question. How to actually record automation using the actual UI (and not the param slider)? Camomile has a mechanism to do this. (See its examples...the organ patch shows it very well) Would be a great addition to PlugData. PlugData_0.52_param_test.pd.zip

[timothyschoen]

Oh I'll definitely add an option to send automation as well!

How would you rate the sluggishness in the standalone? For me, it's much better. I use an entirely different mechanism there, it just reads/writes instantly from a list of thread-safe floats, I wonder if that works better for you as well. I'll look into why the performance is so much worse in the plugin.

[alfonso73]

Here's a video showing a comparison between PlugData 0.52, Camomile and Arturia CS80. The video shows the issue #100 to ;-) I'd say that is a little more sluggish. But the sluggishness probably shows some problem in UI refresh that probably can be investigated. When automation sent from PlugData will be implemented i guess the issue will be more crucial. BTW i did automation using a MIDI controller. Here's video link https://streamable.com/0hvahy

[timothyschoen]

Ah that makes it clear, I'll see what I can do.

[timothyschoen]

I now remember that I'm updating automation once per DAW audio block. It would be better to do it every pure-data block (64 samples), that way the distance is also more consistent if you change your daw settings.

[timothyschoen]

I've implemented the faster update rate, code looks almost the same as Camomile now, except Camomile constantly sends the parameter messages, I only send them when the parameter changes. I'm curious to hear what the performance is like for you now!

Btw, don't test this in Debug mode, it will always be slower. I don't know if you're building from source, but if you are, make sure you run the cmake command with: -DCMAKE_BUILD_TYPE=Release

Or download the latest version from the actions tab!

[alfonso73]

Great. No i'm not building by myself. I'll have to learn because i'll like to try to add some other externals to the VST3 version (i.e CEAMMC beacuse there are some stuff that ELSE does not have and maybe some externals by myself).

[timothyschoen]

@mathiasbredholt has a nice example of including extra libraries in this commit:

https://github.com/mathiasbredholt/PlugData/commit/0b8d7fed97cf3820e000b9eba7596b9972106b52

Instead of nicely putting it in the cmakelists like he did, you can also just jam it behind ELSE (in Libraries/cmakelists.txt):

That might be simpler if you have no prior cmake experience.

Then the shittiest part is adding init functions for every object to Libraries/libpd/x_libpd_multi.c

It's not really a smooth workflow at the moment, and for ceammc I struggled to find the actual source code for just the library.

[mathiasbredholt]

@timothyschoen yeah adding the init functions is quite the pain, would be nice to automate that process somehow :)

[alfonso73]

and for ceammc I struggled to find the actual source code for just the library.

Yep it's quite a complex library. Basically what's really interesting is the aubio lib transient recognition/ audio analysis toolkit. FFTease would be great too for FFT stuff. But we will see....

[timothyschoen]

Sending automation will be added soon, it will work like this:

[alfonso73]

@timothyschoen great! thanks

[alfonso73]

@timothyschoen watch out for some feedback issues when having boh [r param1] and [s param1] working together.....

[timothyschoen]

[s param1] doesn't actually set the parameter to the DAW, but the point about feedback loops is also valid for [s param]. I'll see if I can protect the user against this, but for now, don't create feedback loops.

[alfonso73]

mhhh...i'll send you a video of what's happening....but 'till monay probably i'll be very busy ....monday for sure!

[timothyschoen]

No problem, I'm giving a presentation soon for which I'm going to create a (hopefully more stable) release, so I won't be able to fix it before then. I'll fit it after that though!

[alfonso73]

Hi @timothyschoen here's a video with an automation related test run with PlugData and Camomile.

https://streamable.com/9akhkj

It shows at least three areas of insterest that probably will deserve some design decision.

1. Parameter receiving and sending to and from host. As you can see there's some kind of feedback issue...look (video time code 09:05 and later ) at the periodic automation points generated while automating PlugData and the "spring-like" behavior of the parameter returning back at a fixed value.

2. A way to enter precise values (look at Camomile AlmondOrgan and the way number boxes are used)

3. Parameter mapping. I think that parameters scaling (and probably even smoothing and log/exp curve coeeficients) should be a "parameter window" affaire (as in Camomile .txt file)

Thanks again for your great work and all the best for your presentation!

[timothyschoen]

Thanks, I'll check out your video's soon!

[timothyschoen]

The video made it much clearer! Turns out I made a mistake with sending the parameter change begin and end messages. I'm still unsure how to fix the focus issue, but I'll see if I can reproduce it on Windows tomorrow.

I agree that scaling and range should be handled in the parameter window eventually. I won't get to that this release, but definitely before the next one! I was going to do some rewriting for the automation panel anyways, because it's pretty slow right now.

If this bug is fixed you should be able to set precise values by hooking up a nbx or floatatom to the [s param] right? You can also do it by clicking the number in the automation panel, but it's not very nice yet. I'll make that better soon!

It seems to work fine now:

https://user-images.githubusercontent.com/44585538/170804532-8f1720ec-6067-4b75-a6e0-d39df063fdc1.mov

[alfonso73]

still some strange "spring" behavior in automation "Touch mode" in Reaper.

https://streamable.com/fuew55

If you look at the video sometimes the actual Reaper automation knob in the track panel top left goes out of automation recording sometimes and that's exactly when the curve return to its pre-touch value

[alfonso73]

Hi @timothyschoen! Still some strange things happens when automating parameters in "Touch" mode in Reaper....

[timothyschoen]

Hi! I'm aware of it, I'm a bit confused because my code is very similar to Camomile, yet it behaves differently. It's also very annoying to have to restart the DAW every time I want to test a change, so I postponed this a little bit. I'll make sure it's fixed before next release though! I'll let you know when there's any progress!

[alfonso73]

Thanks @timothyschoen !

[timothyschoen]

I've come up with kind-of a solution. The problem is that reading and writing simultaneously is causing issues. So I just created a new subpatcher for PlugData, [param] that will allow both input and output, but makes sure there's only one happening at a time. This can be done (surprisingly reliably!) with a simple timed gate. All it does it make sure that there's no feedback between the send/receive.

This also makes it easier to figure out how to send/receive parameters!

The update will probably be up tomorrow, I'll let you know so you can test once more to see if it's finally solved now.

[alfonso73]

Great! If a lot of parameters are involved could it be a little heavy on CPU? i remember of Pierre's solution for Camomile... https://github.com/pierreguillot/Camomile/issues/121#issuecomment-404784189

[timothyschoen]

The difference between Camomile and PlugData is that in Camomile, there is a limited number of parameters that you set yourself. This works because it has to be set up correctly for only one plugin. Because there are only a few parameters, it can constantly update the parameters, with a constant stream of messages. This is reliable but indeed, a bit heavy for the CPU.

Since PlugData needs to have 512 parameters, this strategy won't work. I only send the parameter whenever it changes, which is faster, but a bit harder to get right. At the same time, I think that it's maybe better when implemented correctly? Most plugins don't constantly output automation if you're not touching any knobs after all!

[timothyschoen]

It's still not great :(

Everything I was planning to do before v0.6 is done, so I guess this one is gonna get postponed even more... The good news is that as long as you don't read and write simultaneously (things like touch mode) it should be okay.

[timothyschoen]

Looks like it's working now! I've added a manual "change" mode, similar to what Camomile has. That helps a lot. I've found that automation feels more responsive in general now, and it also behaves normally in touch/write mode. New version will be up later today!

[timothyschoen]

2. A way to enter precise values (look at Camomile AlmondOrgan and the way number boxes are used)

3. Parameter mapping.
   I think that parameters scaling (and probably even smoothing and log/exp curve coeeficients) should be a "parameter window" affaire (as in Camomile .txt file)

Entering precise values should be possible, by clicking on the number in the automation panel.

I was a long way into implementing range for the automation panel, but I then realised that it is impossible to do this. The DAW needs to know the range of the parameter at startup, there's no way around that :(

So I guess that since I already have a [param] object, I'll just allow sending messages into that for setting the range.

[alfonso73]

2. A way to enter precise values (look at Camomile AlmondOrgan and the way number boxes are used)

3. Parameter mapping.
   I think that parameters scaling (and probably even smoothing and log/exp curve coeeficients) should be a "parameter window" affaire (as in Camomile .txt file)

Entering precise values should be possible, by clicking on the number in the automation panel.

I guess that an abstraction example with a num box and a slider being associated to the same automation parameter would be great. It's quite difficult to set a precise value in the 0.0 - 1.0 range of the parameter as seen by the DAW host. It's better to specify values in the actual patch with numbers and values that are meaningful for the actual patch.

[timothyschoen]

I've added a whole new parameter system that allows you to create named parameters, with a custom range.

If you could try a recent build to see if parameters are less sluggish now, that would be nice! You'll have to delete plugdata's internal folder when you update to make sure the new [param] abstraction gets unpacked.

Because if this update doesn't work, I can also start using Camomile's method of outputting parameter values in a constant stream. This would be more okay now that we can set up a custom number of parameters.