hi again,
this message is a response to Christian Klippel's post about jmax architecture :
i never said jmax was not client/server oriented BUT it's quite different :
in jmax, the audio engine [fts] acts as a server, the GUI is the client and is currently written in Java. ---> it's audio server oriented.
in PD, the audio engine is the client of the GUI server, objects are executed in the audio engine and can only send drawing orders to the GUI, not do graphics by themselves. ---> it's GUI server oriented.
Consequently, it would be hard to make a GUI for both JMAX and PD, the code is not executed on the same side.
-- i'm afraid i'm not too clear
bye,
yves.
hi yves, hi list,
Am Mittwoch, 24. April 2002 19:22 schrieb Yves Degoyon:
hi again,
this message is a response to Christian Klippel's post about jmax architecture :
i never said jmax was not client/server oriented BUT it's quite different :
sorry, didnt meant that you said it would not be ... ;-)
in jmax, the audio engine [fts] acts as a server, the GUI is the client and is currently written in Java. ---> it's audio server oriented.
right ....
in PD, the audio engine is the client of the GUI server, objects are executed in the audio engine and can only send drawing orders to the GUI, not do graphics by themselves. ---> it's GUI server oriented.
ok, lets see if i got it right : the pd-gui starts up, it then starts the audio-engine, which will then send drawing commands to the gui ? i.e. the drawing instructions reside in the audio-engine ? so, the gui is then only a canvas where the objects draw on ? if so, it would mean that even if the gui would run on a second machine, that the audio engine still has to issue the drawing commands, thus taking away cpu time from the audio process .... are the objects (externals) loaded in the audio-engine or the gui ? would be curious if it is the latter.
Consequently, it would be hard to make a GUI for both JMAX and PD, the code is not executed on the same side.
well, i think not. even with these differences. i mean, if it is only about drawing lines, text, etc. the (new) gui can be equipped with some drawing functions to achieve that. since it will be programmed in c, there could even a (stripped down) tcl/tk interpreter integrated, which translates tk-commands to the native c-drawing-functions of the toolkit ..... it doesnt really matter if the gui just gets a command "put object bla at position x,y" or if it get commands like "draw a line from ... to ..." to draw the object with primitives.......
moreover, with such a "unified" gui it should be possible to pipe the dataflow between pd and jmax, thus easily connecting them together (if this would make sense is a seperate question ;)
-- i'm afraid i'm not too clear
bye,
yves.
me too ;-)
have a nice day,
chris
ok, lets see if i got it right : the pd-gui starts up, it then starts the audio-engine, which will then send drawing commands to the gui ?
right....
i.e. the drawing instructions reside in the audio-engine ? so, the gui is then only a canvas where the objects draw on ? if so, it would mean that even if the gui would run on a second machine, that the audio engine still has to issue the drawing commands, thus taking away cpu time from the audio process ....
yep, that's why in case of a big and greedy update, you have to start a thread for sending graphic commands.
are the objects (externals) loaded in the audio-engine or the gui ?
in the audio-engine for PD, and in the gui for Jmax. That's a real big difference.
well, i think not. even with these differences. i mean, if it is only about drawing lines, text, etc. the (new) gui can be equipped with some drawing functions to achieve that. since it will be programmed in c, there could even a (stripped down) tcl/tk interpreter integrated, which translates tk-commands to the native c-drawing-functions of the toolkit .....
yes, it could, but when used for jmax, it should allow native drawing as well which really means it would have 2 modes. it's not impossible, just doubles the work.
good luck anyway.
yves.
hi yves,
Am Mittwoch, 24. April 2002 20:27 schrieb Yves Degoyon:
are the objects (externals) loaded in the audio-engine or the gui ?
in the audio-engine for PD, and in the gui for Jmax. That's a real big difference.
well, _thats_ the point of misunderstanding here, i think. in jmax, no external is loaded into the gui (except for gui-objects) in you prev. posting you wrote :
in PD, the audio engine is the client of the GUI server, objects are executed in the audio engine and can only send drawing orders to the GUI, not do graphics by themselves.
so, it is actually pd's audio-core whose objects have to do the drawing stuff ! in the case they send drawing orders, they _do_ the graphics themselves !!
in jmax, the externals are also loaded into the fts server, _not_ the gui !! a jmax object can have two parts : one part in c, for processing etc. and it _can_ have a seperate java part (like the slider, switch, ...) which represents the object in the gui. the c-part (loaded in fts) does not know anything about graphics, its representation, etc. all this is done _only_ in the gui. one might get confused by the fact that the gui is "loading" the externals. in reality, it only instructs the fts server to load that. except for gui objects, where the gui loads the java part as well.
- booth parts, java and c, are completely seperate ! *
however, im still looking forward to start that gui project someday, and i will try to make it usable for many apps, not only jmax .... and, since that all is c++ (the qt lib, i mean) it shouldnt be a big problem to extend it for other apps as well .... we will see ...
greets,
chris
hi,
in PD, the audio engine is the client of the GUI server, objects are executed in the audio engine and can only send drawing orders to the GUI, not do graphics by themselves.
so, it is actually pd's audio-core whose objects have to do the drawing stuff !
gee !!! i don't understand this. why "have to", then simply don't, they just send orders.
in the case they send drawing orders, they _do_ the graphics themselves !!
sending an order is __not__ doing native graphics like jmax externs.
in jmax, the externals are also loaded into the fts server, _not_ the gui !! a jmax object can have two parts : one part in c, for processing etc. and it _can_ have a seperate java part (like the slider, switch, ...) which represents the object in the gui. the c-part (loaded in fts) does not know anything about graphics, its representation, etc. all this is done _only_ in the gui. one might get confused by the fact that the gui is "loading" the externals. in reality, it only instructs the fts server to load that. except for gui objects, where the gui loads the java part as well.
- booth parts, java and c, are completely seperate ! *
good, that makes things clearer ( i never looked into jmax code ), but this confirms what i said from the start : jmax's externs do native graphics, pd's externs can't.
there's no contradiction along all this thread, just misunderstanding about what is "doing graphics", to me, it's something like calling "java.awt.LightweightDispatcher.processMouseEvent" or the like in another graphic lib.
thanks for your enlightments on jmax externs
cheers,
yves.
-
Christian Klippel -
Yves Degoyon