Oops-- by "arguments of the parent" I mean arguments of the parent abstraction.
-Jonathan
On Monday, February 24, 2014 2:44 PM, Jonathan Wilkes <jancs...@yahoo.com>
wrote:
So let's just take a concrete example: "$@" syntax. It is a dollarsign
variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands
to the incoming arguments. In an object box this expands to the arguments of
the parent. The code for this feature affects Pd's message parser, which is in
"the core". This is just an example-- there is a whole category of features
which require changes to core code like this one.
If you have a description of a democratic development process that can
implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how
it works, and
if it's maintainable I'll help you implement it.
-Jonathan
On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic <i...@vt.edu> wrote:
From:Dan Wilcox [mailto:danomat...@gmail.com]
Sent: Monday, February 24, 2014 11:34 AM
To: Ivica Bukvic
Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic <i...@vt.edu> wrote:
>On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox <danomat...@gmail.com> wrote:
>
>I consider that a sad thing. At least with Pd-extended, it was largely
>Pd-vanilla + externals.
>
>I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals +
>most limitations of the vanilla. How does that help you in your mission to
>move forward?
I think you're missing my point here. With Pd-extended, you know you would make
things which would work with Pd-vanilla if it had the appropriate externals
compiled and available. With Pd-L2ork, there's a good chance that will not be
the case as you move forward, thus fragmenting people between the apps. The
Linux distro analogy is not a very apt one as there are far fewer PD users by
comparison.
But what if breaking things will bring more people in? (I ask this fully
realizing I am playing a devil’s advocate here since I have no proof of this
being the case with pd-l2ork nor that this will ever be even remotely close to
the success of libpd)
I'm not saying it *will* happen or that it's your stated goal to split things,
I'm just trying to suggest again that there could be a middle ground that could
work for both Miller's and the communities goals. Other projects have managed
that, why can't ours. Obviously, trying to push all updates and requirements
back to the source have not worked, but maybe we can decided upon a subset of
things that could/should be in the core and find a way to implement them.
Again, I think gui abstraction could be a way to help this.
I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also
know you've been trying to integrate changes back into the Pd-vanilla. I just
think that there must be another way.
I am all ears :-)
That said, I would love to entertain the thought of co-developing libpd but I
think that is currently bogged down by the same predicaments that pd-extended
and any other non-vanilla implementations have to deal with, which is whether
you keep the backwards compatibility or move forward as fast as you can at the
expense of the compatibility.
>>
>>Which is why I bring up the idea that we find some firmer ground in the bog
>>and reach a compromise instead of forking galore. If fragmentation is a good
>>thing, then there really isn't much of a community, simply a few islands
>>rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep
>>PD-L2ork going and it won't go the way of DD, but again there should be a way
>>to have our cake and eat it too. I don't see the harm in trying.
>>
>>Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the
>>most life into Pure Data over the last few years by bringing lots of new
>>people in who want to patch for phones and apps embedding libpd. Alot of
>>those people are Max users ... :D I personally don't like the idea of us
>>working on libpd when you take off with Pd-L20rk and we might reach a point
>>where we'd want a libpd-L2ork. Would be nice to have both ...
>
>A lot of things would be nice but that is not the reality of the current
>situation. I think backwards compatibility is even less relevant to libpd when
>it is embedded in ways that are completely transparent to users, but I guess I
>digress, so I'll shut up.
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards
compatible. This way at least you know that if it works in Pd-vanilla when
patching it will work in libpd. Should we diverge to make custom changes we
need and then require an entire new gui for people to build patches for libpd
only? As it is now, libpd development is largely pd development and that's a
good thing overall. If we can manage the architectural changes that were
required for libpd (by Peter Brinkmann), then I don't see why we can't find a
reasonable way to integrate some of the things that are needed for more
advanced guis etc. The rest can be modular in tcl/tk and externals.
I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I
don't want to build a bunch of patches around new functionality that just won't
work on a mobile phone and would be harder to debug.
If the reality is as you say, then I'm not really interested in spending my
time hacking on our little island.
>
>And the only thing I can say at this point is that I respect that and to thank
>you for your genuine effort at moving the community forward.
That remake was hasty of mine and short sighted. My background is in
engineering and I hate seeing effort split up and duplicated on things that we
all want/need. If we all respect Miller, maybe we can also respect that we
could find a middle ground with both his goals and ours.
I’ve said it many times and I’ll happily say it again—I have nothing but utmost
respect for Miller and Miller’s work. Yet, based on my conversations with
Miller, I have my doubts that there will ever be a middle ground—the goals are
too divergent for one code base to meet both needs in a way that also satisfies
your and my (and apparently others’) sense of urgency. That said, I’ve been
proven wrong many times before, so please don’t let this stop you.
--
Dan Wilcox
danomatika.com
robotcowboy.com
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
