Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 10 of 10

Thread: Multiple Teensies for MIDI controller/getting MIDI from DAW

  1. #1
    Junior Member
    Join Date
    Dec 2018
    Posts
    3

    Multiple Teensies for MIDI controller/getting MIDI from DAW

    Hi everyone, I'm sure it has been posted here somewhere but I wasn't able to find a definitive answer to my question, so here it goes..

    I'm interested in building a MIDI controller to control plugins in my DAW. It will be controlled with a Teensy 3.6 utilizing encoders, switches and leds. Nothing groundbreaking. What I'd like to do is combine a unit for a compressor, an EQ and a limiter in one 4U rack, which means I'll need quite a couple of inputs. Can 3 Teensies be linked in a Master/Slave configuration so that they all output their data through the Master's USB port? Thus only one of them will be connected to the PC/DAW, and the entire thing will be one controller. Can this be done with either the RX/TX pins or the I2C? I've only found projects here that the opposite happens, where a master passes data through to the slaves.

    I'd also like to get feedback from the DAW to visualise things like Gain Reduction of the compressor with VU meters (just some LEDs). Do any of you that did similar projects know a way to send MIDI messages from the DAW to the Teensy? I can't seem to find a working version of PizMIDI!

    *My DAW of choice is Reaper (x64).

    Thanks for any help and for keeping this oasis of information up for newbies!

  2. #2
    Member crees's Avatar
    Join Date
    Dec 2016
    Location
    Utah
    Posts
    94
    Look at using possibly the serial pins connected to a rs485 bus. Then use ID's in your serial commands so you know what device is communicating. The appointed master simply parses out serial data and sends it upline via USB or whatever method you choose.

    Check this video out.

    https://www.youtube.com/watch?v=pT2owWZnEXU

    I was looking at doing somthing simular but then decided to use a PI as me head control unit and connect all my teensy via USB hub.

  3. #3
    Senior Member
    Join Date
    Jan 2017
    Location
    Maastricht
    Posts
    122
    Quote Originally Posted by JimmyDS View Post
    Hi everyone, I'm sure it has been posted here somewhere but I wasn't able to find a definitive answer to my question, so here it goes..

    I'm interested in building a MIDI controller to control plugins in my DAW. It will be controlled with a Teensy 3.6 utilizing encoders, switches and leds. Nothing groundbreaking. What I'd like to do is combine a unit for a compressor, an EQ and a limiter in one 4U rack, which means I'll need quite a couple of inputs. Can 3 Teensies be linked in a Master/Slave configuration so that they all output their data through the Master's USB port? Thus only one of them will be connected to the PC/DAW, and the entire thing will be one controller. Can this be done with either the RX/TX pins or the I2C? I've only found projects here that the opposite happens, where a master passes data through to the slaves.

    I'd also like to get feedback from the DAW to visualise things like Gain Reduction of the compressor with VU meters (just some LEDs). Do any of you that did similar projects know a way to send MIDI messages from the DAW to the Teensy? I can't seem to find a working version of PizMIDI!

    *My DAW of choice is Reaper (x64).

    Thanks for any help and for keeping this oasis of information up for newbies!
    Why would you want to use multiple Teensies? Wouldn't it make more sense to use multiplexers, shift registers or port expanders? How many controls are we talking about? Personally I like shift registers for buttons. This thread on shift registers: SN74HC165 shift register revisited contains some pictures of a controller I build for this exact same purpose, controlling plugins in a DAW.

    I have not yet seen any feedback of things like gain reduction meters (I too would like that very much). Feedback of plugin parameter values is also not straightforward. My controller emulates a Mackie control + extender and it works fine with Logic Pro but the way plugins are handled in Reaper and Cubase (I have Logic, Cubase and Reaper and have evaluated Ableton Live) is completely different and as a result my controller doesn't work for plugins with those DAWs, a rewrite of the code would be required.

    Do you want text feedback for the parameters, i.e. are there displays showing values like "2500Hz" or "340ms"? If not than you could use OSC with Reaper. For testing I build a OSC controller for Reaper. Reaper's OSC functionality is very good, alas the text feedback is missing for (continuous) plugin parameters so it's currently not very useful for my controller but if your controller doesn't need text feedback OSC is probably the way to go. I also started a thread on the Reaper forum: Teensy based OSC controller for Reaper

  4. #4
    Senior Member mortonkopf's Avatar
    Join Date
    Apr 2013
    Location
    London, uk
    Posts
    868
    chainable SPI port expanders will give you a lot of pins. With the MCP23s17 expander You can chain eight to one SPI of the Teensy. works just fine for my MIDI projects

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,652
    Quote Originally Posted by Gerrit View Post
    Why would you want to use multiple Teensies?
    If you only consider the cost of semiconductors, then of course a few 50 cent logic chips seems a lot less expensive than another $12 or $20 microcontroller board.

    But the reality is both approaches have plenty of hidden costs. So many of people have gone down the shift register path for huge MIDI controllers. Some make it work. Many others end in frustration. How you physically build everything matters greatly, and usually overwhelms the cost of semiconductors if done well. Everyone loves to focus on semiconductors, but things like connectors, good quality pots, buttons, knobs, and physical enclosures usually end up being the lion's share of the total cost.

    One of the huge advantage of multiple microcontrollers is a modular system that's much easier to troubleshoot and (usually) much more resilient. When something goes wrong, usually it's just one section, where the other parts running with other microcontrollers go on working. Usually this approach involves groups of knobs & buttons with fairly short wires, and importantly, wires that don't cause more than 1 thing to stop working if they come unplugged or break.

    Especially for designs where lots of individual small boards with shift registers are connected by wires, one problem on a clock or power line tends to take down everything. It's a lot harder to troubleshoot. The approaches which save the most money in semiconductors tend to end up with a large amount of wires running everywhere, where a large portion of those wires have the possibility of taking out most or all of the project's functionality if something goes wrong. People who are so focused on saving money tend to solder wires directly to perf boards, which is very cheap compared to good quality connectors having proper strain relief (and avoids buying a special crimp tool), but it ends up being a recipe for ongoing pain, especially if you regularly move the gear and use it in live shows where any failure means you're having to improvise with whatever part is still functioning.

    Certainly the shift register approach can work. But if you're building just one or two large MIDI controllers, and *especially* if you're going to take them on the road and use them in live performance, the sort of cost optimization that makes sense for a mass produced product can be lead you down a path than ends up being "penny wise, pound foolish". These custom build projects have tons of hidden costs and involve all sorts of ad-hoc construction techniques (not the sort of professional building that involves huge up-front investment in tools that you amortize over the sales of thousands of units). Choosing any approach that is physically simpler with fewer wires, fewer points of failure, and less impact when something does go wrong is often well worth the cost of another microcontroller or other "expensive" semiconductors.

  6. #6
    Junior Member
    Join Date
    Dec 2018
    Posts
    3
    First of all thank you all for joining in, your information has been invaluable.

    The thing is, I prefer the simplest solution with hardware, what Paul suggests here, since I'm not particularly electronics minded. I can work through coding with my background but anything above average on difficulty will not suit me. That said, both the port expander solution and the RS485 bus solution, both seem straightforward and feasible. I don't mind the cost of extra Teensies, I'm not trying to build the cheapest MIDI plugin controller, just creating a product that suits my needs as such a device cannot yet be bought (check ohmy!bytes though!). So it's definitely one of those two, the point of the post was to be sure before I buy the Teensy that that sort of configuration can be done, which seems to be the case!

    Gerrit, OSC seems much more capable than MIDI and may even provide a solution on getting feedback from Reaper on gain reduction (did you try ReaComp?), I'm not clear on how to implement it though, I'll have to do a bit of reading on that. I've read your post and as I understad it communication goes over UDP and there's the CNMAT library for Teensy but I have no idea about the kind of commands that can be sent and received, the format in which they must be written etc..

  7. #7
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,802
    you could always control other teensies many of ways, via UART,I2C, SPI,CAN, ETHERNET, etc

  8. #8
    Senior Member
    Join Date
    Jan 2017
    Location
    Maastricht
    Posts
    122
    The most important question is what do you expect from the controller, i.e. what's it supposed to do/be? The Ohmy Bytes controllers you referred to are tailor made for a specific plugin and provide no feedback at all (potmeters and latching switches are used). On switching tracks the controller will not reflect the setting of the newly selected plugin, if this is ok then there are multiple Midi and OSC options. The big advantage of OSC is in the text feedback on track names, plugin names, plugin parameter names but if you don't need that there's no compelling reason to use OSC over Midi.
    The controller I built is the polar opposite of the Ohmy Bytes approach, it is a universal plugin controller that provides feedback on names and settings so that on switching plugin the settings of the newly selected plugin are displayed correctly.
    How do you expect your controller to behave?
    Next question would be what HUI components you have in mind (potmeters, rotary encoders, momentary or latching switches, leds, displays etc) although the choice is related to the first question.
    Third question is how do you see yourself working with it? In other words what's the workflow the controller should support.
    If you have answers to those questions it will be much easier to come up with advice on how to implement the required functionality.

  9. #9
    Junior Member
    Join Date
    Dec 2018
    Posts
    3
    Quote Originally Posted by Gerrit View Post
    The most important question is what do you expect from the controller, i.e. what's it supposed to do/be? The Ohmy Bytes controllers you referred to are tailor made for a specific plugin and provide no feedback at all (potmeters and latching switches are used). On switching tracks the controller will not reflect the setting of the newly selected plugin, if this is ok then there are multiple Midi and OSC options. The big advantage of OSC is in the text feedback on track names, plugin names, plugin parameter names but if you don't need that there's no compelling reason to use OSC over Midi.
    The controller I built is the polar opposite of the Ohmy Bytes approach, it is a universal plugin controller that provides feedback on names and settings so that on switching plugin the settings of the newly selected plugin are displayed correctly.
    How do you expect your controller to behave?
    Next question would be what HUI components you have in mind (potmeters, rotary encoders, momentary or latching switches, leds, displays etc) although the choice is related to the first question.
    Third question is how do you see yourself working with it? In other words what's the workflow the controller should support.
    If you have answers to those questions it will be much easier to come up with advice on how to implement the required functionality.
    The controller is supposed to be a more natural way of working with plugins, which I don't need that many anyway. I occasionally change the plugins I work with but usually I have my go to compressor/EQ/limiter etc. Thus I don't need the controller to be able to adapt to any plugin I throw at it, just to provide a haptic way to control plugins and give me that sought-after "listen with your ears, not with your eyes". For anything else, I will simply continue using a mouse and a keyboard. I have a cheap controller for track control (play,rec,next track, volume, etc) so this is only for controlling plugins in a more organic way.

    I will definitely use encoders so values will not be jumping around when changing tracks but I will not use displays, so no need for text feedback, even though I have been thinking about LED rings around encoders but it's a thought for much later. Maybe there's a way of turning text feedback to numbers in a scale? No idea..

    Your controller is a very nice approach and I admire it, but it doesn't fit my needs, as I said, the point of the controller is to not see values at all but rather arbitrary know where in the spectrum values are. I appreciate your guidance though and any help on figuring out OSC is much welcome!

    Have a nice rest of the weekend everyone!

  10. #10
    Senior Member
    Join Date
    Jan 2017
    Location
    Maastricht
    Posts
    122
    Given your requirements I don't see the benefit of using OSC in stead of Midi for your controller. Perhaps you could pose the question whether to use Midi or OSC for this project on the Reaper forum?
    Having said that, my OSC example sketch actually already contains all the basics for a (much) more sophisticated/complex controller. No external libraries are used and the display is not required for operation, it should compile and run with the default Teensyduino installation.
    The Reaper OSC documentation is a bit rudimentary, it boils down to what's in the Default.ReaperOSC configuration file. See this page on OSC for info how to find that file. On that page it is also mentioned that you can use OSC with a learn function but in that case you'd really be better off just using Midi.
    How do you want to determine which track is controlled? Will the controller always follow the focus on the monitor?
    One of the advantages of using OSC is that you have several options in this respect, the controller can also operate completely independent from the monitor (screen) selection.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •