v6.73+dev0102 - January 2 2023

[Vagelis]

Originally Posted by Kenny Gioia

I think you already have this if you don't solo any lanes.

How? In order to comp I have to solo at least one lane.

Also another problem regarding REs and comping, if i make multiple comps which is the most common thing, how can i move just the one of them if i want to change it during playback?

[Vagelis]

Originally Posted by Kenny Gioia

I agree. And most people will be drawing one area at time anyway. Draw, promote, move on.

Here i will disagree since i would prefer to find the right comps before promoting during playback. I prefer to be able and experiment with multiple comps in lanes and not only with the result on top lane.

[ovnis]

Originally Posted by ferropop

This is nice and approximates the "cycle takes" in classic Reaper comping.

When committing to top lane, I don't think the Razor Area should move TO the top lane. It should stay where it was, as you are focused on the material AT the RE.

+1000 Faster and logic.

[ferropop]

I get the advantages of keeping this open-ended.

Just hoping the workflow is at least as fast as classic Reaper editing. There's some quirks that maybe are just a result of this being so new.

ie,

If you choose Lane 1 as your Comping lane, and you do another recording pass, that latest recording lane becomes your audible lane.

The whole thing does. So you had a comp going, you decided to add another pass, and now the comp that was playing is switched.

Which lane was it? If you had multiple comps, which one?

[ovnis]

Originally Posted by vitalker

Now we should push it to the limit!
We need non-contiguous playback/render based on razor edits. Non-contiguous not only in time, but also in tracks.

If I have well understood: on a regular track, only the area which is inside the razor edit is played (with a specific mouse modifier)?



It could be great!

[ferropop]

What I'd expect when adding passes that overlap :

1. The new pass adds itself as a lane. Nothing changes, the previously playing lane keeps playing.
2. If there's a Time Selection, the pass adds itself as a lane and the section inside the Time Selection automatically gets promoted to the comp lane

[ferropop]

Originally Posted by Kenny Gioia

My feeling on it:

1. Many people don't care
2. Colors
3. Item name can be based on the track and lane it was recorded into
4. Choose the preference (doesn't exist yet) to cut when promoting a section so you always see the wholes created and know where it came from.

Are any of these perfect? No? Do they need to be? I don't know.

People will feel differently (like you said). Putting in my 2c for this being an unfortunate downgrade (in this specific way).

I also create doubles/stacks like you, from takes with the handy action "Delete active takes from items". It guarantees that you're not re-using takes in the stacks. We obviously lose this handy functionality also, unless you "make holes" like you suggested.

Making holes in the source material doesn't sound great honestly...?

And if you didn't do this "during" comping, you can't "make holes from current comp".


Just laying out some thoughts as they come.

[Jae.Thomas]

this really does seem to work well with ARA2 Melodyne 5 as well. It takes from the playing tracks only.

[ferropop]

Originally Posted by Jae.Thomas

this really does seem to work well with ARA2 Melodyne 5 as well. It takes from the playing tracks only.

Was about to test this. Melodyne is finicky even with the slightest little Undo or Delete. I'm cautiously optimistic (!!) that edits won't get reset when making little comp changes.



...can't quite make sense of what is happening, but edits are lost sometimes and not others. And Undo results in edit losses (which might be dependent on the Undo states settings). But notice that the item earlier in time kept its edits, and the one later in time lost them. Why?

^^ this might also give insight to lost edits many people are experiencing already!!

Devs please keep an eye on how this all interacts with ARA. In 2023 this is essential.

[Jae.Thomas]

Originally Posted by ferropop

Was about to test this. Melodyne is finicky even with the slightest little Undo or Delete. I'm cautiously optimistic (!!) that edits won't get reset when making little comp changes.

I did get a freeze at some point but I had some other plugins loaded that may have caused it.

Starting from scratch, worked great.

-----

Do we have a way to auto-color lanes and have them propagate to the top lane?

[Kenny Gioia]

Originally Posted by Vagelis

Here i will disagree since i would prefer to find the right comps before promoting during playback. I prefer to be able and experiment with multiple comps in lanes and not only with the result on top lane.

That's fair. It's just limiting because you can't use up/down actions as that would affect all of your razor edits.

[Kenny Gioia]

Originally Posted by ferropop

There's some quirks that maybe are just a result of this being so new.

Yes. Don't get too caught up in them. It's early.

[ferropop]

Not sure if this is good or bad, but:

If you solo a lane, Melodyne analyses it. Forever. If you make changes On The Lane, and then Comp a part of that item to a Comp Lane, those edits get transferred to the comp lane.

I'm not sure if this is amazing or terrible.

Also I get the feeling that soloing lanes in certain cases will result in lost edits, because Melodyne is analysing new stuff - potentially ruining your edits on the comp.

[Jae.Thomas]

Originally Posted by ferropop

Not sure if this is good or bad, but:

If you solo a lane, Melodyne analyses it. Forever. If you make changes On The Lane, and then Comp a part of that item to a Comp Lane, those edits get transferred to the comp lane.

I'm not sure if this is amazing or terrible.

Also I get the feeling that soloing lanes in certain cases will result in lost edits, because Melodyne is analysing new stuff - potentially ruining your edits on the comp.

I like the idea that the edits stay with the particular piece really - in some ways I'd rather that top lane be more of a reference to the originals....

would you want melodyne to treat everything so seperately?

What if you try a different piece, melodyne that, and change your mind and want to go back?

[ferropop]

Originally Posted by Jae.Thomas

I like the idea that the edits stay with the particular piece really - in some ways I'd rather that top lane be more of a reference to the originals....

would you want melodyne to treat everything so seperately?

What if you try a different piece, melodyne that, and change your mind and want to go back?

So it's more to do with Melodyne sometimes "freaking out" when new analysis happens, and trashing the edits.

I'm concerned that these otherwise-innocent actions in lanes will result in lost edits - just trying to catch the quirks now!


...and as I show above, it trashed the later in time edit and not the earlier in time one, showing that something weird is happening with Razor Edits (and I think has been happening for years).

[ktm]

i tested the comping workflow and like it.
promoting areas to the top lane or any soloed/selected lane works for me.

2 things i miss feature wise:

#1 better display of lane names: at one point lane numbers were displayed ON the track. it would be easy to add a lane name within that form of display.

#2 option to hide all tracks which are not soloed.


this way trying out different comps and working with track versions would be possible.

thanks!

[mlprod]

Originally Posted by Gass n Klang

good to know, thanks! please keep in mind, that just showing only one lane at a time doesn't really solve the problem. I think it's undispensable to be able to see which takes cover which parts of a song at a glance. If a recording session is running out of time, you need to have an overview, how much material you recorded for every part.

The takes would have different names inherent in the file names. Kick-001, Kick-002 etc.

[nofish]

Originally Posted by vitalker

v6.73+dev0102 - January 2 2023[*]+ Media item lanes: add controls to razor edits on fixed lane tracks to move area without contents, copy contents to first playing lane

I know it's very early days (but so maybe a good time to mention it), I hope this new comping system eventually also gets useable for when not all recording passes are necessarily the same length (i.e. non beat-based music).
That's were the old takes comping totally falls short with the auto-splits imo.

I'm thinking if we could not just copy vertically but additionally set a destination point where it should be copied (edit: in time) (aka source destination editing) we'd be quite close already.

[ferropop]

Hoping this can be retained from current comping :

Cycling takes (or areas of takes) in a collapsed state.

It's easy in current Reaper because there's no comp lane, and the take borders are splits, so you just run the actions and it cycles the selected items even if collapsed.

The corollary might be to Swipe a RE on an area of the collapsed lane, and the cycle actions would (internally) "cycle the area up/down a lane and comp it to top".

This would operate very much like the current (very fast and desirable) functionality.

[ferropop]

Ability to lock the comp/audible lane would also go very far towards keeping things stable/consistent/reliable.

It's far too easy to change audible/destination lanes currently - it would take zero effort to accidentally be comping lane 15 to lane 7, meanwhile the comp is actually meant for Lane 1. If you could LOCK Lane X as the destination, and it require effort to unlock, that would be great.

One of the biggest gripes in classic comping was how easy it was to change the active take - just by clicking. I had to keep lanes collapsed or tell the artist not to touch the mouse, for fear of having the comp ruined by simply clicking on stuff.

Some thought in this area would go far!

[lb0]

Potential bug?

For some reason, in the last few dev builds - my script gui window titles have been truncated to a single character. This doesn't happen on v6.73dev1230, and started on v6.73dev1231.

Can anyone confirm?

I'm on Reaper 64, Win10. This is a problem for my scripts - as they use Julian's API and require getting window handles using their window title.

If it's not a common problem - I'll move this to the bug report forum.

Installing dev1230 fixes the issue for me.

[Justin]

Originally Posted by lb0

Potential bug?

For some reason, in the last few dev builds - my script gui window titles have been truncated to a single character. This doesn't happen on v6.73dev1230, and started on v6.73dev1231.

Can anyone confirm?

I'm on Reaper 64, Win10. This is a problem for my scripts - as they use Julian's API and require getting window handles using their window title.

If it's not a common problem - I'll move this to the bug report forum.

Installing dev1230 fixes the issue for me.

Fixing, thanks!

[ovnis]

Some issues:

When mouse modifier>Razor edit are>default action is set on "remove area", or "remove on area" we can't move the razor zone with the arrows.

It should be better to not be able to move at once separate razor areas when we use the arrows. Arrows should move only the razor area where there is the clicked arrows.


"+ Media item lanes: when razor edit areas exist on fixed-lane tracks, play only the media within the razor edit area"
The play of midi items works very bad. Notes seem stucked or there is no play.

[Tale]

* Includes feature branch: JSFX new features and EEL2 preprocessor

Reminder: This issue described by bwsd is still an issue in the current pre-release:
https://forum.cockos.com/showthread....06#post2619006

[Vagelis]

Originally Posted by ovnis

Some issues:
It should be better to not be able to move at once separate razor areas when we use the arrows. Arrows should move only the razor area where there is the clicked arrows.

Yeah that's another issue about using RE for comping, we can't move one razor edit when there are many of them.

Imo I think we should have a dedicated tool for comping similar to RE that will act as the first implementation of play markers and stay visible, so we can see the comps even if we edit inside them.

[Embass]

[ovnis]

The actual arrows system is pretty slow, not very ergonomic:




I think this system should be better:

We can drag & drop only verticaly the razor zone when we maintain the mouse click on the double arrows button. The mouse cusor disapears when we maintain the click.



The advantage:


So we haven't to move the mouse cursor on the arrow each time we have to move down or up the area zone.

We haven't to choose the good arrow if we want to move up or down the razor zone. There is only one button.

It's faster and easy to use!

The double arrow:

[mccrabney]

edit, nvm, this is unchanged and just a result of vertical zoom focusing on track under mouse instead of an unmoving target.

regarding the new zoom behavior, here's a gif showing some jerky movement that occurs if you zoom out vertically to shrink all tracks, and then continue to scroll out. once you hit the minimum, the tracks "shake" as you continue to scroll.



compare to 6.64, where the same over-scrolling does not cause the screen to shake.

[mccrabney]

scratch that, sorry. this is just what happens when you have the vertical zoom set to "track under mouse"

[nofish]

Originally Posted by ovnis

The actual arrows system is pretty slow, not very ergonomic:

There a shortcuts for it I think (can't test atm).
https://forum.cockos.com/showpost.ph...68&postcount=5

(but of course not everyone likes using shortcuts so it's not against your suggestion. )

[Justin]

Originally Posted by mccrabney

edit, nvm, this is unchanged and just a result of vertical zoom focusing on track under mouse instead of an unmoving target.

regarding the new zoom behavior, here's a gif showing some jerky movement that occurs if you zoom out vertically to shrink all tracks, and then continue to scroll out. once you hit the minimum, the tracks "shake" as you continue to scroll.

by "continue to scroll" do you mean continue to zoom, or switching from zoom to scroll once you've zoomed all the way out?

[Justin]

Originally Posted by Tale

Reminder: This issue described by bwsd is still an issue in the current pre-release:
https://forum.cockos.com/showthread....06#post2619006

thanks for bringing this to my attention!

[mccrabney]

Originally Posted by Justin

by "continue to scroll" do you mean continue to zoom

continuing to zoom, using the default ctrl-mousewheel shortcut to "View: Zoom vertically (MIDI CC relative/mousewheel)"

1) set vertical zoom is set to "Track under mouse"

2) run "View: Zoom vertically (MIDI CC relative/mousewheel)" until the tracks are as small as they get

3) then continuing to run that action results in the "shake" seen above.

"why would a user try to zoom out more than possible"

they wouldn't necessarily try, but it may occur unintentionally. i navigate projects by zooming vertically on track under mouse + zooming horizontally on edit cursor. when zooming out, and moving fast, my finger always scrolls a few times more than necessary, resulting in the shake.

[Justin]

Originally Posted by mccrabney

continuing to zoom, using the default ctrl-mousewheel shortcut to "View: Zoom vertically (MIDI CC relative/mousewheel)"

1) set vertical zoom is set to "Track under mouse"

2) run "View: Zoom vertically (MIDI CC relative/mousewheel)" until the tracks are as small as they get

3) then continuing to run that action results in the "shake" seen above.

"why would a user try to zoom out more than possible"

they wouldn't necessarily try, but it may occur unintentionally. i navigate projects by zooming vertically on track under mouse + zooming horizontally on edit cursor. when zooming out, and moving fast, my finger always scrolls a few times more than necessary, resulting in the shake.

Yeah, when zooming and set to "track under mouse", it adjusts the scroll so that the track in question is preserved under the mouse... so it shouldn't shake, unless the mouse position changes too, which might be what's happening?

[mccrabney]

yes, that's it. in this case, movement of even 1 pixel will result in a shake. "zoom to track under mouse" seems to be "zoom to mouse position in track under mouse"



with all of the optical mice i've used, due to the forces involved, the mouse cursor tends to move a tiny bit when the i scroll. by nature, it's kind of a sloppy input in that way.