@whale-av My fancy colleagues look down on the ultralight, I have no idea why. I worked in 4 different theaters that owned the mk3 and was always happy with them.

Is it true in my case that both Pd and QLab are accessing the same MOTU driver, and that that driver implements the coreaudio API, and that that API governs how applications share drivers?

Is there any way to check what buffer size the MOTU driver is using?

One of the tests I ran this morning was to start QLab, then start my Pd patch, then quit QLab and measure. Same long latency. Maybe I should try switching Pd away from the ultralight and then switching back before testing? That would test your hypothesis, wouldn't it? Better yet: run QLab, quit QLab, run Pd, then test.

I ran a show with QLab and hosted a live vocal effect on the same Mac. Here was my setup:

What's odd is that Pd would have ~300mS of latency if my effect patch was started after QLab, but only about 10mS if it was started before. This morning I finally upgraded to Pd 0.55.2 from 0.55.1 and tested with the latest version of QLab, and latency is still dependent on startup order, although only about half as bad (~150mS) in the worst case (and also ~10mS in the best case). Pd's audio settings are 44100, 3 mS delay, 64 sample buffer size, and not using callbacks.

Does anyone know why Pd's latency is dependent on the order it is started? Are there other tests I should perform to understand better what's going on? This behavior is somewhat surprising to me because 2 years ago I ran a much more complicated show involving live effects implemented with REAPER, plugdata, VSTs, and OSC--I don't remember there being any issues.

And if you print the output of the pack on the left, you'll see that it prepends "list" to [samplerate 44100(

@trummerschlunk Have you tried using FFT resynthesis? The bands won't have constant pitch width and the whole thing will introduce extra latency, but it might not matter depending on the sound you want. Take a look at I06.timbre.stamp in Pd help. Also, the min number of bands would be 256, so you'd need to combine bands to get down to 32.

@trummerschlunk If you don't feel like figuring out the math, you could instead convert your end frequencies to fractional MIDI note numbers using [ftom], divide that MIDI interval into the number of bands you want, then convert back to frequency using [mtof]. That'll calculate the log stuff for you.
center frequencies.pd

@rph-r I don't know WebPd and will let others advise you on the networking issues, but you could easily make a remote UI for your installation patch using netsend/netreceive because by default they support Pd list messages:
server and remote.zip

@melter In your first post you wrote "distance between distance 1 and distance 2" but now you're writing "d1 and d2 (which controls the volume of the sound) is zero". In Pd, division by 0 equals 0 (which is definitely weird IMHO)--is that what you meant?

If you're not making the assumption I think you are, then why are you computing the difference between the log math and the output of [env~] in [inverse_sq_law]?

Why is it not enough to just divide distance 1 by distance 2 (both non-zero) and take that as your RMS factor? e.g.

Edit: I cross posted with @manuels ... didn't intend to repeat what he wrote

@melter I think you are expecting [env~] to output 100 for [noise~] at full amplitude. The approx 5dB discrepancy appears to be from that. Take a look at the [env~] help--even for a full amplitude sine, the output is -3dB.

@ddw_music Is this what you're looking for? It's from [pd [expr] examples] in [expr] help.

@le26muko said:

My bandmate is pushing me to sell it

On occasion, someone has seen something I've made for myself or for a work-for-hire job (e.g. a bike chain sleeve, a tube circuit, or an escape room feature) and has encouraged me to create a business selling it. I"ve offered these folks 50% of the company if they'd just help me set it up and navigate all the business stuff. So far, no takers, which to me is very revealing.

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?

@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?

@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?

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

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

@manuels Oh thanks! I missed else/highpass~

It actually seems to be the same

Teach a man to fish: you know this because you looked at source code, or some other way?

but you also have to take the square root of the Q factor!

Oh look, and they take the cube root for vcf_hp6~ when they chain 3 filters. I wasn't aware that Q worked that way. Do you know what they are doing with the cutoff freq signal, [iem_cot4~]?

Edit: just built it and listened on the cue I used to run live in Pd--I would not have been able to tell the difference blindfolded. Thanks again.

I'm assuming that I'd have to build an approximation in plugdata, is that correct? Do you have any suggestions on how to begin? I started stacking up a bunch of [vcf~] but had that strong "I have no idea what I'm doing" feeling.