[PD] puredata evolution

[Mathieu Bouchard]

Niklas wrote:
> Mathieu wrote:
>> Because it's cheaper to implement. If well done, it's also an 
>> intermediate step towards automatic threading. It's important to cut 
>> hard goals into easier goals, because it reduces required investment 
>> and gives quicker returns.
> yes, I totally agree but I was curious about the technical aspects and
> not necessarily about the development process that naturally has to
> obey these rules.

I don't really see the technical aspects and the development process as 
being that much separated. It's at the same time the fact that development 
processes are full of techniques, so i don't know why it should't be 
considered technical; and also that technical aspects that are designed 
without taking development processes into account, can easily become 
unrealistic.

>> Also, I wouldn't trust automatic threading to make use of the CPUs in
>> the best possible way all of the time, *especially* for real-time.
> well, afair an algorithm for the optimal solution would be in NP anyway.
> if a suboptimal solution is enough, i think you can use it in a realtime
> system very well; ableton live for example scales with multiple 
> cores/cpus.

I have no idea how Ableton does it. I have never used Ableton and barely 
know anything about it.

I am not certain about how to control multiple CPU usage in a way that 
prevents all the kinds of dropouts that could arise from it. It has to do 
with whether you can predict the timing of an object according to an 
history of its previous timing. If objects can switch CPUs efficiently 
anytime, maybe this issue is moot, but I don't assume that this is 
necessarily feasible with my current level of knowledge.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada