[PD-dev] overriding "internals"

Hans-Christoph Steiner hans at eds.org
Sat Nov 10 16:53:38 CET 2007


On Nov 10, 2007, at 3:55 AM, IOhannes m zmoelnig wrote:

> 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'd rather not use a special mechanism, especially if it is not  
already widely used.

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

Why?  For example, [list append] will happily append a symbol to a  
float, so the "list" part doesn't seem so accurate.  Why not just  
[append]?

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

The libtkwidget.so would be included in the libdir to make it a  
simple package.

.hc


------------------------------------------------------------------------ 
----

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie







More information about the Pd-dev mailing list