[PD-dev] Re: garray_update

[Tim Blechmann]

> 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 ...

> 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