Report action for the freeze state of a track.

[betov75]

Hi!

Is it possible to add a 'report' action that can output the frozen state of a track? That report action can be added to a new action sequence. The action can report 'Frozen' or 'not frozen', something like that.
Thanks.

[betov75]

I've found (and tested) that BR_GetMediaTrackFreezeCount( track ) return 1 if a track is frozen, 0 if not. The 1, on my side, is always one, no matter how many items are frozen.

I think it's an SWS command, though.

Thanks again.

[ScottChesworth]

Wouldn't it make more sense to report the presence of frozen items when we move to a track along with the other statuses like mute, arm etc?

[ScottChesworth]

Hmmm, I don't think any of our other default status reports rely on SWS though. Gonna need input from @jcsteh I think man.

[RDMurray]

I think it should be fine as long as it doesn't break OSARA if SWS isn't installed.

[jcsteh]

My first question here is: what's the sighted UX? Is there some clear visual indicator on a frozen track? Note that items do get renamed by REAPER to indicate their frozen status and OSARA does report that.

One concern with BR_GetMediaTrackFreezeCount is that since it's not a REAPER internal API, it probably parses REAPER's raw track data. If that's the case, it will be slow in tracks containing a lot of data. We saw this problem with the original implementation of solo defeat and it just isn't acceptable when navigating tracks. Someone would have to look at the source code to know for sure.

[betov75]

Hi! Thank you for that info about the BR functions. On my side, I don't need it to be quick since I give my track selection a 0.5 second delay before reporting and updating faders. In Reaper, OSARA must be super quick so it may not be a good idea to report it with all other toggle states. Maybe just a simple report action can help people build their own action. The reason why I think it's useful on track selection, for some users who use the freeze function more often, it's to make it easier to select multiple frozen tracks without having to check the items. As you said, James, the items are renamed so it still can be identified for 'per track' use. Happy Holidays from Montreal and again, thanks for all. Le ven. 24 déc. 2021 à 07:58, James Teh ***@***.***> a écrit :

…

My first question here is: what's the sighted UX? Is there some clear visual indicator on a frozen track? Note that items do get renamed by REAPER to indicate their frozen status and OSARA does report that. One concern with BR_GetMediaTrackFreezeCount is that since it's not a REAPER internal API, it probably parses REAPER's raw track data. If that's the case, it will be slow in tracks containing a lot of data. We saw this problem with the original implementation of solo defeat and it just isn't acceptable when navigating tracks. Someone would have to look at the source code to know for sure. — Reply to this email directly, view it on GitHub <#621 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZ7PJ72SX3AOMFGNV4RNQ3USRVAZANCNFSM5KU7XG4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[betov75]

I forgot to mention that for sighted people, the track is a bit greyed out and all items are dimmer. Le ven. 24 déc. 2021 à 07:58, James Teh ***@***.***> a écrit :

…

My first question here is: what's the sighted UX? Is there some clear visual indicator on a frozen track? Note that items do get renamed by REAPER to indicate their frozen status and OSARA does report that. One concern with BR_GetMediaTrackFreezeCount is that since it's not a REAPER internal API, it probably parses REAPER's raw track data. If that's the case, it will be slow in tracks containing a lot of data. We saw this problem with the original implementation of solo defeat and it just isn't acceptable when navigating tracks. Someone would have to look at the source code to know for sure. — Reply to this email directly, view it on GitHub <#621 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZ7PJ72SX3AOMFGNV4RNQ3USRVAZANCNFSM5KU7XG4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jcsteh]

Thanks for the info. I'm reluctant to add a specific action for this, as it's inconsistent with the rest of the UX for reporting states like this. Ideally, we would report this when navigating to a track and perhaps we can ask Cockos for API for this.

In the interim, based on your testing of the BR function, it seems you're already comfortable with ReaScript. In that case, you could write your own script to report this via OSARA and bind it to a key.

[jcsteh]

In case you aren't aware, you can have OSARA output a message from ReaScript using the osara_outputMessage API function.