Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright

Basic Midi Monitor

Post any examples or modules that you want to share here

Basic Midi Monitor

Postby unkargherth » Tue Nov 20, 2012 4:24 pm

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 1765 times
Free your memory, .. with a free(). Like a pointer
Cast a pointer into an integer and it becomes the integer...
Cast a pointer into a struct and it becomes the struct...
A pointer can overflow... or can crash...
Be a pointer my friend
unkargherth
 
Posts: 29
Joined: Fri Apr 08, 2005 9:46 pm

Re: Basic Midi Monitor

Postby trogluddite » Tue Nov 20, 2012 7:57 pm

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
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1730
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Basic Midi Monitor

Postby unkargherth » Wed Nov 21, 2012 1:13 am

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?
Free your memory, .. with a free(). Like a pointer
Cast a pointer into an integer and it becomes the integer...
Cast a pointer into a struct and it becomes the struct...
A pointer can overflow... or can crash...
Be a pointer my friend
unkargherth
 
Posts: 29
Joined: Fri Apr 08, 2005 9:46 pm

Re: Basic Midi Monitor

Postby trogluddite » Wed Nov 21, 2012 9:02 pm

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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1730
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK


Return to User Examples

Who is online

Users browsing this forum: No registered users and 77 guests