There is no check on windows in PlatformTimer::startTimer() to check that timeSetEvent() didn’t fail.
Perhaps we could have a jassert (timerId != 0); in there ?
I can have it failing pretty easily here: as soon as I start more than 16 HighResolutionTimers.
This limit can be quickly reached if you have a HighResolutionTimer or two in your plugin and create multiple instances of it.
perhaps we could have a kind of fallback to the PlatformTimer_generic implementation when that happens?
Yeah that might be a good idea.
Unfortunately that’s a hard limit from Microsoft.
Interesting idea, I hadn’t considered that. From memory the performance is significantly different though.
Although, if possible you might be best sharing a HighResolutionTimer between instances if you can, on macOS for example it uses a “Real Time Thread”, you don’t want to be making many of those in a plugin! If they all run at the same interval you could have a class that inherits from HighResolutionTimer and uses a ThreadSafeListenerList to manage listeners where each plugin adds itself. Maybe Use a SharedResourcePointer as a member of your processor to ensure you only ever have one instance of the object, and that it’s destroyed when the last instance goes out of scope.
Are you absolutely certain you can’t do what you want without a HighResolutionTimer? because that might get my vote otherwise.
thank you for your prompt reply Anthony.
Thanks for your suggestions as well, the SharedResourcePointer is a good idea.
But I’m also a bit concerned about what isn’t under my control also, like if the user loads 16 different plugins from different manufacturers and my highResolutionTimer stops working.
imh It worth adding to the startTimer() documentation that this can potentially fails. This can be circumvented, but we have to be aware that this can happen, I had totally overlooked that until now.
