Alternatives to blocking process()?

I have a hack (I mean extremely smart technique) that I use in a few modules.

If I have something I don’t want to run on the audio thread, like malloc, or file I/O or a computation that runs 10 ms. then I run it on the UI thread. I do this by overriding widget::step().

If headless mode means there is no widget instantiated, does that mean this trick won’t work in V2?

1 Like

Why not use a worker thread?

well, that would be the “proper” way to do it, and that’s what I do in “colors” where the long running FFTs would probably make the UI stutter.

Why not, you ask? It’s one line of code to use the ui thread, and it’s a lot of code to spin up a thread, shut it down reliably. etc. Admittedly I now have this code and have tested the crap out of it…

So I say why use a complex method if there is a simple one that works just as well?

1 Like

You shouldn’t allocate memory or do I/O in MyModule::process(), but why would you need to? Suppose you have a method MyModule::loadSample() that blocks an arbitrary amount of time >10ms. You can call this from

  • MyModule::MyModule() if you need to load a default sample when your module is instantiated.
  • MyModule::onReset() if you want to load the default sample when your module is reset.
  • MyModule::dataFromJson() when Rack loads a patch or module preset.
  • something like MyModuleMenuItem::onAction() if you have a context menu item that allows the user to load samples.

Some of these block the engine thread, some don’t. But in all cases, the user is doing some “load” action and would excuse an interruption of audio. You could use a worker thread to avoid all audio interruptions, but if you don’t want to bother, nobody will complain.

Let’s try this again. Over the years, various programming problems have come up in my modules. I decided to solve them by doing work on the UI thread. These plugins will have serious bugs / not work if their widget is not getting called every frame (or so).

So the question is - will these existing plugins need to be changed for V2? Clearly there are many solutions to this problem, but of course the cheapest solution would be “do nothing, it will still work”.

If your code requires the UI in order to work, and you don’t have a UI with headless mode, obviously your code won’t work.

Cool, tx. Was just looking for confirmation about what “no UI” meant. It doesn’t have to mean “no API for running on the main thread at all”. But, yes, that was the most obvious interpretation. Thanks for clearing it up for me.

Who are you quoting?

Probably no one. Sorry about that.