Re: Blepsynth Cutoff Range

[Tim Janik <timj gnu org>]

On 14.07.20 14:39, Stefan Westerfeld via beast wrote:
> Am 14.07.20 um 03:19 schrieb Tim Janik:
> > 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).
>
> I don't want an integer number of octaves - see below.
>
> > 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.
>
> Is there a reason why you want to have "whole" octaves?

Just that yesterday you wrote "even though what we wanted is that each octave
takes the same number of pixels", so I was wondering if that meant "whole" octaves.

> Two examples for possible cutoff ranges:
>
>  - 20..24000 corresponds to log(24000/20)/log(2) = 10.23 octaves
>  - 20..30000 corresponds to log(30000/20)/log(2) = 10.55 octaves
>
> I don't see any reason to quantize the ranges as to enforce choosing
> either 10 or 11 octaves instead of implementing the ranges exactly. As
> long as the mapping is logarithmic it should be ok for the user for
> automation and ui controls, even if we don't have an integer number of
> octaves.
>
> I would understand if for some reason you want to quantize the
> lower/upper bound to an integer number midi note.

Yeah, as I wrote earlier, 23.1246514194771 & 23679.6430535446 are the closest
MIDI notes to the current Cutoff boundaries, and since both are F# that just
happens to match to exactly 10.0 Octaves.
I'm not sure how important that quantization is, but I guess it might make the
UI look nicer if we start annotating Hz with MIDI notes + cent.

>    Cu... Stefan
> > 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.


-- 
Yours sincerely,
Tim Janik

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