Dear List!
Can I tell pd and WishShell to run on two different machines over a network? so i could separate gui and dsp tasks. on what port do they connect to each other? i work on win, osx and linux (but i don't mean X-forwarding) thanks!
Peter P.
Hallo, plessas@sbox.tugraz.at hat gesagt: // plessas@sbox.tugraz.at wrote:
Can I tell pd and WishShell to run on two different machines over a network? so i could separate gui and dsp tasks. on what port do they connect to each other? i work on win, osx and linux (but i don't mean X-forwarding)
Yes, run one with "-nogui" and the other with dsp turned off. Then connect them with either netsend/netreceive (build in) or use OSC (available on pure-data.sf.net)
ciao
Frank Barknecht _ ______footils.org__
On Wed, 5 Nov 2003, Frank Barknecht wrote:
Hallo, plessas@sbox.tugraz.at hat gesagt: // plessas@sbox.tugraz.at wrote:
Can I tell pd and WishShell to run on two different machines over a network? so i could separate gui and dsp tasks. on what port do they connect to each other? i work on win, osx and linux (but i don't mean X-forwarding)
Yes, run one with "-nogui" and the other with dsp turned off. Then connect them with either netsend/netreceive (build in) or use OSC (available on pure-data.sf.net)
Another possibility is to run the gui via rsh on the other machine, on the machine m1.upf.edu:
pd -guicmd "rsh m2.upf.edu /usr/lib/pd/bin/pd-gui 5400 m1.upf.edu"
If you have the rsh permissions setup, this should start the gui on m2.upf.edu and pd on m1.upf.edu.
( .. this may only work on Linux, OSX probably too ..)
GG.
I love hearing about these options I didn't know existed.
So in what way are pd and pd-gui _not_ seperated? This is always mentioned in the "max-pd-future-features-should-be..." discussions:seperation of gui and engine.
I am also wondering that if you control your patch with the gui, how useful it is to have the audio continue when the gui is frozen because of processor load.
curiously
Gerard
On Wednesday 05 November 2003 19:15, guenter geiger wrote:
Another possibility is to run the gui via rsh on the other machine, on the machine m1.upf.edu:
pd -guicmd "rsh m2.upf.edu /usr/lib/pd/bin/pd-gui 5400 m1.upf.edu"
If you have the rsh permissions setup, this should start the gui on m2.upf.edu and pd on m1.upf.edu.
( .. this may only work on Linux, OSX probably too ..)
GG.
On Thu, 6 Nov 2003, vanDongen/Gilcher wrote:
I love hearing about these options I didn't know existed.
its not really an option or feature, its an exploit (that could be turned into an option, I agree)
So in what way are pd and pd-gui _not_ seperated? This is always mentioned in the "max-pd-future-features-should-be..." discussions:seperation of gui and engine.
never said that. not everything that comes up on the list true, you know .. and then, most of the time truth does not exist, especially with software, because we only try to describe things in words that we can understand, but that do not have an exact meaning.
e.g what means separated ? how could a GUI communicate with the engine when they were not connected ?
its probably better described as "separating GUI and engine more", e.g. through asynchronous communication
I am also wondering that if you control your patch with the gui, how useful it is to have the audio continue when the gui is frozen because of processor load.
definitely a frozen GUI is not useful. But with the GUI a little stuttering may not be noticeable, whereas with the sound it is .. well, most of the times at least
(Gosh, I should really stop reading these Prattchet books)
Guenter
curiously
Gerard
On Wednesday 05 November 2003 19:15, guenter geiger wrote:
Another possibility is to run the gui via rsh on the other machine, on the machine m1.upf.edu:
pd -guicmd "rsh m2.upf.edu /usr/lib/pd/bin/pd-gui 5400 m1.upf.edu"
If you have the rsh permissions setup, this should start the gui on m2.upf.edu and pd on m1.upf.edu.
( .. this may only work on Linux, OSX probably too ..)
GG.
-- electronic & acoustic musics-- http://www.xs4all.nl/~gml
Hallo, vanDongen/Gilcher hat gesagt: // vanDongen/Gilcher wrote:
I love hearing about these options I didn't know existed.
Some more options that come to my mind: Run Pd in a VNC environment. Yes, this does actually work. Or you could run the GUI over the X protocol on a remote Xserver. Or run the GUI local, but a streaming Pd (with e.g. oggcast~) on a remote machine. Or use something like PDSender (Perl or Python version on http://www.pure-data.org/community/patches) as a GUI (with only little "G")
All this actually do not "really" seperate GUI from DSP, but they kind of replace Pd's main GUI with another one (in some cases with the GUI of another running instance of Pd).
ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
guenter geiger -
plessas＠sbox.tugraz.at -
vanDongen/Gilcher