These 'extra' notes you observe in the Event List are still part of that item. Please let me elaborate on that. In Options/Preferences/Media/MIDI you'll find an option called "Allow trim of MIDI items when splitting", this option allows you to spit an item and convert it into 2 different items with their own notes (both splits will now have the notes you can see in their own piano rolls only). If you don't have this option enabled and you split an item, this will just work like a trim. In your example, you can see this easily by deleting the first split ("clip") and dragging the left edge of the remaining split to the left; you'll see the notes of that first clip again.

I agree that they are part of the _item_ (or "take", as I believe Reaper calls it), but they should not be displayed as part of the _clip_. Or rather, I would assert that the "piano roll" and "event list" views should always show the same set of notes. Does that make sense? These are supposed to be two different views of the same data, yet the piano roll shows only the notes in the clip, whereas the event list shows all the notes in the take regardless of whether or not they are in the clip that was selected for editing.

- Casey

Sorry MN, the ""Allow trim of MIDI items when splitting"," preference does not do that here (as we have discussed before. :)) And its pop-up help says "add a note off for any notes that span the split point"

Issues:
http://forum.cockos.com/project.php?issueid=497 (I don't know why this was Closed)
http://forum.cockos.com/project.php?issueid=2076
http://forum.cockos.com/project.php?issueid=2874

Discussions:
http://forum.cockos.com/showthread.php?t=46805
http://forum.cockos.com/showthread.php?t=52020


[Some consolidation is needed :)]

It wouldn't be accurate to show only the notes that appear in one of the splits in the Event List because those notes are still part of that item, they're just 'hidden'. An item (clip) is just a visual representation of a piece of information at a given time under certain conditions, whether it shows the whole information of the source or just a part of it it's up to the user. The MIDI Editor just shows what the item in the arrange view shows. If you need to discard notes when splitting you should enable that option in Preferences.

@DarkStar: I still agree, this http://forum.cockos.com/project.php?issueid=2874 and this http://forum.cockos.com/project.php?issueid=2874 are confirmed bugs but as far as I can see they're not directly related to this issue.

I disagree. It is not a question of accuracy, it is a question of consistency. If the arrangement view doesn't show it, and the piano roll doesn't show it, then the event list shouldn't show it. It is highly inconsistent behavior for _all other editors in the system_ to restrict the range of visible notes to one subset, and then have _just one editor_ view all the notes.

Put differently, there is a bug _in one editor or the other_, you can pick which one, I suppose, based on which one you think is the more desirable behavior. Either the event list has a bug, because it shows more notes than the piano roll, or the piano roll has a bug, because it shows less notes than the event list. But they can't _both_ be right.

A nice, feature-oriented way to resolve this might be to introduce an additional option in the view menu of the MIDI editor that says "hide notes outside of clip", or something of that nature. Then, both the piano roll and the event list would show only the notes from the clip when that is checked, and both would expand to show all notes in the item when it is un-checked.

Presumably checked would be the default, to keep it consistent with the arrangement view.

- Casey

Indeed :)

I also don't know why this bug was marked as "not a reaper bug". I fail to see any way that it's not a bug... I mean, I've been a professional software developer for 15 years, so, I usually know a valid bug report when I see one :)

- Casey

We have an option in Preferences to achieve that behavior. Current design allows users to know the 'real' content of the 'whole' item. How would you know if you still can trim an item to use it in its original form if you can't see its 'full' contain? If you want to discard notes while splitting, just use that option. What DarkStar pointed out in those issues is a bug, which I only confirmed with his project, because the split/show notes behavior is not consistent.

EDIT: Maybe we could have a "View" section in the Event List so users can choose to see the 'source contents' or just what the arrange shows.

This is a judgement call ... Mercado_Negro's analysis is exactly correct that the event list view is showing all of the MIDI events in the media item regardless of whether they are audible (regardless of whether the item is trimmed). That has always been the behavior of the event list view -- it's a list of the events in the media item, not a display of the active part of the media item -- and it's reasonable to mark this report as not a bug.

However, with respect to all parties, I'll reclassify the ticket as a confirmed bug. It would be better if the event list view behavior were consistent with the piano roll view.

In case it helps clarify:

I'm not fuzzy on the whole "there's more notes than are in the clip" idea. I understood that when posting this bug and I understand where the extra notes come from.

It's actually a good feature to be non-destructive with the clips in this way, and I actually want it to stay that way. I use it with MIDI all the time. I _like_ being able to have notes outside the clip that I can choose to put back into the clip by expanding the clip horizontally in the arrangement view. This is a great feature, just like it is with audio!

The problem comes when you have big MIDI items and you've broken them into clips for arrangement purposes, and then you want to edit one. I don't actually want to trim the MIDI to just the clip length (as was suggested earlier in this thread), I want to preserve the extra notes that are outside the clip in case I want to expand to them later.

So the "piano roll" works perfectly in this scenario, because when you click on a clip to edit it in the piano roll, even if that came from a giant item with millions of notes, it only shows you the hundred or so notes that are actually in that clip. This makes it easy and quick to edit.

On the other hand, if you then click on the view menu and change to "event list", it jumps back to the beginning of the item, which might be several _minutes_ of music prior to the place you actually want to edit (if the clip starts sufficiently after the beginning of the item). You then have to hunt for the start of the clip (the best way I've found to do this is to start bilinearly searching through the notes and clicking on the rows, viewing where that places the play cursor in the arrangement view... it's very slow... maybe there is a better way?)

Furthermore, it can be very disorienting for the novice because when they are viewing a clip in the piano roll, and then they switch to the event view, the expectation would be that the same set of notes are visible in both views. So when they look at the first event, and it's, say, a pedal event, they would probably assume that it's the first pedal event that they saw in the piano roll view. They will then be confused when they edit it (or delete it, or move it), then switch back to piano roll view only to see that the event has remained unchanged! This is, of course, because they were actually looking at some much earlier pedal event in the event list, so editing it has no effect on the first pedal event in the clip.

Etc., etc.

So I think it would be really nice if the event list worked the same way as the piano roll. I'm not sure if there's a reason _not_ to make it work this way. Is anyone using it right now who _likes_ the fact that it works differently from the piano roll? If so, then it might argue strongly for a toggle that controls whether _both_ views see all notes or just the notes in the clip...

Anyway, thanks for taking the time to look at this thread and reclassify it as an open bug!

Cheers,
- Casey