[PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
ico at vt.edu
Mon Dec 22 23:48:17 CET 2014
On Dec 22, 2014 10:23 PM, "Dan Wilcox" <danomatika at gmail.com> wrote:
>> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>> Unless you want an enormous number of patches in the wild to bit-rot,
you're going to have a "Install Pd-extended libraries" button. If you have
that button, then presumably at least _one_ person is going to need to
build and test the whole enchilada, no?
> I disagree. If it’s easier to build, then it will be easier for a number
of people to test on their respective OS. I assume l2ork doesn’t rely on
one person testing and building across multiple platforms? I’ve been in
that situation already and it sucks. Much nicer to split up the work,
better still if the makefiles work and we have some scripting to handling
automation, fetching, etc for developers and volunteer testers.
Actually, you're simply trading one shortcoming for another, and I would
argue you're shortcoming is a lot harder to troubleshoot. If you provide a
monolithic distribution to all of your users, then reproducing their
problems becomes exponentially easier as opposed to encouraging each user
to install select externals which may clash with each other in unusual ways
that may not be apparent otherwise and then trying to backtrace and
troubleshoot their specific set up as opposed to relying on one monolithic
release that you can easily reproduce on your own computer. If we had
infinite time on this rock this may be a feasible option. As for me,
particularly considering I am doing this not because I am getting paid to
do it, monolithic approach is the way to go with the ultimate goal of
having all externals in the extra folder and without any subfolders (in
part because duplicates and buggy externals will have been weeded out).
BTW for clarification purposes, pd-l2ork is tested by a couple of core
developers, including myself almost on a daily basis, plus 12+ members who
have little or no experience with Linux, let alone with PD through the
laptop orchestra, and finally a bunch of kids through various k12 education
initiatives (who also have little or no knowledge of Linux or PD). I feel
that is fairly sufficient for my needs.
Also, to clarify another point that has been brought up several times on
this mailing list, while pd-l2ork does not support Windows or Mac at this
time, this is mainly due to lack of human resources, rather than some kind
of religious mission. There is clearly an intent on supporting those once
we complete port to Qt toolkit. Until then, there is a bootable USB stick
that boots on most computers, and has its own environment, including a
persistent home directory. There are exceptions-- select laptops that
stubbornly lock down their EFI making them not fully compliant with
bootable USB stick format. Examples of this that I observed include select
Apple hardware (as part of their ongoing "we know better than the user"
walled garden initiative) and a few Dell and Alienware machines (in other
words, select companies in close relationships with Microsoft).
>> Btw-- are there poisonous spiders lurking in the Pd-extended makefiles?
Just reading this thread and seeing alternatives like "let's just port apt
to some proprietary OSes" seems odd to me…
> I agree. I, for one, say let’s make sure the makefiles work well before
getting into package management (if at all).
>> So I guess I'll add my own idea to this mix: how about replacing every
single external binary with an abstraction? Then the external libs become
portable without having to compile a single thing. Plus any Pd user
willing to click the object can potentially fix bugs or make improvements.
Sure, you can't do Gem and some of the fancy stuff, but those are details.
This would also increase the incentives for doing development to the core
which makes abstractions faster.
> rjlib, etc have done some of this already and I’ve followed when I
started reimplementing my abstraction library. Honestly, I don’t think this
community has the resources to tackle an effort like that, regardless of
the technical issues that would need to be fixed. I think it’s far more
pragmatic to work on making it easier to split up the maintenance work on
the existing externals and allow for more people to hep testing, building,
and using them outside of a monolithic Pd-extended release. Again, this
approach has worked for other projects like OpenFrameworks, so I think it
can be applicable to Pd. This way, also, we still allow for the freedom of
the users to step up and dictate which externals they want to keep using
without throwing out all the work and useful source code that already
> Dan Wilcox
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list