x7 writes:

dont know, toys work well as externals as well as do ggexts (+ othrs.), maybe put effort into distribution/collection/editorial/coordination of xtrnls + ~/.pdrc's which loads all exts 4 me and rather keep 'pd' (core program) as min 2 max alohe

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

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.

Guenter

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 |

Karl MacMillan wrote:

I cannot open externals from ggext (or I presume any other set of externals compiled into a single object file) without putting a dummy ggext object on the page. I know that this was discussed before, but there was no resolution that I remember.

there is one solution :: using the "-lib" flag

There are two solutions that I see: compile externals into individual files for each object or have a folder like Opcode Max that holds externals that are loaded at startup. It seems that the first solution is easier and it is more intuitive to the user (you can see what objects are available by looking in the folder rather than having to remember what ggext contains). I don't think the dummy object is acceptable - the point of me doing this is to make things integrate seamlessly.

to me it looks more elegant, just to create one library file than to split up thousands of tiny ones, just imagine GEM. Of course this might be discussed, still. (some times ago it was hard to create proper ~-objects that would load correctly. It was then, i decided to make a big external to work around this problem, but:: i think miller fixed this in pd0.26 or so, so it should be no problem any more) Then some objects are really linked, such as streamin~/streamout~ (note: i know that they don't work at all in the zexy external), or like guenters slider, toddles etc.; these should really be loaded at the same time...

as i indicated previously, i would highly recommend to create something like the "package require" in jmax. this would fix the problem with the dummy objects; maybe there could be a kind of "library objects" (in opposition to the command-line based jmax); but i am too lazy to do it myself

The zexy externals will not compile for me - make says "makefile:4: *** commands commence before first target. Stop." I started to hack on the makefile, but thought I would see if I am missing something obvious first. Any ideas?

i cannot reconstruct this problem, for me it works fine on Win95, WinNT and linux:debian; i haven't tried irix but maybe there are some <space>s at the and of the line ?

sfplay on linux seems to require absolute paths though the help file seems to imply that it will look in the current directory first (haven't checked NT yet). Is this is a portability issue or am I just making a wrong assumption?

again i cannot reconstruct this; here on debian it works fine with relative directories (personally i haven't tested it on NT, but i hear that it did a half-year installation very well on this os)

mfg.fdsa.dfs hannes

by the way:: i checked the linux-version of zexy and cleaned it a little bit up; there WERE some quite dirty messages when compiling (though no errors); i hope i could fix the time object too, although i still get the wrong local time on my machine (on NT/95 it works); if you have this problem too (or not), i would be pleased to be informed

Karl -

I think that is an excellent idea. RPM seems to be a pretty standard package, and debian users can use alien to convert to a .deb. I suspect that PD users are more likely to use non-intel processors than the "average" linux user, so binaries for Alpha and PPC are probably a good idea.

On Wed, 2 Feb 2000, Karl MacMillan wrote:

Well, from the response to this so far and from talking to my colleagues that are interested in PD but still haven't taken the plunge, it seems that nice integrated, ready to go binaries with all the goodies would be welcomed. Perhaps what is needed is someone to compile all this stuff for all the platforms into, to use the linux jargon, distributions. As I have access to linux and windows with compilers and should have access to an O2 soon (and have the time), I would be happy to do this if people are interested. This way the individual packages can continue to be mantained by their authors and released according to their own schedules, but end users can get everything they want. Let me know.

| Kevin Baird | kcbaird@world.oberlin.edu |
| http://www.acsu.buffalo.edu/~kcbaird |

In a previous life, I was an inert scattered mass of organic compounds.