[PD] pd extended development
marius.schebella at gmail.com
Thu Apr 17 16:18:56 CEST 2008
Roman Haefeli wrote:
> pd-extended: extra/zexy/abs~.pd_linux: 'abs~' can be called by
> 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
> - 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:
> - [declare] is partially broken (undecided behaviour inside
> - 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
> workarounds: none
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
More information about the Pd-list