[PD] pd extended development
Roman Haefeli
reduzierer at yahoo.de
Thu Apr 17 11:49:24 CEST 2008
On Wed, 2008-04-16 at 22:54 -0400, marius schebella wrote:
> Roman Haefeli wrote:
> > how important is the portability between pd-extended and
> > pd-vanilla/externals considered? any solution, that involves the
> > [mylib/myclass] scheme creates patches, that are broken on a pd
> > installation with multiclass externals.
>
> seriously??? I did not know that. that actually changes a lot. it
> basically means "back to start"...
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
> > 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.
sorry for causing confusion with new terms. when saying
'multiple-class-per-external format' i was referring to the bundled
libraries. let's stick with the latter.
> > from what i can tell, making a patch work exactly the same on extended
> > and vanilla adds quite some overhead. or is it only me, who would like
> > to create portable (between vanilla and extended) patches?
>
> it should be 100% compatible and should add no or only the very minimum
> necessary overhead. I am willing to put a lot of effort into this being
> realized.
cool to hear.
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
- 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
- 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
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
workarounds: none
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.
roman
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
More information about the Pd-list
mailing list