I can't tell if this is a QLab 5.4.4 or a plugdata 1.9.0 issue. I create an audio cue in QLab, and then add plugdata to its audio FX. In the FX edit window, I load a patch into plugdata and a yellow circle appears to the left of the audio cue, indicating that the cue is loaded and ready to be triggered. If I run the cue at this point, I hear my patch altering the audio of that cue. But if I ever hit esc or stop the cue, plugdata forgets which patch was loaded and reverts to its opening state (no patch loaded). I've gotten it to remember the patch and save to the QLab file exactly once, but I didn't notice what I had done differently. I tried editing and saving the patch, but there was no change.

Previously, in QLab 5.4.1, I had issues getting plugdata to use the most recent version of my patch. It kept reverting to an older version that it had cached. Both issues are consistent with the hypothesis that the plugdata AU is not persisting the patch when QLab thinks it should. I've not had this issue with other AUs, but I don't use AUs that much.

Never had this issue with the plugdata VST3. I don't see any mentions of QLab on plugdata's github, nor any mentions of plugdata in the QLab Google group.

Does anyone know how to coax the plugdata AU to remember the current patch?

Update: I just confirmed similar behavior in Audacity 3.3.3. Effect->Add Realtime Effects->Add effect->AudioUnit->plugdata-fx. Load a patch in the FX edit window, and then play. Everything's as expected. But if you close the FX edit window, then as soon as you stop playback, plugdata forgets the patch. MacOS 14.5

@jameslo said:

I don't see any mentions of QLab on plugdata's github

To be honest I'd never heard of this application before today, not that remarkable that it wouldn't be mentioned anywhere.

It makes more sense if you create a bug report on the plugdata github repository, so that the issue can be tracked, discussed and resolved there.

@dreamer said:

It makes more sense if you create a bug report on the plugdata github repository, so that the issue can be tracked, discussed and resolved there.

You're probably right, but having fielded tons of bad bug reports as a former developer, I just want to wait to see if someone has insight or if better tests occur to me. For instance, I just learned that the Mac version of REAPER runs AUs, so I tested in REAPER and there were no issues. So to me it's a tossup whether I should report it to the QLab group or the plugdata issue list.

(I'm also certain that someone on the QLab group is going to respond "plugWHAT?!!!" )

Update: plugdata as Realtime Effect in Audacity 3.6.1 is also forgetful.

@jameslo I have no idea of course.
Years ago it was suggested to use Rosetta to solve similar problems....
https://www.reddit.com/r/ableton/comments/z4j9hm/lost_the_connection_to_the_audio_unit_v2_plugin/?rdt=37055
..... but as it is working in Reaper maybe it isn't an OS problem.
Was rewire enabled in Reaper?...... I believe rewire has more hooks into a plugin than non-rewire.
A google for "qlab audio units not remembered' reveals .... https://qlab.app/docs/v5/fundamentals/managing-workspaces/
.... and as you say QLab is loading a cached version maybe that page explains how to stop that happening.
David.

@jameslo said:

For instance, I just learned that the Mac version of REAPER runs AUs, so I tested in REAPER and there were no issues. So to me it's a tossup whether I should report it to the QLab group or the plugdata issue list.

Reaper gives some insight, because its file format is text.

I created a Reaper project with a single track, and two effects: plugdata and ReaEQ. I saved two versions of this product, with slightly different plugdata patch contents. Then I opened both files in Emacs and did ediff-buffers on them.

The main difference is that a whole long string of binary-encoded stuff (not human readable) changed... plugdata appears as:

      <VST "VST3i: plugdata (plugdata) (32ch)" plugdata.vst3 0 "" 1821045374{ABCDEF019182FAEB506C44745064496E} ""

... a ton of encoded stuff... like 560 lines of it...

>

Since the encoded stuff changed, it means that plugdata renders the patch into the VST preset data. (Good point about this is that a DAW project using plugdata doesn't have to ship with a pd patch file.)

I guess then, for whatever reason, QLab and Audacity are not handling this, while Reaper does. One plausible guess might be that QLab and Audacity have a limit on the size of a plug-in's settings. Plugdata really spits out a lot. The ReaEQ settings are fully represented in 7-8 lines; plugdata, for a minimally simple adc~ --> dac~ patch, needs over 550. It wouldn't surprise me if some audio software assumed "nobody's going to make a plug-in that big."

Hm, here's a thought -- Cardinal synth (VCV Rack fork) should also save patches into plug-in settings, which could get arbitrarily large. Maybe try that in QLab, for differential testing. If they both fail, you would have more ammunition to go back to QLab. If QLab handles a large Cardinal patch but fails on plugdata, that seems more like a plugdata bug.

Audacity is open-source, so it may be possible to find a limit in the code.

Could be something else too (maybe plugdata's settings use some data types that certain software isn't prepared for). Or it could be too many parameters. Plugdata publishes 512 free parameters, plus 128*16 MIDI CCs, plus a few other odds and ends. Pretty sure even Vital isn't that big.

(I'm also certain that someone on the QLab group is going to respond "plugWHAT?!!!" )

Yeah, tech support finger-pointing. When I worked in tech support, I saw that a lot of questions that really should have gone to partner companies ended up coming to us, because we were the smaller kid on the playground.

hjh

Normally a DAW will save the "state" of a plugin (this is probably that binary blob you noted).

So the problem you see with Qlab is that a saved project does not retain the plugdata state? or was it that simply closing the plugdata window resets its state somehow?

Plugdata defers all it's plugin implementation to JUCE and such state management is likely also done there. Perhaps there are other JUCE plugins that have similar issues with their AU builds in Qlab.

@ddw_music said:

Hm, here's a thought -- Cardinal synth (VCV Rack fork) should also save patches into plug-in settings, which could get arbitrarily large. Maybe try that in QLab, for differential testing. If they both fail, you would have more ammunition to go back to QLab. If QLab handles a large Cardinal patch but fails on plugdata, that seems more like a plugdata bug.

Cardinal's AU implementation is completely independent of plugdata. Of course testing any other AU is useful to test, but ideally the same plugin framework is used to pinpoint where the issue is (with the framework or with the plugin).

@dreamer said:

Cardinal's AU implementation is completely independent of plugdata. Of course testing any other AU is useful to test, but ideally the same plugin framework is used to pinpoint where the issue is (with the framework or with the plugin).

I was suggesting to test whether the host would fail or succeed with a different plugin that is also likely to generate very large blobs. That's not a useless thing to test. You're correct that a result of "Cardinal OK, plugdata not OK" wouldn't be conclusive -- but if they both fail, it would point to the host.

hjh

@dreamer said:

So the problem you see with Qlab is that a saved project does not retain the plugdata state? or was it that simply closing the plugdata window resets its state somehow?

Well, both, but I would expect the former to fail if the AU forgets its state before you can save in the host. In QLab and Audacity, plugdata reverts back to its initial state (no patch loaded) in the course of normal host operations, before I've attempted to exit. I think I even tried exiting QLab while the cue and effect were running (and was prompted to save), but I'd have to rent another day license and check (which I'll do once I learn a enough about Cardinal to construct a useful test).

Hmm, but hold on a second. @ddw_music - if I somehow managed to save once in QLab (see the first paragraph of my original post), then doesn't that mean the huge plug-in state size hypothesis can't be true?

@jameslo said:

Hmm, but hold on a second. @ddw_music - if I somehow managed to save once in QLab (see the first paragraph of my original post), then doesn't that mean the huge plug-in state size hypothesis can't be true?

Ah, I hadn't spotted that. Indeed, if it can work under some unknown circumstances, then that would rule out my guess.

FWIW I can't get Audacity to use plugdata-fx -- I've enabled it in the plug-in manager, but it still doesn't show up in real-time effects for a track.

hjh

@ddw_music said:

FWIW I can't get Audacity to use plugdata-fx -- I've enabled it in the plug-in manager, but it still doesn't show up in real-time effects for a track.

Weird. I got nuthin for you. I installed Audacity 18 months ago, maybe updated it once or twice, and just recently installed plugdata. Wasn't even aware of the plug-in manager.

Update: I decided to skip the QLab group and submit a support ticket. I figure it's paid software, so why not?

Last update:

QLab tech support reproduced the error in QLab but reported that it doesn't happen in Ableton Live. They also discovered the following workaround:

We found that it's possible to persist the settings for a QLab cue with
an extra step. After configuring the effect settings as you'd like them, 
save them as a user preset for that AU. Then load that user preset, and 
the configuration will persist even after stopping and reloading a cue, 
and after saving, closing, and reopening the workspace.

That sounds like what I did in that one case, and it makes sense because (duh) saving a preset saves the current patch state. Figure 53 (QLab's maker) doesn't have the resources to investigate further, so can't provide any more insight. @timothyschoen, would it be helpful I entered this issue into plugdata's github or is that redundant?