Isn't it better to show the actual data, not what its analog product is?
Frankly, that approximation would be wrong in many cases, and would very significantly complicate the visual presentation as well as impact UX.
There is a lot of work here. Actual gains are marginal, risks quite high.
Those steps are the data being manipulated.
Displaying the product of the data only would be confusing in another direction.
So, both would be required.
That is where all the work is, and in terms of priority the case for this kind of thing is super weak, IMHO.
Seems to me you are framing this as a fix when it is not actually a problem.
It is an enhancement request.
While I agree with you, and learned about these things myself! I felt much better about a lot of concerns, but I must also say I find very little utility in a computed visualization of this kind.
It would be spiffy, but would add almost no real value.
> Isn't it better to show the actual data, not what its analog product is?
A stairstep isn't "the actual data". The actual data is a series of impulses. While it is possible that somewhere inside a component of your hardware there's a DAC which is creating zero order hold signals to feed into a reconstruction filter as one cheap way to make the PCM data into analogue audio, Audacity has no way to know that and there's no reason either Audacity or its user should care.
> Frankly, that approximation would be wrong in many cases
You could easily plot a curve that's more accurate than the user's display. You can't see inaccuracies that are smaller than a pixel. There's already suitable code for this calculation (it's called a resampler) inside Audacity.
> Those steps are the data being manipulated.
Again nope, you're manipulating PCM data, an Excel-style view of lists of signed integers would be much closer to "the data being manipulated" in this sense but you presumably don't think that's a good idea.
Your apparent confusion as to what's real here despite having "learned about these things" is exactly why I was pleased to see in the other reply that Audacity now shows lollipop sticks illustrating the actual impulses once you zoom in far enough to see them.
If lollipops are the thing we're showing most users for the next twenty years I have my hopes that conversations like this will become no more necessary than arguing with Flat Earthers.
We'd be trying to draw a curve (a band limited audio signal is a smooth curve, although I guess in the very degenerate case that it's completely silent that curve is also a perfectly flat line), on a display made of rectangular pixels, so, that is always going to be an approximation, but that's really neither here nor there.
> Can we show them the input signal that generated the data easily? If so, great. Let us do that.
Yes, this is very easy to do, in the video you say you've shared many times it shows this (among many other things) because it isn't hard, unless your idea of a fast computer is a 20MHz 80386 or something, in which case, yeah, that's not easy and maybe isn't worth your time.
Or what they have chosen to do now (lollipop graph) is also fine, if you zoom into the lollipop graph on your 44.1kHz recording of a Mariah Carey vocal it's still fine, it only starts to get a bit confusing (making the smooth curve valuable to see what's actually happening) at really high frequencies say, 15-20kHz.
> Well, in that video he is reproducing inputs with only modest frequency complexity.
Monty is making them with a signal generator, so that you can easily see what's going on and (if you have suitable gear) you can reproduce the results. The exact same phenomenon would happen for some hypothetical complicated analogue signal. Notice that Monty also demonstrates a square wave, which is in fact the maximum possible "frequency complexity" because of how audio is defined, even though chances are you're still thinking about it as very simple.
> Won't the compute burden depend on the frequency domain complexity of the input signal?
No, it's just resampling, the same way you would to go from say 44.1kHz (from a CD) to 48kHz (typical modern fixed rate DAC in a cheap PC), except you're maybe going from 40 samples to 1000 pixels if you've zoomed in that far. It'd use a windowed sinc function.
If the software renders the output shown on the scope, fine! That is what people will get.
How useful is that?
The case you made, which is to beat back misconceptions about what the output will be, is a good one. I do not disagree. Then again, just sharing that video does a very similar thing.
I do however think that display and UX would / could be more complex and would not actually get anyone anything new.
In my case, after learning the things presented in that video, I first used my scope, which is actually very similar, if not identical to the one in the video, to play with some signals and explore performance on various devices,circuits and code I found of interest.
Then what?
From an audio editing POV?
Nothing, other than I understand where seeing sample data breaks down in terms of what will be output and heard. That is nice, and seeing it would be nice too, but unnecessary.
Now, when building my own stuff, knowing what to expect is just as nice. I can hook up a scope and validate it.
It does make me wonder about the inverse questions! My square wave is a mess!
Despite fancy rendering and interpolation we may well be back to sharing the video.
Frankly, that approximation would be wrong in many cases, and would very significantly complicate the visual presentation as well as impact UX.
There is a lot of work here. Actual gains are marginal, risks quite high.
Those steps are the data being manipulated.
Displaying the product of the data only would be confusing in another direction.
So, both would be required.
That is where all the work is, and in terms of priority the case for this kind of thing is super weak, IMHO.
Seems to me you are framing this as a fix when it is not actually a problem.
It is an enhancement request.
While I agree with you, and learned about these things myself! I felt much better about a lot of concerns, but I must also say I find very little utility in a computed visualization of this kind.
It would be spiffy, but would add almost no real value.