v6.73+dev1231 - December 31 2022

[Justin]

(try putting like 4 or 5 of those 0.5x modifiers on that custom action, maybe?)

[ovnis]

With that option the behaviour is near than your gif but it seems you don't understand my issue.





first mousewheel move = zoom 1
second mousewheel move= zoom 2
third mousewheel move = zoom 3

In the previous version, each mousewheel move matchs perfectly with my theme. No wast space.




Now, on the second mousewheel move, I have an issue:







Plus, now it becomes very slow/fastidious to zoom. And zoom steps feet even worse than before with my theme.

At the limit, I prefer not to add the 0.5x action.

Either way, forget all that. I would stay on the previous version which is very good and I will come back to the new versions if someone releases a script that reverts to the old zoom behavior.

Thanks for the help and Happy New Year!






.

[Embass]

[Embass]

[vitalker]

Originally Posted by ovnis

With that option the behaviour is near than your gif but it seems you don't understand my issue.

What's your scroll speed? Go to Windows' settings -> Devices -> Mouse. How many lines to scroll each time is set? Maybe you and Justin have different settings, that's why you get different behavior?

[vitalker]

Originally Posted by vitalker

Maybe this time my idea will work again (like with razor edits). Here are two variants, both striped, but the stripes are mirrored regarding what we have in razor edits. Left item has default color, right item is set to custom color.

Or it can look like now, but with the stripes.

[cool]

Originally Posted by matt_t

v6.73+dev1231 - December 31 2022

• + Vertical zooming: overhaul, allow more fractional zoom state

Thank you! Perhaps now is the best time to implement a horizontal zoom limit as well? It would be very useful at work:
Now two wide movements with the mouse wheel increase the zoom so that I can see several hours on the timeline. Although, in real work, 99% of my projects fit in 3 minutes.
Yes, I know about the length limit in the project settings, but this limits the entire workspace, not just the zoom.

Also, developers and fellow testers - Happy New Year and Merry Christmas! I wish you happiness, health, financial peace and a peaceful sky above.

[Embass]

[ovnis]

Originally Posted by vitalker

What's your scroll speed? Go to Windows' settings -> Devices -> Mouse. How many lines to scroll each time is set? Maybe you and Justin have different settings, that's why you get different behavior?

Whatever the scrool speed, the issue will remain!

For my needs (a fast zoom which feet exactly to my TCP) The Justin's zoom behavior is worst than my actual zoom behavior!

Edit 2: to tweak "settings -> Devices -> Mouse" doesn't come close to justin's zoom behavior. Could this be due to my type of toothed wheel?

[BartR]

PSEUDO SOLVED

I found what cause the audio issue on my portable installation 6.73+dev1231
just when Reaper is not more in foreground, it stops to get audio.
When Im' back to it, to make ti active again I have to disarm and re-arm the track.

Just a setting I forgot.

[Embass]

[Embass]

[DerTonmeister]

Originally Posted by cool

Yes, I know about the length limit in the project settings, but this limits the entire workspace, not just the zoom.

Yes, and it still leaves plenty of room behind the limit set...

[schwa]

Originally Posted by Embass

screencaps

Fixing, thanks as always and happy new year!

[sockmonkey72]

Happy new year, everyone! (I know, it's off-topic, but if you're feeling generous...)

[souk21]

Originally Posted by matt_t

[*]+ JSFX/ReaScript IDEs: fix loss of X position when scrolling vertically in some instances [t=274248]

Thanks, it seems to work perfectly !

[vitalker]

Originally Posted by matt_t

+ JSFX/ReaScript IDEs: fix loss of X position when scrolling vertically in some instances [t=274248]

It would be also cool, if hints weren't selected by mouse cursor, if it isn't moving. Now if mouse cursor and hint popup overlap, the hint under mouse cursor is selected.

[Justin]

Originally Posted by ovnis

Whatever the scrool speed, the issue will remain!

For my needs (a fast zoom which feet exactly to my TCP) The Justin's zoom behavior is worst than my actual zoom behavior!

Edit 2: to tweak "settings -> Devices -> Mouse" doesn't come close to justin's zoom behavior. Could this be due to my type of toothed wheel?

we'll add another action for the new behavior, and make it the default.. and restore the behavior of the old action.

[ovnis]

Great! Thx you very much!

[vitalker]

Originally Posted by vitalker

It would be also cool, if hints weren't selected by mouse cursor, if it isn't moving. Now if mouse cursor and hint popup overlap, the hint under mouse cursor is selected.

Here is what I am talking about. It doesn't happen all the time, but when it does, it hurts.

[Phazma]

Originally Posted by matt_t

[*]+ Vertical zooming: overhaul, allow more fractional zoom state

Holy cow, this new vertical zooming is a great improvemen and nicely consistent with horizontal zoom response to mousewheel! Thanks and please don't take it away <3

And maybe this is finally the first step towards supporting smooth scroll/zoom? Especially at slow mousewheel movements the zooming and scrolling is still stepped and jumpy instead of fluid pixel-by-pixel interpolation (as known from browsers but also most other apps nowadays, including DAWs).

[ferropop]

Originally Posted by Phazma

Holy cow, this new vertical zooming is a great improvemen and nicely consistent with horizontal zoom response to mousewheel! Thanks and please don't take it away <3

And maybe this is finally the first step towards supporting smooth scroll/zoom? Especially at slow mousewheel movements the zooming and scrolling is still stepped and jumpy instead of fluid pixel-by-pixel interpolation (as known from browsers but also most other apps nowadays, including DAWs).

<3

The hand tool being smooth suggests smooth scrolling is possible in all directions. Inertia on release +20billion.

[PhelixK]

Originally Posted by matt_t

v6.73+dev1231 - December 31 2022

• + Media item lanes: support tcp.lanelabel element in WALTER, to display the name of the currently-playing fixed lane (not visible in default theme, yet)

Lane label
Having this optional element is great, as well as renaming lanes, but I think after testing it, that the tcp.lanelabel element should also have a corresponding background image, just like other labels have. This will allow transparent labels (invisible when empty), or alternatively to create a solid background. Now the lane label is re-using tcp_namebg and also tcp.label.font/color, which may not be desirable with other themes.

Bug?
When changing to normal track or FIPM, the lane label keeps showing last FL selection. Disappears only when adding a new track.




Lanes armed indicator,
I think the coded small dot for armed lanes isn’t always easy to distinguish, especially on bright themes and backgrounds. A small outline could help though. Also, having the indicator to the left extend the space required for the lane panel, which in my case creates an overlap. Ofc. I can fix that overlap -or live with it, however I hope it can be solved in a different way.




Fixed Lane indicator, when collapsed and panel buttons are hidden,
I believe it was already suggested, but again, a kind of symbol or something indicating FL tracks, maybe a simple dot in the empty panel space?

- I suppose we can use the lane label also as an indicator, but then it should always be placed on top.

• + Vertical zooming: overhaul, allow more fractional zoom state

Instantly feels a lot less jaggy, would hate to see this abandoned.

• # Zoom: fix action to toggle tracks to maximum zoom if maximum zoom has been customized [p=2628925]

hmm, toggle action still not working here on mac, anyone else?


oh, and Happy New Year to all of You!

.

[Phazma]

Originally Posted by matt_t

[*] * Includes feature branch: ReaReaRea timestretch mode

Regarding ReaReaRea I did some more testing and it seems to introduce an abrupt change in timbre at some point throughout the stretch. This is most noticeable with heavily stretched percussive material and the change in timbre seems to be soon after the transient, so I assume it is due to ReaReaRea trying to preserve the transient.

Here an example showing this with a snare sample stretched to a rate of 0.05, first with ReaReaRea, afterwards with a comparable algorithm of another software: https://we.tl/t-u88jOzq725

While the preserved transient can be an interesting feature, I am wondering if ReaReaRea could have a setting that allows it to stretch the sound with a more gradually evolving timbre (at the expense of the transient becoming more smeared) like in the second part of my audio file?

Sorry if my testing and explanations are a bit vague, I hope my feedback is still useful despite my lack of technical knowledge about algorithms.

[ovnis]

Originally Posted by Phazma

Holy cow, this new vertical zooming is a great improvemen and nicely consistent with horizontal zoom response to mousewheel! Thanks and please don't take it away <3

The new and old zoom behaviour will be in the next release.

Inertia on release +20billion.

+1000

The scrolling could be faster with this option!

Faster the movement of your mouse is when you release the mouse button, longer/faster the intertia remains.

[bolgwrad]

HNY to all x

This mouse mod is a bit inconsistent:

[Justin]

Originally Posted by vitalker

Here is what I am talking about. It doesn't happen all the time, but when it does, it hurts.

ah yeah we can filter those small initial mousemoves

[Justin]

Originally Posted by Phazma

Regarding ReaReaRea I did some more testing and it seems to introduce an abrupt change in timbre at some point throughout the stretch. This is most noticeable with heavily stretched percussive material and the change in timbre seems to be soon after the transient, so I assume it is due to ReaReaRea trying to preserve the transient.

Here an example showing this with a snare sample stretched to a rate of 0.05, first with ReaReaRea, afterwards with a comparable algorithm of another software: https://we.tl/t-u88jOzq725

While the preserved transient can be an interesting feature, I am wondering if ReaReaRea could have a setting that allows it to stretch the sound with a more gradually evolving timbre (at the expense of the transient becoming more smeared) like in the second part of my audio file?

Sorry if my testing and explanations are a bit vague, I hope my feedback is still useful despite my lack of technical knowledge about algorithms.

The ReaReaRea algorithm is very much not intelligent so it's not _trying_ to do anything. But I think I see why this is, let me try some experiments to avoid that repetitive sound

[vitalker]

Originally Posted by Justin

ah yeah we can filter those small initial mousemoves

Thank you, would be great, although I don't touch mouse on the gif.

[Luster]

May I bring up this old FR because it feels related to the zoom discussion:
https://forum.cockos.com/showthread.php?t=191647


Thanks for consideration and a happy new year!

[Tale]

# IDE/gfx.getchar: more windows international keyboard support fixes

FWIW: I can type quotes/accents again, thanks!

[nofish]

Originally Posted by matt_t

v6.73+dev1231 - December 31 2022
[*]+ Vertical zooming: overhaul, allow more fractional zoom state

This seems to have broken SWS Drag zoom vertically (at least) unfortunately:
https://github.com/reaper-oss/sws/issues/1717

I know it's actually on SWS side to keep up with Reaper changes, but if something could be done from Cockos side to un-break it it'd certainly be much appreciated.

[nofish]

^ I think I found the issue:
Seems like it's no longer possible to set intconfigvar "vzoom2" (meaning it has no effect when it's set), so this line breaks:
https://github.com/reaper-oss/sws/bl.../Zoom.cpp#L283

The code SWS uses to set configvars:
https://github.com/reaper-oss/sws/bl...ty/configvar.h
https://github.com/reaper-oss/sws/bl.../configvar.cpp

[Phazma]

Originally Posted by matt_t

[*]+ Vertical zooming: overhaul, allow more fractional zoom state

I have noticed that on big track sizes the zoom is more jumpy (less "fractional") than on small track sizes.

Here a video that shows the current behavior: https://vimeo.com/786986751

As the video shows, it seems that when the tracks are around half screen height the zooming becomes noticeably more stepped.

Would be great if the same fine resolution as in small tracks would be kept regardless of track size.

[PhelixK]

Originally Posted by Phazma

I have noticed that on big track sizes the zoom is more jumpy (less "fractional") than on small track sizes.

Here a video that shows the current behavior: https://vimeo.com/786986751

As the video shows, it seems that when the tracks are around half screen height the zooming becomes noticeably more stepped.

Would be great if the same fine resolution as in small tracks would be kept regardless of track size.

I have the same behavior here as in your example, where for some reason there are larger jumps after half height is reached (we also seem to have roughly the same system).

Interestingly, if I use this action on a single selected track, it's nicely floating over the entire screen height. But then again, if more tracks are selected, the vertical zoom effect loses its finesse.




.

[Phazma]

Originally Posted by PhelixK

I have the same behavior here as in your example, where for some reason there are larger jumps after half height is reached (we also seem to have roughly the same system).

Interestingly, if I use this action on a single selected track, it's nicely floating over the entire screen height. But then again, if more tracks are selected, the vertical zoom effect loses its finesse.




.

That's true! Interesting...

Btw have you tried the action "Adjust selected track heights a little bit (MIDI CC relative/mousewheel)"?

That one actually allows to zoom very smoothly (and on several selected tracks)! But the response to mouse inertia is kind of weak, you need to swipe the mousewheel very aggressively to have it zoom a lot...

I have tried to improve this by adding some x2 modifiers but then it becomes also more stepped again.

If this smooth zooming like in "Adjust selected track heights a little bit (MIDI CC relative/mousewheel)" existed for the standard vertical zoom, with more accelleration for faster mouse movements (and a "reversed" action) it would be perfect, at least for me.

[PhelixK]

Originally Posted by Phazma

That's true! Interesting...

Btw have you tried the action "Adjust selected track heights a little bit (MIDI CC relative/mousewheel)"?

That one actually allows to zoom very smoothly (and on several selected tracks)! But the response to mouse inertia is kind of weak, you need to swipe the mousewheel very aggressively to have it zoom a lot...

I have tried to improve this by adding some x2 modifiers but then it becomes also more stepped again.

If this smooth zooming like in "Adjust selected track heights a little bit (MIDI CC relative/mousewheel)" existed for the standard vertical zoom, with more accelleration for faster mouse movements (and a "reversed" action) it would be perfect, at least for me.

Thanks, I haven't actually tried customizing the selected + little bit -modifier until now, and yes with 4x it's very fine, and to me, the inertia effect actually feels as good as without the little bit.

And totally agree, me too would prefer this zoom behavior by default (without selected track), and I also think this will be the case for the majority of mac users who use a Magic Mouse.

[Phazma]

Originally Posted by PhelixK

Thanks, I haven't actually tried customizing the selected + little bit -modifier until now, and yes with 4x it's very fine, and to me, the inertia effect actually feels as good as without the little bit.

Playing around a bit with modifiers and actions I have noticed that adding two 2x modifiers to "adjust selected track heights a little bit" makes it behave just like the normal "adjust selected track heights" action and vice versa adding two 0.5x modifiers to "adjust selected track heights" makes it behave like the "little bit" action. So it is basically the same action but multiplying incoming mousewheel/CC data with a different factor resulting in finer but slower or jumpier but faster zoom.

What I believe should happen to the vertical zoom action is that it behaves like the "adjust selected track heights" action but the incoming mousewheel/MIDICC data under the hood should be modified by a variable factor, depending on how fast the mouse is scrolled. Slow and steady mouse movements should keep the factor at around 0.25x and a faster mouse swipe should be accelerated, depending on how strong the swipe is from 0.25x up to 1x (or more?) and then fade out with inertia from 1x back to 0.25x.

That would allow (at least for Magic Mouse users) to have both very fine, pixel-by-pixel zooming resolution and also the possibility to go from minimum track height to maximum track height with just one slightly stronger mousewheel movement.

Same applies to horizontal zoom and vertical/horizontal scroll obviously.

Originally Posted by PhelixK

And totally agree, me too would prefer this zoom behavior by default (without selected track), and I also think this will be the case for the majority of mac users who use a Magic Mouse.

And I do believe that (despite many critics) the majority of mac users actually does use a Magic Mouse (or trackpad), as Apple users tend to stay within the ecosystem and buy 1st party accessories proposed directly by Apple that are well integrated with the OS.

[PhelixK]

Originally Posted by Phazma

Playing around a bit with modifiers..

I think your findings makes a lot of sense, and if not as default behavior, then as an advanced option for multitouch (mouse). I mean why not, some specific macOS settings are already offered in REAPER, round corners for macOS12+, retina drawing, macOS dark mode theming