Hans-Christoph Steiner wrote:
The part of this whole equation that is the problem is the name
clash. That's how this thread started. Frank said that if he had a
support lib with the same name as another Pd objectclass, then there
was a name clash.Loading a file that is not meant to be an objectclass is not really
problem, AFAIK, it just won't create an object. Oftentimes people
use this as a hack to load libraries.Since the core of this problem is name clashes, then why not use the
existing techniques for dealing with that? I think this discussion
is getting too abstract... I just this there already are far too many
file extensions in Pd, I have had to do extra work because of them,
and have yet to see the benefit. That's my two bits....hc
what I found out from reading franks emails is, that to run one lua script in pd, he sometimes also has lua scripts that are maybe included or referenced or needed to run that one script. and when he gives away a bundle which includes these scripts, then these additional scripts pollute the pd naming scheme. this is not so different to images that are shipped with a patch, you just don't expect that pd would try to open them. and according to franks mail, it obviously *is* a problem that externals don't open correctly anymore, but instead lua spits out an error that it can't load the object correctly (and does not try to look for another file with a *.pd extension instead). there are several suggested solutions right now:
the pd searchpatchs)
files. but then you search the tree 3 times.
scripts, just as pd does not try to load *.jpg files I think the pdlua programmer has to look at the pdlua specs anyway if she wants to write her own scripts, so the learning curve is not much steeper if the user has to learn "name the script in the following way so that it is accepted by pdlua. or you tell every user that in order to run a patch, she has to drag the lua files to a special lua-directory. marius.