Roman Haefeli wrote:
pd-extended: extra/zexy/abs~.pd_linux: 'abs~' can be called by [zexy/abs~] pd-vanilla: extra/zexy.pd_linux: [zexy/abs~] doesn't work
I really want to avoid ever writing [zexy/abs~] as an object. if I wanted to explicitely use a certain version of abs~ then it should be included by [declare -lib zexy/abs~] but I think this would not work in vanilla either. well, it cannot work in vanilla, because vanilla does not ship with zexy. so, what you are saying is, [declare -lib zexy/abs~] does not work on everybody's system. but then, people who run a home-brewed pd-version other than pd-extended will see the error on their console and hopefuly know what to do. they would have even worse problems, if they did not get an error and were using the wrong abs~ (although I cannot think of another behaviour for abs~). my idea is really that all objects can be created with [classname] without prefixes. then we only have to worry about nameclashes.
what is the current policy with abstractions vs. externals? which one are picked first?
not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason.
i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
what are aliases? and what are multiple-class-per-externals? do you mean the bundled libraries or the split-into-separate-files libraries
[mux] is an alias od [multiplex]. currently [mux] can only be instantiated when a [multiplex] has been instantiated before. which means that aliases are not fully supported by the libdir format.
yes, maybe there is a chance to include this information in the metafile? although this would mean a lot of extra work. in general I am *for* aliases, because they make patching faster and use less space.
here a list of a few issues regarding portability between extended and vanilla, that i encountered while using netpd:
- objects, that use the alias name ([mux], [l2s], [s2l] etc.) cannot often not be created, when a patch is loaded on pd-extended. possible work-arounds: - avoid alias-names when making a netpd-patch(my recommended solution) - loading a patch which calls all objects with aliases by their original name, so that the aliasses work afterwards
in the long-run I hope aliases will be supported by pd-extended. right now this is a pain. if you create the objects once with their full name (maybe in a subpatch) then you can use the aliases. but that's also a bad workaround and potential source of bugs
- certain classes cause troubles because they contain characters, that aren't supported by the filesystem (is the filesystem the real reason?) however, certain classes, such as [<~] and [<~] cannot be used at all in pd-extended. my recommended workaround: - avoid such classes in netpd-patches
I think this is a bug, because this was possible earlier, no? It is not possible to avoid >~. the hexloader stuff is broken on osx.
- since it cannot be expected, that every pd-user uses the same configuration (i.e. pd-settings file/registry), it seemed reasonable to me, that netpd loads dependencies by itself. the introduction of [declare] looked very promising at first glance, because it should make it possible, that each patch can load its own dependencies independently from a specific configuration file. currently there are still some culprits with that approach:
workarounds: none
- [declare] is partially broken (undecided behaviour inside abstractions)
- i have to use a different [declare] for pd-extended than for pd- vanilla: [declare -stdlib zexy] vs. [declare -stdpath zexy]
- some libraries are called differently on both: iemlib vs. iemlib1, iemlib2, iem_t3_lib, iemabs
again, I think all these objects should be available in pd-extended without the need of further declares.
if a netpd-patch developer wants to make her patch work on all pd distros, she needs to be aware of the different layouts, which is an unnecessary overhead, i believe.replace 'netpd' by any project, that focusses on portability.
thanks for putting together this very good list of problems. can we give the broken hexloader and declare a "high priority" in the bug tracker?
marius.