. Automation: Object Based Automation (OBA)

  1. Object based automation (OBA): an overview
  2. Adjusting Hyperdraw delay causes audio to move as well
  3. Benefits of putting automation on a separate track (tip)

.1 Object based automation (OBA): an overview

Introductory note: the following describes so-called "Object Based Automation" (OBA) in which MIDI sequences are used to control automation. This is opposed to "Track Based Automation" (TBA): a kind of automation that no longer needs discrete objects on dedicated tracks, but allows you to draw and edit automation data on the tracks themselves directly. However, it was not until Logic 5.0 that TBA was introduced. The article you're currently reading was written in pre-v5 days, when OBA was all there was. That means that for Logic-5 users, being accustomed to TBA and/or being unaccustomed to OBA, the following is kind of outdated. Note however that OBA is still possible, even in the latest versions of Logic. Each has its strong and weak points, and some users definitely prefer one over the other. The pros and cons of OBA and TBA are not discussed here though. That should happen in another part of this FAQ.

  1. Before doing any automation we should perhaps have a look how audio automation is achieved in Logic: Automation is both recorded and played back on MIDI tracks. This has pros and cons, one con being the fact that there's no latency correction yet, one pro being the fact that automated data can a) easily be altered by various editors, b) could even be drawn onto a track using Hyperdraw.
    The way this MIDI data to audio automation thing happens: any Audio Object sends out MIDI data when you move faders, buttons, knobs, etc. This data is sent on a certain MIDI channel. By default Audio Objects 1-16 are set to MIDI Ch. 1-16: you can see and alter the channel in the Object's parameter box.
     
  2. Once you've recorded some fader movements on a MIDI track, you have to make sure the data will be sent back to the Audio Object once you hit 'play', using the appropriate MIDI channel and all. This is done by using a Channel Splitter object (which the so called A-Playback actually is). Assign the Arrange track with the recorded fader-movements sequence to this Channel Splitter, to ensure that the recorded automation plays back properly. Note that this Channel Splitter is (or should) be cabled to the Audio Objects that you want to be automated. By default outs 1-16 of A-Playback are cabled to Audio Objects 1-16.
    Note: instead of assigning the Arrange track to the A-Playback Channel Splitter, you could also assign the Track to e.g. the Audio-1 object directly. This is confusing though, since usually tracks assigned to Track Objects contain audio data and not MIDI data. Therefore using the A-Playback object is "cleaner". Another advantage of using A-Playback, is that it can serve 16 MIDI channels at once, so you could merge all automation for Audio-1 - Audio-16 into one track, assign that track to A-Playback, and have all 16 mixer channels playback automation as expected. No need for 16 different automation tracks.
     
    So far so good, everything should work well if you would only use the first 16 Audio Objects for any automation (assuming your A-Playback Channel Splitter is cabled correctly). Now lets assume you want to record automation using more then these first 16 Audio Objects.
     
  3. Just select one of your Bus Objects for instance and look what the Object's parameter pane says: most likely for Bus-1 you will see that it uses MIDI channel 1 again. Aha! Now suppose you recorded some automation for the Bus-1 object, and assigned the track with the automation data to the A-Playback object. What would happen is that the recorded data (on channel 1) gets sent out the Channel Splitter's "1" outlet -- which is cabled to the Audio-1 object. Your Bus automation would, upon playback, thus affect the Audio-1 object and not the Bus-1 object!
    There are basically two ways to avoid such problems:
     
    1. If you think 16 automated Audio Objects (be it plain Track Objects, Busses or Output Objects) are enough in any case, you could rewire the A-Playback Channel Splitter object to the appropriate objects in the Audio Mixer. For example: the Channel Splitter outs 1-10 could be cabled to Track Objects 1-10, outputs 11-14 could be cabled to Busses 1-4, and finally outputs 15-16 could be cabled to two Output Objects.
       
      Important note: You'd need to switch the MIDI channels of the Objects in order to accomplish this (e.g., in the above example Bus-1 should be set to MIDI channel 11 and so forth).
       
    2. If you need more than 16 automated objects or simply don't want to mess with recabling, just create a new Channel Splitter (from the Audio Mixer's New menu) and cable it to the desired objects. For example: Create a Channel Splitter, name it "Bus-Automation" and cable its outlets to the Bus Objects (output 1 to Bus-1, etc., for up to 16 Bus Objects). Again you need to watch out that the MIDI channels match. For recording you could now assign this "Bus-Automation" object to your Arrange track (note: you'd need to check the icon box of the Channel Splitter in order to have it displayed in your Arrange window's Instrument List) and record any Bus automation on that track. The disadvantage of this method is that you can't record both Audio-x objects and Bus-x automation in one go, so personally I prefer method No.1 -- again: as long as 16 objects is sufficient for your song.
       
  4. Finally there's one other thing you need to look out for: Logic is a bit limited w.r.t. the maximum number of plugin parameters that can be automated. It actually only allows you to automate the first 16 parameters of any plugin -- that is: if another plugin is inserted in the next insert slot.
     
    Example: Lets assume you have a FatEQ on Insert #1 of some Audio Object. Now lets further assume there's another plugin on Insert #2, say, a Flanger. The FatEQ offers 25 parameters: switch to "Controls" to see them all, count through them from the top to see which parameter equals which CC number (start counting at 64). The 25 parameters are "routed" to controller numbers 64-88. If you however insert the Flanger in slot #2, controller 80 and up are "stolen" by the Flanger. Now lets go a bit further and say you've recorded some automation of the FatEQ's parameter #17 (which is frequency for the high mid band). Due to Logic's limitation on the maximum number of controllable plugin parameters this will now be "rerouted" to parameter #1 of the Flanger (which happens to be the Flanger's Mix parameter) on playback -- surely not what you wanted. To avoid this you need to count through the parameters before doing any automation. If you find out that the number of the parameter you want to automate exceeds 16, don't insert a plugin in the slot which directly follows, but simply skip one slot -- or, if you already inserted a plugin, move it to the next slot via the Audio Configuration window. I.e. in this case just insert the Flanger in Insert #3, thus allowing the FatEQ to use 32 controllers for automation-- which is enough.
     
  5. Everything that applies to MIDI automation is true for audio as well. You might want to check out Hyperdraw for adjusting things. You further might try automating things just by using Hyperdraw sequences playing through the same Audio Object. That's what I personally prefer.

By now one should be able to do a more or less complete arrangement and mix, using both MIDI and audio automation. Roughly estimated time for the last mentioned points: Ages... It's just opening up possibilities upon possibilities.

[top] [contents]

 

.2 Adjusting Hyperdraw delay causes audio to move as well

Question: Hyperdraw latency : I'm using LAWP 4.1.1 and SBLive MME drivers which have a latency of 297 ms. Logic accommodates this latency when playing back audio so that it is in sync with the midi. The problem is that Hyperdraw messages don't appear to get sent 297 ms early to compensate. They appear to get sent at the exact time as if there was no latency in the audio. I attempted to alter the delay to -297 to compensate but this brought the audio forward as well.

Answer: I think you mean to say that a negative delay of -297 brought the audio BACKWARD (ie... back in time, or earlier in time) as well.

Workaround #1: Don't do your automation on top of the audio regions. Instead, do them in independent "MIDI-only" regions that will affect the audio (i.e. the "Object Base Automation" A-Playback Track). Then negative delay these "MIDI" regions.

Workaround #2: Don't set a global negative delay for this particular audio driver, but rather for each audio region. Then, the automation and the automation data will be put back in time (negative delayed) by the same amount.

There is another aspect of latency that you cannot compensate for: SLEW. This is where the automation data can't be read fast enough by the specific audio hardware. In other words, fast *changes* will smooth over and won't be recognized exactly. Not all hardware is created equal, so automation latency/slew are different always.

[top] [contents]

.3 Benefits of putting automation on a separate track (tip)

Note: This only applies to old-style Object Based Automation (OBA).

Create a new track using the same Audio Object, then create a new sequence on that track, switch Hyperdraw on and automate on that sequence. The advantages are:

If you find yourself ending up with too many tracks, simply put them in a folder.

[top] [contents]