v6.12+dev0618b - June 18 2020

[ovnis]

A single area selection is enough.

I'm OK with that.

[EvilDragon]

Originally Posted by schwa

We’d add the ability to prevent retriggering for specific media items, not an overall preference.

But a global preference not to kill events at the end of MIDI item would also be super welcome. There are too many cases where this is much more useful than Reaper's current (unmodifiable) behavior.

[_Stevie_]

Definitely a good idea, I agree with ED.

[deeb]

Originally Posted by vitalker

Because this user will try to move all the tools to a new DAW to feel comfortable, even if something is relatively useless.

Sorry but your sentence is very non sense in my opinion.

What can a user that don't even know or experienced area selection can bring to the table?

Experienced users might know good practices and what is useful in them. Also experienced users experienced something created by specialized skills and "know how" present in those DAWs features, per example: User Interface Design and User Experience Specialist.

So, the experience of those well crafted features made by skilled people is not comparable with a random user post, with unknowned skills or experience, that never experienced something on Topic and that can say whatever he wants, can argue however he wants and against whoever he wants in a forum like this.

Also , historically there is a tendency of creating standards as long as they work well. So , in practice I am pretty sure every daw that nowadays have Area selection/ range selection had as reference cubase since they created the concept i think something like 15 years ago and worked really well.

Piano roll is equal in every daw nowadays, because it worked well. Copy paste in every text editor works the same in principle because it worked well, as with Manny things in real life and software world. So people tend to standarize this as the expected behaviour, until something gives obvious advantages from a new method, BUT chances of someone which had never experienced something to invent something 2.0 are really low. Do you get the picture?

[vitalker]

Originally Posted by deeb

Do you get the picture?

Of course you right, but that doesn't mean I'm not right.
I've never used AS, but I understand how it can look like. At least Sexan's script shows the power.

[deeb]

Originally Posted by vitalker

Of course you right, but that doesn't mean I'm not right.
I've never used AS, but I understand how it can look like. At least Sexan's script shows the power.

It's not about being right or not, but since you putted in this way, you are not right because you are minimizing the experience from other DAWS and that is a mistake, Also if your reference is Sexan script, then you lack experience on Area Selection, because it was never finished and i guess you did not use it fully in a single project. So saying things like you said previously "If it's enough for you does not mean it's enough for others" is valid but a very random/ easy arguing.

[vitalker]

Originally Posted by deeb

but if your reference is Sexan script, then you lack experience on Area Selection, because it was never finished and i guess you did not use it fully in a single project.

My reference is my logic.

[deeb]

Originally Posted by vitalker

My reference is my logic.

i know! others also have their logic combined eventually with experience, which makes a new logic paradigm.

[vitalker]

Originally Posted by deeb

i know! others also have their logic combined eventually with experience, which makes a new logic paradigm.

It's okay. So what's your opinion? I still don't get it. You said one contiguous area is enough for you, but also you used other DAWs, where it can be non-contiguous. I don't see anything fresh in this statement.

[deeb]

Originally Posted by vitalker

It's okay. So what's your opinion? I still don't get it. You said one contiguous area is enough for you, but also you used other DAWs, where it can be non-contiguous. I don't see anything fresh in this statement.

you don't see because you don't see the picture of area selection usage in practice

[vitalker]

Originally Posted by deeb

you don't see because you don't see the picture of area selection usage in practice

How do you know what I see? Why Studio One allows for it? It can be used for non-contiguous time selection and soloing the items you need to hear.

[deeb]

Originally Posted by vitalker

How do you know what I see? Why Studio One allows for it? It can be used for non-contiguous time selection and soloing the items you need to hear.

I am not saying i prefer 1 single area for reaper. I was saying that it's not by allowing multiple or single areas that makes better/worst good area selection. A good single area is enough if it works really well , muscled for a defined purpose. And if someone don't see that, in other words consider multiple /single as better/worst, is because that someone don't see the picture of using it in practice.

Plus, i would say and might be controversial, but in general if someone wants to do the same with AS what they can do with item selection then it's because they don't see the picture and role of AS.

[vitalker]

Originally Posted by deeb

I am not saying i prefer 1 single area for reaper. I was saying that it's not by allowing multiple or single areas that makes better/worst good area selection. A good single area is enough if it works really well , muscled for a defined purpose. And if someone don't see that, in other words consider multiple /single as better/worst, is because that someone don't see the picture of using it in practice.

I got it.

[vitalker]

Originally Posted by deeb

Plus, i would say and might be controversial, but in general if someone wants to do the same with AS what they can do with item selection then it's because they don't see the picture and role of AS.

Well it would take more time, so it's not efficient. On the other hand, you can at least see what is selected, especially when you have lots of really short items.

[deeb]

Originally Posted by vitalker

Well it would take more time, so it's not efficient. On the other hand, you can at least see what is selected, especially when you have lots of really short items.

Applied on Items and AI, AreaSelection is destructive by nature while regular selection is not . ! It should be seen as complimentary and not a substitution. Both work together making a selection system. Both have different roles , Advantages and Cons.

[vitalker]

Originally Posted by deeb

but AS is destructive by nature while regular selection is not. ! It should be seen as complimentary and not a substitution. Both work together making a selection system. Both have different purposes, Advantages and Cons.

What do you mean by destructive? In Reaper it's not. When you select items with both methods, what can go wrong?

[deeb]

Originally Posted by vitalker

What do you mean by destructive? In Reaper it's not. When you select items with both methods, what can go wrong?

destructive on the bounds , if an item or AI is not fully inside the area that item or AI will split when applying something, so per example copying that bit of item will have to be considered as a new item, so per example if that item was a pooled item it will have to loose this status.

So this is the mind set we need to have when considering one selection over the other. If i want pooled items to be maintained i use regular selection , if i am willing to make a new item out of an intercepted item by the area i know i will loose the pooled property.

If i am constantly looking to make ranges with the perfect size of an item to not destroy it on the bounds, it might not be not worth comparing with item selection, because that is the purpose of item selection and faster.

for copying/moving envelopes i don't see any advantage of regular selection over Area Selection. Same would happen for manipulating envelope values but at this moment reaper AS does nothing here.

[vitalker]

Originally Posted by deeb

destructive on the bounds , if an item or AI is not fully inside the area that item or AI will split when applying something, so per example copying that bit of item will have to be considered as a new item, so per example if that item was a pooled item it will have to loose this status.

Okay, it makes sense now. You are right. That's why we can just select items.

[deeb]

but if reaper devs are willing to go deep on the possibilities that might arise on the splitting, on the pooled example i just wrote:

-- they could make pooled items with different offsets or something, but still item is splited but the advantages of item selection are minimized

And that could be actually good idea ...

Also another typical split constrain is the looped status, .. but if they do something like pooled loop /offset item , again item selection advantage also minimized. I am thinking very abstract now and i might be not thinking correctly. I need to open reaper which i won't do now.

This was a limitation example that could be skipped, at some point advantages could be really minimized, but only they know.

[deeb]

So relatively what has been written, i guess it's useful to be aware of this, as it's a very appropriate feature for Area Selection (Automation Items should be obviously included).

Request Thread: MIDI items: Options and actions for pooling MIDI when splitting items

Originally Posted by juliansader

REAPER has several options, actions and mouse modifier functions that pool MIDI when *copying* MIDI items.

However, we do not have any options or actions with which MIDI can automatically be pooled when *splitting*.

Pooling of MIDI items when splitting has at least three advantages:

1) The split point can be moved.

2) If a MIDI event is edited in one of the child items, and the split point is then moved across that edited event, the edit is still reflected in the other item that now covers that event.

3) Since each item doesn't retain a full copy of the MIDI data, the project file and backups don't grow huge.

DISabling the option "Allow trim of MIDI items when splitting" shares advantage (1), but may result in large files if a large MIDI item is split into many parts.

At present, in order to pool MIDI when splitting, the user first has to make a pooled *copy* of the item. Once the MIDI item is part of a pool, subsequent splits will keep each child item in the pool.

@https://forum.cockos.com/showthread.php?t=236192

[Stroudy]

Originally Posted by EvilDragon

It is painfully obvious now that some improvements regarding splitting MIDI items are in order. We need to be able to NOT have all-notes-off at the MIDI item end, there needs to be MIDI event spillover, optionally of course.

Absolutely THIS ^^^