No no no no, back up back up a few steps, man.
You're the one saying MIOS was crap before. I never said it. :hyper:
I think MIOS Studio is absolutely fantastic. It's awesome. It's super-duper. It's incredible. :queen:
I'm saying that better monitoring of OSC + MIDI data would be the single biggest improvement possible.
How much time do we spend monitoring and debugging data? A lot.
I don't think you disagree with this statement. And MIOS Studio does everything else perfectly already.
So improved monitoring tools would therefore be the single biggest improvement. It's logical.
I can't do the patches for you, though, because I don't know your codebase, and learning it and how it all fits together would take me a month before I can even begin coding, and then just one afternoon to make the patches (they're that trivial). It's a very lopsided exchange and would make me a fully-capable MIOS Studio coder just for one small change. And then what do I do with this knowledge?
The changes are basically this:
Table view:
* GUI: tableView (a sorted table of all seen addresses)
* Array seenOSCEvents, seenMIDIEvents.
* onOSCEvent/onMIDIEvent: Loop through seenOSCEvents/seenMIDIEvents. If we find the event address, write a new "last-seen value" and trigger the flash() function of the LED in the GUI for that event address. If we don't find it, add it to the array and then call a function on the tableView() to redraw itself with the newly seen event address.
Filtering:
* onOSCEvent/onMIDIEvent: If event is in the tableView, and the user has unchecked the checkbox next to it, then don't output this event into the raw textbox.
Monitoring:
* onOSCEvent/onMIDIEvent: If the user has opened a monitoring window for this one, then draw the new value in that window.
Actually, Monitoring is a slightly-difficult one since it would need a scrollable window-type and graphical drawing of data.
However, Filtering can basically fill that need anyway, since it would be possible to hide all other events and just watch the one you care about.