Time has passed. A new president has been elected. I need to shave. And Halebopp has progressed since the last time I wrote about it.
On the front end side, panning with the middle mouse button and zooming with the scroll wheel is now possible. Audio tracks sport a nifty amplitude preview. Tracks can be dragged around.
Regarding the backend, Halebopp is now completely supporting stereo recordings. There is a method that supports loading FLAC and wavefiles via libsndfile, but there is no GUI for it yet.
On a sidenote, I rewrote the sound engine. I'm trying something nobody has tried before, which is applying a datamodel for editing large images to working on a piece of music. Audio sequencers usually focus on mixing audio "real-time", that is: the data is being prepared, processed and finalized on the fly, as the sound is being output. The advantages are low-latency processing of recorded input and low memory consumption. The disadvantages are high CPU consumption and the inability to apply time-domain effects like reversed reverbs or timestretching.
Rather than generating audio data realtime, I render all data "offline" in the main thread into a large chunk of memory (which maps the complete song), and determine what needs to be rerendered based on invalidated ranges in that buffer. This is a model that is stupidly easy to handle from a programmers perspective. It limits CPU consumption to the situations where data needs to be rerendered. If the song does not change, there is virtually no CPU consumption, as the completely cached song is directly streamed. Skipping around in the track is equivalent to scrubbbing in an MP3 file: there is no restarting of effects, everything sounds exactly the same everytime you play it. Mixing down the song to disk simply means just dumping the contents from memory, which takes no time. And the rendering process is multicore friendly.
The challenge is still to keep rendering times short, well distributed and well segmented, while not overusing memory consumption - the usual issues. However handling offline processing is much easier than generating audio on-the-fly, since you can access data randomly across the entire timeline, which gives you a bigger range of possibilities and allows you to write code in a fairly straight-forward manner.
Wednesday, November 5, 2008
Subscribe to:
Post Comments (Atom)
3 comments:
Sounds interesting...so will each audio track/synth have it's own pre-rendered audio that's layered with the other parts during playback? I ask this because if, for instance, if a synth is playing and i want to just fiddle with some knobs on it, it sounds ilke the ENTIRE audio would have to be rerendered for this...
?
hs, at the moment i am trying to keep the number of mixdown surfaces low, so i hope 2 or 3 surfaces are going to work for everything.
yes, technically, if you modify the song while it is playing, the parts of the song which you invalidated will be rerendered. however, rerendering is planned to be done in small chunks (so you can update the segment that is playing first), and also able to cancel previous update jobs (so you can redo a segment that was supposed to be done already), so the audio that is about to be played should usually be delivered on-time.
but that area is still subject to experimentation. the first versions will deal with offline editing entirely, and realtime tweaking will at some point become part of the program.
Cool. the same idea i had months ago (prerendering).. <3 nice one
Post a Comment