Re: [Qtractor-devel] [LAD] panning thoughts
An Audio/MIDI multi-track sequencer
Brought to you by:
rncbc
From: Ralf M. <ral...@al...> - 2010-11-14 05:27:40
|
On Sat, 2010-11-13 at 19:30 +0100, Arnold Krille wrote: > On Saturday 13 November 2010 18:51:17 Ralf Mardorf wrote: > > On Sat, 2010-11-13 at 16:26 +0100, fo...@ko... wrote: > > > On Sat, Nov 13, 2010 at 02:57:44PM +0000, Folderol wrote: > > > > Paul Davis <pa...@li...> wrote: > > > > > there's an awful lot of math for which a modern processor can compute > > > > > the answer faster than it can look it up. this is one such example > > > > > (as fons noted), but there are many others. this started changing > > > > > about 8 years ago, and its only gotten more true since then. > > > > > > > > Oh dear. I didn't realise I was so far out of date :( > > > > > > It's absolutely true. > > > > > > Note that the calculation I posted earlier runs entirely on > > > the FP processor, and two variables, q and d, will probably > > > only exist there and never be written to memory. If it takes > > > any time at all, the CPU can meanwhile do something else, > > > such as getting the pointers to the audio data it will need > > > later. Using a LUT will mean the CPU has to do all the work, > > > which includes getting the base pointer and calculating the > > > required offset(s). > > Just to ensure you aren't talking about different claims. > > > > Is math even faster, as e.g. 4 states for left, 1 for centre and 4 > > states for right, provided e.g. by an array? Or are you thinking about > > nearly stepless panning? > > Unless your memory runs (and is connected) at the same speed of the processor > (which afaik no platform has, even the first and second cache run at lower > speeds), simple math of only a limited number of operations is always faster > then getting stuff from memory. Todays processors contain even more > optimizations for fast and parallelized math. > The trick Fons showed is about doing the pan calculations in simple math > instead of using trigonometry which would require complicated functions like > sin/cos to be called or tables from memory to be checked. > > Have fun, > > Arnold Using sin/cos still is very time-consuming? I do understand The Wiki on German better, but the Wiki on English, pardon: "Die Tabellierung aller Werte ist angezeigt bei geschwindigkeitskritischen Echtzeit-Anwendungen, wenn diese nur eine recht kleine Winkelauflösung benötigen." (http://de.wikipedia.org/wiki/Sinus_und_Kosinus#Berechnung) Loosely translated: Tabulation for rt (when using sin/cos) for small angles (what ever a small angle might be) is still faster. My question: It's better to avoid using sin/cos and instead to use Fon's trick?! Hence Qtractor (Rui) better shouldn't use sin/cos? Thanx, Ralf |