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?
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?
@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
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.