osara
osara copied to clipboard
Thoughts on adding a "report every x seconds" feature to Peak Watcher?
I've just been using Console One from Softube. One of their accessibility things is that when you're monitoring peak and gain reduction meters, you can either have the info reported on demand or reported at 5 second intervals. I expected to find the latter intensely annoying, but actually it was super handy when I was dialling in compression and level-matching ahead of doing some comparisons. However, there's a significant entry price into that ecosystem, and not enough of a range of plug-ins for me to operate entirely with in it, both of which made me wonder whether we could implement something similar in Peak Watcher? One thing I haven't seen anyone else doing yet is providing an update at a user-specified interval that averages the last x amount of seconds activity. Sure, there would be some inherent trade-off of precision with such summarized feedback, it wouldn't be right for every task, but for someone like me who ballparks numbers and does the rest by ear, I could see it being used a lot here. Not much detail here yet I know, I wanted to ask about feasibility before I get attached to the idea and start obsessing over potential UX. Thoughts?
Is the advantage here that you don't have to keep moving your hands while you're setting levels, etc.? If you're just listening, on-demand seems like it offers more control without much extra user effort, but I can see why auto reporting would be useful if your hands are elsewhere.
In terms of implementation, Peak Watcher already uses a timer internally, so having it report something every x seconds should be fairly easy. Averaging is a little harder, especially once you get into the weeds of how that interacts with peak hold, etc., but definitely not infeasible.
One UX thing to consider is whether these automatic reports should interrupt other speech or not. That isn't going to make any difference to users for whom interruption doesn't work at all, but it might make all the difference when it does work.
+1 for this Sent from my iPhoneOn 19 Jul 2023, at 11:46 am, James Teh @.***> wrote: Is the advantage here that you don't have to keep moving your hands while you're setting levels, etc.? If you're just listening, on-demand seems like it offers more control without much extra user effort, but I can see why auto reporting would be useful if your hands are elsewhere. In terms of implementation, Peak Watcher already uses a timer internally, so having it report something every x seconds should be fairly easy. Averaging is a little harder, especially once you get into the weeds of how that interacts with peak hold, etc., but definitely not infeasible. One UX thing to consider is whether these automatic reports should interrupt other speech or not. That isn't going to make any difference to users for whom interruption doesn't work at all, but it might make all the difference when it does work.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Sounds interesting. Just having peak watcher auto report and reset on the same configurable time frame would be nice in lots of circumstances Sent from my iPhoneOn 19 Jul 2023, at 9:55 am, ScottChesworth @.***> wrote: I've just been using Console One from Softube. One of their accessibility things is that when you're monitoring peak and gain reduction meters, you can either have the info reported on demand or reported at 5 second intervals. I expected to find the latter intensely annoying, but actually it was super handy when I was dialling in compression and level-matching ahead of doing some comparisons. However, there's a significant entry price into that ecosystem, and not enough of a range of plug-ins for me to operate entirely with in it, both of which made me wonder whether we could implement something similar in Peak Watcher? One thing I haven't seen anyone else doing yet is providing an update at a user-specified interval that averages the last x amount of seconds activity. Sure, there would be some inherent trade-off of precision with such summarized feedback, it wouldn't be right for every task, but for someone like me who ballparks numbers and does the rest by ear, I could see it being used a lot here. Not much detail here yet I know, I wanted to ask about feasibility before I get attached to the idea and start obsessing over potential UX. Thoughts?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Another UX thing to think about: right now, Peak Watcher reports which watcher and channel. I imagine that'll get pretty annoying if we're doing it every few seconds. Should it only report the level? But then how will you figure out what this level is associated with? Should this auto monitoring feature only be available when only one thing is being monitored?
Yeah, seems the simplest solution is only allowing users to enable the time-based auto-report for a single watcher at a time. I think it's reasonable to expect users to remember (or failing that, do a quick manual check) of how their watchers are configured, so the auto-reports only speak the dynamic information and we're not adding spurious speech.
How would we handle the UI for configuring this? ? I think both watchers currently present the same GUI right? Maybe the cleanest way is to add a new entry to the context menu, so we'd have 1st watcher, 2nd watcher, Auto-reporting. In the new Auto-reporting menu, we have branches for 1st and 2nd watcher, and in there, maybe a couple of preset choices for how frequently the reports will happen. I like the idea of adding it to the context menu because then it can be accessed via accelerators, EG you could do Alt+W, A, 2 then choose the frequency of reporting you want from the second watcher.
Is the advantage here that you don't have to keep moving your hands while you're setting levels, etc?
Exactly that. Would be useful when you're setting levels and juggling an instrument, hearing a lil extra reassurance when you're dialling in a compressor using a surface and suchlike. Not a high priority thing, I was just surprised by its usefulness when I was investigating some Console One stuff, figured we might wanna incorporate something if time permits. Also McLaren wants it, that drops it a few entries down the priorities list. :)
One UX thing to consider is whether these automatic reports should interrupt other speech or not.
Hmm I hadn't thought about that. Console One was reporting via Sapi when I used it there, so no speech interrupt. I think I would've preferred it to be interruptable, but then, I like everything interruptable by default, and I guess we have to weigh that up against the potential for interruptable reports being so easily skipped/missed in situ. Maybe having it not interruptable is a way of separating these reports from other feedback that might be coming in. Like, if you hear the full report, you always know that's an auto?
Sidenote: hitting the "Quote reply" option doesn't populate the comment edit field here anymore. Had to assemble those quotes manually and it really sucked. Is this happening for anyone else? Maybe it's a change I missed.
Quote reply doesn't work if you press enter on it in focus mode, but it does work if you switch back to browse mode and press enter on it there. That's a GitHub bug, but at least there's a workaround (albeit an annoying one).
Note that it's not just multiple watchers we have to worry about. OSARA currently reports the channel (first chan, second chan) for sources which separate channels (currently only peak dB I think). That seems like it could be annoying for auto reports. Then again, could the user be confused by just hearing a random number with no context?
So maybe we also need to restrict this to a single channel? Alternatively, we can forego the prefix when only one is configured, but prefix when multiple (watchers or channels) are configured. This way, the user has the choice to auto report for multiple things (and we avoid the UX pain of restricting them), but the reports are still more efficient if the user only configures one.