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 ... ;)