Make an audio plugin controller with teensy 3.6

Status
Not open for further replies.
Hi everyone,

I'm starting a new project for school, I want to make a controller for a specific audio plugin.

My knowledge is :

- I know I can make MIDI learn and control potentiometers of my plugins with some reals potentiometers for example, looks easy.
- I know I can receive MCU information from basic commands from the daw like track selection, vu meters etc..

But I would like to receive information from the audio plugin, to show them on an oled screen for example or even motorized fader...

My question is :

- Does audio plugin send midi information outside the DAW when for example I turn a knob in the audio plugin interface ?
- If they aren't, does the daw can do that ?

I looked at lot of topics and I don't have clearly seen if that is possible or not.

Thanks a lot and sorry for my english.
 
Does audio plugin send midi information outside the DAW when for example I turn a knob in the audio plugin interface ?
It's really down to the individual plugin. You might have some luck with the stock plugins in your DAW.

If they aren't, does the daw can do that ?
It may be possible to manually map MIDI to and from plugin parameters in Ableton or FL Studio perhaps?
You would have to set this up for each individual instance of the plugin though, and it would be quite a time-consuming process to map each time.
 
It's really down to the individual plugin. You might have some luck with the stock plugins in your DAW.


It may be possible to manually map MIDI to and from plugin parameters in Ableton or FL Studio perhaps?
You would have to set this up for each individual instance of the plugin though, and it would be quite a time-consuming process to map each time.

Hello there - yeah, its been a constant frustration for me, too, especially with some plugins able to transmit some midi information, but not all parameters, and precise documentation hard to find or non-existent. As above, it's really down to the plug in. As you've noticed, the most you'll get from most web-sites is that a plug-in will midi learn, which isn't terribly helpful.

For a daw I use cubase, and for me so far in the VST plugins I've played with the most comprehensive midi implementation has probably been with the blue cat audio plugins. There is a generic midi remote in cubase that is extremely useful for midi out of parameters and information from daw/plug-in to external controller, but takes a little thought to program. This still relies on the programmer of the plugin to make the parameters available, though.

Might seem a little odd, making hardware controllers for what is essentially a software emulation of an older piece of hardware :), but there is some rationale behind it, at least for me. It's far more satisfying to have the immediacy of knobs, dials and displays than use a mouse, and eg for my basic amplitude controller I can place it so I don't have to reach across a desk whilst trying not to bang my guitar, and I can't afford all the original hardware...

I would suggest using encoders rather than pots for your controller, though - after all, if a parameter changes in the daw, from eg automation data, the position of the pot won't represent the value of that parameter anymore. This is got round in some midi controllers by holding the transmitted value from the daw until the pot is moved through that value, which is a bit kludgy. I've got a jl cooper fadermaster that basically does that. With an encoder, you can update the encoder value in your code without needing to move it, although I do appreciate that encoders are more expensive than pots. Optical encoders, which are admittedly more expensive than mechanical ones, take a little less programming as they don't need de-bouncing of the switches for an accurate reading, but the big advantage of them for me is that they can be moved faster without skipping counts. I've had pretty good success with fairly cheap 360/600 ppr (pulses per rotation) encoders from china/HK, which come in at around 10gbp or so each. The very cheap mechanical "KY-40" type encoders with switch come in at under 1gbp still work, they're just not as responsive and you can't be as rough with them. For optical encoders, just divide down the number of pulses you read to fit your purpose. My early projects started using 1 rotary encoder, led button switches via an mcp23017 ic to choose what parameter was being controlled by the encoder, and an ili9341 lcd display to display the values.

Motorised faders seem more trouble than they're worth, to be honest - and they're fairly expensive, too. I've never tried programming one, but I've got a jl cooper mcs 3800 daw controller that has them, and never really use it. Again, feedback never seems to be immediate enough, although the flying fader thing does look pretty impressive :). Personally, I'd rather have visual feedback from a dedicated display.

Not posted on here for a while, this hobby was sort of put to one side during covid, due to my work-life being insane and my wife working from home. Hopefully can pick it back up again.

Best of luck with your project.

Paul.
 
I might be tempted to use HID to interface with the plugin.
1.You could eliminate any sort of MIDI setup, giving you a plug and plug experience.
2. You could use higher than 7bit resolution.

The only issue and can foresee is with multiple instances of the plugin. You controller would have to know which instance to control.
 
Hello there - yeah, its been a constant frustration for me, too, especially with some plugins able to transmit some midi information, but not all parameters, and precise documentation hard to find or non-existent. As above, it's really down to the plug in. As you've noticed, the most you'll get from most web-sites is that a plug-in will midi learn, which isn't terribly helpful.

For a daw I use cubase, and for me so far in the VST plugins I've played with the most comprehensive midi implementation has probably been with the blue cat audio plugins. There is a generic midi remote in cubase that is extremely useful for midi out of parameters and information from daw/plug-in to external controller, but takes a little thought to program. This still relies on the programmer of the plugin to make the parameters available, though.

Might seem a little odd, making hardware controllers for what is essentially a software emulation of an older piece of hardware :), but there is some rationale behind it, at least for me. It's far more satisfying to have the immediacy of knobs, dials and displays than use a mouse, and eg for my basic amplitude controller I can place it so I don't have to reach across a desk whilst trying not to bang my guitar, and I can't afford all the original hardware...

I would suggest using encoders rather than pots for your controller, though - after all, if a parameter changes in the daw, from eg automation data, the position of the pot won't represent the value of that parameter anymore. This is got round in some midi controllers by holding the transmitted value from the daw until the pot is moved through that value, which is a bit kludgy. I've got a jl cooper fadermaster that basically does that. With an encoder, you can update the encoder value in your code without needing to move it, although I do appreciate that encoders are more expensive than pots. Optical encoders, which are admittedly more expensive than mechanical ones, take a little less programming as they don't need de-bouncing of the switches for an accurate reading, but the big advantage of them for me is that they can be moved faster without skipping counts. I've had pretty good success with fairly cheap 360/600 ppr (pulses per rotation) encoders from china/HK, which come in at around 10gbp or so each. The very cheap mechanical "KY-40" type encoders with switch come in at under 1gbp still work, they're just not as responsive and you can't be as rough with them. For optical encoders, just divide down the number of pulses you read to fit your purpose. My early projects started using 1 rotary encoder, led button switches via an mcp23017 ic to choose what parameter was being controlled by the encoder, and an ili9341 lcd display to display the values.

Motorised faders seem more trouble than they're worth, to be honest - and they're fairly expensive, too. I've never tried programming one, but I've got a jl cooper mcs 3800 daw controller that has them, and never really use it. Again, feedback never seems to be immediate enough, although the flying fader thing does look pretty impressive :). Personally, I'd rather have visual feedback from a dedicated display.

Not posted on here for a while, this hobby was sort of put to one side during covid, due to my work-life being insane and my wife working from home. Hopefully can pick it back up again.

Best of luck with your project.

Paul.

Thanks for all the information you bring, and I totally agree with you on the interest to make a controller of a machine simulation. It's all about the feel of the touch. I'm thinking of using encoders, I've looked a bit at how to handle motorized potentiometers but it's indeed a bit too complicated for the interest it brings.

I'm still looking for a solution to receive all the parameters of the plugin. I'm not sure I understand, I don't use cubase, is it possible to redirect any parameter of a plugin in midi out ? Or does it still depend on if the developer made it available or not?

Assuming yes as you said it is tedious to have to remap midi outs every time you restart the DAW. I'm looking to see a plug and play experience. Maybe developing an application that interfaces between the DAW and the controller that does the remapping? But I'm not even sure if the DAW can communicate easily with external applications.


I might be tempted to use HID to interface with the plugin.
1.You could eliminate any sort of MIDI setup, giving you a plug and plug experience.
2. You could use higher than 7bit resolution.

The only issue and can foresee is with multiple instances of the plugin. You controller would have to know which instance to control.

I'm not sure what you mean by HID? I took a look at USB HID but I don't understand how it can be plug and play?
 
It wouldn't be plug and play for the developer, but it could be for the users. It's not trivial to implement, but what you would do is use a rawHID interface (which can be combined with MIDI). Your plugin would see if the a rawHID interface is connected to the system, and if it is, it could read and send rawHID packets to and from that interface. This is how my control applications for MIDI Expression and eDRUMin devices work. RawHID is class compliant so it works on almost all operating systems, except for iOS (for some reason, Apple will not approve any applications that try to use rawHID APIs).
 
Thanks for all the information you bring, and I totally agree with you on the interest to make a controller of a machine simulation. It's all about the feel of the touch. I'm thinking of using encoders, I've looked a bit at how to handle motorized potentiometers but it's indeed a bit too complicated for the interest it brings.

I'm still looking for a solution to receive all the parameters of the plugin. I'm not sure I understand, I don't use cubase, is it possible to redirect any parameter of a plugin in midi out ? Or does it still depend on if the developer made it available or not?

Assuming yes as you said it is tedious to have to remap midi outs every time you restart the DAW. I'm looking to see a plug and play experience. Maybe developing an application that interfaces between the DAW and the controller that does the remapping? But I'm not even sure if the DAW can communicate easily with external applications.




I'm not sure what you mean by HID? I took a look at USB HID but I don't understand how it can be plug and play?

Aye, it's only possible to redirect a parameter that the developer of the plugin has made available. They're not always well documented, and even when available can sometimes only be accessed by somewhat cryptic abbreviations. The way in which parameters are accessible is down to the DAW software, as well. As I say, I use cubase, which has the very configurable generic remote functions. I'm not sure if other DAWs have anything to compare to it fully, but I would assume that there would be equivalents. This allows mapping of specific parameters to specific MIDI ports be saved, so they only need to be programmed once. They don't need to be remapped every time, and the generic remote will allow for multiple copies of the same plug in to be controlled by eg track selection. So, by directing to/from the teensy midi port, all the plugin parameters can be read and written from the teensy. Once done, pretty much plug it in and it works. I posted a kush hammer eq controller project a bit back, with some notes on how I put it together and the sketch, please feel free to have a look and use any bits that might be helpful. This is just a hobby, and that project was an enjoyable learning curve for me. I'm sure the code could be greatly improved upon, but I tried to document it as I went along, and it might be in line with what you're trying to achieve.

As a hunch, I think that sometimes the leaving out of access to a particular parameter is deliberate, to make it more difficult to make dedicated controllers, possibly as a licensing requirement. Just a hunch, though. The other thing that can make dedicated controllers awkward and frustrating is plug-ins such as eg slate vmr, where parameters are assigned to slots in a rack, rather than individual modules, or stand-alones such as amplitube, where parameters are assigned to presets, rather than amps/pedals individually.

As an aside, there have been proprietary sort of plug and play MIDI control protocols around for a while, eg Mackie HUI, Steinberg Houston, JL Cooper, etc, and these have "hooks" written into the DAW as a specific licensed controller. They use dedicated MIDI ports in a non-standard way, and they usually rely on a "handshake" from the hardware controller to begin to operate. Some generic MIDI controllers, eg Behringer BCF, can emulate these protocols.

Welcome to the maddening world.....

Paul.
 
Status
Not open for further replies.
Back
Top