Waveform Draw feature in bus tracks

What would be an awesome addition to Ardour would be the ability to draw waveforms in the buses.

It is a feature that I have found very useful in Sonar (which I am currently replacing with the wonderful Ardour 2). Basically, as you playback your song, a waveform is drawn in the bus as the playhead moves forward, just like when you’re recording to a track. It then leaves the waveform there until you play over the same section, at which point the waveform is simply “overwritten” by the data from the current playback.

It seems like you might be able to modify/use the same code routines that draw the waveform as you record into a track since the audio is inputting in similar fashion to the bus. The difference is just that the waveform gets drawn, but no recorded file is produced since it’s a bus. In fact, the menu structure is already there in the context menu; when you right-click on a bus the “Show Waveforms” check option exists, it just doesn’t seem to do anything right now.

This feature would be really nice as a double check for what your real-time effects are doing and for mastering. It allows you to use your ears first, but have a visual cross-check for what is going on so you can zero in on things even faster.

Excellent work, Ardour team! I am very excited for the future of Linux and think you guys are doing amazing things!

This feature has been raised recently on the ardour-users mailing list.

To be honest, it is extremely unlikely that this will be implemented at any time in the foreseeable future. To do this requires changes in very very fundamental design assumptions in ardour (specifically: waveforms are drawn from either peakfile and actual audio data depending on the zoom level; peakfile data exists only for audio files on disk).

At the present time (with ardour3 needing a lot of love), this is very low on any priority list I know about.

i’d like to make another comment. i would like to continue to hear justifications for this “feature”. i am normally told by people with a lot of audio engineering experience that the ear is everything, and that waveform displays really are just candy when doing real work. the only exceptions seems to be when dealing with very percussive music where beats can be clearly “seen”, spotting clipping (which ardour marks in red), and noting the general closeness of a signal to total saturation (the basis of the so-called “loudness wars”).

there was some discussion of this on ardour-users, but i admit that i am still deeply skeptical that this “feature” serves any actual purpose. it feels to me that it is mostly desired by relative newcomers to audio engineering who feel that looking at waveform data can provide more significant information than my list above.

finally, what happens in sonar if you zoom way in on the waveform in a bus (e.g down to the pixel-per-sample level) ?

if you feel otherwise, i would appreciate any justification of this feature. i understand that it certainly looks cool, and makes a user feel that they have access to critical information. but does it really provide any critical information? and if so, what. does it serve some other purpose? thanks for any comments you may have.

I personally find this feature not relevant. What could be more relevant to me is above 0dbFS markers in the bus when that occurs.

Indeed, a bus can accept many inputs and it is sometimes hard to determine which input is to blame for the > 0 peak. If you Paul do not reject the idea of using the bus track for something, I think indicating > 0 peaks as they are played would be a potentially valuable info.

Thanks for your quick and sincere response, Paul. Honestly, I had thought it would be -much- simpler to implement than it is. It is certainly not necessary, as you have mentioned. To answer your question about Sonar, you’re right on the money; if you zoom way in it is not sample accurate by default (there is a setting for the block size that it approximates, I believe). One of the uses of the function is indeed that it colors > 0 dbFS parts red.

I certainly don’t want you to take time away from critical things. It was just an idea in case it happened to be easy to add. In fact, because of jack and Ardour’s wonderful routing, you can already do this in a different way. All I have to do is make a dummy track and do a send from whichever track I want to investigate and record it into that track, waveform and all. This also has the advantage of being sample accurate.

As you mentioned, I deal primarily with heavier forms of rock, where it is often wildly transient and the beats can be clearly seen all the time (and compression is typically used more frequently than in subtle minimalist forms of music). I have used it for investigating dynamics plugins (especially LADSPA compressors/limiters that I’m not as familiar with) when I want to closely analyze what the attack and release are really doing to the drums, for example. It’s not that you can’t do the same thing with your ears; it’s more that sometimes you hear things that you’re not 100% sure if it is what you think it is, and the visual cross-reference can help clarify so that you can more quickly interpret your ears (in other words, it’s about how -fast- you can find the problem, not -if- you can find the problem other ways).

However, I think the solution I have come up with above is perfectly adequate anyway, given the further information you have provided. I certainly didn’t mean to pester an already busy team; I feel kind of bad about asking now. It sounds like it’s been brought up more than I realized, and is perhaps not as useful for everybody as I thought. I’m definitely willing to try relying on my ears more. Thanks again for your time and feedback!