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