Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
audio time features #575
This includes work I've done over the last couple months to improve time based functionality in the audio namespace.
Scheduling audio::Node::enable() / disable() at a specified time
The biggest addition here is that there are overloads for Node::enable(), disable(), and setEnabled() that take a
By precise, I mean sample accurate if needed. This comes into play mainly with audio generators, where you'd want them to start producing samples somewhere in the middle of an audio block, not at the beginning. All of the
Scheduling audio::SamplePlayerNode::start() / stop() at a specified time
Related, SamplePlayerNode subclasses also get nice trigger overloads. BufferPlayerNode adheres to
audio::Param specified begin times and support for sequencers with latency
I addressed two use cases here. One was how to make an audio::Param into a sample accurate ADSR, and the other is how to strongly sync audio (ci::audio::Param) and visual (ci::Timeline) animation events. Both are achieved by enabling events to be scheduled in the future, by setting the
The problem this addresses is that we want to keep the audio thread non-blocking, yet we need to schedule events on it and ensure that they are processed. The only way to do this is by introducing latency - you cannot try to schedule an Event at 'audio time now' (on the main thread) and be 100% sure that it will be processed, because that time may have already passed when we get back to the audio thread.
However, if a real-time ADSR is needed, you can (with these changes) schedule an attack + decay with pretty good indication that they will fire sample accurately (or a block or two off), with something like the following:
I'm considering improving this in the future to ensure that both the above applyRamp() and appendRamp() calls above happen before audio processes, but one solution would require a recursive lock against the Context's mutex, and I'd like to wait until I have larger projects to test against before making that move.
I also needed to make adjustments to the audio::Param::apply() method to account for delayed events, so that the apply 'wipe out' doesn't effect any events that are within the latency period. For similar adjustments on the ci::Timeline side of things, see PR #574.