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