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

Reply via email to