View Single Post
Old 05-07-2014, 10:04 AM   #95
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by Banned View Post
I just made some string related functions, but I can now probably throw them out again.
Actually, good thing I didn't, as I still very much need them. I did rewrite them a bit using the new features in v0.3, though, while getting a bit more comfortable with the syntax.
Quote:
Originally Posted by Banned View Post
Adding the ability to create custom GUIs from OSCII-bot scripts is excellent; I was going to suggest that - and not only because console logging can be pretty harsh on the CPU. Pretty cool demo script showing I/O there, too (although not quite readable, hehe). Will definitely need to dive deeper into that stuff...
I have been playing with the "show-io.txt" demo script a bit, it was quite useful to learn a bit about the gfx* features.

While this was mainly an exercise just for fun, I have also adapted it a bit, hopefully enhancing its usefulness for other purposes than simple demonstration (= profit!). In doing so, I have removed a bit (but not all!) of the fun graphics stuff - so it is definitely not intended as a replacement for it. Check out my MonitorMIDI+OSC-IO.txt script here.

The main things that I thought made sense to add, were:

- (Most importantly): display not only the address of OSC messages, but also their parameter(s) value(s) and type(s);

- Creating some user defined functions for getting parameter values as strings (to help with the above), which seems to be quite fundamental to parsing OSC messages;

- An adapted layout, with different message types on separate 'lines', which seems more suitable for visualizing MIDI to OSC / OSC to MIDI conversion; the line for MIDI input is displayed at the top, followed by OSC output, then OSC input, and finally MIDI output. This way you can more easily see both what comes in and what goes out, both for MIDI and OSC.

- Color coding - just because it's awesome. Things were getting a bit too much old school monochrome terminal.

- When receiving many messages in a short time span (e.g. on action to 'refresh' all console surfaces), the messages were pasted on top of previous ones, which frustrated readability. As a quick and dirty solution (which works ok in most cases, less so for some larger fonts / font sizes), a filled black rectangle is now drawn over a line before drawing a new message on the same line. However, since it also seems useful to somehow be able to see that there are multiple messages arriving in a short time, I chose to make it slightly transparent.

- I added a timer/counter to the fade-to-black effect, so the speed can be tweaked (i.e. slowed down), and enhanced it with a bit of blurring: frustrating readability just enough to be fun, while still being somewhat useful -- but sorry, the rotation and resize blitting just *had* to go...
Quote:
Originally Posted by Banned View Post
The OMNI snooping thing looks quite useful, too.
Although indeed *very* useful, the downside to this approach seems to be that it seems to be impossible to see which device any specific message is going to / coming from (please correct me if I'm wrong!).

For example, since I wanted to display MIDI messages in a more human readable format (e.g. "[MIDI input] Channel 5 CC#7 value: 100") than raw bytes (which of course do not provide much additional information, since we already have OSCII-bot showing those in the bottom left corner), I initially intended to integrate the sophisticated 14 bit CC# pairs / (N)RPN message parsing from JeffOS' MIDI2OSC script into this one.

But then I soon realised that in order to reliably parse such messages consisting of multiple parts, we would need to be able to discriminate between originating devices. For example, when receiving value almost simultaneously for channel 1, CC# 7 from one device and channel 1, CC# 39 from another device, the script (in hi-res mode) could (incorrectly) interpret them as a single pair of MSB/LSB CC# messages to make up one 14-bit value, because we can't tell which device was the source of the individual messages.
Quote:
Originally Posted by Banned View Post
A little suggestion: when pressing the escape key, OSCII-bot quits (at least, on my Mac it does). Imho it should be slightly more persistent.
Somewhat related: conversely, OSCII-bot does *not* quit when a GUI window created by a script has focus. I guess it would make sense to always pass computer keyboard commands like CMD+Q (Mac) / ALT+F4 (Windows) on to the main app window (another one: CMD+` does work to cycle from the main window to the first script window, but then stops working, so you can't cycle through all of the application windows). Also, GUI windows created by a script can't be closed or minimized using the usual OS-specific keyboard shortcuts. Shouldn't they?

---

Some remarks about the current implementation/documentation:

- Is gfx_update() perhaps called *automatically* in the @timer section? The documentation mentions: "Once the graphics window is open, gfx_update() should be called periodically." However, the graphics functions seem to work just fine without doing so, and calling gfx_update() in fact results in a syntax/compile error. :-/

- I can't seem to get gfx_getchar() to work either. Am I missing anything, or is it perhaps bugged / not yet implemented? For example, this code (placed in the @timer section, or anywhere else) seems to do absolutely nothing (regardless of which window has focus):
Code:
char = gfx_getchar() ? printf("%c", char);
- While this hardly surprising, it isn't quite self-evident that the graphics coordinate system starts at the top of the window with x = 0, and y = 0 at the left. (I pretty much typed all the code I thought I needed for drawing VU meters before testing to see if it actually worked, only to find out that it worked *almost perfectly: it was upside down. ) I figure that deserves to be mentioned somewhere.

- The reference for gfx_setfont() mentions: "After calling gfx_setfont(), gfx_texth may be updated to reflect the new average line height." Wouldn't it be more useful to have something like gfx_texth to reflect the *maximum* line height? (Or is there perhaps another easy way to find that out?)

- Imho it would be pretty useful if we could get the window dimensions, and set the GUI window position in relation to the screen. Currently, when creating multiple GUI windows, they always seem overlap on (re)loading scripts.

- I managed to crash or hang OSCII-bot a couple of times on loading scripts with invalid syntax. Will email in some sample code and (OS X) crash reports to support later.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote