Link Track and Edit Selection not working

[santoorman]

Upgraded to PT 2019.5. Still have 2018.10 app file on my machine.

When music is playing if click somewhere in any track it doesn't jump to it and start playing from there. dynamic transport is on as well as Link Track and Edit Selection.

Video of it NOT working in 2019.5
https://www.dropbox.com/s/afhamnbc4c...55-34.mp4?dl=0

Video if it working in 2018.10
https://www.dropbox.com/s/egye82x4av...18.10.mp4?dl=0

any idea why?? is this a bug??

[santoorman]

no one else having this issue?

[christian kuntner]

I asked the same question one month ago...same happening here, no helpfull reply till now...

[DAT11]

Same problem on 10.13.4 mac with PT 2019.5

This latest update also causes my computer to have severe CPU issues - even with new sessions with almost no plugins (never happened before with prior versions!). I even trashed everything and did a clean install. Way to sell those "subscriptions" AVID.

[grabie]

Originally Posted by santoorman

When music is playing if click somewhere in any track it doesn't jump to it and start playing from there. dynamic transport is on as well as Link Track and Edit Selection.

This happens here, too. I was wondering also, what is going on.

[bartosz idzi]

Maybe this may help?

http://duc.avid.com/showthread.php?t=404855

Originally Posted by daveyc

You are correct that there have been some tweaks to dynamic transport. The changes are the same in PT | Standard and PT | Ultimate... so no trickery on our part.
We have put a lot of energy into what we are calling 'continuous playback', which is an effort to remove most (many) of the little interrupts, hiccups, and glitches a user has to endure during playback when making timeline mods, instantiating plug-ins, adding and/or removing tracks, etc. We wanted to create an environment where a user could engage the transport and work uninterrupted without loosing sync or experiencing drop-outs or glitches with the focus being for music creation... staying in the flow.
This particular behavior was intentional. The idea was that when a loop end point was pulled in front of where the playhead currently was, the playhead would continue to play on, uninterupted.
In order to keep looping, a user would make sure the playheads was always within the loop points. If a loop needed to be shortened, it would need to be done while the playhead was still in the area prior to where the end point was being moved to.
I have received one additional complaint about this, so I will revaluate if this behavior is correct and potentially change it in the future. It seemed intuitive during development and behaved that way in some other DAWs that have a better rep for maintaining continuous playback during music creation.