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.
_______________________________________________
beast mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/beast
