Hello, Rodrigo!
Yes, it uses MIDI messages directly, bypassing the ss-cooking on one side and the ss on the other.
It offers all the features that these offer plus a few more.
1. You don't have that terrible issue that once you've opened any document with an "ss" in it, you can never close it and reopen it.
2. It allows you to scroll messages across the display in various ways.
3. There's a "randomize" feature (just for fun) that randomly sets all the LED states.
In addition, there are a couple more features in development that I'd have finished if the unit hadn't failed (it's on its way back to California right now! It was a very early unit so...)
1. There's actually a queue of commands built in to the scrolling display already - I use this in my personal setup, I just didn't reveal it in the interface. This lets you do things like send a single command that says, "Scroll this message three times across the display, then display this other message."
This seems like a fancy feature but in fact it's really useful in live performances.
2. I have written but not finished testing a "note display" mode where it lights up LEDs as you press notes (with dynamic allocation of some set of the LEDs). That really is "eye candy".
3. I haven't even started a "MIDI clock mode" (which could work perfectly well with the "note display" mode) which would steal, er, be inspired from your work on doing just that (I think it was yours?) Once I get the unit back it should be only a short amount of work. More eye candy!
4. There's a Max For Live version that I use in my own show that won't get revealed till the next complete version - that lets you do things like "display the current clip name".
5. There's a mapping mode that I use in my own show that lets you store mappings from Softstep presses to collections of MIDI messages in a text file in JSON form that you can store outside Max - which lets you use the same patch and different data files to get different results.
...... start preaching mode here .....
I feel somewhat as if I'm cheating here, when I see all the work that you and others are going through with pure Max to do the same thing. It's a lot more work to get going on the Javascript implementation, but once you've done it, adding serious logic is no big deal.
I basically stopped doing pure Max development a year ago. My hand started to preemptively hurt when I opened up Max - all that dragging tiny wires to hit tiny inlets and outlets! I seemed to spend at least 20% of my time simply moving around boxes and wires (and not in presentation mode) just to keep it vaguely readable.
And I had such trouble creating complex logic that worked correctly. I thought it was me - until I started reading other people's code...
There's a Max For Live patch out there, I won't name it, that has literally *tens of thousands* of Max boxes in it. I wondered how a Max patch could be several meg in size, and then I wondered why Max just seemed to go away for a few minutes when I opened it. Presentation mode was a little crowded... but then I left Presentation mode and zoomed out... and out... and out...
And now I have code to do super-fancy, useful things. For example, in my main controller patch I have a separate "style sheet" in JSON which determines the sizes of my items, the fonts and colors - so I can switch between layouts, or just tweak the size of all my buttons by editing one number in a text file.
If I had my way, I'd convince everyone that this was a better way and we could all share code and I'd never have to drag a wire again.
The rule I follow is: Javascript for logic, Max for audio. Or more specifically:
Javascript: logic, layout, MIDI, persistence, data
Max: audio, GUI
Thanks for reading!
...... end preaching mode here .....