March 10th

Another update on my audio programming journey. The last week has mostly been about wrapping my head around what an audio region should be in my application as well as some Dear Imgui implementation. 

I decided to take a first easy route regarding handling audio buffers where I allocate memory and copy buffers for every region change I make. This is of course a complete waste of resources, but also the easiest way to make things work quickly. My audio regions consist of:

• An audio buffer thats holds the audio data 

• An instance of WavInfo struct that holds info about the underlying wave-file

•  A texture displaying the audio data

• Properties about the region itself (gain, fades etc)

Audio buffers

One important note about the audio buffer; my goal is to convert this into just a pointer to an audio buffer allocated elsewhere. The region will then work as a “portion” of a buffer and with this design I only have to allocate and copy memory once the user decides to actually render a region into a file. I can also have multiple regions pointing at the same exact audio buffer. Pretty neet (if I can get it to work)..!

Displaying Audio data

I’ve set up my UI so that it is displaying the regions as “images” (specifically in DirectX11 shader resource views) which comes with some great features. I can use these images as render target views and render directly to them during startup. By rendering I mean taking in the actual audio data, converting it into screen space by clamping the values in the 0-1(floating point) range and then drawing using linelist as primitive topology.

What the rendered audio buffer can look like (ignore the weird line...)

Coming up are some scary (but super important!) features on the same topic. I want to be able to split a region and therefore I need to unwrap and reverse the steppes executed when I take audio data into an image. I will now have to look at where the user wants to split the region and convert this into a position in the audio buffer. Exciting!