[PD] pd forks WAS : Keyboard shortcuts for "nudge", "done editing"

Hans-Christoph Steiner hans at at.or.at
Mon Sep 26 16:49:12 CEST 2011


On Sep 26, 2011, at 1:59 AM, Jonathan Wilkes wrote:

> ----- Original Message -----
>
>> From: Marvin Humphrey <marvin at rectangular.com>
>> To: Jonathan Wilkes <jancsika at yahoo.com>
>> Cc: Richie Cyngler <glitchpop at gmail.com>; "pd-list at iem.at" <pd-list at iem.at 
>> >
>> Sent: Monday, September 26, 2011 12:54 AM
>> Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"
>>
>> On Sun, Sep 25, 2011 at 05:33:22PM -0700, Jonathan Wilkes wrote:
>>> If you are planning on making substantial contributions to Pd  
>>> Vanilla,
>>
>> I wouldn't say I'm "planning" on it -- more that I'd like
>> to keep that option
>> open.
>>
>>> you should consider making a few "test" contributions to gauge
>> the amount of
>>> time and energy it will take you to get patches accepted;  
>>> something like a
>>> patch for getting this <control-enter> key binding would be a good
>> start.
>>
>> Indeed, I've already started that process, by negotiating the shape  
>> of the
>> patch to come and building consensus.  :) There's been some  
>> question as to
>> what key combo should be used.  It seems that [modifier]-Enter is  
>> already in
>> use and people are happy with it, so I'll go that direction despite  
>> my mild
>> personal preference for <ESC>.
>>
>> A patch which has consensus support from the community probably has  
>> a better
>> chance at being applied, even under BDFL governance.  :)   But  
>> consensus can
>> be costly to achieve depending on the project's culture...
>>
>>> Also, realize that any substantial changes you make may sit in the  
>>> patch
>>> tracker for some time -- it's not easy getting them accepted, nor
>>> communicating with Miller if they don't.
>>
>> Well, controlling entities for open source projects have to be  
>> responsive to
>> their communities.  If they are not, they get forked, or people  
>> move on to
>> other things.
>
> It's been forked-- four times (AFAIK).  Nova, DesireData, Pd- 
> extended, and
> Pd-l2ork.  Two of those forks-- Nova and DesireData-- had explicitly
> stated goals which basically boiled down to being more responsive to
> the Pd community (in addition to many other things).

There was also pd-devel, which was probably the first big big fork.  I  
think that you can think of Pd has a kind of association of forks.  As  
the maintainer of Pd-extended, I try to contribute as much as possible  
upstream to Miller, but I also include a number of things that I think  
will probably never make it into Vanilla.  pd-l2ork seems to be born  
out of Ico's frustration with the work it takes to submit clean  
patches.  I try to follow the development since the l2ork crew did  
very nice work like getting the Magic Glass working again.  But its  
very difficult to do since pd-2lork does not seem to use any source  
code management, just tarballs.

Forks are a good thing as long as we lay the basic ground rules to  
keep things compatible and reasonably in sync.  It means that we can  
have more development and testing of ideas.  git makes this much  
easier once you learn it, but git takes quite a bit of learning to  
really use it well.


> I believe the author of Nova moved on to developing parallelism for
> Supercollider, which will probably become a core part of Supercollider
> well before any revision of his 7-year old tooltip patch ever gets  
> included
> in Pd Vanilla.  So as a perfect example of your theory, yes-- Pd gets
> forked, and/or people move on to other things!

To be fair, after that tooltips patch was submitted, Miller expressed  
his problem with how the patch was implemented.  No one ever bothered  
to follow up on that, so yes, that patch made no progress.

> Pd-extended and Pd-l2ork are extant.  There there has
> been some effort to lessen the number of core differences between
> Vanilla and Pd-extended.

On my part, there has been a lot of effort to do keep Pd-extended in  
sync, but its not just on this list or in public forums.  Before I  
started the pd-gui-rewrite, there was a lot of discussion about what  
Miller would accept, and I worked within those guidelines.  These  
days, Miller is mostly using Pd more than working on Pd, so Vanilla  
reflects that.  It seems it is working for what he wants to do, and  
that's what free software is all about, scratching your itches. :)

If you want to see one way I keep Pd-extended in sync, clone the git  
repo and checkout the 'patch_series' branch.  Pd-extended is  
maintained as a series of patches to Pd vanilla from the pure-data.git  
repo.  This way I can develop, test, and release code and then easily  
cook them into well polished patches to submit to Miller.

.hc

>
>>
>> But it's also generally true that large, boil-the-ocean patches are  
>> costly
>> to
>> review, especially for stable projects with large user bases, and so
>> contributors are well-advised to bear that in mind and prepare small,
>> easily-digested morsels when possible.
>>
>>> Additionally, if they are big, desirable improvements to the Pd  
>>> community
>>> they may find their way into Pd-extended anyway.
>>
>> So long as contributions to Vanilla are integrated into Pd-extended  
>> in a way
>> that adheres to the provisions of Vanilla's BSD license, then  
>> there's no
>> problem. :)
>
> The three clauses of the BSD license used by Pd Vanilla are  
> compatible with both
> the GPL v2 & v3
>
> -Jonathan
>
>>
>> Cheers,
>>
>> Marvin Humphrey
>>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



----------------------------------------------------------------------------

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams





More information about the Pd-list mailing list