Debugging Tool V006
Posted: Sun Dec 23, 2012 7:48 pm
Seasons greetings, everyone.
Couldn't let the Xmas holidays go by without posting up a little present for you all - so here's a little tool I've been working on that I hope you'll find useful.
You know that thing - you're trying to debug a schematic, so you put in a load of little boxes so that you can read some values. But they're all on different levels of the schematic, so you can't see them just at the critical moment, and miss the very event you were looking out for as you stumbled in and out of nested. sub-nested, sub-sub-nested modules.
GRrrrr....
So how about a little window that you can stick elsewhere on your desktop that can show you your 'test probe' values no matter where you are looking in the schematic....
DOWNLOAD:
NB) Before downloading, you might want to read THIS.... If you need the ability to monitor running vst or exe exports, this is still the version to use - but it is not 100% reliable. A better version, but only for monitoring schematics within the FS editor, is on its way soon.
There are five modules included...
1) Debugger Window. Export this as an .exe file, then open the .exe and stick it somewhere visible whenever you need to do some de-bugging.
2) Debug Probe (green). Stick one of these anywhere in your schematic that you want to test a 'green' value. Don't worry about the string input; most other data types will automatically convert to strings, so other types aren't really needed. Each one has a 'Tag' box where you can name it for easy identification - individual probes are always 'unique' even if the names are the same, and you can rename at any time. The probe output is usually just a copy of the input, but you can also type values in the main Debug application and have them sent as 'test signals'. You can use just the module's input or output, or use both together.
3) Debug Probe (stream). Just the same for streams, except there's a little on/off LED, and a setting for how fast you want the stream values to be sampled.
4) Debug Probe (MIDI) - sends a text description of incoming MIDI messages. Extra data (e.g. velocity, channel) can be seen if you examine a message in the 'Value' viewer window. To send midi from the main application use either a comma separated list 'status,channel,data1,data2', or enter a SysEx hex string (including the F0 and F7).
The Debug .exe application starts a network server, to which each sender connects - so that data can be sent regardless of position in the schematic.
5) Debug Probe (Ruby) - this acts as a 'gateway' for other Ruby instances to communicate with the de-bugger. It adds a new Ruby module called "Debug" with methods for outputting values to the Debug events list, and for linking a Ruby instance to the 'Ruby Console' from where you can execute commands in the context of any chosen 'linked' Ruby editor.
The main app' also has a couple of other tricks up its sleeve...
CURRENT VALUES window
- The 'Current Values' area shows the values of all currently monitored 'senders'.
- And a count of how many events have been received - clear either main view window to reset the counts to zero.
- Click the labels bar to clear the list and start afresh.
- Click tag names in the list to select them. CTRL and SHIFT can be used for regular windows style multiple selections. The Events list (see below), will now filter the incoming events to show only the selected values.
- R-click the tag names area to remove the selection, and see incoming events without filtering.
- The latest incoming value is still shown in the 'Current Values' even for filtered out data.
- Click a value in the 'Values' column to enter a new value, which will be sent to the probes output connector.
EVENTS window
- Shows incoming events, timetamped with the system time when they happened.
- Click the label bar to clear the current data.
- Some values aren't going to fit inside the little columns (e.g. arrays, long strings). No problem - click a value to highlight it, and it will appear in all its glory within the large 'Value' window.
- Max.events sets how far back you want data to be remembered.
RUBY CONSOLE
- If you have a Ruby probe module inside your schematic, you can then link any Ruby editor to the console using the method "Debug.link('TagName',@this)". A reference to this Ruby instance will then appear on the Console's drop down list of Ruby ID's. You can now enter a short chunk of Ruby code into the upper of the two Ruby console windows. The code will be executed in the context of the chosen linked Ruby instance, and any return values or error messages are directed to the lower console window.
For example - typing "output 0,'Hello'" and sending this to a linked Ruby instance will output 'Hello' on the first output of the targeted Ruby editor.
I've tested on both my machines without any problems - though bear in mind that your firewall settings etc. could disrupt the network link - and I have very little experience with these kind of connections!! If you get a pop-up box warning you about opening the connection, click to allow the connection and this should be remembered for next time.
A small file and folder is saved inside your 'Application Data' folder - this is used to store the IP address allocated to the main program, so that the senders are able to find the correct IP and port addresses.
All bug reports and suggestions for improvements will be gratefully received - just post a reply to this thread, or PM me.
Best Wishes
Trog Luddite
Couldn't let the Xmas holidays go by without posting up a little present for you all - so here's a little tool I've been working on that I hope you'll find useful.
You know that thing - you're trying to debug a schematic, so you put in a load of little boxes so that you can read some values. But they're all on different levels of the schematic, so you can't see them just at the critical moment, and miss the very event you were looking out for as you stumbled in and out of nested. sub-nested, sub-sub-nested modules.
GRrrrr....
So how about a little window that you can stick elsewhere on your desktop that can show you your 'test probe' values no matter where you are looking in the schematic....
- Debug Screen.jpg (137.98 KiB) Viewed 28516 times
DOWNLOAD:
NB) Before downloading, you might want to read THIS.... If you need the ability to monitor running vst or exe exports, this is still the version to use - but it is not 100% reliable. A better version, but only for monitoring schematics within the FS editor, is on its way soon.
There are five modules included...
1) Debugger Window. Export this as an .exe file, then open the .exe and stick it somewhere visible whenever you need to do some de-bugging.
2) Debug Probe (green). Stick one of these anywhere in your schematic that you want to test a 'green' value. Don't worry about the string input; most other data types will automatically convert to strings, so other types aren't really needed. Each one has a 'Tag' box where you can name it for easy identification - individual probes are always 'unique' even if the names are the same, and you can rename at any time. The probe output is usually just a copy of the input, but you can also type values in the main Debug application and have them sent as 'test signals'. You can use just the module's input or output, or use both together.
3) Debug Probe (stream). Just the same for streams, except there's a little on/off LED, and a setting for how fast you want the stream values to be sampled.
4) Debug Probe (MIDI) - sends a text description of incoming MIDI messages. Extra data (e.g. velocity, channel) can be seen if you examine a message in the 'Value' viewer window. To send midi from the main application use either a comma separated list 'status,channel,data1,data2', or enter a SysEx hex string (including the F0 and F7).
The Debug .exe application starts a network server, to which each sender connects - so that data can be sent regardless of position in the schematic.
5) Debug Probe (Ruby) - this acts as a 'gateway' for other Ruby instances to communicate with the de-bugger. It adds a new Ruby module called "Debug" with methods for outputting values to the Debug events list, and for linking a Ruby instance to the 'Ruby Console' from where you can execute commands in the context of any chosen 'linked' Ruby editor.
The main app' also has a couple of other tricks up its sleeve...
CURRENT VALUES window
- The 'Current Values' area shows the values of all currently monitored 'senders'.
- And a count of how many events have been received - clear either main view window to reset the counts to zero.
- Click the labels bar to clear the list and start afresh.
- Click tag names in the list to select them. CTRL and SHIFT can be used for regular windows style multiple selections. The Events list (see below), will now filter the incoming events to show only the selected values.
- R-click the tag names area to remove the selection, and see incoming events without filtering.
- The latest incoming value is still shown in the 'Current Values' even for filtered out data.
- Click a value in the 'Values' column to enter a new value, which will be sent to the probes output connector.
EVENTS window
- Shows incoming events, timetamped with the system time when they happened.
- Click the label bar to clear the current data.
- Some values aren't going to fit inside the little columns (e.g. arrays, long strings). No problem - click a value to highlight it, and it will appear in all its glory within the large 'Value' window.
- Max.events sets how far back you want data to be remembered.
RUBY CONSOLE
- If you have a Ruby probe module inside your schematic, you can then link any Ruby editor to the console using the method "Debug.link('TagName',@this)". A reference to this Ruby instance will then appear on the Console's drop down list of Ruby ID's. You can now enter a short chunk of Ruby code into the upper of the two Ruby console windows. The code will be executed in the context of the chosen linked Ruby instance, and any return values or error messages are directed to the lower console window.
For example - typing "output 0,'Hello'" and sending this to a linked Ruby instance will output 'Hello' on the first output of the targeted Ruby editor.
I've tested on both my machines without any problems - though bear in mind that your firewall settings etc. could disrupt the network link - and I have very little experience with these kind of connections!! If you get a pop-up box warning you about opening the connection, click to allow the connection and this should be remembered for next time.
A small file and folder is saved inside your 'Application Data' folder - this is used to store the IP address allocated to the main program, so that the senders are able to find the correct IP and port addresses.
All bug reports and suggestions for improvements will be gratefully received - just post a reply to this thread, or PM me.
Best Wishes
Trog Luddite
Dubug 
After I recovered my mind, from a party night alcoholic.