On 04/23/2013 02:26, Jonathan Wilkes wrote:
I cannot figure out where the code is,
externals/loaders/hexloader/
but I'm assuming there is a loop that goes through each path in search of $object_name.$whatever to load the setup routine, and then goes through each path for $object_name.{pd, max} for loading abstractions.
yes kind of.
Is this the case? If so why not say for each directory, check if there is a $directory-meta.pd, and if there is parse it to find a comment in the form of: ALIAS normal_characters_name weird_characters_name1 weird_characters_name2 etc.
sounds like a good idea, though....
Then if $object_name matches any of the atoms that follow ALIAS, look for any files inside $directory that match any of the aliases. If you find a match, follow the current loading logic (i.e., look for $objectname_setup, etc.). This has the benefit that the external/abstraction developer doesn't have to care about what order to put the atoms after ALIAS, only that one of the atoms uses "normal" characters that correspond to the characters of the filename (minus the file extension) that contains the class/abstraction.
i'm pretty sure there is a catch somewhere when it comes to loading abstractions.
Finally, if there was a match, and there was a $normal_characters_name_setup that was executed without error, then Pd should automatically do a "class_addcreator" for each of the remaining aliases.
not sure whether this should be handled automatically or explicitely within an external.
I suppose its easier to require $1 of the "ALIAS" comment to be normal_characters_name. I think it's better for the external/abstraction author if it can be an unordered list, but honestly anything is better than the current hexloader complexity.
what's that "complexity"? having to have to look up some characters in an ascii table?
If someone can explain to me where the loop is in the source code where Pd looks for binaries/abstractions, I'll try to code it myself.
just check the various loaders in externals/loaders/
gmdrs IOhannes