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

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.

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.

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

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.

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).

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

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?

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

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?

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?