How do CC work?

NimboStratus

Hi noob question so bear with me.

How do CC midi thingys work? By that I mean if a AUV3 app like SnakeBud or whatever accepts a pattern change on CC10 do you usually have to also pass in a value, ie send the app “CC10, 7” from “somewhere” (still trying to get to the bottom of that) and the receiving app SnakeBud will change it’s pattern to 7?

This is a kinda follow on to my other thread ( https://forum.audiob.us/discussion/45374/auv3-cc-sequencer#latest )about CC In AUM as really want to automate CC sends

Thanks!

mojozart

Keep in mind that AUv3 parameters are a modern replacement for MIDI CC, but I digress.

For starters, here's some Sweetwater to cover the basics:

https://www.sweetwater.com/insync/continuous-controller/

You're specifically asking about sending a pattern change via CC, as opposed to Program Change (PC), which is something different.

On the receiving end, a value of 0 is usually ignored and either a value >0 or a value >63 will trigger the change. To be safe, send 127. Often a press is programmed to send 127 and a depress is programmed to send 0. Then a pattern change will happen on each press.

xor

@NimboStratus yes, you have the gist of it. Midi cc messages contain an id (the cc#) and a value between 0 and 127. From reading through the SnakeBud thread it appears that cc10 should change patterns. The first pattern will probably be selected with the value of zero or one with the other patterns going up from there. You also have to know how the app will respond to the incoming cc (it should mimic how it responds in the ui). Are patterns supposed to change immediately or after the current pattern finishes.

xor

@NimboStratus here’s a quick video of automating ChordBud with StepBud. If SnakeBud is like ChordBud then the cc value will start at 1 for pattern 1. The only thing that I think will be unclear is the long-press on the step# to bring up the edit window in order to disable notes being sent.

wim

Think of MIDI CC's as simply a combination of three values: MIDI Channel, CC#, and CC Value. That part is easy enough. You can send those three values from a controller with knobs, or from an app that can send CC values, or from hardware. It doesn't matter where it comes from, it's all just a series of values.

Next is the receiver of those values and what it does with them. That varies from app to app and also has the added option of AU parameter automation. So, to pick it apart...

• App has a built-in way to deal with fixed midi CC's. Basically it does something in response to receiving a certain CC at a certain value. In this case it sounds like the pattern changes based on the value of CC #10.
• App has a built-in way to map midi CC's or other messages to do something. In that case you can map a different CC to some function.
• App has "AU Parameter" control. In this case, it's not the app itself that makes the connection between midi messages and doing something, it's the host. So, for instance AUM lists a parameter, and it lets you map a midi message to that control, which in turn does something in the app. In contrast to the above two methods, you do not send the midi messages directly to the app, but instead to the host's control mechanism.

Understanding which of those methods you're using at any one time is key to figuring out how things need to be wired together. Also, understanding that all apps vary in their midi/parameter implementations is important.

NimboStratus

Thanks all that Really helps ❤️

LinearLineman

@wim said:
Think of MIDI CC's as simply a combination of three values: MIDI Channel, CC#, and CC Value. That part is easy enough. You can send those three values from a controller with knobs, or from an app that can send CC values, or from hardware. It doesn't matter where it comes from, it's all just a series of values.

Next is the receiver of those values and what it does with them. That varies from app to app and also has the added option of AU parameter automation. So, to pick it apart...

• App has a built-in way to deal with fixed midi CC's. Basically it does something in response to receiving a certain CC at a certain value. In this case it sounds like the pattern changes based on the value of CC #10.
• App has a built-in way to map midi CC's or other messages to do something. In that case you can map a different CC to some function.
• App has "AU Parameter" control. In this case, it's not the app itself that makes the connection between midi messages and doing something, it's the host. So, for instance AUM lists a parameter, and it lets you map a midi message to that control, which in turn does something in the app. In contrast to the above two methods, you do not send the midi messages directly to the app, but instead to the host's control mechanism.

Understanding which of those methods you're using at any one time is key to figuring out how things need to be wired together. Also, understanding that all apps vary in their midi/parameter implementations is important.

Excellent teaching, as always.

Teunis

@xor said:
@NimboStratus here’s a quick video of automating ChordBud with StepBud. If SnakeBud is like ChordBud then the cc value will start at 1 for pattern 1. The only thing that I think will be unclear is the long-press on the step# to bring up the edit window in order to disable notes being sent.

This is brilliant. I spent a day trying to work out how to achieve a result you demonstrated in under 5 minutes. Brilliant works a treat. Thank you.