Provide visual feedback for audio clipping

[rillig]

Is your feature request related to a problem? Please describe. When I'm programming a sound wave, many mistakes can happen. For example, the samples may be outside the range [−1 to +1]. Since the program is run 44100 times per second, the usual logging techniques seem inappropriate since they would very quickly fill the screen.

Describe the solution you'd like If a sample is outside of the valid range, a peak level meter or other visual indicator should show that clipping happens. Compared to a real-life peak level meter, there are some additional mistakes that typically only occur in programming and that should be indicated separately:

• the returned sample is ±infinity
• the returned sample is NaN
• the returned sample is always too high or always too low, for example when accidentally adding 440 to the sample instead of the frequency

I have no idea about how existing hardware music equipment displays these errors. The UI should probably look similar to them.

All these visual indicators should appear fast and fade slowly, like in a typical ADSR envelope.

Describe alternatives you've considered For compile errors, there is already a red error bar below the code. That could be used for traditional error messages, if programming the visual indicators should turn out to be too much work. Since there are probably only a few different error messages, fading them in and out could work. But then again, looking at a red light is probably more efficient than reading a line of text. Plus, it occupies less screen space.

[anuejn]

A live scope like view would be very nice. However, i have absolutely no idea wether this is doable with okayish performance

[cfstras]

You could probably do a scope with a 2D Canvas, make it 200px wide, average 4 samples, that makes for a refresh of 44100/200/4 = ~55 fps, which should be doable on an requestAnimationFrame

[anuejn]

I think, we would need some trigger logic and some timescale setting. Otherwise, the results would be hard to interpret. The image would be jusf flickery in most cases

Moreover averaging 4 samples togegher would limit the bandwidth to ~5khz, which could sometimes be not enough.

The general idea to use a canvas2D / some plain webgl is quite good :)

[rillig]

The original goal of this issue is to provide simple visual feedback for typical programming mistakes. Having a fully emulated oscilloscope is not part of that goal but would be an entirely different idea.

The choice of a peak level meter was deliberate. It provides visual feedback without producing a nervous cloud of pixels. It can tell the peak level, over or underflow (clipping) and the total amplitude of the output signal. That's all it should do.