Audacity Forum

steve wrote:

Gale Andrews wrote:I would quite strongly prefer "Label <what we're labelling>" myself.

but then the majority of Analyze tools will be listed as "Label <something>" whether that be beats, envelopes, sounds, silences, zero crossings, clipping, regular intervals, or whatever, which makes it harder to visually scan the menu to find the tool that you are looking for.

That's a fair point, but I think "marker" is potentially misleading. You know how many people want "markers in the waveform".

If we are going to have that many "markers" they might as well have their own menu item, surely, which makes them easier to discover?

steve wrote:When we have "Album Track Marker" then we won't necessarily need two general tools for marking sounds/silences.

+1 to that.


Gale

I had a few PM's with Koz about this. I think he will accept a majority decision.

I think there are three plans on the table. All of the plans could also include configurable threshold below 0 dB for the given number of samples. I think that is un-necessary complication but I don't object if we want it.

Plan A) has Show Clipping trigger threshold as now, one sample at 0 dB, unconfigurable. Meter also clips (and holds) at one sample at 0 dB (removing discrepancy between meters and Show Clipping), but user can change that to x samples before it clips and y samples before it holds. Non-holds will fade away.

That's a fairly big change for playback meters - it may make loudness war files show as more dangerous than they are (but Steve would say that is a good thing).

So Plan B) lets the meter clip default stay at 4 samples at 0 dB (and x and y can still be customised). To maintain consistency with Show Clipping, the latter does not show red lines until 4 samples are clipped. But because consensus says it must show every clipped sample by default, we show runs of 3 or less clipped samples differently (lighter red, dashes or whatever).

Plan C) makes both Show Clipping and Meters thresholds configurable. Both default to trigger on 1 clipped sample. Because we have a pair of matched settings they have to go in Prefs. I don't favour C. It makes the settings less accessible and makes the display of Show Clipping more complex if user chooses a threshold more > 1.

I would choose A) for consistency and no change to Show Clipping, though B) is a good fallback if consensus thinks meter should continue not to clip until four samples.

I would also say with B), Find Clipping default thresholds should change from 3 to 4 samples.

Is this a way of moving forward? I hope so


Gale

I'd be happy with A, B, no change, or a combination of A and B.
I'm not so keen on C.
I'd prefer that "x" is always 1.

Plan D: Add additional controls to the Meter Preferences dialog: t trigger dB, x samples before clips show; y samples before it holds; z.z total fade time (.75z seconds would be fully saturated, .25z would fade from fully saturated to gone). Change the current clipping menu item from a single checkable item to a submenu with the existing checkable item plus an additional "Clipping Preferences…" (in keeping with the absolutely ridiculous current trend of divorcing preference access and scattering them); this new dialog will allow the user to configure: t trigger dB to define clipping; x consecutive samples before clip show; checkbox to allow differential display; y samples before it differentiates; .d (acceptable values between .80 & .20?) indicating saturation; drop-down to choose between four (or maybe all 7) fully saturated indicator colors: yellow, red, green & blue are obvious [exhaustive: (255, 0, 0); (0, 255, 0); (0, 0, 255); (255, 255, 0); (0, 255, 255); (255, 0, 255); (255, 255, 255)].

If I may not have my cake and eat it too (although I can because Plan D is virtually - no fading - a watered-down version of what I currently have for myself and my clients) I would go with Plan A.

The only way that we will get agreement about the meters is if users can choose what sort of meters they want.
That would require either:
a) A huge number of preferences for meters.
b) Meters as plug-ins (with several meters to choose from and each meter plug-in handles its own preferences.

Looking into my crystal ball, (a) will never be accepted. (b) has a good chance of being accepted.

Currently we don't have (b). We are (now) looking at options / preferences for the shipped meters, which are currently the only ones available, so all users get these meters whether they want them or not.

While I think that "plan D" might be nice for some users, I think it is over the top for most users, so -1 (though I'd be quite happy for there to be a meter plug-in to have "plan D").

steve wrote:a) A huge number of preferences for meters.
b) Meters as plug-ins (with several meters to choose from and each meter plug-in handles its own preferences.

Looking into my crystal ball, (a) will never be accepted. (b) has a good chance of being accepted.

Currently we don't have (b). We are (now) looking at options / preferences for the shipped meters, which are currently the only ones available, so all users get these meters whether they want them or not.

While I think that "plan D" might be nice for some users, I think it is over the top for most users, so -1 (though I'd be quite happy for there to be a meter plug-in to have "plan D").

I can only think that Steve is bang in the money here - both Steve and Gale have already voted for b in the proposal (no other votes)

Update: I've just voted on the Proposal to support b (I have no real use for that myself but I can see that others might).

steve wrote:a) A huge number of preferences for meters.
b) Meters as plug-ins (with several meters to choose from and each meter plug-in handles its own preferences.

For clarity, please not that my (lower case) "a and b" are not the same as Gale's (upper case) "Plan A, B and C".

steve wrote:While I think that "plan D" might be nice for some users, I think it is over the top for most users, so -1 (though I'd be quite happy for there to be a meter plug-in to have "plan D").

I'm -1 on "Plan D", it's overkill for shipped meters.

I don't think it unreasonable to have two shipped meter "styles" with the same/almost the same preferences set. I know I am the only one of us who still likes the RMS meters, so if there are no user complaints in 2.1.0 about the RMS meters being non-default, a future Audacity might have instead e.g. a PPM, Loudness or VU meter as alternative to the gradient, hybrid meter that is current default.

So at the moment plan A) is winning.


Gale

Gale Andrews wrote:I know I am the only one of us who still likes the RMS meters

Actually, I quite like them, though I prefer the new style meters as the default.

So I think this has stalled for 2.1.0 inclusion (?)

Are you (Ed) willing to do a patch for plan A) (upper case) some time? Or does anyone want a combination of A) and B) as Steve suggested he would be OK with?

Does a combination mean A) plus differentiated display of Show Clipping, or something else?


Gale