v4.32pre5 - December 5 2012

[EvilDragon]

That's TCP navigator where sliding is possible. ME navigator is missing functionality (as stated in the prerelease log).

[mwe]

Originally Posted by EvilDragon

I disagree with the horizontal scroll there. It's going to be confusing.

It should just be like the navigator in TCP. No scrollbars. Just mouse dragging around with the "focus frame".

This is where my ignorance of MIDI editing leaves me lacking. Would the width of the frame equal the timeline displayed in the editor window?

Edit: Never mind. I haven't tried the TCP navigator till just now. I see your point.

[gofer]

With those track names on the side you can't go very much smaller in height and the main problem remains.

Personally I think I could do with the track list (when functional with selection/activation/visibility and stuff) alone... dock-able to a side of the editor.
Let the navigator be a navigator and the tracklist be a tracklist, so to say. With many tracks, when shown as small as in ED's navigator pic, there ain't much sense in selecting items in it anyway, more so when it shows the whole project length always...

[musicbynumbers]

One thing for later in this development I would love to see worked out is the separation of midi and audio sends so reaper can allow us to send midi to child tracks of a folder and not think it would feedback.

This would allow us to put the midi for say a drum vst on the folder track and the individual outs on child tracks so when we don't need to see the individual tracks we can close the folder.

Currently you have to have the midi on a child track making it awkward to folder up a multi out instrument.

[run, megalodon]

Originally Posted by musicbynumbers

One thing for later in this development I would love to see worked out is the separation of midi and audio sends so reaper can allow us to send midi to child tracks of a folder and not think it would feedback.

This would allow us to put the midi for say a drum vst on the folder track and the individual outs on child tracks so when we don't need to see the individual tracks we can close the folder.

Currently you have to have the midi on a child track making it awkward to folder up a multi out instrument.

Yup, I'd like that to, it makes much more organizational sense.

[Coachz]

please fix midi zoom when opening new midi windows

[Seventh]

Oh wow, exciting stuff! Thanks devs =)

I'd like to point out one thing in the current implementation of the navigator though:

Right now the horizontal zoom is tied to the MIDI editor, while in the original idea the navigator shows all the MIDI items on the track, just like the arrange view navigator.

Also a zoom function for the navigator would be great (right-drag?). If not vertical, at least horizontal to allow focusing on certain items on the track.

[krahosk]

Originally Posted by EvilDragon

I have always HATED the "untitled MIDI item" thing. It is just so long and redundant.



Agreed, we need an option for this. I want an empty item name myself. If I want to name it, I will do so myself. Don't autoname it for me when you can't read my mind!

Agreed.

[jnif]

Originally Posted by musicbynumbers

v4.32pre5 - December 5 2012
+ MIDI editor: added navigator lane (show all MIDI media items in the project)
+ MIDI editor: switch active MIDI media items by clicking in the navigator lane
+ MIDI editor: add MIDI media items to the MIDI editor by selecting via mouse click or marquee
+ MIDI editor: remove MIDI media items from the MIDI editor via alt+click or alt+marquee
+ MIDI editor: secondary MIDI media items are editable when the media item is selected
# MIDI editor: color MIDI media items via right-click
# MIDI editor: mini-TCP view in navigator lane is preliminary (no functionality exists yet)

I'm sorry to say these changes in MIDI editor are really bad in so many ways and on so many levels. I don't know where to start. Should I start reporting bugs? Probably not, because the basic design has so many flaws. I think it would be better to scrap the current MIDI navigator. Think and discuss about what users really need. And what is the best way to get there.

If there is some grand vision behind the current MIDI navigator, please explain it to users. Adding functionality to the mini-TCP is not going to help. There are so many other problems already in the basic concept.

1. The MIDI navigator is not really a navigator. It is a very bad copy of the arrange view. What is the point? Why not just use the arrange view?
2. The location of the navigator is wrong. It can't be in the CC lane. It is a horrible decision.
3. The MIDI navigator wastes a lot of screen real estate.
4. There are already many (maybe too many?) ways to control the visibility/editability/activation of MIDI items. Arrange view, MIDI editor's contents menu, Track/item list in MIDI filter window, Track manager, double-click in PRV. Why do we need yet another way, the MIDI navigator? If you think it is going to replace all (or some of) the other methods and be the ultimate solution, then please explain how? I can't see it based on the current implementation. It looks like it would be in many ways worse than the already existing methods.
5. "Mixing" the item selection operation to the item visibility/editability control is very confusing.
6. There is no clear indication of item visibility/editability status in the MIDI navigator.
7. The item color selection dialog is in the right click sub-sub menu. Really slow and bad usability.

jnif

[EvilDragon]

That was a bit harsh, no? I do think the MIDI navigator could be useful, but only if it's working similarly to TCP navigator - so we can see the whole project in it, unlinked to ME zoom level. And of course, no item names for thinner item display.

[Dstruct]

Pretty weird solo bug. See attached file.

-> play


=> fine


-> solo/unsolo track 1 many times while playback

=> not fine. track 2 should always be muted if track 1 is soloed. somehow it isn't (because of the track 1 send to track 2)


FIXED (5.15pre4)

[swiiscompos]

Some ideas for the midi navigator:

1_ As ED said, the midi navigator (MN) zoom has to be unlinked to the midi editor (ME) zoom level, with his own scroll bars

2_ It would be nice if we could see the zone that appears in the ME as a rectangle (maybe with a lighter color) in the MN.

3_ something like shift+click in the MN would move this rectangle to the clicked point and of course change the view in the ME. That would be an easy way to change precisely the view in the ME keeping exactly the same zoom level.

4_ And something very useful would be the ability to drag a rectangle in the MN (maybe with alt+click), which would become the new view in the ME. This is surely hard to code... but we know you can do it!

[jnif]

Originally Posted by EvilDragon

That was a bit harsh, no? I do think the MIDI navigator could be useful, but only if it's working similarly to TCP navigator - so we can see the whole project in it, unlinked to ME zoom level. And of course, no item names for thinner item display.

But the TCP/arrange view navigator is a totally different thing compared to the current MIDI navigator. You can't select items in the TCP navigator. You can't change/control any item properties. It is basically only a tool for zooming and scrolling the arrange view (that is why it is called 'Navigator'). The MIDI navigator seems to be designed to a totally different purpose. It is more like a copy of the whole arrange view + TCP added with MIDI item visibility/editability controls, not a navigator at all.

If I, you, and other users like to have a navigator in the MIDI editor then let's focus on that and scrap the current design which is something totally different.

But what I'm really worried about is the basic concepts of editing multiple MIDI items/tracks. Focusing development now to the navigator (if it would be designed only for scrolling and zooming) would not be wise because the basic multi item/track editing has still lots of issues that need to be solved. MIDI editor navigation (scrolling/zooming) features can be added separately from the editing features.

jnif

[swiiscompos]

But the TCP/arrange view navigator is a totally different thing compared to the current MIDI navigator. You can't select items in the TCP navigator. You can't change/control any item properties. It is basically only a tool for zooming and scrolling the arrange view (that is why it is called 'Navigator'). The MIDI navigator seems to be designed to a totally different purpose. It is more like a copy of the whole arrange view + TCP, not the navigator at all.

If I, you, and other users like to have a navigator the MIDI editor then let's focus on that and scrap the current design which is something totally different.

jnif

The best would be to use the midi navigator as a navigator, like the tcp navigator, and as an item "selector" or "activator"...

[jnif]

Originally Posted by swiiscompos

The best would be to use the midi navigator as a navigator, like the tcp navigator, and as an item "selector" or "activator"...

But it wastes too much screen real estate when used as an item selector/activator tool. Especially when working with multiple tracks. It can't be the only way to manage item/track visibility/editability/activation. We would still need something like the track/item list in the MIDI filter window.
So, there would be a lot of "feature overlap" between arrange view and MIDI navigator, and between MIDI filter and MIDI navigator.

This could lead (again) to a situation where new methods are added for managing MIDI item visibility/editability/activation but none of those methods work really well. Currently in v4.31 it is already a mess. And this new MIDI navigator looks like it would add even more confusion to the already existing mess.

jnif

[j79]

I dont think it necessarily needs to function the exact same way as the tcp-navigator...i understand that there is some concern of consistency involved here, but it is a different thing after all.

I always work with the midi-editor taking up the whole screen...so the ability to select, move and create items and having access to vsti's, fx and faders directly from the midi-editor would be an awesome addition to me. I agree with a lot of the issues raised, but i actually think that this is heading in the right direction.

I dont agree on the need to keep the navigator limited to the same functionality of the tcp-navigator...not at all. Why should we, its a different thing isnt it?

[jnif]

Originally Posted by j79

I always work with the midi-editor taking up the whole screen...so the ability to select, move and create items and having access to vsti's, fx and faders directly from the midi-editor would be an awesome addition to me. I agree with a lot of the issues raised, but i actually think that this is heading in the right direction.

So, why not copy the arrange view + TCP directly to the MIDI navigator?
It might be a big waste of development time and resources to implement TCP controls and arrange view features again in the MIDI navigator. And if there will be some MIDI specific mini-TCP controls in the MIDI navigator, like MIDI patch/instrument selector, then many users would like to have those same features added also to the arrange view TCP.

And what is the difference between "midi-editor taking up the whole screen with MIDI navigator visible" and "MIDI editor without MIDI navigator docked above arrange view"?

jnif

[Mercado_Negro]

Originally Posted by jnif

I'm sorry to say these changes in MIDI editor are really bad in so many ways and on so many levels. I don't know where to start. Should I start reporting bugs? Probably not, because the basic design has so many flaws. I think it would be better to scrap the current MIDI navigator. Think and discuss about what users really need. And what is the best way to get there.

If there is some grand vision behind the current MIDI navigator, please explain it to users. Adding functionality to the mini-TCP is not going to help. There are so many other problems already in the basic concept.

1. The MIDI navigator is not really a navigator. It is a very bad copy of the arrange view. What is the point? Why not just use the arrange view?
2. The location of the navigator is wrong. It can't be in the CC lane. It is a horrible decision.
3. The MIDI navigator wastes a lot of screen real estate.
4. There are already many (maybe too many?) ways to control the visibility/editability/activation of MIDI items. Arrange view, MIDI editor's contents menu, Track/item list in MIDI filter window, Track manager, double-click in PRV. Why do we need yet another way, the MIDI navigator? If you think it is going to replace all (or some of) the other methods and be the ultimate solution, then please explain how? I can't see it based on the current implementation. It looks like it would be in many ways worse than the already existing methods.
5. "Mixing" the item selection operation to the item visibility/editability control is very confusing.
6. There is no clear indication of item visibility/editability status in the MIDI navigator.
7. The item color selection dialog is in the right click sub-sub menu. Really slow and bad usability.

jnif

What's the point? In my case, it is extremely helpful and it fits my needs 100% because it is exactly that, a copy of the arrange view, a mini copy. I always work with the MIDI Editor in full screen mode so having a mini version of the arrange speeds up my workflow because I don't have to go back and forth (close/open ME).

It doesn't make sense to have it there in a CC lane? Yes, probably (though we can still argue about that because depending on what's coming in the next builds, people could have different versions or "views" of the navigator, whoknows).

[Justin]

Originally Posted by EvilDragon

Passively noticed a bug:


When I assign a keyboard command to the action "Virtual MIDI Keyboard: Send all input to VKB", it can be used only to turn this action on, it cannot be used to turn it off. Kinda makes it useless then.

I presume that "all keyboard input" in that case should be all keys EXCEPT the assigned keyboard combination for that action!

Hit ESC...

[j79]

When it comes to controls i am not imagining a full-fledged channelstrip in the midi editor. I small knob to adjust volume, a button to open fx-chains and the kind of "editing-facilities" thats already halfway there.

Collaps the things so its only visible on selected tracks maybe.

Waste of development time and ressources? Not to me...who decides that? And the argument that we should not implement something useful (to me at least) because someone else might want the same functionality elsewhere, is one i dont buy.

If someone else want it elsewhere too, its probably because its somewhat useful to them

And what is the difference between "midi-editor taking up the whole screen with MIDI navigator visible" and "MIDI editor without MIDI navigator docked above arrange view"?

Midi-navigator would take up much less space...the reason i work with the midi-editor full screen is that i need the space. A midi-navigator with this added functionality would take up much less space than a useful view of the arrange, and it would enable me to do everything from one window.

[jnif]

Originally Posted by Mercado_Negro

What's the point? In my case, it is extremely helpful and it fits my needs 100% because it is exactly that, a copy of the arrange view, a mini copy. I always work with the MIDI Editor in full screen mode so having a mini version of the arrange speeds up my workflow because I don't have to go back and forth (close/open ME).

But it is not a mini copy of the arrange view. It looks like they have implemented all the features almost from scratch. There are massive amounts of arrange view features missing.

It would be much better to have real copy of the arrange view and TCP in the MIDI navigator if this is what users really want. I think it would be good. But the current MIDI navigator is very very far from a real copy of the arrange view.

jnif

[jnif]

Originally Posted by j79

Midi-navigator would take up much less space...the reason i work with the midi-editor full screen is that i need the space. A midi-navigator with this added functionality would take up much less space than a useful view of the arrange, and it would enable me to do everything from one window.

Are you sure about that?
Remove the main toolbar and timeline/ruler from the arrange view and it is almost exactly the same size as the MIDI Navigator.
And arrange view supports "compacted folders". So, the arrange view can easily be a lot smaller than the MIDI Navigator.
And if there will be some super small track heights implemented in the MIDI Navigator, then those same track heights should be available also in the arrange view.

jnif

[Lawrence]

Try this. I did it last night but decided not to post the pictures.

1. Take something like PT and load a midi project with about 25 tracks. Load the same midi project in Reaper. Now detach and maximize the midi editors.

In PT what you'll see in a track list for the midi items (tracks) with lots of empty space to spare in the list. In Reaper with the current design you'll have to steal vertical space to only see about 1/2 the tracks in the navigator, and will have to do a fair amount of scrolling. Less octaves to view at the same note height.

2. Now dock both midi editors and size the arrange splits at the same place.

Same thing. You still see all the midi tracks in the PT track list but to have any kind of editable space in the Reaper editor with a controller lane and a list in the navigaator, you only see about 3 tracks in the navigator. Same thing as relates to workable note height and available edit space in the midi editor.

Anyway, I like the Reaper main navigator but this one seems to not be a good design, imo, to serve the purposes that it appears to be heading towards serving.

JNif's words were a bit too harsh but I agree, I think this is a bad design in general. I think if the idea is to be unique, re-invent the wheel, it may not work so well in this case.

[Evan]

Thanks for the continued MIDI improvements... looking very exciting!

I too don't like the current placement (i.e. inside the CC list) of the new navigator. But getting the functionality and workflow nailed down is more important at this stage.

As the MIDI editor gets more features, I am feeling less and less comfortable with it looking like a dialog window (with just a small 'x' button). Dialog windows are usually meant for brief user interactions. I would like to see normal minimize/maximize buttons. And double clicking on the title bar could turn the editor into a title-bar only compact window.

[schwa]

"Navigator" was the wrong name for the new MIDI editor lane. We should have called it "Selector" or something like that.

The intent is to let the user easily see, and change, which MIDI media item is active, and which other items are displayed/editable in the MIDI editor.

One major issue is that there are many ways to to work with MIDI in a project.

Some users will have various MIDI media items at different places on the timeline, but only on one or two tracks. For these users, the basic idea of the new MIDI editor lane, as implemented, can be made to work. They will be able to choose which media items to work with, in a fairly straightforward manner. (Leaving aside, for now, the question of where exactly the new lane should be displayed.)

Other users will have full-project-length MIDI media items on many tracks. For these users, the current implementation will not work. These users need a narrow, vertical list of tracks, that they can use to choose which tracks to work with.

Other users will have media items at different places on the timeline, on many tracks. They will also need a narrow, vertical list of tracks, which can be used to choose what is displayed in the editor. The selector lane would then show only those tracks, and can then be used to choose which media items to work with.

For simple navigation around the project, it makes more sense to extend the existing project navigator (not the new MIDI editor functionality), so that you can use it to zoom the MIDI editor. But navigation is separate from choosing what is displayed and edited. For example, in an orchestral composition with full-project-length MIDI media items, the user might want to edit track 1 and track 48 together, and ignore the tracks in between. Or, the user might want to see bars 2-4 from track 3 next to bars 4-8 from track 12. What we are currently working on is display, selection, and editability, as opposed to navigation.

Regarding the current proliferation of ways to choose what is displayed in the MIDI editor -- that's what we are trying to fix. A simple, visual way to make these selections can take the place of the MIDI filter window (which only shows the media items you have already loaded into the editor) or the Contents menu (which shows everything in the project, but is cumbersome to use).

[EvilDragon]

Originally Posted by Justin

Hit ESC...

Alright, but I'd expect for the keyboard combination I use for that command to behave as a toggle. Wouldn't you?

[EvilDragon]

I believe the current "navigator" should be reduced only to navigator functionality (as in TCP), and the Filter to be used for actually which items get shown and enabled for editing. Kinda makes the most sense to me...

If it's going to be a "selector" as schwa said, then you have to make sure that it's not possible to enable the "selector" lane multiple times - just one is enough. Also making it undockable could be useful to people with multiple monitors!

[j79]

Sounds great Schwa.

Originally Posted by jnif

Are you sure about that?
Remove the main toolbar and timeline/ruler from the arrange view and it is almost exactly the same size as the MIDI Navigator.
And arrange view supports "compacted folders". So, the arrange view can easily be a lot smaller than the MIDI Navigator.
And if there will be some super small track heights implemented in the MIDI Navigator, then those same track heights should be available also in the arrange view.

jnif

I see your point...but this has to do with how we all work differently i guess, and we must reach a sort of compromise that serves us all well.

I usually work on projects that have both audio and midi. Usually somewhere between 10 and 50 tracks. Out of those tracks somewhere between 1 and 10 have midi on them.

Thats why the "navigator" in the midi-editor would make things a lot easier for me, as it only needs to show 1-10 tracks, and thus takes up much less space.

I do agree though that for midi-only projects or projects with a large number of midi-tracks, your point is completely valid...and a good one too.

How we can make it work for both i am not sure of...but the way i read Schwa's post above thats exactly what they are trying to figure out as well.

[Mercado_Negro]

Originally Posted by jnif

But it is not a mini copy of the arrange view. It looks like they have implemented all the features almost from scratch. There are massive amounts of arrange view features missing.

It would be much better to have real copy of the arrange view and TCP in the MIDI navigator if this is what users really want. I think it would be good. But the current MIDI navigator is very very far from a real copy of the arrange view.

jnif

Don't take things too literally, jnif. With "copy" I meant "a representation of". This is exactly what I needed:

Originally Posted by schwa

The intent is to let the user easily see, and change, which MIDI media item is active, and which other items are displayed/editable in the MIDI editor.

And so far, it looks promising.

[jnif]

Originally Posted by schwa

"Navigator" was the wrong name for the new MIDI editor lane. We should have called it "Selector" or something like that.

The intent is to let the user easily see, and change, which MIDI media item is active, and which other items are displayed/editable in the MIDI editor.

One major issue is that there are many ways to to work with MIDI in a project.

Some users will have various MIDI media items at different places on the timeline, but only on one or two tracks. For these users, the basic idea of the new MIDI editor lane, as implemented, can be made to work. They will be able to choose which media items to work with, in a fairly straightforward manner. (Leaving aside, for now, the question of where exactly the new lane should be displayed.)

Other users will have full-project-length MIDI media items on many tracks. For these users, the current implementation will not work. These users need a narrow, vertical list of tracks, that they can use to choose which tracks to work with.

Other users will have media items at different places on the timeline, on many tracks. They will also need a narrow, vertical list of tracks, which can be used to choose what is displayed in the editor. The selector lane would then show only those tracks, and can then be used to choose which media items to work with.

For simple navigation around the project, it makes more sense to extend the existing project navigator (not the new MIDI editor functionality), so that you can use it to zoom the MIDI editor. But navigation is separate from choosing what is displayed and edited. For example, in an orchestral composition with full-project-length MIDI media items, the user might want to edit track 1 and track 48 together, and ignore the tracks in between. Or, the user might want to see bars 2-4 from track 3 next to bars 4-8 from track 12. What we are currently working on is display, selection, and editability, as opposed to navigation.

Regarding the current proliferation of ways to choose what is displayed in the MIDI editor -- that's what we are trying to fix. A simple, visual way to make these selections can take the place of the MIDI filter window (which only shows the media items you have already loaded into the editor) or the Contents menu (which shows everything in the project, but is cumbersome to use).

Thanks for clearing up the intended purpose of the MIDI "Selector" lane.

The most important changes needed immediately:
1. The item selection should be separate from the visibility/editability/activation properties. User should be able to first select multiple items in the "Selector" and after that decide what he wants to do with those selected items, i.e. make them visible/invisible/editable/ineditable/active/etc.
2. The visibility/editability state of each item/track should be clearly shown in the "Selector". The checkmarks in the right click menu are not enough. The state should be visible directly on the items/tracks.

jnif

[Lawrence]

Originally Posted by schwa

Other users will have full-project-length MIDI media items on many tracks. For these users, the current implementation will not work. These users need a narrow, vertical list of tracks, that they can use to choose which tracks to work with.

Thanks. I was hoping that my previous observation related to that didn't come off as being unfairly expressed.

Thanks Schwa.

[DarkStar]

Just tried downloading - NIS (don't moan) reports "Suspicious.Cloud.7.EP" in the file.

[Lawrence]

Originally Posted by DarkStar

Just tried downloading - NIS (don't moan) reports "Suspicious.Cloud.7.EP" in the file.

Yep. Norton automatically removed it the first two times I downloaded it. I had to go into Norton and restore it to install it.

[VVV]

I also find that "MIDI Navigator" very useful. I like it. I work in fullscreen with MIDI as well and it speed up my workflow and make the whole thing more clear IMO.

It does not exclude the ability to select tracks in the filter window tracklist.(and maybe it will be possible to use the navigator track focused, as an item inspector)

Personally I also don't have any problem with the synchronized horizontal zoom. Again it is more clear that way. But maybe it's because I cut my Midi instrument tracks in lot of small parts.
By the way when you click on a item in the Navigator, sometimes it zoom in but sometimes not. It could be 1 click: select, double click: zoom in.

[xpander]

Just some quick notes, took a while to jot down while testing so I'm sorry if a lot of this has already been discussed further in the meanwhile. There are bugs to be reported also, later...

At any rate, I'm excited about the MIDI Navigator. Funny thing too, in the main arrange I never use the Navigator, zoom features work faster for me.

Originally Posted by jnif

Think and discuss about what users really need. And what is the best way to get there.
...

1. The MIDI navigator is not really a navigator. It is a very bad copy of the arrange view. What is the point? Why not just use the arrange view?

Current MIDI Navigator isn't like the Navigator in Main Arrange but I agree it could have that kind of simplified view/mode too(with the same kind of zoom feature as well).

However, I don't think MIDI Navigator (as it is now called) should be limited only to that kind of function. I see great potential in this MIDI Navigator in helping ME finally to become it's own (independent) MIDI arrangement environment, without the need to use Arrange. That exactly is one point for its existence as far as I'm considered.

As a personal example, so far I've always had MIDI editor docked in the bottom of the screen, but had to have narrow strip of Arrange visible at top. I had to have that up there to make copies of items, move them around, execute actions etc.

With the new MIDI Navigator, from the first second tries I was already exhilarated about its existence within the MIDI editor. It doesn't (yet?) have all the features I used the Arrange for, but is much better approach for my way of working anyway.

2. The location of the navigator is wrong. It can't be in the CC lane. It is a horrible decision.

No matter where it would be, it would take room of something else that was there, this has always been the way with everything we have had visible on our screens. It's about choices. For me personally current way is fine. If I'm working on MIDI item (block) level, I'm not editing individual CCs and vice versa. Shortcuts/actions to make it visible and maybe docking options within ME?

3. The MIDI navigator wastes a lot of screen real estate.

Same as above.

4. There are already many (maybe too many?) ways to control the visibility/editability/activation of MIDI items. Arrange view, MIDI editor's contents menu, Track/item list in MIDI filter window, Track manager, double-click in PRV. Why do we need yet another way, the MIDI navigator?

Because it offers a visual way to navigate/select and edit MIDI items at track/item (not event) level. For this reason, it does need the track listing AND the item names there too. That's why I think "pure" navigation view should/would have to be separate from this, or another selectable view, maybe?

5. "Mixing" the item selection operation to the item visibility/editability control is very confusing.

Maybe I'm not understanding that totally, but the way its now, I find it liberating and compared to, say, MIDI filter screen, way more simple to figure out. Would it have all the same features as the filter window, I could even see myself using just the MIDI Navigator for all that. But yes, these duplicated features can and do have tendency to confuse too.

6. There is no clear indication of item visibility/editability status in the MIDI navigator.

Yes, this would need fine tuning.


---
edit: ok, had time to go back and read the missed posts. Thanks Schwa for explaining this Navigator/Selector feature. Have to meditate on this for a while, but this seems to be heading into nice direction and is actually the first new MIDI feature I'm really excited about. Thanks!

[jnif]

The automatic disabling of "Allow editing inactive MIDI media items" is very annoying. I think the state of this setting should not be changed automatically at all.

Also user should be able to change active item directly in the piano roll without diabling editing of other items. Currently double clicking inactive item's note will make the clicked item the only editable item.

jnif

EDIT:
Looks like disabling "Allow editing inactive MIDI media items" setting does not disable editing of inactive items anymore. Maybe the behaviour of this setting should be updated to actually reflect the description of the setting.

[Amazed]

I'm gonna go with JNIF on this navigator issue. At least the devs have sort of implied intent of this mechanism by calling it selector.

As a selector it takes up too much space IMO. I think a number of us desperately want to shrink or even hide the keyboard so the track names wouldn't work.

If it really about selecting tracks/items the midi filter dialog actually works I thought.Sure it's scruffy and I hate the sort of tree thing that's going on with it but hell it floats

Can't we maybe think about how to make THAT better without the selector?

[Sexan]

What about original idea for Navigator to see notes?

[xpander]

Originally Posted by Amazed

If it really about selecting tracks/items the midi filter dialog actually works I thought.Sure it's scruffy and I hate the sort of tree thing that's going on with it but hell it floats

Hehe, for me that's exactly one of filter windows problems, it sure floats but doesn't dock into ME like it should, if wanted to.

[chucky5p]

Schwa:

Nice to clear-up the air about the selector vs navigator view. If it's to be a selector, something like this would be nice (It's just a start) The black dots inside the white squares are selected options; i.e. quantize all selected lanes, adjust all selected lane velocity, edit enable, etc. We could have more than one option selection per lane. Actually, this could finally be a way for those who want "Track Based " MIDI editing a way to do it, but with lanes; "Lane Based" MIDI editing

Chuck