Guenter,
I like the externals, as it gives me the possiblity to experiment more while programming.
It should be well thought over what goes into pd and what does not, as people consider objects in the main distribution as "fixed" and should be able to rely on their behaviour ..
Therefore I would leave complex objects like fiddle, bonk, paf out of pd, and putting the basic ones in (expr would be my favorite here).
I certainly agree here and that was sort of why I suggested what I did. The idea that most of the high-level functionality of PD is contained in external objects is appealing because it offers so much flexibility. By packaging PD and a bunch of externals together into some sort of distribution you get the convenience of everything included for those that just want to use the program and not fiddle around with it (sorry) but give the rest of us the freedom to change a lot (not that I want to or feel up to replacing fiddle or bonk . . .).
As to including graphical objects. The ggext graphical objects are currently not really fit to go into pd as they are.
(But meanwhile I know how I would code them inside pd)
What I would like to see is a layer over the graphic routines, which would make it possible to port pd to other GUI libraries easily.
This should be easy as code used for graphics is still small.
This sounds nice - I have been experimenting with a GTK+ replacement for pd-gui and have been thinking about the best way to paste it onto pd. Of course the current TK canvas commands are pretty generic (draw a square here, line there, etc.) and could easily be converted to another GUI. Maybe just layer that can be called directly for similar drawing commands that could handle the socket communications instead of using the sys_vgui function. If you could post some more specifics - I would certainly like to know what you had in mind.
Karl
| Karl W. MacMillan | | Peabody Institute of the Johns Hopkins University | | Network and Telecommunications Services | | karlmac@peabody.jhu.edu | | 410/659-8297 |