Basic Midi Monitor

[unkargherth]

Here is: a Port to Ruby of the excellent MIDI Analyzer by trogluddite

Added a few bells and whistles , but still a beta: It lacks "styling properties", proportional column width, and the Sysex support is very alpha. Probably it holds a lot of bugs, too.

Description and usage restrictions (very lazy) inside module

Waiting opinions/suggestions

MidiMonitor.fsm

Initial release

(13.46 KiB) Downloaded 1767 times

[trogluddite]

That's great. I really like the added SysEx and CC descriptions, that's an excellent idea - descriptions can be much more useful than plain old numbers, so that is a real enhancement to my old design.

One bug - the Ruby goes straight into 'error' on load. It seems to be the init routine that's the problem - if you get rid of the "def init" and "end", it works fine as 'bare code'.
EDIT: Nope, this is wrong - the error is because the variable @lineHeight is used in the font declaration inside 'init' - but it doesn't get declared with a value until the first screen redraw in the 'draw' method. I keep having this problem myself - Ruby variables are persistent; i.e. they don't get "undeclared" if you edit the code. So until you save and reload, stuff like this is really hard to spot - the variable could have been declared hours ago during a long session, and it will still be there making it look as if the declaration order is just dandy when it isn't.

I've asked Malc to clarify what the order of things at startup - loadState, init, input output stored values etc. necause it's very confusing. I can't quite work out what init is supposed to do - it's there in all the examples, but I can't work out when it's supposed to run. So far, simply not using it seems to work best for me.
Malc has said he'll put a little something together for us to explain, as there's nothing in the User Guide about this.

Something else cool I found - instead of using array notation, there are methods for getting the bits of the Midi message that are much nicer to read - .channel, .status, .data1, .data2 and .sysex - e.g.
@channel = @myMidi.channel

[unkargherth]

Thanks for pointing those bugs. I'm also getting strange behaviours with vars realated to when were they get the value ( althought the @lineheight bug makes me feel a little studpid )

Anyway fro this point my firts concern tis to find a clever way so i can distribute a BareBones version and every user could "easily" implement it's ownhardware sysex specifics. I thik it's a waste of time to try to build the "ultimate sysex parser" fro every Brand and model. MIDIQuest boys did it and it's a work of 10 years and counting under a corporate infrastruture

I own a Yamaha DX/ with a ridiculous SYSEX implementation and is already a nightmare to code a parser (not to mention that in no place there's a specific byte saying "this is a dx7", so even finding the model isn't easy. Cannot imagine what could be Parsing the full MOTIF 7 Sysex spec !!!

Anyway. a question. It's worth to add an "Inport/Outport" column?. Obviously not for VST, but maybe for exe's. Or better maintain this as a developer tool more than something you want to include in your exported version?

[trogluddite]

Yes, I think you're right about the parsing of all messages - it would be a monumental task to do this even for the most commonly used kit.
Possibly, at a push, you could define a standard syntax for importing parser information from a document, so that users had a way to write their own "syntax files". But even that would be tricky - especially given the kind of support that users might need in order to get the best out of it.

However, I DO think that a SysEx librarian is definitely feasible. I have already played with the Marshal module that allows you to easily wrap Ruby objects into a raw binary file on HDD, and it is surprisingly easy to use (the FS3 loadState and saveState methods use it behind the scenes)
Marshal is not supported for every class of object, but it works very cleverly in a recursive way. e.g. numbers and strings are supported and so are hashes and arrays, meaning that an array of numbers, a hash of strings, a hash of arrays of hashes of arrayed strings..etc.. are handled seamlessly - it just digs down through the layers until it gets to the raw data, remembering the structure as it goes along. As SysEx messages are just strings, that presents no problem for creating a folder of patch dumps that could be called up on demand.

That also has some interesting possibilities for other VST's - you could potentially save huge folders full of your favourite drum loops or musical phrases in MIDI form. I always liked that idea, as it is much more flexible than audio loops. Or a trance gate or step sequencer that isn't just saddled with 16 VST patch memories - it could gorw into something like the old tracker app's that I grew up using, even.