Thanks. I don't understand the square root though. The equation is even more expensive processor-wise than the straight cos. Granted, you're quoting someone else, but maybe someone out there knows. On Nov 11, 2010, at 9:40 PM, Ralf Mardorf wrote:

On 11/12/2010 03:08 PM, Eric Kampman wrote: the SQRT2 is a constant := sqrtf(2.0f), usually defined as M_SQRT2 in "math.h" qtractor computes the panning coefficients each turn they get changed. then it applies through regular gain to each steaming channel as usual. just const mul over a vector/block/buffer, whatever i'm no expert but i'm sure Ralf quoted me :) seeya -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On Friday, November 12, 2010 11:43:42 am Eric Kampman did opine: And is computationally less expensive if you drop the pi / 2 and use pi * 0.5 as mulls cost less than divs. Or at least this is true if its not handed off to an FP processor. ;-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Don't get suckered in by the comments -- they can be terribly misleading. Debug only code. -- Dave Storer

On Fri, 12 Nov 2010 23:45:56 +0100 Arnold Krille <arnold(a)arnoldarts.de> wrote: Why not go the whole hog and use a pre-calculated look-up table for the whole thing? You will only want a limited number of points, and then only from centre to one side - the other is of course mirror image. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Sat, 2010-11-13 at 11:54 +0100, fons(a)kokkinizita.net wrote: Thank you for your explanations Fons :). Is there a 'most common value' for the centre? I do know several analog mixing consoles from el cheapo to very expensive and all pan pots are ok, I can't notice an audible difference. I only know one very el cheapo mixing console, the Yamaha RM 602, http://i1.tinypic.com/6fzx1k1.jpg , where the pan pots are crappy. As a youngster I started with this mixer :), using the pan pot means to readjust the faders ;). Cheers! Ralf

On Sat, 2010-11-13 at 16:04 +0100, fons(a)kokkinizita.net wrote: Thank you :) so I assume this is what I know from cheap Behringer to Mackie to Soundcraft to expensive Neve etc. ;). Ciao, Ralf

On Saturday 13 November 2010, at 18.07.22, Philipp Überbacher <hollunder(a)lavabit.com> wrote: [...] That sounds like a bug to me. Incorrect sign special-casing, where the signal is inverted in one of the cases...? Although -0.0f is physically different from 0.0f on many platforms, that sign bit shouldn't affect the results in this case, as the value is still 0. -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '---------------------------------------------------------------------'

On Sat, Nov 13, 2010 at 06:07:22PM +0100, Philipp Überbacher wrote: For a panner you need L and R gain. There are certainly not 0, -0 or +0 at the center. So what value are you talking about ? Ciao, -- FA There are three of them, and Alleline.

Excerpts from James Morris's message of 2010-11-13 21:25:05 +0100: It seems there is no single 0.0 but -0.0 and +0.0 instead, but I'd need to manage to compile the program to test or find the right place in the actual implementation to see what happens. The program in question is traverso: http://git.savannah.gnu.org/cgit/traverso.git

On Sunday, November 14, 2010 01:01:17 am fons(a)kokkinizita.net wrote: 'Fixed' that issue in git, thanks for notifying me (again hehe) about this issue! Hmm, you never used Traverso I see ... at least not in the way it should be used: there are no widgets in Traverso to control gain/pan values. But you are correct that the pan/gain 'indicators' have less precision then the actual gain/pan values. One of the reasons I didn't fix this earlier is due I've no idea how much precision is needed. I.e. how small a step value do we want/need for gain and pan, and do we actually want to show that in the indicator? E.g. a value of -3.05 dB is a bit overkill? Right now gain increment steps are 0.05 dB for gain, and there are 200 steps for pan normalized between -1, 1 I've to admit I didn't read all the panning emails, will do so today, maybe there was some conclusion drawn with respect to how panning has to be applied and the needed resolution for the pan value ? Just some thoughts: rotary knob controls are better to control by the human then sliders are, probably due the movements of the fingers are much more precise? The use of sliders vs knobs in software imho still is a different issue since you have to control those with a mouse, right? And this mouse movement dictates how good the movement (and precision of that movement) can be done in combination with how the knob/slider 'widget' is implemented. E.g. the width of the slider is 100 pixels, then you can't use more then 100 steps. Traverso does away with that by using the relative mouse moving distance, allowing for mouse movements to be translated in relatively small gain/pan adjustements in effect giving the user a much better control over the gain/pan/other values. Side effect is that the mouse can be moved physically for over long distances without being limited by screen sizes, so no matter if you're using a large or small screen, a large or small knob/slider, it always feels the same, with much more precision :) (remember, Traverso does NOT use sliders/knobs to control values those are just indicators) Anyway, just my 2 cents. Ciao, Remon

Understandable... we're open for suggestions and bug reports about those issues of course! OK, makes sense. I'll stick with gain in/decrement steps then of 0.1 dB. T at the moment doesn't smooth transitions of gain/pan values when the user changes those when transport rolls. is this much of an issue ? Keep in mind that gain automation uses an interpolation for the gain value calculated and applied per sample. yes, 201 positions, 100 steps in both directions and the central (zero) position. If this kind of precision isn't needed, then I can change that to use the same resolution as midi (128 steps) or perhaps a multiple of 128? How do you move sliders with a mouse with sub-pixel accuracy ? (maybe I'm misunderstanding the sub-pixel accuracy way of moving a graphical slider) Thing is that the 'pan/gain slider' in Traverso isn't used for changing that value, instead you just 'activate' the 'change pan' key and then move the mouse. The distance of the mouse movement is calculated with respect the 'old mouse position' and from that value the pan/gain change is calculated and applied. For pan you keep the P key pressed and move the mouse, the whole track is sensitive for that key. Similar for Gain, then you have to use the G key. To please some stubborn users that insist on trying to click with the mouse on that damn tiny pan/gain slider, it was added as a 'key action for pan/gain' too, but it's considered bad practise :) This 'virtual' slider equals a size of 600 pixels in Traverso, but is easily changed into any value you want. So to pan hard left you have to move the mouse 300 pixels to the left, and vice versa. Ciao, Remon

On Sat, Nov 13, 2010 at 4:07 AM, Folderol <folderol(a)ukfsn.org> 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.

On Sat, Nov 13, 2010 at 02:57:44PM +0000, Folderol wrote: 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). Ciao, -- FA There are three of them, and Alleline.

On Saturday 13 November 2010 18:51:17 Ralf Mardorf wrote: 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

On 11/14/2010 05:14 AM, Ralf Mardorf wrote: as said, for qtractor the panning coefficients are computed _only_ when the pan widget slider changes. the simple one-shot calculation is carried out in gui thread context so it does not add a cycle whatsoever to dsp load ;) cheers -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On 11/14/2010 11:27 AM, Paul Davis wrote: yes, there's no automation in qtractor as of yet. anyhow, panning coefficients are indeed pre-computed into per-channel gain, which in turn is applied in per-sample computation, same as ardour i guess. with or without automation. when automation gets into the picture, then yes it is in my mind design that it will have this sin/cos computation re-evaluated on a per-buffer or process-cycle basis. even though, it's all ordinary cheap for nowadays cpus :) byee -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On Sun, Nov 14, 2010 at 06:14:48AM +0100, Ralf Mardorf wrote: Define 'very time consuming'. This is not about small angles. More exactly: 'Tabulation is the proper solution for RT applications when only low resolution of the angle is required'. You won't get a single simple answer to a question that has no such answer. It all depends on: * The platform. DSP chips don't usually have fast sin() and cos() functions while on a modern PC these can be quite fast. * The application: which will define what is required in terms of - absolute accuracy - relative accuracy - resolution - other numerical criteria * How the calculation is used: - for each sample - for each N-th sample - for each N-th sample but only when the input changes and - on one or a few channels, or - maybe on hundreds of them. Ciao, -- FA There are three of them, and Alleline.

On Sun, 14 Nov 2010 16:03:57 +0100 Arnold Krille <arnold(a)arnoldarts.de> wrote: I don't know if this is at all relevant (prolly not!) but I dimly remember, from my BBC B days, there was a way of drawing circles using Pythagoras. This was dramatically faster than using sin/cos. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Fri, Nov 12, 2010 at 10:40:33AM +0100, Jens M Andreasen wrote: Constant power, but the mapping from angles to L/R ratios is not very good (the regions near full L or R are compressed). A simple second degree approximation works better. Try this in gnuplot: plot [0:1] sqrt(x), sin(x * pi / 2), x * (2.2 - x) / 1.2 Ciao, -- FA There are three of them, and Alleline.

On Sat, Nov 13, 2010 at 04:22:03AM +0100, Ralf Mardorf wrote: Lens apertures are expressed as a ratio of focal lenght to diameter of the lens. E.g '2.8' means that the effective diameter of the lens is its focal lenght divided by 2.8. Surface (and the amount of light passing through) is proportional to diameter squared, and that's all there is to it. In the panning formula you refer to the square roots ensure constant power, since p + (1 - p) == 1. Ciao, -- FA There are three of them, and Alleline.