It has taken some time, but I reported the PlugData GUI issue now. The JUCE related input and output issue has already been addressed.

https://github.com/plugdata-team/plugdata/issues/2093
https://github.com/plugdata-team/plugdata/issues/2084

Does this forum not send email notifications when a topic you create gets replies? I didn't get any.

Anyway...

My patch used Vanilla plus GEM and a few externals. I got all the updated versions of all the externals and Gem.
Gem is the one that's causing most of the trouble... or rather all of the trouble.

I get GL stack underflows, crashes when closing the gemwin, "someone sent a bogus pointer..." and other errors, none of which existed back when I created the patch. I have started reporting the bugs to Gem, but it's hard to isolate them, narrow them down and create minimal reproducing examples, as the patch is very, very complex, and the last time I touched it (and Pd) 12 years ago it was running seamlessly and very stable. I also tested on Windows and it's even worse: there it crashes when opening the gemwin.

My goal is not to use the old version of Pd and Gem to run the patch. That would be my very, very last resort. One one hand I suspected a bc-breaking change in how Pd handled some kinds of messages and wanted to test that, but I have already discarded that; on the other hand I wanted to see if I could run the patch without issues on the old versions, and from there either (a) start trying to narrow down the issues, always comparing between the two versions (because I don't remember how half of the stuff works, so if I reduce it to a minimal patch and still get issues, I'm never sure whether I'm introducing errors in the patch) or maybe (b) offer the Gem developers my whole patch (I cannot publish it but I would trust them) as a black box that certainly triggers a bunch of bugs even though it's very far from a minimal test case. I can still do that but it would be nice to confirm that the patch runs with no errors with the older version on a modern machine and OS.

In the end I was able to compile Pd 0.43-3 (pretty sure it would have been the same with 0.43-4) with the "new" build system by using CXXFLAGS="-std=c++98" for configure.

Now I have another issue:

Pd runs but only if I launch it from the correct folder. That is if I do from a terminal:

cd /path/to/pd-043-3/src
pd

it works (that is where the compiled binary was created; anyway everything holds true if I move it to ../bin/).
But if I do:

cd /path/to/pd-043-3
src/pd

then I get the error:

Error in startup script: couldn't read file "../tcl//pd-gui.tcl": no such file or directory

Not a huge deal, I can write a shell script that cds into the directory and runs pd, but it makes me think that something is not quite right.

I'm also trying and unable to compile the old version of Gem, but I'll open a separate thread about that.

@rph-r [savestate] runs after the abstraction is created and before [loadbang], I used a [loadbang] in the abstraction to load arguments which ends up deleting the [savestate] information. I added a [spigot] after the [loadbang] in the abstraction and any information coming into the right inlet will now disable the [loadbang], I believe this will solve you issue? Assuming I understand the problem, if this does not solve the issue an actual example patch demonstrating the issue would be helpful.
list-store51.pd

We can also make [savestate] happen after the [loadbang];

[del] and [del 0] are not actually zero delay, they delay it one event in the scheduler so makes that list bang after the patches [loadbang] fires. Generally you would not want to use this method and simply fix the abstraction in question, but could be helpful when using an abstraction from a library since your patch will not mysteriously break when you update the library or reinstall. Ideally you will be able to let the maintainer of the library know about the issue and they will fix it, but that is not always possible.

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

I recenlty used OBS to capture different IP camera stream and get the image in pix_video using a virtual camera as output in OBS.

• First issue is that pix_video cannot get thevirtual camera texture under Windows or MacOS (https://github.com/umlaeute/Gem/issues/433)

• I changed to Ubuntu linux and a second issue was that RTSP stream doesn't work anymore under Ubuntu, so I installed a
  special version of VLC to allows RTSP and finally made a VLC source in OBS...

adding here that i need to revise this statement:

if i compile Pd 0.55.0 with Wish-8.6.12, i get a build that works perfectly fine

... with this build, the switch between edit- and perform-mode do work as stated, but somehow, clicks sometimes are just ignored. this happens in both modes (and in the "temporary perform mode" with Cmd+Click). and since this is not an issue with Pd 0.53-2, there does seem to be some issue through changes on the Pd side.

Tested with:

1. [hradio] where i'm just clicking through all states: sometimes the state just doesn't change
2. alternately clicking inside a [+ ] object to edit it and outside to deselect: sometimes, it doesn't select the object text and sometimes it doesn't deselect the object.

EDIT: my assumption was also wrong that this other issue is not a case with Pd 0.53-2. seems like there is only the choice between the 2 issues, depending on the Wish version. :/

@whale-av said:

Stopping the [metro 10] that is banging [snapshot~] seems to relax Pd.

I have no issues with this patch on linux, patch peeks out at 5% cpu when I adjust tempo and no lags or drop outs or issues editing. This could be a bug in the Windows version of pd or perhaps just an issue with how Windows schedules and manages jobs? I assumed it was one of those issues with ASIO that you help people with so often so did not respond before.

get number of channels in mc connections
https://github.com/pure-data/pure-data/issues/1989

missing/useful [snake~] methods
https://github.com/pure-data/pure-data/issues/1996

@gentleclockdivider Ceammc is vanilla..... with some add-ons that seem not to load (according to your console).
Your Ceammc distribution must be based on a version of Pd prior to 0.53.
Prior to that version you had to define the length of the list to get..... so... [get $1 1( ... instead of... [get $1( ..... will work.

Please carefully check the help file for objects before posting technical issues.
You should find that they are different in your 2 screenshots.
If, and only if you are running the latest version of Ceammc, then you can report the issue here...... https://github.com/uliss/pd-ceammc/issues
David.

@4poksy A standard sequencer is probably a few dozen instructions to the cpu and even the early rpi can do ~2000 MFLOPS, pd can get a great deal done between audio blocks despite its single thread nature. Has your experience demonstrated that you even need to worry about this? Even my 230k patch which is an entire programming language can accomplish a great deal between audio blocks and it can control all of the parameters for a good number of analog style subtractive voices in real time without issue. Sure my computer is a considerably more performant than a pi but still, it is getting a hell of a lot done between audio blocks.

An arduino will probably not help anything unless you have a good amount of interface stuff and/or are using one of the old single core pis, with a multicore pi you can just do the UI stuff external of pd and let the kernel deal with scheduling everything, it will almost certainly do a better job than a mortal unless your programming skills are getting up around kernel dev level. Even on a single core pi it may not be an issue. If it is a multicore pi than one of the things you can do is isolate a cpu core with the isolcpus kernel parameter, play with IRQ affinity and start pd on that isolated core with taskset or cpuset, this will make sure that the kernel does not stick some other process on the core with pd during a time when pd has an easy load which can cause dropouts when that load suddenly jumps. You can also structure your patches so all UI is separate from DSP which will allow you to isolate a second core and run UI on one, DSP on another and communicate between them with [netsend]/[netreceive].

But none of that may even be a problem, are you having issues with dropouts or are you attempting to preempt such issues? For the former knowing your exact issues would help a great deal in assisting you, for the latter learning more about how pd works and the system on which it will be run will guide you in what preemptive measures you actually need to take.

The stuff above regarding arduino and pi should be taken with a grain of salt, I have no direct experience with either and am basing that off of my electronics/pd/linux knowledge, but someone (hopefully) will come along to correct me in short order if my assumptions are faulty.