If I want more than 16 channels of MIDI do I need a second teensy?

[sargentpilcher]

My project is going to be using MIDI to control hundreds of RGB lights, and the way I have it coded (Maybe there's a better way) is for one MIDI note to equal one value of RGB on an LED. So for example, I have a strip of 144 dotstars, but multiply that by 3 to get 432 and that's how many MIDI note values I'm going to need just for that one strip. So I'm going to need 4 channels of MIDI just to control one meter worth of LED's, which is going to cause problems as soon as I pass 4 strips.

I realize that the limitation here is on the 30 year old technology that is MIDI and not a shortcoming of the Teensy. But I'm wondering if there would be a way to program the Teensy to act as more than one MIDI controller as seen by the computer? Or would I need to have more than 1 Teensy? That option is far less desirable because it means I will need 2 USB ports in order to accomplish what I want.

 

[oddson]

Each Tx/Rx pair available should in theory be able to control a separate physical MIDI port but I don't know if the Library would support this.

I don't think a Teensy can be two usbMIDI devices but if you use status messages other than note-on you will get many more potential messages to proxy for RGB data... although why you would want to eludes me.

 

[sargentpilcher]

I'm trying to have it function with some music software called ableton, so I need it to be MIDI, unless Teensy starts being compatible with some more modern MIDI alternatives like OSC or MPE then I'm stuck I guess :/ Thanks for the help. I guess I'll either get less dense strips, or get a second teensy and hope I don't run into problems.

I wonder if there is a better way than doing one note per LED? I'm not sure what it would be though.

 

[markonian]

... unless Teensy starts being compatible with some more modern MIDI alternatives like OSC or MPE then I'm stuck I guess :/

I'm an OSC novice, but I just googled for "Teensy OSC" and got lots of hits. Here one: CNMAT/OSC.

Support

IDEs

Arduino 1.05 and 1.6.3 (tested for Due Serial and Teensy so far)

Best Supported Board: The Teensy 3.0 and 3.1 and LC have the performance and memory that afford rich OSC implementations. Our primary test platform for new development is the Teensy 3.1 which currently offers the best performance of any of the Arduinos and variants. We greatly appreciate Paul Stoffregen's ongoing work with "best practice" engineering of high performance microcontrollers.

 

[Davidelvig]

There are good, prebuilt ways to control hundreds of rgb leds (FastLED, the Octo lib, others)

Will Ableton generate the MIDI commands for lighting (along with music played elsewhere), and the Teensy is listening and driving the LEDs?

Why midi to light LEDs directly?

What's the overall physical setup you imagine?

Like oddson, I'm struggling with understanding the MIDI to LED requirement.

 

[sargentpilcher]

I'm an OSC novice, but I just googled for "Teensy OSC" and got lots of hits. Here one: CNMAT/OSC.

Oh wow! That's awesome, I wasn't expecting that. To be honest I'm not very familiar with the format and made a lot of assumptions about it's capabilities and may or may not be capable of what I want, so that will require further research on my part, but at least I know that it's an option. I'm hung up on getting other sections of the code working right now before I expand it out to a thousand LED's.

There are good, prebuilt ways to control hundreds of rgb leds (FastLED, the Octo lib, others)

Will Ableton generate the MIDI commands for lighting (along with music played elsewhere), and the Teensy is listening and driving the LEDs?

Why midi to light LEDs directly?

What's the overall physical setup you imagine?

Like oddson, I'm struggling with understanding the MIDI to LED requirement.

From all the examples I've seen of people using neopixels, the lights all follow complicated patterns of chasing tails, and beams, and various methods of creating patterns, which is great if you're trying to make some pretty lights to show off some capabilities. However what I want to do is to create premade patterns that go with a music set for live performances. I'll be using Ableton live as my software to playback live music, and in order to minimize the amount of seperate programs I have running, thus the amount of things that can go wrong, and crash, I would really like to keep it isolated to just Ableton and nothing else. Possibly bitwig instead if I end up going to OSC route.

I'm more than open to FastLed, or any other library, but my main requirement is individual control of lights to synchronize it with a live music set.

 

[mlu]

USB MIDI supports up to 16 logical jacks/cables for every USB MIDI endpoint, that would give 16 cables * 16 channels * 127 Notes.

This is not implemented in the current library, would need to add the logical jacks in the USB MIDI descriptor and code that handles the CN (cable number) field in the USB MIDI messages.

For the host this should show up as 16 MIDI out ports associated with the Teensy.

In principle, meaning not yet done or tested ... it is surely possible.

 

[sargentpilcher]

USB MIDI supports up to 16 logical jacks/cables for every USB MIDI endpoint, that would give 16 cables * 16 channels * 127 Notes.

This is not implemented in the current library, would need to add the logical jacks in the USB MIDI descriptor and code that handles the CN (cable number) field in the USB MIDI messages.

For the host this should show up as 16 MIDI out ports associated with the Teensy.

In principle, meaning not yet done or tested ... it is surely possible.

VERY cool! Exactly the kind of information I needed! Thank you! I just need to learn how to customize libraries, or find somebody else who does. I didn't know that about the USB MIDI protocol. Thanks again!

 

[oddson]

See https://forum.pjrc.com/threads/18740-Multiple-virtual-MIDI-ports-over-USB-with-Teensy-2-0-(Or-3-0-) and https://forum.pjrc.com/threads/41275-Virtual-Midi-Cables-8-ports-OSX-and-PC for more on the prospects of getting multiple port/jack/cable usbMIDI to work with Teensy

But I still ask, Why?! Why not send scene-change events to Teensy and let it implement the digital logic to set the individual parameters

Also, how? How on earth will you tell Abelton what changes to make to the thousands of parameters from one tick to the next?

Assume you want to make all the lights swell and color shift... you will have to figure out how to get Abelton to make thousands of adjustments to send thousands of near identical messages.

Also... if you did need to repurpose MIDI why limit yourself to note-on... you can use seven of eight values in the TYPE nibble.

If you really need to send all the data required to show a given scene and you can only use MIDI I would check into SysEx support form the software.

If you can send arbitrary sysex data you can design your own means of passing the data much more efficiently.

 

[sargentpilcher]

See https://forum.pjrc.com/threads/18740-Multiple-virtual-MIDI-ports-over-USB-with-Teensy-2-0-(Or-3-0-) and https://forum.pjrc.com/threads/41275-Virtual-Midi-Cables-8-ports-OSX-and-PC for more on the prospects of getting multiple port/jack/cable usbMIDI to work with Teensy

Oh wow thank you! Those are excellent resources! I will definitely be diving more deeply into that area once I wrinkle out some other things that are ahead of that in the chain. I originally asked this question to see if it was possible, as right now I only have the 1 strip of DotStars, and until I have several of them this won't matter, although I could get the code working on 1 strip ahead of time. I was afraid I was going to have to force myself down to a 60 LED per meter strip to make up for it, but assuming I can get this working, I can have a LOT of LED's going which is awesome! (the wall I'm hitting right now is how to specify a different channel as I've used up all my available notes and I can only light up 1/4 of my strip. I'm going to make another forum post shortly about it asking for help)

But I still ask, Why?! Why not send scene-change events to Teensy and let it implement the digital logic to set the individual parameters

I apologize as I'm not very well versed in this sort of thing. I'm a musician and not a programmer, and have only been at this for a couple of months, so I'm not even sure what you mean by "scene change events". Typically in a musical context a scene change would mean for example you have a MIDI controller with 16 pads that control the program. By changing the scene you could use those same 16 pads to control different things effectively giving you 32 pads or more depending on how many "scenes" you have available. That's the first place my mind goes and I'm not seeing the connect to using it for a light show. Maybe I'm misunderstanding something? Again I apologize. I am very open to suggestion if you think there is a better way. I do not think that this is going to be the best way, it is just the way that I thought up in my head and am pursuing because I don't know of any other way.

Also, how? How on earth will you tell Abelton what changes to make to the thousands of parameters from one tick to the next?

So far what I have planned is the simple On/Off messages from the MIDI notes. I already have brightness connected to velocity and it's working great. I was thinking of using aftertouch to control individual LED brightness if I want individual pixel control, and I was thinking of using the ModWheel to control the brightness of the entire strip (From what I've read this isn't the best way to do it as it erases the previous brightness values so it may not work how I want). Again, if there's a better way I am very open to suggestion. Right now I have it working pretty good functionality wise on one strip, but it's maxing out at 40 LED's and there could easily be problems when I get up to 1,000 (If I get that far, or use that many).

I've used Ableton to automate quite lot of things using very CPU intensive synthesizers, so I don't think the MIDI part is going to be much of a problem for it.

Assume you want to make all the lights swell and color shift... you will have to figure out how to get Abelton to make thousands of adjustments to send thousands of near identical messages.

Ableton is fully capable of doing this with the MIDI functionality. It's more the implementation within Teensy and the limitations I will encounter from the DotStars that I'm worried about.

Also... if you did need to repurpose MIDI why limit yourself to note-on... you can use seven of eight values in the TYPE nibble.

I apologize again, I'm a newb programmer. Could you explain to me what the TYPE nibble is?

If you really need to send all the data required to show a given scene and you can only use MIDI I would check into SysEx support form the software.
If you can send arbitrary sysex data you can design your own means of passing the data much more efficiently.

I'm not against this if it's a better way. One guy I saw online talked about how programming custom MIDI controllers using Max4Live was far more reliable than what I'm trying to do (I think that's how I would implement SysEx in Ableton Live), but it's going to require some more research on my part. I've never used Max4Live, and don't know what I'm doing, but I didn't know what I was doing with Arduino either (I still kinda don't), and I learned. I would definitely appreciate some guidance if you think there's a better/ more efficient way to go about doing this.


Like I said I am a musician and not a programmer, and I had a vision in my head of how I could have a portable lighting rig for live performances to help set me apart from the crowd. I chose MIDI because I am very familiar with it from my many years experience with music software. I appreciate your ideas and your challenging of my ideas. I want it to be as reliable and simple as possible.

 

[oddson]

If you're not a programmer... don't bother with the multi-port solution unless someone fixes the libraries to support the functionality.

Typically in a musical context a scene change would mean for example you have a MIDI controller with 16 pads that control the program. By changing the scene you could use those same 16 pads to control different things effectively giving you 32 pads or more depending on how many "scenes" you have available.

Yeah ...'scene' is typically used to mean a collection of parameter values called up all at once.

So in your example the software could control the scene by configuring each button on the controller and the controller doesn't know anything about the scene, just the individual settings.

Or you could make a controller that has scene memory so that you select the scene on the controller and the software doesn't know anything about the scene.

Or you could send a scene-change message from the software to the controller... the controller has the scene details but the software initiates the change...

With this latter set up you get software control of when the scene is implemented but the controller manages the changes. The major advantage is a much smaller message.

The parameter set for a subset of your lighting system could constitute a scene that could be controlled with a short message by the software. But only if the scenes can be configured and held on the lighting controller (Teensy).

Max4LIVE might come in handy if you were to go ahead with the 'send everything' approach as at least that would give you a programming environment to figure out what all those RGB values need to be and to turn them into MIDI messages.

The 'nibble' comment means that the first byte of a MIDI message is called the 'status' byte but the last four bits are the channel data (four bits is sometimes called a 'nibble' as in small byte).
If you only use note-on messages you are using only 1 of seven usable status nibbles... the others are used for CC, pressure change, pitch bend etc. but they are all 3-byte MIDI messages that could be used along with note on (and off) because your RGB values include 0 so you don't need a special off message (you need three RGB messages with 0 as the magnitude).

I wouldn't bother with this unless you have to but it would let you squeeze many more messages into the MIDI space.

although I could get the code working on 1 strip ahead of time. I was afraid I was going to have to force myself down to a 60 LED per meter strip to make up for it, but assuming I can get this working, I can have a LOT of LED's going which is awesome! (the wall I'm hitting right now is how to specify a different channel as I've used up all my available notes and I can only light up 1/4 of my strip. I'm going to make another forum post shortly about it asking for help)

It may be that once we see what you're doing on the small scale in detail you might get better advice on scaling up.

 

[sargentpilcher]

Oddson thank you for all of your help and advice! You are very knowledgeable with programming. I don't know if I will have the chance to implement many of the things you said as much of it goes over my head.

You probably saw this coming a mile away. I just got my code for the entire strip, and I don't know if my problem is my incredibly ineficient code, or if it's a limitation of the dotstars, but when running that many MIDI messages at a time, it seems to overload the whole thing and it's not smooth at all, running and very obvious blank spaces occuring throughout. If I leave it running for long enough, once I press stop the lights keep going like it has to "catch up" with all the messages it's receiving. I may be able to work around it by minimizing how many things I have being sent to it at once (I was deliberately overloading it to see how far I could push it), but for now I need to learn how to use an array so I can condense some of this code down and see if it helps. Right now I'm at about 2,500 lines of code for the entire strip. That's 432 lines just to declare all the variables, and another 2,000 for the rest of it.

Thanks again for all of your help!

 

[oddson]

If you can describe what you want to achieve I might be able to suggest an appropriate means of achieving it. As suggested the main issue is whether the specific data can live on the Teensy or needs to be sent every time there is an update.

If you had a finite number of scenes you could load them into EEPROM memory via Sysex of other data transfer mechanism and then have a set of commands that your Teensy interpret as "initiate scene x" and set all the parameters appropriately.

Your existing code problem (assuming you keep to the 1-MIDI per RGB parameter) can be minimized by the efficient use of loops and arrays but I couldn't sort out how in time to post tonight on your other thread.

BTW ...is your handle anti-drug or just old-guy trivia?

 

[sargentpilcher]

If you can describe what you want to achieve I might be able to suggest an appropriate means of achieving it. As suggested the main issue is whether the specific data can live on the Teensy or needs to be sent every time there is an update.

If you had a finite number of scenes you could load them into EEPROM memory via Sysex of other data transfer mechanism and then have a set of commands that your Teensy interpret as "initiate scene x" and set all the parameters appropriately.

Your existing code problem (assuming you keep to the 1-MIDI per RGB parameter) can be minimized by the efficient use of loops and arrays but I couldn't sort out how in time to post tonight on your other thread.

BTW ...is your handle anti-drug or just old-guy trivia?

I definitely see the value in having presets already loaded into the Teensy memory, but it would require an extreme amount of precision to sync with a song the way I want to do. For example, I have a song where I have an arpeggio going from low to high incredibly fast and it sounds really cool, and I do tempo changes within the arppeggio (I don't know if this would be possible to program, but MIDI works great for it). To be honest with you this song is the inspiration for doing this entire light project because I thought the 2 would be so cool paired together. I made a functional prototype to imagine it by getting 7 RGB LED's and wiring them up on a breadboard, and I needed 21 ports to do it, and when I did it was awesome. Just more fuel for me to keep going and expanding it, so next step was to get some NeoPixels working, then the Dotstar strip. My code hasn't changed much since that initial "digitalWrite(ledPin1, HIGH)". I haven't learned yet how to use an array but that's next on my list of things to learn so I can trim some fat off this monster of a sketch. I don't know why I thought I could use so many lines of code and still have it perform decently.

As far as what I'm trying to achieve with it. I want to have lights synchronized with music, and not in the way that I usually see on youtube, where the lights get brighter with the music or something basic. I want a portable light show. Like this https://www.youtube.com/watch?v=vd8Kne8U7CM but on a much smaller scale. I want every kick to light something up. I want the whole strip to be lit up really soft on the prechorus, a soft pad going and evoloving opening it's filter as the lights are changing color from red to purple to blue, and as I start a snare roll going in 1/4 notes to 1/8 notes to 1/16 to 1/32 I want the lights to follow, turning off and on rythmically, getting brighter as the filter opens up. Then the music stops and so do the lights for 1 full beat, then full brightness on the chorus, going in and out with the rythym or whatever the main element is. That's how I see it in my head anyways. Maybe a little ambitious. Maybe even impossible if I can't get the code slim enough or cut down some features. Or maybe I could get some less dense strips. They don't NEED to be 144 LED's per meter, I was just buying what looked like the "best" thing to experiment on, but maybe a 60LED per meter would suit my purposes just as well if it means I could run everything smoother. I'd rather smoother lights with less density than vice versa. I appreciate all your help and advice!

My handle isn't a terribly interesting story. I'm aware he was the guy who busted the beatles for drugs, but it's also the name of a Primus song about said Pilcher. Primus was my favorite band when I was in high school and all of the Primus related usernames were all taken, but then Primus came out with a new album, and I finally got myself a Primus username that didn't have random numbers at the end of it (I'm not a fan of the song, but still love Primus). Added bonus, it's unique so I've never had it already taken. If it is, I know I've already made an account, so I've stuck with it for over a decade.

 

[DeathBloom]

Hi sargentpilcher!

Were you successful doing your project? Is it done?