Hi all, i'm basically of the same opinion as Günther, but i also think we are stuck in a non-satisfying situation, where i'm fully with Tim. Right now, the critical parts in PD for me and my GUI project vibrez are arrays und DSP. I'm afraid that arrays won't be really usable for some time, because there's no click-free loading of large amounts of data, no synchronisation between array-using objects and no feedback about dirty regions. Currently, i am thinking of implementing my own array objects, because there's not much lost (in my view) with abandoning the current PD array functionality and associated internals. Concerning DSP, i probably make a new attempt in the future to split the DSP chain in separate parts for each root-patcher in the first place, and then maybe even try that for each patcher/abstraction, as already discussed here some time ago. This is the most straighforward way to enable a click-free delayed loading of patchers, as to be implemented in dyn~. Still, since this is a lot of work, it would be good to hear Miller's opinion on this, whether it collides with his ideas or not. It's very hard to contribute things without having the greater picture of future developments. As for the overall view, i would very much support a more modular concept of PD, with separation into several then easier to maintain parts, above all concerning kernel and GUI, but also data processing (like SIMD), data structures, internals, DSP etc.
best greetings, Thomas
� schrieb:
Hi Tim,
On Sat, 9 Jul 2005, Tim Blechmann wrote:
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...
I think that it might be just as hard, if not harder for Miller to track your changes, also because you probably have a different view of what Pd is supposed to be and where it should be going too. So I fear you have to step back, as you are not the author of Pd.
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)
I think that Miller has the absolute right to not accept patches, either because they touch parts of Pd that should be left alone or because they are just too big. Incorporating patches is a task that takes a lot of care, I had to realize that when I included the alsa-midi patch into the Debian package.
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 :)
Changing the scheduler is not a minimal change. I also think that the SSE code can be maintained apart from the main pd. For PDa I have just rewritten the signal objects as externals, the changes to make this work in Pd are just a few lines of code. This way Miller could be sure that no bugs are introduced in the standart Pd version, and using SSE would be a call to "pd -nomsp" and the "MSP" part gets loaded dynamically. I have done something similar with the scheduler.
Anyhow, what I want to say is that structuring the changes might help the transition. And even if your additions don't go into the main Pd distribution, this scheme also helps to port them to a new release of Miller, because your changes in PD itself are just some "hooks" to your code. (this was my main concern when chosing this structure).
I admit that this probably won't work for the soundfiler and array locks, but it would mean that this patch would be a few lines of code and maybe gets accepted by miller.
Cheers, Guenter
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@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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev