time stretching oddity; new bug?

[EMRR]

Yesterday I tried manually stretching a soundbite to a shorter duration, and it would just disappear. I tried moving other layers back to see if ti was under another soundbite, no luck. Didn't appear on the soundbites list as a stretched soundbite (I think they show up that way?). Using 'scale time' did the same thing. If I stretched longer versus shorter, it was still there, but nonsensical in appearance. This is the first stretch I've tried since moving to 11.31. I need to try it again on another session. Anyone seem similar? Turned it off, turned it back on.....


EDIT - see below

[stubbsonic]

Just did a couple tests here with mono & stereo tracks and I'm not seeing that here.

I did it with grid snap off, FWIW.

[mikehalloran]

I can’t duplicate this.

[EMRR]

Ok, I couldn't see where it was going yesterday, just tried again.

Time stretch or ‘scale time’ to a shorter increment on a soundbite that’s not at it’s original timestamp makes the soundbite disappear, other than what looks like a 1 sample line that is only visible at certain zoom levels. Stretch or scale longer gives non-sensical result.  ‘Set user timestamp’ doesn’t address the problem. Other soundbites stretch as expected.  I tried deleting the analysis files, made no change.  I can't replicate it in other DP sessions.   

There is another graphics bug(?) I was seeing shortly before this happened, pops up occasionally, I wonder if it’s related. Sometimes if I move the edge of a soundbite, another copy appears underneath the one I’ve moved. I have to start deleting layers of copies to get it back to a single soundbite. I’ve seen this every now and then since I moved to DP11. This sessions was built from a template that I built from scratch in DP11, it wasn’t transitioned from an earlier DP.


Link to screen capture:

https://www.dropbox.com/s/y16a4uc0fg9e4 ... 5.mov?dl=0

[stubbsonic]

Does it make any difference if you drag the upper right corner rather than the upper left? (Upper right is my default behavior).

[EMRR]

Does it make any difference if you drag the upper right corner rather than the upper left? (Upper right is my default behavior).

Same result

[PVB]

Noticed same issue last night. Upgraded to DP 11 recently.

[EMRR]

From MOTU support, in my case:

I've been testing this project, and can definitely see the behavior you're experiencing. It's hard to say exactly what is causing the issue at the present moment, but I do have a fix that may work for you. Try moving these problematic soundbites to a new track(s), and then attempt to stretch/compress them. I've just tried this on my system, and the soundbites that were experiencing this issue in their original tracks do not exhibit the behavior on the new tracks.

[bayswater]

I can't reproduce this either, not on an M2 Sonoma, nor intel macOS 12.7. I wonder if it's a corrupt project? Can you import the audio into an empty new project (not created with your template) and reproduce it? If not can you import the sequence and reproduce? Might narrow it down.

[EMRR]

I can't reproduce this either, not on an M2 Sonoma, nor intel macOS 12.7. I wonder if it's a corrupt project? Can you import the audio into an empty new project (not created with your template) and reproduce it? If not can you import the sequence and reproduce? Might narrow it down.

Have been around and around on every option, and also with tech support. They provided the best known answer. Not sure if it was stated earlier, but it's one sequence in a session with 8 sequences, built from scratch. I've never seen it again. As sliced and diced as it is, I wouldn't begin to know how to import it into another project, there's a zillion cuts and crossfades. It's not just dragging a few files over.

[mhschmieder]

I kept two related/similar issues bookmarked from last year and will check them as soon as I can to see if they are manifestations of this one, as your report sounds awfully familiar to me, but I haven't had time to re-check the issues recently or reverify my workarounds. I'll link the other topics once I am confident they are part of the same issue.

UPDATE: I have some hand-written notes on a related topic that I'll re-find shortly, but my two bookmarked topics are about conductor track tempo changes not behaving correctly, and side effects of changes to continuous data caused time scaling even though unrelated. This latter problem MAY relate to what you have observed, however.

viewtopic.php?p=598270#p598270

[mhschmieder]

I found my handwritten notes from earlier last year, and they may correspond, but I haven't rechecked this workflow lately to see if it is still an issue for me in my specific setup.

If I selected MIDI by bars, that is, if I selected a range in the Tracks View vs. selecting discontiguous MIDI blocks (and not gaps between blocks such as when dragging a bar range), this should correspond to a continuous time window range, but if you change velocity on this selection, it also time-stretches, which of course is an unrelated activity.

In transferring and rewording these notes just now, I think it is probably solved in recent updates, but I have to close my browser to have enough resources to run DP so I can't check it directly while participating in a forum topic.

[bayswater]

I wouldn't begin to know how to import it into another project, there's a zillion cuts and crossfades. It's not just dragging a few files over.

Start a new empty project, and use the Load command in the File menu to import the sequence from the original project. No dragging required.

[EMRR]

Worth a try

[mhschmieder]

Yeah, loading into a new project often clears up a lot of problems. Be careful about duplicating bundles on the way in though, or you'll have some bookkeeping and cleanup afterwards.

I try to use the same bundles template across projects, to avoid such time-consuming issues, but of course over the years our interfaces change and a project that hasn't been opened in a while has bundles different from our current template.