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
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list