[PD] implications of pd~ for 'poly' objects

[Mathieu Bouchard]

On Wed, 9 Sep 2009, Phil Stone wrote:

> Thanks for clarifying that, Hans, and for pointing out the issue with 
> threads, IOhannes.  One shouldn't be profligate with [pd~]s, strewing 
> them all about and expecting performance gains -- therefore, one [pd~] 
> per voice instance in a [polypoly] patch is probably not a good idea 
> until we have 64-core CPUs as a regular thing! :-). However, with 
> judicious use, [pd~] seems like it will allow Pd to scale to future 
> processor design, and that's a good thing.

For large numbers of CPUs, and even for not so large ones, [pd~] is not so 
useful, as it has to be put explicitly in places where one would rather 
not have to put it, and where it can be quite complicated to introduce it.

If [pd~] were more like [pd] it would be more transparent; it would be 
easier to switch between the two. However, the most useful load-balancing 
cutting lines are not necessarily those of subpatches and they're even 
less those of whole patches (thus you have to artificially create separate 
patches wherever you want to spread work on several CPUs). I would believe 
that the most useful solutions would look more like Blechmann's [detach] 
and [join], but I don't know all of the implications of it.

...

There is also a naming problem. It's expected that a ~ sign contrast such 
as [exp~] vs [exp] means that both classes are as similar as possible 
except one works on signals and the other doesn't. Despite Pd having some 
quirks about this, [pd~] introduces a big mental clash, so that now, when 
one explains the general meaning of ~, on has to make an exception for 
[pd~]. (If [pd~] were more like [pd], this problem wouldn't be any 
different.)

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801