@dreamer I'm not so much scared of the concept of a chat room as I am incredulous that that would be the preferred format for technical discussions. Over here, people apologize for digressing and sometimes have a hard time following along! OK, let's see if anyone over there lectures me about cross-posting

Edit: I immediately got my answer from that scary chaotic place known as Discord . Use [plugin_latency].

Edit 2: But that object doesn't exist in v0.8.3, and I can't get v0.9.2 to work in REAPER. MIDI doesn't seem to be passed out of the plugdata to the next VST properly.

Edit 3: plugdata v0.9.2 on REAPER is identifying note on messages on channel 1 as being on channel 17 using [notein]. When using [midiin] it says it's on channel 2! Not an issue in v0.8.3 or Camomile.

In plugdata v0.9.2 hosted on REAPER v7.48 running on both Windows 10 and 11, I can't set the plugin's latency under Settings...->Latency (samples). When I enter the number of samples and close the dialog box, it immediately reverts to 0 and REAPER reports a plugin delay compensation amount of 64 samples which is what it reports when plugdata is first loaded. I fell back to plugdata v0.8.3 on my Win10 machine and was again able to set the latency, so there's my workaround.

Surprisingly, if I copy that same REAPER project hosting plugdata v0.8.3 over to the Win11 machine that has plugdata v0.9.2, it retains the latency I set on the Win10 machine, but as soon as I try to edit it, it reverts to 0.

Anyone else seeing this issue?

I'd also love to know if there is a way of setting the plugdata latency setting within Pd. My patch has a look-ahead detector, and when I change the look-ahead amount, the latency has to change accordingly.

Hi,

this is conTorchionist (or its embryonic version, I would say): https://github.com/ecrisufmg/contorchionist

It's a project that is in its very early stages, but I thought it was worth announcing here, not so much for its current development stage, but because it might be useful to others and also as a thank you to the community and the developers who have created inspiring tools. Besides, obviously, Pure Data, SuperCollider, and Python, I'm referring to libraries like FluCoMa, timbreID, nn~, librosa, and others, which have been fundamental to the development of conTorchionist.

Briefly, the idea is to have a nomadic and flexible library, based on libtorch, that allows for the use of the same DSP (machine listening, but also, in the future, other things related to synthesis/signal processing) and ML processes in both real-time (PD, Max, SC) and non-real-time (Python). Wrappers for other languages/environments should not be so hard to code, as everything is interfacing a shared library (and libtorch shared libraries). Another key idea is to have a widely used tool like PyTorch/libtorch/torchaudio as a foundation, which greatly facilitates development and integration with existing ML+ML experimentation workflows and processes. The structure is heavily inspired by FluCoMa, but it is probably simpler and follows a logic of core Processors and wrappers in different languages (we have been prioritizing Pure Data, but we are gradually creating things for Max, SC, and Python as well). Since we use libtorch, conTorchionist also has some other potentially interesting features, like using the GPU for calculations and DSP - CUDA (Windows/Linux) or MPS (Apple Silicon).

We are taking it slow, so a lot is still missing (documentation, testing, etc.). That's why we haven't published a versioned release or binaries yet. We hope to do so soon after verifying the consistency of some things regarding DSP calculations in PyTorch / torchaudio (which, in turn, use librosa as a reference) and ensuring that the initial wrappers compile properly on various operating systems (we have tested mainly on Linux and macOS, so it's likely that some adjustments will be needed in the CMakeLists for Windows).

I hope it will be useful and that we can gradually make things more organized. At the moment, it's just me and a great student (Vinícius Oliveira), plus some always quite hallucinatory and unreliable AI bots.

The paper we presented this week, on SBCM, is here: https://www.researchgate.net/publication/395473005_conTorchionist_A_flexible_nomadic_library_for_exploring_machine_listeninglearning_in_multiple_platforms_languages_and_time-contexts

Or if you prefer figures: https://ecris.cc/2025sbcm_contorchionist-slides/

Any feedback is appreciated, of course!

Best regards!

José Henrique Padovani

Previously been using an older MacBook Pro with OSX 10.10, and PurrData, all good.

New MacBook Pro M4 Max, and PurrData v2.19.3 from here... (2.20 was reported as damaged by the OS)...

https://github.com/agraef/purr-data/releases

PurrData v2.19.3 and v2.19.2 work fine, but there's no audio coming in from ~adc.

Opened a DAW, Reaper, set the input channels correctly, and there's audio coming in - to my new MacBook Po M4 Max. So the audio interface - a MOTU, is fine, and set up correctly ...it's just PurrData - there's nothing coming in from ~adc (I tried hooking up all input channels ~adc 1 2 3 4 5 6 7 8, and still nothing). Otherwise midi flows back and forth ok, and audio is sent out to the audio interface (via ~dac), but ~adc is dead ...and just to reiterate Reaper hears the input on those channels fine - but PurrData doesn't.

The audio properties in PurrData are set up fine, the audio interface selected, and multiple channels - so all good there (and I've using PD for many many years).

Anyone come across this - what to do?

@porres I understood that documentation to apply to ramps subsequent to the first ramp, and so am commenting on the part I didn't understand. Especially the part that the timing of all messages can be fractional WRT blocks. I'm sure that must be documented somewhere. I think I may have been predisposed to discovering it because I had recently studied REAPER's bare metal scripting language JSFX--that's how they do control rate timing.

FWIW, I tested MIDI messages and they looked to be block-aligned. I think REAPER keeps the fractional timing.

@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

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

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

@earlyjp I had to do something vaguely similar for a show last summer. I loaded the file I wanted to playback into REAPER, and then added automation and/or MIDI in relation to the audio file--all DAWs excel at that kind of thing. I triggered REAPER playback using OSC, and had a Pd patch running as a VST3 in plugdata (or maybe Camomile) that was reading the automation/MIDI and doing stuff in response.

BTW, since learning that's it's easy to encode arbitrary Pd messages as sysex, I've been using REAPER a lot more to record, edit, and playback Pd message sequences. To me, with my limited patience and imagination, It's more pleasant than doing it in Pd alone, although it's also true that I have to write myself plenty of notes regarding how. things are set up.

@ddw_music Oh OK, well I redid the test using a 1033.6 Hz sine wave (1.5 cycles/64 sample block) and the result is consistent with a 64 sample shift (i.e. 180 degrees out of phase), plus it goes away when I set plugdata's latency to 0. I'm gonna check on the REAPER forum to see what they say about PDC--maybe the issue is that REAPER assumes a base 64 sample latency for all plugins so plugdata doesn't need to report that portion.

It would still be interesting to see if other DAWs behave similarly. Maybe I have to dig out my old laptop and struggle with Cubase again. 1033.6 Hz sine.wav

BTW, is there a way to set plugdata's reported latency to the host programmatically? I have an FFT resynthesis patch that uses different block sizes. Camomile has that facility.

Update: I think I'm seeing the same behavior in Audacity, but my understanding of Audacity is weak. I also tested an FFT resynthesis patch in REAPER using a 16384 block size and set plugdata's latency to 16320 (16384 - 64) ; that produced the alignment I was expecting. So I'm provisionally declaring that you should set plugdata's latency to the latency of your patch as measured between adc~ and dac~. In retrospect that seems completely obvious, but I was thrown by plugdata's default of 64.