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