How to have setClickTrackRange() be respected

Hey there

I’m finding that if I set a range using setClickTrackRange(), I can query it and indeed see I’ve set it to a range of time. However when I play with click enabled, the clicking continues regardless.

Is there something else that needs to happen for this range to be respected?

Many thanks,

Hmm, maybe there’s a bug here?

bool ClickGenerator::isMutedAtTime (double time) const
    const bool clickEnabled = edit.clickTrackEnabled.get();

    if (clickEnabled && edit.clickTrackRecordingOnly)
        return ! edit.getTransport().isRecording();

    if (! clickEnabled)
        return ! edit.getClickTrackRange().contains (time);

    return ! clickEnabled;

That second branch looks suspicious. Shouldn’t it go

if (clickEnabled) { return ! edit.getClickTrackRange().contains (time);  }

Ah okay, I think I might have misunderstood how this works. Looking at TransportControl::performPlay() and TransportControl::performRecord(), where setClickTrackRange() is also called, it looks like the range is actually being used for enabling the click for a count-in if it is not otherwise enabled. Which would make the isMutedAtTime right.

But then setClickTrackRange is called in performRecord() and performPlay(), so anyhow your custom range will be overwritten. Which makes me think, it is not really meant to be used outside those methods?

1 Like

@chrhaase Thanks so much for taking a look! Evidentally I’m misunderstanding the intent of the function. Perhaps it’s a shame performPlay() isnt virtual to allow for messing with the contents and modifying this click behaviour.

Anyway, I appreciate you sharing the results of your investigation!
Cheers, Jeff

1 Like

Happy to help :slight_smile:
Hope you’ll find another way around it!

1 Like

Yes, that should probably be marked as @internal as it’s really only supposed to be used by the TransportControl to set the click for count-ins only.

Can I ask what your use-case is?

Hey there
For my situation I want to have a click count-in for a recording, then have the click drop out (so it doesn’t get recorded by the mic), then have the click turn back on again when the recording (or practice range) punches out.

Currently I’m running a timer that checks current position and compares it against a range, disabling and enabling the click accordingly. Not the most elegant solution but it’s working for now.

Interestingly I think I saw a clamp on the click volume so that I can’t set it lower than 0.2. Not sure why.

I think the clamp is probably there to avoid setting it to 0.0 and the user getting confused as it’s not “muted”. However, that clamp should probably be at the UI level rather than in the API.

I don’t really want to add more confusion to the Clip API as it’s complex enough as it is. I think manually setting the volume is probably the best approach.

Actually, thinking about it, can you not just enable/disable the click track when you need to?

Yes that’s what I’m doing now. Using timer to query the transport to see when it should enable or disable.

That was an aside I was just puzzled as to why there was a clamp on the volume. I set it to 0 but still heard it, then investigated and was surprised!