murat k.

Can you fix this bug? When you come up with a workaround I have a feeling like: "This bug will never be fixed."

So the lesson learned from this topic: "The Concept is everything."

Thanks for the sharing of your workflow. It seems that you're not trying to move the clips from before the zero point. This would be crazy. But also you gave an advice not to do that. So I am not sure that if you didn't do. The thing is, people are giving advices to the people without carefully reading their topics. In the OP it says So it has nothing about misdirection. You also didn't get what I was saying. No problem. I think you get it now.

And this is crazy when you're trying to nudge clips to a position before the starting point.

I also don't think that no one is trying to move a clip to a nonexisting position.

I don't think so: There is obviously something about shortcuts. Just turn on Numlock. It will nudge.

Just like "MIDI Event Chase on Play" action. This behaviour will keep and read the note till the end. MIDI Event Chase on Play is for playback, this will be for editing. By the way Ableton LIVE also works the same way, you won't need editing in PRV for this action:

If there was a preference like "Trim also Notes while trimming the Clip", this would solve our problem @msmcleod .

OK, but this is more practical.

Thanks Mark, but I'm not talking about the stretching the clip itself. It is about stretching the start point of the clip. In the second GIF I'm only changing the position of the starting point of the note and the Note remains. This is not possible in the Cakewalk.

When we stretch a clip and if the note starts beyond the clip, the note disappears. It's not like that in other DAWs. This way is more productive. So please make it that way.

1. Each menu has different purposes. "Track View/View/Display" is for Clips "Track View/MIDI" is for View only MIDI "Track/Edit Filter/Notes" is for Editing selected CCs So no problem with the menus. 2. Menu is closing with every selection. It can stay and disappear whenever we click outside of the menu. +1 3. They use only use Track color in Clips mode but yes, they can use their color in faded mode. So +1 4. Absolutely +1 5. Yeah, unfortunately. We should be aware of notes when selecting a CC in Inline PRV. +1

I'm more like talking about when you're editing a Controller, brighter colors are OK. But when you're not editing a Controller, when they're in the background, the view should be darker.

I'm not talking about changing the Controller Colors. I'm talking about when the Controllers are visible in the background, they should be darker than the current situation. This will be an overall process for every Controller. Just like they made it brighter to improve the visibility of Clip outlines in the PRV, the same thing, but this will be darker, not brighter like with the Clip Outlines.

With the Release 2022.11 Update developers"Improved MIDI clip controller rendering" But they did only for Clips Pane. We also need the same thing for PRV.

Now it's clear.

Yes when the cursor turned into the Drag mode, press Ctrl, you'll get snapshots at selection begin-end.

You don't need to drag with the Ctrl. I'm sure that we are talking about the same thing. 🙂

You never know. They're doing awesome stuff. Also this request is not new. So it can happen anytime.

I think it's time to make an implementation of this request. Yes there are some plugins but thanks. To me working with the Linked Clips is the best way for now. But it is just a workaround. We need a flexible built-in MIDI routing feature in the Cakewalk.

When the Controller Pane is closed and Display Multiple Controllers checked with showed CC value, while working with Notes/Velocity, the background is too bright. Just like the New Dark Controller Events in the Clips Pane, making it possible in the PRV View would be great.

Thanks @GreenLight . Yes I remembered that function. When the cursor turns to the automation drag mode, pressing Ctrl is adding nodes at selection". So we only need a working "Automation Snapshot Shortcut".

😄

When the Tempo Track is at minimal level it is 50 pixels height. When it is at that height it draws integers. If you drag Tempo Track a little bit higher, it starts to draw decimals. And if you have a Tempo like for example 60.51 and if you drag Tempo Track at minimum level 50 px, tempos starts to draw 61.51, 62.51 Same thing happens when the Tempo Track height is at 100px just like 50px. It draws integers. Because every cursor move on pixel draws tempo. With the same logic if you extend the Tempo Track height to 200px you'll see that tempo increment turns to 0.5 And all those are in the scale of 100bpm. if you increase it to 1000bpm, auto-scale does the job and you lose all these integer values even if you change Tempo Track height to specific level. And I am saying we shouldn't have to deal with those kind of things to get integers for tempo values on drawing. It can be solved easily by a variable. Anyone can change their desired values and draws tempos by that value increment. It will snap tempos to defined values. Actually this request isn't new. I requested it years ago when the Tempo Track is not avaiable. You can see at Tempo Snap Setting:

In the PRV, events change frequency determined by event drawing resolution. In the TrackView it is controlled by AutomationDecimationMsec variable. So actually in the Track View or in the PRV, they do the same thing for automation, both are sending individual events. I am requesting a preference to automatically disregarding Snap settings when drawing automation in PRV. So transitions between events will become smoother without disabling the Snap everytime. Also we can't do everything with the envelopes: