DSP Robotics Support

Hi!
I've made a simple knob with numeric parameter entry using RUBY module. Everything works fine in Flowstone. But there is a problem with test VST module using this kind of knob. It works only if the VST module has a signal on it's input. When I set it inactive or simply stop the DAW the numeric field doesn't react to the mouse clicks any more (the knob itself does). When playing with this problem I found that all RUBY modules are "frozen" in inactive VST plug except the ones connected to MGU module by video connector. But in described case createEdit command is placed in MGU connected module inside def mouseLDouble ***** end block and should work as far as I understand. Help me please to find, what's wrong or simply give me *FSM example with RUBY based numeric data entry which can be translated to correctly working VST-plug.

Thank you!

Extract the routine you speak of to a degree you can, post your schematic, so that others could help.

hello ortseam,

watch my example here:
viewtopic.php?f=3&t=2197

manual data input for the knobs too

you can find the knobs here:

viewtopic.php?f=3&t=641&start=50

knob 2.2 uses create edit in the label module

Nubeat7 wrote:watch my example here:
viewtopic.php?f=3&t=2197

Thank you! Tried to make VST module from your example. The same problem is present: numeric entry does not work if the plugin doesn't receive audio data (DAW is stopped).

UPD: the same with knob 2.2. It seems to be the FS bug ((

doesnt it update the values when changing it in stopped mode?

Nubeat7 wrote:doesnt it update the values when changing it in stopped mode?

It even doesn't call the editing field where you print the figures. BUT when you move the knob the number changes accordingly.

which DAW are you using? because on my machines with renoise 3 the editboxes are working (tested in the morning) cubase should work too, but i can test it in the evening because i`m @ work atm..

Nubeat7 wrote:which DAW are you using? because on my machines with renoise 3 the editboxes are working (tested in the morning) cubase should work too, but i can test it in the evening because i`m @ work atm..

REAPER. It has an option not to run VST effects when stopped. So to be clear I should say: not DAW run/stop state means but the plugin off/on state. Try to bypass your plug in Cubase and look at the result.

Confirmed here on Reaper - and 'createDropList' also has the same behaviour.

In most DAWs, plugins are still processed when the transport is stopped - so that you can still hear 'live' inputs monitored via FX etc. But the Reaper setting that ortseam mentioned allows plugins to be completely shut down while stopped so that they use a minimum of CPU time - and this makes the Ruby event timer go to sleep, because it is synchronised to the audio buffers. I imagine the same would happen in other DAWs that have a plugin "on/off" button that is independent of the FX bypass.

For some reason 'createEdit' and 'createDropList' must be using the Ruby event system, so they get affected by the shut-down. This is seen clearly when the plugin is 'woken up' again - the 'buffered' events spring to life, and any pending edit boxes or drop lists will suddenly pop up.

This is not good!
IMHO, the Ruby timer should default to its "no audio" 100Hz clock when audio is stopped. A dead GUI is simply not what the user expects - and the sudden re-appearance of 'stored' events when the plugin wakes up just adds to the confusion.
Worse still, if the user has been clicking like crazy to work out what the hell is going on, there could be so many 'stored' events that it blows the Ruby "excess processing" fuse - resulting in a completely dead GUI!!

Meantimes, there's not a lot of choice for a workaround...

- Don't turn off the plugins (but maybe there is a very good reason why you want to - and not good force other users of our plugins to change their preferences just to suit us!)
- Use the old 'green' dropLists and edit boxes (PITA if the rest of your GUI is in Ruby!)
- Somehow detect that the clock is stopped, and indicate to the user somehow that some features are locked under those conditions (Yuck!).

I'll pass this info on to the guys at DSPr to see if we can get them to fix it.

trogluddite Thanks a lot for your explanation! Everything is clear for me now.

ortseam wrote:I'll pass this info on to the guys at DSPr to add to their 'to do' list!

That would be very good! Thanks!