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.

@raynovich said:

Does ofelia take over the "terminal" or some other function for Pure Data if created?

TL;DR Probably the best solution is for you to construct the commands with full paths, pointing exactly where you want, and do not rely on the current working directory.

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz.

Why?

"Shell" functions (as I understand it -- maybe it's different in some programming environments, but this is my observation) generally don't persist their state.

That is, if you open a terminal window, there is one shell, and every command operates on the same shell. cd changes the current working directory of the shell, and the next command remembers the new cwd.

An object like [shell] is like opening a new terminal window for every command. Every invocation starts from scratch. So you should not expect it to work if you ask shell to first cd, then ls. (You said this worked, but I was not able to get that behavior on my machine.)

SuperCollider has a couple of ways to do it that illustrate the issues involved.

"ls".unixCmd;  // user home

"cd tmp".unixCmd;  // no output, OK

"ls".unixCmd;  // still user home

The cd did not affect the second ls -- because it's like: terminal window 1, ls; terminal window 2, cd; terminal window 3, ls and why would you expect window 2 to affect the behavior of window 3?

Many shells, when parsing the typed input, can handle a series of commands separated by &&:

"cd tmp && ls".unixCmd;  // lists ~/tmp, OK!

But this is a parsing feature. If a backend issues the command in a different way -- as an array of strings, where the first string is the command and the other strings are arguments, one by one -- this bypasses the parser (because the arguments are already parsed into the array), and the && trick no longer works.

"cd tmp && ls".split($ ).postcs.unixCmd;
[ "cd", "tmp", "&&", "ls" ]
(and no `ls` listing)

[shell], as far as I can see, works in this second way. A message like ls tmp works only if it's a list of two symbols. If you try to make it a single command string -- ls\ tmp -- then it fails, because there is no system command named l-s-space-t-m-p. (In SC, "ls tmp".unixCmd runs the command through the shell's parser, which splits a string into command-and-argument. That usage isn't supported in [shell]. Maybe it's supported in [command] but I didn't take a look.)

hjh

Hello all,
So, I am trying to open an Applescript using Shell.

I am confused by how shell works. I would think that sending Shell cd .. should take the system down up a directory, but it does not seem to work. I am stuck on the directory that I went to.

Can anyone provide additional clarity on Shell and moving directories and applications and such.

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