[PD-dev] Re: garray_update

[Guenter Geiger]

On Sun, 10 Jul 2005, Tim Blechmann wrote:
> > 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.
> sure, it's miller's right to reject patches ... like it's my right to
> fork from pure data to release and maintain my flavor of pd ;-)
> none of these solutions it optimal, though ...

Ok, I understand. There is probably nothing more to say about that from my
side. Still hope you can sort it out some way.

Guenter

>
> > 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
> well, i never said that the changes are minimal ... but changing the
> scheduler was necessary to achieve better latencies ...
> the sse code can't easily be separated from the pd kernel, since
> functions are used for both dsp objects and the dsp tree ...
> beside that, no one has to use the simd code ... the inclusion of the
> simd code is a compile time option ...
>
> > 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).
> you can probably use hooks for a few tasks, but it's getting difficult,
> if you are adding features, that you want to use / export for external
> developers (e.g. tooltips or idle callbacks)
>
> > 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.
> one example ... a few days ago i improved the data structures for the
> clock callbacks (from a singly linked list to nested lists, still O(n),
> but faster than the old implementation) ... since i can't run the clock
> callbacks in the dsp callback (threading issue), i introduced a
> run_clock_callback function that's run in both the traditional and my
> scheduler for callback-based dsp ticks ...
> now i can write a patch to port the improvement back to stable, but this
> would conflict with another patch i would write to submit my scheduler
> changes ...
> during this time, i could probably find out, how to implement the
> tooltips for outlets ...
>
> 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
>