NAMM NEWS - DP 10 - It's Here!

[FMiguelez]

Where can we go to discuss what DP 10 is (i.e. not what we imagined it would/could be) if people are going to fill every thread with their favorite old diatribes?

Given that it hasn't been released, we can't know what DP is, so it's just all speculation based on some related videos.

If that's what you want to talk about, feel free to do so, but don't tell me or anyone else what aspects of DP we can and we can't talk about in a DP thread, capisce?

DP 10 doesn't fix this, that's unfortunate. It doesn't include articulation support, that's also unfortunate. But that doesn't mean it's ok to start spewing multiple page-long messages in this thread about why it should. Lots of us are keen to discover what DP10 does, anything people might have seen at the show, release info etc. And post release, how people are getting on with it. There's a troubleshooting/criticism section for a reason, I presume.

It's also unfortunate you don't like this thread.
You can look for the DP10 videos that are out there and you can try checking out MOTU.com.

Unless James says so, you don't get to dictate what we talk and not talk about in a DP news/speculation thread

[richhickey]

It's also unfortunate you don't like this thread.
You can look for the DP10 videos that are out there and you can try checking out MOTU.com.

Unless James says so, you don't get to dictate what we talk and not talk about in a DP news/speculation thread

I'm not dictating - I'm stating an opinion, as we all are. And asking for that moderation, I guess.

[stubbsonic]

Sounds like FMiguelez wants to tell someone "what they can and can't talk about in a DP thread."

This isn't about censorship, it's just about organizing a topic and keeping threads manageable/readable.

I think RichHickey makes a totally fair point. Just as we moved the worthwhile discussion of MPE and MIDI 2.0 to another thread, I think the automation topic is TOTALLY VALID and WORTHWHILE, but it is a bit off-topic in the sense that this particular feature may not have been addressed or fixed or changed in the current version.

It makes sense to bump the other threads that discuss a particular criticism with the added info "DP 10 doesn't appear to address this".

We all understand how frustrating this automation thing is. We've read about it in detail. We agree that it should be addressed. But they didn't address it.

It would be great to see any reports of things that ARE fixed with this version. And I think it is fine to mention things that aren't fixed-- and perhaps link to external conversations about those topics.

But there is quite a bit of volume on this topic, here and elsewhere in the forum.

Were we wrong to move the conversation about MPE into another thread? Should we have dug in and added those 3 or 4 additional posts here? Kinda doesn't matter much, but I didn't mind moving it.

[FMiguelez]

...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 VI and synth work 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.
... [SNIP]
One way to "resolve" this ambiguity is to automatically create MIDI 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/MIDI windows, 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.

It sounds very reasonable to me, jloeb.

Unfortunately, the very words "MIDI Regions" will resonate badly here. Some members will offer you to the gods as a sacrifice for such heresy...

Personally, ASA MOTU doesn't break anything else, I'm all for those kind of improvements. Also, unless I'm totally mistaken, I INSIST that MOTU could fix the whole automation situation with the algorithm I've been peddling for a while... I think that might meet less resistance from other long-time users, since that wouldn't change things under-the-hood too much for their comfort zone.

But I think you're definitely on to something, jloeb, and I'd encourage you to send your suggestions to MOTU and keep talking about them here. They won't do anything until they feel they have a big enough base who wants x or y.

[Michael Canavan]

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.

Look, there are hundreds of things we want DP to do/fix, discussed at length in prior threads (as this has). Should all of those threads be regurgitated here? Where can we go to discuss what DP 10 is (i.e. not what we imagined it would/could be) if people are going to fill every thread with their favorite old diatribes?

DP 10 doesn't fix this, that's unfortunate. It doesn't include articulation support, that's also unfortunate. But that doesn't mean it's ok to start spewing multiple page-long messages in this thread about why it should. Lots of us are keen to discover what DP10 does, anything people might have seen at the show, release info etc. And post release, how people are getting on with it. There's a troubleshooting/criticism section for a reason, I presume.

Have to agree that this is is a subject that should be discussed here. Articulation support is a kind of bad comparison, since that's a new feature that people want like MPE, it's still relevant, but it's not in the same category. Track automation behaves differently in DP than any other DAW, and it's not a good thing in most cases. There's a reason other DAWs do it differently.

After spending a lot of time messing around with this last night, I completely get what Toodammedhip and FMiguelez are on about. TDH mentioned it's not the same with MIDI automation, and in my experience that's true, MIDI automation doesn't ramp really. Track automation, which is never attached to MIDI data in DP is what ramps all over the place in DP when moved, copied etc.

Firing up Logic I see that Logic has two distinct (from what I can tell with the time I spent on it anyway), behaviors with track automation. It ties Track automation to the MIDI and ramps up or down 90º at the point of new automation data, but if you copy and paste or option drag automation outside of the object, it ramps like DP does.

Ableton Live does somewhat of what I think TDH and FM would be happy with, it ramps at 90º regardless of it being attached to the MIDI or not, so in DP's case where track automation is never attached to MIDI it would work. The caveat in Live seems to be it can't be option dragged to copy it though? It has to be copy pasted...

The behavior as it stands is mostly good for doing creative things with snapshot automation and ramping, but it's a nightmare of time suck, especially if automation goes in opposite directions, ramping wise in many cases. I haven't figured out what the method is that DP uses to determine which automation state is going to be given priority when you take a snapshot by selection? I'm betting there's logic to it, just didn't see it last night.

One behavior of track automation that's IMO almost completely useless is that it does not overwrite automation data that's already in an area that you drag new automation data to. So old breakpoints that are not exactly where new breakpoints are do not get overwritten. I cannot think of a single time when this would be the wanted behavior?

I have to say this is one of those WTF things. and hopefully it gets addressed at some point. In the mean time I'm thinking about sticking with MIDI automation as much as I possibly can, just to avoid 90% of the hassle. Using track automation for only the final mix and not as a way to automate parameters in a mix during composition is a big let down though. I've been avoiding track automation during the composition phase anyway, mostly so I could use chunks with impunity hosting VSTi's in a V-Racks.

[FMiguelez]

It would be great to see any reports of things that ARE fixed with this version. And I think it is fine to mention things that aren't fixed-- and perhaps link to external conversations about those topics.

Ok. I can do that...

Other things that have been broken for ever and I hope to see fixed in DP10 are:

-- Set Sequence Tempo from MIDI command. It's never worked as advertised.

-- The Dither command under the Audio menu is broken (it gives NO dither for merged 24 bit files. So it only truncates them). I checked all this with null tests.

-- Quan Jr. and MW Limiter are broken too. No dither gets sent out when either is set to quantize to 24 bits. And the other settings are unreliable (the volume of dither sometimes modulates!) So if you've been mastering using any of that for dither, well... you haven't.

-- Waves L2 (and I'm almost sure the whole Lx family) dither Type 2 does not work with DP. Try out and see what kind of "dither" it gives you and how often it actually pulls it out. So you've been truncating all along instead of dithering to 24 bits!

-- The Trim plugin, and DP's engine (summing via buses), it seems, sum to mono incorrectly (Trim will not null out with any other "mono-ing" commercial plugin, not even with DP's own Spatial Maximizer --which interestingly enough, does null out completely with all other tested 3rd-party plugins--). So our mono mixes do sound different than if done in any other DAW (not saying better or worse, but there is an important difference in level in the mono signal, by definition. What actually happens to that "extra or missing signal" is anyone's guess).

You NEVER get total cancellation when summing to mono, only partial nulling.

AFAIK, I'm the only one who has mentioned those issues in this forum (so no external links), but I hope MOTU was aware of those issues and corrected them (I remember making tech-tickets, long ago, when I discovered them). If MOTU not mentioning it is an indication, then it seems none of that was fixed. But we'll see soon enough. I will test those points to know the answer for sure when it comes out.

It may be argued that none of that is a big deal either, but... really?

[MIDI Life Crisis]

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.

Look, there are hundreds of things we want DP to do/fix, discussed at length in prior threads (as this has). Should all of those threads be regurgitated here? Where can we go to discuss what DP 10 is (i.e. not what we imagined it would/could be) if people are going to fill every thread with their favorite old diatribes?

DP 10 doesn't fix this, that's unfortunate. It doesn't include articulation support, that's also unfortunate. But that doesn't mean it's ok to start spewing multiple page-long messages in this thread about why it should. Lots of us are keen to discover what DP10 does, anything people might have seen at the show, release info etc. And post release, how people are getting on with it. There's a troubleshooting/criticism section for a reason, I presume.

I totally agree, Richhicky. This thread is a perfect example. Rather than discuss new items (none of which are in the hands of anyone but the beta testers and MMOTU, AFAIK, the thread has devolved into a rant about stuff that has already been posted and reported to MOTU. So why is it here again?

If I were a trained psychologist, I might take a stab at that but don't really have a desire to delve deep into the mind of ANYONE posting on the internet. lol

In fact, the forum was designed to make posting organized and intelligently searchable. By hijacking a simple thread, instead of starting a new discussion with an appropriate title, all the posting folks are doing is making noise and detracting from both the discussion at hand and the organizational hierarchy that James has thoughtfully set up for us.

Ironically, hijacking a thread with unrelated information reduces your chances of getting a solution (if one exists) from a member who might have the answer for you. If I had the solution (for example) to the copy paste so called "bug" and was browsing the forum, I wouldn't necessarily look at this thread at all. IOW, the very people you want to read your post may never see it because it's buried deep into 10 pages of irrelevant posts.

Additionally, someone thinking about buying DP will see "NAMM NEWS - DP 10 - It's Here!" and read this thread, and likely decide to NOT buy DP.

Very productive, guys. Very productive.

What's a member to do? Let me answer that...

• Post to relevant topics with reasonably relevant comments.
• When you create a new discussion, create a title that reflects the major issues you are dealing with.
• Post to the proper section of the forum.

Is it that hard to follow three simple rules?

Thanks again, Rich. In the old days, James might lock a thread that got out of control. It may be time for that here.

[Michael Canavan]

I totally agree, Richhicky. This thread is a perfect example. Rather than discuss new items (none of which are in the hands of anyone but the beta testers and MMOTU, AFAIK, the thread has devolved into a rant about stuff that has already been posted and reported to MOTU. So why is it here again?

If I were a trained psychologist, I might take a stab at that but don't really have a desire to delve deep into the mind of ANYONE posting on the internet. lol

In fact, the forum was designed to make posting organized and intelligently searchable. By hijacking a simple thread, instead of starting a new discussion with an appropriate title, all the posting folks are doing is making noise and detracting from both the discussion at hand and the organizational hierarchy that James has thoughtfully set up for us.

Ironically, hijacking a thread with unrelated information reduces your chances of getting a solution (if one exists) from a member who might have the answer for you. If I had the solution (for example) to the copy paste so called "bug" and was browsing the forum, I wouldn't necessarily look at this thread at all. IOW, the very people you want to read your post may never see it because it's buried deep into 10 pages of irrelevant posts.

Additionally, someone thinking about buying DP will see "NAMM NEWS - DP 10 - It's Here!" and read this thread, and likely decide to NOT buy DP.

Very productive, guys. Very productive.

What's a member to do? Let me answer that...

• Post to relevant topics with reasonably relevant comments.
• When you create a new discussion, create a title that reflects the major issues you are dealing with.
• Post to the proper section of the forum.

Is it that hard to follow three simple rules?

Thanks again, Rich. In the old days, James might lock a thread that got out of control. It may be time for that here.

I am not trying to argue here, but I have never understood exactly what FM and TDH were on about until this thread had me interested enough to try it out, and to try it out with other DAWs to compare etc. They have a new "convert" someone who like you, never really worked like that, who now would like to see this behavior changed.

So it being pointless to talk about, well that's not true. I mostly work with Chunks and V-Racks, so track automation isn't something I use like TDH and FM do, but this is a huge issue for a very legitimate way of working, and it's relevant to address it in terms of hoping it's in a future update, which we found out it's not, in this thread. I miss working with track automation, it's in many ways easier to deal with than MIDI automation for doing creative mixing tricks, and sound FX, so knowing that ramping is an issue, that automation in DP must be cleared or it will 'merge' is an issue.

It think the problem with TDH,FM's issue is the lack of understanding of how it can affect your workflow. When someone decries the lack of XML support improvements in DP10 even those of us who don't use it understand that an import/export function is missing and acknowledge the persons request or observation. Me and Bayswater thought there was some sort of issue out of a behavior that one didn't like, VS something that is not really predictable which is what we have now. So you get these big conversations about it, not because it's some personal agenda, but because at least three of us mentioned it not being an issue for us...

I think it's good to not be too judgmental, that's all.

[jloeb]

I understand the urge to keep this topical. That's entirely valid.

I think the key point, though, is that DP10 is not yet a released product. Once it is, then I'd agree that it's time to move on and table this discussion to "unaddressed issues." But for now, some of us are attempting to focus discussion on what we believe to be a core feature that we'd like addressed, if possible, in a near-future version of the app. I've tried to provide a simple and straightforward feature suggestion, one that doesn't get into the guts of the code in any major way and that, if implemented, wouldn't change anyone's workflow who didn't invoke it.

For that very same reason, I think it might make sense to change the title of the thread, which is inaccurate. DP10 is not "here;" it has merely been announced.

There has also been pretty exhaustive discussion of and speculation on what new features we do have information about, with links to the available info. Most of what I know about DP10 I learned in this thread. There's room for both.

[jloeb]

Unfortunately, the very words "MIDI Regions" will resonate badly here. Some members will offer you to the gods as a sacrifice for such heresy...

I agree about MIDI regions; I think they're an abysmal idea ("Hey, let's put training wheels on this Ducati!")

[MIDI Life Crisis]

I am not trying to argue here, but I have never understood exactly what FM and TDH were on about until this thread had me interested enough to try it out, and to try it out..

Similarly, I also found myself enmeshed n the alleged bug and also tried it out (I only have DP). When copy and paste totally worked "as expected" for me I was basically told: No, you have to have LOTS of control data and other info in there to see it.

That's where I stopped caring and why "most people don't give a fiddler's fart about that particular issue. Should DP be able to do that? I suppose so. Is it a priority for the vast number of users making music and sound in the app? Clearly not.

Well, that's my perspective on it, at any rate. BTW, I don't mind people being argumentative, not one bit. I get pretty passionate about some stuff, but this particular 'bug' is seeping into several discussions now. I'm beginning to wonder if the PT folks aren't infiltrating our blessed forum to escalate the issue even further. j/k!!!!!

All I can say is if it's THAT important to you and another app does what you need done better than DP, than just 'effing use the other app. And I guess I am being somewhat argumentative there if anyone cares to take it that way. That's ok. I'm doing score after score in DP and have for decades and it does everything I need it to do. If it didn't, I wouldn't be here. Capisco?

[jloeb]

All I can say is if it's THAT important to you and another app does what you need done better than DP, than just 'effing use the other app. And I guess I am being somewhat argumentative there if anyone cares to take it that way. That's ok. I'm doing score after score in DP and have for decades and it does everything I need it to do. If it didn't, I wouldn't be here. Capisco?

(Wouldn't that be "Capisce?" Just being argumentative, paisano. )

But I don't want to use any effing other app. I want DP to, as it were, win, and to continue to win. Consonant with MOTU's development direction, when those LoopKids show up, I want them to have a way to make things just-object-like-enough that they keep coming back.

As a major mod-wiggler, let me confess: yes, I took a long look at Live Suite (mea culpa, mea culpa, mea maxima culpa). But man that ish is *expensive,* and not in a good way; in a Trendy Bloatware way. I'm not paying that, for that. DP can do this. It's solely a question of will. And of perceived user desire.

[MIDI Life Crisis]

(Wouldn't that be "Capisce?" Just being argumentative, paisano.

Do the Google, baby!

[jloeb]

Do the Google, baby!

Not me, man. Italian family from Trenton. I had a Teamsters answering machine. You kiddin me?


(P.S. Is this off-topic?)

[Michael Canavan]

I am not trying to argue here, but I have never understood exactly what FM and TDH were on about until this thread had me interested enough to try it out, and to try it out..

Similarly, I also found myself enmeshed n the alleged bug and also tried it out (I only have DP). When copy and paste totally worked "as expected" for me I was basically told: No, you have to have LOTS of control data and other info in there to see it.

That's where I stopped caring and why "most people don't give a fiddler's fart about that particular issue. Should DP be able to do that? I suppose so. Is it a priority for the vast number of users making music and sound in the app? Clearly not.

Well, that's my perspective on it, at any rate. BTW, I don't mind people being argumentative, not one bit. I get pretty passionate about some stuff, but this particular 'bug' is seeping into several discussions now. I'm beginning to wonder if the PT folks aren't infiltrating our blessed forum to escalate the issue even further. j/k!!!!!

All I can say is if it's THAT important to you and another app does what you need done better than DP, than just 'effing use the other app. And I guess I am being somewhat argumentative there if anyone cares to take it that way. That's ok. I'm doing score after score in DP and have for decades and it does everything I need it to do. If it didn't, I wouldn't be here. Capisco?

I think you're running into the issue I did when I first looked at what they're talking about, MIDI CC data doesn't really need to continue or tie in on itself like track automation does. It sounds like you tried it with MIDI CC data.

Track automation always keeps lines of automation going to it's next point, whereas MIDI automation data can exits without being connected together, or creating the ramps TDC and FM are on about. You're a hands on player for the most part from what I can tell, so MIDI automation is going to be what you use, and copy pasting data is going to seem like a waste of time compared to just playing the part again.

If you were in a recording studio though, where you might be asked to add automation that's the same to two different parts of Mindy's Next Hit™, then the guitar volume ramping like TDC mentioned earlier would be a real problem.

I think it's a relevant request, and something I intend to write out a detailed request to MOTU about. I think also it's really a bad call on interested parties not to have shown some .jpgs at the very least showing how this behaves and why this is an issue.

Personally my solution is to stick to MIDI automation for now, and Live etc. if I really really need track automation moved around etc. but I would like to see it changed, it's only purpose now is for sound design, no other reason for it to behave like it does.