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.