Losing links to the old forum is a disaster ... That was a huge resource. Why not "freeze" it but keep it available for searching and access via whatever URL's folks might have saved for themselves. I know I have a lot.

For those interested in communicating between Matlab and pd using OSC, the following link should be very useful:

http://stackoverflow.com/questions/17077364/communicating-between-pure-data-and-matlab-using-osc

The weird problem the original poster describes seems rather specific to their system, but about 1/3 of the way down there is an answer with a wealth of good material including Matlab/pd client/server examples, links to the sources for osc-mex, compiled 32- and 64-bit Windows mex files, and compilation instructions.

I decided to try this, and was delighted that it worked:

If arbfunc~.pd is

[$1 $2]
|
[outlet~]

then you can successfully use it like

[arbfunc~ osc~ 1000]

or

[arbfunc~ phasor~ 100]

I assume this power should only be used for good.

In the following patch, when I [bng] manually, the vline~ and tabwrite~ start exactly at the same time, as desired, but when I turn on the [metro], the start of the vline~ is randomly delayed (by up to one block, I'm guessing).

What's going on?

Replacing the vline~ with line~ and the appropriate input messages eliminates the start time problem, although line~ appears to round the duration of its ramp down to the nearest block.

[bng] [tgl]
| |
| [metro 500]
| /
[t b b]
| |
| [0, 1 2(
| |
| [vline~]
| /
[tabwrite~ array]

When I first create an array and tabsend~ or tabwrite~ a signal into it, it is plotted with a bold line. If I close and re-open the patch, the line is now only one pixel wide. (XP and Win7, 42.5 and 43.4)

Is there some way to control the line width (or colour!) ? That would be very handy for distinguishing more than two signals (using points or polygons) and making plots easier to see at a distance.

Is anyone successfully using earplug~ from pd extended 0.42.5 ?

On both Windows and OSX, earplug~-help.pd is clearly not doing the right thing. The HRTF-filtered noise sounds lowpass- and comb-filtered, and undergoes multiple extreme amplitude variations, but nothing sensible in the way of perceived location changes, as the azimuth parameter is varied.

Any trick to getting this working? Thanks.

In a student activity I recently devised (characterizing filters and entering the measured values into a spreadsheet), I seem to have discovered a bizarre interaction of pd (extended, 0.42.5) and MS-Excel (2007 or 2010 versions) on Windows XP and Win7.

Namely, after a period of normal operation, the spreadsheet will become sluggish or freeze entirely. This is resolved immediately if pd is closed, and it happens with the console window alone; no patch needs to be opened, and no interaction like cutting and pasting between programs is necessary to make it happen. I have reproduced this behavior on several XP and Win7 systems.

Has anyone else experienced this, and can anyone offer an explanation?

I am working on a patch to get data from a Polhemus Fastrak motion tracker.

It returns serial records of the form:

"01 9.44 -0.75 -0.62 -40.90 15.74 29.96"

in which the orientation angles are the last three values. The azimuth value, for example, is always in characters 25 through 31, so I am extracting it like this:

[ list of char bytes(
|
[packel 25 26 27 28 29 30 31]
| | | | | |
[sprintf %c%c%c%c%c%c%c]
|
[value \

which puts the correct value, -40.90, in the number at the bottom.

This works fine, but is there a better way?

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

Just discovered an error in my patch.
Please replace [tabread~ spectrum] with

[r tick]
|
[tabplay~ spectrum]

Otherwise the accumulated spectrum "signal" is not in sync with the new one.

The mrpeach externals have [udpsend~] and [udpreceive~]