Well this is a kick in the nuts: VST2 plug-ins

[syntonica]

I don't think that there's any way I could truly separate my GUIs from my DSP. I have 32 values that can be updated per sample, all at the same time. There are up to 70+ GUI widgets that all need to be updated in real-time, but at 60fps, any lag or shearing is not noticeable.

That said, while I read values directly from the DSP thread, any changes to values done by the user in the GUI are sent to the DSP thread to update, so I do keep them separate for all practical purposes. However, there's no need for a host to play man-in-the-middle. I would hope the host had better things to do with its time.

[mr.ardour]

I don't think that there's any way I could truly separate my GUIs from my DSP. I have 32 values that can be updated per sample, all at the same time. There are up to 70+ GUI widgets that all need to be updated in real-time, but at 60fps, any lag or shearing is not noticeable.

You don't control the refresh rate. If you try to draw that fast on a stock macOS system, the host application will be throttled by Quartz.

We've seen issues with this in plugins from several companies that for some reason think that they should decide the refresh rate for their GUI windows. This might have worked on older versions of macOS, but at some point Apple said no more. Try to draw too fast, get throttled.

Lag/shearing is not visible because Quartz drawing is fully double buffered. It has nothing to do with your refresh rate. You can draw at 5fps on Quartz, and nothing will ever shear.

However, there's no need for a host to play man-in-the-middle. I would hope the host had better things to do with its time.

You should come and work on a host sometime

[syntonica]

You don't control the refresh rate. If you try to draw that fast on a stock macOS system, the host application will be throttled by Quartz.

Actually, I do! It's set on a timer for 60fps with some room for dropped frames, down to 30fps, IIRC. The timer calls a method to mark the rect as dirty. I don't actually call the draw method directly, which is probably what those other naughty coders are doing! Animations (waveforms, knob automations) run very smoothly and look better than when I set the frame rate to 30fps, where I do notice some artifacting.

(When I spoke of shearing, I meant due to values changing rather than incomplete frames. I probably should have chosen a different word, but that's what came to mind. Maybe stuttering?)

[mystran]

We've seen issues with this in plugins from several companies that for some reason think that they should decide the refresh rate for their GUI windows. This might have worked on older versions of macOS, but at some point Apple said no more. Try to draw too fast, get throttled.

Are you sure it's throttling and not something like VSync causing issues? The reason I'm asking is that even on Windows if multiple plugins try to VSync their windows while sharing a GUI thread, they basically end up taking turns and the GUI performance goes down the drain. At least on some systems (eg. mine) this used to be broken in earlier macOS version (eg. at least OpenGL swapInterval would always be treated as 0), but seems to work fine with Big Sur.

I just tried messing with some game code of mine and if I skip the internal rate-limiting I can definitely still draw as fast as the poor integrated GPU can handle, but enabling swapInterval drops me to 30fps. I'm not sure why this is 30 instead of 60, but I'm not in the mood to investigate right now whether it's the system or something in the game code.

[S0lo]

OK, fair point. But most people in this thread are against this separation, because in VST2 they used the same float storage for their DSP and their UI. What is really, really bad design. VST2 also does not enforce to code this way, but people did it anyway.

Thats called shared data access management among threads. (shared data doesn't necessarily mean shared variables). This has been covered and talked about to death for decades in tens of books and tutorials. You don't need GUI/DSP separation for that!!. Otherwise, all other none audio apps would also need separation too if they have multiple threads accessing shared data.

There are genuine reasons why some here don't think that separation should be the "default" or "recommended" option. Just read a few pages earlier if you haven't.

So far in this thread, the only reason that makes sense to me to have separation is true real hardware separation of GUI and DSP. Yes, that is useful. May be there are a few other reasons, but these definitely don't even make more than 10% of what the plugin market typically needs.

[mr.ardour]

You don't control the refresh rate. If you try to draw that fast on a stock macOS system, the host application will be throttled by Quartz.

Actually, I do! It's set on a timer for 60fps with some room for dropped frames, down to 30fps, IIRC. The timer calls a method to mark the rect as dirty. I don't actually call the draw method directly, which is probably what those other naughty coders are doing!

Yes, this may not trigger throttling, since marking a rect dirty isn't the same as drawing. But have you actually measured how often your render code is actually called? I haven't checked on this for many versions of macOS, but at some point, Quartz would never actually render more than about 30-40fps no matter what you did. Apple may have changed that.

[hibrasil]

Seems a bit OT, but many plug-ins are using OpenGL, Metal etc CALayer -backed views where NSView's drawRect is not called. Even Skia software mode in iPlug2 gets 60 FPS which does use drawRect. This seems to work in ardour too. On mac 60 FPS is possible with an NSTimer or CVDisplayLink (VSYNC ) but on Windows we had to use VSYNC in order to get a decent timer > 40 FPS.

[syntonica]

Yes, this may not trigger throttling, since marking a rect dirty isn't the same as drawing. But have you actually measured how often your render code is actually called? I haven't checked on this for many versions of macOS, but at some point, Quartz would never actually render more than about 30-40fps no matter what you did. Apple may have changed that.

I haven't measured the actual frame rate I'm getting, but 60fps is more an ideal than a necessary goal. I just know that setting the timer to 60-hz gives me a very acceptable result, where as 30-hz starts to look a little shaggy. The funny thing is, the CPU hit from 30->60 is negligible, maybes .5% out of 5% CPU used. Because it's so minor, I never bothered to explore timings between the two values.

The only use case I've heard for complete separation of GUI and DSP so far is using a render farm on a different CPU with its own private RAM. In this case, there probably should be a separate mechanism (optional extension) to perform the communication. However, with RAM speeds lagging behind, but RAM availability still growing, this is becoming a less and less desirable option. I'm surprised the UADs and the Kymas of the world still seem to be holding on except by sheer stubbornness.

[mr.ardour]

The only use case I've heard for complete separation of GUI and DSP so far is using a render farm

render farms are typically not going to need the plugin GUI, so even this is not a particularly "real" use case. Hosts can trivially build a lightweight UI for the plugin if for some reason graphical control of parameters are required.

the main practical argument for the separation is that both the host and the GUI are capable of reading and writing the plugin parameters, and that better design generally arises when there is only way to do this. allowing the GUI "priviledged" access to the DSP but not the host creates two pathways for read/write access to parameters, and this kind of asymmetry is generally not a positive.

in addition, another argument is that the host (and/or user) may not even want to use the provided GUI, and that in some cases even just loading the DSO/DLL blob corresponding to the GUI is a waste of time and resources. This is only about code/object level separation though, not the runtime relationship between the GUI/DSP.

[mystran]

[...] on Windows we had to use VSYNC in order to get a decent timer > 40 FPS.

And just in case people read this and proceed to set OpenGL swapInterval to 1: please don't.

If you really want to VSync, then do it like IPlug2 and use a separate thread for the waiting.

[syntonica]

render farms are typically not going to need the plugin GUI, so even this is not a particularly "real" use case. Hosts can trivially build a lightweight UI for the plugin if for some reason graphical control of parameters are required.

It may be trivial, but it is useful? I have ~75 parameters and when viewed in the host-built GUI, they have no rhyme or reason and are not logically grouped, like in its own GUI. As well, the waveforms are not displayed and arguably, this is one of the more important features in sound design. My DSP and GUI are inextricably bound together in this regard. As I stated before, I need "privileged" access, one direction or the other. I just find it easier to reach into the DSP side for the values I need rather than unnecessarily pushing them to the GUI. The GUI updates every 735 samples (44.1khz) and the frame buffer can be anywhere from 1 to 1024 samples, or more, so usually runs at a faster rate. I only need to pass back user changes from the GUI, but I do this by calling the proper method and not just plugging new values into my tables. It would be great if both sides had equal r/w access to the data, but due to architectural issues, bad things, man! Really bad things!

[mr.ardour]

Your understanding of the term "render farm" seems to differ from my own, which is fine.

[syntonica]

Your understanding of the term "render farm" seems to differ from my own, which is fine.

Sorry. I seem to be suffering from nominal aphasia lately. I just mean any special-purpose CPU/GPU dedicated to handling the DSP functions. Basically, hand it a job, get the results back, whether offline or real-time.

[abique]

Hi,

Excuse me, I did not read the past messages (too many, not enough time), but I've heard about the GUI running in a different process.

I think it is a good idea to run the plugin GUI in a separated process, yet I don't think that it is necessary and a good idea to involve the host.

The plugin can take care itself of starting the GUI process and communicate with it. And if it does not rely on the host, it means that:
- it will work consistently across hosts
- it will work consistently across plugin API

I know that it is not an easy thing to write such code, but it is not rocket science either. A plugin interface is not a library.

The best approach in my opinion is to have a helper library to achieve it. You'll have full access to shared memory, and the full range of IPC which means optimal performances for the task.

If I am correct, https://www.audioblast.me/product/acidbox/ does it on Linux.

[milkmiruku]

The worth of relatively obscure .ttl syntax is that it can be used to describe a graph. On generating Turtle; see https://github.com/DISTRHO/DPF/tree/mas ... -generator and https://github.com/zynaddsubfx/zynaddsu ... abeb9d2c40

Ingen has an extension to save projects with, as new LV2 plugins (), and this is also used by MOD Devices for their Pedalboards (that amazing live demo again, few users at a time only)

I.e. part of what both the syntax and UI and DSP separation allows is not just a modular but semi-modular nature; as presets are just plugins that relate theirself to the uri of the original plugin, whole plugin graphs can be plugins also

Also, here are grouped parameters in a generic host UI; https://kx.studio/screenshots/news/carla-2.1_params.png

P.S. I'd link to lv2kit but it's not ready yet