Hey, I ran into something similar on Ventura. The trick that worked for me was wrapping the osascript call in a small shell script and calling that from PD instead of running the AppleScript directly.

So instead of:
osascript -e "set volume output volume 50"

Try creating a shell script like this:

bash
Copy
Edit
#!/bin/bash
osascript -e "set volume output volume 50"
Save it as setvol.sh, make it executable (chmod +x setvol.sh), and then call it from PD using ggee/shell.

This worked for me when the direct call was silently failing inside PD. Let me know if it helps!

@alexandros I tried to compile with Ubuntu and there are some issues. But you need to keep the addons name ofxOfeliaExtended (ofxImGui is included then) - that might be your issue. I will give it another try. I use the OF master branch, so possibly the lua bindings need to be regenerated, if you use an older OF version (https://github.com/Jonathhhan/ofxOfeliaExtended/tree/main/scripts/common and https://github.com/Jonathhhan/ofxOfeliaExtended/tree/main/libs/ofxLua/scripts).
Btw: I also updated the regular addon / external ofxOfelia some time ago and it is still working... https://github.com/Jonathhhan/ofxOfelia/tree/update-april-2024
Regarding ofxImGui: I included the develop-branch: https://github.com/jvcleave/ofxImGui/tree/develop

@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

@cfry Try using the full paths to the program in the message that starts pdreceive. [exec /Applications/Pd-0.53-2.app/Contents/Resources/bin/pdreceive 3000( Also updated the patch in the original post to get rid of the [del] and run the connect message off of the exit status of [command], not sure what I was thinking there.

I am running linux and it works here. For your having to force quit, I am guessing OSX is more picky than linux here and we probably just need to do some cleanup, try deleting the [logger] abstraction before quiting and see what happens.

Edit: forgot to answer part of your question there. I am betting the abstraction will work fine on your pi and once we figure out why it is not working on OSX we can make a couple tweaks to the abstraction so it will work for both. For learning about working with the shell, I don't really know about resources these days, I learned this stuff 20 years ago, mainly learned by using the shell and learning to write shell scripts, these days when I have a question I generally just search stackoverflow. Learning to script will certainly teach you a fair amount, I learned that primarily with the bash man page and IRC which I suppose would be discord these days

@zigmhount I generally just pay attention to the order I start them in and specify the midi stuff at startup, pd -alsamidi -mididev 1 <files to open> first listed by aconnect will be the first started. The entire startup process including connecting the midi ports can be scripted so all you have to do is run a script and have everything good to go. I will try and get around to making my pd script a more generic startup/connect script if you want, probably can do it tomorrow. But perhaps someone knows a way to name them or has a better alternative. I just went with what I know when I made my script, more interested in making it all work then figuring out the best way.

@esaruoho [command] and [ggee/shell] allow you to execute shell commands and scripts, both are in dekken, no idea if they work on OSX but I expect they would. I also do not know what shell they run, might be limited to plain old sh for scripts but I believe I have used bashisms with both, would be surprised if I havn't so they may just load the users default shell.

@Load074 Since it takes so long you may want to just log all those prints externally. You can use the pdreceive command line application to send the data out of pd with the [netsend] object. So instead of connecting thing to various [print] objects you prepend a descriptive label to the data and then send that into [netsend]. Run pdreceive [port number] >> [logfile name] then send the [connect <port number>( to your [netsend] object in pd, and start the patch, everything gets send there. Then you can use a text editor or the standard command line tools to examine the text file after the crash, just control-c to kill pdreceive after pd freezes. Useful tools too examine the log will be things like tail and grep, tail -50 [logfile] will give you the last 50 lines of the log, tail -50 [logfile] | grep [label] will give you the last 50 occurances of all entries for [label]. Should make it much easier to decode the problem. The [trace] object could also be of use here. And there are a great number of other useful tools on the command line, any of the tools used for working with text files like cut and sort and the shells own scripting language, any good guide for your shell should help you here if you do not have much experience with shell scripting and the command line apps.

And time is relative, no need to wait an hour, speed up your control objects, if everything is under control of a master [metro] make it run 10 times faster and you will get your result in a tenth of the time. If you are logging it all to a file you do not need things to run slow enough that you can read them in the log window.

@Jona No, I manually updated the paths which the script updates because I had been dealing with terrible readme's and build instructions all night by the time i got to ofelia and it seems my reading comprehension was seriously degraded by then. Script also seems to add some files to OF, so it might solve the problem, but the deken install having the same issue leaves me doubtful. Thanks for pointing out the obvious, it is often exactly what I need.

The second script is the cause of all my frustration that night, OF's build instructions are just a few scripts for major distros which leave anyone using other distros in the dark, I had to sift through all the scripts and find what packages I was missing, so lots of failed build attempts on OF and a few fun diversions into problems building those dependencies by the time I got to ofelia. 99% certain I got all those, OF did build error free.

@oid I guess you already run this script before compiling the external?
https://github.com/cuinjune/Ofelia/tree/master/scripts/Linux64
And https://github.com/openframeworks/openFrameworks/tree/master/scripts/linux/ubuntu (depending on the linux distro)...

Hey everyone,

I wasn't sure where to post this, but I wrote a little bash script to make my mouse input ctrl+e only when purr-data is running.

In the hopes that this makes someone else's life a little easier, here's the script- you just need to bind it to your chosen mouse button using xbindkeys. (xbindkeys -k will pop open a little window where you can find out which button you're trying to assign, xev also works, but you'll need to download it as well) You'll also need to download xdotool if you don't have it already. I've included an xbindkeys config file as well.

note that you'll need to replace "purr-data" in the script at line S1='"purr-data"' with whatever the class of the windows are for the version of pd you're running. you can find this by running xprop in a terminal and clicking on pd, there should be a line with WM_CLASS. The text you want is what's in quotations after the third space in that line. The script will look for those quotation marks, so make sure you include them between the ticks!

If you're running purr-data and the button on your mouse you want to assign is somehow b:2, then this will work out of the box as long as you make the script executable and run xbindkeys -f /path/to/~xbindkeysrc

I know I've done a shoddy job explaining this, so please feel free to contact me if you want to get it working! I know it's saved me a lot of reaching to my keyboard when I'm disconnecting and connecting and testing things.~xbindkeysrc purr-data_editmodetoggle.sh