Old 12-06-2012, 03:28 AM   #41
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,541
Default

That's TCP navigator where sliding is possible. ME navigator is missing functionality (as stated in the prerelease log).
EvilDragon is online now   Reply With Quote
Old 12-06-2012, 03:28 AM   #42
mwe
Human being with feelings
 
mwe's Avatar
 
Join Date: Mar 2012
Location: Kentucky, USA
Posts: 254
Default

Quote:
Originally Posted by EvilDragon View Post
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.

Last edited by mwe; 12-06-2012 at 03:35 AM.
mwe is offline   Reply With Quote
Old 12-06-2012, 03:30 AM   #43
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,093
Default

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...
gofer is offline   Reply With Quote
Old 12-06-2012, 03:34 AM   #44
musicbynumbers
Human being with feelings
 
musicbynumbers's Avatar
 
Join Date: Jun 2009
Location: brighton, uk
Posts: 12,589
Default

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.
musicbynumbers is offline   Reply With Quote
Old 12-06-2012, 03:36 AM   #45
run, megalodon
Human being with feelings
 
Join Date: Apr 2010
Posts: 2,860
Default

Quote:
Originally Posted by musicbynumbers View Post
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.
run, megalodon is offline   Reply With Quote
Old 12-06-2012, 04:18 AM   #46
Coachz
Human being with feelings
 
Coachz's Avatar
 
Join Date: Oct 2010
Location: Charleston, SC USA
Posts: 6,016
Default

please fix midi zoom when opening new midi windows
Coachz is online now   Reply With Quote
Old 12-06-2012, 04:44 AM   #47
Seventh
Human being with feelings
 
Seventh's Avatar
 
Join Date: Sep 2010
Location: Finland
Posts: 776
Default

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.
Seventh is offline   Reply With Quote
Old 12-06-2012, 05:02 AM   #48
krahosk
Human being with feelings
 
krahosk's Avatar
 
Join Date: Jul 2009
Location: Canada
Posts: 1,665
Default

Quote:
Originally Posted by EvilDragon View Post
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.
krahosk is offline   Reply With Quote
Old 12-06-2012, 05:08 AM   #49
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

Quote:
Originally Posted by musicbynumbers View Post
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

Last edited by jnif; 12-06-2012 at 05:33 AM.
jnif is offline   Reply With Quote
Old 12-06-2012, 05:18 AM   #50
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,541
Default

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.
EvilDragon is online now   Reply With Quote
Old 12-06-2012, 05:30 AM   #51
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,272
Default

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)

Last edited by Dstruct; 01-26-2016 at 12:57 PM.
Dstruct is offline   Reply With Quote
Old 12-06-2012, 05:44 AM   #52
swiiscompos
Human being with feelings
 
swiiscompos's Avatar
 
Join Date: Mar 2011
Location: Lausanne (CH)
Posts: 1,097
Default

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!
swiiscompos is offline   Reply With Quote
Old 12-06-2012, 05:56 AM   #53
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

Quote:
Originally Posted by EvilDragon View Post
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

Last edited by jnif; 12-06-2012 at 06:09 AM.
jnif is offline   Reply With Quote
Old 12-06-2012, 06:08 AM   #54
swiiscompos
Human being with feelings
 
swiiscompos's Avatar
 
Join Date: Mar 2011
Location: Lausanne (CH)
Posts: 1,097
Default

Quote:
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"...
swiiscompos is offline   Reply With Quote
Old 12-06-2012, 06:20 AM   #55
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

Quote:
Originally Posted by swiiscompos View Post
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

Last edited by jnif; 12-06-2012 at 06:31 AM.
jnif is offline   Reply With Quote
Old 12-06-2012, 06:38 AM   #56
j79
Human being with feelings
 
j79's Avatar
 
Join Date: Mar 2009
Location: Göteborg
Posts: 1,320
Default

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?
j79 is offline   Reply With Quote
Old 12-06-2012, 06:47 AM   #57
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

Quote:
Originally Posted by j79 View Post
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

Last edited by jnif; 12-06-2012 at 06:53 AM.
jnif is offline   Reply With Quote
Old 12-06-2012, 06:56 AM   #58
Mercado_Negro
Moderator
 
Mercado_Negro's Avatar
 
Join Date: Aug 2007
Location: Caracas, Venezuela
Posts: 8,245
Default

Quote:
Originally Posted by jnif View Post
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).
__________________
Pressure is what turns coal into diamonds - Michael a.k.a. Runaway
Mercado_Negro is offline   Reply With Quote
Old 12-06-2012, 06:56 AM   #59
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 11,857
Default

Quote:
Originally Posted by EvilDragon View Post
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...
Justin is offline   Reply With Quote
Old 12-06-2012, 06:57 AM   #60
j79
Human being with feelings
 
j79's Avatar
 
Join Date: Mar 2009
Location: Göteborg
Posts: 1,320
Default

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

Quote:
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.

Last edited by j79; 12-06-2012 at 07:04 AM.
j79 is offline   Reply With Quote
Old 12-06-2012, 07:02 AM   #61
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

Quote:
Originally Posted by Mercado_Negro View Post
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 is offline   Reply With Quote
Old 12-06-2012, 07:13 AM   #62
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

Quote:
Originally Posted by j79 View Post
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
jnif is offline   Reply With Quote
Old 12-06-2012, 07:23 AM   #63
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,296
Default

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.
__________________
"I, Bozo The Clown, do solemly swear to uphold the Consti.. consti... uh, how do you pronounce that again?".
Lawrence is offline   Reply With Quote
Old 12-06-2012, 07:26 AM   #64
Evan
Human being with feelings
 
Join Date: Oct 2006
Location: Greece
Posts: 3,519
Default

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.
Evan is offline   Reply With Quote
Old 12-06-2012, 07:34 AM   #65
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 9,839
Default

"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).

Last edited by schwa; 12-06-2012 at 07:40 AM.
schwa is offline   Reply With Quote
Old 12-06-2012, 07:41 AM   #66
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,541
Default

Quote:
Originally Posted by Justin View Post
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 is online now   Reply With Quote
Old 12-06-2012, 07:44 AM   #67
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,541
Default

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!
EvilDragon is online now   Reply With Quote
Old 12-06-2012, 07:46 AM   #68
j79
Human being with feelings
 
j79's Avatar
 
Join Date: Mar 2009
Location: Göteborg
Posts: 1,320
Default

Sounds great Schwa.

Quote:
Originally Posted by jnif View Post
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.
j79 is offline   Reply With Quote
Old 12-06-2012, 07:56 AM   #69
Mercado_Negro
Moderator
 
Mercado_Negro's Avatar
 
Join Date: Aug 2007
Location: Caracas, Venezuela
Posts: 8,245
Default

Quote:
Originally Posted by jnif View Post
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:

Quote:
Originally Posted by schwa View Post
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.
__________________
Pressure is what turns coal into diamonds - Michael a.k.a. Runaway
Mercado_Negro is offline   Reply With Quote
Old 12-06-2012, 07:58 AM   #70
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

Quote:
Originally Posted by schwa View Post
"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
jnif is offline   Reply With Quote
Old 12-06-2012, 08:00 AM   #71
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,296
Default

Quote:
Originally Posted by schwa View Post
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.
__________________
"I, Bozo The Clown, do solemly swear to uphold the Consti.. consti... uh, how do you pronounce that again?".
Lawrence is offline   Reply With Quote
Old 12-06-2012, 08:01 AM   #72
DarkStar
Human being with feelings
 
DarkStar's Avatar
 
Join Date: May 2006
Location: Surrey, UK
Posts: 17,742
Default

Just tried downloading - NIS (don't moan) reports "Suspicious.Cloud.7.EP" in the file.
__________________
DarkStar ... interesting, if true. . . . Inspired by ...
DarkStar is online now   Reply With Quote
Old 12-06-2012, 08:04 AM   #73
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,296
Default

Quote:
Originally Posted by DarkStar View Post
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.

__________________
"I, Bozo The Clown, do solemly swear to uphold the Consti.. consti... uh, how do you pronounce that again?".
Lawrence is offline   Reply With Quote
Old 12-06-2012, 08:07 AM   #74
VVV
Human being with feelings
 
VVV's Avatar
 
Join Date: Mar 2010
Location: France
Posts: 391
Default

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.
VVV is offline   Reply With Quote
Old 12-06-2012, 08:10 AM   #75
xpander
Human being with feelings
 
xpander's Avatar
 
Join Date: Jun 2007
Location: Terra incognita
Posts: 4,554
Default

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.


Quote:
Originally Posted by jnif View Post
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.

Quote:
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?


Quote:
3. The MIDI navigator wastes a lot of screen real estate.
Same as above.

Quote:
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?

Quote:
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.

Quote:
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!

Last edited by xpander; 12-06-2012 at 09:03 AM.
xpander is offline   Reply With Quote
Old 12-06-2012, 08:19 AM   #76
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,040
Default

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.

Last edited by jnif; 12-06-2012 at 09:31 AM.
jnif is offline   Reply With Quote
Old 12-06-2012, 08:26 AM   #77
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,645
Default

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?

Last edited by Amazed; 12-06-2012 at 08:26 AM. Reason: typo
Amazed is online now   Reply With Quote
Old 12-06-2012, 08:28 AM   #78
Sexan
Human being with feelings
 
Sexan's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 2,081
Default

What about original idea for Navigator to see notes?
Sexan is offline   Reply With Quote
Old 12-06-2012, 08:44 AM   #79
xpander
Human being with feelings
 
xpander's Avatar
 
Join Date: Jun 2007
Location: Terra incognita
Posts: 4,554
Default

Quote:
Originally Posted by Amazed View Post
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.
xpander is offline   Reply With Quote
Old 12-06-2012, 08:46 AM   #80
chucky5p
Human being with feelings
 
Join Date: Apr 2011
Location: Canada
Posts: 454
Default

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


Last edited by chucky5p; 12-06-2012 at 09:03 AM.
chucky5p is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 11:12 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.