[PD-dev] sysloader problem

[Thomas Grill]

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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
>   

-- 
Thomas Grill
http://grrrr.org