v6.64+dev0728 - July 28 2022

[Edgemeal]

v6.64+dev0728 - July 28 2022

* Includes feature branch: track media/razor edit grouping
* Includes feature branch: pan law/function improvements
* Includes feature branch: improve experimental silent-track CPU reduction option to include FX tail length
* Includes feature branch: media item fixed lanes
* Includes feature branch: internal pin management overhaul for future extension
+ Media item fixed lanes: add lane header button context menu option to set recording lane
+ Media item fixed lanes: add lane header button mouse modifier to set recording lane
# Media item fixed lanes: after new recording, set track to play only newly created lane
# Media item fixed lanes: respect option to add new items in fixed lanes when recording overlapping items in a not-yet-fixed-lane track

Full changelog / Latest pre-releases

[AZpercussion]

Recording lane

Nice feature, but I expected it some different.
For now (maybe yet) it looks inconsistent with record modes and options for overlapping existing media items.

If option says split and create takes there is an overlapped item created on the one lane which marked for record. Also with trimming.
Strange. I expect if there is a lane chosen for recording it's behavior should be the same as on regular track.


There is only one case when different behavior will be anyway:
if track is FL track, lane for recording is chosen and option set to Create media items in fixed lanes.
As it is an empty (seems meanless) combination, I suggest a smart behavior.
We could have both take and lanes system simultaneously in this case.
There will takes created in items on the record marked lane, but in new lanes there will whole pieces of recordings. Just as a backup copy.
So we could use any variant of comping in every moment.
We could listen any whole record pass undestructed, copy something from it and move to comp lane.

Very often comping made while recording and it would great to have master lane for this purpose.

[schwa]

Originally Posted by AZpercussion

If option says split and create takes there is an overlapped item created on the one lane which marked for record. Also with trimming.
Strange. I expect if there is a lane chosen for recording it's behavior should be the same as on regular track.

Sorry, I don't follow what you mean. When the option is set to "split existing items and create takes", how is the behavior different when recording into a specific lane, versus recording into a non-lane track?

[Mercado_Negro]

I'm just digging deep into the fixed lanes feature and I don't think I understand the logic behind it. Let's see...

I have my track to record in and "create new media items in fixed lanes" is enabled. Ok, I hit record and get my first take, cool. Then I move the edit cursor a couple of bars before that first take to get a new take and it looks like this...



First question, why is the last created lane soloed? That doesn't make sense but OK, I'll record another take and things look like this...



The last lane is soloed by default which I still don't understand why but let's not focus on that, the real question is why this doesn't look like this?



Forget for a moment the split on the second item, I just didn't find a way to edit that image properly. The thing here is that third item I recorded stopped at a point that the second item above was still covering ahead so why not make that extra portion play automatically? I mean, what I want to understand is why not make it so fully enclosed items don't play and if a take is longer than the last recorded take just play that portion as well?

[bolgwrad]

"why is the last created lane soloed? That doesn't make sense"

For me, it eliminates the pause between having recorded multiple takes and choosing which to review first. There was also the uncertainty, without autocolor, of which is the most recent take.

The option to defeat it might be nice, but it makes sense to me.

[Sexan]

Originally Posted by Mercado_Negro

... the real question is why this doesn't look like this?

Its not that kind of feature. Lane = "separate track" here and there are some features missing (they are disabled atm since they are being reimplemented) which make this whole thing complete and make sense.

Check previous pres to check it all (v6.61+dev0626 is with every feature)

[AZpercussion]

Originally Posted by schwa

Sorry, I don't follow what you mean. When the option is set to "split existing items and create takes", how is the behavior different when recording into a specific lane, versus recording into a non-lane track?

It's simple. There just no takes on FL track are created. Items are placed on single lane.

So they play together and I don't see any sense. Because if I need layers I can use lanes or free item positioning mode.

[lucas_LCS]

"Lock Track Height" selection in the right-click pop-up menu doesn't appear to be working.
The tracks are still acting like they do when not locked.

I see this behaviour in v6.57 and v6.64

::

[schwa]

Originally Posted by lucas_LCS

"Lock Track Height" selection in the right-click pop-up menu doesn't appear to be working.
The tracks are still acting like they do when not locked.

I see this behaviour in v6.57 and v6.64

::

"Lock track height" means the track height will not be affected by actions like "increase selected track height", "zoom vertically" (control+mousewheel), etc. You can still resize the track by grabbing the bottom of the TCP and dragging.

[Edgemeal]

Seems OK here (regular tracks or Fixed item lanes), by OK I mean it works fine as long as I don't run a known action that breaks it.

Example, new project, add 2 tracks, height lock one track, vertically zoom the TCP with mouse, as expected only one track height increases, now run the action "View: Restore previous zoom level" multiple times, if you run the action one or more times then actually needed the track height lock no longer works. Even saving and reloading the project doesn't help, although the track height lock option is still enabled.

Win10 / v6.64 / +dev0728 _x64

FWIW This and other height lock problems were posted in pre-release, v5.78rc1 - March 16 2018
https://forum.cockos.com/showthread.php?t=204514

Wow, I completely forgot about my trick to get around that bug!

One workaround is to save as screenset after locking heights, then run those actions, then restore the screenset and the locked track heights work again!

Sorry for the OT post.

[lucas_LCS]

Originally Posted by schwa

"Lock track height" means the track height will not be affected by actions like "increase selected track height", "zoom vertically" (control+mousewheel), etc. You can still resize the track by grabbing the bottom of the TCP and dragging.

Thanks, Schwa.
I appreciate the clarification.

::

[deeb]

Originally Posted by schwa

"Lock track height" means the track height will not be affected by actions like "increase selected track height", "zoom vertically" (control+mousewheel), etc. You can still resize the track by grabbing the bottom of the TCP and dragging.

But why? I personally find this sort of things confusing and not clear workflow. If is locked even by dragging should be not resizable unless I unlock it fist. Example: I might just select all tracks for convenience and drag one of them to resize all of them that are selected but I would expect those that are locked to be unaffected.

Not that this particularly is something I struggle a lot but I do struggle with this hidden logics and not clear workflows specially on envelopes editing and envelope lanes. Is not clear. This small details have huge impact on users mental sanity.

[MonkeyBars]

Originally Posted by deeb

Is not clear..

+1

[AZpercussion]

Originally Posted by deeb

But why? I personally find this sort of things confusing and not clear workflow. If is locked even by dragging should be not resizable unless I unlock it fist. Example: I might just select all tracks for convenience and drag one of them to resize all of them that are selected but I would expect those that are locked to be unaffected.

Not that this particularly is something I struggle a lot but I do struggle with this hidden logics and not clear workflows specially on envelopes editing and envelope lanes. Is not clear. This small details have huge impact on users mental sanity.

Agreed. Locked track could be modified if I resize it directly. But if it placed among several selected tracks and I resize any unlocked track, the locked track should be untouched.
If there are several selected tracks and I resize the locked one, this track and other unlocked should be resize.
I think it's clear and convenient (don't require to unlock the track excess time) for user.

[schwa]

Originally Posted by deeb

Example: I might just select all tracks for convenience and drag one of them to resize all of them that are selected but I would expect those that are locked to be unaffected.

Dragging the bottom of a track only affects the height of that track, not all selected tracks. Actions that affect all selected tracks will not affect tracks with locked height.

Originally Posted by AZpercussion

Agreed. Locked track could be modified if I resize it directly. But if it placed among several selected tracks and I resize any unlocked track, the locked track should be untouched.

I think you are describing the existing behavior but you are agreeing with the previous comment that dislikes the existing behavior?

In any case the track height locking behavior is definitely not a prerelease issue as it has existed for many years!

[AZpercussion]

Originally Posted by schwa

I think you are describing the existing behavior but you are agreeing with the previous comment that dislikes the existing behavior?

Ah, yes! I see now, current behavior is right for me, I was confused by deeb's message. I see now he means mouse dragging. But we have mousewheel for that. One thing could be added: use shift to resize selected tracks while mouse dragging.

[deeb]

Originally Posted by schwa

Dragging the bottom of a track only affects the height of that track, not all selected tracks. Actions that affect all selected tracks will not affect tracks with locked height.

I use alt for dragging and the lock track height in not respected.


but i am on v6.59 - May 30 2022 , so Maybe something is changing now ..

anyway this brings me another thought:
if i have several tracks selected and drag one of them to make its height change, why not change all? it's selected , why not use the principle to do whatever in whatever is selected? which will bring me to what will say next:

Originally Posted by schwa

In any case the track height locking behavior is definitely not a prerelease issue as it has existed for many years!

Eventually for future, i wonder why not achieve workflow consintency between track level elements like Items , AIs, envelopes points , RE, everything possible ... if i do an action per example like glue and i have Item and AIs selected why not do glue to both? even withing just selected items some actions are applied to all selected , others not ... this brings confusion and not a clear workflow.

Sorry for this short out of topic vent

[BartR]

Originally Posted by deeb

I use alt for dragging and the lock track height in not respected.

but i am on v6.59 - May 30 2022 , so Maybe something is changing now ..

anyway this brings me another thought:
if i have several tracks selected and drag one of them to make its height change, why not change all? it's selected , why not use the principle to do whatever in whatever is selected? which will bring me to what will say next:



Eventually for future, i wonder why not achieve workflow consintency between track level elements like Items , AIs, envelopes points , RE, everything possible ... if i do an action per example like glue and i have Item and AIs selected why not do glue to both? even withing just selected items some actions are applied to all selected , others not ... this brings confusion and not a clear workflow.

Sorry for this short out of topic vent

This issue is not occurring to me on both: official release and dev.

6.64


6.64Ddev 728

[bolgwrad]

OT somewhat, but I wonder if people appreciate that their very hi-rez gifs make the whole pre-release thread very tiresome to read on a non-4k monitor.

[MonkeyBars]

Originally Posted by bolgwrad

OT somewhat, but I wonder if people appreciate that their very hi-rez gifs make the whole pre-release thread very tiresome to read on a non-4k monitor.

It's quite difficult to adjust gif size. Can't really be done with LICEcap which is the best animated gif screen recorder (created by Cockos btw!).

[deeb]

Originally Posted by BartR

This issue is not occurring to me on both: official release and dev.
]

.. I am using a modifier to drag not mouse scrolling. I can also feel on your example that the track which is with mouse over should stay in same place while everything would resize while keeping this track in same place, and not moving around. Same happens with project zoom. We zoom in and out and where our mouse is focused Gets changed position. Example: in zoom in and out in bar 5 I want this bar 5 to stay in same place where my mouse initially was. Otherwise is very corrousel and confusing. Details .. details but super important.

[Daodan]

Originally Posted by deeb

.. …
the track which is with mouse over should stay in same place while everything would resize while keeping this track in same place, and not moving around. Same happens with project zoom.
…
Details .. details but super important.

Not a prerelease issue too (sorry) but I’m with you.

[swiiscompos]

Originally Posted by bolgwrad

OT somewhat, but I wonder if people appreciate that their very hi-rez gifs make the whole pre-release thread very tiresome to read on a non-4k monitor.

Use the Reaper 5 theme for the forum (scroll at the bottom of the page to switch), it resizes images automatically, including GIFs.

[BartR]

Originally Posted by deeb

.. I am using a modifier to drag not mouse scrolling. I can also feel on your example that the track which is with mouse over should stay in same place while everything would resize while keeping this track in same place, and not moving around. Same happens with project zoom. We zoom in and out and where our mouse is focused Gets changed position. Example: in zoom in and out in bar 5 I want this bar 5 to stay in same place where my mouse initially was. Otherwise is very corrousel and confusing. Details .. details but super important.

I used ctrl+mouse wheel as usually I do.
Actually, before to open licecap, in the dev, I moved the track. I didn't even guess it could be important.

[BartR]

Originally Posted by swiiscompos

Use the Reaper 5 theme for the forum (scroll at the bottom of the page to switch), it resizes images automatically, including GIFs.

Great hint. I never noticed that switch. Thank you so much ✌️✌️✌️ just you loose the page selector. Everything is in one page ... but's manageable :-)

[deeb]

Originally Posted by BartR

I used ctrl+mouse wheel as usually I do.
Actually, before to open licecap, in the dev, I moved the track. I didn't even guess it could be important.

That’s the problem. You did not do it , reaper does it and so we loose our focus and we need to refind/refocus it again. This is systematic things that we use a lot every time and reaper silently makes our life worst.

[BartR]

Originally Posted by deeb

That’s the problem. You did not do it , reaper does it and so we loose our focus and we need to refind/refocus it again. This is systematic things that we use a lot every time and reaper silently makes our life worst.

Sorry but I can't recreate your bug ... I always use the modifier CTRL+Mouse Wheel