I assume you’re recording in loop mode? (Which adds the <TAKES> node).
What does your <TAKES> node look like? -1 is returned to show that the current take isn’t part of the <TAKES> state.
I think the problem might be that it’s using this: auto pid = sourceFileReference.getSourceProjectItemID().toString();
When it should also be using the file version.
Maybe something like this (untested):
The above scenario occurs simply by enabling recording on a track and recording an audio clip. The resulting clip has index of -1, instead of the expected 0.
The int WaveAudioClip::getCurrentTake() code shows where the -1 comes from. I am curious as to why it is -1 rather than 0.
I am finding the te take methodology to be very idiosyncratic. Perhaps a more generic version of takes can be fashioned?
Anyway, for my own DAW, I will be creating my own mechanism for takes. I will, however, “borrow” the clip->state to store my own takes.
Well it’s because you don’t have any “takes” until you add them as “takes”. If you just record a single file to a clip it just gets set as the property. The notion of takes is an additional feature.
Returning -1 is an indiction that there aren’t any “takes”.
However, I’m struggling to see how hasAnyTakes() is returning true?
The code does this: bool hasAnyTakes() const override { return getTakesTree().getNumChildren() > 0; }
but if theres’ no takes tree, this should be return false?
You are correct! I had a “take” leftover in the clip->state from previously trying to add one. That is why hasAnyTakes() returned true. I started over with a new track, and hasAnyTakes() does indeed return false. So that bit of confusion on my part is addressed.
I will proceed with creating my own take mechanism. Thank you for your help!