v5.79pre17b - April 15 2018

[mabian]

v5.79pre17b - April 15 2018
# MIDI editor: clicking to activate an already-active item in track list will auto-zoom
# MIDI editor: simplify open-zoom logic (do not auto-zoom when opening via arrange, unless the item clicked is already the active item in editor)

v5.79pre17 - April 14 2018
# MIDI editor: improve auto-zoom behaviors more

[EvilDragon]

Selecting items via arrange (single-click or marquee) doesn't scroll to them, though... So it's still not as good as pre14 in this regard Here's the reason why:




We just end up with MIDI editor empty far too many times (in case MIDI items are apart so that the ones we're activating/making visible and/or editable are outside of current MIDI editor viewport) and needing to manually scroll it. It shouldn't be like that... Definitely it'd be nice to have an option to scroll.


Oh well, looking forward to 5.80pre1.

[Futur8me]

I just got another warning using the 579pre17b-1cc18 64 bit..,

"reaper_host_i386" is not optimized for you Mac.
This app needs to be updated by its developer to
improve compatibility.

.

.

.

[musicbynumbers]

Hi devs, some great changes regarding midi editor, thanks!

There's a issue whereby closing the midi editor (when docked to bottom half of arrange page) forces the arrange page to automatically scroll right back to the top of the arrange again.

If you get time, could you look at trying to make the arrange keep its vertical scroll position, even just roughly would be fine thanks!Thanks!

[vitalker]

Originally Posted by musicbynumbers

If you get time, could you look at trying to make the arrange keep its vertical scroll position, even just roughly would be fine thanks!Thanks!

And here is the short video why it could be improved.

[MorkV]

Yes... It would be good to add options "lock midi editor v/h zoom(positions?)"

[ovnis]

Selecting items via arrange (single-click or marquee) doesn't scroll to them, though...

Same thing, here . Now, I have to click more time for the same result. If it's an intentional behaviour, how is it supposed to improve our workflow ?

EvilDragon, 48 inch screen ?

[vitalker]

Originally Posted by ovnis

EvilDragon, 48 inch screen ?

No, he has two monitors.

[tusitala]

I tested this last version and personally it works pretty much as I was hoping to.

Thank you very much!!

[EvilDragon]

Originally Posted by ovnis

EvilDragon, 48 inch screen ?

Yep, effectively. 2x 24" monitors, at 1920x1200.

Originally Posted by tusitala

I tested this last version and personally it works pretty much as I was hoping to.

Thank you very much!!

So, the example I posted above, wouldn't annoy you to no end? It literally makes no sense.

[ovnis]

So, the example I posted above, wouldn't annoy you to no end? It literally makes no sense.

Totaly. Lake of scrolling at the first click seems like a Monty Python's absurd comedy when the clicked midi item doesn't display at all inside the midi editor.

[Justin]

Originally Posted by Futur8me

I just got another warning using the 579pre17b-1cc18 64 bit..,

"reaper_host_i386" is not optimized for you Mac.
This app needs to be updated by its developer to
improve compatibility.

That's apple's stupidity, warning on 32-bit apps... :/

[Justin]

Originally Posted by EvilDragon

Selecting items via arrange (single-click or marquee) doesn't scroll to them, though... So it's still not as good as pre14 in this regard Here's the reason why:




We just end up with MIDI editor empty far too many times (in case MIDI items are apart so that the ones we're activating/making visible and/or editable are outside of current MIDI editor viewport) and needing to manually scroll it. It shouldn't be like that... Definitely it'd be nice to have an option to scroll.


Oh well, looking forward to 5.80pre1.

Ah OK, that's not opening though (that's the selection-change mirroring), separate code. For 5.80pre1...

[EvilDragon]

Originally Posted by Justin

Ah OK, that's not opening though (that's the selection-change mirroring), separate code. For 5.80pre1...

Eagerly awaiting!

Again, I think I'm fine with current behavior when OPENING.

[FnA]

Originally Posted by musicbynumbers

Hi devs, some great changes regarding midi editor, thanks!

There's a issue whereby closing the midi editor (when docked to bottom half of arrange page) forces the arrange page to automatically scroll right back to the top of the arrange again.

If you get time, could you look at trying to make the arrange keep its vertical scroll position, even just roughly would be fine thanks!Thanks!

I wanted to bring it up too.

I notice a number of posts lately where people are finding the docker is good to avoid getting in to using pins in the windows. Mostly referring to the mixer, but it affects midi editor and other Windows too. The commands to dock/undock can then bring the window to the front, but this procedure causes the scroll too. SWS: undo zoom will not necessarily bring the scroll back to where it was.

https://forum.cockos.com/showthread.php?t=193808

[Justin]

Originally Posted by musicbynumbers

Hi devs, some great changes regarding midi editor, thanks!

There's a issue whereby closing the midi editor (when docked to bottom half of arrange page) forces the arrange page to automatically scroll right back to the top of the arrange again.

Is this also an issue in 5.78, or is it new in 5.79pre?

[FnA]

I don't know if mbn found anything new in this pre cycle, but after I made the report I linked to in my last post here, I stumbled across a post he made about the issue even before my report was posted.

I think we're talking about the same thing. Plugging an old issue. Sry. Edited my bug thread with "tested with 5.78 on Windows 7x64".

[snooks]

How about...

1) 2 options for disable auto-zoom/auto-scroll, always without exception*
2) some lovelier default behaviour, to be cajoled into existence by concerned parties
3) ReaScript callback on MIDI item/track open/change with source of action (Track List, arrange), MediaItem_Take(s)** and current viewport (plus queryable viewport).

** this could be a good opportunity to get/set editable MIDI takes via ReaScript too.
* if options are making anybody feel a bit queasy, maybe have these attributes accessible by API only, for custom startup scripts to be used in conjunction (or not) with (3).

I think this way that absolutely everybody should be ecstatically happy because everything will be possible but nothing has really changed apart from some polish of existing behaviour.

[mccrabney]

alriiight i'm finally back from my weekend away from REAPER

EDIT - i was wrong, see below. first impressions upon opening multiple items in REAPER is that my requests have been answered via the "make secondary items editable when opening from arrange view" and "editability linked to selection" ... thanks so much for doing this.

so, it seems that this issue of having to make different items "active" in the midi editor isn't going anywhere. that's OK, though in my ideal desired behavior, the entire track would be active upon opening one midi item in the editor. i can accept that such a workflow would require too many "deeper" changes that you might not want to mess with.

as such, i will be trying to make my midi tracks look and behave as if all items were active, rather than just one. i notice that non-active midi items don't display the alternating note colors, or the highlight for "last clicked" midi note. is this something that i can fix in theme or settings, or is it a FR?

since i'll be editing non-active items, these visual guides are very helpful. non-active spaces in the midi editor are just greyed out, imo unnecessarily giving up valuable visual queues.

thanks for the attention to detail on all of this.

[mccrabney]

nope, i spoke too soon. this behavior is intermittent, but it still happens. my prefs are shown at the end of the gif. this behavior isn't changed by "active midi item follows selection changes in arrange view"



upon opening the item, full track is editable
after changing active item in midi editor, first midi item becomes uneditable

[mccrabney]

the action "open item in built in editor" behaves differently when triggered by mouse modifier vs by action.

it behaves as expected via mouse modifier.

when triggered by action, it opens the wrong item in focus. see gif, it opens the first track with a midi item instead of the track whose item was clicked/entered.

[introvert]

I'm not sure where the discussion is currently happening regarding ReaSurround changes, but I found a bit of time yesterday to fire up a build and listen to it and hear what it was doing, so I wanted to quickly drop my thoughts here (although they may not be extremely useful).

Overall it seems to have come along really well. I've got two possible issues with it, although one is difficult to confirm:

A. I'm not sure how to send signal to LFE from the panner.

B. There seems to be a small dip when panning from front/back/front along one side of the panner, although I'm in a new room and not fully calibrated so it's possible this is an issue with the placement/relative loudness of my speakers. Can anyone else in a better space check this and report back?

Otherwise, I'm able to send sounds directly out of individual speakers, I'm able to lock two pucks together and automate both of them simultaneously, and in general it seems like it's in much better shape. So thanks to the Cockos team for all the effort on this!

[wjmwpg]

Originally Posted by EvilDragon

Selecting items via arrange (single-click or marquee) doesn't scroll to them, though... So it's still not as good as pre14 in this regard Here's the reason why:




We just end up with MIDI editor empty far too many times (in case MIDI items are apart so that the ones we're activating/making visible and/or editable are outside of current MIDI editor viewport) and needing to manually scroll it. It shouldn't be like that... Definitely it'd be nice to have an option to scroll.


Oh well, looking forward to 5.80pre1.

+1
Came here to talk about this but as usual someone else has beaten me to it and done a better job than I would have.