Original Take of Clip Has Index of -1

If I record an audio clip, the original take for the clip will result in the following results

waveAudioClip->hasAnyTakes() // returns true
waveAudioClip->getCurrentTake() = -1;
waveAudioClip->getNumTakes() = 1;

We can see in tracktion_WaveAudioClip.cpp the following;

int WaveAudioClip::getCurrentTake() const
{
    if (currentTakeIndex == takeIndexNeedsUpdating)
    {
        currentTakeIndex = -1;

        auto takesTree = getTakesTree();
        auto pid = sourceFileReference.getSourceProjectItemID().toString();

        for (int i = takesTree.getNumChildren(); --i >= 0;)
        {
            if (takesTree.getChild (i).getProperty (IDs::source) == pid)
            {
                currentTakeIndex = i;
                break;
            }
        }
    }
    return currentTakeIndex;

Is there a reason that getCurrentTake needs to be -1 rather than 0?

It seems to me that 0 is the more appropriate value for the index. But, I don’t know all the other use cases.

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):

        auto pid = sourceFileReference.source.get();

?

No, I do not use loop mode.

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!