DP 9 and 10 Cannot read heavy automation well, Proven!

[MIDI Life Crisis]

Instead of "proving" that something doesn't work the way you want it to, wouldn't it be more efficient to figure out how best to get where you want to go?

Sage advice! I've been in this business for over 43 years now and the one thing that remains constant is that there are always going to be obstacles. The name of the game is problem solving. Often that means changing your prescription. If massive automation isn't working, maybe that's a bad idea? Finding another path is what CREATIVITY is all about. Or one can just...

Frankly, I find it extremely hard to even imagine what the heck is being automated so intensely to create this problem. My guess is that doing so is actually very unmusical. How does that even apply to the most complex music ever created for actual instruments? Seriously, specifically what needs to be automated to that degree?

Again, either change your Rx or try another DAW.

All proofs rest on premises.

~Aristotle

[toodamnhip]

Instead of "proving" that something doesn't work the way you want it to, wouldn't it be more efficient to figure out how best to get where you want to go?

Sage advice! I've been in this business for over 43 years now and the one thing that remains constant is that there are always going to be obstacles. The name of the game is problem solving. Often that means changing your prescription. If massive automation isn't working, maybe that's a bad idea? Finding another path is what CREATIVITY is all about. Or one can just...

Frankly, I find it extremely hard to even imagine what the heck is being automated so intensely to create this problem. My guess is that doing so is actually very unmusical. How does that even apply to the most complex music ever created for actual instruments? Seriously, specifically what needs to be automated to that degree?

Again, either change your Rx or try another DAW.

All proofs rest on premises.

~Aristotle

And again a member fails to just say” Looks like DP May have gone backwards from 8 to 9 stranding those who automate heavily”. instead, You’d rather impune my work? Elude to it being unmusical? Do I need to post a Grammy resume? Yikes. Ok man, I suck, you’re right, DP the inanimate object that it is, is more perfect than the human producer reporting it’s shortcomings. Happy?
listen brotha, The day I change how I mix due to the technical limitations of ANY DAW is the day I truly become mediocre.

[MIDI Life Crisis]

From page 610 of the DP 10 manual... just sayin' You were warned.

THIN CONTINUOUS DATA
MIDI instruments tend to send continuous data as fast as they possibly can. If you record several
tracks of this and play them all back at once, Digital Performer, your instruments, or MIDI itself may
bog down. The Thin Continuous Data command selectively removes continuous data events,
“thinning out” the amount of continuous data while retaining all of its essential characteristics.
This allows you to transmit a reasonable amount of continuous data that can be handled easily by all
components of your MIDI system.

[FMiguelez]

From page 610 of the DP 10 manual... just sayin' You were warned.

THIN CONTINUOUS DATA
MIDI instruments tend to send continuous data as fast as they possibly can. If you record several
tracks of this and play them all back at once, Digital Performer, your instruments, or MIDI itself may
bog down. The Thin Continuous Data command selectively removes continuous data events,
“thinning out” the amount of continuous data while retaining all of its essential characteristics.
This allows you to transmit a reasonable amount of continuous data that can be handled easily by all
components of your MIDI system.

That's a good point, Mike.

I suggested its cousin, tweaking the Ramp Automation Density (?) preference upthread.

However, that only applies to ramps, as in how much information is used to describe them. So our suggestions don't apply to snapshots, which are a good part of TDH's workflow (or at least mine), since those typically only use 2 point values per parameter (you can program ramps like that too, but those don't work too well either, IIRC).
The problem seems to be not the density but the amount of plugin parameters and mixer-related automation.

I also gave upthread a decent explanation of why this "brute force" automation workflow is very nice and effective to use in very specific (but typical) scenarios (i.e., creating quick static "skeletons", via snapshots, when you want to mix different sections of a song in contrasting ways. Afterwards, form these static skeletons, you can animate them and create movement with ramps, etc.).
It's also a great workflow for mastering many tracks in a chunk timeline. Just make your tracks sound the way you like by tweaking whatever you want to your heart´s content, make the selection and take a snapshot. Repeat and rinse for the rest of the tracks. Rápido y efectivo!
The workflow really works in these contexts. Try it and see for yourself. Nothing to lose experimenting with this.

Yes, this creates a lot of "wasted" parameters that get automation values at cero or default, but it's a great trade-off for speed and it helps let the creative flow flow faster.
Deleting unused automation parameters, as has been suggested before, doesn't work for the reasons that you hate about music making>
... Wasting time and effort treating DP as if it were some database/spreadsheet program.

It obviously doesn't work for all contexts/scenarios, but for stuff similar to what I've mentioned, I doubt there is something faster or more effective.

[James Steele]

I take no solace in coming her to bitch. I am busy. It takes time to write these posts and argue with people who think its all MY fault, or that I am doing something "wrong". Why would I do this? For kicks? lol. Just trying to be a conscientious member and let this forum know the new data----I made NEW system verifying everything that happened on the prior systems. It's exactly as my original post stated....and, Its DP...must face! lol

Yeah... all I know as owner of this forum, your posts pretty much make me hate coming here.

[James Steele]

I don’t agree with James characterization of “brute force”, it’s a negative set of words that seems like a bit of a copout, always siding with DP. I don’t know why James or others can’t just say, “yes, DP is broken or has gone backwards in this area”.

I'm not asking you to agree with me, man. And correct me if I'm wrong, but I was under the impression that when you take your frequent snapshots, you do it across ALL tracks, and every parameter whether it changes or not, and I thought you also snapshot every parameter of every one of your plug-ins as well. I mean, the fact of the matter is that you may be working in a manner that creates an unusually large amount of dense automation data. It maybe that MOTU engineers did not anticipate this otherwise why give us a choice of which parameters to automate and which to allow to be static? No doubt it was for *efficiency* reasons. Maybe they didn't anticipate people automating parameters that never change? But last time I checked, this forum is not exactly overflowing with posts complaining about the issue that you have been harping on literally for YEARS here. That lends even more credence to the possibility that not many DP users work in the manner you do.

Maybe what you might want to do is send a project to MOTU... one that brings DP 10 to its knees and let them see it for themselves. In the meantime, you gotta do what you gotta do to get your work done, and yeah... I really have come to dread seeing your posts on this forum I started. Just being honest. You're not bashful about expressing your opinion around here... I don't think I should be either.

Hopefully MOTU can solve this someday before I finally throw up my hands and create a permanent topic for you to post away in. I can call it "DP Heavy Automation Issues" and rather than create new posts over and over, you can simply update that particular topic from time to time.

[James Steele]

Hey guys, thanks for the offers to test, but testing without the full gamut of plug ins I use would be of little value.

Right. Does that mean you are indeed snapshot automating every single parameter of every single plug in in your project even if those parameters actually never change throughout the entire sequence?

[toodamnhip]

Hey guys, thanks for the offers to test, but testing without the full gamut of plug ins I use would be of little value.

Right. Does that mean you are indeed snapshot automating every single parameter of every single plug in in your project even if those parameters actually never change throughout the entire sequence?

No it doesn’t. And every time I read your responses, it feels to me that you are not taking into account the fact that it worked in 8.07. Debating whether I work right isn’t the point. The point was DP became LESS able to handle large amounts of automation. That was what I was reporting. All this other mumbojumbo about my work habits bro? Why? I am showing all of us DP doesn’t handle automation as well in its later versions. Do you NOT want to know that? It’s informative.
1) However I work, It all worked when I made the damn songs
2) It doesn’t after 8.07. Same session file, nothing changed, works in 8.07, fails miserably in nine and above. ( importing session into a clean 9 or 10 file doesn’t solve the issue either )
3) Tests through various systems and clean installs rule out it is my particular system.
4) I reported it as a lessening of automation capability...ts DATA man.

Don’t hate me or my posts. Question WHAT is REstimulating in everybody’s mind. I think I’m stirring up memories of Gearslutz trolls that come here just a bitch and moan for the purpose of bitching and moaning or getting personal, throwing shade on people etc.
I have data. It’s real. Accept it for what it is. You now know MORE about DP than you did before now as the extra data is all the new comps and clean installs rule out my particular system.. . There’s been a gamut of tests by a member presented . I tried to write it out logically. Hope it made some sort of sense. Not just trying to throw shade on DP land.

PS.
I have sent MOTU yet another offer of a session file.
Their servers can’t accept a large file so I await advise on how they want it sent. I sent them one a couple years back too.
By the way, lest you think I “harp too much”, I showed a very prominent person at MOTU The ramping issue just last year, and they were amazed to see it. They did not know about it. I demonstrated it in person. I cannot believe that high up staff aren’t aware of this issue, that pasting a mix screws up a mix, it absolutely blows my mind. So as many times as I might’ve come here to where you’re sick of it, still MOTU hadn’t really
known about it. I write that in response to people who might say don’t go through proper channels to get issues taken care of.
Ps Ps
My tests also show that the log jam is in the programming of DP. And my very experienced technician tells me that software can be inefficient while a computer has plenty of headroom remaining. That is my situation. I have plenty of comp head room remaining, I am guessing that DP chokes due to its own code, or the way it interacts with 3rd party code. But it didn’t in 8.07. It did a bit graphically, but not playback.
Now, just to rule out some things about third-party software. It was not an update of a third party software that slow things down in DP9.
Whatever version of all the software I have, it all works in 8.07.
Logically, if it was third-party software that screwed everything up, it would also stop working in 8.07

[toodamnhip]

I don’t agree with James characterization of “brute force”, it’s a negative set of words that seems like a bit of a copout, always siding with DP. I don’t know why James or others can’t just say, “yes, DP is broken or has gone backwards in this area”.

I'm not asking you to agree with me, man. And correct me if I'm wrong, but I was under the impression that when you take your frequent snapshots, you do it across ALL tracks, and every parameter whether it changes or not, and I thought you also snapshot every parameter of every one of your plug-ins as well. I mean, the fact of the matter is that you may be working in a manner that creates an unusually large amount of dense automation data. It maybe that MOTU engineers did not anticipate this otherwise why give us a choice of which parameters to automate and which to allow to be static? No doubt it was for *efficiency* reasons. Maybe they didn't anticipate people automating parameters that never change? But last time I checked, this forum is not exactly overflowing with posts complaining about the issue that you have been harping on literally for YEARS here. That lends even more credence to the possibility that not many DP users work in the manner you do.

Maybe what you might want to do is send a project to MOTU... one that brings DP 10 to its knees and let them see it for themselves. In the meantime, you gotta do what you gotta do to get your work done, and yeah... I really have come to dread seeing your posts on this forum I started. Just being honest. You're not bashful about expressing your opinion around here... I don't think I should be either.

Hopefully MOTU can solve this someday before I finally throw up my hands and create a permanent topic for you to post away in. I can call it "DP Heavy Automation Issues" and rather than create new posts over and over, you can simply update that particular topic from time to time.

wow man, if you made a sticky about automation issues, I’d donate to your favorite charity!
And as always, I do thank you for this forum and for your patience even if you don’t like my posts.

[magicd]

To be clear: I do not work for MOTU and do not represent them in any way.

But I do have many years experience in the music software development business.

When I started with computers I thought they were an absolute platform. I said to a programmer "I like computers because they are a controllable universe". He just laughed. It may or may not be an example of chaos theory, but there are so many variables to a computer based recording system that we're lucky anything works at all.

It's quicksand. The OS changes. The processors change. Third party software and hardware is involved. There are variables and they constantly change.

Inevitably a customer comes up with a way to use the product that was never an intended use but ended up being an option in the software. That's true for the company I do work for now. We make an amazing tool and for sure someone will try to do something with it we never thought of.

So what happens next? Well, for any commercial company I would expect they'd look at a number of factors. Ok, so something could be improved. What would it cost in terms of time and effort? How many customers would it affect both positive and negative (because for sure if you change a behavior or even fix a bug you'll piss someone somewhere off). Can it even be done or is this a questions of unrealistic expectations?

I owned a Fostex B16 that cost me $7000 cash. Now people complain they can't get automation working the way they want across 60 tracks on a $3000 laptop? It's all relative.

The reason I'm posting here is not to minimize any perceived flaw in DP. I am here to offer a perspective on perhaps a practical approach to an obstacle. If DP doesn't work the way you want you have some choices: Switch to another DAW. Find a way to get around your obstacle to get things done. And with the second choice it's clearly a compromise. And as far as that goes my best suggestion is to be polite and consistent with the company that makes the product, and hope that what you want somehow becomes a development priority.

Dave

[Phil O]

I usually steer clear of the arguments, flames, vitriol, etc. but sometimes I have to speak up...

I have data. It’s real. Accept it for what it is. You now know MORE about DP than you did before now as the extra data is all the new comps and clean installs rule out my particular system.. . There’s been a gamut of tests by a member presented . I tried to write it out logically. Hope it made some sort of sense.

Well I’d like to see some of it it, I asked about it before and wanted to test for myself:

Can you give us a clue as to when you are seeing the failure. Tell us, for example, how many audio/MIDI tracks/VIs. How many automation lanes. Is most of the automation on MIDI tracks or audio? I would like to experiment with this and see what the limits are on my setup.

I was prepared to set up a test file and spend time on this, but I got no response except to say that testing would "be of little value." In case you didn't notice, I was trying to help. Why not try and work with the people here instead of always arguing with them. Life is too short, man.

Philippe

[MIDI Life Crisis]

When Finale removed the movie window my workflow was dead in that app. I had to use F2014.5 even though I bought the upgrade to F25 & F26. The company just deleted the movie window. No explanation. So like the o/p, I used the older version. Then that stopped working reliably as the OS moved on.

I was forced to find a method that worked. I did and it’s even more efficient than using the movie window in Finale was. The point, which has been made before, is when it’s clear that the old way is no longer valid, and one has exhausted the attempts to get it back to what it was, one either finds an alternative or sinks into a rabbit hole of despair and complaint, blaming everyone and everything except their inability to find a solution.

It’s been said that by the o/p that he’ll be damned before he changes his workflow to accommodate changes in DP. We’re seeing that play out in real time here.

A lot of very able minds have contributed to help, even to the extent of offering to test his issue on their machines. It has pretty much all been rejected. At this point, I’m treating the o/p the way he is viewing DP 10: a dead end with no solutions possible until something changes.

FWIW, DP10 performs flawlessly on my machine.

[FMiguelez]

I would be happy, for now, if I could listen to 5 different bounces of the same TDH problematic file.

That way, by trying to null out the different bounces, we could perhaps at least determine if automation always changes randomly or if there´s some kind of pattern about it.
Could it be due to one or a handful of particular plugins you always use?
Is volume being misread in the same spot always? Is it only some compressor parameters? Or is it always random?

Also, you ARE only bouncing audio and not MIDI VIs, correct? I'm assuming you printed all your VIs first (otherwise this could very well be the issue, as it has been for me mostly).

Let´s make this more scientific:
Even if we don´t have ALL your plugins, we could replace them as needed, and work with this (probably messed up) test mix. It would be the new test-base upon which we could test, and we should be able to make it sound the same every time to falsify your theory. If we can not falsify it, then you would definitely be on to something.

Posting your video with a working link, where you point us to the problems, would also work wonders here, and probably at MOTU too.

[FMiguelez]

So, just to recapitulate, from the 2 different automation issues we've been talking about, we ALL agree, including Dave, that the unwanted ramps are a big problem for people who move automated tracks around, or people who snip/paste automated tracks/regions, yes?
Even if it does not affect you personally, you can see it not working properly, correct?

The other more elusive problem, the automation-reading unreliability past a certain threshold, is where most of you guys do not agree with TDH because you've never seen it yourself, correct?
I've personally had this happened before just a few times, but in my case, printing VIs prior to bouncing solved the problem, so perhaps the causes were different.

So do we all agree on the first, but NOT on the second problem?

I just want to know where we stand regarding that for clarity.

[Phil O]

Even if it does not affect you personally, you can see it not working properly, correct?

I would have to respectfully disagree with this. I think "it is not working in the best way possible for some workflows" would be more accurate. It's working exactly as it was designed to work. DP isn't broken. It's just that this feature needs a better design.

DP automation works by connecting the dots (at least for audio). If the dots are not at the same level then the result is a ramp, as you would expect. To avoid these ramps when pasting in from a section of different level one needs to insert extra dots before and after the pasted-in selection (and, BTW, decide how far from the insertion position those dots need to be). DP doesn't do this automatically. So we need to stop saying DP is not functioning correctly and start asking MOTU to add a feature which automatically inserts the extra dots, preferably as a preference because I'm sure it would screw up someone else's work flow if they simply changed the behavior. JMHO

Phil