"Track Based Midi" - how best do we describe this?

[mccrabney]

hey, i'm interested in farming out a definition of "track based midi."

by this, i mean an alternative approach to "item based midi," REAPER's current approach to midi editing. currently, REAPER's midi editor opens 1 midi item at a time. other items can be made to be editable, but are not considered "active" or "focused"

in track based midi, the entire track is "active." item bounds still exist, but are merely means to contain content.
in the midi editor, the entire track's midi contents are visible and editable.
users can still jump from item to item, zooming to contents etc.
midi notes drawn outside of item bounds create new items.
record/overdub creates a new midi item if none exists
overdub prefers existent midi item always. record creates a new take OR a new concurrent item in fipm.

this should get us started. i'm looking for comments from ya boys Tod and ivansc, whom i've seen talking about this feature request throughout the forum. this thread is created for the purpose of making a well informed request, using REAPER's existing features whenever possible to make for the shortest ground between where we are now and the requested workflow.

[Tod]

Originally Posted by mccrabney

hey, i'm interested in farming out a definition of "track based midi."

Good one mccrabney, Track based midi would be one of the best updates and improvements Reaper could make. It would solve a huge number of problems.

[ts335]

+1 This would so helpful when I'm stitching together parts without having to glue everything.

[enroe]

Originally Posted by mccrabney

in track based midi, the entire track is "active." item bounds still exist, but are merely means to contain content.
in the midi editor, the entire track's midi contents are visible and editable.
users can still jump from item to item, zooming to contents etc.
midi notes drawn outside of item bounds create new items.
record/overdub creates a new midi item if none exists
overdub prefers existent midi item always. record creates a new take OR a new concurrent item in fipm.

This is already possible if you create one big midi-item for the full
length of a song.

In existent songs you can get there if you select all items of one
track and glue them.

What I would call "track-based" approach is having track-playback-
parameter in a special "track inspector". These can be transpose,
delay, midi-note range, velocity adds or subtracts, humanize factor
etc.

[mccrabney]

Originally Posted by enroe

This is already possible if you create one big midi-item for the full length of a song.

as discussed in other threads, this sacrifices all functionality workflow that utilizes item bounds (in my case, zoom to item content), and as such isn't a solution. if you're using items to copy/duplicate/rearrange different parts of your song, you have to re-split and re-glue items. if you have hanging pickups or note tails that normally would overlap with other items ala fipm or concurrent items, you have additional work to do.

1 track long midi item can be used conceptually in describing desired behavior, but it only gets us halfway there. we need to keep what is good from item-based workflow.

Tod, am i missing anything? you and ivansc are 2 of the people i wanted to speak up in this thread.

--

one thing that the MPC did better than REAPER was that it allowed midi note ends to extend past the item bounds. this is currently doable in REAPER by having overlapping midi items, and is why i mentioned FIPM earlier. being able to do this makes for a MUCH better way to handle pickups and chords that "strum" in, rather than starting on an item's first moment.

imagine this is an item in reaper, with midi notes in it: in REAPER, item end means midi NOTE end.
[----]

in the MPC, you could have this: [----]--

where the note end extends beyond the item bounds. you can move this item and that trailing note end follows. this makes for a MUCH better solution for hanging notes, pickups, strummed-chords that don't begin at X.1.0, etc.

in REAPER you need overlapping midi items, and REAPER doesn't handle overdubbing into these very well.

[Tod]

Tod, am i missing anything? you and ivansc are 2 of the people i wanted to speak up in this thread.

You're doing pretty good mccrabney.

As soon as I found out how Reaper's item based midi worked, I started using full song items. Of course I do all my editing
and copy/pasting in the midi editor.

I started using midi in the mid 1980s and I'd never heard of "item or clip" based midi until I came to Reaper. My last DAW
was Sonar before coming to Reaper, and I just played in my midi anywhere on the track. It did make little clips, but they
meant nothing other then I could copy/paste them anywhere. In the midi editor you didn't see any clips, you just saw the midi.

Think about it, being able to use midi items with no bounds other then what you see in the arrange area, it would just be a
visual thing. You could still use the items like you do now but you wouldn't have to worry or think about boundaries.

I'll say it again, I think "Track Based Midi" would be the best improvement Reaper could make right now.

[nofish]

My 2 ct's...

While I like a track based MIDI approach I'd expect the notion of active / editable not to change as it would I think for example break a lot of MIDI scripts which work on the 'currently active item'.

So I'd expect

in track based midi, the entire track is "active."

not to happen.
Additionaly I like that I can exclude edits from certain items by making them not editable.

Actually I think we are already quite close to a track based MIDI workflow (e.g. we can set it so that all track's MIDI opens at once, I once posted in a related thread) and what seems more realistic to me is focusing on that the remaining bugs which prevent this currently (as you reported e.g. here and here) should be squashed.

If this all worked as it should, what else would be missing from a track based MIDI workflow?

[mccrabney]

Originally Posted by nofish

If this all worked as it should, what else would be missing from a track based MIDI workflow?

probably not a lot, assuming all features and scripts are properly addressed to work on all selected midi, rather than just the active item's midi.

some theming issues, maybe, because inactive midi items are displayed differently. for instance, i'd expect the selected note row display (green hilight in the screenshot below) would extend beyond the active item bounds here



ideally i wouldn't even see a difference here between active/inactive.
i just want to open a midi editor for a track and be able to forget all about active/inactive items, WITHOUT losing the compositional benefit that items-as-containers offers.

[Tod]

Originally Posted by nofish

My 2 ct's...

While I like a track based MIDI approach I'd expect the notion of active / editable not to change as it would I think for example break a lot of MIDI scripts which work on the 'currently active item'.

So you think track based midi would interfere with the current midi item system?

Even if the midi items remained the same in the arrange area, but in the midi editor they all showed up as one single item?

Additionaly I like that I can exclude edits from certain items by making them not editable.

I trust you nofish, and basically believe everything you say, but what's the reason you want to make items uneditable?

Actually I think we are already quite close to a track based MIDI workflow (e.g. we can set it so that all track's MIDI opens at once, I once posted in a related thread) and what seems more realistic to me is focusing on that the remaining bugs which prevent this currently (as you reported e.g. here and here) should be squashed.

If this all worked as it should, what else would be missing from a track based MIDI workflow?

Here's where my ignorance shows, since I've been using full song items since I started with Reaper, I don't know about this stuff.

Actually it all seems rather convoluted to me, but then again that's Reapers way, and that's what I like about it.

i just want to open a midi editor for a track and be able to forget all about active/inactive items, WITHOUT losing the compositional benefit that items-as-containers offers.

Ha ha, well I think that's the crux of the matter.

[nofish]

@mccrabney
Good points I can all agree with (though I do like the visual distinction between active / editable, but this could probably be optionized.)

Scripts not working on all editable items currently is also a big one for me, I'm hoping for the necessary API addition.

[nofish]

Originally Posted by Tod

but what's the reason you want to make items uneditable?

Example:
Manipulate MIDI in all verses at once but not the choruses (which are all separate items here):
I make the choruses items uneditable and all manipulation I do (e.g. raise / lower velocity, quantize etc.) are only applied to the verses.