Down the Ruby Rabbit Hole

[trogluddite]

NB: Please don't skip straight to the download. This is partly a little experiment, and you need to follow the instructions to get the most out of it. In order not to spoil the fun with erm... "spoilers", don't look inside the module until you've done the experiments.

Going through my old projects as I migrate to a new machine turned up some interesting things that I'd forgotten about, and I thought I'd present you with a little curiosity that I came across when delving into how Ruby is integrated into FlowStone.

If you open the little schematic that follows later, it seems innocent enough. It shows a little message saying that it's happy to be in your schematic, and shows the current running time of the schematic, as given by the Ruby time method, and the current system time. There's no redraw ticker, but you can force redraws by clicking the GUI or waving your mouse around to trigger FS workspace redraws.

Now try exporting it as a .exe file (remember where you put it, as you won't want to keep it!) Again, you can click on the GUI to make the executable redraw.
What does it tell you now?

Now try putting it in your toolbox (remember where you put it, as you won't want to keep it!). Expand your toolbox wide enough that you can read the text clearly, and force some redraws by wiggling the toolbox around.
And now?

What conclusions can you draw from its behaviour? (you're now allowed to look inside the module for clues!)

trog_experiment_1.fsm

(859 Bytes) Downloaded 747 times

[RJHollins]

Hi TROG.

Read through your post. Can't help but think I have a similar situation happening with one of my new FS project.

It all works fine in FS ... but when I export as a VST, and now in the DAW, I many times have to force a redraw to get the display to show on the GUI.

I've been trying various 'trigger' strategies ... not successful. I looked at triggering a ReDraw/refresh via the GUI primitive .... but I think the issue may be due to the RUBY code in this project.

Maybe this is not related to the example schematic you posted. That one has problems in FS.

Anyway ... I'll be following your thread.

[trogluddite]

It all works fine in FS ... but when I export as a VST, and now in the DAW, I many times have to force a redraw to get the display to show on the GUI.

The first thing I'd try is some "in-export" Ruby debugging - it could be that an error is occurring in the draw routine for some reason; for example, an instance variable that has an illegal value until some other part of the code is executed. The best way to check this is...
- Add an extra String output to the RubyEdit and connect it to a text viewer module that you'll be able to see on the GUI (label it 'debug' for the following code to work...)
- Add a rescue clause at the end of your draw method as follows...

Code: Select all

def draw(view)
  # Your drawing code here
rescue StandardError => error
  output 'debug', error.message
  raise error
end

If something goes wrong in your draw routine, you should now see the error message in the text box. You can test that it's working by putting the following line somewhere in your main draw code...

Code: Select all

fail("Error handler is working!")

This can be a useful technique even within FS, as the error message will persists at the String output even if a subsequent, successful redraw clears the error from the RubyEdit's own watch panel - transient errors can easily be hidden this way.

To go back to my little experiment...

Firstly; yes, it does demonstrate just how often the FS workspace generates redraws of its own, and these can confound the debugging of redrawing problems in exports or experiments in optimising redraws.

Secondly, it shows that the toolbox is not using embedded or cached thumbnails of any kind; every time a custom module appears in the toolbox which has a GUI, the module is loaded, compiled, initialised, and has its drawing routines called. From a coding point of view, that makes sense; the code for doing that is obviously already present in FS. However, it does mean that the toolbox is rather inefficient, and more problematically, that any critical bugs in a toolbox module get the opportunity to crash the whole FS environment.

For example, on my system (FS 3.0.8.1), if the Ruby method schematicLocation gets called by a module in the toolbox when it initialises or redraws, it will crash FS completely - and you can't delete the offending module from within FS, as making the module visible there causes the crash! This was part of my reason for looking for a "are you in the toolbox?" test (and I discovered that the time method always returns nil in this case.)

Thirdly, and with big implications for Ruby, it means that RubyEdit instances can get created and initialised, and have their methods called, when shown in the toolbox. This mean that they are part of the global Ruby namespace that is shared by all RubyEdit instances. If a toolbox module defines a Class, Module, global variable, or constant, then as soon as you scroll past that module in the toolbox, those things might be defined across the whole FS environment. If your current schematic happens to define any of those things differently, tough luck; they might get overwritten just by scrolling past a toolbox module that you're not even using within the schematic.

As I have complained in the past, the power of Ruby in FS seems very hobbled to me because the implementation makes using custom Classes, Modules, and external libraries so difficult. Unfortunately, this "toolbox effect" means that the Ruby namespace isn't necessarily "clean" even when you have only one schematic open, thus confounding this problem even further.

One last observation. In the experiment, I showed how a RubyEdit can sense whether it is in the toolbox, in a schematic, or in an export. There's a fourth situation that, as yet, I have found impossible to detect reliably - a RubyEdit which has been deleted from the schematic, or belonged to a schematic which has been closed. These don't get deleted straight away; it all depends on what the Ruby garbage collector decides. In fact, if they include, for example, Ruby tickers, which work by having a RubyEdit send events to itself, they will happily carry on running in the background even though they aren't connected to anything any more!

Unfortunately, this proved to be the downfall of another old project - a suite of Ruby debugging tools. These required access to RubyEdits that bypassed the FS event system; but debugging messages from RubyEdits that you think you've deleted could make them more confusing than helpful!

[tulamide]

I made similar experiences, when working on my "advanced color management" project. It wasn't without Ruby trickery that I managed to implement a server-client structure, so that the "server" module stays on the top layer, while the clients can be placed anywhere in the schematic and instantly connect to the server to get their data. It involves calls to object id and such.
I even worked hard to get it to copy into the toolbox without crashing. But now, on FS4 alpha, the newer Ruby 2.5 is used and of course they crash again when trying to copy them into the toolbox.
For some time now I hoped that schematics would be sandboxed, as far as Ruby is concerned, but it seems to be too difficult.

Another aspect is security. Ruby is powerful enough to do serious damage when in the wrong hands. Since many people here use FS because they don't want to program, chances are they wouldn't understand Ruby code. Ruby code that executes each time you open Flowstone, imagine that! Which leads to a general warning: Only download code from trusted sources!

[wlangfor@uoguelph.ca]

Hi fellas, ruby can be a pain I know, I’ve had the saddening realization that ruby can prevent a vast load. Thanks for Your contributions Trogluddite they’re hella handy.

[wlangfor@uoguelph.ca]

Hi, I didn't have time to post and I hope mine didn't seem overly negative.

Perhaps I think CSS3 is a better visual formatting aid, but all the same Your Ruby work is amazing. I loved Your image maker and I think there is hope for Ruby assuming that there is a way to delay the loading of Ruby; Especially when it comes to visual formatting.

I had not had time to attend to Ruby but that is about to change and I have a great deal of experience troubleshooting code so I will try and help.

Thanks for Your goniometer and slow trace meter Master Trog; amazing.

BTW: solved the oversampling issue. Look in the shelf EQ; It has a timed switch for on and off with two streams. It up mixes and then down mixes when off and only shuts off when off to avoid feedback. Means no crash. Enjoy that.

Also, making a three state fx sort without ruby for the time being.

http://dsprobotics.com/support/viewtopic.php?f=2&t=14696

[trogluddite]

Hi, I didn't have time to post and I hope mine didn't seem overly negative.

Oh no, not at all; I've voiced my own concerns about the rather sparse Ruby API and inability to elegantly handle library loading many times in the past (not to mention the non-hardware-accelerated GDI graphics implementation!)

Thanks for Your goniometer and slow trace meter Master Trog; amazing.

You're welcome! I notice from your other posts that you're fastidious about giving credit where due - always an admirable trait!

[lalalandsynth]

Interesting ,FS is always crashing for me because of "something" in my toolbox, some things I cannot enter into the search or it will crash , some toolboxes are off limits . Havent had the patience to track down exactly what are the offending modules.