Skipped CC messages #s

Is there a specific reason why the CC numbers 32 through 63 and then 96 through 101 are not available when we go, for example, to a MIDI FX such as the Modifier and click the dropdown menu to assign a MIDI button/knob?

On my keyboard some pads and knobs are assigned to some of those numbers so when I try to learn the MIDI, those pads or knobs are not learned using the MIDIFX, but if I use the Controller Assignments window and hit Learn, I am able to assign for example CC 44 to a parameter on Alchemy, even though 44 doesn't show up under the MIDIFX dropdown.

The first group are the MSB LSB to CC #0 to 31.

96 to 101 are used for RPN and NRPN.

Both cases suggest that there could be conflicts.

Edit: LSB and MSB

The first group are the MSB to CC #0 to 31.

96 to 101 are used for RPN and NRPN.

 

Both cases suggest that there could be conflicts.

Not sure I understood...

I don't know what RPN and NRPN is and also, the benefits of the MSB?

Anyway, I was assigning my MIDI controller to different parameters and I was able to only use those that are available everywhere, so no worries

I was just curious about why they skipped those numbers...

The controllers from 0 to 31 have only 7 bit resolution from 0 to 127. This isn't that much. That's why there is the technique of sending two combined controllers that allow for 14 bit resolution from 0 to 16383. That's also why we have the inconsistencies with bank select (cc0, cc 32 or both).

NRPN: https://en.wikipedia.org/wiki/NRPN

RPN are pretty much the same.

The controllers from 0 to 31 have only 7 bit resolution from 0 to 127. This isn't that much. That's why there is the technique of sending two combined controllers that allow for 14 bit resolution from 0 to 16383. That's also why we have the inconsistencies with bank select (cc0, cc 32 or both).

 

NRPN: https://en.wikipedia.org/wiki/NRPN

 

RPN are pretty much the same.

Ohhh I see. I didn't know that!

So for example if I use the ModWheel as the way to control a filter cutoff modulation, for example, it will be more "step-y" than if I use for example CC 87?

If it's not that simple, can you please explain how to combine controllers to allow 14 bits?

Thanks

First, I was confused about the actual role of the higher CC#: They are additional LSB's to the lower CC#. Perhaps this confusion comes from the fact that I had mostly to do with the bank select controllers 0 and 32 where this confusion is prevalent with manufacturers as well.

For the other controllers it goes like this: The higher controller number gives an additional 127 steps between each step of the lower controller. Let's take for example Modulation.

Normally this is CC #1, ranging from 0 to 127. When it is use as a 14 bit controller it means that (for example) between values 0 and 1 of CC #1 there are additional values of CC #33, again ranging from 0 to 127. Then between values 1 and 2 of CC #1 again additional values of CC #33 and so on. This means that usually both controllers are sent together.

The MIDI specification allows for sending just the higher numbered CC# for the "fine" steps. Let me quote the relevant part of the MIDI specification 1.0:

Controller numbers 0 through 31 are for controllers that obtain information from pedals, levers, wheels, etc. Controller numbers 32 through 63 are reserved for optional use as the LSB (Least Significant Byte) when higher resolution is required and correspond to 0 through 31 respectively. For example, controller number 7 (Volume) can represent 128 steps or increments of some controller’s position. If controller number 39, the corresponding LSB number to controller number 7, is also used, 14-bit resolution is obtained. This provides for resolution of 16,384 steps instead of 128.

 

If 128 steps of resolution is sufficient the second byte (LSB) of the data value can be omitted. If both the MSB and LSB are sent initially, a subsequent fine adjustment only requires the sending of the LSB. The MSB does not have to be retransmitted. If a subsequent major adjustment is necessary the MSB must be transmitted again. When an MSB is received, the receiver should set its concept of the LSB to zero.

Implementation of this is always a bit spotty; but then even implementation of Pitch Bend (which is 14 bit too) could be a bit strange.

Some hardware controllers can be programmed to send 14 bit values. This means they send both controllers.

As far as your example with modulation or CC #87 goes: No, this won't work (at least not this way). If a hardware controller sends 14 bit values it means it sends controllers as a pair: the "regular" one (CC #x) followed by the "fine" one (CC #x+32).

I don't think this resolution is used often but perhaps Logic is accounting for the original intention here.

First, I was confused about the actual role of the higher CC#: They are additional LSB's to the lower CC#. Perhaps this confusion comes from the fact that I had mostly to do with the bank select controllers 0 and 32 where this confusion is prevalent with manufacturers as well.

 

For the other controllers it goes like this: The higher controller number gives an additional 127 steps between each step of the lower controller. Let's take for example Modulation.

 

Normally this is CC #1, ranging from 0 to 127. When it is use as a 14 bit controller it means that (for example) between values 0 and 1 of CC #1 there are additional values of CC #33, again ranging from 0 to 127. Then between values 1 and 2 of CC #1 again additional values of CC #33 and so on. This means that usually both controllers are sent together.

The MIDI specification allows for sending just the higher numbered CC# for the "fine" steps. Let me quote the relevant part of the MIDI specification 1.0:

 

Controller numbers 0 through 31 are for controllers that obtain information from pedals, levers, wheels, etc. Controller numbers 32 through 63 are reserved for optional use as the LSB (Least Significant Byte) when higher resolution is required and correspond to 0 through 31 respectively. For example, controller number 7 (Volume) can represent 128 steps or increments of some controller’s position. If controller number 39, the corresponding LSB number to controller number 7, is also used, 14-bit resolution is obtained. This provides for resolution of 16,384 steps instead of 128.

 

If 128 steps of resolution is sufficient the second byte (LSB) of the data value can be omitted. If both the MSB and LSB are sent initially, a subsequent fine adjustment only requires the sending of the LSB. The MSB does not have to be retransmitted. If a subsequent major adjustment is necessary the MSB must be transmitted again. When an MSB is received, the receiver should set its concept of the LSB to zero.

 

Implementation of this is always a bit spotty; but then even implementation of Pitch Bend (which is 14 bit too) could be a bit strange.

 

Some hardware controllers can be programmed to send 14 bit values. This means they send both controllers.

 

As far as your example with modulation or CC #87 goes: No, this won't work (at least not this way). If a hardware controller sends 14 bit values it means it sends controllers as a pair: the "regular" one (CC #x) followed by the "fine" one (CC #x+32).

 

I don't think this resolution is used often but perhaps Logic is accounting for the original intention here.

Ok this is waaaay too deep for me hahaha

I don’t really use hardware and maybe that’s where this is relevant. I was thinking of resolution when it comes to drawing automation. Not that I experience any kind of issue, but maybe knowing how that works could help here and there.

But yeah, this is far too advanced. Maybe one day I will go back to this post and understand it

Thanks for trying to clarify it though!

The good news is, there's no need for you to know or understand any of this for basic MIDI Controller use.

And don’t we all love the good news...?

Thanks

Here's the relevant part for the ES2 including a description why those controllers are not available:

https://support.apple.com/guide/logicpro/set-controller-assignments-lgsia12440f/mac

Here's the relevant part for the ES2 including a description why those controllers are not available:

https://support.apple.com/guide/logicpro/set-controller-assignments-lgsia12440f/mac

Thanks. It's still a bit confusing to me, the whole concept, because I don't know how that applies in a practical scenario and the real advantages.

I mean I understand that having 14bits vs 7bits gives you more steps and that increases the resolution (pretty much like having more bit depth while recording, for example), but this concept now is a bit foreign to me. And as David said, I probably don't need to worry about this in order to create the music I'm creating

I really appreciate your links and help, though I wish I could understand and then use that information. No worries!

Just to give you an idea:

Here's a file with an ES2 and two notes. For the first note pitch is modulated with a 7 bit controller (#16), for the second one with a 14 bit pair (#16 and #48).

14bit ctrl.logicx.zip

Just to give you an idea:

 

Here's a file with an ES2 and two notes. For the first note pitch is modulated with a 7 bit controller (#16), for the second one with a 14 bit pair (#16 and #48).

 

 

14bit ctrl.logicx.zip

I appreciate your effort

Ok so this is what I was thinking I needed to do, using 2 automation lanes. Makes sense. I guess I was thinking it was a more complex process.

And yes, I've experienced that "step-y" thing in the past and knowing I can fix that, it's definitely worth knowing this trick.

Looking at the automation you created, I know have a few questions:

1 - You didn't use a straight line to create the pitch for CC 16 (General #1). Any reason for that? If I have a straight line already, how can I apply the same concept? With a straight line it's hard to really pick where the next pitch starts and ends (not so accurately, if that even matters)?

2 - Why did you pick those 2 CC's? Is there a reason why you picked 16 specifically?

3 - I guess the reason why you picked CC 48 is because it says #16LSB so it's related to the CC16 you picked initially? So it's that relationship you mentioned before?

4 - I noticed that for CC48, you always create a ramp down in between the 2 numbers in CC16, for example in between 1 and 2, 2 and 3, etc). Why is that? Is it like a "reset"?

5 - On CC48 the ramp up doesn't always start or end on the same number as the previous ramp up. For example the ramp up for the number 4 on CC16, it goes from 4 to 114 on CC48, but then for the number 5 on CC16, it goes from 8 to 123 on CC48. Why is that? Does it make a difference?

6 - Also, that ramp down in between numbers is not always aligned with the numbers on CC16. Is it supposed to? Is it irrelevant? How unaligned can it be? The only one aligned is the first node; was that on purpose or by accident?

7 - What if I wanted to use a different CC, for example CC107? Would I be able to reproduce the same effect? If so, how?

Sorry, but now you opened pandora's box and I'm going to ask you everything until I understand it and can apply it hahaha

But indeed makes it way smoother and in the past I "complained" about it. No one seemed to either understand it as much as you do or they just didn't bother to explain. So I appreciate it once again you patience and help!

Just to give you an idea:

 

Here's a file with an ES2 and two notes. For the first note pitch is modulated with a 7 bit controller (#16), for the second one with a 14 bit pair (#16 and #48).

 

 

14bit ctrl.logicx.zip

I was playing with the file you sent, making some changes to see if I could understand a few things, but I'm getting some weird results

1 - When I remove all the nodes between the same number on CC16, the effect is the same. For example all the nodes between 2 and 2, then between 3 and 3, etc. So why does your example have all those nodes?

2 - When I do the same for CC48 and I make the ramp up 100% straight, I hear a jump in pitch when it goes from 1 semi tone to another. Here's the file (green is your original region, blue is mine with only the nodes from CC16 removed, pink are the ones that cause that jump when I remove some or all nodes).

14bit ctrl - 2.logicx.zip

Ok so this is what I was thinking I needed to do, using 2 automation lanes. Makes sense. I guess I was thinking it was a more complex process.

On the contrary I think the process is quite convoluted and also somewhat buggy. Or perhaps I simply don't know fully how it works. We'll get to that in a second; and I would welcome input from anybody.

Please keep in mind that the file as intended as an example for the audible effect, not so much for how to practically work with 14 bit controllers. It actually took me a bit of effort to get there because Logic was working not all the time as I thought it would.

And off we go:

1 - You didn't use a straight line to create the pitch for CC 16 (General #1). Any reason for that?

The automation wasn't drawn; it was recorded from a 14 bit fader in the environment (I don't have a 14 bit hardware controller at home right now).

If I have a straight line already, how can I apply the same concept? With a straight line it's hard to really pick where the next pitch starts and ends (not so accurately, if that even matters)?

Exactly; and I don't have an immediate answer for this. The additional controllers must be "nested" between the values of the main controller; and those are simply not visible in the automation lane if you have drawn just a line between two points. If there is a way to truly just draw 14 bit controllers I haven't yet found it.

2 - Why did you pick those 2 CC's? Is there a reason why you picked 16 specifically?

Not much of a reason, except that it is already one of the default controllers in the ES2 (Ctrl C). I could have picked any other controller under #32 instead of #16.

3 - I guess the reason why you picked CC 48 is because it says #16LSB so it's related to the CC16 you picked initially? So it's that relationship you mentioned before?

Exactly. The ES2 automatically uses the LSB controller (in this case #48; but in general "MSB + 32") for fine adjustments. That's why it isn't possible to pick #48 in the ES2 itself.

4 - I noticed that for CC48, you always create a ramp down in between the 2 numbers in CC16, for example in between 1 and 2, 2 and 3, etc). Why is that? Is it like a "reset"?

It's not so much a ramp as simply a new value. Those lines (as we normally use them) can be very misleading. It's a good idea to look at the event list for this particular example; we'll do this in a second.

5 - On CC48 the ramp up doesn't always start or end on the same number as the previous ramp up. For example the ramp up for the number 4 on CC16, it goes from 4 to 114 on CC48, but then for the number 5 on CC16, it goes from 8 to 123 on CC48. Why is that? Does it make a difference?

It's a bit like pitch bend or "thinning out" the MIDI data stream. As you noticed there are just a handful of #48 values between each #16 value (instead of the full range from 0-127). This still gives a higher resolution than the plain 7 bit from #16; and every additional "step" between those #16 values makes the transition sound smoother.

6 - Also, that ramp down in between numbers is not always aligned with the numbers on CC16. Is it supposed to? Is it irrelevant? How unaligned can it be? The only one aligned is the first node; was that on purpose or by accident?

I guess now it would be a good idea to look at the event list and talk about bugs or problematic implementation:

(this is a German installation; "Steuerung" means "Controller"; and no - I wouldn't have localized that...)

I've highlighted in red the actual transition from CC #16 value 0 to CC #16 value 1. I've also highlighted in blue the additional values of #16. Those don't really serve a purpose at all (except I'm missing something here - more about this in a second).

It's also quite obvious that the #48 values are always sent as a "pair" (except when #16 actually moves to a higher value); and after the second #48 value the #16 value is sent again, even if it hasn't changed.

So the values for #48 between CC #16 value 0 and 1 are:

2, 30, 35, 50, 58, 73, 76, 83, 91, 104, 111, 117, 124

Now the "spillover" to CC #16 value 1 occurs; and #48 starts anew:

4, 11, 24, 39, ...

(again with additional #16 value 1 sprinkled in between)

Why do we have those additional CC #16 values, even if #16 hasn't changed?

I don't know. If I had to guess I would say it's some sort of automatic function: after a certain time has passed the MSB controller is "resent". Or the general idea was to always send a pair #16 with #48 together; and those cases where two sole #48 are sent in a row are not intentional. Or maybe it's a function of the environment controller.

I really don't know how much of this is intentional and how much might be a bug.

For example: I tried to delete those additional #16 values when the value doesn't change. It simply did not work yesterday (even after restarting Logic): Deleting a single #16 event took out ALL #48 events. Tried it again this morning - now it mysteriously works.

Actually those additional (unneeded) #16 values could even be considered harmful. The MIDI specification says:

When an MSB is received, the receiver should set its concept of the LSB to zero.

So in theory all those additional #16 values would be interpreted as an additional #48 with value 0 (then immediately followed by the correct #48 value). On the other hand the #16 and #48 values appear at the same time so perhaps this isn't a big deal for the Logic plugins at least

7 - What if I wanted to use a different CC, for example CC107? Would I be able to reproduce the same effect? If so, how?

No, it wouldn't work; at least not with the assignment in the ES2. This requires you to pick the MSB controller and it automatically interprets the LSB controller (MSB + 32) if it is present. There can't be an LSB controller for #107 since this would have to be #139 which is outside the MIDI range.

1 - When I remove all the nodes between the same number on CC16, the effect is the same. For example all the nodes between 2 and 2, then between 3 and 3, etc. So why does your example have all those nodes?

I simply recorded the environment controller. Those additional nodes don't serve a purpose. I would have deleted them myself if it would have worked at the time...

You could have even deleted more of them: You always left a single value before the "spillover" to the next one:

Those could be deleted as well and it would have no audible consequences. I've attached another example of the song with them deleted.

2 - When I do the same for CC48 and I make the ramp up 100% straight, I hear a jump in pitch when it goes from 1 semi tone to another. Here's the file (green is your original region, blue is mine with only the nodes from CC16 removed, pink are the ones that cause that jump when I remove some or all nodes).

That's because the "reset" happens now before #16 jumps to its next value:

Those two values pull #48 down to pretty much to zero BEFORE #16 makes the transition from 0 to 1. That of course is audible again as a step.

(Keep in mind that additional #16 value 0 is not needed at this point)

What you need is an ultra steep transition at the same moment #16 changes its value, like this:

This puts the LSB values exactly where we want them:

I took your last region and modified it accordingly; it's the orange region. And last but not least at the end there's a green region which takes #48 to its full 0-127 range.

Personally I think it would be nice to have a single 14 bit automation lane that would perform this automatically. As I wrote: having to "sandwich" those data is cumbersome and error-prone.

14bit ctrl - 3.logicx.zip