I was about to request something like this as well and been thinking about this for some time.
But less for "just" some debug-messages, but for a more generalized approach, so JSFX-coders could send filterable accessibility-messages too(or output debug-messages, like RichCaloggero wants to do).
Basically, what you need is an additional way for messages to be send, that is completely independent of any gfx-stuff.
You also need a way to separate useful and important messages from less important ones, to reduce the information sent.
UI's can show much more at the same time, than a description can say, so a way to filter out messages by some criteria
would be important.
So here's what I have in my mind, that might be an attempt to do it(and it has similarities with Justin's approach).
1) On FX-side:
I think, there should be an internal messages-log, that could be filled by JSFX/Video Processor/ReaScript/Cocko's VST-extension.
In JSFX for instance, you fill it by setting the variables #acc_description and acc_priority(more on priority later) and acc_message_changed.
This adds a message to an internal logger.
This logger logs:
- the description sent(acc_description)
- the priority(acc_priority between 0(low) and 10(high))
- the time of the log(like reaper.time_precise())
- guid of the jsfx that logs.
And it logs it everytime, when acc_message_changed=true(so the log wouldn't get spammed with 15623 versions of the same message, unless wanted to).
2) On API-side:
The API gets a function to access this internal log:
Something like this:
Code:
string message, integer timecode, integer priority = reaper.GetFXMessage(string fx_guid, integer message_log_index)
This can be used by extensions(Osara) or ReaScripts to get the sent messages, show them, filter them by priority, specific jsfx, message-content, time-range, etc.
And when they know, which message is wanted, they put it onto screenreaders, etc.
3) Filtering messages, using the information in the log:
Now, as I said, reducing and filtering the messages is important to prevent possible information-overkill.
With a log like that, this filtering can be done by Osara itself, with an interface designed for reducing messages
to the most important ones.
For this, we have multiple things we can filter for:
First, the fx itself. Second the message itself. Third, the message-priority. Fourth, the time-codes.
a) The FX itself:
This is simple. If you want to get only the messages of the currently opened JSFX and ignore the rest, you get
the guid of the fx and just get the messages of it.
That way, all JSFX can send messages, but I just see the one visible or even in focus.
Or I want to monitor messages of a certain JSFX I'm currently testing, how it works in combination with other FX,
no matter if the JSFX is visible or not.
The same way: get the JSFX's guid and get its messages only.
Means: reducing messages by specific JSFX.
b) Priority:
But what if I want to monitor multiple JSFX at the same time? They might constantly send messages, some important,
others not.
For instance: you have a JSFX, that monitors, if at certain frequency-ranges you have clippings.
It might want to send a message of "everything is fine and under xx dBa" constantly and once in a while
a "OMG, CLIPPING ALERT!"-message.
Now, getting the constant "everything is fine"-message written on your screenreader is tedious. You might want
to check this once in a while to get the current dBa-value but not constantly, so such a message is of low priority.
However, a "OMG, CLIPPING"-message is more important and you might want to know this instantly, so such a message gets
a higher priority.
So JSFX-coders, who want to send messages, can use the variable acc_priority to give the sent message a priority.
That way, the accessibility-user can set a threshold of messages, that they want to know instantly and those, they just get when needed.
The threshold being the priority and therefore importance.
Reduces the amount of messages and seperates between "give me instantly" and "I get them, when I want to".
c) The message itself:
This can be used to sort by keywords etc. So if all sorts of messages are sent via JSFX, but you want to have only a
handful of them in your message-list to check for, you can enter filter-keywords, that allow you ignoring messages by
content.
That also reduces the information in the most custom way.
d) The timecodes:
as the log logs the timecode as well, it would be possible to filter out by timecode too.
So Osara or a ReaScript monitors, when the user hits play and when the user hits stop afterwards. So getting
all messages inbetween play and stop, filtered by the criteria a-c, would allow even more reducing.
Now, if such a message-queue is available, extensions like Osara could provide an interface, that allows filtering such things in
the most accessible way. It also means, Osara can decide, what to output and what not.
I'm still thinking about, how to extend this message-queue-attempt to ReaScripts as well(script-instances have
no guid and therefore it's hard for Osara to get, which script is talking to a message-queue and which is the
currently focused one, when using gfx-windows).
But for JSFX, this would allow tons, already. Especially, as currently, there's no way to output any accessibility-messages
at all, so all JSFX relying completely on UI(monitoring JSFX that only "draw" the states" for instance) are pretty
useless for accessibility-users.
And all it needs is a log, that can be filled by fx with message, priority, logtime, fx-guid and accessed via API.
(Sorry for the long novel-like post

)