[DilettantParticipant]

sometimes the results differ just because of the sampling rate…

That may be (i think much less often than most 96 kHz users postulate), but the point is, that there simply do need not care about /why/ it differs for the User.

Thus, it _is_ completely possible, perfectly senseful and legal to compare 96 kHz with 48 kHz Systems. There is absolutely no argument to not do that.

[DilettantParticipant]

You do not understand enough about digital and what happens with processing.

I understand that things very well. But for many users (and me including), they don’t really matter. It is simply fact that not
everyone that buys a SQ does that because of the (at least postulated) very low latency or finbe high frequency responses. Some of them
even use 48 kHz AR/AB Stageboxes and are perfectly happy with that. Some even have 16 kHz Low Pass filters or Shelves on their Master Bus.
They simply care about about what they want to produce, not about sampling Frequencies.

Most users compare Mixers due to Criteria that matters for them. That even may not be any sound parameter
but the housing color, the weight, the preference of their dealer or their favourite brand. If that matters for them,
it is what they should care about and it is what they should compare.

But also the technical argument is way less clear than you insist.

There are a lot of experienced and professional Engineers out there that clearly say 96 kHz does _not_ make anything better most of the time
because there is simply no signal source and no signal target that can make use of the additional Data and the
noise floor off the algorithms is way low enough for most purposes anyway. And they have points. Just try to name 5 common
Samplers that deliver more than 48 kHz or 5 common stage Microphones that can be used over 20 kHz – you will see that is
not easy. Even some professional Amps and speaker Management systems have a steep 22 kHz Low Pass on their inputs.

If you detect a special 96 kHz Console sounds better than a special 48 kHz one, that might or might not be due to the
sampling frequency. That is, because it is practically nearly impossible to make such a comparison without psychological Biases
and because there are many other things influencing what you hear – Many “differences” reported out there are for sure due to
some different calibrations of used D/A-Converter (even in different Modes for 48 and 96 kHz that may be different), the following
analogue Amp stages and of course the Loudspeakers/Headphones (that are always the by far weakest part of the Chain when it comes to exact
reproduction).

Only one thing is absolutely clear: 96 kHz means to process twice the data volume of 48 kHz. That _may_ reduce number of
available Channels (like it does even on SQ Drive Multitrack Recording), it may make the system to respond less fast,
eat DSP power, consume disk space and so on. That might make the Console more expensive (it not necessarily has to,
that is mainly a question of FPGA Market price structures and politics at the end of the day).

A&H says, 96 kHz help reducing latency. That can matter in some situations, it cannot in some other. If you filter
20 kHz, the latency Argument can be correct. If you filter 100 hz, it cannot because your period is 100 ms and there is
absolutely no way to extrapolate periods longer than 4 times of the available Data that makes sense in any form.

You say, 96 kHz even reduces processing noise. That may be but there are rare cases that noise does really matter. Most of the
time, you have 100 and more times higher noise levels from your preamps, microphones and even ambience. And even processing noise may
be reduced as well by dedicated oversampling instead of generally higher sampling rates for many use cases.

And that statement also was mentioned in the forum earlier: There were tons of really good Audio material produced with
less than 96 kHz over decades, many of it absolutely rocking the planet. If any result doesn’t, that nearly sure is not
due to the sampling frequency of the mixer.

[DilettantParticipant]

Well for those Users A&H should offer a Hardware addon containing some Drone that brings up a really big sign right in Front of the Desk…

To get serious again:

In General: “Some Users are too dumb” most of the time is nothing more than a widespread lame Excusion of bad or unmotivated (not only user interface) developers. Not every time, but most of.

So if you say such things, you should try to reflect about your goals.

Do you want to feel good by demonstrating the dumbness of some Users / feel yourself as a “Pro” that is better than all those Amateurs out there? Then go on. You are on the right way.

Or do you want a User Interface that makes work as easy and fast as possible?

What might (more of) your customers want to pay for?

For the concrete Problem “User might work accidentally in wrong Mix Layer” that means:

A single LED is indeed a way too weak signal to get recognized intuitively in that case. Even when it is flashing. That is because the User may be highly focused on changing something special. So the Signalling has to be penetrant enough to gain attention over that for telling he might be in the wrong Mix.

Before we had Channel LCD Stripes, there was a similar Problem with Custom Fader Layers on digital Consoles. It was an important Part of the working solutions not only to place text on them but also to set Background Colors which will change when you switch to another Layer – only that makes the recognition really work for most People. You may just try it out by setting all your LCD Colors to Black or White.

Changing Color of the LED in the Select Buttons may be a good compromise (if that is a RGB LED, dunno). If that disturbs in some use cases, it can be made configurable. If that is impossible because those LEDs are fixed Color ones, Blinking Select LEDs or changing LCD Text Foreground Color might be an Option but you have to beware about Contrast to keep it readable. Maybe something like black = main, dark blue = Group, dark green = Aux, dark red = FX. And for colour-handicapped People it would be good to have that configurable.

[DilettantParticipant]

PLASSE stop compare 96KHz versus 48KHz architectures consoles…

Sorry, i have to state this:

No, at least myself, but i could bet many other people, too, definitely won’t.

I simply see no reason to care about having 48 or 96 kHz on the Console core. Thats just one of many technical Parameters which may influence things I care about, but then i will care on them and not on sampling frequency.

In Fact, at least my personal goal and i think the goal of most SQ Users is to mix Audio for humans, not for bats, dogs or any kind of analyzing device. Humans are “pets” that can hear a maximum of around 20 kHz, maybe 24 kHz as a Baby, but as far as i know there was never detected a human on the whole planet who can hear higher Frequencies.

Most of us use Microphones which are limited to a maximum of 12 up to 20 kHz or synthesizers that use 44 or 48 kHz Sampling Frequency on our Inputs. And most of us generate output that will be shipped to “End Users” with that sampling rates.

So why should I not compare Consoles with 48, 96, 72, 80 or 192 kHz? They all more or less can do what i want. The Sampling Frequency is the way, not the target. In Himalaya Climbing where the way may be the target, in Audio Processing it is definitely not, at least not for me.

Of course, I may care about number of Inputs, features, noise, sound, latencies and many other things. I also may care about file sizes, bandwidth or storage, about a reasonable User Interface, about robustness of the Hardware and last but not least about money.

If SQ is better or worse in some of that points because of using 96 kHz, that’s good, but it makes no difference if another Console would do that with better Software, other Hardware or whatever else may help. In both Cases the result is mainly the same.

So don’t be disappointed there, I and many others will continue comparing Mixers without caring at all about what sampling Frequency they use. We also may compare Cars without caring about the inside color of the gear housing.

[DilettantParticipant]

I think this is one of the rare Cases where the signal mut not be a static one.

Blinking or flashing is no good Idea for most normal display Options because it automatically gains attention immediately – just try it out with some Websites – no matter what else is on them, if there is any animated part that absolutely ties your mention at once. That is btw the reason why i never would allow animated commercial banners on my Website – I want to gain my users Atention myself and not hand it over to third parties 😉

So, for most things it is not a good idea to blink, flash or animate because there is no need to get attention.

The absolute single case Blinking, Flashing or animating is a valid and legitimate display method on a good user interface is a Warning. Nothing else.

And that is exactly what we have here: a Warning to the User that the console is not in the intuitive suggested basic Mode of Operation.

So: yes, please blink. As with Mute groups on the Mute buttons (which is also a kind of warning message). Blinking with the LCD Stripes on all Strips that are not in “normal” Operation would be a good Option for that.

The absolute Minimum would be to change the LED of the Select Button to the LCD Color of the Bus Master.

[DilettantParticipant]

16 Colors are a little much restricted. Does not need to be RGB, but 32 or 64 Colors to choose from would be good. And maybe a “hide” Color for “black text on black Background” for “secret” Channels.

[DilettantParticipant]

Aaaaah great! Thanks for the hint.

Then of course I take back my suggestion. Maybe it would reduce support Calls to make the GUI more consistent by placing that at the same place as Pan/Bal for input channels.

[DilettantParticipant]

+1

Would be a great addition when using Ardour with Ubuntu and SQ as DAW Controller.

[DilettantParticipant]

BTW it would be a nice feature in future SQ Generations to not have to do that because there are already LED Stripes besides or on the Buttons.

[DilettantParticipant]

+1

Thats an absolutely needed Option for IEM and for parallel Stereo FX (think of a MoTown Compression: of course you want the panning of the compression signal being the same than the panning of the uncompressed Channel Signal so you do not “double place” your lead Singer – if it is a female one, making the “Image” much wider could even result in physical damage to the techie ;).

[Author]

Posts