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.