[PD-dev] Re: garray_update

[Tim Blechmann]

> If you want to fork, then do it, that's fine.  The people who have
> been   working devel have been going that way for a while.  I fully
> support   the goal of addressing usability issues now, that's
> inevitably going to   break things.  But you can't expect people who
> aren't using devel at   all to track your changes, especially if you
> are unwilling to submit   working patches.  Like you said there aren't
well, i don't expect that people track my changes, since i track
miller's changes .... my local copy of devel_0_39 is an exact copy of
devel_0_38 with miller's changes from 0.38 to 0.39 ... (i'll check it
in the cvs, when it compiles fine on osx)
beside that, it would be easier for miller to track my changes (not
suggesting, that he should do that), than for me to track his changes,
since he wrote pd and thus knows about 100% of the code
and thanks to the pd-cvs mailing lists, it's even very easy to track
changes...

> Sure, submitting patches is a slow process, but I think its starting
> to   work.  Miller has started accepting a number of patches, mostly  
is it? the patches that miller accepted where usually only patches of a
few lines ...
and he also said, he's not taking the simd code written by thomas grill
and ported to linux by me, since he can't / don't want to maintain it
... (well, both thomas and i could easily maintain this) ... nor did he
accept günter's tool tips (which are possibly the most useful addition
to pd)

he's also very critical about the use of threads, thus i guess, he's not
willing to maintain my callback-based scheduler / idle-callbacks, nor
the lockfree fifo implementation... (miller, please correct me if i'm
wrong :)
and the improved portaudio code (allowing acceptable latencies) and the
current jack implementation rely on both the callback-based scheduler
and the idle-callbacks ...
as you stated, submitting patches is a slow process ... a very slow
process ... 
patches work fine if the don't really depend on each other, but if they
do, managing patches becomes pretty difficult ... it would be easier to
have a development team (e.g. consisting of the people who commited
changes to devel during the last two years) working on the same sources
on the cvs. this would definitely improve the speed of development a
lot ...

> bugfixes, but its a start.  I am personally disappointed that there is
> a fork, each branch has its own unique strengths.  I still think that 
a fork is about the worst thing that can happen to the development of a 
program, you are totally right ... i really don't _want_ to fork, i'd
prefer to work on a community pure data, but if this is not working,
i'll try it with a community pure devil ...

> if the extra effort is taken to break up many/most of devel's changes 
> into digestable patches, it will get included.
well, i'd guess, it would take quite some time to break down devel's
changes to single patches, during this time, i could possibly write a
native core-audio interface or the feature to load pd as a ladspa plugin
... or record a solo cd ... 
beside that, if miller rejects my improved scheduler or the idle
callbacks, most other patches will fail and i did the work for nothing
... 
it would basically be much easier to go through the diffs between stable
and devel and talk about the changes ... most of them are even well
commented.

i really think, parts of pd are really great and i highly appreciate
millers work, but i also see some problems and think that a
community-driven pure devil would solve these problems much faster ...
so that we can think sooner of making music than of making music
software ...

cheers ... tim

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

latest mp3: kMW.mp3
http://mattin.org/mp3.html

latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs