I wish DP's controller data would operate like AfterEffects

[PrimeMover]

I'm a video producer/animator by day. My weapon, along with the millions of others who use it: Adobe AfterEffects.

The similarities between audio DAWs and video edit suites & compositing programs (such as After Effects) are endless. Hell, when I started, I knew nothing about video editing but was able to because it was so similar to my experiece with Pro Tools and Digital Performer. So, let's forget, for a second that one product works in the audio realm, and the other in the visual, because aside from that, the interface principals are practically identical.

After Effects has the best controller handling of any time-based editor on the market. Audio suites like Digital Performer or Logic could learn a hell of a lot from the sheer power and ease-of-use that keyframe editors (the equivalent of data controllers in DAWs) like After Effects use.

First and foremost, DAWs walk this precarious balance between raster-based data entry, and vector-based data entry. What I mean by that is: whether data is recorded moment-to-moment, or whether there are specific "keyframes" (for lack of a better word), and data is interpolated between these. If I were to choose DPs biggest problem, it's that, unlike Pro Tools and most other DAWs, it chooses to use moment-to-moment data points, and then fakes an interpolated line. This means that moving a data node often results in weird redrawings of interpolated data. We all have experienced this. For this reason, DP has probably the weakest data handling of any DAW that I've used. Sure, it might be slightly better suited to real-time data entry... but I'm starting to see real-time entry as a relic of the past: it's imprecise, slow, and complicated. I feel that modern day DAWs should cater first, and formost to vector-based data entry... but maybe that's just me.

But even DAWs in general are fairly weak in the controller realm to their video production counterparts. After Effects includes a full scripting language so that various data structures can effect one-another. It's made simpler by a series of shorcuts and linking tools.

Imagine if a DAW had a scripting language like that? For instance, tou could create complex side-chaining events right through the data structure. Have one script follow and interpolate the current amplitude of the track, and send it to the volume level on another track, without ever passing through a single, processor-intensive plugin. Attach a looping compand to a track's volume nob to create an instant ping-pong pan. This method just seems far more intuitive as a method of controlling track data than anything any DAW has presently presented.

What this all comes down to is that I feel like the audio world is more hung up on maintaining some kind of philosophy of design connection to vintage devices. Where-as the video & film production world (which are almost as old) are far more willing to streamline and make use of the things that modern computer user interface technology has to offer.

[Mr_Clifford]

If I were to choose DPs biggest problem, it's that, unlike Pro Tools and most other DAWs, it chooses to use moment-to-moment data points, and then fakes an interpolated line.

Firstly, are you talking about MIDI CC data or controllers like volume automation? DP behaves exactly the same as Pro Tools with both.

Sure, it might be slightly better suited to real-time data entry... but I'm starting to see real-time entry as a relic of the past: it's imprecise, slow, and complicated. I feel that modern day DAWs should cater first, and formost to vector-based data entry... but maybe that's just me.

Well, as someone that mixes with faders via a control surface, I totally disagree.

Imagine if a DAW had a scripting language like that? For instance, tou could create complex side-chaining events right through the data structure. Have one script follow and interpolate the current amplitude of the track, and send it to the volume level on another track, without ever passing through a single, processor-intensive plugin. Attach a looping compand to a track's volume nob to create an instant ping-pong pan. This method just seems far more intuitive as a method of controlling track data than anything any DAW has presently presented.

Sounds interesting, why don't you design a plug-in to do that. The architecture is all in place to do so.

What this all comes down to is that I feel like the audio world is more hung up on maintaining some kind of philosophy of design connection to vintage devices.

Yes, that's true, but for good reason for the most part.

[blue]

Imagine if a DAW had a scripting language like that? For instance, you could create complex side-chaining events right through the data structure. Have one script follow and interpolate the current amplitude of the track, and send it to the volume level on another track, without ever passing through a single, processor-intensive plugin. Attach a looping compand to a track's volume nob to create an instant ping-pong pan. This method just seems far more intuitive as a method of controlling track data than anything any DAW has presently presented.

This reminds me of a suggestion letter I sent to MOTU several months ago. Not exactly the same idea, but somewhat related. Here's the letter I wrote:

• I have an idea for a DP plugin.
  
  I am always modulating plugin parameters through various means, but often the process can be painful and limiting. Each plugin has its own method for time-based tweaking (host automation, MIDI, internal LFOS, etc.) but the time it takes to set some of this up can kill the buzz.
  
  What I would LOVE to see is a host-based plugin that acted like a global modulation source. It would have envelopes, sequencers, LFOs and other mod sources that could be assigned to any target AU or MAS plugin parameter though drag and drop. It could work much like FabFilter's mod scheme -- where you can click on a source and drag it to a target to connect -- but apply to outside plugins. Each mod source would have controls to affect polarity and the amount of modulation applied to each target. And, you could even allow input modulation, whereby you one plugin parameter could modulate a different plugin's parameter by way of the global mod plugin. Imagine the possibilities for tweaking, without the headaches!
  
  Something like this would be immensely useful and creative, especially for folks who do electronica based music. I'm no programmer, so I don't know what it would take to make this, but it seems doable as an extension of an already implemented host-based automation. What I do know is this: A plugin like this would be revolutionary in terms of how a host interacts with plugins, and how plugins interact with each other. It would set DP apart.

[PrimeMover]

Firstly, are you talking about MIDI CC data or controllers like volume automation? DP behaves exactly the same as Pro Tools with both.

Incorrect. DP behaves VERY differently with controller operations, both volume/pan and MIDI (not absolutely sure about the MIDI, since I mostly used PT for audio). Pro Tools controllers are 100% vector based, there is no individual point data. All of it is interpolated between nodes. If you drag a node, the rubberband line will simply shift accordingly. DP approximates a line from incidental data points. But if you drag a node, depending upon how you drag it, it may or may not rewrite all the incidental data points, so sometimes the line redraws itself to match that. It's VERY frusterating, and many times requires redrawing the line from scratch. The closest analogy I can think of is vector/rastor graphics in photoshop. If you draw a line with the brush tool in photoshop, the program has no way of knowing that it is, in fact, a "line" but is simply a bitmap drawing of pixels. However, drawing a vector line with the line tool is all math, and you can change the dimensions, rotation, etc of the line on the fly.

Pro Tools controller data is basically the equivelent of vector data, where-as DP is basically raster data. VERY different, and functionally very different.

What this all comes down to is that I feel like the audio world is more hung up on maintaining some kind of philosophy of design connection to vintage devices.

Yes, that's true, but for good reason for the most part.

How is being hung up on ANYTHING a good thing? If the process is illogical with modern interfaces, why keep it around? If I wanted to use hardware (which I don't) I would use hardware... not software that tries to act like hardware. This is why I'm so against "hardware-like" frontends to plugins, the look like childrens toys and they take up valuably screen realestate.

I use software to get away from clunky hardware interfaces. I'm cool with vintage analog synths and tube processors, those can do things that digital technology can't (as well). But interfaces are simply interfaces. I despise hardware sequencers, for instance, because they are simply computers with bad software, tiny screens, and clunky UIs. In doing live sound or basic multi-track recording, mixing boards are very usefull. But in post, they're really not. And software sliders are implossible to automate well without a decent HUI, and even then, I don't really see a huge advantage to out-of-time data editing.

[Mr. Quimper]

I have to agree with PM. As an ex Pro Tooler, I've always found going in and changing breakpoint values to be a complete pain in DP...it's got its own quirks that I've never been able to articulate as well as PM.

[blue]

If the process is illogical with modern interfaces, why keep it around? If I wanted to use hardware (which I don't) I would use hardware... not software that tries to act like hardware. This is why I'm so against "hardware-like" frontends to plugins, the look like childrens toys and they take up valuably screen realestate.

Ditto. The analog paradigm is a hindrance to DAW evolution in the long run. It's been nice that we've been able to somewhat replicate our hardware studios with much less money and space, but to get to the next level DAW makers will have to start thinking less linearly. For instance, I love the idea of object-based editing. Why is that not a staple yet? Soundtrack Pro has it, but I don't think most other audio software does.

[Mr_Clifford]

Incorrect. DP behaves VERY differently with controller operations, both volume/pan and MIDI (not absolutely sure about the MIDI, since I mostly used PT for audio). Pro Tools controllers are 100% vector based, there is no individual point data. All of it is interpolated between nodes. If you drag a node, the rubberband line will simply shift accordingly. DP approximates a line from incidental data points.

I'm sorry, but you might have to explain that one more. If I put in nodes on the volume automation (audio track) in DP, it draws lines between the nodes and automates accordingly, just the same as it does in Pro Tools. I'm struggling to see the difference. I agree that the editing tools in DP aren't quite as useful but the way it deals with the automation points seems the same.

MIDI controllers would have to be individual data points in both programs because that's how the MIDI schematics work - individual messages have to be sent (value between 0 & 127) for each change. That's why it's more accurate to automate the audio output of a VI rather than by sending CC#7 to it (but that's digressing...)

[PrimeMover]

Object-based editing? Not sure I know exactly what that refers to, but since I'm a fairly hierarchical thinker with a background in object oriented programming, as well as Max/MSP, I'd probably love it.

I forgot to mention, there is ONE thing that I think video/graphics programs could learn from DAWs... and that is signal routing. Video designers have never experienced the bliss of advanced signal routing. While objects can be nested and traded around, output is a fairly linear process. This means that applying the same plug-ing to a specific group of tracks a bit combersomb. You can get by this with nesting tracks, but if you could, say, have each track output to an Aux track, with a single plugin, it would be even nicer.

Currently, though, we have Adjustment Layers, which provide a lot of the same thing, but they effect ALL layers below them within the same sequence. So if you need to effect multipul groups of layers, you must nest sequences.

I'd really love to design a DAW someday.

[PrimeMover]

I'm sorry, but you might have to explain that one more. If I put in nodes on the volume automation (audio track) in DP, it draws lines between the nodes and automates accordingly, just the same as it does in Pro Tools. I'm struggling to see the difference. I agree that the editing tools in DP aren't quite as useful but the way it deals with the automation points seems the same.

For insance, if you have a volume fade, from 0db to -inf (two nodes) and then you insert one in the middle, you'll probably be fine dragging it vertically. However, if you then drag it to the side, DP many times thinks that you're just shifting that one point and all points after it, so that the right-side of the fade will be redrawn correctly, but the left-side will make a jag. It only seems to happen when you drag to the right, though. it's a problem in DPs ability to assimilate individual points into vectors.

MIDI controllers would have to be individual data points in both programs because that's how the MIDI schematics work - individual messages have to be sent (value between 0 & 127) for each change. That's why it's more accurate to automate the audio output of a VI rather than by sending CC#7 to it (but that's digressing...)

Not true. Yes, that is how MIDI works (I used to program MIDI sends and recieves manually with Max/MSP and C Sound for quite a few years). But that doesn't mean that the front end has to work that way. It's not just DP either. All sequencers are surprisingly stupid about MIDI data transfer. For one, none that I have seen go back and re-transmit the last data points for all controllers on all channels. That should be an absolute CINCH to program a sequencer to do... we're talking no more than 10ms or so to go back and resend that data. So previews from the middle of tracks are often incorrect because of missing data. You'd think they'd have given us the option to resend all MIDI data by now.

Secondly, simply because MIDI is sent by individual points, doesn't mean that a sequencer has to represent that data that way. Individual points are largely meaningless to users, unless we're talking CC64 and up (on/off togels). We're trying to program smooth curves, flat slopes, sine patterns for wah expression, things like that. It would be far more usefull to have a completely vector-based front-end and then have the sequencer send the appropriate data points on an as-needed basis behind the scenes. Obviously, a horizontal line doesn't need data to be resent at every sample, but during a slope, it will need to be resent. A simple option of how often to send a CC data change (in milliseconds) would be good enough. There are a few exceptions... for instance, a MIDI software package that lets you select guitar picking styles by sending a specific number to a certain controller... but those cases are few and far between... and for that, you should still be able make a sudden data change.

No, I don't see any reason why the front-end of a MIDI control program should have to actually tell you every single data point. We already largely try and bypass this, as is, with this half-assed psuedo-vector bullsh•• that DP uses.

[blue]

Object-based editing?

Sorry, I should explained better. "Object-based" might even be the wrong term, but essentially I'm referring to non-destructive layer-based editing ala Photoshop. You can apply edits and effects in layers, then turn those layers on and off or even rearrange them without creating new audio files. It's like pulling out the tablecloth without having to remove the dishes first.

[PrimeMover]

Sorry, I should explained better. "Object-based" might even be the wrong term, but essentially I'm referring to non-destructive layer-based editing ala Photoshop. You can apply edits and effects in layers, then turn those layers on and off or even rearrange them without creating new audio files. It's like pulling out the tablecloth without having to remove the dishes first.

So basically clip-by-clip non-destructive editing? Yeah, that would be nice. I'd, at the very least, like to see clip-based volume and pan envelopes. Many times, when you're smoothing out a vocal track, it would be nice to just have an individual volume envelope for that particular clip, instead of messing with the entire track's volume envelope. Should be able to apply plugins to clips too. However, that could lead to a lot of "bad habits" in audio editing, but I'd still be for it.

However, I'm kinda against "layered" audio editing. That's fine in Photoshop and After Effects where one object being on top of the other makes a difference. But in music, there's no such thing as one part of a an audio object obscuring the one behind it, in the same way. Therefor, there's no reason to portray an interface in Z-space instead of along the Y-axis... especially since screens are flat and depth is much more difficult to portray in an interface. I used to think it might be a cool idea, and there are some wave editors out there that use it: "Wave Editor" being one of them, Soundforge I think also does it these days (haven't used that program since 2001 though).

The new composite take-system in DP6 seems absolutely wonderful though, and seems to do a lot of these kinds of things. I haven't tried it out yet, but I can't wait.

[martian]

So basically clip-by-clip non-destructive editing? Yeah, that would be nice. I'd, at the very least, like to see clip-based volume


err thats called bite volume in DP 5...


i'd like to see bite volume expanded to clip based EQ - all those gawdam breakpoints p me off! ( also not a new idea - please see the avid audiovision and fairlight MFX series )

[blue]

However, I'm kinda against "layered" audio editing. That's fine in Photoshop and After Effects where one object being on top of the other makes a difference. But in music, there's no such thing as one part of a an audio object obscuring the one behind it, in the same way. Therefor, there's no reason to portray an interface in Z-space instead of along the Y-axis... especially since screens are flat and depth is much more difficult to portray in an interface. I used to think it might be a cool idea, and there are some wave editors out there that use it: "Wave Editor" being one of them, Soundforge I think also does it these days (haven't used that program since 2001 though).

I'm not talking about visual layers. I'm talking about process layers, where the order or processes absolutely has an effect on the output. Another benefit is non-linear undo capability. Waveform editing would be a prime candidate for this kind of approach, and probably the reason you see it more in dedicated audio editing apps.

[Mr_Clifford]

For insance, if you have a volume fade, from 0db to -inf (two nodes) and then you insert one in the middle, you'll probably be fine dragging it vertically. However, if you then drag it to the side, DP many times thinks that you're just shifting that one point and all points after it, so that the right-side of the fade will be redrawn correctly, but the left-side will make a jag. It only seems to happen when you drag to the right, though. it's a problem in DPs ability to assimilate individual points into vectors.

I just tried it with both audio volume automation and the bite volume, and it works perfectly - moving the middle point anywhere causes DP to redraw the lines exactly as you would expect.

All sequencers are surprisingly stupid about MIDI data transfer. For one, none that I have seen go back and re-transmit the last data points for all controllers on all channels. That should be an absolute CINCH to program a sequencer to do... we're talking no more than 10ms or so to go back and resend that data. So previews from the middle of tracks are often incorrect because of missing data. You'd think they'd have given us the option to resend all MIDI data by now.

Unless I'm totally misunderstanding you here, it's called event chasing and it's been around on MIDI sequencers as long as I can remember - right back to Cubase on the Atari. You have to set up how you want it to behave in the preferences though. DP's works perfectly for me - the main one that I use being CC#11 (Expression), but it chases pitch bend, modulation etc. just as well.

Secondly, simply because MIDI is sent by individual points, doesn't mean that a sequencer has to represent that data that way. Individual points are largely meaningless to users, unless we're talking CC64 and up (on/off togels). We're trying to program smooth curves, flat slopes, sine patterns for wah expression, things like that. It would be far more usefull to have a completely vector-based front-end and then have the sequencer send the appropriate data points on an as-needed basis behind the scenes. Obviously, a horizontal line doesn't need data to be resent at every sample, but during a slope, it will need to be resent. A simple option of how often to send a CC data change (in milliseconds) would be good enough. There are a few exceptions... for instance, a MIDI software package that lets you select guitar picking styles by sending a specific number to a certain controller... but those cases are few and far between... and for that, you should still be able make a sudden data change.

No, I don't see any reason why the front-end of a MIDI control program should have to actually tell you every single data point. We already largely try and bypass this, as is, with this half-assed psuedo-vector bullsh•• that DP uses.

Yes, that's true. I can see how a curve being represented as a vector rather than individual points would be easier to edit. DP's considerable tools at least make it one of the best sequencers to deal with editing the curves, sine curves etc. as they are at the moment represented in points.

In Cubase SX they introduced Vector based tempo manipulation - ie. you could draw a ramp for a perfectly smooth tempo slow down, problem was it took heaps more processing to calculate, it was mostly useless (as you only need the accuracy in a tempo change to be the same as your smallest note value) and when you went to export it as a MIDI file it literally crapped itself, because, of course, a MIDI file has to have all the data as distinct events. I don't know if they persevered with it in later versions.

[Shooshie]

I'm sorry, but you might have to explain that one more. If I put in nodes on the volume automation (audio track) in DP, it draws lines between the nodes and automates accordingly, just the same as it does in Pro Tools. I'm struggling to see the difference. I agree that the editing tools in DP aren't quite as useful but the way it deals with the automation points seems the same.

For insance, if you have a volume fade, from 0db to -inf (two nodes) and then you insert one in the middle, you'll probably be fine dragging it vertically. However, if you then drag it to the side, DP many times thinks that you're just shifting that one point and all points after it, so that the right-side of the fade will be redrawn correctly, but the left-side will make a jag. It only seems to happen when you drag to the right, though. it's a problem in DPs ability to assimilate individual points into vectors.

MIDI controllers would have to be individual data points in both programs because that's how the MIDI schematics work - individual messages have to be sent (value between 0 & 127) for each change. That's why it's more accurate to automate the audio output of a VI rather than by sending CC#7 to it (but that's digressing...)

Not true. Yes, that is how MIDI works (I used to program MIDI sends and recieves manually with Max/MSP and C Sound for quite a few years). But that doesn't mean that the front end has to work that way. It's not just DP either. All sequencers are surprisingly stupid about MIDI data transfer. For one, none that I have seen go back and re-transmit the last data points for all controllers on all channels. That should be an absolute CINCH to program a sequencer to do... we're talking no more than 10ms or so to go back and resend that data. So previews from the middle of tracks are often incorrect because of missing data. You'd think they'd have given us the option to resend all MIDI data by now.

Secondly, simply because MIDI is sent by individual points, doesn't mean that a sequencer has to represent that data that way. Individual points are largely meaningless to users, unless we're talking CC64 and up (on/off togels). We're trying to program smooth curves, flat slopes, sine patterns for wah expression, things like that. It would be far more usefull to have a completely vector-based front-end and then have the sequencer send the appropriate data points on an as-needed basis behind the scenes. Obviously, a horizontal line doesn't need data to be resent at every sample, but during a slope, it will need to be resent. A simple option of how often to send a CC data change (in milliseconds) would be good enough. There are a few exceptions... for instance, a MIDI software package that lets you select guitar picking styles by sending a specific number to a certain controller... but those cases are few and far between... and for that, you should still be able make a sudden data change.

No, I don't see any reason why the front-end of a MIDI control program should have to actually tell you every single data point. We already largely try and bypass this, as is, with this half-assed psuedo-vector bullsh•• that DP uses.

[edited]
Tell you what. Try the little tutorial about control points on page 2 of the DP Tips Sheet. That should get you started. You can set your ramp density for however many tics between points, right down to 1, though that's usually considered impractical for any DAW. Pseudo vectors? You realize it's MIDI, don't you? NO matter what you do, it's still dots. So DP's "line mode" is about as good as it gets, and that happens to be great.

You'll find "Event Chasing" in the index of the manual.

I'd go on, but let me sum up: if you're going to trash Digital Performer, you should learn it first. Otherwise, you just sound silly criticizing it for it's "lack" of features that have been standard for 20 years. This is one of the most advanced MIDI sequencers on the planet, and always has been.

Shooshie