Re: [LAD] ?==?utf-8?q? 'A' note Tuning Range
Am Mittwoch, 10. April 2019 18:38 CEST, Len Ovens schrieb: > On Wed, 10 Apr 2019, Will J Godfrey wrote: > > > On Tue, 9 Apr 2019 23:23:54 +0200 > > wrote: > > > >> Without doubts it should be 440 Hz +- 50 Cent. > > > > Thanks everyone for your comments. There seems to be a general consensus > > (and > > elsewhere too) so I'll check nobody actually *is* using extreme settings for > > some reason, and maybe tame it down a bit. > > For tuning, anything greater than half way between semitones can be > acheived with transpose. Or, to put it another way, if you need to detune > by that much, you are really playing in a different key. Hmm, no. You are mixing up frequency with pitch class. (Ab)using transposition for changing pitch only works for equal temprament (but OP referes to Scala tunings). Even in my rather limited world of baroque music playing I've used: 440, 415 (modern pseudo-baroque), 432, 392 (french low), 456 (high Venetian), 517 ... That has nothing whatsoever todo with transposition. Just my 0.2 $ Cheers, RalfD > -- > Len Ovens > www.ovenwerks.net > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 'A' note Tuning Range
On Wed, 10 Apr 2019, Will J Godfrey wrote: On Tue, 9 Apr 2019 23:23:54 +0200 wrote: Without doubts it should be 440 Hz +- 50 Cent. Thanks everyone for your comments. There seems to be a general consensus (and elsewhere too) so I'll check nobody actually *is* using extreme settings for some reason, and maybe tame it down a bit. For tuning, anything greater than half way between semitones can be acheived with transpose. Or, to put it another way, if you need to detune by that much, you are really playing in a different key. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 'A' note Tuning Range
On Tue, 9 Apr 2019 23:23:54 +0200 wrote: >Without doubts it should be 440 Hz +- 50 Cent. > >+- 50 Cents is what the meter of the BOSS TU-12H chromatic tuner >displays and what you'll find for other software synth, such as e.g. >iSymphonic. The BOSS meter's Hz labelling is from 430 Hz to 450 Hz and >the Hz labelling of iSymphonic from 428 Hz to 452 Hz. IOW the >Cent labelling range from - 50 Cent to + 50 Cent is a little bit more >than the HZ labelling range from 428 Hz or 430 Hz to 450 Hz or 452 Hz. > Thanks everyone for your comments. There seems to be a general consensus (and elsewhere too) so I'll check nobody actually *is* using extreme settings for some reason, and maybe tame it down a bit. As an aside, doing further reading it seems most authorities consider 5 cents to be about the limit for people to detect pitch change (lots of caveats of course) yet Scala example files have figures with 10^-6 cents, and Yoshimi has 10^-6 :o -- It wasn't me! (Well actually, it probably was) ... the hard part is not dodging what life throws at you, but trying to catch the good bits. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] How do you improve optimization for integer calculations?
In Sun, 7 Apr 2019 23:06:45 +0500 Nikita Zlobin wrote: > I really did not recognize that nasty trick, clearing xmm0 :). > Also i understood, why SSE can't be used there. Without integer > division support it is undoable with SSE - replacing with > multiplication means conversion to float. > I recently discovered fast integer division algorythm, allowing to accelerate multiple divisions with same divisor. I got working this way, but then discovered that gcc uses this method, so it is still doable by SSE. Though from other side, i still can't find enough places, where benefit of working with colors as single integers rather than separate color values would be meaningful... one such place is accumulator, used for averaging. While input is uint8_t[4], accumulator is uint16_t[4]. I have to either work with them by elements or use masks, bitshifts and OR for each element... just to prepare single value and store (either uing32_t[2] or just one uint64_t). Looks like benchmarks are necessary, along with these intrinsics, to test, wether integer SSE really better than what gcc proposes. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
