If a container clip contains an audio clip with auto tempo enabled and the main Edit’s TempoSequence has changes that overlap the clips, these won’t be reflected in the playback.
Rather than wrap a NodePlayer, it might be better if the container clip node contained its own subgraph and handled the looping itself. The idea being that the play head would always be the same and the times in the contained nodes would actually correspond to the main edit, not with respect to the container clip.
There are several things to ensure still work with this approach:
[ ] ContainerClip looping. The contained clips should repeat themselves with respect to the CC’s loop range
[ ] ProcessState: this contains flags for the start/end of loops and the internal WaveNodes must have these. We might have to be able to still process with our own process state to get this right (and not just when the edit loops)
[ ] Looping: As the region of the CC’s loop determines the position of the contained clip’s, it might be simplest to work out what the offset of those clips is (compared to the start of the CC) and simply update that with each loop iteration. Something similar is done in the LoopingMidiNode already and works well. WaveNodes will need to take this as an atomic offset that can be set during playback
[ ] This should also mean dynamic time stretching (changing bpm at play time) will work in the same way as with normal WaveClips
If a container clip contains an audio clip with auto tempo enabled and the main Edit’s TempoSequence has changes that overlap the clips, these won’t be reflected in the playback.
Rather than wrap a NodePlayer, it might be better if the container clip node contained its own subgraph and handled the looping itself. The idea being that the play head would always be the same and the times in the contained nodes would actually correspond to the main edit, not with respect to the container clip.
There are several things to ensure still work with this approach: