[PD-dev] Re: garray_update

Thomas Grill gr at grrrr.org
Sun Jul 10 13:45:58 CEST 2005


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 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
>>
>>_______________________________________________
>>PD-dev mailing list
>>PD-dev at iem.at
>>http://lists.puredata.info/listinfo/pd-dev
>>
>>    
>>
>
>
>_______________________________________________
>PD-dev mailing list
>PD-dev at iem.at
>http://lists.puredata.info/listinfo/pd-dev
>
>
>  
>




More information about the Pd-dev mailing list