v5.984+dev1026(a) - October 26 2019

[nofish]

v5.984+dev1026a - October 26 2019

# MIDI editor: fix unintentionally disabled menu items


v5.984+dev1026 - October 26 2019

# Auto-stretch: fix warp marker slope with multiple gradual tempo changes
# MIDI editor: add sine shape to LFO dialog
# MIDI editor: better interpolation of LFO start/end
# MIDI editor: increase width of CC LFO dialog
# Media item import: fix item length when matching tempo on import [p=2195281]
# Media items: when copy/pasting items with auto-stretch at tempo markers enabled, preserve the original play rate [p=2195949]
# Toolbar editor: use toolbar background color for previews

Full changelog / Latest pre-releases

[_Stevie_]

@devs: totally surprised, thaaaaaanks so much for the LFO tool improvements!!!

One little thing: square and parametric don't start at the lower part:



Otherwise, purrrrfect!

[_Stevie_]

Another one regarding the auto stretch feature.
I think Julian already mentioned this issue in the previous pre thread (or maybe it's only related):
http://nextcloud.stephanroemer.net/i...Ck9MYkzsNXo96W

[Edgemeal]

In MIDI Editor the Action List menu item is disabled. The LFO menu item is also disabled but not always, odd behavior.

[deeb]

Regarding timestrech import, could we have a way to import (by dragging) into a sampler with the timestretch applied?

[EvilDragon]

Originally Posted by nofish

# MIDI editor: increase width of CC LFO dialog

I don't understand this, devs. Why do this when you could use the same terminology you used in automation item LFO in the old dialog size (Amp skeq, Freq skew)?

Why not try to have some consistency?


Also, now that MIDI CC LFO has sine waveform, don't you think automation item LFO should follow suit?

[vsgrt]

Originally Posted by EvilDragon

I don't understand this, devs. Why do this when you could use the same terminology you used in automation item LFO in the old dialog size (Amp skeq, Freq skew=?

Why not try to have some consistency?

Strongly agree with this. Similar functionality should be similarly named and follow a reasonably similar design.

[bFooz]

Originally Posted by EvilDragon

I don't understand this, devs. Why do this when you could use the same terminology you used in automation item LFO in the old dialog size (Amp skeq, Freq skew)?

Why not try to have some consistency?

"Consistency is one of the molecules of the Design DNA":

https://uxdesign.cc/design-principle...y-6b0cf7e7339f

[schwa]

The significant difference in functionality is that the automation item dialog has a "cycles" control to define the LFO number of cycles in the entire item, where the CC LFO is tempo-synced and has "cycles per grid" instead. "Cycles per grid" is long enough text that the dialog has to be wider to accommodate it. The wider dialog can also accommodate un-abbreviated "amplitude skew" and "frequency skew" so given the option between abbreviating that text simply for consistency with another dialog, or using the entire word, we chose to use the entire word.

There are plenty of other legitimate suggestions to make about user-facing consistency between similar functionality in different parts of REAPER, and plenty of new functionality in this dev cycle to talk about, so I hope we don't spend a bunch of posts in this thread talking about that particular dialog text!

[EvilDragon]

Sure, I guess. Why not make all the dialogs follow the theme colors then? For somewhat proper visual consistency.

[bFooz]

LFO shapes and starting points:
I'd expect (as someone mentioned previously) that all LFO shapes start at the same logical point, even if that be different from what is mathematically correct. That means "square" should have phase shifted to 50 and "parametric" should have phase shifted to 25.

List order of shapes:
Logical order would be from the smoothest to the most angular:
sine - parametric - triangle - saw - square

Name "parametric":
Is there any special parameter that can be adjusted? I haven't found any. If there is, it needs to be make clearer. If there isn't, the name is confusing.

"Phase" scale:
I'd expect it to go from 0 degrees to 180 degrees. Now it goes from 0 to 100, which is confusing.

Cycles per grid:
"per grid" is understood that if I change the grid, the curve changes. But I changed the grid in the MIDI editor (1st dropdown at the bottom) and the curve stayed the same. Why not call it "Frequency" (there is also "frequency skew").

Cycles:
Is there a need for such a small cycle number as 1/256 on the slider? It could be made that the ultra-low/high numbers can be always typed in. And put only the most used range on the slider.

Baseline:
current -100 to 100 seems confusing. Better would be to rescale to 0-100 with 50 as a central value. -100..100 would be good for pan, where the range is really mirrored. Otherwise, for volume, expression, modwheel, 0..100 is better.

Amplitude:
I don't understand the point of going bellow zero when we have a phase slider, which accomplishes the same thing when set to 50%.
Don't understand the point of going above 100.
=>The slider range should be clamped to 0..100.

Order of sliders:
frequency - baseline - amplitude - phase - freq skew - amp skew - pulse width
This is based on probable usual order of operations needed, would need more user research though, especially the order of the first 4 parameters. "Pulse width" should be definitely at the end since it is active only with one shape.

"None" shape:
What should happen when this is selected? Currently nothing happens and the previous curve stays at previous shape+settings.

Typing in numbers:
you use 3 types of behavious across the software:
1) type in and the slider and effective value is changed immediately (ReaEq)
2) type in and the value is changed after some timeout (here, the most confusing)
3) type in and the value is not changed until submitted, e.g. by enter (JSFX)
That is a broad inconsistency which would need a small overhaul. The best option is 3).

Bug:
typing in numbers into some textboxes resets the shape to "none".

These suggestions would also apply to the AI LFO.

Plus these colors and "Pulse width" glitch (Win7 x64)


Most of these should be further user-tested. I most likely did not consider all use cases.

[nofish]

Originally Posted by bFooz

2) type in and the value is changed after some timeout (here, the most confusing)

There's actually a pref. for this behaviour (Keyboard/Multitouch -> Commit changes to some edit fields after 1 second of no typing), but it seems it's not obeyed here (i.e. with this pref. off it's still applied after timeout).

[bFooz]

Check your aligments:

(the window behind is the dynamic split for comparison)

what's wrong:
- label's vertical position (text baselines not aligned)
- the fader "rift" 1 px too high, not centered in the slider frame
- textbox height and alignment




For comparison:
- dynamic split slider after photoshop-shifting its textbox position (which still needs to be fixed!) is aligned well

[Klangfarben]

I just wanted to chime in and say thanks so much for adding sine. Really appreciate it! (and for wading through all these comments )

[Reflected]

I just find these updates worthless when I can't use the midi editor properly...
I still didn't get an answer why can't we just set our own actions for right click in the velocity lane regardless of the piano roll and whatever else?
why can't we use single clicks to edit in the midi editor?

does making and lfo tool more important than the basic of the basics of midi editing workflow?

I really can't stand this midi editor,...way too technical and unintuitive.
many many people already show interest
I really like to know what's the reason...and if this is something that is on the to do list.

[EvilDragon]

I don't think devs are going to appreciate your tone which is becoming more and more confrontational and even insulting. Chill, maybe? Devs don't divulge their todo lists to us, and they don't need to explain their decisions on why Reaper is the way it is to us.

Originally Posted by Reflected

does making and lfo tool more important than the basic of the basics of midi editing workflow?

For this round of dev builds, yes that is what is supposed to be tested. schwa has a good point above. If you don't have anything useful to say about what's happening in the dev builds (rather than what's in your dreams), you are not obliged to write here.

[Klangfarben]

Originally Posted by Reflected

why can't we use single clicks to edit in the midi editor

Have you made a feature request in the Feature Requests forum with the changes you would like? That's generally the accepted protocol when asking for changes not related to the current pre-release. That also allows your request not to get lost amongst many other posts that are discussing pre-release changes unrelated to your request.

[Reflected]

they ignore my posts and requests anyway.
this isn't just my lost not having basic behavior to work properly.

seriously 10 years waiting for single clicks to work?!
I'm looking for updates regarding midi day by day...and it's just not there!

blah..
I'm super super disappointed

[Klangfarben]

Originally Posted by Reflected

they ignore my posts and requests anyway.

Just make an official request in Feature Requests. At the end of the day, it's a worthwhile request. Maybe they will implement it, maybe they won't. But at least you've done it the proper way.

[Ivannn Bennnettt]

Originally Posted by Reflected

seriously 10 years waiting for single clicks to work?!

What do you mean?

[Reflected]

Originally Posted by Ivannn Bennnettt

What do you mean?

that it is impossible currently (for 10 years already) to:
use single click to change a single velocity without dragging
use single right click to remove a single note without dragging

there are other similar very basic editing behaviors for midi editing that are missing but these are so basic that not having these feels like this software is broken.

[EvilDragon]

To you and maybe some others, but not everyone.

[deeb]

Originally Posted by EvilDragon

To you and maybe some others, but not everyone.

i guess this can be applied on everything else.

[foxAsteria]

Hmmm. If I spent a decade waiting for something that was never promised and never came, I'd think about adjusting my expectations...

[Reflected]

Originally Posted by EvilDragon

To you and maybe some others, but not everyone.

if 100% of producers friends in real life think the same (and all of them have more then 15 years of experience with many daws), I take you as a weirdo and the devs should too but they just don't know because as it seems to me, they don't have much experience in midi writing as well...

too bad for me and for my friends and for the devs that you have too much spare time at your parents house, posting things with weird workflow behaviors that ruin the program which cause me to lose hope in this daw and my friends sure won't join as well.

just too bad because the audio part of this daw is my fav...

Originally Posted by foxAsteria

Hmmm. If I spent a decade waiting for something that was never promised and never came, I'd think about adjusting my expectations...

I just did...2 days ago, thanks to the devs and Evil Dragon...

No expectations for best midi editor at all (not even close)...Actually, I'm no gonna use the midi editor of reaper to create new ideas anymore.

[EvilDragon]

You should stop with stupid conjenctures about people you have no idea about. Parents house, really? If you have to resort to ad hominems like that you really need to grow up. And yes, after 10 years, obviously adjust your expectations.

But this is not about me or you or "100% of your producer friends". How many OTHER Reaper users do you think there are out there, and they use Reaper's MIDI editor just fine. Hmmm?

[schwa]

Originally Posted by Reflected

use single right click to remove a single note without dragging

When using the MIDI editor right-drag mouse modifier "delete notes/CC immediately (suppress right-click context menu)", events are deleted immediately in the release version of REAPER. It doesn't quite work right in the +dev builds (the screen is not refreshed until mouse-up), but this is fixed for the next build.

[EvilDragon]

The way I understand Reflected regarding the single click, he also wants to have left mouse click available for the same stuff. Like, clicking anywhere directly on the velocity stick would immediately change the value. Right now it requires you to drag the mouse a bit, which is apparently a huge problem for certain workflows?

Comparison:




Notice how you can also adjust velocity stick from either side of it (in Reaper only from right side, but not from left side). Works the same way for CCs in FL.


It's not an unreasonable request (it could have been better worded without alluding to "broken software" etc.), but only you can tell if this is possible considering how you, the devs, implemented Reaper's mouse modifier system.

[EvilDragon]

There's one more thing to ask here. If the mouse modifier context is called "left click/drag", why do some/most of the actions available for that context actually do anything only on drag, but nothing on click? This is clearly evidented in the above GIF.

Context is MIDI CC lane left click/drag, default action "Edit selected CC events if any, otherwise draw/edit". Same default action is set for MIDI CC event left click/drag mouse modifier. So edit only happens when you start dragging, but it never happens on a single click.

[Ivannn Bennnettt]

Originally Posted by Reflected

that it is impossible currently (for 10 years already) to:
use single right click to remove a single note without dragging

I use left double-click for that

Originally Posted by Reflected

that it is impossible currently (for 10 years already) to:
use single click to change a single velocity without dragging

works left double-click as well
(it's one more click than single click)

[EvilDragon]

Yes and he explicitly wants to use a single click, not a double click. So, your point?

[schwa]

Maybe this was discussed earlier (this is the problem with so much noise in the prerelease threads, stuff gets buried!) but one potential issue with immediately editing on left-click is that with the default mouse modifier (draw/insert), you'd no longer be able to deselect events by clicking in empty space in a CC lane. It seems OK to edit on click, but maybe there needs to be an additional preference to support inserting on click?

[EvilDragon]

Originally Posted by schwa

but one potential issue with immediately editing on left-click is that with the default mouse modifier (draw/insert), you'd no longer be able to deselect events by clicking in empty space in a CC lane.

True, and that's exactly how it is in FL. It seems they value faster event input and editing over how fast you can deselect events. It's a valid workflow, I suppose.

I think a better preference would be to toggle deselecting events on single click or not (this for MIDI CC lane context only). Otherwise just do edit or insert normally. This would match the FL behavior.


Another behavioral issue we have is the "Linear ramp CC events" mouse modifier. This one needs to be able to draw linear ramps from scratch, not just edit existing CCs. Maybe a new mouse modifier that does both draw and edit?

[_Stevie_]

I personally deselect MIDI notes when having the eraser selected (ALT+click).
Chances are to high to insert a new note on single click when using draw/edit.
EDs suggestion seems a good one, though.

[EvilDragon]

It's really Reflected's suggestion. Just worded better, maybe

[foxAsteria]

Originally Posted by schwa

one potential issue with immediately editing on left-click is that with the default mouse modifier (draw/insert), you'd no longer be able to deselect events by clicking in empty space in a CC lane.

Personally I don't like that feature at all. I'm always deselecting by accident there when I can reliably do so just above, on the piano roll.

I'm used to dragging in the CC lanes to "chop off their heads" by now but it's always felt a bit fiddly. If nothing is selected, single click to edit single points makes the most sense to me (would be awesome if they were highlighted on mouse-over to indicate that as well).

[mccrabney]

^ i feel the opposite. after years of working in Arrange, where clicking empty space deselects items, i expect the same behavior in all other areas as well -- CC, velocity, and AI.

[EvilDragon]

So if we get an option to deselect all events when clicking in MIDI CC lane, both sides could be satisfied.

[Reflected]

Originally Posted by schwa

one potential issue with immediately editing on left-click is that with the default mouse modifier (draw/insert), you'd no longer be able to deselect events by clicking in empty space in a CC lane.

currently when left clicking on empty space in the velocity lane it just moves the edit cursor which is another thing that I would never want.
I personally want that the edit cursor in the midi editor will move only from the timeline.
if I would need to move the edit cursor from within the piano roll or cc lane, I would use a Alt / Ctrl / shift + click for that or something else.

Originally Posted by schwa

It seems OK to edit on click, but maybe there needs to be an additional preference to support inserting on click?

many people already asked for freedom on adjusting the mouse modifiers.
it seems that it's almost there, so why not make it completely/fully adjustable? (using scripts for all (not just for some) modifiers and do whatever you wish with right and left click/ drag and whatever..)

[mccrabney]

currently when left clicking on empty space in the velocity lane it just moves the edit cursor which is another thing that I would never want.
I personally want that the edit cursor in the midi editor will move only from the timeline.

^ i feel the opposite. after years of working in Arrange, where clicking empty space (optionally, but by default) moves the edit cursor, i expect the same behavior in all other empty areas as well -- CC, velocity, and AI.

just goes to show how convoluted this gets. supporting every expectation is virtually impossible, but the effort is made...
and then, several pre releases deep, another user comes into the pre-release forum to complain about current dev cycles not applying to their particular desired workflow.