I've seen several libraries and applications for including Pd as the audio engine for Unity3D. How do I use a combo of Pd and Unity3D where I use only Pd for Unity "scripting"? I'd build the models in the Unity3D environment, though I'd like to programatically generate models in Pd at runtime too. But all the behaviors I'd like to control in Pd, not any Unity3D scripting language or system.

Basically I'd like to use Unity3D as the GUI environment for Pd patches, the way Pd can use GEM. How do I do that? How do I get access to any Unity3D API other than just the audio?

[ctlin] , [midiin] and [sysexin] are each passive receivers of MIDI data that must be actively sent by a MIDI device. Is there a way for Pd to poll a MIDI device? For example, read a Korg Nanokontrol's knob positions without changing the knob positions? Is there a way to read a "control" value, not just the "Control Change" value when a control's value is changed?

I understand that message and object dollar args ($1 etc) are substituted with values from different types of sources: Object arg values are from their enclosing scope's creation arg values and message args are from their inlet values. What do I do if I want to create an object with a dynamic value from a message?

Specifically I want a small abstraction wrapping [ctlin] so I can choose during runtime which control (and/or its channel) it's getting CC values from. [ctlin] has no inlets, nor properties (so no receive symbol), only creation args. I thought that I could Put a [ctlinWrapper] subpatch in my patch (saved in the same folder or in the Path as ctlinWrapper.pd ). In the subpatch include [inlet]-[f] to accept a message sent in the enclosing patch connected to the subpatch inlet, that would be available in the subpatch as $1. Then I could include in the subpatch [ctlin $1] . But the $1 in [ctlin $1] doesn't seem to receive the value from the inlet, as [ctlin $1] doesn't output any value even when I work the MIDI control that generates the CC signal.

Is there a way to specify by message during runtime a creation arg of an object? Or otherwise specify during runtime rather than at creation the control that [ctlin] reports?

Whenever I tried to Put into a patch of some moderate complexity a new Object, after typing the 4th character of the new object's name my X server would crash, ending my login session and forcing a new login. I installed the latest official Intel Linux graphics driver using Intel's APT source as per some third party instructions and my problem was solved.

Note: Intel disclaims support for lowlatency kernels with these drivers. I haven't upgraded the Mint kernel to a lowlatency version yet to test.

Details:
Pd-extended 43.4 was crashing my (up to date) HD4000 GPU / UbuntuStudio/x86_64 v12.04 workstation's X server whenever I tried to Put into a patch of some moderate complexity a new Object, after typing the 4th character of the new object's name. It was the only app causing that kind of crash, but it was the last straw with Ubuntu for me (many other problems with UbuntuStudio). So I replaced my OS with Linux Mint 15 / Cinnamon. I was less unhappy with Mint's new set of problems, but Pd kept crashing X. So I deleted Pd-extended and replaced it with the latest (20130724) Pd-l2ork . But that crashed the X server the same way. /var/log/syslog reported gnome-session was crashing the Xserver:

(date time hostname) gnome-session[17963]: Gdk-WARNING: gnome-session: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.#012
(date time hostname) mdm[17908]: WARNING: mdm_slave_xioerror_handler: Fatal X error - Restarting :0

Googling showed lots of X users having this problem with lots of apps going back several years. Usually they solved it with workarounds that stopped executing the code triggering the crash. Or they installed their entire X system. Or a new kernel upgrade solved it automagically. Or they upgraded the video kernel driver. I opted to upgrade the driver, which forced an upgrade of many essential packages in the entire X system.

The official Intel support pages start at the Intel Download Center at https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=13815 linking to the .deb download at https://01.org/linuxgraphics/downloads/2013/intelr-linux-graphics-installer-version-1.0.2 supports only Ubuntu and Fedora, not Mint. I found an insightful and thorough page at http://www.webupd8.org/2013/04/how-to-use-intel-linux-graphics-drivers.html explaining the Intel support contents, the subtle ways Mint (and some other Ubuntu based distros) requirements differ from the supported distros', and how to add to Mint the official Intel APT sources and install. This way it's a "set it and forget it" repair, so ongoing upgrades to the workstation's OS will be maintained automatically, without revisiting this intervention.

for Linux distributions based on Ubuntu 13.04 (like Linux Mint 15), use the Linux commandline:

echo "deb https://download.01.org/gfx/ubuntu/13.04/main Ubuntu 13.04 #Intel Graphics drivers" | sudo tee /etc/apt/sources.list.d/intellinuxgraphics.list
wget --no-check-certificate https://download.01.org/gfx/RPM-GPG-KEY-ilg -O - | sudo apt-key add -
wget --no-check-certificate https://download.01.org/gfx/RPM-GPG-KEY-ilg-2 -O - | sudo apt-key add -
sudo apt-get update
sudo apt-get upgrade # Or use other package management tool, like Synaptic etc.

Note: Intel disclaims support for lowlatency kernels with these drivers. I haven't upgraded the Mint kernel to a lowlatency version yet to test.

Howdy. I have a Python script I want to embed inside a Pd patch. So I believe I want to use Python externals, which I believe is the way to do that.

So I tried following the instructions for including PyExt as an external, which I believe enables using Python externals. However, I immediately got into some kind of recursive installation session, since PyExt depends on something else, which depends on something else.

Where can I find the simplest current instructions for whatever I must do to include a Python script in a Pd patch? I'm using Pd 0.43.4-extended on Linux Mint 15 / Cinnamon / AMD64 . Thanks for the help.

Howdy. Attached to this message please find sys_gui-test.pd . In it I'm exercising the sys_gui object, sending it tcl designed to display simple Tk GUI widgets. I'm using pd-extended v0.43.4-extended on Ubuntu Studio 12.04 .

Banging the first set of messages works, it shows a Tk messageBox and receives the user response. But banging the second set of messages fails to display the Tk listbox, or to return any error or other sign that Pd is processing the sent messages other than the sys_gui output bang. Though if I create the listbox again without first desroying it the Pd window returns an error that 'window name "lb" already exists in parent', as is proper. The same tcl used in commandline wish8.5 properly displays the listbox

I've tried to send some other tcl that properly displays Tk GUI widgets using commandline wish8.5 , and many of them fail in this same way, not only widgets using the grid command to display themselves. How do I get these widgets to work? Thanks for your insights.

http://www.pdpatchrepo.info/hurleur/sys_gui-test.pd

Howdy. Please find attached plugin~-test.pd , which demonstrates sending the message "plug gverb" to [plugin~] . I'm using pd-extended v0.43.4-extended on Ubuntu Studio 12.04 .

The Pd window indicates the message has been received by [plugin~] and has selected the GVerb plugin, but [plugin~] doesn't behave as if it has selected the GVerb plugin. There's no change to the signal passing through [plugin~] , and [plugin~] doesn't add the extra stereo in/outlet that GVerb instantiates, such as when creating [plugin~ gverb] with the creation argument.

Does [plugin~] take [plug <plugin_label>( messages dynamically only when the Pd GUI object remains visibly the same (eg. remains mono or stereo, depending on how it was created with an argument)? Is there some other way to dynamically set [plugin~] to use some other plugin? Thank you for your insights.

http://www.pdpatchrepo.info/hurleur/plugin~-test.pd

Attached is counter.pd , which implements an iterative loop. However it doesn't work as I expected. When started with the bang, the Count value inits to the Max rather than the Init value, and then counts down to the Init value.

I don't see how the Count value would decrease at all, since the only active operator is [+ 1]. And I don't see why the Count would not be inited to the Init value, or how it is inited to the Max value, or why its counting would stop at the Init value.

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

@mod said:

@Matthew said:

I haven't measured the difference between [ctlin]-[filter for cc] and [ctlin cc].

can you measure it and pass on the info?
if you can find a significant difference, then we might get the change you're asking for

What's the accepted benchmarking approach?

@mod said:

sorry for the uninformed intrusion,

but doesn't all midi input need filtering at some stage anyway?

Is there really that much difference in cpu usage if it's filtered at the C level inside an object, or at the abstraction level within the pd environment???

I haven't measured the difference between [ctlin]-[filter for cc] and [ctlin cc]. Maybe [ctlin cc] doesn't query the MIDI driver by cc, but itself filters for cc. But even if the latter, filtering downstream from [ctlin] (without a cc creation arg) means Pd has to transmit all MIDI data to whichever downstream objects filter it, plus the filtering.

In any case there's a problem with semantics, and hence maintainability, when the object can be created by GUI with a filter/query arg but dynamically the filter/query arg is unavailable. Dynamic patching would be a lot more useful if its API were identical to (or better yet a strict subset of) what's exposed to the patching GUI. Pd would be a lot less idiosyncratic, and own more of the simplicity from graphical patching that it claims.

@billystiltner said:

Matt, if you could figure out the particular ctlin's object number maybe you could use pdmsg somehow to change the ch and control # at runtime, I am getting ready to look into this to fix my problem with the $0

Thanks, I'll look into it.

@billystiltner said:

it seems that tcl has a special way to signify a literal

puts "$Z_LABEL $Z" ;# Prints the value of Z
puts "$Z_LABEL \$Z" ;# Prints a literal $Z instead of the value of Z

Yes, Pd has a lot of problems using metacharacters (including $, {, } and some others) in data - usually prohibiting them. It usually doesn't even allow them, but in this case it allows the (somewhat) integrated Tcl to do what most languages do: use the backslash \ as an escape to indicate to the runtime data processor that the following $ character is not a metacharacter, but a literal.

There is no quoting system, and not even strings - except some crude instances that aren't all the same thing, like comment objects (not exposed to the Pd API) vs messages vs anything data etc. I guess it's "pure data" in that it's "no metadata". The somewhat arbitrary limits to dynamic patching are because there really isn't any "metaprogramming" available (programmer makes a patch that does some programming, like create objects at runtime).

I wish Pd could treat a patch's objects and connections as data at runtime. But I also wish it used Javascript instead of Tcl, and a browser/DOM instead of Tk. The patch window (or even better, a purely virtual object, not a GUI, container of the patch) should have an addressable data structure of the patch, and objects should be readable/writable/creatable/destroyable at runtime through that structure. Maybe next time.

@billystiltner said:

Matthew, mke ctlin omni and filter out the ch, ctrl# you want after ctlin.

Yes, that will work but I try to reduce computation as much as possible. Pd is signal processing that is demanding of HW capacity, and some code I'd like to work on the tiniest HW (Raspberry Pi and smaller as they come out). Since [ctlin] takes a parameter at least filtering (if not actually selectively generating) for the specified control, I'd like to be able to select at runtime the control whose state it outputs. Plus the filtering approach clutters the patch, not just computation overhead but also it makes the program's logic less clear for ongoing revisions.

It seems that's not possible using Pd in its current state, so filtering is necessary. That's something to consider for revisions to Pd, since it should be possible. Dynamic patching should have available a more consistent model of the patch components and patches to make from them.

@sebfumaster said:

but again, other than that it seems like this list of floats is what agitato was trying to get.

Ah, the 4096 values the patch prints are indeed the directory sizes, and are what agitato was looking for. The [shell] docs didn't indicate it output line by line, just that it bangs the right outlet when complete. Yes, it does have some bug where it splits some lines, and it looks like it sends a 0, not a bang, to the right outlet when complete.

So your patch is the correct answer, and your [$n( filter on [shell] output is a good technique. How would you alter the test patch I attached earlier to pull just, say, the 3rd line output from [shell]? Or better yet, the xth line, as specified dynamically by the patch during runtime?

@sebfumaster said:

I ran it (well, with ls -a -l), it worked. agitato was asking for the 5th item in each list i think. shell outputs the lines as seperate messages.

I ran the attached patch and got first the "$5: argument number out of range" error agitato reported, then a series of "print: <float>" lines where <float> was a number, mostly 4096. I got several sets of those, probably one for each file in the directory being listed. What do you get?

http://www.pdpatchrepo.info/hurleur/ls-shell-test.pd

@sebfumaster said:

@Matthew said:

That won't actually work, since each multiword line from [shell] is a list itself; shell is outputting a list of lists, from which list #n is desired. There is no list of lists (of symbols) native in Pd.

why would "casting" as a list not work? the reason it's there is to put the list selector on in order to get the right element (the 5th) from $5 because pd recognizes the list selector.
the reason the error occurs is in the case when the fifth element isn't present, which some

logic would fix.
otherwise it works, but i'm still curious why it wouldn't?
Did you run it? Your patch doesn't work because [ls -al( returns a series of lines, each line a series of words. Pd doesn't recognize the newline delimiter, only the space delimiter that makes the whole output look like just one long list, that happens to contain lines. There's no structure in Pd to say "5th line" or "fifth list", just "5th atom in a list" at best.

Pd doesn't have data structures at all except for space-delimited list, whether of symbols or other atoms. It doesn't even have strings. It doesn't have any way to make more complex data structures, except the crazily complicated struct/template system that doesn't support runtime dynamic template construction, except perhaps by the ridiculous kluges for dynamic patching. Pd is a programming system, but it is not really a *metaprogramming* system, where runtime logic can change definitions. It's an object system with classes available for instantiation only by the programmer, not by the program.

That's why it's a pretty interesting music/performance system, but an extremely frustrating general programming system. Instead of "Pure-Data" it really could be called "No-Metadata".

@agitato816 said:

Additional Question:

[shell] object with AWK and Perl script also run under Windows or other OS?

No. [shell] just invokes the Linux shell separately installed in the Linux host that Pd is running in. The Linux shell is able to run awk, perl, or whatever else is installed on that host that the Pd user has permissions to run. None of them except [shell] itself is part of Pd. So if you don't have the separate awk, perl or whatever you call by passing to [shell] both installed and accessible by the Pd user, it's not going to work. Which is the case on any other OS other than Linux. Unless they do have awk or perl etc installed separately, which I believe MacOS does have (Windows doesn't by default have awk or perl, but it might be possible to install some version of them that [shell] can invoke). Some functions, like ls , are builtin shell functions, so [shell] has them builtin too.

You can check which actual shell Pd invokes by using
[echo $SHELL]
|
[shell]
|
[print]

@sebfumaster said:

[ls -al(
|
[shell]
|

|
[$5(
|
[whatever else (print?)]
That won't actually work, since each multiword line from [shell] is a list itself; shell is outputting a list of lists, from which list #n is desired. There is no list of lists (of symbols) native in Pd.

For something called "pure data", Pd has very crude and limited data structures. Especially if the data isn't numeric.

Maybe PDContainer, like some use of [h_multiset data] receiving the shell output, like: [ls -al]-[shell]-[h_multiset data] .

I would guess that you could write a few lines of Tcl to consume the keypress (by its code) in a Tcl plugin like the Triple-Click interceptor example. Unless that callback can't destroy the last copy of the keypress event, so elsewhere continues to process it. But it should probably be a fast Tcl coding session to see that it can't destroy the event.

@Matthew said:

Attached please find ccin.pd , which takes a float in its hot inlet specifying the MIDI control number, and an optional float in its right inlet specifying the MIDI channel (defaults to 1), and outputs the MIDI control's value from the CC message.

Attached please find a revised ccin.pd which outputs the MIDI control's value from the CC message. It takes an argument specifying the MIDI control number and defaults to MIDI channel 1. An optional float in its left inlet overrides its MIDI control number filter; an optional float in its right inlet overrides its MIDI channel number filter.

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

Thanks all for the tips. Including that demonstration of dynamic patch metaprogramming in ctlinn.pd .

Attached please find ccin.pd , which takes a float in its hot inlet specifying the MIDI control number, and an optional float in its right inlet specifying the MIDI channel (defaults to 1), and outputs the MIDI control's value from the CC message. Inside it wraps [ctlin] to filter for only the specified MIDI control/channel's value. So the complete channel/control#/value triplet can be gotten from the input messages and the output message, and packed into a list in the patch enclosing this patch if desired.

I do wonder how much extra resources this patch consumes in wrapping and filtering [ctlin], beyond what a hardcoded [ctlin 57 1] would consume. Mainly in MIDI latency, but also in CPU and possibly RAM, when considering running on constrained devices. Like if Pd could run right in a MIDI controller device, with one of these patches running on each of many controls.

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