The GUI port I'm working on for Pd-l2ork should essentially replace Pd-extended. But I still have to get it building on OSX. There will be some inconveniences:* I'm not porting Toxy. (But Pd Vanilla broke support for it anyway.)* Aside from some key GUI externals, I'm only going to port GUI externals "a la carte". That is, if your patches depend on it and it would be burdensome to find a workaround, I'll go ahead and (try to) port it. But in general, all the other externals that ship with Pd-extended should work just fine (and do work atm in Pd-l2ork). -Jonathan
On Wednesday, October 14, 2015 11:22 AM, "rolfm@dds.nl" <rolfm@dds.nl> wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list