Go Back   Cockos Incorporated Forums > REAPER Forums > MIDI Hardware, Control Surfaces, and OSC

Reply
 
Thread Tools Display Modes
Old 11-23-2012, 11:32 AM   #81
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by gofer View Post
When you copy+drag events in the piano roll to a space outside their original item's borders and there are multiple items existing on that track at the place where you drop them - what should happen?
Good question. Opinions on that will vary for sure. I personally think it should remain on the same clip and just extend the clip.

If the intent is to move it to another clip, I would guess there would be ways to make that happen whether by key-mod or cut/paste. But my preference would be to never have the software assume I want to move a note from the existing clip, to another clip. I'd want that to be an explicit instruction, so maybe a key-mod, dunno.

How do you do that now in Reaper, move a note from one clip to another when you have two clips showing at the same time layered? Is this something you can do now or is this just something that you can't do now but are just asking how the new thing might actually work when and if it becomes possible later?

Thanks Gofer.

If you want me to look and see and come back and tell you how it works now in a couple of other places, I can do that... if that's what you're actually asking.

Last edited by Lawrence; 11-23-2012 at 11:38 AM.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 11:40 AM   #82
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

You can't do that now per drag and drop, but I would for sure like to be able to do that - drag-copy a viola phrase to the celli. Or forward-copy a movement to the next item on the track (or to an empty area creating a new item - but on which track, provided we have several of them displayed in the editor?).

Key modifier ain't so easy, as there could be several possible target items.


I think this is all part of the question "How do we imagine this new feature". It's something I totally hope is a part of what we are asking for. If not, I indeed misunderstand the whole thing.

Last edited by gofer; 11-23-2012 at 11:51 AM.
gofer is offline   Reply With Quote
Old 11-23-2012, 11:55 AM   #83
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by jnif View Post
Let's try to list the general requirements first. I will try not to use any terminology that could be interpreted in a wrong way. We can try to make the complete requirement list first and only after that decide whether it is possible (or useful) to implement all of them or only some of them in Reaper.
First of all, well done! Brass tacks: we're down to them.

Quote:
1. Edit multiple MIDI items at the same time interactively directly in Piano Roll View. (This does NOT include batch processing, scripts, or separate edit windows/panels like quantize/transpose windows.)
This is a potential source of confusion, and is where the conversation's gotten hung up before. There can be many items available for edit at once in the ME -- you call these "active" items in 2 below -- but only one of them has focus at any time. But REAPER calls the focused item the active item, so when you say "active items" plural, it can be misconstrued as a suggestion that the notion of single focus be abolished altogether (or marginalized into meaninglessness), as in Sonar. I now know that's not what you mean, but it's an example of how slippery terminology can be.

And specifying the behavior of focus can get very tricky indeed. The focused item is the container that receives events under normal circumstances. That's pretty much it, but it's incredibly important. It may be obvious which item has focus, as in Cubase or Studio One or REAPER; and it may not, as in Logic. Drawing notes in some DAWs auto-focuses the item below the cursor, or extends the currently focused item if necessary, or even creates a new item for the note if none fits its criteria. Specifying this behavior will be a lengthy process.

Focus does not prevent you from operating on events in multiple items at once. This is another area of confusion. Most implementations allow you to delete, drag, lasso, resize, quantize, and otherwise operate on any event visible in the ME, regardless of what item it lives in.

Quote:
2. A method to easily select which MIDI items are active for editing. The active items can be on same or different track. And the items can be in different time locations, or partially overlapping, or completely overlapping.
In the simplest case, the MIDI items that are selected in the arrange view are visible are the ME. This is how Logic handles it. I'm pretty much OK with any selection process here.

More soon.

Last edited by medicine tactic; 11-23-2012 at 12:24 PM. Reason: punctuation
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 11:57 AM   #84
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by gofer View Post
You can't do that now per drag and drop, but I would for sure like to be able to do that - drag-copy a viola phrase to the celli. Or forward-copy a movement to the next item on the track.
It depends on the drop target area... in the other DAWs.

In Cubase and similar if the drop target (the mouse location when dropped) is still over any portion of the original clip it assumes the same clip. If the drop target is over another clip, and the original clip isn't still underneath the mouse, it just moves the notes to the other clip, or whatever clip is in front there in the Z-Order if that location has stacked clips under the mouse.

You can - in the latter case - drag/drop/move groups of notes between clips at will, even clips that reside on different arrange tracks.

S1 makes the latter a bit easier, it has a dedicated context menu function for that "Transfer Notes" for directly throwing any selected data from any track to any other track that's exposed in the editor. In that case you can also drag notes from the ME directly to arrange to make a new clip on any track from those notes.

So how it's handled really depends on where you look. No clue how Sonar, Logic, DP does that stuff. I would tend to doubt if any of them do it all the exact same way.

Last edited by Lawrence; 11-23-2012 at 12:06 PM.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 12:11 PM   #85
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by gofer View Post
You can't do that now per drag and drop, but I would for sure like to be able to do that - drag-copy a viola phrase to the celli. Or forward-copy a movement to the next item on the track (or to an empty area creating a new item - but on which track, provided we have several of them displayed in the editor?).

Key modifier ain't so easy, as there could be several possible target items.


I think this is all part of the question "How do we imagine this new feature". It's something I totally hope is a part of what we are asking for. If not, I indeed misunderstand the whole thing.
Yeah, it'd be great to be able to do this. And to my knowledge (I could definitely be wrong here), no other DAW I've tried allows it, so it could be a great way to differentiate REAPER's editing.

Key commands to shift focus during a drag comes to mind.
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 12:13 PM   #86
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Quote:
Originally Posted by Lawrence View Post
It depends on the drop target area... in the other DAWs.

In Cubase and similar if the drop target (the mouse when dropped) is still over any portion of the original clip it assumes the same clip. If the drop target is over another clip, and the original clip isn't still underneath the mouse, it just moves the notes to the other clip, or whatever clip is in front there in the Z-Order... if that location has stacked clips under the mouse.

You can - in the latter case - drag/drop/move groups of notes between clips at will, even clips that reside on different arrange tracks.

S1 makes the latter a bit easier, it has a dedicated context menu function for that "Transfer Notes" for directly throwing any selected data from any track to any other track that's exposed in the editor. In that case you can also drag notes from the ME directly to arrange to make a new clip on any track from those notes.

So how it's handled really depends on where you look. No clue how Sonar, Logic, DP does that stuff. I would tend to doubt if any of them do it all the exact same way.

The Cubase method sounds very interesting. So you'd first change the z-order in the target area and then simply drop them there?

I dig the idea to drop stuff onto the arrange as well.
gofer is offline   Reply With Quote
Old 11-23-2012, 12:17 PM   #87
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Yeah, when things are stacked Z-Order has to take precedence because (obviously) there's no other easy way to define a default target for something like a paste operation other than to assume that what's on top of the layer (or what has the current edit focus) is the target.

But it's easy enough to do that, selecting a note on a clip brings it forward, makes it the active target, much the same way it works in Reaper now if you cut a note from clip A, select a note on clip B to give that clip the edit focus, and then paste.

Same thing... for cut and paste moves.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 12:21 PM   #88
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by Lawrence View Post
Yeah, when things are stacked Z-Order has to take precedence because (obviously) there's no other easy way to define a default target for something like a paste operation other than to assume that what's on top of the layer is the target.

But it's easy enough to do that, selecting a note on a clip brings it forward, makes it the active target, much the same way it works in Reaper now if you cut a note from clip A, select a note on clip B to give that clip the edit focus, and then paste.

Same thing... for cut and paste moves.
What if we had tabs for stacked items, like browser tabs? When dragging, briefly hover over a tab to bring it forward. Maybe that's too large-footprint a solution for a fairly uncommon problem. Just throwing it out there.
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 12:29 PM   #89
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Cool - we're talking

I don't mind changing z-order. The idea med tac has is pretty good as soon as the content display can be docked in a nice way. If you already have the data copied under your mouse, and find you have the wrong target up front you could still make a little detour and go on. But it falls under cherry on top (I like cherries).
gofer is offline   Reply With Quote
Old 11-23-2012, 12:29 PM   #90
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

@ Medicine:

It's not really an issue because you only see or edit the clips in the editor that you select to see or edit. So if you want to drag copy from Clip A that's at bar 1 to Clip B at bar 15, just select those two clips for editing and/or filter the others for editing.

You aren't forced into always viewing or editing every clip in a layer with stacked clips and even when you are viewing them all you can easily disable any or all of the layers for editing anyway.

So there's no problem there to solve. The user can easily define the edit focus in any way he he she chooses, no matter what data they're actually viewing.

The filters are two-fold, viewing and editing. They work independently, per-clip or per-track I guess, depending on what DAW you're using.

Cubase has a little "layer" icon for that, "Edit Active Part Only" that automatically disables all the other layers but the currently selected one, so it's pretty easy to shift the focus to just any one layer.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 12:31 PM   #91
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Quote:
Originally Posted by Lawrence View Post
The filters are two-fold, viewing and editing. They work independently, per-clip.
Yeah, this seems to be the key to it - view and edit filters.
gofer is offline   Reply With Quote
Old 11-23-2012, 12:42 PM   #92
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Cool guys.

And... I will say this very, very respectfully and humbly ... this is why I was "suggesting" earlier that Medicine read some of those old threads on the subject because all of this stuff we just talked about (literally all of it and more) has been talked multiple times before, with graphic examples actually showing some of it in some of those threads.

I wasn't intending to be rude by merely suggesting that, so if it came off that way, apologies.

Maybe I should take more care of how I frame my words in those cases and me taking it as "I can't actually bother to read it, just tell me about it all again..." was maybe not the best or most friendly way to view that.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 01:28 PM   #93
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

The problem with "read some of the old threads" is that this discussion is scattered across some 20+ threads, probably a lot more, some of them with a completely different topic to begin with. Plus, each time the topic is raised there is first the "if-you-got-questions-you-don't-get-it" barrier to break and only very little info to be cherry picked until somewhere on page x some fruitful discussion might come up and persist.

I suppose it all has been said before, but you need a big portion of persistence, time and luck to find it - and luck doesn't seem to be my strong side at the moment... It would be good to have a thread that consists of just signal (I know that ain't ever gonna happen, but maybe just a positive s/n ratio on the first page would be doable, if we all really try ).
gofer is offline   Reply With Quote
Old 11-23-2012, 01:33 PM   #94
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

I can't say your logic there is flawed.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 01:36 PM   #95
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
Default

Quote:
Originally Posted by gofer View Post
When you copy+drag events in the piano roll to a space outside their original item's borders and there are multiple items existing on that track at the place where you drop them - what should happen?
Quote:
Originally Posted by Lawrence View Post
If the intent is to move it to another clip, I would guess there would be ways to make that happen whether by key-mod or cut/paste. But my preference would be to never have the software assume I want to move a note from the existing clip, to another clip. I'd want that to be an explicit instruction, so maybe a key-mod, dunno.
Actually I can't imagine doing this (move, copy/pase, etc.) unless it was totally intended so I don't know why it would need any special comands. It should work just like normal, right?

Quote:
Originally Posted by Lawrence View Post
In Cubase and similar if the drop target (the mouse location when dropped) is still over any portion of the original clip it assumes the same clip. If the drop target is over another clip, and the original clip isn't still underneath the mouse, it just moves the notes to the other clip, or whatever clip is in front there in the Z-Order if that location has stacked clips under the mouse.

You can - in the latter case - drag/drop/move groups of notes between clips at will, even clips that reside on different arrange tracks.
This is what my thinking is, total freedom for cut/paste, copy/paste, move, drag/drop, etc.

Quote:
Originally Posted by medicine tactic View Post
What if we had tabs for stacked items, like browser tabs? When dragging, briefly hover over a tab to bring it forward. Maybe that's too large-footprint a solution for a fairly uncommon problem. Just throwing it out there.
There in lies the what I think might be the biggest problem. I have never and probably never will stack items in the arrange but I know may folks do.

Quote:
Originally Posted by Lawrence View Post
The filters are two-fold, viewing and editing. They work independently, per-clip or per-track I guess, depending on what DAW you're using.
Quote:
Originally Posted by gofer View Post
Yeah, this seems to be the key to it - view and edit filters.
But that sort of screws up one of the main advantages of track based editing, because it clutters and confuses the Filter. Being able to just click on tracks is an important part to this. Maybe there could be a switch in the filter box to show just tracks vrs tracks and items.

Okay heh heh, I'm going to call it Track Based Editing because that's kind of become ReaperSpeak to me.
Tod is offline   Reply With Quote
Old 11-23-2012, 01:46 PM   #96
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Here was my (apparently unsuccessful) attempt at a general FAQ on the basic subject from about 8 months ago. I was trying to clear up some of the misconceptions and misunderstandings of what people were asking for, misconceptions of that which seem to always surround the discussion in some way.

Obvious fail.

http://forum.cockos.com/showthread.php?t=99692

And with hindsight being 20/20, I actually forgot about the last Question and Answer in that list, my bad...

Quote:
Q: Ok. So now that it's been covered in great detail will you guys just please shut up and stop talking about it? It's annoying.

A: Yes. I think all you had to do was politely ask.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 01:52 PM   #97
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by gofer View Post
The problem with "read some of the old threads" is that this discussion is scattered across some 20+ threads, probably a lot more, some of them with a completely different topic to begin with. Plus, each time the topic is raised there is first the "if-you-got-questions-you-don't-get-it" barrier to break and only very little info to be cherry picked until somewhere on page x some fruitful discussion might come up and persist.

I suppose it all has been said before, but you need a big portion of persistence, time and luck to find it - and luck doesn't seem to be my strong side at the moment... It would be good to have a thread that consists of just signal (I know that ain't ever gonna happen, but maybe just a positive s/n ratio on the first page would be doable, if we all really try ).
Oh man, you nailed it. I spent like a week spelunking old FR's and archives and following links and thought I'd been pretty thorough, but apparently not. And the FR's themselves are frequently vague, or use easily misunderstood terminology. An FR Wiki would be better, so this stuff can be consolidated and curated.
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 02:41 PM   #98
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Nice one, Lawrence, I guess I missed it.
As said, I already knew about the "whats" and the "whys" and don't question them, but nevertheless get regularly misunderstood and seem to upset people when I ask about the "hows". It's probably just as annoying as permanently getting those questions you mention there and I was pretty close to drop a "shut up already, it's annoying" at some point in this thread. I'm glad I got the curve and kindly asked .
gofer is offline   Reply With Quote
Old 11-23-2012, 03:10 PM   #99
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by gofer View Post
I was pretty close to dropping a "shut up already, it's annoying" at some point in this thread.
Haha. I know. I didn't need "Spidey Senses" to perceive that threshold approaching. I can certainly be annoying (admittedly, a short pause for some necessary introspection) but I'm actually not oblivious to that.

Thanks Gofer.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 03:16 PM   #100
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by Lawrence View Post
Here was my (apparently unsuccessful) attempt at a general FAQ on the basic subject from about 8 months ago. I was trying to clear up some of the misconceptions and misunderstandings of what people were asking for, misconceptions of that which seem to always surround the discussion in some way.

Obvious fail.

http://forum.cockos.com/showthread.php?t=99692

And with hindsight being 20/20, I actually forgot about the last Question and Answer in that list, my bad...
Heh, a link to that would have been much appreciated earlier on! Keep it handy

In general, I think using Sonar as the go to example is misleading. It's so different that those new to the discussion naturally assume its oddities are what everyone is clamoring for. I honestly thought the consensus was that it was the model to emulate, and many of the FR's can be interpreted within that framework.
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 03:18 PM   #101
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
Default

Quote:
Originally Posted by Lawrence View Post
Here was my (apparently unsuccessful) attempt at a general FAQ on the basic subject from about 8 months ago. I was trying to clear up some of the misconceptions and misunderstandings of what people were asking for, misconceptions of that which seem to always surround the discussion in some way.

Obvious fail.

http://forum.cockos.com/showthread.php?t=99692

And with hindsight being 20/20, I actually forgot about the last Question and Answer in that list, my bad...
Heh heh, that's pretty good Lawrence, I hadn't seen that before. That was a good stab in the right direction and you covered a lot of bases.

What I'd like to see is some of the Reaper folks that use midi a lot on a daily basis get involved with all this. There's more to it than whats been discussed here so far.

For one thing, I think the track and item list should be totally separate from the filter box. Until then the track and item list will never be able to be dockable like jnif shows here.

http://forum.cockos.com/showthread.p...923#post767923

This might seem a little OT but really and truly it's not, it all ties in together.

And then there's the Contents menu selection, I think it also needs an overhaul, maybe a separate box like the Track List.
Tod is offline   Reply With Quote
Old 11-23-2012, 04:00 PM   #102
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by jnif View Post
3. Display full project timeline and grid lines in the Piano Roll View. Grid and timeline should be visible also in empty areas between items. It should be possible to scroll the view to any location of the project in Piano Roll View even if there are no MIDI items there.
I think the empty areas between items should be indicated somehow, because it's a useful piece of information to have, and it provides a hit area for item creation, a la Studio One. I'd love a grid there, just a visually distinct one.

Quote:
4. Create new items automatically when MIDI events are added to empty area of a track.
This can go a lot of ways. Logic extends the prior item, or creates a new item if no item exists. Studio One allows you to draw a new item in the area first, which I like.

Quote:
5. Extend MIDI items automatically when MIDI events are moved outside existing item, or added close to the edge of existing item.
I like Cubase's behavior here: it just lets you drag the items out of bounds. I figure if out of bounds events are supported, then lets really support them. Especially if you're editing an item that's been shortened, but still want access to all its events. Supporting this no man's land, and then leaving it untouchable (without extending item borders) just feels wrong to me. I'm probably alone on this one, though.

Quote:
6. Option to disable automatic item creation and extending described in requirements 4 and 5.
Quote:
7. Easy MIDI editor view focusing (= zoom and scroll) to item(s) activated for editing, or to visible item(s).
This would be great. Something like FL Studio's zoom-to-selection feature. I'd even love smooth scrolling and rubber band scrolling like iOS and FL Studio! This may sound frivolous, but smooth visual transitions help maintain a frame of reference. Abrupt transitions can be disorienting.

Last edited by medicine tactic; 11-23-2012 at 05:16 PM. Reason: added jnif
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 04:17 PM   #103
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Did somebody mention MIDI editor tabs?

http://forum.cockos.com/project.php?issueid=1336
EvilDragon is offline   Reply With Quote
Old 11-23-2012, 06:05 PM   #104
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,111
Default

Quote:
Originally Posted by medicine tactic View Post
This is a potential source of confusion, and is where the conversation's gotten hung up before. There can be many items available for edit at once in the ME -- you call these "active" items in 2 below -- but only one of them has focus at any time. But REAPER calls the focused item the active item, so when you say "active items" plural, it can be misconstrued as a suggestion that the notion of single focus be abolished altogether (or marginalized into meaninglessness), as in Sonar. I now know that's not what you mean, but it's an example of how slippery terminology can be.

And specifying the behavior of focus can get very tricky indeed. The focused item is the container that receives events under normal circumstances. That's pretty much it, but it's incredibly important. It may be obvious which item has focus, as in Cubase or Studio One or REAPER; and it may not, as in Logic. Drawing notes in some DAWs auto-focuses the item below the cursor, or extends the currently focused item if necessary, or even creates a new item for the note if none fits its criteria. Specifying this behavior will be a lengthy process.

Focus does not prevent you from operating on events in multiple items at once. This is another area of confusion. Most implementations allow you to delete, drag, lasso, resize, quantize, and otherwise operate on any event visible in the ME, regardless of what item it lives in.
Yes, I agree. Only one item is focused at any time. The focused item is kind of like "the main target" of editing operations. Also other active items can be edited but the focused item is the main target of editing. And this main target should be indicated clearly in the GUI. In my multi-item midi editing pseudo-code I tried to specify some parts of the editing behaviour. There I used the term "Last Touched Item" which could be considered same as "Focused Item".

Quote:
Originally Posted by medicine tactic View Post
In the simplest case, the MIDI items that are selected in the arrange view are visible are the ME. This is how Logic handles it. I'm pretty much OK with any selection process here.
Selecting in the arrange view is probably the most unabiguous way. All other methods (lists, trees, tabs, etc.) seem to have some issues if you have lots of items, or if you have fully overlapping items (items inside other items) on same track. It will become very difficult to identify item in those methods because you can't see size and time position (or vertical position) of the item compared to other items. Usually the selection is only based on item name and color, which in some complex MIDI item arrangements is not enough. However, this does not mean that MECP style track/item hierarchy control panel in the MIDI editor is useless. MECP is very useful and fast way to manage item/track selection in many simple projects and even in moderately complex projects. Only the most complex use cases require arrange view based selection.

And here I think Reaper can be more advanced than some other DAWs, like for example Studio One. Reaper supports clear arranging of overlapping items on same track in arrange view. And you can also activate/focus overlapping items individually directly from MIDI editor without using arrange view. Based on my somewhat limited experience with StudioOne, it looks like this kind of fine grained item selection control is not possible in Studio One. You can have have overlapping items in Studio One but I think it is mostly designed to support only partial overlapping. Whenever you put multiple items on same track completely inside each other, then the item selection becames very confusing. Studio One experts may verify if this is a correct observation.

jnif
jnif is offline   Reply With Quote
Old 11-24-2012, 01:20 AM   #105
djjedidiah
Human being with feelings
 
Join Date: Nov 2011
Location: Denver, CO, USA
Posts: 447
Default

Jeez, and I thought this was all that needed to be said:
djjedidiah is offline   Reply With Quote
Old 11-24-2012, 02:34 AM   #106
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 22,754
Default

Quote:
Originally Posted by medicine tactic View Post

Sorry everyone! Let's lay this one to rest.
I am so happy and relieved to see this, friend.
Was beginning to feel like it was me being a grumpy old man.
You are big enough to adjust your way of thinking and that impresses me greatly.
Thank you.

P.S. Just being able to decide that I DON'T want extending a MIDI item's length to automatically duplicate and extend the existing MIDI data would be a big help...

...now someone tell me this was implemented in a deeply buried options menu in version 4.02


Last edited by ivansc; 11-24-2012 at 02:41 AM.
ivansc is offline   Reply With Quote
Old 11-24-2012, 03:13 AM   #107
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Quote:
Originally Posted by ivansc View Post
P.S. Just being able to decide that I DON'T want extending a MIDI item's length to automatically duplicate and extend the existing MIDI data would be a big help...

...now someone tell me this was implemented in a deeply buried options menu in version 4.02

???
Not sure if you mean that, but maybe disabling "Loop item source" in the item context menu under "Item settings:" or in item properties helps you. Preferences -> Media Item Defaults, if you want it off per default.

I guess switching it on/off was implemented together with the feature back in the Pleistocene .

...tell me you mean something else.
gofer is offline   Reply With Quote
Old 11-24-2012, 07:59 AM   #108
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

This seems to have turned into a productive discussion.
Lawrence is offline   Reply With Quote
Old 11-24-2012, 09:10 AM   #109
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Dropping onto stacked items has it's difficulties as mentioned in selecting the payload target. Hovering over the stack could periodically force the stack to pop thereby allowing a drop of the payload onto the required item? Or hovering over the stack with a payload could put up a drop list of items in the stack allowing a drop onto the selected item?
Amazed is offline   Reply With Quote
Old 11-24-2012, 09:38 AM   #110
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,111
Default

Quote:
Originally Posted by Amazed View Post
Dropping onto stacked items has it's difficulties as mentioned in selecting the payload target. Hovering over the stack could periodically force the stack to pop thereby allowing a drop of the payload onto the required item? Or hovering over the stack with a payload could put up a drop list of items in the stack allowing a drop onto the selected item?
Sounds quite complex. Is it really necessary to have some special behaviour just for drag-and-dropping events from one item to another item in a stack of overlapping items? Why not just use separate cut/copy + "change focus to other item" + paste operations?

Could you explain some real world MIDI editing situation where you would like to do this with one single mouse drag gesture?
EDIT:
Looks like gofer already provided an example where he would like to use drag-and-drop- copying/moving to other track.
Quote:
Originally Posted by gofer View Post
You can't do that now per drag and drop, but I would for sure like to be able to do that - drag-copy a viola phrase to the celli. Or forward-copy a movement to the next item on the track (or to an empty area creating a new item - but on which track, provided we have several of them displayed in the editor?).
How about an option to lock edits to single track? Then if you are working on cello track, you could just drag-copy notes from viola or bass track (or even from both at the same time) and they would drop to cello track because the "edit target lock" is enabled on cello track.
If "Edit target lock" is disabled, then the target track of drag-and-drop operations are based on the source track of each event. I.e. if you drag-copy viola, cello and bass notes at the same time each copy will be dropped to their own track. This is of course the default behaviour. Enabling "Edit traget lock" would be necessary only occasionally.

jnif

Last edited by jnif; 11-24-2012 at 10:01 AM.
jnif is offline   Reply With Quote
Old 11-24-2012, 10:24 AM   #111
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by jnif View Post
Sounds quite complex. Is it really necessary to have some special behaviour just for drag-and-dropping events from one item to another item in a stack of overlapping items?
That's pretty much what I was thinking. It seems to be more of a corner case situation than anything that might happen a lot.

Just cut, shift focus, and paste.

Or, if the "layers" are in lanes in arrange, they're all visibly separated already so that would (in some cases anyway) be a much easier edit in arrange anyway, drag it to a different lane and merge the clips.
Lawrence is offline   Reply With Quote
Old 11-24-2012, 10:28 AM   #112
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by jnif View Post
How about an option to lock edits to single track? Then if you are working on cello track, you could just drag-copy notes from viola or bass track (or even from both at the same time) and they would drop to cello track because the "edit target lock" is enabled on cello track.

jnif
That S1 method I presented earlier "Transfer Notes" can logically be easily extended. Currently, the targets for the transfer of notes are other tracks but there is no really logical reason a function like that couldn't also include other clips on the same track.

It would just do the same thing, you'd have a menu function "Transfer Notes" and the list would present all the clip layers currently exposed in the editor for editing. You select one from the list and the selected notes get moved to that clip/layer, in the same position.

Easy... and specific.

Last edited by Lawrence; 11-24-2012 at 11:09 AM.
Lawrence is offline   Reply With Quote
Old 11-24-2012, 10:50 AM   #113
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Quote:
Originally Posted by jnif View Post
How about an option to lock edits to single track? Then if you are working on cello track, you could just drag-copy notes from viola or bass track (or even from both at the same time) and they would drop to cello track because the "edit target lock" is enabled on cello track.
If "Edit target lock" is disabled, then the target track of drag-and-drop operations are based on the source track of each event. I.e. if you drag-copy viola, cello and bass notes at the same time each copy will be dropped to their own track. This is of course the default behaviour. Enabling "Edit traget lock" would be necessary only occasionally.

jnif
That sounds like a good workable idea, locking to a target track when the edit needs to cross from one track to another. It could stay enabled when you are sort of collecting data from several other tracks to the one you are targeting to and you wouldn't need to set a target each time. I think I like it. That's sort of (but not exactly) how I understood the z-order concept described earlier (in the Cubase example)

There still can be ambiguity with multiple possible target items at the target time on the same track. Like when you work on a (single) drum track with parallel items for kick/snare/hihat/etc. and want to copy a hihat variation forward (or you use that awesome workflow with key-switch articulation items Lawrence described earlier - deserves a thread, that one - you don't want stuff dragged into these). If Reaper had some concept of "item lanes" the same principle could be used, but that would be stretching our luck I guess .


@Lawrence: That works for transferring in place, but jnif's idea can work for mouse drag/copy as well as define the target for clipboard cut/copy/paste, so it can do both.

Last edited by gofer; 11-24-2012 at 10:58 AM.
gofer is offline   Reply With Quote
Old 11-24-2012, 11:06 AM   #114
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by gofer View Post
@Lawrence: That works for transferring in place, but jnif's idea can work for mouse drag/copy as well as define the target for clipboard cut/copy/paste, so it can do both.
Ah, got you. Thanks.
Lawrence is offline   Reply With Quote
Old 11-24-2012, 12:15 PM   #115
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

I'd like to try to define "item-based" and "track-based". I'm going to give you the definition I was working from at the start of the thread. I probably should have begun with this instead of a polemic, but I assumed this was the definition everyone was already using -- always a bad idea! And I should say I've definitely gained a deeper understanding as this thread has progressed, so I'll probably contradict things I said earlier. Thank you all for being so understanding, and putting up with my stubbornness (really!).

I realize the definitions of these terms as they've been used are considerably looser. But I'd argue that's why there's so much confusion around what people actually want, which possibly contributes to the devs' reluctance to get into it. Clear expression and mutual understanding energize people!

First of all, is it worth trying to define the terms? Are "item-based" and "track-based" even things? I think they are. I think the terms are actually surprisingly accurate, and I think it's worth attempting to give them definitions that are as precise as possible. As REAPER evolves, and we all participate in hammering out requirements and testing pre's and reporting bugs, the terms "item-based" and "track-based" are bound to come up, so it would be incredibly beneficial if we had a common understanding.

The usual disclaimers apply: this is just my opinion; please correct me where I'm wrong, etc.

The problem with saying "to me, 'track-based' just means editing multiple items at the same time" is that it doesn't really say much. Just about every DAW fits this description. (Except REAPER, heh, but that's just because REAPER's young and has been postponing a lot these difficult decisions.)

It seems to me the fundamental difference between item-based and track-based systems is the event container type that is emphasized. Item-based systems emphasize the item as the event container, and track-based systems emphasize the track. I'm using this distinction not to push my viewpoint, but because it's the only meaningful distinction I can see, and it seems to be able to accurately predict other features of the system. Here's a comparison of attributes, as I see them:


Item-based
  1. Items contain events.

  2. Tracks contain items.

  3. It's the item that has focus in the MIDI editor, not the track. It may or may not be obvious which item has focus, and the rules for how it's shifted around vary greatly (often shifting implicitly as part of another operation), but it's there nonetheless. Focus serves to disambiguate the event-receiving item.

  4. Multiple items' events can be made available for editing in the MIDI editor at the same time. The user can lasso, drag, transpose, resize, quantize, and otherwise operate on them.

  5. Items are managed by the user. The system may create or lengthen items automatically based on the user's actions in the MIDI editor, but this behavior is simple and predictable, and implicit in the user's actions.

  6. Items are never automatically deleted or shortened by the system based on the user's operations on events in the MIDI editor. (I think this deserves its own bullet)

Track-based
  1. Tracks (or track-length "layers") contain events.

  2. Items are ephemeral groupings used as a shorthand for event manipulation.

  3. It's the track (or layer) that has focus in the MIDI editor, not the item. There may be roundabout ways to target specific items, but that's discouraged by the model. Focus serves to disambiguate the event-receiving track (or layer).

  4. Multiple tracks' (or layers') events can be available for editing in the MIDI editor at the same time. The user can lasso, drag, transpose, resize, quantize, and otherwise operate on them.

  5. Items are managed by the system. The system creates, resizes, and deletes items based on the user's actions in the MIDI editor. This behavior is complicated and difficult to predict, and shouldn't be counted on. The user has some control over items, but again, mostly as a shorthand for event operations.

  6. Items can be automatically deleted by the system based on the user's operations on events in the MIDI editor. (I think this deserves its own bullet)

Whithin this framework, most of the feature requests that have been considered to fall into the track-based category, actually fall into the item-based or are acategorical (coinage!). Also, within this framework, Sonar is the only DAW I know of that is track-based. This probably looks suspect, but I promise it's a natural consequence of drawing the line at the event container type, as the terms themselves seem to me to imply.

Last edited by medicine tactic; 11-24-2012 at 02:14 PM. Reason: wording
medicine tactic is offline   Reply With Quote
Old 11-24-2012, 12:39 PM   #116
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

My general description of "track based", in the context it was framed around that particular FR, was ...

"What is lowest level editing base or editing range?"

...for editing midi anywhere and everywhere ... which in that context is always the entire "track collection" in something like Cubase.

In that case no matter where you edit, the "base" (range or limits, like an Army "base" literally ends at its physical borders?) for editing always extends to the entire track collection, every track in the song. "Track based", for lack of an existing description for that context.

The edit "base" is the entire track collection. Like the Army base is every street inside it's borders.

The term was only really relevant in the specific context of the FR.

A rough analogy of "item based editing" (imo) in that same context might be a database where you could only ever edit one record at a time instead of being able to update any and all selected records at the same time.

Like if you were updating a database and you wanted to mark 14 customers as "inactive", which is a data field in all the customer records, "Active / Inactive", you'd have to open those 14 records one at a time and change them one at a time, instead of selecting all 14 records and updating that one field for them all at once with one edit.

Like if you wanted to mute all C#3's across 14 midi clips in Reaper, all at once. The base of data editing does not reach that far. It's restricted to the item level. It's quite literally "based" (the current midi edit model in the ME) on only one item's contents at any given time, for editing data.

It - the edit model of the editor itself - is "based" on a single item's contents, not based on the full track collection or any larger collection of data.

So the terminology was largely contextual, and it was a result of needing to call it "something or other" since it actually doesn't have a formal name.

None of it matters really, imo... beyond having a tag for shorthand descriptions of the edit model restrictions that led to the FR. Those restrictions are (apparently) because Reaper opens up "item data" for editing, and can't yet reach beyond that and bring other "item data" in.

The others open up "data" for editing, from a large collection of data, and it's all available. A larger base from which to edit data, at any time. The "base" in that case is anything from any track, "track based". It can restrict itself to only editing one items data, but it isn't actually built that way.. to force that restriction.

That's my view anyway... that in "track based" (in that context) you actually can't even open anything less than an entire track's worth of data, even if some of it is filtered for editing or viewing, it's still accessible. The track is the lowest level edit container.

In "item based" (at least in Reaper) the item is both the lowest and highest level edit container, the actual only level of editing. In that particular contextual framing.

Last edited by Lawrence; 11-24-2012 at 01:20 PM.
Lawrence is offline   Reply With Quote
Old 11-24-2012, 02:57 PM   #117
James HE
Human being with feelings
 
James HE's Avatar
 
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
Default

Track ? Item ?

whatever. If we want to take the REAPER ME into a different direction, lets talk about TAKES.

I use a lot of takes with MIDI. Right now, there is no way to switch between takes within the ME, this is, for my workflow, the only flaw with REAPER that I can't work around without having multiple ME's open.

I like item based editing. I like having different takes of items. I wish, from the ME, I could duplicate the active take, make changes to the copy, and then A / B them, making sleight variations and or more copies. I really cannot do this without having to shift focus many times.

Actions do not work well in aiding this, as the window focus causes problems. (it works a bit better with the in-line editor, but I only use inline for very specific tasks.)

Could be just get rid of that Toolbar that most people never use (as they have their own custom layout of toolbars) And instead have a representation of the associated tracks(s) there, where we could switch takes, select items to focus editable items in the ME, and other things?

Any one want me to make a mockup?
James HE is offline   Reply With Quote
Old 11-24-2012, 05:14 PM   #118
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Locking a target. Sounds like the ticket. So even when I'm painting or playing in notes that activity will be applicable to my 'locked' target. Is that right? So where I'm now selecting items in the filter dialog I'd be selecting tracks in the target dialog?

Last edited by Amazed; 11-24-2012 at 05:20 PM. Reason: swapped one term for another
Amazed is offline   Reply With Quote
Old 11-25-2012, 08:07 AM   #119
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 22,754
Default

Quote:
Originally Posted by gofer View Post
???
Not sure if you mean that, but maybe disabling "Loop item source" in the item context menu under "Item settings:" or in item properties helps you. Preferences -> Media Item Defaults, if you want it off per default.

I guess switching it on/off was implemented together with the feature back in the Pleistocene .

...tell me you mean something else.
Yep - imprecise s ever. I am wanting to turn off the extend data with item feature and at the same time enable whole track editing, so although turning off looping has been with us a long time (and I use it and it IS relatively useful) it is still just one of those limping along substitutes for the real thing, isnt it?

Sorry if I am a bit slow and stupid today. 4am return to base after last nights gig is not good when you re 68.

Maybe I should quite while I am behind....
ivansc is offline   Reply With Quote
Old 11-25-2012, 08:09 AM   #120
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 22,754
Default

Quote:
Originally Posted by jnif View Post
How about an option to lock edits to single track? Then if you are working on cello track, you could just drag-copy notes from viola or bass track (or even from both at the same time) and they would drop to cello track because the "edit target lock" is enabled on cello track.
If "Edit target lock" is disabled, then the target track of drag-and-drop operations are based on the source track of each event. I.e. if you drag-copy viola, cello and bass notes at the same time each copy will be dropped to their own track. This is of course the default behaviour. Enabling "Edit traget lock" would be necessary only occasionally.

jnif
+1. A good start in the right direction if I am interpreting this correctly.
ivansc 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 10:11 PM.


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