At 02:46 PM 10/28/2012, you wrote: >>My understanding was related to the Event Loop timing on Windows, per William >>Wu, that it was limited to 15ms-20ms and no lower. So incoming MIDI events >>can be delayed by up to 25-30ms, just because of REAL's resolution for >>incoming events like callbacks. It's a huge problem, one I HOPE they'd >>address ASAP. Still nothing though.
>Actually the windows way seems to run a thread in an endless loop, sleep a >millisecond and check for events. No, what I'm referring to is that any REAL Windows app has a limit in it's resolution of responding to incoming events. This was confirmed by William Yu of REAL <feedback://showreport?report_id=14227> "This is just a note and does not in any way suggest that we will or will not do anything about it, but we could use Multimedia timers on Windows which will increase the timer resolution, but we would need to document the limitations (16 timers per process) and since these are threaded timers it may introduce some instability in our product. Right now we use the standard system timer which is documented (by Microsoft although we probably should also document it in our product too) to have a resolution of 10-15ms (although on slower computers this could be upwards of 50ms)." Please read the context of the Feedback ticket - it has to do with REAL's event loop as much as it does with Timers. This causes a big problem for people like me that have programs that deal with incoming MIDI events from external keyboards. When all is said and done, a sound starts usually around 25-30ms after you strike the key. That's an eternity in music time. Garth Hjelte Sampler User _______________________________________________ Mbsplugins_monkeybreadsoftware.info mailing list mbsplugins@monkeybreadsoftware.info https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info