v6.76rc1 - February 26 2023

[mozart999uk]

Originally Posted by mccrabney

i can't thank you folks enough for chasing down these AI issues/details. i've never enjoyed working in REAPER so much as i have in the last few weeks. this is a massive improvement and i hope it doesn't go unnoticed by the larger community.

Same here. Thanks Devs and Thanks mccrabney for testing :-)

[Thonex]

Originally Posted by Klangfarben

Also, you only have a total of 10 screensets. So, you would be using up most of your available track view screensets just for simple zoom commands. And if you have screensets already assigned you are going to have to dump some of them, again just to zoom. That's not very efficient and not really a workaround option imho.

I agree... I've tried screensets multiple times in the past and abandoned them because they never really worked for me.

I think zoom presets would be fantastic. You can zoom into anything you want in Reaper, but it can be tedious. I would love to see some Vertical (TCP) zoom presets and some Horizontal (amount of time displayed in the arrange area) presets that would be action-able.

For example, the default track height (user definable in the Reaper prefs, not theme) could be "one" track height unit. And you could have 2 x unit, 3 x unit, 4 x unit... etc. heights for tracks. And you could also choose to have (say) a Horizontal zoom of 250ms for the entire arrange window if you are doing delicate transient work on a sound. Or, 5 min zoom for a whole piece. etc.

I hope I'm making sense.

Anyway... I fully support some kind of predictable zoom preset system. No need to change the zoom functionality, just an easier way to recall presets.

[_Stevie_]

That's a superb write up, Thonex.

And it reminded me, that we don't have a native "enlarge selected track" feature.
Well, we somewhat do, but it's tied to rec arm and the size is not user definable:



There are a couple of scripts out there, but let me show you a comparison.

Scripted enlarge selected track:





Native enlarge selected track:





It would be awesome, if the already existing feature could be extended to:

- enlarge selected track, no matter if it's rec armed or not
- the ability to define a custom track height

Thanks for considering!

[Futur8me]

Hello, I’ve noticed that the horizontal mouse wheel movement works in opposite directions when in the mixer view compared to the arrangement view.

I’m using a mx master 3 mouse.., when I use the horizontal thumb wheel up to go right in the mixer window it goes right.. but in the arrangement view window it goes left..?, it should work in the same direction for both arrangement view and the mixer view shouldn’t it?.

It works in the exact same direction in both bitwig and Logic Pro X.., is it a bug in Reaper?.

.
.

[bFooz]

There are assignable actions in the action list, search "scroll horiz mousewheel". There are reversed and non-reversed versions.

Don't know how it works with the horizontal mousewheel though.

[BPBaker]

Originally Posted by Justin

You can set the maximum in pref/editing behavior to be more than 100%

True. But on tracks with large numbers of takes or many FIP items (and of course the upcoming track items not included in this particular RC), the 800% vertical track zoom often still isn't enough for detailed editing in my experience.

And currently, even if your maximum vertical zoom is set to 800%, the "Toggle Zoom to Selected Items" action still sets you to a maximum vertical zoom of 100%, limited by the size of the track. (And then you have to zoom in further from there.)

To me, the most intuitive behavior would be for "Toggle Zoom to Selected Items" to zoom in as far as needed to have an individual item fit to the screen, regardless of track size or the maximum vertical "track" zoom.

[MonkeyBars]

Originally Posted by Klangfarben

Also, you only have a total of 10 screensets. So, you would be using up most of your available track view screensets just for simple zoom commands. And if you have screensets already assigned you are going to have to dump some of them, again just to zoom. That's not very efficient and not really a workaround option imho.

This touches on my FR for project-based screensets.

Global screensets are okay for studios churning out the same thing over and over between projects, but for creative musicians there tend not to be so few options. Other DAWs I've used tie the screensets to the project, which makes a lot more sense to me as my projects tend to vary widely from one to the next.

[Klangfarben]

Originally Posted by _Stevie_

It would be awesome, if the already existing feature could be extended to:

- enlarge selected track, no matter if it's rec armed or not
- the ability to define a custom track height

Now THAT is high quality GIF reporting! And perfectly shows why scripts/screensets can't cover this.

[bFooz]

Originally Posted by Justin

make a custom action that has one or more "Action: Modify MIDI CC/mousewheel: 2x" followed by the zoom action... see how many of those "2x" you need to make it as it was.

I need 3x "0.5" to feel alright.

Just to be totally clear: (MIDI editor context and scrolling in notation).

[FeedTheCat]

Originally Posted by Odys

+ ReaScript: add SendMIDIMessageToHardware()

I'm curious about the new API function.

Is there a benefit to using this over consecutive StuffMIDIMessage functions for Sysex? Is it faster for sending large chunks?

[JamesX]

Originally Posted by mpl

Thanks for this, Justin, from first testing that seems to work (at least launchpad enters session mode from REAPER)!

MPL,

Was your use of SendMIDIMessageToHardware() for a sysex message?

If so, could you give some details as to how you did this?

Thanks,

J

[Justin]

Originally Posted by FeedTheCat

I'm curious about the new API function.

Is there a benefit to using this over consecutive StuffMIDIMessage functions for Sysex? Is it faster for sending large chunks?

StuffMIDIMessage can’t be reliably used for sysex

[FeedTheCat]

Originally Posted by Justin

StuffMIDIMessage can’t be reliably used for sysex

Thx, makes sense. I'll start using the new function for some controller stuff I've got going on.

[_Stevie_]

Originally Posted by BPBaker

To me, the most intuitive behavior would be for "Toggle Zoom to Selected Items" to zoom in as far as needed to have an individual item fit to the screen, regardless of track size or the maximum vertical "track" zoom.

Yep, aka „enlarge selected track / item“, which would benefit the comp system AND the arrange. That’s why I mentioned it in my post.

[Justin]

Originally Posted by bFooz

I need 3x "0.5" to feel alright.

Just to be totally clear: (MIDI editor context and scrolling in notation).

Thanks! Does it feel right in the piano roll view with that or does it become way too slow?

also is the difference zoom-dependent or the same at all zoom levels?

Part of the reason is that in the score, it treated large mousewheel movements as small ones previously, so now it will be faster with the larger movements but possibly the same speed when moving it more slowly. So a 1:1 translation might not be expected.

[Phazma]

Originally Posted by Justin

Thanks! Does it feel right in the piano roll view with that or does it become way too slow?

also is the difference zoom-dependent or the same at all zoom levels?

Part of the reason is that in the score, it treated large mousewheel movements as small ones previously, so now it will be faster with the larger movements but possibly the same speed when moving it more slowly. So a 1:1 translation might not be expected.

Not sure if it is useful feedback and related to this, but one thing I noticed on macOS in the piano roll is that vertical scroll doesn't respond correctly to mouse inertia. Both horizontal/vertical scroll in the arrange window and horizontal scroll in the MIDI editor accellerate based on the mousewheel movement but vertical scroll in the MIDI editor seems to have a fixed speed which feels rather fast when zoomed in and awkwardly slow when zoomed out.

Another weird thing in the MIDI editor is vertical zoom which is very flickery because it uses the pitch under mouse cursor as zoom center (which is totally fine) but it additionally scrolls so that when the top of the mouse cursor reaches the top or bottom of a pitch the view jumps to reposition the mouse cursor again at the top or bottom of the pitch respectively. Instead the scroll and cursor positions hould remain static and only the pitches become bigger or smaller.

[bFooz]

Does it feel right in the piano roll view with that or does it become way too slow?

For the pianoroll, I'd say 2x "0.5" matches the notation quite accuratelly.

The physical distance travelled is the same at all zoom levels, which is good.

Part of the reason is that in the score, it treated large mousewheel movements as small ones previously, so now it will be faster with the larger movements but possibly the same speed when moving it more slowly. So a 1:1 translation might not be expected.

Hmm, I don't know why this would be treated separatelly, but I do get 1:1 distance with slow vs fast in both pianoroll and notation. I'm on Windows with normal windows mouse with clicks on the wheel. If anything, maybe +-1 click difference but that might be just how the finger moves the wheel.

[Justin]

ah actually I can make them behave identically between piano roll and notation, which obviously makes the most sense. the factor for that is actually closer to 1/3rd the current ratio...

[Phazma]

Originally Posted by Justin

ah actually I can make them behave identically between piano roll and notation, which obviously makes the most sense. the factor for that is actually closer to 1/3rd the current ratio...

Would it maybe be possible to make it overall behave/feel like in the arrangement window? Or is that undesirable for some reason or a totally different implementation?

[bFooz]

Originally Posted by Phazma

Would it maybe be possible to make it overall behave/feel like in the arrangement window? Or is that undesirable for some reason or a totally different implementation?

Yes, I think for consistency, the distance travelled should be the same everywhere for a vanilla action. And user can then use the same CC speed modifiers in every context if required.

[Buy One]

We need more screensets, or at least have them unlocked during REAPER session so we can add our own which i tried once only to hit a snug.

[Buy One]

Originally Posted by _Stevie_

And it reminded me, that we don't have a native "enlarge selected track" feature.

Not as a factory action, but there're

View: Increase/Decrease selected track heights [a little bit]

Admittedly they don't behave like record arm track enlargement which is exclusive to the selected track.

[_Stevie_]

Hm, that's not at all what I was proposing. My GIF makes it pretty clear, though:
you select a track and it zooms to a pre-defined track height. When you go to a different track, that one zooms and then the previous selected track goes back to its previous track height.

[Buy One]

Originally Posted by _Stevie_

Hm, that's not at all what I was proposing. My GIF makes it pretty clear, though:

The implication was that it could be scripted using these actions. Not ideal but seems usable

Originally Posted by ReaPack

Automatically increase height of selected tracks, decrease others'

[_Stevie_]

You clearly did not read my post, did you?
The first GIF shows a scripted solution.

[Buy One]

It didn't work like the native feature.

[_Stevie_]

So what you are trying to say is that the native action "View: Increase/Decrease selected track heights [a little bit]" is faster than setting the track height via the API?

But even if that's the case, the "enlarge selected track" feature would need a lot more than that, like monitoring the height of all tracks in the project. It would need when selecting the track via keyboard OR mouse. All scripts I have tried to date unfortunately don't work reliably in that regard.

[Buy One]

To me the most obvious difference between the scripted solution shown in the movie GIF and the native 'show full TCP on armed track' feature is that in the former tracks aren't expanded as soon as they're selected. But that's feasible with a defer loop. I'm not saying native feature is useless but that it can be emulated with the current toolkit.

[Klangfarben]

Originally Posted by Buy One

To me the most obvious difference between the scripted solution shown in the movie GIF and the native 'show full TCP on armed track' feature is that in the former tracks aren't expanded as soon as they're selected. But that's feasible with a defer loop. I'm not saying native feature is useless but that it can be emulated with the current toolkit.

It literally can't be done with a defer loop, you twat. That is literally the ENTIRE point of the request. If it *could* be done, we would have scripted it by now.

Also, I would suggest actually reading some of the posts too. I know it's a lot harder than watching visuals, but it really can be enlightening sometimes.

[_Stevie_]

You mean a defer script like this?

Welcome to Track Zoom Roulette!

[Klangfarben]

OMG Stevie, that is SO much better! I'm going to install that right now. You can clearly see how well the defer loop works for this!

[Thonex]

Originally Posted by Klangfarben

OMG Stevie, that is SO much better! I'm going to install that right now. You can clearly see how well the defer loop works for this!

To clarify, Klangfarben is being sarcastic here. I’m mentioning this for those who don’t read threads for context. He means the opposite, that Stevie’s request should be native
And not scripted.

[Thonex]

I will add this: when a SCRIPTER like Stevie asks for something to be native, there is a good reason. Just look at all the scripts written by “sr_” in Reapack. I don’t think Stevie just posts these requests without having seriously researched it.

[Buy One]

Originally Posted by Klangfarben

you twat.

Wow din't expect such a trivial matter to spark such emotion, LOL
Like, really, insulting out of the blue... Are you the 'scripter' whose 'solution' is demonstrated in Stevie's GIF? If you are i could empathize with you.

Now i know that you're someone 'with feelings', whether human being or not, that remains unclear

Originally Posted by Klangfarben

It literally can't be done with a defer loop.

Ready to bet you life or eat your hat?

This is CGI

Originally Posted by Klangfarben

If it *could* be done, we would have scripted it by now.

WE who? An elite fraternity of scripters Kappa Tau Delta who empowered you to speak on its behalf?

[schwa]

Cmon no name calling.

[Buy One]

Originally Posted by Thonex

Just look at all the scripts written by “sr_” in Reapack. I don’t think Stevie just posts these requests without having seriously researched it.

So i cannot respond to his posts daring to sound disagreeing with the authority, got it. Please excuse me.

[Buy One]

Originally Posted by schwa

Cmon no name calling.

Should i remove this?

Originally Posted by Buy One

Kappa Tau Delta

[_Stevie_]

The point is that someone (me) suggested to implement a native "enlarge selected track" feature, because it would also come handy, when editing takes with the new comp mode (there has been quite some feedback from users where the lanes are flooded with items and you can't see the wood for trees).

But then you come across and completely play it down and say: it can be done with scripting and render the FR useless. That is not nice.

As I said, I have been trying all the scripts out there (and no, the shown script is done by a member of the scripting community and not Klangfarben).
The issue becomes apparent, when you actually have 100s of tracks and all of them loaded with Kontakt instances and whatnot.

We need a robust solution for this feature, that is all I am saying.

[_Stevie_]

I put the FR in its own thread:
https://forums.cockos.com/showthread...76#post2655676

[Buy One]

Originally Posted by _Stevie_

But then you come across and completely play it down and say: it can be done with scripting and render the FR useless. That is not nice.
We need a robust solution for this feature, that is all I am saying.

Maybe that sounded or was perceived that way but this wasn't the import. I'm always in favor of new features, there cannot be too many of them.

The response was to address the GIF in which in my opinion the available scripting potential wasn't utilized.

Originally Posted by _Stevie_

As I said, I have been trying all the scripts out there

Something new may always come along.