[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
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
      - 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 
    - 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.


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