Turning off "Excessive processing detected" possible ?

[mccy]

Is it possible to turn of the "Excessive processing detected" effect, that it turns of all ruby?

I have no bad loop inside my tx2sfz converter, but indeed excessive processing when translating big programs(maybe because of my low programming skills I do some things rather complicated), so when about 300 samplegroups in a Tx16Wx file are analyzed the program quits... but it would finish, if it had more time, am I right? Just reducing samples in Tx16Wx makes it possible again. I managed to load some bigger files when turning of some scannings in the converter, but I'd like to turn off that safety mode, because it shouldn't be dangerous to give the cpu some food...??!! Or is it!?

[nix]

I'd like this option too.
It could be on by default,
but a checkbox in options would be cool.
I always watch my processors in task manger,
so I can manage the consumption manually.

[trogluddite]

+1
Maybe an option to set our own 'time out' duration, so we can 'balance' the protection to what we need.

[Jay]

+1

even if there was a way of having it not shut down every ruby module in a schematic just because of one you are working on! its a pain in the ass having to restart all the ruby components again!

[support]

See your points here. This is something we put in as a failsafe but it could do with being more flexible. I'll note down that this needs to be looked at.

[trogluddite]

Thanks, that would be great.

[mccy]

Great! Thanks!

[Jay]

Thanks Support!

[MyCo]

This "Excessive processing detected" rescued my schematics several times. Otherwise I had to start from last saved schematic. Even with the option, I wouldn't turn it off, because FS could lock up. Eg: just type "redo" in a RubyEdit, and you can start from scratch.

[trogluddite]

I'd certainly keep it turned on most of the time in order to have that safety net.

But there are situations where the current behaviour gets in the way - for example, calling an external function that takes a long time to return, or waits on user input.
Likewise in mccy's case - it seems to be 'timing out' on the Ruby protection rather than generating, for example, a stack overflow. Possibly his code could be tightened up as he suggests - but that would only raise the threshold for the maximum file size that would parse; there would still be an upper limit if time is the critical factor.

In a cases like these, there needs to be some way of letting FS know that the "excessive" processing is intentional and not the result of a programming error. Of course, the onus is then on the programmer to be aware of what the side effects might be (hundreds of Ruby events queuing up for access to the parser, for example) - so I would certainly not advocate turning it off as a routine measure!!

For this to work, it would certainly have to be a "per schematic" or, better still, "per RubyEdit" feature. I would be very concerned if it was implemented as a global option - that would not be wise move at all.