richhickey wrote:dix wrote:toodamnhip wrote:The automation ramping STILL EXISTS in DP 10. At least the versions at Namm. I tested DP 10 at NAMM...the ramping has not been fixed. I have filed reports and had great assistance with reports from our great guru Matt La Point, so I am sure they finally know about the issue. But whether they have time to fix such a thing before the first release? I am skeptical, but hopeful. gain, the issue remains in the DP 10s they had at NAMM.
There you have it. Since it’s not actually part of DP10, I’m thinking the issue could use it’s own thread m’be....?
Yes, please
No, this makes no sense to me at all. This is a discussion of an as-yet-unreleased version of DP, and it's exactly the type of topic that should be discussed here ("in house") at this time and in this thread.
FMiguelez/TooDamnHip/OldTimey's point about automation editing is correct. It affects multiple genres of music production, if not every style of production: those whose music consists of live instrument takes plus a naturalistic style of arrangement will care less; those heavily into automation care a lot (and that is a lot of people, including myself). I've been turning this thread and last year's thread on this topic over in my head to try to come up with a short, sensible heuristic for dealing with the automation issue that covers all bases and can be suggested to MOTU devs.
On the surface, the fix seems obvious ("make it behave like audio!") and the appearance of ramps after edits "nonsensical," but that's not exactly true.
CC automation comprises two phases of activity: building and editing.
1) Building: recording automation during or as an overdub to a performance. Drawing in or dragging automation points with the mouse. Hand-editing by adding or subtracting one or more points from within an existing passage of automation.
If these are the activities you are engaged in, then changing the automation data should result in a smooth transition of the automation state between the edited points: interpolation. Where CC data consists of interpolated breakpoints, what you should expect to get when you remove or change a point is interpolation between the current and previous breakpoint values. In other words: a ramp.
This is DP's current behavior. It is the most logical behavior when you are starting from scratch and want to quickly build a set of contours for the track; or when you want to hand-alter data breakpoint by breakpoint.
2) Editing: Cutting/pasting// copy/splicing, or generally performing removal or relocation of regions of automation data which overlay existing data or audio in a track.
Now your expectations are different, because of the association of the automation data with that underlying track content. It can be assumed that edits should prioritize current value state above all else: when you remove a region, for example, what remains at the excision point should be a hard square-wave disjunct between the values at the beginning of the edited region and those at its end. If you splice a region into another region, there should likewise be a hard disjunct between the values within the splice and those bracketing it.
This is so because, to make musical sense, automation events should retain essentially sample-accurate association with the data which they overlay. The results of edits should imitate, as much as possible, the results of editing already-printed audio files.
The tricky part, and a possible answer: These are not mutually exclusive types of activities, and it is likely that a user would want to switch back and forth from one type of behavior to the other many times during the course of a project.
One way to "resolve" this ambiguity is to automatically create regions. I think MIDI regions are counterintuitive, create inflexibility, and build fences where the user has not erected them. This is not the DP design philosophy.
I think the solution that preserves flexibility for the user's working style (the DP way overall), and that is relatively simple to implement, possibly within the timeframe of the several weeks between now and release, is a feature that puts the choice between these behaviors in the user's hands. It consists of:
1) A checkbox, dropdown or otherwise a UI toggle, in the control bar or in the sequence window, which allows selection of an automation edit mode consisting of one of: Building or Editing.
2)
Building Mode preserves DP's current behavior, as-is.
3)
Editing Mode changes the behavior simply by spawning breakpoints for all active automation channels immediately (e.g., one tick) before and after the bounds of a selected region when any copy, delete, drag or paste operation is invoked for that region.
I think that's enough to do the trick, and result in the desired behaviors for any given situation, subject to the user's judgment. It's actionable by the devs, it adds flexibility, and it doesn't mess up anyone's current workflow.
FMiguelez et al, does this seem reasonable to you? If so, pending your input I'll send it as a support message to MOTU and I suggest you do the same.
