billv wrote:the selectors are all ruby...
There's a
slim chance that it could be related to the Ruby components. FS 3.0.7 changed how the RubyEdit callback methods get called (e.g. event, draw, mouse methods, etc.) to support per-RubyEdit timeouts, and this is known to cause a memory leak and a lot of extra CPU load. This is the main reason that 3.0.6 is generally recommended over the later versions, despite the older 'global' Ruby timeouts being such a PITA.
I also noticed that the module "Ticker - Custom SEQ" uses 'scheduleMethod', and this too, has a bug which I reported a while ago which affects all of the FS 3.x.x versions since that method was introduced. If Ruby runs its 'garbage collection' routine while the scheduled method is pending, the arguments which are passed after the method name can get thrown away, so that they're not available when the method gets executed. It may be just a coincidence, but an access violation is exactly the kind of error which this might lead to. (NB: A workaround is to use the 'input' method with a time delay to schedule an event for a dummy input.)
It's a long-shot that either of those are the problem, as Ruby generally needs to be pretty low on memory before you'd notice any nasty side-effects from them; but given how many temporary drawing objects are created, it might be possible (NB: It's a lot better to create Pens/Brushes/Fonts etc. once at startup and re-use them rather than create them within the draw method - as I've said before, DSPr need a slap for providing such lousy code examples!)