DSP Robotics Support

A little while back, a few of us were discussing the hassle of navigating around a schematic when debugging, and Spogg said something that I've long thought myself...

Spogg wrote:It would be really nice if we had two simultaneous views available: one for the highest level - the front panel, and one for diving into the schematic. Often I’ve had to put readouts inside modules then go to the front panel to see what’s happening, or sometimes put knobs and such into modules so I could emulate the front panel for testing and de-bugging.

Maybe be a letter to Santa?

Well, I've a way to go before my beard will reach Santa-sized proportions (though it's just about the right colour), and magicking up a split view is something only the developers can really do; but I did spend the Xmas holidays getting back to a long-dormant project very much along those lines - the "Trogtools Schematic Watcher"...

As the filename suggests, this is still rather a work-in-progress, but I've found it useful enough in a couple of my other projects that I thought it was worth seeing what anyone else made of it (NB: If you save the file with a new name using "Save as...", you have to close FS and re-open the file).

There's a main viewer module with two views - an "events" time-line of incoming triggers/events in the order received, and a "traces" view showing a selection of current values and trigger counts. A bunch of little 'watcher' modules that you wire up just like trigger counters determine what you want to watch. There are no "wireless rules"; both GUI and 'watchers' can be anywhere in the schematic, and you can even have multiple GUIs in different places wherever you need to see what you're doing - the only limitation (feature!) is that they all have to be within the same schematic.

You can watch all of the common 'green' values, audio streams either as raw values or as audio-level meters, MIDI messages, and even Ruby code via a little extension to the 'watch' method (which is where I stole the name from!) Triggered events can also open messageBoxes ("popups") for when you really don't want to miss something. The schematic contains examples of how to use most of this, and a 'user guide' module contains more detailed instructions.

I've only tested in FS 3.0.6 so far, so "caveat emptor", of course; but any and all feedback would be gratefully received, as like all developer tools, it does need to be particularly sturdy and I'm bound to have missed many things!

I just had a short look (using FS4, no crash so far ), so expect no helpful report.

I just wanted to quickly say how much I enjoy for once having a look at clean, tidy and documented code. Mostly Ruby code is not even indented, when there is a call for help, and that makes it so difficult to follow the logic of the original coder!

I wish, more people than just you, TheOm and me would take care when writing Ruby code!

And to you guys, reading this and asking yourself, what the difference might be: Going through this code is like a walk in the park, relaxing and fun while the sun shines bright. Normally I go through other peoples' code like in a blizzard in the dark, freezing and uncomfortable

That is very cool.

tulamide wrote:I just wanted to quickly say how much I enjoy for once having a look at clean, tidy and documented code. Mostly Ruby code is not even indented, when there is a call for help, and that makes it so difficult to follow the logic of the original coder!

I wish, more people than just you, TheOm and me would take care when writing Ruby code!

And to you guys, reading this and asking yourself, what the difference might be: Going through this code is like a walk in the park, relaxing and fun while the sun shines bright. Normally I go through other peoples' code like in a blizzard in the dark, freezing and uncomfortable

Is something like this usable in the FS environment?
https://arachnoid.com/ruby/rubyBeautifier.html
It won't improve bad logic, but would at least make it more readable.

(I just love that opening line:
"I have always felt that a language hasn't really arrived until there is a source beautifier utility for it.")

This thing looks amazing trog!
I haven’t tried it yet but I will.

Since I know only a few basics in Ruby would it be possible for you to speak generally about how it works? Just an overview…

Cheers

Spogg

tulamide wrote:I just wanted to quickly say how much I enjoy for once having a look at clean, tidy and documented code. Mostly Ruby code is not even indented, when there is a call for help, and that makes it so difficult to follow the logic of the original coder!

Thanks, tulamide. As I'm sure you well know yourself, the untidiness of many people's code (and schematics!) is often why they end up asking for help in the first place! People seem to forget that high-level languages aren't there to make code easier for computers to understand (ASM does just fine for CPUs!) - they were intended to help us write code that humans could understand! Ironically, in my private life, I'm just about the most untidy, disorganised person you could ever meet - but I learned long ago that the refactoring stage is often when I get to truly understand my own code.

deraudrl wrote:Is something like this usable in the FS environment?

Not directly, I don't think, as we don't have any way to patch scripts or "macros" into the RubyEdit's embedded code editor. In principle, the script could be written into the "parse" method which gets called when we tinker with RubyEdit code, but it would drastically slow down the "real-time compilation" that the RubyEdits use (though personally, I don't like that "feature" very much anyway, and I always write any code longer than a few lines in Notepad++ - if only because the shortcut keys are now burned into my reflexes, and I prefer a black background so I don't get a migraine!)

Spogg wrote:...would it be possible for you to speak generally about how it works?

It actually works very much like the passing of 'events' to RubyEdits that FS uses internally.

- Not every object in Ruby "belongs" to a RubyEdit, some are held in the general Ruby "namespace" within classes and modules; in this case, a custom class "Trogtools::SchematicWatcher". Each instance of this is simply a couple of containers for little 'Event' and 'Trace' objects which store the label, value, colour, etc. of each watched event. Storing (almost) everything in the 'Trogtools' classes keeps them safely tucked away out of sight of the rest of Ruby ("encapsulation" in object-oriented lingo).

- To keep schematics separate, there's a SchematicWatcher instance for each schematic, stored in a Hash indexed by the 'schematicLocation' data (folder and filename - hence the need to shut-down/re-load after changing the file name). If there isn't a 'schematicLocation' available, then a module knows that it's in the toolbox, so shuts itself down completely and doesn't even bother defining the classes that it needs (there is no 'Trogtools' module when there are no watchers being used).

- Each time a 'watcher' is triggered (or a custom 'watch' method call is made), the SchematicWatcher for the schematic is looked up, an 'Event' or 'Trace' object is placed in the appropriate queue, and a counter is incremented. The customised 'watch' method is an example of "monkey patching" - re-defining something in an existing class (hopefully without breaking its normal behaviour - there's nothing in Ruby to prevent you from re-defining addition methods to subtract!)

- The main GUI is driven by a ticker. At each tick, the GUI checks the schematic's SchematicWatcher to see whether there's anything new on its queues by comparing the counters against their last known values. If there's nothing new, it just exits without doing anything. If there is, then it updates its display of whatever is in the queues.

- Each little 'Event' or 'Trace' object has its own 'draw' method, which is passed a View and a target Area by the GUI. So the GUI doesn't need to know how to draw each different kind of item; they do it for themselves. Each data type can have its own specialised kind of 'Event' or 'Trace' object, which is the key to making it easy to customise how each different kind of data appears without needing a huge chain of decision making code to sort out which drawing routine to use ("polymorphism" in OO-speak - objects which look the same to the calling code because they have the same method signatures, but which work differently inside).

The most tricky stuff is the drawing optimisation - caching as much data as possible on the first occasion that an event draws itself, and determining which events are outside the scrolled view area, so that the GUI's main draw routine has as little work as possible to do.

Thanks for that trog.

I think I have a sort of general idea now, but don’t ask me to repeat it back to you!

Cheers

Spogg