An example using Softstep with only standard Max objects

a place to share your patches and get help with the Max/MSP Dev. Kit.
User avatar
Jeff
Posts: 10
Joined: Mon Aug 15, 2011 6:06 pm
Contact:

An example using Softstep with only standard Max objects

Postby Jeff » Sun Aug 21, 2011 2:57 pm

I thought I'd share this patch that uses only standard objects in Max/MSP to control the Softstep.

As a warning, though, it uses common sysex that was sniffed out with a midi monitor. If used incorrectly, sysex can really scramble things. I've even heard stories of sysex permanently "bricking" hardware, although I've never personally experienced it. I've used this software daily since Thursday without any problems, but there are no guarantees.

SO,

Please, until KMI releases this information officially and with more specifics,

***No guarantees, use at your own risk***

Also: I've chosen functionality that pertains to my own use, so, not a lot of LED action. There is information inside of the jk.stepcore abstraction if you want to add this functionality.

A big thanks to my friend Chris Lavender for helping with the output stage.

http://www.jeffkaiser.com/jk.softstep.zip

a bit more information here:

http://jeffkaiser.blogspot.com/2011/08/ ... axmsp.html
User avatar
ChrisLavender
Posts: 12
Joined: Sun May 01, 2011 5:32 am
Contact:

Re: An example using Softstep with only standard Max objects

Postby ChrisLavender » Sun Aug 21, 2011 9:24 pm

No sweat man. So far your patch is working great for me!

The sys-ex messages should be fine. If you send a device sys-ex that it knows what to do with all is good. It's when the device gets a sys-ex message, which it doesn't recognize that very bad things can happen. Thus, free-styling sys-ex messages is ill-advised :-)

Hey, here is a little sub-patch I put together that scrolls the LED if what you have to display is over 4 characters.

http://christopherlavender.com/wp-conte ... maxpat.zip
User avatar
Macciza
Posts: 157
Joined: Mon Jan 31, 2011 6:23 pm
Location: Sydney, Australia

Re: An example using Softstep with only standard Max objects

Postby Macciza » Sun Aug 21, 2011 10:19 pm

Hi
Please, until KMI releases this information officially and with more specifics,
***No guarantees, use at your own risk***

Also be careful with how much data you 'try' to send to the SS - try to avoid scrolling boxes in Max that send continously when controlling the LED's. Or implent some method to throttle the speed of the messages being sent. The CC msgs can get a bit scrambled as well.

Cheers
MM
KMI StringPort_1650, SoftStep_VK2 v1.2 & MIDI Expander; Mac_Moore Guitar,
Roland VG 8, 88 & 99, YamahaVL 70m; OSX 10.6.8, iMac i7 2.8G QC; MaxMSP 5.1.8, Ableton Live 8.2.2, M4L, SC3, QC, cSound, etc, etc,
User avatar
ChrisLavender
Posts: 12
Joined: Sun May 01, 2011 5:32 am
Contact:

Re: An example using Softstep with only standard Max objects

Postby ChrisLavender » Sun Aug 21, 2011 11:54 pm

Probably good advice for any piece of hardware, but I did leave this scrolling patch running today with a paragraph's worth of text for about 4 hours without any issues. I even cranked the metro up to 1ms for a while, and although it was difficult to read the LED :-D still no issues. But these are CC messages. Sys-ex is a totally different story as the protocol was never intended to accommodate "real time" responsibilities.

In fact, I would venture to say that the sys-ex issue is probably the number one reason to use the KMI software. It is true that you can really screw up your hardware w/ sys-ex messages. Particularly with something like Max, which is always ***at your own risk***. If you are reading this and you're not comfortable with what system exclusive messages are and how they are different from MIDI performance data then I would HIGHLY recommend sticking to the ss objects in Max. (or even just the regular editor)

It's not difficult to envision a scenario where one might accidentally connect a sys-ex message to a metro that's been set to something like 10ms or less, or try to compile sys-ex inside a patch rather than bang out a fixed message and some numbers get crossed because of bad message ordering. Everything might be fine... or you could very well end up with a piece of incommunicable hardware. Unlike Jeff, I've actually seen that happen (or rather the aftermath) and it's a big bummer.

But these are extreme cases. If you're consciences about your patching and just use the two or three initialization sys-ex messages (tether, standalone, backlight) you'll be fine. I haven't and wouldn't do any more than that.
User avatar
Macciza
Posts: 157
Joined: Mon Jan 31, 2011 6:23 pm
Location: Sydney, Australia

Re: An example using Softstep with only standard Max objects

Postby Macciza » Mon Aug 22, 2011 12:14 am

The main point I wanted to make was that the alternate LED multi-cc system is far less robust and WILL give strange results if the messages get scrambled (though unlikely to brick your unit)- this has response been seen by a few a people so be careful . . .
Cheers
MM
KMI StringPort_1650, SoftStep_VK2 v1.2 & MIDI Expander; Mac_Moore Guitar,
Roland VG 8, 88 & 99, YamahaVL 70m; OSX 10.6.8, iMac i7 2.8G QC; MaxMSP 5.1.8, Ableton Live 8.2.2, M4L, SC3, QC, cSound, etc, etc,
TJ-Shredder
Posts: 22
Joined: Fri Aug 12, 2011 2:51 pm

Re: An example using Softstep with only standard Max objects

Postby TJ-Shredder » Mon Aug 22, 2011 10:01 am

Yes, I observed that as well, as there is no protection to keep three different cc messages together, if another part of the program starts sending also commands to a different LED...
That is, why we need a single cc message for the yellow LED as well. Another example for bad firmware design in the SoftStep is also, that the LED off commands, only switch off the LED if it was on in the same color. What we would need is a simple off, that turns an LED off no matter what color it was on before...
Technically there is no need for sysex at all in a device like that. It should be simple and avoid unnecessary traffic on the MIDI bus...
I bet it would cost less parsing code in the firmware as well...

Stefan
User avatar
ChrisLavender
Posts: 12
Joined: Sun May 01, 2011 5:32 am
Contact:

Re: An example using Softstep with only standard Max objects

Postby ChrisLavender » Mon Aug 22, 2011 1:36 pm

Hmm, As far as I can tell there is an independent message for the "yellow" color (looks orange to me but...).
I've put together another annotated example patch which hopefully demonstrates this relatively clearly:

http://christopherlavender.com/wp-conte ... _cntrl.zip

As for providing message packing protection, that is precisely the job of the software. As long as we're working in Max using native objects than that means WE are the software designers and it's up to us to make sure message ordering happens in a responsible fashion. Message ordering would be a problem if it was MIDI or OSC or another proprietary protocol, and it's a HUGE problem in Max due to the non-linear nature of the development environment. If you're having trouble delivering messages correctly in your own patch one easy solution would be to just use the ss objects since they do in fact deliver the messages in the correct order.

As for the sys-ex... the entire purpose for the system exclusive protocol is to control global state parameters of a device. Are there other more modern ways to do it? Sure. But the SoftStep is a MIDI device at it's core and in MIDI sys-ex is how it's done.

The upshot to using MIDI is that it's extremely light weight, relatively easy to debug, is compatible with the vast majority of other music technology, and has already been put through it's paces over the last 30+ years. Yes, you're limited to 128 values from the device, but in Max you can morph that into whatever you want (which is what the KMI SoftStep editor does).

Let me know if you have any input and/or questions regarding the above patch :-)

-CL
Last edited by ChrisLavender on Mon Aug 22, 2011 2:22 pm, edited 2 times in total.
User avatar
Jeff
Posts: 10
Joined: Mon Aug 15, 2011 6:06 pm
Contact:

Re: An example using Softstep with only standard Max objects

Postby Jeff » Mon Aug 22, 2011 1:49 pm

Nice, Chris! That was pretty clear in jk.stepcore as well, which you showed me how to do... :-)
User avatar
Jeff
Posts: 10
Joined: Mon Aug 15, 2011 6:06 pm
Contact:

Re: An example using Softstep with only standard Max objects

Postby Jeff » Mon Aug 22, 2011 1:54 pm

Stefan, as far as turning the color off before changing, I didn't even think of it...I just automatically trigger an "off" then "color" as part of my abstraction. Automatically having the firmware turn off when turning to a new color would cause us to lose some functionality of combining, I think...? So I don't think I would want the firmware to do that. (I'm away from my softstep at the moment.)
User avatar
ChrisLavender
Posts: 12
Joined: Sun May 01, 2011 5:32 am
Contact:

Re: An example using Softstep with only standard Max objects

Postby ChrisLavender » Mon Aug 22, 2011 2:24 pm

Thanks! I just updated the example patch and made it even simpler. The above link should still be good. -C

Return to “SoftStep Max/MSP Dev Kit forum”

Who is online

Users browsing this forum: No registered users and 1 guest

cron