Hmmm, isn't this what MCWS is for?
https://wiki.jriver.com/index.php/DevZone
Nope.
Too much latency rendering MCWS useless for accurate DSP plugin development.
Not sample accurate.
It also requires constant polling, which is very wasteful of system resources versus individual state change notifications.
Polling maybe suitable for initial DSP startup initialization, but falls apart at runtime for DSP.
If one is interested in 3 parameters, it equates to polling 3 web calls for every frame @ 768kHz ( 3 x 768,000 poll calls per second when not necessary ).
Does that make sense versus making a single notification, ONLY when a specific parameter of registered interest changes ?
Which would have a better chance of running on a RPi ?
Might be fine for updating a skin or displaying a title and track every 5 seconds, but not for frame accurate DSP state transitions.
It brings back nightmares of watching DOS programmers trying to code multi-IO port comm code on a preemptive multi-threaded RTOS using polling and then wondering why their throughput is so low and client latencies are so high causing comm timeouts, magnified retry counts and further network bottlenecks.
All they had to do on the RTOS was to register an interrupt callback on each of the IO ports and then go to sleep with no polling overhead waiting for IO to arrive on the respective ports and be processed in proper FIFIO order.
They decided to stick with their DOS centric polling "solution" and their work product painfully reflected their inferior design choice to the detriment of all features that used their comm interface.
In short, polling(MCWS) is the wrong tool for realtime DSP.