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