MOTUnation.com

if I stop and start playback after the first automation point, the plugin automatically bypasses itself, ignoring the automation that is telling it to be unbypassed. It then remains that way, ignoring the automation until I start playback before the first automation point again.

I don’t see a bug. If the automation is to change a state, how is it supposed to work once you have passed the first point? This is not the same as changing a snapshot.

Working as it always has here but still pine for two features: update to end of song/file in write/trim/mute plus allow a feature selectable in prefs which keeps mute automation on and active in solo and allows mute automation during and while in solo mode. GB

I have been begging MOTU for these since 2005.

mikehalloran wrote:

if I stop and start playback after the first automation point, the plugin automatically bypasses itself, ignoring the automation that is telling it to be unbypassed. It then remains that way, ignoring the automation until I start playback before the first automation point again.

I don’t see a bug. If the automation is to change a state, how is it supposed to work once you have passed the first point? This is not the same as changing a snapshot.

A plugin that has automation that uses the bypass functionality:
1. Does not chase.
2. Will flip it's state when the transport is stopped and then remain in that flipped state when the transport is restarted.

I'm experiencing other chase automation erratic behaviours also.

This a real problem for me and basically makes DP 10.11 not work for how I use it. I'm having to wind back to 10.01 where this problem does not happen. I've done another tech-link about it too, so fingers crossed Motu will fix this soon.

Sorry for not seeing Page 1:

hammerman wrote:
Called MOTU and they confirmed the bug. They were able to replicate. Passed on to Dev team.

Glad to know they understand it is a bug - but automation working inconsistently is a problem. I am going to file a TechLink for my case, just so they have enough 'this really is a problem votes'.

I am seeing a very similar/same issue [automation doesn't work after stopping playback] with simple 'straight line' automation on the HCF Freq using MW EQ.

If I Stop playback in the middle of the automation or after it is done, and move the current play position cursor back before the automation and hit play, the freq resets but when it hits the automation line, it does not do anything.

If I Stop playback in the middle of the automation or after it is done, and move the current play position cursor back before the automation and click Stop again (sometimes have to hit it twice), then when it plays the automation works.

It seems to be requiring me to hit Stop (once or twice) again after positioning the cursor for automation to work.

This is on macOS 10.14.6, DP 10.11

Rich

mikehalloran wrote:

if I stop and start playback after the first automation point, the plugin automatically bypasses itself, ignoring the automation that is telling it to be unbypassed. It then remains that way, ignoring the automation until I start playback before the first automation point again.

I don’t see a bug. If the automation is to change a state, how is it supposed to work once you have passed the first point? This is not the same as changing a snapshot.

+1

mikehalloran wrote:

if I stop and start playback after the first automation point, the plugin automatically bypasses itself, ignoring the automation that is telling it to be unbypassed. It then remains that way, ignoring the automation until I start playback before the first automation point again.

I don’t see a bug. If the automation is to change a state, how is it supposed to work once you have passed the first point? This is not the same as changing a snapshot.

Shouldn't the playback behaviour be exactly the same as it would be if you hadn't stopped and restarted? Don't we expect playback to conform to the most recent automation setting for all parameters?

A Poem for MLC

Does not chase?

MOTU must face!

HCMarkus wrote:A Poem for MLC

Does not chase?

MOTU must face!

Mongo like poems...

MIDI Life Crisis wrote:

HCMarkus wrote:A Poem for MLC

Does not chase?

MOTU must face!

Mongo like poems...

I am often surprised when folks reveal an appreciation for verse.

I prefer the chorus.

High art. Now I have the munchies.

MIDI Life Crisis wrote:High art. Now I have the munchies.

I've got these really good brownies...

bayswater wrote: Shouldn't the playback behaviour be exactly the same as it would be if you hadn't stopped and restarted? Don't we expect playback to conform to the most recent automation setting for all parameters?

If the app is generating a data stream, then yes. Volume, pan and many other parameters are recorded as data streams—but not all.

Many times, the data doesn't stream. Instead the status of a parameter changes and that's all. Think of a marker that changes xxxyxy to xxyxxy. If you start past that, the change cannot happen because the marker was missed and the state was never set to xxxyxy in the first place.

This is an occasional complaint in many forums including Finale that end in "...but that's not what I want."
"Sorry, a complete rewrite of the app to give you that is unlikely."
"What is the workaround"
"Start playback from the beginning."

mikehalloran wrote:Many times, the data doesn't stream. Instead the status of a parameter changes and that's all. Think of a marker that changes xxxyxy to xxyxxy. If you start past that, the change cannot happen because the marker was missed and the state was never set to xxxyxy in the first place.

This is an occasional complaint in many forums including Finale that end in "...but that's not what I want."
"Sorry, a complete rewrite of the app to give you that is unlikely."
"What is the workaround"
"Start playback from the beginning."

I suppose because disabling a plugin is not a controller, developers can argue they shouldn't have to code to chase it. But rewriting the app is obviously not required -- I haven't done coding for a long time, but I could figure this out. It's nice we can automate things like disabling something, but it really needs to be done properly. I had an expensive German car once, and complained to the dealer that it developed a slight front end shudder over 80. They said not to drive it over 80.

mikehalloran wrote:

bayswater wrote: Shouldn't the playback behaviour be exactly the same as it would be if you hadn't stopped and restarted? Don't we expect playback to conform to the most recent automation setting for all parameters?

If the app is generating a data stream, then yes. Volume, pan and many other parameters are recorded as data streams—but not all.

Many times, the data doesn't stream. Instead the status of a parameter changes and that's all. Think of a marker that changes xxxyxy to xxyxxy. If you start past that, the change cannot happen because the marker was missed and the state was never set to xxxyxy in the first place.

This is an occasional complaint in many forums including Finale that end in "...but that's not what I want."
"Sorry, a complete rewrite of the app to give you that is unlikely."
"What is the workaround"
"Start playback from the beginning."

I have the same issue and I'll try to describe the problem so you can try to replicate it, if you want:

I record enable automation on a track (audio or other). Then use aux send 1 for example to route the track's audio to this auxiliary and record a single "bypass" on/off event on it. So far it works as it should.
Now use any other aux send and record a "bypass" on it as well. What happens now is that when you play the song from start to end, it reads the events fine, but if for any reason you stop playback after the event (and there are a hundred of times you do this during mixing), and start playback again, "bypass" returns to its initial state and not to the last one, as it is supposed to do. It does not actually read the "bypass" automation on this second aux.

This is quite a serious issue (and one I've never had in any previous version) which renders DP 10.11 unusable for mixing, for me. I'll send a techlink to MOTU on this but in the meantime I'm afraid I have to go back to 10.01.

After doing some more tests, it seems that the problem appears to be happening to all the aux sends that are below the first (from top to bottom) aux that already has any type of automation recorded on it, irrespectively of the type of automation or which one of them was recorded first. It also happens only when you stop and then start playback again, at any position after the event.