What's going on with MIDI automation? Or with me??

[FMiguelez]

Agreed.

There are like a million ways of doing things with DP.

I know software companies (in general) can be a bit slow to incorporate user's feature requests. It does not surprise me at all, though, since there are a few things that not even WE (MOTUNation users) can agree on in terms of priorities and new features.

There is this other awesome software company called OmniGroup (not music related, though) that has this GREAT system of listening to customers' wish-lists:
They have this sort of "cue", where the most requested features tend to be the top-priority in their to-dos list. They have this Suggestions Box where users can write and let them know about what they want, so it's very cool because at least you know that the most popular requests get implemented according to demand.
They are VERY tight lipped too in regard to release dates and details (ahem), but they found the perfect balance of listening and acting without compromising company policies.

I think basically any Audio company (ahem) could benefit from a model like this. Especially because it's quite simple and effective.

[Shooshie]

Did you ever get your problem figured out from your original post? Basically it's this:

1) Continuous Control-Change data (CC's) are MIDI, and not automation data. They are recorded as MIDI, and automation setup does not affect them in any way, nor vice versa. They can be used to control a synth in real time, thus they are often considered "automation," but they are automating the targeted synth, NOT the Channel Strip or Audio Track faders and knobs in DP.
2) Audio automation control points, which automate the controls on a channel strip, are not MIDI information. They are stored as automation data.

MIDI Volume (CC #7) is not to be confused with Automation Volume. You can convert one to the other in the Region/Reassign Continuous Data Menu. The Audio automation data is a check box or radio button or something. You can't enter "7" into the CC# field and get audio automation. It's a separate type of data. Likewise with Pan, mute, and others.

CC data is for controlling synthesizers. While they are loosely given names such as Modulation Wheel (CC#1), Breath Control (CC#2), Expression #11, Volume #7, and so forth, in reality any of them can be assigned to any function. The attempt to standardize them is just a MIDI convention that makes it easier to use someone else's MIDI tracks.

Then there are the double-CC functions that we call NRPN Controllers. (Non-Registered Parameter Numbers) These usually require two MIDI CC channels to operate. I try to keep them in a track of their own, because editing them becomes extremely difficult if they get mixed up with other CCs in a MIDI track. One of the easiest ways to use NRPN's is to record a MIDI CC as a mockup for the NRPN you want, then use DP's Reassign Continuous Data to convert it to NRPN. You'll end up with two sets of data, one for coarse and one for fine control. This gets you a set of data with essentially 16,384 values. (128*128)

I can't imagine how much confusion this must cause people who are just getting into this business. Whoever thought this stuff up had a very limited vocabulary, and ended up using the same terms to describe a LOT of stuff. Confusion reigns, but once you figure it out it all makes sense. (Still, they could have thought up different names for these things!)

Shooshie

[tommymandel]

This is great clarification, Thank you Shooshie

[FMiguelez]

Did you ever get your problem figured out from your original post? Basically it's this:

1) Continuous Control-Change data (CC's) are MIDI, and not automation data. They are recorded as MIDI, and automation setup does not affect them in any way, nor vice versa. They can be used to control a synth in real time, thus they are often considered "automation," but they are automating the targeted synth, NOT the Channel Strip or Audio Track faders and knobs in DP.
2) Audio automation control points, which automate the controls on a channel strip, are not MIDI information. They are stored as automation data.

MIDI Volume (CC #7) is not to be confused with Automation Volume. You can convert one to the other in the Region/Reassign Continuous Data Menu. The Audio automation data is a check box or radio button or something. You can't enter "7" into the CC# field and get audio automation. It's a separate type of data. Likewise with Pan, mute, and others.

CC data is for controlling synthesizers. While they are loosely given names such as Modulation Wheel (CC#1), Breath Control (CC#2), Expression #11, Volume #7, and so forth, in reality any of them can be assigned to any function. The attempt to standardize them is just a MIDI convention that makes it easier to use someone else's MIDI tracks.

Then there are the double-CC functions that we call NRPN Controllers. (Non-Registered Parameter Numbers) These usually require two MIDI CC channels to operate. I try to keep them in a track of their own, because editing them becomes extremely difficult if they get mixed up with other CCs in a MIDI track. One of the easiest ways to use NRPN's is to record a MIDI CC as a mockup for the NRPN you want, then use DP's Reassign Continuous Data to convert it to NRPN. You'll end up with two sets of data, one for coarse and one for fine control. This gets you a set of data with essentially 16,384 values. (128*128)

I can't imagine how much confusion this must cause people who are just getting into this business. Whoever thought this stuff up had a very limited vocabulary, and ended up using the same terms to describe a LOT of stuff. Confusion reigns, but once you figure it out it all makes sense. (Still, they could have thought up different names for these things!)

Thank you for following up on this, Shoosh.

NOW I understand that CCs other than 7 and 10 are not really considered automation data by DP. Now I understand why they don't work as I expected, since they are "recorded as MIDI".

However, this is a total bummer, since just knowing about it does not solve the problem.

Take a VI such as Vienna Instruments (you have it). In order to automate most of its parameters, one must use, in addition to key switches, all those other CCs for it to make it shine. I assigned, just to mention a few, CCs 2,3,4,5,6,8,9, etc., to automate things like Cross Fade velocity, Attack, Release, Humanize, etc.
Any of my normal MIDI tracks will use at least nine to ten of those CCs at any given time, in addition to Volume (pan -width and position use 48 and 49).

As you can imagine, when one is programming this VI, it doesn't really matter if they are considered automation data or plain raw MIDI by DP. One still needs to do basic things such as selectively disabling or enabling any CC, taking snapshots, using the mixer's record-automation facilities (latch modes and normal modes) etc.
These days one would expect to be able to treat these other CCs as if they were 7 or 10. It is a real necessity. A MUST-HAVE. Otherwise, one really feels crippled by not being able to do any of the above, or having to jump through all kinds of hoops and workarounds to do those elementary every-day automation things.

In other words, MOTU really must make them be "automatable". Like I said, I understand the logic behind why this is not the case at the moment, but the problem remains. I REALLY feel MOTU must address this issue. Most VIs DEMAND this basic flexibility and agility. Maybe there was not a need to do so during the last decade, but now the rules have changed and DP must reflect that by giving us a solution to deal with this.

I already know all the workarounds to make this pseudo-work, but they feel so clumsy. For instance, to disable CC#48 one must either, delete it or move it to another track or take. And that's only for dealing with one of them.
When one uses all these CCs constantly, in every track, this really becomes a handicap and a real waste of time. It becomes a track-management nightmare!

And the solution to improve all this is really simple: MAKE ALL CCs AUTOMATION-FRIENDLY, just like 7 or 10. And make them take advantage of all the mixer's automation-recording features that we already have.

I could really beg for this...

[toodamnhip]

Thank you for following up on this, Shoosh.

NOW I understand that CCs other than 7 and 10 are not really considered automation data by DP. Now I understand why they don't work as I expected, since they are "recorded as MIDI".

However, this is a total bummer, since just knowing about it does not solve the problem.

Take a VI such as Vienna Instruments (you have it). In order to automate most of its parameters, one must use, in addition to key switches, all those other CCs for it to make it shine. I assigned, just to mention a few, CCs 2,3,4,5,6,8,9, etc., to automate things like Cross Fade velocity, Attack, Release, Humanize, etc.
Any of my normal MIDI tracks will use at least nine to ten of those CCs at any given time, in addition to Volume (pan -width and position use 48 and 49).

As you can imagine, when one is programming this VI, it doesn't really matter if they are considered automation data or plain raw MIDI by DP. One still needs to do basic things such as selectively disabling or enabling any CC, taking snapshots, using the mixer's record-automation facilities (latch modes and normal modes) etc.
These days one would expect to be able to treat these other CCs as if they were 7 or 10. It is a real necessity. A MUST-HAVE. Otherwise, one really feels crippled by not being able to do any of the above, or having to jump through all kinds of hoops and workarounds to do those elementary every-day automation things.

In other words, MOTU really must make them be "automatable". Like I said, I understand the logic behind why this is not the case at the moment, but the problem remains. I REALLY feel MOTU must address this issue. Most VIs DEMAND this basic flexibility and agility. Maybe there was not a need to do so during the last decade, but now the rules have changed and DP must reflect that by giving us a solution to deal with this.

I already know all the workarounds to make this pseudo-work, but they feel so clumsy. For instance, to disable CC#48 one must either, delete it or move it to another track or take. And that's only for dealing with one of them.
When one uses all these CCs constantly, in every track, this really becomes a handicap and a real waste of time. It becomes a track-management nightmare!

And the solution to improve all this is really simple: MAKE ALL CCs AUTOMATION-FRIENDLY, just like 7 or 10. And make them take advantage of all the mixer's automation-recording features that we already have.



Amen brotha, well said!!

[Shooshie]

And the solution to improve all this is really simple: MAKE ALL CCs AUTOMATION-FRIENDLY, just like 7 or 10. And make them take advantage of all the mixer's automation-recording features that we already have.

You're confusing CC7 and CC10 with Volume and Pan. Volume and Pan are automation data. CC7 and CC10 are controllers that are optionally assigned to Volume and Pan. But they are MIDI, not automation.

What you seem to want is for Vienna to add automation to their VI interface. They've opted for MIDI control. You want automation control. They would have to add that. I don't know if it's possible for a DAW developer to reach into a VI's code and add automation to it in that way. I think it requires the VI's developer (Vienna) to add those programming hooks to their code. Since not all DAWs use automation data, or use it in the same way, the writers of Vienna Symphonic Library probably figured that learnable CC MIDI data was the best compromise. It would be up to them to go back and add audio automation data.

Since the first difference between the two data types is that one works in audio and one works in MIDI, that's probably the deciding factor for which type of code they use to make these work. MIDI just makes more sense for VI's, even though they do produce audio.

Personally, I find MIDI code easier to edit than automation code. It's not a problem for me to edit tons of MIDI Control for an instrument. You just develop ways of working that allow you to quickly isolate that particular CC type: quick filter will usually do the trick. Or, select a whole line of it (double click) and drag that selection to a scratch track in the Tracks Overview Window. There, DP's reshape tool and all its options allow for quick editing. If you can't get that exact ramp you want, then grab a control point and move it. The level of precision is up to you and the method you choose. You'd probably want to use Line Mode for this type of editing.

Shooshie

[FMiguelez]

You're confusing CC7 and CC10 with Volume and Pan. Volume and Pan are automation data. CC7 and CC10 are controllers that are optionally assigned to Volume and Pan. But they are MIDI, not automation.

I'm not confusing them. I just want MOTU to make make them behave the same way, even if they are different things. Even if MOTU must make some kind of "translator" interface.

What you seem to want is for Vienna to add automation to their VI interface. They've opted for MIDI control. You want automation control. They would have to add that.

FINALLY we are communicating!!
Finally you got my point!!! (although it was probably my fault not making myself clear)

Suenan las campanas, la la la la laaaaaa

My question to you is: If Vienna and most other VI companies choose to use MIDI control, I think it should be MOTU the one who invents some kind of translator than converts MIDI control to automation control. Wouldn't that be the obvious choice?

Man, why couldn't I just say that in my first post? I could've avoided all this miscommunication in the first place.

Ok. What do you think about this now, Shoosh?
Do you not think it would be a GREAT and needed feature? It would speed up my (our) editing 1000%

[rukidding]

I've been bitching and moaning about this for years and the problem is DP's drivers. They don't work with ANY control surface and I've tried many. Don't expect it in 8 either. If I know MOTU they'll have us buy a box to fix the problem rather than rewriting software. We're in the MUSIC business not the graphic arts business!

[Shooshie]

You're confusing CC7 and CC10 with Volume and Pan. Volume and Pan are automation data. CC7 and CC10 are controllers that are optionally assigned to Volume and Pan. But they are MIDI, not automation.

I'm not confusing them. I just want MOTU to make make them behave the same way, even if they are different things. Even if MOTU must make some kind of "translator" interface.

What you seem to want is for Vienna to add automation to their VI interface. They've opted for MIDI control. You want automation control. They would have to add that.

FINALLY we are communicating!!
Finally you got my point!!! (although it was probably my fault not making myself clear)

Suenan las campanas, la la la la laaaaaa

My question to you is: If Vienna and most other VI companies choose to use MIDI control, I think it should be MOTU the one who invents some kind of translator than converts MIDI control to automation control. Wouldn't that be the obvious choice?

Man, why couldn't I just say that in my first post? I could've avoided all this miscommunication in the first place.

Ok. What do you think about this now, Shoosh?
Do you not think it would be a GREAT and needed feature? It would speed up my (our) editing 1000%

Oh, I can think of several new designs that would make it easier to edit CC data, but I can't honestly say that I'd recommend converting it to automation data. It feels a little like, say, converting a shower booth into a bathtub, then adding a shower so that you don't have to take baths. In other words, I think they could do what you want by changing the way that CC data is edited. Perhaps they could break out CC data into individual lanes, so that without having to change your record-enabling, it would automatically put each CC into its own lane without overwriting those in other lanes. There could be an "edit mode," which enables you to "touch edit" CC data, so that it only records when new data is coming in, and doesn't erase when you're not sending data. I could see that happening.

In fact, I like the idea of CC lanes. They'd all be visible together as they are now, but when you hit the CC editor button, they'd all bust out in individual lanes. That sounds pretty cool, actually. But then there's the problem of getting MOTU to think that it sounds cool. I've got another big letter to write to MOTU, so maybe if I put this in there, too, they'd get the message.

Another reason I like this idea, is because it's clear, concise, and not hard to grasp in its importance or execution. The idea of converting to automation data? Well… let me put it this way: not gonna happen!

This seems like a more workable solution to me, FM: CC lanes that break out when in CC edit mode, which permits "touch style" punch-in edits. It could resemble the current comp tool: the track we're accustomed to is visible until you hit the button, then the other lanes open up under the main track.

Sounds good to me!

Shooshie

[JoeDeF]

In other words, I think they could do what you want by changing the way that CC data is edited. Perhaps they could break out CC data into individual lanes, so that without having to change your record-enabling, it would automatically put each CC into its own lane without overwriting those in other lanes. There could be an "edit mode," which enables you to "touch edit" CC data, so that it only records when new data is coming in, and doesn't erase when you're not sending data. I could see that happening.

In fact, I like the idea of CC lanes. They'd all be visible together as they are now, but when you hit the CC editor button, they'd all bust out in individual lanes....

This seems like a more workable solution to me, FM: CC lanes that break out when in CC edit mode, which permits "touch style" punch-in edits. It could resemble the current comp tool: the track we're accustomed to is visible until you hit the button, then the other lanes open up under the main track.

I am still using DP 7.24, and have been fairly frustrated with the issues raised in this thread. Thanks to all who clarified the situation by participating.

To Shooshie (or anyone else in the know): Has this CC behavior been changed (improved) in DP8? Can CC information now be made to be responsive to touch, latch, or trim behavior in punching in (similar to the way automation works)?

I will surely update before long either way, but if this improvement is there in DP8, it will surely make upgrading to DP8 my biggest priority.

Thanks,

Joe

[FMiguelez]

Hi, Joe.

Nope. Unfortunately, NONE of the issues I raised in this thread have been addressed, and I see no indication of that happening any time soon

So it looks like we will need to keep on resorting to half-measures and workarounds to deal with these issues (basically my 4 or 5 point list up-thread).

I think this will eventually NEED to be fixed and improved. The only thing that will make this a priority for MOTU is if people start asking for it. If you would like to see any of the issues I raised fixed soon, then let MOTU know via the proper channels.

[JoeDeF]

Nope. Unfortunately, NONE of the issues I raised in this thread have been addressed, and I see no indication of that happening any time soon....

The only thing that will make this a priority for MOTU is if people start asking for it....

Thanks for the reply, FMiguelez, and I appreciate you raising this topic.

I will ask for it. I am familiar with the workarounds, and will continue to use them. Maybe together we can get MOTU rolling on this, as this is an area of DP that is sorely in need of an update. Control surfaces and CC controllable VI's and plugins are mainstays of the typical modern workflow (a hundred times moreso than they were ten or fifteen years ago). So, I hope that MOTU will see the value in improving controller punch-ins, quasi-automation, and the like.

Joe
(using Performer/DP since 1988)

[waterstrum]

I'm having good luck automating my plugins and VIs in DP 7.24.
So far, I haven't run in to a situation where I couldn't get the results I wanted.

That being said, I think I don't understand the question.

A couple of posts implied that MOTU is behind the curve in this implementation.
That implies that other DAWs are doing it better.
Can you point to a DAW that has the feature you are seeking?
That would help MOTU help you.

[waterstrum]

I've been bitching and moaning about this for years and the problem is DP's drivers. They don't work with ANY control surface and I've tried many. Don't expect it in 8 either. If I know MOTU they'll have us buy a box to fix the problem rather than rewriting software. We're in the MUSIC business not the graphic arts business!

I'm currently using V-Control Pro and a Tascam DM4800 as control surfaces for DP.
Very fun to use the iPad for remote mix moves and effect editing.
I think DP's drivers are O.K.
Working very well for me.

[JoeDeF]

I'm having good luck automating my plugins and VIs in DP 7.24.
So far, I haven't run in to a situation where I couldn't get the results I wanted.

That being said, I think I don't understand the question.

Hi Waterstrum,

I think that most of us here can automate VIs and can generally get the results that we want, but we are asking for a more powerful CC punch-in scheme (allowing CC-only punch-ins by moving a physical controller such as a fader, or a virtual controller using the mouse, etc.) in to help us to work faster and maybe better.

Basically, we would like MIDI CC's to work similarly to volume and pan automation in terms of punch-in behavior (overwrite, touch, latch, trim, etc).

When you have recorded automation for volume (for instance) using, say, a physical controller, you can play the sequence back, and, assuming that you have play and record enabled automation, you can grab the controller and either rewrite or scale the prior automation pass. The act of moving a fader while hearing the changes in context is fundamentally different (and possibly more musical) than drawing a shape while looking at a static representation of your data.

So, we like the way that DP handles volume and pan automation, and would like MIDI CC data to be handled in a similar fashion. For instance, assume that you have CC#11 (expression) controlling dynamics in a VI. You record a pass playing the notes and moving a fader to write CC#11. You are mostly happy with it, and you "nailed" all of the notes, but there are certain sections where you didn't really "nail" the expression data. Maybe in one section, you would like to replace the CC#11 data to reshape your musical line, but in other sections, the general shape is excellent but a little too intense. In the first section, you would like to be able to listen to the track, and when the moment comes, grab the fader and overwrite that section of CC#11 data only, leaving the rest of the data untouched. In the following sections, you would like to listen, and at the appropriate time, pull back the fader a bit in order to scale your last CC#11 pass. Currently, you can't do either of these two things.

Yes, there are work-arounds, and many of us are using them. With modern VI's, it is not uncommon to automate five or more parameters simultaneously, some of which interact with each other organically (SampleModeling instruments, for instance). A work-around which, say, involves five additional tracks for each VI is pretty cumbersome. And, while DP's controller editing tools are excellent and much appreciated (I personally have probably inserted at least hundreds of thousands of hand-drawn CC messages, and reshaped hundreds of thousands more), they do not allow you the real-time interaction that the more sophisticated VI's are now capable of responding to in a musically expressive way.

So, if one likes the way volume and pan automation data is handled, one would probably like to be able to handle MIDI CC data in a similar fashion. The moment you grab a controller, DP should begin to (depending on how you have set up your automation record mode) overwrite or trim that controller and only that controller. leaving the rest of the track intact. That's what I'm asking for.

A couple of posts implied that MOTU is behind the curve in this implementation.
That implies that other DAWs are doing it better.
Can you point to a DAW that has the feature you are seeking?
That would help MOTU help you.

I haven't used the latest incarnations of DP's competitors enough to know how other DAW's handle this issue.