Blepsynth Cutoff Range

[Tim Janik <timj gnu org>]

Hi Stefan,

the Blebsynth Filter range is currently created as 20..24000:

> pid_cutoff_ = add_param ("Cutoff", "Cutoff", 20, 24000, 1000, "Hz", STANDARD + "logcenter=880:");

Those boundaries don't fit exactly for a straight logarithmic mapping like
you gave in the comment below, if you also want a straight mapping of
pixels to octaves (i.e. map 0..1 to an integer set of octaves).
The value range closest to the current boundaries that I could find is
centered around F#5 (739.99Hz):

begin=440 * 2**(9/12.) / 2**5. ; end= 440 * 2**(9/12.) * 2**5.
print begin, end
23.1246514194771 23679.6430535446

Let me know if I should use different boundaries when I'm implementing
logarithmic parameters.


On 13.07.20 13:13, Stefan Westerfeld via beast wrote:
>     I have just added logscale mappings
>
> The mappings you added are obviously useful, especially for milliseconds (x^3)
> mappings, but these are /not logscale/. A true logscale mapping plots as line if
> you |set logscale y| in gnuplot. A true logscale mapping is fully determined by
> two points, a center is not necessary. Here is how that would compare to the
> function you implemented:
>
> |begin=32.7; end=8372; center=523; e=log((end-begin) / (center-begin)) / log(2)
> print e; set logscale y; plot [0:1] begin + x**e * (end-begin), center, exp (log
> (begin) + x * (log (end) - log (begin))) |
>
> You can also see that this is not true logscale in BlepSynth frequency knob. It
> has more pixels for 20..40 Hz than it has for 12000..24000 Hz, even though what
> we wanted is that each octave takes the same number of pixels.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/tim-janik/beast/issues/5#issuecomment-657496751>, or
> unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIVS7XUQDYAS5PXL5HX6MTTR3LT5BANCNFSM4DLGVKSA>.


-- 
Yours sincerely,
Tim Janik

---
https://testbit.eu/timj/
Free software author.