Hello, it doesnt look like theres an obvious way to draw the waveform of an AudioThumbnail backwards (right to left) to represent reversed audio.
Is anyone aware of any workarounds? The waveform is zoomable so applying a transform wont work for me.
Reverse the AudioBuffer (AudioSampleBuffer) which is drawn.
Use AudioThumbnail::reset() and AudioThumbnail::addBlock()
Rail
Well thats a workaround for sure, one which I hadnt considered, but it does seem very OTT for something which is just a graphical concern.
Assuming a daw-like environment with multiple, potentially large clips, it seems like that would be very resource intensive.
I guess you could set an affine transform to flip the graphics context left<->right before you draw it, but that’d be very poor programming!
Saying “this is just a graphical concern” is completely the wrong way to think about it!
The code that draws the graphics for a waveform should only be responsible for drawing. How the samples map onto time is knowledge that belongs somewhere else, probably in some code that actually knows how to play the audio.
It’d be a really bad design if you could e.g. flip the waveform backward/forwards, invert it, stretch it, etc and then if every one of those operations was implemented twice as both an audio and a graphic operation… Yuck!
Hi Jules, my Audio and UI are indeed very separate, and id like to keep it that way, hence the reservations about manipulating buffers to feed the thumbnail.
When the user chooses to Reverse a clip, it does nothing other than flags that the source should be read backwards and reversed before being applied to the callback buffer.
As far as my thumbnail is concerned the source and time range remain the same, only that the waveform should now draw from right to left.
This is what I mean by being a purely graphical concern as there has been no change to the source audio being read, I just want to flip the placement.
Nice I got it working by vandalising AudioThumbnail::refillCache to test endTime < startTime and then reverse the arithmetic on timePerPixel, sample indexes and levelData. Works very well, exactly the same, but backwards.