I ended up using a hacky method, with some inspiration from @th8a:

wget https://github.com/agraef/purr-data/releases/download/2.9.0/pd-l2ork-2.9.0-ubuntu_16.04-x86_64.zip
unzip pd-l2ork-2.9.0-ubuntu_16.04-x86_64.zip
mkdir pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64
dpkg-deb -R pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64.deb pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64
sed -i -e 's/libgsl2/libgsl23/g' pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64/DEBIAN/control
sed -i -e 's/libpng12-0/libpng16-16/g' pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64/DEBIAN/control
dpkg-deb -b pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64 purrdata-pop.deb
sudo apt install ./purrdata-pop.deb

Seems to work ok with a lil testing, but I noticed fonts are a little funny in UI. Might be totally unrelated.

As a sidenote, when I usually have this problem (installing a deb I got off the internet) I can solve it 3 simple ways:

The simple method

double-click on the package file, and there is a little widget that comes up and lets you install it (and goes and finds the deps for you.)

The older, non-GUI method

sudo dpkg -i FILE.deb
# there will be errors
sudo apt-get -f install

This will grab all the deps (if they are available) and fix future apt errors.

The modern non-GUI method

You can also use the apt wrapper to do both steps:

sudo apt install ./FILE.deb

In most cases this works for things that are made for ubuntu, on Pop!OS, but in this case I get some errors (probly due to the version hard-coding):

sudo apt install ./pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64.deb 
[sudo] password for konsumer: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'pd-l2ork' instead of './pd-l2ork-2.9.0-20190416-rev.2b3f27c-x86_64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 pd-l2ork : Depends: libgsl2 but it is not installable
            Depends: libpng12-0 (>= 1.2.13-4) but it is not installable
            Recommends: tap-plugins but it is not going to be installed
            Recommends: ladspa-foo-plugins but it is not going to be installed
            Recommends: invada-studio-plugins-ladspa but it is not going to be installed
            Recommends: blepvco but it is not going to be installed
            Recommends: swh-plugins but it is not going to be installed
            Recommends: mcp-plugins but it is not going to be installed
            Recommends: cmt but it is not going to be installed
            Recommends: blop but it is not going to be installed
            Recommends: slv2-jack but it is not installable
            Recommends: omins but it is not going to be installed
            Recommends: ubuntustudio-audio-plugins but it is not going to be installed
            Recommends: rev-plugins but it is not going to be installed
            Recommends: dssi-utils but it is not going to be installed
            Recommends: vco-plugins but it is not going to be installed
            Recommends: wah-plugins but it is not going to be installed
            Recommends: fil-plugins but it is not going to be installed
            Recommends: mda-lv2 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Is there a new one of these? I am having same problems (on Pop!OS) and that link appears dead.

It's not perfect, but here is a video of it working pretty well:

I am accomplishing something similar, in a different way, so I don't have to use full paths. Chek out pdpi. In MAIN.pd I dynamically load a patch like this:

When it receives a float message on programchange, it dynamically loads the patch, then sends a synthetic loadbang message (dynamic loaded stuff doesn't trigger loadbang.)

To wire things up, I have a catch~ L, catch~ R hooked to dac~ and s control, and s note hooked to ctlin and notein

I fixed it with a bang to step, which seems a bit hacky, but it works.

What are linked lists? I liked the idea of using the new text, as I am already using a fairly new vanilla. I built this arpeggiator with text objects. It seems to work much better, but there is still a pause when it loops around. Am I using text sequencer incorrectly, or is there a better way to use this?

Yeh, I was thinking I should combine the bang outlets by just inputting the current step (instead of a bang.) I suspected your advice, but I appreciate the confirmation. I will report back if I get it working.

I want to make an arpeggiator that tracks the current midi keys that are down and plays them in the order they were pressed, and removes them from the pattern when they are released. Basically loop through steps and play the current position in the list of current notes with makenote. I started trying to make this with list objects and it doesn't work well. Often keys stay "stuck" or will not register they were pressed. Is there a better way to accomplish this goal? Here is what I have. arp-help.pd is the example. Any suggestions on making it work are greatly appreciated.

I ended up using dynamic messages to load patches as objects. Seems to work really well. Here is my framework,

I made another version, with no library dependencies.

You will need listplugins and analyseplugin in your path (they come with LADSPA, so you should.)

Again, they might need a little hand-tuning, but overall they should be a good start.

Hi David, I am also David.

m0oonlib doesn't come with Pd-vanilla, but I am willing to get Pd-extended working (I'm actually prototyping for a patch that will run on a raspberry pi.) I definitely want to share these patches when I'm done, so I am using relative paths because I want it to run on different environments, with different file structures, with everything relative to the main patch.

If I declare /synths wouldn't that be an absolute location (at the root of my filesystem?)

open messages require 2 params, the second of which is the path. If you leave it off you will get this error:

Bad arguments for message 'open' to object 'pd'

I have tried it several ways, and all do not work:

(I get the Bad Argument error)

With all of these I get Device not configured:

These work, but are not ideal:

I'd prefer not hardcoding an absolute path.

moonlib/absolutepath doesn't seem to work with a directory name, only a file. That means this works:

But not this (the format I actually need for path):

This works, but really I'd just prefer a solution that works in Pd-vanilla:

I'm on OSX with Pd 0.46-7

I'm trying to dynamically load patches.

I have this:

I have my patches in the relative dir synths/ named synth1.pd, synth2.pd, etc. When I click the radio I get this error:

synth1.pd: read failed; Device not configured

I wanted an easy way to generate skeleton patches for all my plugins, so I wrote a python script.

For the script to work, you need to install python-ladspa.

I have generated all the patches for my system, so for most people, you won't even need to generate the patches. They are located in the ladspa dir (install this in a pd lib dir).

You can check out how it works with demo.pd. demo.mid is a seq24 midi score.

plugins.txt is the info that the script spits out, when you run it, you can use it as reference when making your own patches.

You will probably need to fine-tune the generated patches, because the ladspa meta-data for control inputs isn't always accurate and sometimes a toggle is better then a slide, for example (see demo.pd for a few examples of tuned patches).

My demo patch also illustrates using midi record on/off messages.

The demo is simple and pretty noisy, I just threw it together.

I couldn't figure out how plugin~ ctlout's work, so I left it out.

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

I wanted an easy way to generate skeleton patches for all my plugins, so I wrote a python script.

For the script to work, you need to install python-ladspa.

I have generated all the patches for my system, so for most people, you won't even need to generate the patches. They are located in the ladspa dir (install this in a pd lib dir).

You can check out how it works with demo.pd. demo.mid is a seq24 midi score.

plugins.txt is the info that the script spits out, when you run it, you can use it as reference when making your own patches.

You will probably need to fine-tune the generated patches, because the ladspa meta-data for control inputs isn't always accurate and sometimes a toggle is better then a slide, for example (see demo.pd for a few examples of tuned patches).

My demo patch also illustrates using midi record on/off messages.

The demo is simple and pretty noisy, I just threw it together.

I couldn't figure out how plugin~ ctlout's work, so I left it out.

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

Use OSCroute.

You can do this:

[OSCroute /emotion /cognitive /facial]

Here is more on that
https://ccrma.stanford.edu/~juanig/articles/wiriavrlib/Reading_OSC_data_on.html

An easy way to do it with pduino/pd, try like this:

[ ] <- toggle
|
[select 0]

the first output of select is a 1/2 banger, the input of the toggle is where your doubled bang goes.

@lunchbox said:

is there any differences between the firmata and the simple messaging system? I'm also working with IR sensors, arduino connected to PD, and i need to read inputs from the arduino, so which external is better? I've tried the firmata, it works well, but i still don't get how this external works...

Yep, there is a difference. The difference is that firmata is designed to let everything happen in software, rather then on the arduino (see my attached example on the other post for an example of how to read your IR sensors)

Better is subjective. I like Pd coding better, so I use pduino and firmata.

So, to recap, burn firmata standard on your arduino, use Pduino, and code the app in pd, for easy, graphical, dynamic programming (pd-style) otherwise, interpret the messages in some other format, and do it some other way. It's up to you.

My attached example is definitely the easiest way to achieve your goals, in my opinion. You get the bonus of having pretty simple conversion from Arduino-languuage examples into pd-friendly code, rather then using some intermediary language that you have to code for on both ends (arduino interprets inputs, emits OSC or something else on serial, pd interprets OSC or something else and does stuff, blech!) instead you can just route incoming messages in pd, the same way you would with midi, a joystick, keys, or whatever.

Once you get pduino all setup, and my above patch works, try right-clicking on Pduino object, and choosing help. It actually has a pretty nice help file, which is how I figured all this out.

Did you burn the Pduino (Firmata) firmware on there? It's needed to make the arduino pd patch work. After that, you can just send commands to it, instead of writing your code to the arduino. It's a serial interface for PD. It already has the baud set correctly.

To install it, copy the "Firmata" dir (inside Firmata-2.0beta in Pduino distro) to arduino/hardware/libraries. After that, open the arduino IDE, and go to Sketchbook/Examples/Library_Firmata/Standard_Firmata. Burn this to your Arduino.

See the attached patch for an example of what you are trying to do, once you get Firmata installed. On the hardware end, connect photodetector to power and pin2.

http://www.pdpatchrepo.info/hurleur/arduino_din.pd