slider and meter do not align with new MusE3 design

[spamatica]

Atleast with the style I'm using now the slider markers and the meter color markers do not align. I would expect them to since both are the same height.

[kybos]

Still relevant? If yes, could you provide a screenshot? I don't quite get what is meant by the markers.

[spamatica]

Actually there still seems to be some issue with alignment. Wouldn't the marker for red be at zero?

[kybos]

Oh, I see. That could be quite difficult, because the slider scale is calculated dynamically, dependent on the strip height and possibly other factors. We would have to interconnect it with meters somehow, but as the meters are a very performance critical component, I'm not sure if it's a good idea. I personally would not touch it ;-).

BTW: The colours in the new style are not correct (those that did not exist in master before my PR). You can reload them from the global cfg file (something like /usr/share.../Dark Flat.cfg).

[spamatica]

Aha, yeah, I'm OK with closing it. Perfect alignment would be good but keeping ones sanity is better :D

Yeah, I was just going to ask about the colors. I will write a separate message.

[terminator356]

Yes I brought this up recently, mentioned it to kybos. Been a long-time fix meaning to get to. I mentioned we could have the slider tell the meter what its current upper and lower marking positions are and the meter will adjust itself.

[terminator356]

I'm going to take a shot at this. I've known a long time that it would be hard, otherwise I would have done it before ;-) Not sure if I can get this done fast enough not to be abandoned...

I considered setting up two pairs of signals and slots so that the meter can ask what the slider's limits are, and additionally the slider can inform the meter when something changes. But this approach has problems. For example if the meter asks the slider for the current limits, it might be too soon, the slider may not have changed yet. Or if the slider informs the meter of changes, the meter might not exist yet. One or the other might miss any changes. [ Edit ] Hm actually it might work. A two-way system might take care of all scenarios.

So today I thought about it and I think the best way is to put an h-layout in the slider, which contains the slider itself, followed by another v- / h-layout deal containing the scale followed by optional meter widgets (added with a method "addMeterWidget"). That way the whole thing is automatic, the meter adjusts its dimensions to the scale layout. This is challenging. The slider is already a populated widget. So a new containing widget may have to be created, to hold all three widgets. [ Edit ] Oops, oh... yeah, this is why it was gonna be hard: The scale is not a widget, it's a painter. It can be on top of the slider (I did that).

[terminator356]

• Fixed long-time meter and slider scale mis-alignment. New stylesheet property meterSpacing.

Tested OK with dark flat and light themes. Try it out. Look closely at the ends of the meters, how they align with the slider scale endpoints.

@spamatica About 'redder-than-red-lining': Fun fact: Our meters show beyond 0 dBFS because they show the accumulation of audio at a particular node which internally can be greater than 1.0 But these values are not passed to the audio system, they are clipped before output. Thus, our strips conveniently show you just exactly what the total audio could have been had it not been clipped before output. Ie just how far beyond 1.0 you really are. A sort of visual mixing 'overhead'. I think that's the story.

[terminator356]

Also, beside actual audio output clipping, on the wave file side of things, I think I read that libsndfile automatically clips all float data (by default).

[spamatica]

Den fre 19 juni 2020 kl 07:10 skrev Tim notifications@github.com:

• Fixed long-time meter and slider scale mis-alignment. New stylesheet property meterSpacing.

Cool, looks great!

Tested OK with dark flat and light themes. Try it out. Look closely at the ends of the meters, how they align with the slider scale endpoints.

@spamatica https://github.com/spamatica About 'redder-than-red-lining': Fun fact: Our meters show beyond 0 dBFS because they show the accumulation of audio at a particular node which internally can be greater than 1.0

Yeah, fully with you on that, the internal headroom is and needs to be much higher.

But these values are not passed to the audio system, they are clipped before output. Thus, our strips conveniently show you just exactly what the total audio could have been had it not been clipped before output. Ie just how far beyond 1.0 you really are. A sort of visual mixing 'overhead'. I think that's the story.

Right, I wonder if we do that in the jack driver? I was trying to use ALSA directly (through the RtAudio driver) some weeks ago and unless I remember wrong I got really bad sounding distortion, which I concluded was because I had too hot output. Then again I may remember it wrong. Sending out non-clamped values through a DA does sound horrible, that much I know for a fact.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/muse-sequencer/muse/issues/497#issuecomment-646438142, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCFAN2ZW6DYSAQTKZJ22TTRXLXL3ANCNFSM4B7GABVQ .

[terminator356]

It may have been simply because the signals (meters) were above the 0dB mark. Thus regardless of whether the driver clips, it was gonna distort no matter what.

There is a danger in that users might think that they are OK if the meter is displaying in the red area. Users might think that they still have some signal headroom, and that it's OK to have a signal somewhere in the red portion but not at the top. When in fact, the 0dB mark (where yellow meets red) is the absolute highest that they should be adjusting for. Should find a way to warn users about that. The clipper labels go red, but maybe that's not enough to warn them to back off a bit.

[kybos]

This is fixed, closing...