I already figured out the routing that was the easy part.

I just used a [throw~] that gets it's catch~ from a send (id-out) so to connect id 5 to main-out, which is 16 (the volume knob,) I just send 16 to 5-out. I have it sending 16 to all the outs now, on-load, but eventually I imagine that you could chain modules (whoever is closest to 16 is the endpoint.) This part works really well.

The problem I am having is that it's not fast enough to poll every single module on update of every other module. It makes the whole system herty-gerty. I feel like with some clever trickery I could be more efficient about it, but I just can't figure it out in pd-only. I was thinking I might need to modify TuioClient to get it working fast (maybe send a "who is closet to me" & "who is closest to center" message on update?

Here's what I have:

I just had some little ideas that make the logic a little smoother, and make it easier to just do graphics, or just sound, or add/remove definitions of instruments & graphics.

Just open main.pd to check it out. I included the shell script I use with it (in Linux) to start it up in fullscreen.

You will need hid_invert from the hid lib (should be in extended.) My example uses gem, and renders the graphic opposite for my projection system. If you want to change that, go into gfx_base and add a hid_invert between the receive and the math before it goes into translateXYZ. You could also just delete the main_gfx, if you don't want it to do gem stuff.

Marker 16 is the volume knob, and the others that do something are defined in the main_ patches in main (main_snd, main_gfx, main_network) right now it's all little white squares that are either osc's or phasors. You can see how easy it is to make your own, in main_snd and main_gfx.

The whole thing runs really fast and smooth on my setup.

http://www.pdpatchrepo.info/hurleur/dktable.tar.gz

Pd-0.39.2-extended-rc2 released!

http://at.or.at/hans/pd/installers.html

After a long pause, it's time for another release. That means Release Candidate 2!! Almost there! Yes, there are a couple known bugs, and most definitely unknown bugs. Let's find them and make a final release!

* Bitstream Vera Sans Mono is now default font on Windows and GNU/Linux
* Bitstream Vera Sans Mono is included in the Windows installer
* Monaco is the default font on Mac OS X
* fixed GUI size, should actually be the same size on all platforms now
* pdp and pidip should support quicktime/mjpeg/png and theora now
* pdp_ieee1394 included on Mac OS X
* the Mac OS X package looks much better, thanks to Steffen <stffn@dibidut.dk>
* default preferences are embedded into the Pd.app on Mac OS X
* revamped font flags and added '-font-weight' flag

A couple of known issues:

* it's still missing Gem font support on Mac OS X
* the delread~/sqrt~ bug is still not fixed

Test away and file bugs in the bug tracker!

http://puredata.org/dev/bugtracker

.hc

I finally succeed installing my demudi for working with pdp/PidiP,
here my config

1. install the demudi

2. edit the /etc/apt/sources.list ,make it looks like that:

deb http://demudi.agnula.org/packages/demudi/ demudi main/updates
deb http://ftp2.fr.debian.org/debian/ testing main contrib non-free
deb-src http://ftp2.fr.debian.org/debian/ testing main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://www.os-works.com/debian/ testing main
deb http://sindominio.net/~caedes/debian/ unstable main
deb http://ftp2.fr.debian.org/debian/ unstable main contrib non-free
deb http://apt.cerkinfo.be/ unstable main contrib

3. run synaptic
4. search for pdp, then install

It works pretty nice, i am into search of the better compromise between quality, low cost of process codecs. For now, i have good results with AVI in in IYUV codec and the undocumented [pdp_xine] object:

1st inlet:
[open namefile.ext< open a file
[bang< print a frame
[loop 0/1< loop mode
[n< go to frame n and play
[speed n< n x the speed of the original file

2nd inlet:
? it get floats, it seems to make the video jump to the next KeyFrame... not sure.

Running pd on the mac has upsides and downsides...

I use both. The PC is handy for running wierd stuff like the VST~ objects, but my mac has better audio support, plus its a laptop so its more handy for gigs etc... An added bonus is my mac doesn't sound like a harrier jump jet, unlike the fan on my PC. However, the PC does keep my feet nice and warm under the desk at this time of year.

Sad to say it, but the mac actually crashes more often than the PC now days, something i never thought i would find myself saying

As for running linux on the mac, you could run a linux build with a nice GUI, however, having tried the mac-linux install myself in the past I wouldn't recomend it unless you really know what your doing and don't mind messing about with various bits of your mac's built in kit (especialy wifi cards) for a few weeks to get the damn things to work...

Well, running VST isn't actually a problem on OSX, apart from in LOGIC, That I agree was a bloody minded attempt for apple to abuse it's ownership of emagic and jump start a new format.
But, as a format AU is actually much better in the long term. The main difference to me is that a VST effect is never truly mono, when you add a vst effect to a mono channel its just becoming mono again at its output stage, so in effect (no pun intended) it is processing all mono sources twice, which is a waste of cpu time for whenever you are dealing with mono inputs. If you take a look at the difference in CPU load in Logic when using a mono pluggin compared to a stereo one it is fairly big now, whereas in the old logic the difference between mono and stereo VST's was quite minimal.