Re: [tim-janik/beast] Most Bus properties ported to C++ (#78)



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, view it on GitHub, or mute the thread.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]