Matt-- I don't believe that bug has been fixed.
Roman-- I haven't looked closely at the relevant code, but it looks like Pd recalculates the graph-- a single graph for the running
instance of Pd-- every time you add/remove a tilde object. (Not sure about
control objects, but it's easy to test.)
The reason I'm comfortable speculating about this is the existence of
wireless tilde objects like [throw~] and [catch~] which use global
receiver names. When you change an object inside a tiny patch with
100 other patches open in the same Pd instance, how would Pd know that
you aren't altering a [throw~] which has a [catch~] in one of the 100 other
patches? Same for [send~]/[receive~], [delwrite~]/[delread~]/[vd~],
[table]/[tab*~], etc.
Here's the dsp_tick routine in d_ugen.c:
void dsp_tick(void)
{
if (dsp_chain)
{
t_int *ip;
for (ip = dsp_chain; ip; ) ip = (*(t_perfroutine)(*ip))(ip);
dsp_phase++;
}
}
That is-- execute each dsp routine in the global array of dsp routines until
there are no more dsp routines to execute.
But this makes me wonder-- how does Supercollider "do its thing"? Seems like
it has an interface to add/remove parts of its dsp graph, and it can do so in a
much more efficient manner.
-Jonathan
On Saturday, September 19, 2015 10:56 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
One more thing to think about is how the DSP graph is handled using dynamic patching. For a long time there was a "bug" where the last audio object added didn't trigger a recalculation and would be left out of the DSP graph until the next edit. Is this still the case? The workaround, if I remember correctly, was to add one last dummy object at the end of dynamic patching.
Matt