> > On 09.09.2018 15:21, Stefan Westerfeld via beast wrote:
> Instead of two volume sliders we only need one. The two meters could be put
> next to each other. So this would mean left-to-right volume slider (only one
> slider), scale numbers (-96..+12), left meter, right meter.
Do you intend to work on this as part of this pull request? For beast-gtk
and/or ebeast?
I think that's beyond the scope of a property port, and I wonder if we're
getting too side tracked here, especially when we're pumping resources into
more beast-gtk UI development...
> Ideal for pan would be a round knob, but we could for now use a slider above
> the other widgets left to right (where left is -100%, right is +100%).
>
> > At least using (sqrt(2) ~= 3dB) is what I believe is the correct value
> > here, I'd
> > have to double-check that before implementing it.
> > The monitoring code for our level meters uses dB SPL, which is 20log10(avg)
> > and
> > corresponds to the power ratio of the signal, so the value to use here
> > would be
> > more around 2. See also: https://en.wikipedia.org/wiki/Decibel#Acoustics_2
>
> Lets discuss details not now, but when I've written the code.
When you convert to/from dB, simply use db SPL everywhere (described in the
above WP page) then there's no need for further discussions.
> > Also sync is no longer needed
> > then, and should be removed.
> > The sync property is saved im BSE files, so we need compat loading code at
> > least. If sync is to be removed from the UI depends on how that's designed
> > and
> > implemented to cope with panning. Thus my question above.
>
> Right, it should be ignored during read (real compat code is just needed to
> translate the stored left and right factors => volume/pan). Sync == true
> files will have identical values for left and right volume, so sync is not
> needed to load the file, and sync == false files will have their panning
> information in left and right volume, so this needs to be translated.
We cannot make any assumptions about the values stored in BSE files, about the
order or which values are present or not present, e.g. a user can add sync=1 to
a bse file that has left=0.5 and right=1. That's why the code currently ensures
left + right are synced after parsing if needed.
FWIW, that's one of the reasons things will get easier when we move to XML
based BSE files, we don't have to react to property values coming in in random
order, but can query left,right,sync from the XML nodes and attributes and
configure the object accordingly.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/78#issuecomment-421014075
_______________________________________________
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast
