[PD-dev] overriding "internals"

[IOhannes m zmoelnig]

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