Debugging Exported Ruby

[trogluddite]

I just had a PM from a forum member with an interesting Ruby problem. The Ruby code works fine when in FlowStone, but either doesn't get executed or fails somehow when its inside a VST export. Of course, in an export, there's normally no way to see if there's a Ruby error - there are no red borders to follow or RubyEdit error messages.

So here's a quick tip for how you might debug something like this - assuming that you know what code it is that isn't doing what you expect. You need to surround the code under test with a clause like this...

Code: Select all

begin

  #### CODE UNDER TEST HERE ####

  messageBox(0, "Code was executed")
rescue Exception => error
  messageBox(0, error.message, error.class)
  raise(error)
end


Ideally, you want as little code inside there as possible, to narrow down where the problem is. If the code under test is inside a method, make sure that the whole of the above code is inside the method definition.

Now, one of three things will happen...
- The code runs OK, in which case you get a messageBox saying so. The problem must be somewhere else.
- A messageBox pops up containing an error message (the box text) and error type (the box title).
- There is no messageBox at all - the code didn't even get executed.

This will work the same whether it is inside an export or inside FlowStone (and you'll still get red module borders etc. if the code fails) - so you can check whether the test code works inside FlowStone to make sure the messageBox works properly before exporting.

The second messageBox argument can be any String of text that you like, of course - so you can refine the debugging by creating your own strings to display - for example, including variable values that will help to narrow down the problem.

WARNING:
It is possible with this technique to get stuck in a loop of messageBoxes that you can't escape from if an error keeps happening repeatedly (say, if a ticker is triggering it).
ALWAYS SAVE A BACKUP OF YOUR SCHEMATIC FIRST!!!!

[shrunkyq]

Great read!

I just had a PM from a forum member with an interesting Ruby problem. The Ruby code works fine when in FlowStone, but either doesn't get executed or fails somehow when its inside a VST export. Of course, in an export, there's normally no way to see if there's a Ruby error - there are no red borders to follow or RubyEdit error messages.

So here's a quick tip for how you might debug something like this - assuming that you know what code it is that isn't doing what you expect. You need to surround the code under test with a clause like this...

Code: Select all

begin

  #### CODE UNDER TEST HERE ####

  messageBox(0, "Code was executed")
rescue Exception => error
  messageBox(0, error.message, error.class)
  raise(error)
end


Ideally, you want as little code inside there as possible, to narrow down where the problem is. If the code under test is inside a method, make sure that the whole of the above code is inside the method definition.

Now, one of three things will happen...
- The code runs OK, in which case you get a messageBox saying so. The problem must be somewhere else.
- A messageBox pops up containing an error message (the box text) and error type (the box title).
- There is no messageBox at all - the code didn't even get executed.

This will work the same whether it is inside an export or inside FlowStone (and you'll still get red module borders etc. if the code fails) - so you can check whether the test code works inside FlowStone to make sure the messageBox works properly before exporting.

The second messageBox argument can be any String of text that you like, of course - so you can refine the debugging by creating your own strings to display - for example, including variable values that will help to narrow down the problem.

WARNING:
It is possible with this technique to get stuck in a loop of messageBoxes that you can't escape from if an error keeps happening repeatedly (say, if a ticker is triggering it).
ALWAYS SAVE A BACKUP OF YOUR SCHEMATIC FIRST!!!!

[RJHollins]

Thanks TROG.

I've been following on the RUBY module issue that I've had happen ... the dreaded red outline error box.

It seems having to do that data has not triggered the RUBY module. Once I clear the error status ... the module works fine.

I've seen use of an AfterLoad trigger being added to the RUBY input module. Is this the only solution? Do we do every RUBY module?

This is a reason I went to FS 3.07. It does seem to have that similar issue [like 3.06]. The Ruby code is always fine [once I get it correct], it's the initialization at load up in FS that it shows up.

It concerns me ... though I can say I've had issue using the exported VST ... but ...

Thanks !!

[trogluddite]

I've seen use of an AfterLoad trigger being added to the RUBY input module. Is this the only solution?

There are two other ways. One is simple but doesn't always work. The other seems reliable, but requires editing the Ruby code.

Simple Method: Click everything, resave, and keep your fingers crossed!
You can manually make a trigger happen at an input just by clicking on the connector circle, so long as it has a link attached. The problem can sometimes be fixed by doing this for every single RubyEdit input and then resaving the schematic. In principle, this should ensure that the schematic is saved in a state where every input has a valid value "pushed" into it. However, sometimes it doesn't seem to work, or things break again a few editing sessions down the line.

Fiddly Method: Always use a Ruby "event" method.
I won't go into all the details of why the error happens or why this solutions works, as it would become a bit of an advanced Ruby tutorial. But it has to do with there being two kinds of Ruby code...

First type: Bare code where every trigger makes all of the code in the RubyEdit get executed...

Code: Select all

result = @an_input + @another_input
output result


Second type: Define methods [def <name> ... end]. Triggers only make the method named "event" execute...

Code: Select all

def event i, v, t
  result = @an_input + @another_input
  output result
end

def another_method
  # The code in here isn't called by input triggers.
end


The way I've written the "event" method above would normally be a bit odd - methods are usually used when you have more complex stuff to do than "bare code" can handle, so wouldn't look much like that. However, it does illustrate the other solution - wherever "bare code" is failing, edit the code to wrap it inside an "event" method.

The error seems to happen because the two kinds of Ruby code have to be initialised in different ways - and for some reason the "bare code" kind goes wrong and tries to run its calculations when there aren't any input values to use ("nil"). The "event" method style of Ruby always seems to work properly - so you can fix the problem by wrapping the code in between the lines "def event i,v,t" and "end" as shown above. Even then, you may still need to trigger the inputs after editing the code by clicking on them to make sure that they all have values saved in the schematic.

And finally, a caveat. I don't think that anyone has really got to the bottom of exactly why some RubyEdits are affected and not others, and the issue may well be fixed in the alphas by now. I can't promise that the above is the most optimal fix, nor that you wouldn't be doing a lot of unnecessary work if you rewrote every single RubyEdit just to be on the safe side. Caveat Emptor!

[RJHollins]

Thanks TROG.

Went into a suspect schematic, and the Ruby module that 'might' show an error, did NOT have the EVENT.

So I added def event i,v,t .... end

The error cleared out .... now to test.

Thanks for the explanation .... and the offered solutions.

[trogluddite]

Finger's crossed for you, RJ!

I should maybe add as well: Even RubyEdits which do use methods can have the same kind of problems with invalid inputs sometimes, especially if certain kinds of error happen while you're editing the code, or if you have "init" or "loadState" methods which are buggy. The "click all the RubyEdit inputs" routine is always worth trying if you have a RubyEdit which is complaining about "nil" input values, even if it's only to temporarily clear an error while you're trying to get a bug fixed.

[RJHollins]

Hi TROG,

Other than my, mostly, self inflicted errors I make with RUBY [well ... and most other things in life]

It's the reloading of a Schematic in FS that would ;newly] come up with that RUBY error [red box].

It really started happening in 3.06 [my up from longtime 3.04]. I then jumped to 3.07, and many of those spurious errors stopped happening. Going back to an earlier version brought that issue up again. Not rampent, but enough of a pain to have to find and reset a module.

Its why I was mostly going with 3.07

But then I read from You Guys that 3.06 is the best one ... why wouldn't I listen ?!?

I have some fun with FS. I like to follow along with many of the Topics and examples that are posted ... and I enjoy reading the discussions that You and the other learned Programmers talk [with what ever level of understanding I have ...]

It is a break for me from my Mastering work ... and a nice distraction.

I've been able to make some handy VST's with all of this. The main one I use is a Project Time Manager, that tracks the amount of Time that I'm Playing a DAW.

It Timestamps the start of a project, tracks the Play time [not just the ongoing Time that its on], which helps me determine a barameter of the exact time I spent playing/listening to a Track I'm working on.

It also calculates the Client Charges/Hr rate, and lets me save a LOG file specific to each Project.

This was something I needed, and was fun to put together ... and it works. It's one of those specialized tools that no one seems to have written [as a VST plugin] ... and it's in every session I do ...

It's be awesome to send it up to someone like you to critique/improve ... but .... You Guys on this forum have help me so much [over the years] just to get this working ...

It's a weird kinda fun, I admit.