I want to implement tab to transient, ala ProTools. This is incredibly useful for editing audio.
Looking for ideas / implementation tips.
WarpTimeManager has a getTransientTimes() function, to retrieve transient times, after calling a TransientDetectionJob.
I’m thinking of running this background task each time a clip is loaded or modified, and run a first pass when an edit has finished loading. This way, finding the next transient will be quick and pretty straightforward by simply iterating each AudioClip past the current playback position until a transient is found.
Does this seems like a correct implementation to achieve this ? Is there anything I could be missing ?
Depends on what you mean by “modified”?
It’s probably going to be constantly running if you run this detection every time a clip is moved? And you’d have to fully render the audio clip (maybe without plugins) as they might be running with time-stretching applied in real-time (i.e. AudioClipBase::setUsesProxy (false)).
It might be possible to do this smoothly in the background though.
The other way to do it would be on the raw audio files that are in the Edit and then map those sample positions to clip times. That would be less processing but tricky in terms of mapping those source file samples to Edit times what with time-stretching, tempo changes, offsets, looping etc.
The first option would definitely be simpler to implement.
It probably depends on how you store the transient time stamps. If they’re in seconds or samples, if the clip is moved between timeline times with different time sigs or tempos and the clip is time-stretched to follow, the seconds will be invalid.
If you store the transients in edit-time-beats they’ll stay the same if a clip is moved in this way.
Right now WarpTimeManager stores transients as TimePosition’s. I’m fine with converting them to BeatPosition’s, yes.
I’m thinking maybe this would make more sense to scan through transients each time the user request it, rather than keeping transient times stored and update them for every clip operation.
This is an interesting topic. I wonder how PT does this internally.
That’s going to be slow if you’re doing it on demand as you may have to read several seconds of each audio file and possibly render them before you can know the transient times.
I’m not sure about PT but didn’t it historically render all time-stretches anyway? So detecting transients at this stage would be one way of doing it.
