[PD] hex loader

Mathieu Bouchard matju at artengine.ca
Thu Nov 29 04:05:39 CET 2007

On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote:

> i don't like matju's suggestion to provide an API,

Ideally, hexloader should be merged into the core and the API would be a 
single function shared by the loader and the parts of the internals that 
do the same thing as the hexloader does (the symbol mangler).

I'm not really advocating that an external exposes an API otherwise than 
as pd objects and methods... but then, this is also what Gem need to do if 
some externals are not linked directly into Gem... so it must not be that 
ugly. GridFlow will also have to do it eventually. I just think that doing 
it for one function is a waste.

Anyway, because virtually the same code is already in the core, it makes 
sense to have that shared function in the core, so the issue of linking to 
an external should be moot.

> as this would require to have hexloader be loaded before all other 
> externals that rely on that API.

Not if the linker knows about it. (The problem is how to tell the linker 
about it)

> what might be a better solution is to tell Pd to try to load a different 
> class instead (kind of recursively calling the loading stuff).

I don't understand.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

More information about the Pd-list mailing list