To begin, I apologize in advance for this Not being a complete abstraction, so please forgive me for that.

As apology, I offer my humility: 10 hours-straight work later, I know some of what i thought of is beyond my knowledge limit and capacity to continue working on.

That all being said,...

My idea (which I thought would be Very simple, yet learned that PD, no matter how sweet She is, does not behave like the linux shell) was simple:

Make a rack of a set of vradios (i chose 8 due to the cpu limit on my laptop, but more could easily be added) which each denote a set of effects;

Send the results to a shell control along with the "slot" in the stack;

Have it copy that effect into an eff(ects)/tmp folder (mapping over the dummy files that were there),

so when the adc~ > eff1 > eff2, etc., chain runs they would be loaded as copies of the desired effects abstractions.

My intention was to empower the usage of multiple instances of the same effects abstractions as well as cut the wiring required in many/my pedal rack/s I have seen to almost nil.

That Was accomplished.

And I DO like the "idea".

On the other hand, I learned, to my chagrin, 2 VERY important lessons:

1. pd loads all subpatches on startup
   and
2. there is no (this is were I bow to higher minds than myself) way to "refresh" the patch, shy of closing and reopening it (because while you can do this sort of thing in linux, you can not in pd "underwrite" a subpatch and presume it will know the change has been made).

I Did pursue trying to load via "cat" the effect file-contents into a pd (sub)patch object, but could not figure out how to make that work, even with subtracting the file accouterments, i.e.#X, #N.

In closing I will say that the goal, though only partially achieved, IS one worth pursuing if it is a domain you are more knowledgeable about than myself.

I have attached a zip of my work.

It includes:

a shell script to start extended (it must be started this way, if the shell object is to know where the resource folder is located;

a folder, "res", which includes: /effs (where you put your effects abstractions), /effs_tmp (with 8 dummy files, where your effs get copied to), and /helper (where Mother is located)

and

a Mother_effsmap.txt file, where you list your effects, by filename (including the ".pd" extension", which it cross-references the vradio index to the line number on the file to know which file to copy.

Also,
I have found that it does copy correctly, but then you are left with the stack of controls to contend with. But I have yet to figure that out and think it better to go ahead and share it.

-peace, thanks for listening, and I hope it gives you some new ideas to work with.

svanya

Mother.zip

I stumbled on pd-fileutils and what it can do:

So I put together a linux (tho I'm sure you can make a .bat windows version, too) shell script that will (if added as a "Tool" to the Web Developer Extension (mozilla add-in and probably others too) you can:

View a raw pd webpage, ex. on GitHub (have not tested on others, and in some instances when a link points to a pd file my browser thinks its a binary )
Go to Web Developer Extension > Tools > pd_viewer;
and
See the file in all its real PureData glory.

Two images below and an attached .zip of the needed pd2svg (js + css folders) and the shell script, "pd-fileutils_viewer".

Standard Rule re: downloaded shell scripts:

ALWAYS look inside the script before ever running it on your computer to be sure it does not have anything that would mess up your system.

In this case, what it does is:

Copy the needed files to /tmp, read the online path to the raw file, wget the file to /tmp, take the (base)filename name, echo a header with all the pd-fileutils html stuff, cat in (and sed replace the quotes and apostrophes with their entities) the pd file as a string, then echo the html page footer, and send it to your default browser.

To do this you will need to add the Web Developer Extension, tho I am pretty sure any other add-in/feature that lets you run an app on a page will work too;
extract the contents of the zip below to a location of your choice,
then add the "pd-fileutils_viewer" as a program to view those pages, i.e. as a "tool".

Viola! Pd file ready for viewing!

pd-fileutils_viewer.zip

If you see any wrinkles in this either or ways to improve it let me know and I will see about incorportating or you can do it yourself and share the updated version.

But for now at least: The WWW is in our pd oyster.

Peace, goodwill, and happy music making,
-svanya

note: depending on how much work the pd-fileutils is asked to do, i.e. how complex the patch is it might take a moment to render the svg.
The images below hopefully will guide you thru how to set it up. Basically, add the mozilla Web Developer Extension, then under Tools, point it to where ever you saved the shell (with its folder) script.

Ciao for now

.

Haven't followed the whole of this conversation, but what I've understood is that you're trying to connect to a wireless network, right? Do you use a wireless dongle or something? Cause I think the Pi doesn't have wireless, or does it?
Anyway, since both your computer and the Pi are in the same network, you can run a script on the Pi's side to get it's IP and send that over to your computer, if setting a fixed IP is a problem. Actually you can use [shell] to get the IP of the Pi without using a script.
Put the following line in a message:
ip addr list wlan0 | grep "inet " | cut -d' ' -f6 | cut -d/ -f1
and send that message to [shell] and it will output the IP of the wireless from its left outlet. If you know your computer's IP (which should probably be fixed for such a project) you can have that hard coded in the patch running in the Pi and send the output of [shell] to [netsend] via [oscformat]. Then in your computer you can have the incoming IP go through a [symbol] and from there to the following message:
connect $1 9001
taken that the port your computer will send data to the Pi is 9001. Anyway, you get the idea. This way your computer will get connected to the Pi.

THE GOAL:

I want my Raspberry Pi 2 to automatically start up the Jack server with realtime scheduling, and subsequently start Pure Data with realtime scheduling, load a patch &c. without any user intervention from a login shell.

As a performance artist working primarily with psychodrama (the technology is definitely NOT the important part here), fiddling around at a terminal right before or during a performance is kind of... psychically inconvenient. I need a box that I can plug in, give the audio output to the sound guy, and be ready to go.

PREREQUISITES:

I use Raspbian with a Linux kernel compiled with realtime goodness. I have hand-compiled Jack2 and Pure Data with realtime support in order to take advantage of this. Running a process with realtime priority requires the proper PAM directives set in /etc/security/limits.conf and related places, but that is beyond the scope of this little write-up.

Also somewhat relevant: I use a M-Audio MobilePre USB soundcard (sounds pretty awful by today's standards, but it's an extremely USEFUL box and sounds good enough for the work I do). For full-duplex sound, this requires the RasPi's USB to be set to single speed. In this configuration, I can get just under 2.9ms latency with good CPU overhead for Pure Data to run a few of my 64-voice wavetable and delay line granulators. Yeah!

THE PROBLEM:

Purely by happenstance, I had given the jackd command in my startup script the option “-s” which allows the server to ignore overruns and so on. So things seemed to be working as expected, but I noticed a lot more glitches than when I manually started up Jack and Pd from the terminal without the “-s” option. Upon removing it from my startup script, everything failed! WAH.

So I started piping STDERR and STDOUT to text files so I could read what either Jack or Pd were complaining about. As it turns out, Jack was unable to start with realtime priority due to a permissions problem. (I assume this is one of the things the “-s” options allows jackd to ignore, and thus start up with non-realtime priority. Problem is that Pure Data can’t connect to a non-realtime Jack server when its “-rt” option specified.)

Now, I had already been through the whole rigamarole of setting proper memory and priority limits for the “audio” group, to which the user “pi” belongs. So I thought, okay, I have to execute these commands as “pi”, and while simulating a login shell because the security limits in question are only set during login.

So I did this:

su -l pi -c "/usr/local/bin/jackd -R -dalsa -dhw:1,0 -p128 -n3 -r44100 -S >> /home/pi/jackd.log 2>&1 &"

This says “login as user ‘pi’ and then run the jackd command with these options, piping the outputs to this log file and run it in the background”. Well, I still got all the same errors about not being able to set realtime priority. WHYYYYYYYYY?

THE SOLUTION:

I hunted and hunted and hunted on a Very Popular Search Engine til I decided to try searching “security limits not loaded with su -l” and found this.

(Makes me think of that Talking Heads lyric, “Isn’t it weird / Looks too obscure to me”.)

So by uncommenting the line # session required pam_limits.so in /etc/pam.d/su everything started working as expected.

CONCLUSION:

I now know a LOT MORE about PAM and how important it is to keep in mind when and in what order scripts and other little subsystems are executed; but also that sometimes the problem is EXTREMELY OBSCURE and is to be found in some seemingly far-flung config file.

I hope this helps anybody out there working with Pure Data and the RasPi. The second generation board really packs quite a punch and can run several hundred audio grains (run by vline~ and enveloped by vline~ and cos~) simultaneously without a problem. And I'm pretty sure this is just using ONE of the 4 cores!

I'm by no means an expert Linux sysadmin, so if you have any other suggestions or corrections, please let me know! I wouldn't have been able to get this far without all the generous and helpful writeups everybody else has contributed, both within the RasPi and Pure Data communities. If you have any questions about anything I glossed over here, I'll do my best to answer them.

Hello, morganevansweiler:
I do not use OSX but GNU/Linux.
There was this post sometime ago:

http://puredata.hurleur.com/sujet-5515-gem-alternative-guis

in which katjav used a bash script to launch two instances of Pd. I paste that part below, which is also in the thread above:

<cite from Katjav>

-That's a good idea to start a -noaudio Pd for the GEM GUI.

OSX does not like to start two instances of a process, but there is a syntax to do it from a single terminal window. As a script (example):

#!/bin/bash
/Applications/Pd-extended.app/Contents/Resources/bin/pd /Users/katja/pd/Slicejockey/SliceJockey.pd &
/Applications/Pd-extended.app/Contents/Resources/bin/pd -noaudio /Users/katja/pd/GEMdingen/draggable-guis/1WaveRefinery.pd

The '&' option does it.

Now you would need a different script for each OS, and even for each user because paths are always different. I'm thinking of ways how to make this user friendly so the patches can be shared without the user selecting and rewriting the correct script.

Say you first open the audio patch in a Pd with gui and audio. On that patch is [ggee/getdir] to find the working directory and the GUI patch. Now it would be great to open a second Pd with -noaudio and load the GUI patch, from *within* the first Pd. There is a variety of shell objects for Pd:
[motex/system], [ggee/shell], [flatspace/open] and [moonlib/open]. They all work different and it's easier to crash Pd with them than get anything useful done, like starting a second Pd. I have not yet succeeded in this. Further, to make it work for everybody, the path to the Pd executable should be somehow found in runtime. I have the feeling that these things can be solved.

<end of cite from Katjav>

Anyway, I recommend you to read that thread so you can catch up with the twin instances topic.
Good luck!

Sumidero

Sonsofsol, I followed your hints.

I got the idea to do a single cross-platform tcl script, because tcl is by definition present on all computers with a Pd or Pd-extended installation. I had help from a script-wiz this weekend.

It works like this: from a running Pd you open a second Pd instance, with optional arguments, by simple click or loadbang.

[bang]
|
[getdir]
|
[open tclsh $1/anotherPd.tcl <argument1> <argument2etc.>(
|
[moonlib/popen]

The tcl code:

# cross-platform script to open a Pd-extended instance

# change working directory to location of this script so we can use relative path names:

set workingdir [file dirname [info script]]
cd $workingdir

# find operating system and executable path, assuming regular location

if { $tcl_platform(os) == "Linux" } {
puts "this operating system = Linux"
set pdpath [exec which pdextended]
} elseif { $tcl_platform(os) == "Darwin" } {
puts "this operating system = OSX"
set pdpath [glob /Applications/Pd-extended*.app/Contents/Resources/bin/pd]
} elseif { $tcl_platform(platform) == "windows" } {
puts "this operating system = Windows"
set pdpath [exec which pd.exe]
}

# in case of more than one Pd-extended executables found, use the first one:

set pdpath [lindex $pdpath 0]

# start Pd-extended with optional arguments:

eval exec $pdpath $argv &

You can automatically load a patch with relative path into the new instance by passing it as argument. We tested this on Linux and OSX and so far it seems to work fine. Would be nice if someone could test this on Windows. Example patch and tcl file are attached.

Maybe there are easier or better ways to perform the same functionality. We did not try Python scripting for example.

Katja

edit: changed the path find function for Windows to [exec which pd.exe]

last edit: sorry folks, this which command for Windows will only work if you have special gnu commands installed. I hope to find a better solution.

http://www.pdpatchrepo.info/hurleur/anotherPd.zip

shouldnt it be possible to put the script in the working directory and use a local path? - to avoid having the user to change anything...
or if that doesnt work - use a function to find the path of the workingdirectory in the script?

also when executing something in the shell from pd, i found it more useful+stable to write a shell-script with the commands and just execute that script from within pd instead of the commands themselves.
well
good success with this anyway.

@sonsofsol said:

start C:\Programme\pd\bin\pd.exe -noaudio D:\koffa_root\camera\gui.pd
start C:\Programme\pd\bin\pd.exe -nogui D:\koffa_root\camera\audioplayer.pd

That's a good idea to start a -noaudio Pd for the GEM GUI.

OSX does not like to start two instances of a process, but there is a syntax to do it from a single terminal window. As a script (example):

#!/bin/bash
/Applications/Pd-extended.app/Contents/Resources/bin/pd /Users/katja/pd/Slicejockey/SliceJockey.pd &
/Applications/Pd-extended.app/Contents/Resources/bin/pd -noaudio /Users/katja/pd/GEMdingen/draggable-guis/1WaveRefinery.pd

The '&' option does it.

Now you would need a different script for each OS, and even for each user because paths are always different. I'm thinking of ways how to make this user friendly so the patches can be shared without the user selecting and rewriting the correct script.

Say you first open the audio patch in a Pd with gui and audio. On that patch is [ggee/getdir] to find the working directory and the GUI patch. Now it would be great to open a second Pd with -noaudio and load the GUI patch, from *within* the first Pd. There is a variety of shell objects for Pd:
[motex/system], [ggee/shell], [flatspace/open] and [moonlib/open]. They all work different and it's easier to crash Pd with them than get anything useful done, like starting a second Pd. I have not yet succeeded in this. Further, to make it work for everybody, the path to the Pd executable should be somehow found in runtime. I have the feeling that these things can be solved.

Katja

** EDIT ** I created an UPDATED version on this wiki page with steps to follow. Here:
http://puredata.info/docs/developer/DebianWheezyAmd64

Hi Nicola,
@bamboomusic said:

Hi, I've just installed Debian Wheezy amd64, but I can't be able to find a compiled Pd-Extended version for Debian 64-bit.
I checked in:
http://puredata.info/community/projects/software/pd-extended
http://autobuild.puredata.info/auto-build/

and in the puredata repo, but I only found i386 versions.

Am I missing something?

I think simply there is no packaged version.

I actually managed to build the source partly following the instructions found here:
http://puredata.info/docs/developer/Debian and thanks to the script in the scripts directory in the source package - credit really goes to the authors of these

with some modifications and additions:
---- WARNING. Pretty much untested. Pd starts, no libraries complain, audio and a bunch of patches I have work with alsa and jack ----

• Add the debian multimedia repository as explained directly on their page:
  http://debian-multimedia.org/

• Do the build-dep as explained but with a slight modification

  apt-get build-dep puredata gem pd-pdp

(notice pd-pdp non not pdp)

• Install the following packages not listed on that page:

  apt-get install libmp3lame0 libmp3lame-dev ladspa-sdk dssi-dev libimlib2-dev libtheora-dev

• Install libquicktime1 and libquicktime-dev from the official main packages *not* with apt. The links:
  http://packages.debian.org/testing/libs/libquicktime1
  http://packages.debian.org/wheezy/libquicktime-dev

• Get the source of Pd-extended, unpack anywere as explained in other places..

• from the main source directory go to source dir for pidip:

  cd externals/pidip/

• configure and make pidip with the following switches:

  ./configure --with-pd=../../pd --with-pdp=../pdp
  make

• chdir to scripts/auto-build/ from the source dir:

  cd scripts/auto-build/

• Start the ./pd-extended-auto-builder.sh script:

  ./pd-extended-auto-builder.sh

• Wait...

• Cross fingers...

• Ignore some scary messages...
  If everything went well there should be a message saying you have a deb in dir ./packages/linux_make/Pd-0.42.5-extended.deb (still from the source root):

• cd there:

  cd ../../packages/linux_make/

• Finally install:

  dpkg -i Pd-0.42.5-extended.deb

By the way I got a nice .deb so maybe I could put it up somewhere, not sure about the dependencies though.

Hope this helps,
Lorenzo

@quantum said:

Cool thanks

How do I know what order the script variables are in?

you define these yourself in the sh script with $1, $2 just like in a pd patch. check this guy out for an example:
http://www.dafe.lukifer.net/stuffoffdesktop/GEMMoviemakerScript.sh
this script also uses nc, which you will want to learn...
@quantum said:

Also, how do I set up scripts to send and receive messages over netsend?

"man nc" netcat is the coolest.

@quantum said:

Can I set up scripts to communicate over OSC?

probably. I know nothing about OSC (and am shamed for it)