DSP Robotics Support

Can't use it because i'm still without FS. But again an awesome piece of work!!
A big Thank you!!
Wish you all a nice Christmas.

Cheers, stw. Hope you're able to join in the fun some time soon.

Next update (v004) is now available in the top post.. New features...

- Probes are properly identified by their Ruby instance. So even if two probes have the same name, they will remain separate entities in the values lists. Probes now send a message whenever you edit the name, to make sure that the Current Values list is as up to date as possible.
- Probe outputs. Each probe now has an output which normally is just a copy of the input value. However you can also send an output value from the main Debug Application screen by simply clicking in the 'Value' column of the 'Current Values' display. So you can now inject test values into a schematic as easily as taking readings.For the MIDI data type, you can send either a list of the four parameters for a regular message status,channel,data1,data2 or a SysEx hex string.
- Switched to UDP instead of TCP as recommended by DWB. I have kept the IP address system as it is though - now that there is two way communication, I wasn't sure about using 'broadcast' mode (advice?).
- Little bit of code tidying.

Note that both the probes and application are now sending slightly different data than before (to include the instance ID) - so the modules from this version are NOT compatible with previous versions.

Heheh Tronic

stw wrote:Can't use it because I'm still without FS.

I've been using the demo to open .FSM files with no issues so far.

Has anyone tried to use this in an single FS instance with cascading editor windows please?

thanks trog! and a happy x-mas to you!
and all of you!

infuzion wrote:Has anyone tried to use this in an single FS instance with cascading editor windows please?

Since the last update, the probes are now unique (tagged by their Ruby instance ID), so you can have probes simultaneously in different schematics and they all stay live.
It really helps to give the probes in different windows different names though, just to tell them apart more easily on the debugger display.

However, after some more thorough testing, I have had the odd occasion where a probe has fallen out of the network and won't reconnect. I'm trying to get to the bottom of this - tricky, as it happens so rarely, but reliability needs to be top-notch for a de-bugging tool.
Replacing the 'dead' probe always seems to fix the problem, and I'm also working on network fault tracing from within the main application. A manual test can be done on suspected dropouts by sending out a value from the 'Current Values' table. The value is sent to the probe, but the displayed value only updates after feedback from the probe itself, so if a probe won't update, it is out of the network. Should be pretty simple to automate the 'handshaking' so that at least there is a clear warning of any failed connections.

Anyhow, that won't be for a couple of days - gotta go and get ready for Xmas dinner, and no doubt will not feel like doing too much programming tomorrow after all the boozing!

Best Wishes, all!

Version 6 now available in the top post.. Note that you will need to replace any modules from previous versions with these new ones, as the communication protocol has been extended.

New Stuff...
- Trigger order slightly changed to make logged events appear in the correct order.
- You can now reset just the trigger counts by clicking in the 'Counts' column of the 'Current Value' display.
- Selections in the Current Value and Events windows are now remembered until explicitly cleared by clicking the title bars.
- Ruby Probe and Console.

The new Ruby parts are still a bit experimental - but they add a couple of interesting ways to tap into the heart of any chosen Ruby module inside the schematic.
First, place a single instance of the "Ruby Probe" module inside the schematic. This creates a new Ruby module that allows the interfacing, using three simple commands...

Debug.watch ("Tag Name",value)
Works just like the regular FS 'watch' method, except that the output is directed to the debuggers 'Events' list. The 'TagName' string is optional - items will just get a generic "<Ruby>" label if it is omitted.
Debug.link("Tag Name",@this)
Creates a link between the Ruby Console and this Ruby instance. Note, you must pass both a Tag (string), and the instance variable '@this' (@this is a default instance variable that acts as a pointer to the current Ruby). The current Ruby is then added to the 'Ruby ID' drop-down of the Ruby Console. Select a linked instance using the drop down, then type some Ruby code into the upper Ruby Console window. When you press 'Send', that code gets executed within the targeted Ruby instance, and any return values or error messages appear in the lower console window..
Using this, you can view or set variable values within the targeted Ruby, or send values to its inputs and outputs, or even redefine methods (careful now!)
Debug.unlink(@this)
Removes the any links between the Console and the current Ruby primitive. Again, the argument must always be the instance variable '@this'.

NB) 'Debug; must always begin with an upper-case 'D', as it is a module name, not a variable.
Also, take care if you are using synchronised modules - if you use one of the Debug methods, the code will be copied into all of the sync'ed modules, creating lots of extra links that all have the same name!

Hmm. I'm having a bit of a rethink here now.

I notice a few people have downloaded the latest version - anyone had any problems with the network links getting lost?
I had noticed it a few times before; not often, but enough to make me think that it might not be a reliable enough way to do it. Certain operations, like cut and paste, dragging to the toolbox, seem to trigger the problem in particular.

A debug tool that itself is buggy is not really a very useful tool at all, so I think I will end development of the network version for the time being (v006). I'll keep it here, as the network comm's can be handy when you really need to stick probes inside a running .exe or VST export.

I'm most of the way there with a completely 'internal' version that uses only Ruby for communication - rather than an .exe, you run it within a second FS editor window. The displays all update just fine even if the Debugger isn't the current "in focus" window, so by tiling the editor windows you get the same "always visible" panel. So far, this seems way more reliable than the network connections, and also uses much less CPU as the code is much simpler, and there is no network latency.

Keep you posted - should have a first Beta to post very soon...

Wow, nice work trog!
As i will build complexer and complexer structures, i am sure this will come in handy.
CC

Thanks, glad yo like it.

Development's pretty much on hold at the moment, I'm afraid. The whole thing hooks itself into Ruby quite deeply, so with all the talk of trying to change the way Ruby works to make it more 'secure', I want to see which way the dev's decide to approach the problem.
If the underlying structure of all Ruby instances sharing the same class were to change, the new version I was working on would not work at all - and the current 'networked' version would actually be a better bet to continue developing.