Hi, it's true that the current loader hook has designed for libs only. I've also thought about introducing an additional object loader, which should then also be able to draw its patcher text from an external source (like from the web, or from a database), but that's hard because of the way how pd currently loads and creates the objects.
oops, wanted to write more, but no time.... all the best, Thomas
IOhannes m zmoelnig schrieb:
hi miller, all.
i am currently having troubles implementing the hexloader as a system-loader. while things work rather straightforward in external/library land, it stops being trivial when it comes to loading abstractions via a system-loader. (this is needed since the hexloader mainly applies a different objectname<->filename mapping, which should eventually work for abstractions too)
the problem is, that in the context of the loader, i have no idea about the arguments for the object instance. unfortunately abstractions do not have the "abstract class" vs "instance" separation like binary objects, so the only way to instantiate them seems to be to directly evaluate them with the arguments available in some "context".
ultimately it would be good if patches would be loaded with the same mechanism as other externals within the pd core (this is: with a separate patch_loader() that is registered just like the lib_loader())
a temporary workaround would be some way to access the arguments passed to a yet-unknown object from within the loaders.
mfasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev