Midi bandwidth. Advice?

[lukas412]

Hello Everyone. So I've built an 8x8 button matrix out of spare parts I had around. I did not use the newer scan matrix code, just wired up buttons and leds the standard old way. I have everything working and I'm running the midio128 application. I've created a max patch to translate the midi note on/off messages into osc so I can run monome apps. This all works for the most part, but I quickly run into bandwidth issues running apps like the Reaktor version of mlr. So I doubt there is much I can do about this, but does anyone have any suggestions for increasing the bandwidth? Some way to run the data through more midi ports? I'm on the list to get the new usb module. Is there some way I can send the data down both midi inputs to double the bandwidth? Is there something other than note on/offs that would be lighter weight? As far as I know monome serial runs at 115200 bits per second, and the midi standard is 31250 bits per second. Thanks for any advice.

Luke

[stryd_one]

Running out of bandwidth with 64 notes going in? I doubt it....

You can't increase the bandwidth but for this, I don't see why you'd need to. I think you might be chasing a problem that lies elsewhere. What makes you think you're out of bandwidth?

[lukas412]

Running out of bandwidth with 64 notes going in? I doubt it....

You can't increase the bandwidth but for this, I don't see why you'd need to. I think you might be chasing a problem that lies elsewhere. What makes you think you're out of bandwidth?

Well there is a fake monome app out there that I used as a base for the translation of the midi to osc. When this app is run alone with no midi box there is no bog down. With the Reaktor mlr app for example it will work fine, and then when you get a lot of sequencing going it will start to not respond, and then when you hit stop you can see the midi box continue firing as if its catching up.

I think that the way that the monome apps are generally written has a lot to do with it. For example in the reaktor mlr, you have 4 sequence tracks. If you run these straight through no problem. What it lets you do is re-sequence the 8 chops of the loop for up to 8 bars. This can be quantized down to 96th notes. So multiply this times 4 and you can see how its many more than 64 notes going in. Each track is sending out 8 on/offs for every tick from what i can tell. When I look at the watch in max its just pouring out data.

The monome will respond to a couple differnt types of commands one of them being the row number then one byte of data eg 0 255. Each bit turning one of the 8 lights on or off. The only thing I could come up with to translate this was to fire 8 note on or offs every time i get the row command from osc. It's clearly an inefficient way to do this, but I'm not skilled enough to clean it up, and the monome has the bandwidth to burn, or it just takes care of that command internally I guess.

I mean when this is going on the display on the mb is going nuts, its changing so fast that its just a blur. Maybe I can take a video of it, but I have very little doubt that its a bandwidth issue. Hopefully I'm wrong and one of you guys can help me figure out where the issue is.

Thanks for the help,

Luke

[/tilted/]

Hate to jump in with a boring question, but you aren't sending vast streams of AIN data, due to open AIN pins, are you?

[stryd_one]

Each track is sending out 8 on/offs for every tick from what i can tell. When I look at the watch in max its just pouring out data

....

I mean when this is going on the display on the mb is going nuts, its changing so fast that its just a blur. Maybe I can take a video of it, but I have very little doubt that its a bandwidth issue.

Well that's just silly, you're sending more data than you can visualise - the LEDs don't even light up that fast. The problem here isn't a lack of bandmidth from MIDI, it's an excess of data being sent from max.... so to answer your question "Midi bandwidth. Advice?": My advice is to fix the problem, and it ain't midi.... It's your software. Sorry :(

[lukas412]

Thanks Stryde. So do you have any recommendations? How would you go about this? I'm doing it exactly like I understand the monome does. I've just added a midi in and out module to the max patch that the monome people supply to test monome apps without having one. I don't want to re-write monome apps just so they will run properly on my hardware. Whether its silly or not this how I understand the monome apps to work. I can see how this is an inefficient way of doing this, but this is how it appears they are doing it. So I would say it is a bandwidth issue, but the monome just has plenty to spare so they writing apps that aren't very efficient to keep the coding simple.

/tilted/ its not ains, it works fine even with a lot of monome apps, but some just really pump out data. Thank you.

Has anyone else actually created a mb based monome clone, or own one that can give me some advice if I am interpreting this wrong?

Thanks all,

Luke

[stryd_one]

I would say it is a bandwidth issue, but the monome just has plenty to spare so they writing apps that aren't very efficient to keep the coding simple.

To call this a bandwidth problem, is like saying, you need to get 5 people from your house to the store, and for no reason, you put 50 people in the car, it breaks down, and you call it an engine problem.

I wonder if you could write a max -> midi converter, which accepts the big stream of data from max, and outputs something normal like a midi note-on message to turn the LED on, and a note-off to turn it off?

Perhaps you could mangle the data they use, like using CC's - the channel nibble represents a row of leds, the cc# and value can represent the 8 bits you spoke of (with spares)

I can't help but wonder - why would they do it that way?

[lukas412]

To call this a bandwidth problem, is like saying, you need to get 5 people from your house to the store, and for no reason, you put 50 people in the car, it breaks down, and you call it an engine problem.

I totally understand what you are saying here, all that I was saying is that its two different protocols. Monome is running on usb2 at 115 baud. So I guess they just don't care if its efficient. There headroom is huge. Try to convert that same system to midi and your gonna hit the ceiling.

I wonder if you could write a max -> midi converter, which accepts the big stream of data from max, and outputs something normal like a midi note-on message to turn the LED on, and a note-off to turn it off?

This is pretty much what I am doing, I think what I would need to do is manage the state of the leds more efficiently, rather than just send out the data whether it needs it or not. For example the way this seems to be working is that it will send out a note off even if the led is already off. It doesn't care. It always updates it whether it needs to or not. So in some ways its simpler to program. You don't really need to store the current state of the led to determine if you need to turn it off or on based on its current state you just send the command anyway.

Perhaps you could mangle the data they use, like using CC's - the channel nibble represents a row of leds, the cc# and value can represent the 8 bits you spoke of (with spares)

This is the kinda stuff I was looking for! Thanks, I will see what I can do here. Maybe write a c app that can take this in and internally process it so I'm only sending one command to handle an entire row or column, instead of 8. Is that what you are saying? That would really lighten the load.

I can't help but wonder - why would they do it that way?

I am not trying to pretend to be an expert. I don't own a real monome and have very limited knowledge of max. All that I have to go on is the fake monome app they have posted. Like I mentioned above, I assume they do it this way because its easy. No true state management. Just fire off the ons or offs, needed or not. If you've got the headroom why make it more complicated to deal with. I could be totally wrong here. Just what I've been able to gather so far. I appreciate your help on this. I hope to make this thing fully work. It's so much fun.

Thanks again,

Luke

[stryd_one]

There headroom is huge.

Totally, but that's why I wonder why they decided to use it like they did... maybe as you say it's just convenience, maybe something else.... If it's really needed, I guess you'll find out the hard way. Pioneering is like that heheheheh

what I would need to do is manage the state of the leds more efficiently, rather than just send out the data whether it needs it or not.

Sorry yeh that's what I meant :)

take this in and internally process it so I'm only sending one command to handle an entire row or column, instead of 8. Is that what you are saying?

Exactly. You could use pitchbend or notes or whatever has 3 bytes.... In the end you'll always get 4bits to ID the track (channel nibble) and 14bits of payload. What you do with that is up to the device :) NRPNs would probably be the most "correct" method.

Seeing as the monome max patches send it that way, I thought it might be easy. Otherwise you thin the data out as required in max to just send appropriate note-on/offs. I guess it depends on whether you want to spend more time programming max, or your midibox.

I don't own a real monome and have very limited knowledge of max.

OK that makes two of us :D

[lukas412]

Thanks a lot Stryd. I would much rather spend the time programming in my midibox. I'm not to much a fan of max at this point. I want that to do the bare minimum. I mostly want to use this with Reaktor. I'm installing the new programming platform now. The setup tutorials for the tool chain are tremendous. Good work to all of you. I'll start with NRPN's and see how it goes. It works decently well even now, but some apps just kill it. So I think with this optimization it should work quite well. I'm sure I'll have some more questions.

Thanks again,

Luke

[lukas412]

Quick update on this. I have gotten this to work quite well. I was able to reduce 8 note on messages to set a row of 8 LEDs to 1 note on message. I will soon release the c code and a small max patch that does the transform. I was going to use NRPNs for this, but that would only reduce the messages being sent from 8 to 4 rather than 8 to 1. Its setup so you can easily choose the type of midi message you would like to use.

It works by rearranging the bits in a 3 byte midi message. This allows you to take the low bits from the 2nd and 3rd bytes to get the full 8 bit value to set all 8 LED's at once. That leaves the high bits from the 2nd and 3rd byte to set the command type and the row or col number. It's pretty simple and allows for more command types if needed. Comments appreciated! Thanks to everyone that gave advice and TK for the great platform!

Thanks,

Luke

Here is the mapping using note on.

midi note on message

9n 7F 7F

12 34 56

1: Command Type

2: Midi Channel

3: Command

4: Arg1

5: Arg2

6: Arg3

Command Types

9: Monome Command

        x: More command types can be added here.

Commands that emulate the monome commands

0: LED

1: ROW

2: COL

3: CLEAR

4: MODE

---------------------------

Command Definitions

---------------------------

LED

9n 0F 7F

12 34 56

1: 9 Matrix Command

2: Channel

3: 0 LED

4: Arg1 Row

5: Arg2 Value

6: Arg3 Col

---------------------------

ROW

9n 1F 7F

12 34 56

1: 9 Matrix Command

2: Channel

3: 1 ROW

4: Arg1 High bit

5: Arg2 Row

6: Arg3 Low bit

---------------------------

COL

9n 2F 7F

12 34 56

1: 9 Matrix Command

2: Channel

3: 1 COL

4: Arg1 High Bit

5: Arg2 Col

6: Arg3 Low Bit

---------------------------

CLEAR

9n 3F 7F

12 34 56

1: 9 Matrix Command

2: Channel

3: 3 CLEAR

4: Arg1 Off/On 0/1

5: Arg2 0

6: Arg3 0

---------------------------

MODE

9n 4F 7F

12 34 56

1: 9 Matrix Command

2: Channel

3: 3 MODE

4: Arg1 0

5: Arg2 0-All On 1-All Off

6: Arg3 0

[Max Romantschuk]

Coming in to this thread late... I was just going to recommend bit masking as a simple way to reduce bandwidth, and... well... Never mind. ;)

The other, rather more complicated thing you could do if you wanted further optimization is refrain from sending redundant data. That would of course mean storing the interface state in the computer end, and only sending the changes through MIDI. But probably doesn't make sense as you already seem to have everything in order. :)

I like the idea of this monome-OSC-bridge-thingy... Makes me want to build a button matrix at some point. :)