v4.33pre (Post only about MIDI)

[nofish]

Originally Posted by run, megalodon

Ok, sorry to be lazy since I don't want to go read through the whole discussion, but can you tell me quickly why do we need editable and active states? Is this in addition to selected? Having all three of those seems really complex.

In a nutshell (there are posts in the previous pre's explaining this more in depth):

- active: only one item can be active at a time, in this item only you can draw new events
- editable: several items at once can be editable (the new thing), you can eg select all events in all editable items and move, edit them at once

Right now (from what I gather) the devs are testing if editability should be tied to selected or not and which way is best to implement this whole thing.

[Tod]

Originally Posted by medicine tactic

What we have now is almost the same, but way better. Now the active item is indicated via its own column (this could change),

But this is where we were prior to V4.33pre5 and V4.33pre5 eliminated (Actually changed how it was used) this extra icon because it wasn't needed in the way it was being used. Much less clutter and confusion.

freeing up highlight-style selection for the item selection, which is super useful for batch toggling the various settings.

I had no problem toggling the "eye" and "arrow" icons for batch selection.

[pc999]

I don't seem to be able to edit multiple items, only the active one, I can only have the active one with the arrow?

Am I missing something?

This seemed better in the pre5 as it seemed more intuitive (although I didn't tried pre4) so it may just because I learned to other way first?

Thanks, it is great to see some MIDI love (I almost only need a session view and a linux version!)!

[medicine tactic]

Originally Posted by schwa

Regarding the MIDI track list, we have tried different behaviors in different prereleases.

In pre4, selected rows were editable, and you clicked a separate column to choose the active item. This was useful for quickly choosing which MIDI items you want to work with, just by selecting the rows.

In pre5, the selected row was active, and you clicked a separate column to choose which items are editable. Some users argued that this was more intuitive, because you are likely to select a set of MIDI items to work with relatively infrequently, but among that set, switch the active item more frequently.

In pre6, the default behavior is similar to pre4, except there are a ton of options (too many options, really). You can alternatively choose a completely different workflow where there is no automatic behavior based on row selection, and instead you select rows and click various icons to affect all of those rows. So if you want to make a group of items editable, you select them, then click the editable (unlocked) icon. This alternative workflow is arguably the most flexible, but not necessarily intuitive, and will require more clicks than the other behaviors.

We're not going to preserve all of these options and behaviors for the final build. I know it's unusual for us to throw so many different behaviors out there, but it does seem clear that different users have different expectations for the best way to manage multiple MIDI items.

I have the alternate behaviors selected (really just to turn off the default behaviors), and "media item selection mirrors arrange view".

I've said it before, but I love the swipeable editability and visibility columns, and I love independent item and editability selections. Let item selection be just that: a selection of items with no extra meaning, with the arrange view selection reflected in the MIDI track list and the MIDI media item lane (minus audio media items, of course). IMO, the selection should be an inherently meaningless set that you do stuff to. At least leave the option.

I'm hoping the default behaviors aren't an indication of the direction you're leaning.

Edit: I realize the item and editability selections are technically independent. What I really mean is that I don't want selection to automatically set anything, and deselection to automatically unset anything.

[EvilDragon]

We're missing "Track selection mirrors arrange view" option, too.

[jnif]

Originally Posted by schwa

Regarding the MIDI track list, we have tried different behaviors in different prereleases.

In pre4, selected rows were editable, and you clicked a separate column to choose the active item. This was useful for quickly choosing which MIDI items you want to work with, just by selecting the rows.

In pre5, the selected row was active, and you clicked a separate column to choose which items are editable. Some users argued that this was more intuitive, because you are likely to select a set of MIDI items to work with relatively infrequently, but among that set, switch the active item more frequently.

In pre6, the default behavior is similar to pre4, except there are a ton of options (too many options, really). You can alternatively choose a completely different workflow where there is no automatic behavior based on row selection, and instead you select rows and click various icons to affect all of those rows. So if you want to make a group of items editable, you select them, then click the editable (unlocked) icon. This alternative workflow is arguably the most flexible, but not necessarily intuitive, and will require more clicks than the other behaviors.

We're not going to preserve all of these options and behaviors for the final build. I know it's unusual for us to throw so many different behaviors out there, but it does seem clear that different users have different expectations for the best way to manage multiple MIDI items.

I appreciate your efforts to provide different behaviors for testing in these prereleases. However, there is a big problem.
All these behaviors contain lots of bugs. It is quite difficult to get good impression of usability when you have to constantly guess how it would feel like if bugs are fixed.
Please try to get the basic operation right for at least one workflow. I have not yet seen a single working workflow.

For example in this pre6
1. Sometimes enabling visibility will automatically enable editability, sometimes not. Very confusing and unpredictable. There seems to be some kind of hidden memory that changes behavior of control based on previous state. It is probably a bug. If not, then it is very bad design.
2. The default behavior is supposed to be fast but it is not because an important option is missing. There should be also an option "Deselecting a row does not change editability/visibility states".

jnif

PS. I also like the full flexibility of the alternative track list behavior, but I would like it much more if there was one more option to make it a bit faster. Row selection and active state could be linked when there is only one row selected. This would make active swithcing faster and it would be visually more clear when active item/track is also selected.

[nofish]

Originally Posted by pc999

I don't seem to be able to edit multiple items, only the active one, I can only have the active one with the arrow?

The edit-ability is now controlled by the lock icon in this pre.
Still only one item can be active at a time (the one with the arrow), as it was in the previous pre's.

[medicine tactic]

Originally Posted by jnif

1. Sometimes enabling visibility will automatically enable editability, sometimes not. Very confusing and unpredictable. There seems to be some kind of hidden memory that changes behavior of control based on previous state. It is probably a bug. If not, then it is very bad design.

Yeah, I don't know if this is intentional or not, but it feels wrong.

[Evan]

[BUG]
Double-clicking on a MIDI item in the arrange view, selects all MIDI items and opens the editor. Bug?

I like the selection mirroring but it shouldn't auto-select all items.

[Dafinga]

The ME controls are great. I find them very intuitive and easy to work with.

[VVV]

Wow. The next update will be huge. Good job!

I'm a little bit tired and haven't spent a lot of time using the track list but my first impression is that the pre5 was more intuitive and less confusing.

For exemple, I don't see the point of separating selection and activation of a row.

[medicine tactic]

Originally Posted by run, megalodon

Wow, thanks guys. This stuff is seriously complex. I think that there should be one state that lets you edit an item including drawing, selecting, moving, etc.

Ugh, no offense but we've been over and over and over this stuff.

That one state is the active item. It's the only item that can be drawn and pasted into.

If you want to draw in one item and move stuff from other items, isn't it a lot easier to just toggle editability than have a bunch of states that let you do all kinds of different things?

That's exactly the way it is. There's the active item mentioned above. Then there's the editable items in which you can modify existing events. Then there's the visible items which just provide non-interactive background information. It's really very simple and kind of inevitable.

In fact, I think it would be easiest if there was simply "selected" items, and item that are selected can be edited. This also has the benefit of letting you perform item based actions without thinking because the ones that the actions are applied to are the ones you are working on.

This has been the major area of debate. There are many different ways to handle the relationship between item selection/deselection and the editability/visibility selections. You can equate them, or one way link them, or keep them completely independent, and there are advantages and disadvantages to each approach. The last three pres have presented different UIs and functionality in this area. I'm in favor of an independent item selection and no automatic setting. I just can't bring myself to repeat everything again. I'm sure it'll all come up again soon. You can also read the previous pre threads (searching for "selection" would probably get you what you're looking for).

Edit. I mean, visiblity and locking and stuff are all nice, but concerning selection/editability it seems like there should only be one.

There is no locking. There's only active, editable and visible, which are all very unique. Edit: or I should say editable=unlocked and uneditable=locked. They're the same thing.

It all seems *way* more complicated than it is because we're in the thick of figuring out the UI.

[pc999]

Tested a bit more and I think prefer the pre5 behavior, just easier to use IMO as it is more intuitive and much more immediate, but I wouldn't mind at all if the other two are alternative behaviors .

What bother me more is that when you deselect a track you cant see it anymore!

[Evan]

[MIDI Editor]

Don't you guys think the media item lane (bottom panel) would be more useful if only the active items appeared fully opaque and in color? And the inactive items maybe in grey or maybe semi-transparent.

[argee]

Double-click in the piano roll is still not working at all anymore with the latest pre-release 6a, doesn't matter what action I set it to do.

[airon]

Originally Posted by EvilDragon

pre6 behavior is definitely the most flexible, and is something that should be offered in the final build, IMHO. Sensible defaults are the key, though.

Perhaps, surveying the midi user crowd on a public release is useful in this regard ?

Or compressing the two most popular workflows in to two options in the prefs that can reveal deeper options on request. Two larger buttons or a two-position slider or two radio buttons with a "midi editor options" button to go deeper.

Anything really to keep it very simple for as long as possible, unless the user themselves want to tinker.

[Mercado_Negro]

Split

Originally Posted by gpunk_w

Bug with naming notes in multiple MIDI items
As you can see it only shows named notes when the item is editable, needs to show them at all times if visible
I suspect some kind of ordering is needed, so if the current editable item has a note named at the same note as lower items (Visible) Then that will be displayed and the others ignored, but as in this instance if the lower (Visible) items are named and the editable not, the lower names should be shown, as you can see here, needed for drum editing.

[Susan G]

Has this been addressed?

http://forum.cockos.com/project.php?issueid=697

Please add the ability to preview (audition) notes when moving them with the keyboard, not just with the mouse.

It doesn't seem so, but maybe I missed it. I confess my eyes kinda glaze over when I go through the posts on the ME changes and I'm hoping it ends up pretty much like SONAR !

Thanks-

-Susan

[EvilDragon]

Please add option to move the ME hover info on the bottom where the transport and all the other options are. Desperate here already. ;_;

[musicbynumbers]

Originally Posted by Evan

[MIDI Editor]

Don't you guys think the media item lane (bottom panel) would be more useful if only the active items appeared fully opaque and in color? And the inactive items maybe in grey or maybe semi-transparent.

I might have mistook what you mean here but I use colours to help me quickly identify what is what so not sure if that would be useful to me at least.

I do agree though the more clarity on the things the better. Perhaps a themed coloured outlined.

[musicbynumbers]

Tiny side note. Would love to have the scale finder window able to be a toolbar in the midi editor. Even tried sneaky ways and couldn't get it to work there.

[musicbynumbers]

Anyone else reproduce this bug? It's quite a big one and stops you accidentally moving notes in adjacent items when using the marque selection unless you lock them first.

Originally Posted by musicbynumbers

potential bug.

If I have say, 4 copies of an un-ghosted midi item on the same track all displaying side by in the midi editor and then go to edit the first one of the 4, I find that using the right click select marque to select a few notes in the first item ALSO selects any notes on the same rows in the other tiems UNLESS I lock the other items.

Is this intentional? I tried a few of the "row options" and couldn't figure this out.

Also, like to say that apart from the lock option (that I'm unsure of it's need) I'm loving editing in this pre as I was in pre 5 still. Later I will try it on a massive orchestral project and see how it holds out there.

Be great if you can find time to squash that above bug though

[Anton9]

Originally Posted by EvilDragon

"Exclusive mute" and "Exclusive solo" in ME track list don't seem to work at all.

Confirmed

Originally Posted by EvilDragon

There's missing "Shift" designation for "Set selected media items to random colors".

Shift+clicking the color swatch on the track in media item lane does not work.

Works here

[mikeroephonics]

Please use small images, thumbnails, or post
the web address for the image.

It's really difficult to read these (horizontally)
loooong threads.

For the sanity of the users & the devs!

Thanks!

[Anton9]

Originally Posted by mikeroephonics

Please use small images, thumbnails, or post
the web address for the image.

It's really difficult to read these (horizontally)
loooong threads.

For the sanity of the users & the devs!

Thanks!

Option 1:
If you are logged in at the top of the thread you should notice a link titled "User CP".., click on it and then click on "Edit Options" and under the "Thread Display Options" you have an option to "Show Images"..., just un-tick that.

Option 2:
At the bottom of each thread in the "Thread Tools" section is a link titled "Show Printable Version".

Using one of these is a lot easier than getting everyone else to comply.

[DarkStar]

^^^
I disagree. Those 2 options suppress the images. I still want to see small images.

That particular image is so wide that I cannot tell what it is showing as I need to scroll left and right to see it.

And I have to scroll right just to click the [Save] button for this edited reply

[EvilDragon]

Originally Posted by Anton9

Works here

Works now in pre6a, didn't work in pre6.

[chronocepter]

Hi. Keep the hard work boys. In this critical historical REAPER episode.

The multiediting is a huge stuff. but the simpe copy-paste MIDI act still incomplete and slowing down my produtivity. But this is esay to fix i guess.
Just spread that so private "copy notes" action (that allows copy and drag MIDI using the mouse) to everywhere in MIDImouse modfiers.
I dream with the possibility to hold ctrl and click in a blank area in MIDI editor to copy+drag my MIDI stuff with the mouse avoiding the need to seek that specific pixel in a little MIDI note (far zoom editing) or engage a zooming trip.

Thanks.
keep goin

[Win Conway]

Image removed from post above

[Lawrence]

Originally Posted by airon

Perhaps, surveying the midi user crowd on a public release is useful in this regard ?

My thoughts is that while lurking through the 3 pres, the active, selection, locked, whatever stuff just all seemed to complex... so I stayed out of it. I look at the others with tracklists and they don't seem nearly as complex, the behaviors.

Select a clip in arrange, it shows up in the editor. Select multiple clips they all show up to edit. Want something not to be editable, turn off the pencil. Seems simple to me.

Most of the actual selection I personally do is in arrange. Select some clips, edit in the ME, close it and go back to arrange. The other stuff seems to be solving problems that nobody really has.

[Guido]

Hi,

1. Arrange window still zooming/scrolling when mousewheeling in the midi track list of a docked midi editor.

2. I have a midi track with 10 or so items each with 5 or 6 takes. While using the midi tracklist to edit the ACTIVE TAKES, somehow all active takes changed. So i reloaded the song ,saved them as a take comp, and when it happened again..reloading the items comp didnt work.

Coudnt there be a way of locking/unlocking active takes in the midi editor track list?

Guido

[schwa]

As is often the case, we have the "why does this need to be so complicated?" camp and the "please give us the most control" camp.

[pc999]

Originally Posted by schwa

As is often the case, we have the "why does this need to be so complicated?" camp and the "please give us the most control" camp.

Make the first the default and the second optional, because the those that prefer the second will be those wiling to put more neurons and time on it too. Even better if the first is simple and intuitive the second can be even more complex without more complains!

There is already two behaviours, so it is a way of getting both the best of both worlds by balancing them IMO.

[Evan]

Originally Posted by schwa

As is often the case, we have the "why does this need to be so complicated?" camp and the "please give us the most control" camp.

It's true but these discussions are very useful. If a feature is overly complicated, some people will be put off and not use the "advanced functionality". Especially those who have not participated in pre-release discussions and see the finished feature for the first time.

For example, I am trying out the current midi track list and I am somewhat confused overall.

More specifically, I have this below:



1) By instinct, I wanted to activate complete folder tracks with their children tracks, but I can't. I can't click on "strings" or "synths" in the example.

2) Similarly, I wanted to control visibility in complete folder tracks with one click, but I can't. Folder hierarchy is only visual, not functional.

3) To someone who hasn't studied the rules, it's not clear what is clickable and what isn't.

4) I am still confused by the track/item selection vs. the editable arrow icon. Because I can enable a different track/item for editability, the MIDI editor shows me that item, but the selection highlight is on a different track/item in the track list.

[VVV]

Originally Posted by schwa

As is often the case, we have the "why does this need to be so complicated?" camp and the "please give us the most control" camp.

As well as the "please give us the most control in order to make the whole thing really simple. For instance left click name= active row, right click name+swipping= editable row" camp.

[EvilDragon]

Originally Posted by schwa

As is often the case, we have the "why does this need to be so complicated?" camp and the "please give us the most control" camp.

I hope it doesn't put you off?


Yes, give us the most control for these behaviors as possible, but keep the defaults simple, intuitive, and easy to grasp.

[merdave]

Just a reminder: adding more options and more complexity to these MIDI objects means a much tougher job for the developers; it means re-coding their base objects and creating new, derived child objects that don't break in the future when more options and complexity are "demanded" by the users.

Some good reading: http://blog.learningbyshipping.com/2...e-methodology/

[Lawrence]

Originally Posted by schwa

As is often the case, we have the "why does this need to be so complicated?" camp and the "please give us the most control" camp.

Haha.

[Lawrence]

Originally Posted by EvilDragon

Yes, give us the most control for these behaviors as possible, but keep the defaults simple, intuitive, and easy to grasp.

Yeah. Reaper's way is to have multiple options or choices for just about everything so with that in mind I suppose this shouldn't be any different.

For the basic tracklist functionality I wanted, Schwa kinda had me at "hello", a few pre releases back. The kitchen sink part of it all (covering almost every imaginable workflow possibility) is I suppose what's being worked out now.

[drew]

A couple of MIDI Editor things..
Double-click to insert a note is not working here. That's definitely a new issue.
Alt-drag to delete notes plays the pitch where you start mousedown at the start of the drag and stays until you mouseup, which isn't helpful to that operation since you're not deleting that pitch necessarily. Think that's a new issue, but not sure how new.