AW: [PD] pd-gui wishlist

[Christian Klippel]

hi yves, hi list,

Am Dienstag, 23. April 2002 22:16 schrieb Yves Degoyon:
> a/ i was speaking of loosing client/server feature<br>
> if one's intended to write externs in Java<br>
> which would handle their graphics by themselves :<br>
> this approach is not feasible because of the overhead<br>
> introduced by the graphics that you would embed in PD itself.<br>
>     <br>
> you NEED to have a protocol between PD's real time engine<br>
> ( e. g. process named PD ) and the graphical server.<br>
> this protocol for now consists of Tcl/Tk scripting commands<br>
> ( which says : draw an image, draw a rectangle ),<br>
> Java CAN'T do that AFAIK.<br>
>     <br>
> if it can, good, but it still would be very slow ( try jmax on a large
> scale ).<br>

hmmmm ..... maybe i should say something here in regards to jmax, client/server
and java.
first, jmax is _perfectly_ client server ! jmax as whole consists of two (or more)
programs : first, fts, the core. this is written purely in c, does the dsp stuff,
graph handling and i/o. next part is the java/swing gui, which communicates
to fts via network. you can easily start fts on one machine and the gui on 
another. also, the gui is responsible to set-up the fts kernel (instruct it to
load packages, setu-up the system, etc., while the latter is done now
with normal patches, instead of a config file)
well, its clear that the graphic side of java is weak. the awt toolkit only provides
rudimentary functions, and swing is so slow because it does all its own.
and since java is still an interpreted language (even with the compiled byte code)
it is naturally slow.
i think one advantage of jmax is the fact that the patch representation is completely
up to the gui. the server (fts) doesnt care about how a object box, slider, numbox
etc. looks like, it doesnt even know. so there is more process time left in the kernel
for dsp processing, and not to handle graphic commands.
since some time im thinking about a new gui for jmax (and maybe pd too?) designed
in qt. qt is multi-platform too (win,linux,osx,handhelds), fast, and has one great
advantage : its paradigm looks a little like that of a patche. every object can
emit signal, which are connected to other object's slots. using this it would be
easy to create complete "gui-only" objects, like sequncers, gui's, etc. which
then connect to the to a "real" outlet to be connected elsewhere ....
(i think you get the idea what i mean here)
since this can be run on a completely different machine (or processor, or task)
it wouldnt take away much resources from the dsp process .....

as said, im currently in the planning phase, qt3 is out now and has become somewhat
faster, so it all looks promising.

any help & ideas are welcome, esp. in making it universal for jmax and pd ....

greets,

chris

btw: yves, could you send mail as plain text, please ?? html often looks so
ugly when shown as pure ascii ... ;)


-- 
visit me:
http://mamalala.de - jmax audio related
http://video.mamalala.de - jmax video related
irc.openprojects.net - channel #jmax