> (which actually might be tricky depending on platform/how their system is set > up).
exactly, that's why it's better not to make any assumptions. just tell users: "needs zexy, cyclone ..." and it's their responsibility to add the necessary search paths/load libs if necessary. and again: > > imagine you want to use both [foo/obj] and [bar/obj] in the same > > abstraction. how could you possibly force on or the other with > > declare? > Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr > Von: "Derek Kwan" <derek.x.k...@gmail.com> > An: "Alexandre Torres Porres" <por...@gmail.com> > Cc: "Christof Ressi" <christof.re...@gmx.at>, Pd-List <pd-list@lists.iem.at> > Betreff: Re: [PD] declare vs. namespaces - current best practice > > > >> And to come back to my first remark here on this thread, if > >> [declare] cannot always force a priority, shouldn't it? > > > > I don't think so. [declare]'s job is to add paths to the search path > > and load libraries. it has nothing to do with namespacing. > > > > imagine you want to use both [foo/obj] and [bar/obj] in the same > > abstraction. how could you possibly force on or the other with > > declare? > > > > Well, I suppose one way of forcing the use of cyclone's gate without > typing out the entire thing and dealing with this whole namespacing > thing is to basically use the -noprefs flag when launching pd (and > assuming the people you are distributing the patch to have Pd somewhere > in their path which might be a big if, you can send along a shell script > that launches pd with that flag for them) and using [declare] to control > what gets loaded and what paths are added (which actually might be > tricky depending on platform/how their system is set up). And of course > not loading the prefs file affects more than just paths/loading... > > So maybe now that I type it out this isn't such a simple idea to > implement haha, but maybe it could be helpful for some use cases... > > Derek > -- > Derek Kwan > www.derekxkwan.com > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list