For example: One computer running a complete pd instance with the gui and physical controllers, the other running a (-nogui) pd doing the "work", and both instances communicating via OSC.

Would that work (well)? (well, this scenario would also make sense on Dual Core processors, isn't it?)

Best Urs

IOhannes m zmoelnig schrieb:

Miller Puckette wrote:

...

I've done it once. You have to do something like: pd -guicmd "ssh myothermachine pd/bin/pd-gui 5400"

after fixing ssh not to prompt for a password (for instance by using the "ssh-add" mechanism).

Probably will take a fair amount of fooling around to get working.

note however, that the pd-gui task is relatively small compared to the pd-core (a lot of gui-stuff is really evaluated in the pd-core). so your performance gain might not be as big as you think when running pd and pd-gui on 2 separate machines. it should however be useful if you want to run 2 instances of pd on different machines and control them separately (this is: not with [netsend]/[netreceive]) from one monitor/mouse/keyboard - like 2 applications.

mf.adsr. IOhannes

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Thanks IOhannes,

that's what I wanted to hear during a few recent threads concerning dual core processors ;-) Urs

IOhannes m zmoelnig schrieb:

Urs Liska wrote:

...

For example: One computer running a complete pd instance with the gui and physical controllers, the other running a (-nogui) pd doing the "work", and both instances communicating via OSC.

Would that work (well)? (well, this scenario would also make sense on Dual Core processors, isn't it?)

definitely.

we use such approaches for most of our CPU-hungry applications (like the CUBEmixer), although we don't use OSC but netsend/netreceive: less processing overhead involved at the cost of non-compatibility with other appications

we even use this on single-processor machines: the "number crunching" pd -nogui runs with "-rt" and a quite low latency whereas the gui runs with a lower priority. whether the physical controllors are attached to the gui or to the dsp is a matter of design.

mfg.asdr. IOhannes

Frank Barknecht wrote:

Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

...

we use such approaches for most of our CPU-hungry applications (like the CUBEmixer), although we don't use OSC but netsend/netreceive: less processing overhead involved at the cost of non-compatibility with other appications

Acutally I did this the other way around: I was forced to use OSC instead of netsend because netsend stalled one of the two Pds running, threw it off the jack graph and did other nasty things. So I just

interesting and good to know. thanks

however, there was one reason a forgot why we used netsend instead of OSC: it is built-in...

mfg.asdr IOhannes

Hallo, geiger hat gesagt: // geiger wrote:

On Sat, 1 Jul 2006, IOhannes m zmoelnig wrote:

...

...

Acutally I did this the other way around: I was forced to use OSC instead of netsend because netsend stalled one of the two Pds running, threw it off the jack graph and did other nasty things. So I just

interesting and good to know. thanks

however, there was one reason a forgot why we used netsend instead of OSC: it is built-in...

OSC and netsend 1 should not behave differently. If this is so, then there is something wrong in netsend. Did you use netsend with UDP ?

Yes, I tested both UDP and TCP, but mostly was using UDP. There was a longer thread regarding my problem a while ago - I guess it was here, may also have been on pd-dev. I'm conviced that there is something wrong with netsend, as Roman Haefli and also Georg Holzmann reported similar problems with netsend in that thread. IIRC Roman is using netserver instead, Georg fixed it by not running two instances of Pd.

It may only happen if you have to send much data. I also only run one Pd, the receiving one, in -rt mode. So the setup was this:

1. GUI-Pd with Gem, noaudio, non-rt
2. Audio-Pd without Gem, with audio, -rt, with or without GUI (didn't

matter)

After a short while I got terrible timing problems with the Audio-Pd, including stuttering etc. If running with Jackd there also were Jack underruns, and often jackd killed itself or dropped the connection to Pd.

Similar things happened with -oss or -alsa. As I said, using OSC instead of netsend fixed that issue (I still have this little abstraction which acts as the network bridge and which can be switched between sending over netsend/UDP or OSC.

Note that the symptoms happened on both my laptop and on my home machine.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

carmen wrote:

...

After a short while I got terrible timing problems with the Audio-Pd, including stuttering etc. If running with Jackd there also were Jack underruns, and often jackd killed itself or dropped the connection to Pd.

however you dont _need_ netsend to do this. i pretty much gave up playing with GUi widgets wen PD was connected to the jack graph, since a burst of traffic can usuaully get it kicked out of the graph _and_ get pd killed by its own watchdog.

but we all know single-threaded design is bad, and its not like i can code C without turning an uninhabited island to Segfault City, so i'll be quiet. :)

[netclient] uses a new thread for each connection. Maybe it would work better...

Martin