Hans-Christoph Steiner wrote: > Hey all, > > So for the Pd-0.40.3-extended release, I am planning on trying to > make the internals available as a library like any other. I'd like > this work to be applicable to pd-vanilla, so I'd like to discuss how > to make it happen.
cyclone does something like this (it overrides already registered externals, which - at this point - are not different from internals) it is basically looking whether the class-name is already registered, and if so, overwrites the class-pointers. however, for this to work, you need first need to call a function in your overriding new library. therefore you will probably need something like a "library" (instead of single, same-named externals) > > I was thinking of just breaking out the classes into their own files, > then compiling things as a libdir. This is pretty easy for most of > the objects, but I haven't gotten into the DSP classes yet, and I > expect things will be more complicated there. And [list] too. funnily enough i have always been opposed when requesting that the [list] objects get _proper_ names. > > One of the things I am planning on doing for the tkwidget library is > making it have a shared libtkwidget.so which each of the object > classes uses. Then each objectclass will have its own file, but they > still will have shared code. If this works out well, I think it > could be a model for Pd libraries in general. well, i don't see a reason why it should not work well. the biggest problem is probably to find a way where the objects will search for the search-lib (if you don't want to put it into a standard place like /usr/lib/ or /usr/local/lib) fmasd.r IOhannes _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
