One thing I'll add-- Pd-extended already includes within it the ability for
individual libraries to be compiled "a la carte" in the way Dan desires. Any
library adhering to the "libdir" format will have a standard makefile that can
be used to compile the binaries. They'll end up in the same directory with
their help patches, which means in most cases they will create properly when
the user opens the help patch (even if that library hasn't been loaded yet).
The idea of scripting dependencies across externals is an interesting one. I
don't think that currently happens with Pd-extended. But a lot of libraries do
employ [pddp/pddplink] in the documentation, so that feature would be handy in
that situation.
Also-- I think weeding out "duplicate" externals is a bad idea, at least the
way Ivica describes it. Many people have built patches with Pd-extended,
assuming that all the object names available at startup are essentially like
"keywords" in text-based languages. It's unfortunate that [lib1/foo] does the
same exact thing as [lib2/bar]. But if I'm trying to show off Pd by playing
some fancy synthesizer patch which relies on [lib1/foo], it had better work.
I'll always prefer ugly-but-works over
clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits.
Anyway, I think there are ways to prefer certain objects or libs in the search
results, and steer new users to the more reliable and maintained set of
externals.
-Jonathan
On Monday, December 22, 2014 5:48 PM, Ivica Bukvic <i...@vt.edu> wrote:
On Dec 22, 2014 10:23 PM, "Dan Wilcox" <danomat...@gmail.com> wrote:
>
>
>> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes <jancs...@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 exists.
>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
