Plugin disabled = Ruby disabled

[matti]

I've noticed that there's a slight bug or oddity in FS, which might be about some threading stuff again.

When the audio stream is disabled(the plugin disabled but GUI still shown) everything else works, except for the parts that are made with Ruby(GUI stuff etc). This kind of brings out again the issue of threading that's a bit wonky on other parts of FS too(Midi). There needs to be a distinct line drawn between realtime and non-realtime tasks! This along with VstParameter ordering are the biggest shortcomings of FS at the moment. Something absolutely awesome made to be adequate with just a few tiny snags on the way.

FS team! Kick yourself to do something about these

[trogluddite]

Good spot, matti.

Think you're onto something - when no audio is running inside the FS editor, Ruby defaults to a 100Hz clock as its timing reference.
But I just tested a simple export - 'custom ticker' + 'trigger counter' as a VST, and it seems that without incoming audio samples to count for the timing reference, Ruby events just stop - there's no 'fallback' timer as there is inside the FS workspace.

I can see why counting the samples in real time would help keep the timing stable, but I think it would be better if there were a "free running" clock to take over if the audio stops.

This should be tested some more - I'm wondering what would happen if a 'green' user interface, or preset changes scheduled new Ruby events. I'm guessing that they would be cached, and would then get processed when the Ruby clock restarts - (the custom ticker restarts as soon as audio is restored).
It could lead to some strange side-effects if green events still continue to be handled in real time - not to mention, very confusing for the end user. For example, a queue of scheduled MIDI events would freeze when bypassed, and then be output after audio restarts.

[trogluddite]

Yes, it seems to be as I said in my previous post - Ruby events are buffered until the clock restarts.
Here's my very simple test rig - just a 'green' knob going via Ruby with a trigger counter...

Ruby VST Events Test.fsm

(126.28 KiB) Downloaded 1025 times

With audio running, the value just passes through, and you can see the triggers being counted.
Now bypass the effect, then go bonkers with the knob - no output triggers.
Turn the effect back on.
Whoa - all those triggered Ruby events now get output at once, and the trigger counter jumps up in value massively.

This is worrying - not only the sheer number of triggers coming as a big flurry, but potentially, there could be enough Ruby events to blow the "excess processing fuse", which might disable all currently open Ruby-dependent plugins.
I haven't actually been able to make that happen so far, but maybe I just haven't had the patience to waggle the knob for long enough!
I'll let "support" know the results of these tests - I think this is a really important one to address.

[MyCo]

Have you reported that to Malc? Sounds like a serious bug to me.

A solution would be a timeout in the VST bufferswitch. Like this in pseudo:

Code: Select all

BufferswitchMethod {
  stop 100Hz Timer
  clear Timeout
  set Timeout 10ms
  ... do other code
}

onTimeOut {
  start 100Hz Timer
}


[matti]

Whoa - all those triggered Ruby events now get output at once, and the trigger counter jumps up in value massively.

Just imagine having this behaviour on a host automated vstparameter.. NOT good.

The point of having Ruby tied up to the audio stream is pretty odd to begin with. It's not supposed to be doing the audio processing. There's the Code and Asm primitives for that. But i know it has something to do with the new timing system.. which doesn't seem to be that useful anyway. Even if you can do things with great timing precision, they are too cpu intensive to be used in real life. Ruby is great, but not for the things it tries to do right now.

Devs, please comment.

[trogluddite]

Have you reported that to Malc? Sounds like a serious bug to me

Just preparing some examples for Malc now.
EDIT: Now Reported.

Even if you can do things with great timing precision, they are too cpu intensive to be used in real life.

Depends what you want to do - although stream processing with Ruby isn't cool, it does mean that MIDI events can be scheduled with exact sample precision. So it's not necessarily about being able to process a large number of events, rather the ability to schedule a small number of events to happen exactly when you want them to.
What other timing standard for the clock could be used? We know that Windows timers are hopelessly inadequate, so that leaves only the sample rate or the system clock. But the system clock doesn't send events, it needs an explicit call to read the value, whereas the sample rate can be easily derived from the ASIO/VST buffer requests.

But, there does need to be a fall-back if those buffer requests stop coming - I think we can all agree on that, whatever we want to use Ruby for!

[matti]

Well.. I wan't to do controlling of midi devices from a vst-plugin.
Works quite nicely so far, even though FS is trying it's best at stopping me

I noticed the Ruby bug when i disabled one of my controller plugins. All the Gui parts that were made with Ruby froze. Everything else worked.. graphics, mouse control, loading files and even sending midi. I didn't notice the buffering thing as i've built everything in a way where i can control all the triggers movements. A buffer being unloaded would just hit my trigger blocks.

Oh wait. The buffering issue was happening with Midi too, if i recall. That's why i needed to do all blocking of midi signals before they were generated.

Btw, i still do everything Midi or VstParameter related with windows timers as Ruby can't be used with them.

[trogluddite]

potentially, there could be enough Ruby events to blow the "excess processing fuse"

Worst fears confirmed - if there are enough queued events while bypassed, Ruby will bomb out when audio is restored, totally disabling the plugin. (and even making the Ruby knob in the test rig disappear from view completely!!)

Other FS plugins open at the same time are not affected though - the separation between each plugin's clock is preserved, and the Ruby "fuse" prevents the lock-up from propagating.

[Tzarls]

Other FS plugins open at the same time are not affected though - the separation between each plugin's clock is preserved, and the Ruby "fuse" prevents the lock-up from propagating.

Other plugins...as in "different plugins also built using FS" or "other instances of the same plugin"... or both?

[trogluddite]

"different plugins also built using FS" or "other instances of the same plugin"... or both?

Both.
I tried it with a few instances of the test rig and a couple of other FS VSTs, and only the instance that has been bypassed and fiddled with crashes.
That is good at least - it shows that the 'protection' works well to isolate the problem in once place.