imagine that these 3 notes are a synth chord with a long-ish filter attack sweep. what will happen to the audio result when you split them, creating 6 note ons and 6 note offs instead of 3 of each? it's a completely different melodic phrase than the one you had before stretching. this is not a solution and assumes the user has created an Area Selection either in between notes or in areas where no midi notes exist.
(my) expected behavior would be that the split would occur 'behind' the existing item, so that the notes (including noteoffs) before/outside the stretch-edge would be unchanged, while notes under/inside the stretch edges would be stretched. note ends should be allowed to exist outside of midi items, while still being associated with the item in which they originate
The split is expected as discussed in previous thread. Split is the only way to keep parallelism in case area is selecting audio and MIDI. If the midi item is not split how can you deal with this? https://forum.cockos.com/showpost.ph...4&postcount=10
The split is expected as discussed in previous thread. Split is the only way to keep parallelism in case area is selecting audio and MIDI. If the midi item is not split how can you deal with this? https://forum.cockos.com/showpost.ph...4&postcount=10
the midi ITEM can be split - the midi NOTES contained therein should not be split at AS edge. note-ends need to be able to extend beyond the item endpoint.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
The split is expected as discussed in previous thread. Split is the only way to keep parallelism in case area is selecting audio and MIDI. If the midi item is not split how can you deal with this? https://forum.cockos.com/showpost.ph...4&postcount=10
Simply stretch the MIDI event positions *inside* the MIDI item without splitting.
The audio item is not split, so splitting the MIDI would not keep parallelism between the items.
A potential problem is that the audio time-stretch remains visible as a stretch marker and can easily be removed later with an Alt+click, while the MIDI stretch will be less obvious.
Modifying the MIDI event positions themselves is not a good solution, it would run into all kinds of quantization and resolution problems, and it's essentially destructive.
What I think we'll do is add the ability to prevent retriggering notes at media item edges. This will probably wait a little while though.
What I think we'll do is add the ability to prevent retriggering notes at media item edges.
a situation where i could see this being a problem is if a phrase/item (intentionally) ends on a note and the next phrase/item begins with the same note - this new note would be lost in the scenario you describe.
similarly, if someone is using 8th note hats (for example) and their start/endpoints are quantized to grid, you could lose the first eighth note of every item.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
Perhaps it can depend on the underlying source: If the note in the lefthand item extends past the visible item boundaries, and the note in the righthand item starts before the visible item start, then don't re-trigger. If the notes do start and end at the item boundary, the do re-trigger.
esp if that applied to midi recorded in a looped section via overdub... i've long loathed the unwanted new note on that occurs at loop start if you hold a note over the loop endpoint
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
... yes, loop-recorded midi is a good example, but IMHO this is the most desirable behavior in general:
Quote:
Originally Posted by mccrabney
the midi ITEM can be split - the midi NOTES contained therein should not be split at AS edge. note-ends need to be able to extend beyond the item endpoint.
I'd love that for ordinary MIDI item splits as well, actually! Of course, the internal representation used by Reaper can make this outcome easier or harder to implement.
Modifying the MIDI event positions themselves is not a good solution, it would run into all kinds of quantization and resolution problems, and it's essentially destructive.
Simply stretch the MIDI event positions *inside* the MIDI item without splitting.
The audio item is not split, so splitting the MIDI would not keep parallelism between the items.
A potential problem is that the audio time-stretch remains visible as a stretch marker and can easily be removed later with an Alt+click, while the MIDI stretch will be less obvious.
FOr me, as I said in previous thread, the best solution is split and stretch at borders for MIDI AND AUDIO (and video, and image,...)
stretch markers are'nt the best solution to stretch in a lot of situation because it add sometimes strange pre ring and "wobble effect"
I made a video so you can hear by yourself what i mean (hope youtube compression will not hide it too much)
Everytime i use Stretch markers, I get the same kind of problems : on drums, on guitars, on bass...
On sources with not too much transient and/or low end, it sounds transparent enough but for most of music application, it's not the best choice
I'd love that for ordinary MIDI item splits as well, actually! Of course, the internal representation used by Reaper can make this outcome easier or harder to implement.
This is what the setting Preferences -> "Allow trim of MIDI items when splitting" determines. When disabled, split notes actually extend past the visible item boundaries.
When disabled, split notes actually extend past the visible item boundaries.
^ in the context of the last few pages, this is not what we mean here when we're talking about allowing noteoffs to extend past the item endpoint. we mean having items where noteoffs hang off the end of the item, like in this childish illustration:
in the 2nd graphic, the noteoffs exist and are played when the playhead passes them, even after the midi item end bound. this makes for really good overlapping behavior for pickups and other melodies that cross sensible splitpoints in midi items.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
If you don't split the MIDI AS, then how do you determine the length of what is being stretched? If you make a precise Area Selection and the end of the AS lands 3/4 of a way through a midi note and you have included an audio item in the same AS of the same length as the midi item, Reaper would have to recalculate the length of that last midi note to 3/4 the length. Because if it didn't, the stretched midi AS would never match the stretched audio AS which would be the desired behavior.
I keep my tick resolution extremely high so I'm not so concerned with slight differences between the midi stretch relative to audio. But unless the AS calculation determines a new midi note length every time, then not splitting would result in a difference between the two stretches (midi and audio) that is a lot more than just slight. That seems like a lot of onus on Schwa because now we aren't just talking about area selection, we are talking about recalculating every midi note length inside of an AS.
The other disadvantage of not splitting the item and just stretching inside the item is the midi information to the left and right of the AS. If the item is split in the bounds of the AS, then you can easily mute, delete and move that material. If it is not split, you then have to go into the midi editor to edit it and in this case, the AS material may be overlapping the same area as the previous information making deleting, muting, moving etc. MUCH harder. In fact, it would probably get pretty ugly having the stretched AS overlapping other midi events not in the AS in the SAME item. As someone else mentioned, a stretch marker implementation for midi could be a solution for this, but until this can be hammered out, I'm voting for staying with splitting.
Yes, I’m definitely also in favor of splitting the item. Anything else doesn’t make sense. If you edit an existing portion of an item, it should be altered without affecting the non selected area.
the midi ITEM can be split - the midi NOTES contained therein should not be split at AS edge. note-ends need to be able to extend beyond the item endpoint.
Unfortunately not cutting the notes will create a bunch of other issues. Like: when you glue two items together and they include the same notes (overlapping), then those notes will de deleted. That’s a very undesirable behavior and I definitely vote against it.
^ yet present and celebrated in classic midi sequencers
stevie, i'm not following your issue description, would you please rephrase?
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
It's incredible how still so Manny things related with AS and it's workflow need to be done and the concern is already trying to do magic tricks with a tool which by nature is destructive. We should know what we are doing ... If people start doing if then else operation with area selection here we go again for the matrix workflow.
Area selection is destructive on the bounds. Item selection is not. Use each when appropriate.
I know when I split 1 note I get 2 notes. If the result is not this it is not splitting.
I have 2 options:
- i split, and i know the problems that might arise, and if there is something to be done, i do it.
- or i don't split (or don't use the tool that might split like AS)
Let the tools be simple .. no magic and if then else .. simple, straightforward and objective.
Each tool have a purpose and an aim. It's part of our job and should not be reapers job to combine the tools in a clever, musical and efficient way.
What i want from reaper is allowing me to use the tools quickly and smoothly and intuitive, allowing my decisions done fast ... Unfortunately still AI's and manny aspects of reaper lacks about this... and that should be reaper primarily focus and not trying to do smart complex if then else tools and functionalities while being dummy on the workflow...
examples of this just in this thread:
Quote:
Originally Posted by deeb
I'll write some disadvantages of not using a ghost:
- we loose the sight where it comes from [edited: experimentally done]
- we are not really sure what we are substituting
- we mess with the audio output while we drag in random ways
- it is very useful while in play mode to drag an area (specially envelopes) and while previewing the output wait for the right moment to drop it, doing so when it feels right and without messing the audio before (in random ways) - so it's useful to have a ghost area already being dragged near the playback cursor waiting for the right moment to drop it.
Quote:
Originally Posted by deeb
If you want to experiment more, .. while dragging there should be no changes commmited, make a transparent ghost area with an "allow" or "not allow" sign with a transparent background , .. and commit only after drop !
Look at other softwares (i sent Schwa a video some time ago)
Quote:
Originally Posted by deeb
They are experimentally changed :P ! go go !
Quote:
Originally Posted by deeb
This still does not feel right to me:
as soon as we start doing another selection , previous one should be clear.
Current implementation has the advantage that after doing alt and drag click we still can press shit and add to selection , but looks strange:
Also, when we want to remove area selection , i would feel natural if by pressing alt outside of selection , that area would disappear, no need of left clicking outside, .. that menu appearing makes me nervous, .. i feel in trial and error to clear area or redefine a new one (too manny mouse and left clicking and alt , non alt swapping):
Quote:
Originally Posted by deeb
I just tried this now, and after pressing to delete area content i feel like the area should disappear. What would i want to use the area for?
It's incredible how still so Manny things related with AS and it's workflow need to be done and the concern is already trying to do magic tricks with a tool which by nature is destructive. We should know what we are doing ... If people start doing if then else operation with area selection here we go again for the matrix workflow.
Area selection is destructive on the bounds. Item selection is not. Use each when appropriate.
I know when I split 1 note I get 2 notes. If the result is not this it is not splitting.
I have 2 options:
- i split, and i know the problems that might arise, and if there is something to be done, i do it.
- or i don't split (or don't use the tool that might split like AS)
Let the tools be simple .. no magic and if then else .. simple, straightforward and objective.
Each tool have a purpose and an aim. It's part of our job and should not be reapers job to combine the tools in a clever, musical and efficient way.
What i want from reaper is allowing me to use the tools quickly and smoothly and intuitive, allowing my decisions done fast ... Unfortunately still AI's and manny aspects of reaper lacks about this... and that should be reaper primarily focus and not trying to do smart complex if then else tools and functionalities.
In my humble opinion, the problem is the same every time when it comes to new feature in REAPER. Basically, many users give their opinion on the "proper functioning" of the feature based on the behavior of their crappy EX DAW without taking architecture, functionality and global reaper behavior into account. THEY, they know, they have a more than valid argument: "they used a DAW that costs more!", Is that they are necessarily right.
Stretch markers, automation items, it has already been the case, suddenly, I have the feeling that the devs are trying to find a balanced compromise that ultimately does not go all the way. Personally, as far as I am concerned, the arguments which contain "in PT, in cubase, in SO4, ..." are not admissible because they are closed softwares which have an ergonomics with a common thread. In short, trying to make REAPER look like another app is the worst possible idea. Devs can actually be inspired by interesting features but it must remain an inspiration and not a true copy not consistent with the rest of the software.
Other DAWS are always good references, it's part of devs job to filter what are the structural limitations and advantages of implementing them.
The problem is: there is some tendency from users and Devs seem to like, for creating complexity on the tools and if then else logic for this tools. So they loose the objectiveness.
And then for some reason some of the workflow is turned as secondary while should be first. Maybe because they are details and the feature still exists without them, but the problem is that as users we will be struggling with this little details and facing them constantly in every project. Personally They make me nervous, i feel like begging: "errrrr, damn Reaper why you so dummy in this simple thing ..." but hundreds to thousands of times per project. In the things we are supposed use constantly.
I feel this specially in AI, envelopes lanes and hopefully won't happen in AS .. but ...
Relatively to the 1 page topic about timestreching with AS, I don't even remember seeing any DAW doing time stretch with Area selection per example.
Is there any?
After Area Selection and it's details is well cooked then yes: Create AI's from area selection, glue items and AI kind of stuff and EnumAreaSelectionRanges() will eventually happen and appropriate for the tool, but until then please care about the details.
^ yet present and celebrated in classic midi sequencers
stevie, i'm not following your issue description, would you please rephrase?
Yes, here's a GIF.
This is a script that will heal the cuts on two different items. The first item has note ends that overlap the item end. When executing the heel script, the notes of the adjacent item are deleted.
^ thanks, i understand what you were saying now. that shouldn't happen.
i don't know how the "dangle" suggestion would make it worse than it already is, but i agree that it shouldn't happen in any case.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
In my humble opinion, the problem is the same every time when it comes to new feature in REAPER. Basically, many users give their opinion on the "proper functioning" of the feature based on the behavior of their crappy EX DAW without taking architecture, functionality and global reaper behavior into account. THEY, they know, they have a more than valid argument: "they used a DAW that costs more!", Is that they are necessarily right.
Stretch markers, automation items, it has already been the case, suddenly, I have the feeling that the devs are trying to find a balanced compromise that ultimately does not go all the way. Personally, as far as I am concerned, the arguments which contain "in PT, in cubase, in SO4, ..." are not admissible because they are closed softwares which have an ergonomics with a common thread. In short, trying to make REAPER look like another app is the worst possible idea. Devs can actually be inspired by interesting features but it must remain an inspiration and not a true copy not consistent with the rest of the software.
my 2 cents
Sorry Reno but i don't agree with you. New users who are coming from other DAWS, they have a lot of fresh ideas that Devs sometimes should take into account as well.
For example Area Selection. Why not to listen to a user who has beem using area selection for 10+ years to another Daw? It's not a matter of competition or copying another daw... Because in the end there are many functions that are the same in every DAW. It's about making Reaper better and add more to it..
So this thing Reaper must not copy other DAWs is not valid at all, because most of the users want to have a better enviroment, they are not seeing it as a competition like who would copy the other...
Because this use will try to move all the tools to a new DAW to feel comfortable, even if something is relatively useless.
Then if this is the case we shouldn't have area selection in Reaper..
IMO it's not about satisfying one's needs to feel comfortable to his new DAW, It's about ergonomics, usability, having all the tools for proper editing.
And the user who has been using area selection for many years, then for sure he can add some ideas to the table. Again i don't see it as a competition between users or DAWs, as i mentioned before, many functions work the same in many DAWs.
In the end everything happens for the greater good.
Sorry Reno but i don't agree with you. New users who are coming from other DAWS, they have a lot of fresh ideas that Devs sometimes should take into account as well.
For example Area Selection. Why not to listen to a user who has beem using area selection for 10+ years to another Daw? It's not a matter of competition or copying another daw... Because in the end there are many functions that are the same in every DAW. It's about making Reaper better and add more to it..
So this thing Reaper must not copy other DAWs is not valid at all, because most of the users want to have a better enviroment, they are not seeing it as a competition like who would copy the other...
because a daw need to be considered in its entirety and consistency is the best key to avoid having a gas plant as software that requires a different methodology depending on the feature. For me, the "worst" beta tester is the one who knows 10% of the software, ignores that "what he can not do in rpr" is in fact possible. But, he concludes that it is not possible because it does not work as in X.
because a daw need to be considered in its entirety and consistency is the best key to avoid having a gas plant as software that requires a different methodology depending on the feature. For me, the "worst" beta tester is the one who knows 10% of the software, ignores that "what he can not do in rpr" is in fact possible. But, he concludes that it is not possible because it does not work as in X.
Yeah that's another case, which happens when a new user haven't learned Reaper yet, so he doesn't have a bigger picture.
But with AS, which has similar functionality to any other DAW for basic editing, it doesn't have to do about how much he knows his new DAW, since the workflow is the same.
And sometimes when this function behaves better in another Daw than Reaper, why not to point it out? We are all in the same boat, lets make it better.
I could start naming a few but AS for Reaper is not finished yet and more features and few functionalities will be added/ might change. Even though for me it's in the right direction : )
As an example i could name Cubase, S1 , Ableton.. All of them are a nice reference to AS, since it's been there for years. That's why some nice ideas from users who have been using some of these DAWs are welcome to me.
But again AS in Reaper is not finished yet, so i can't speak about it, only throw a few ideas when needed.
Ableton.. All of them are a nice reference to AS, since it's been there for years.
As I heard, Ableton doesn't allow you to select items indepedently. So you'll have the same as time selection, but you can choose not all tracks, right?
As I heard, Ableton doesn't allow you to select items indepedently. So you'll have the same as time selection, but you can choose not all tracks, right?
Yes in this scenario AS in Reaper, S1 and Cubase is better. But i like Ableton's AS with envelope manipulation where it's possible to edit separately each envelope lane on the track lane. Even though you can't select more than one lane, it would be nice if we could do the same in Reaper. And then it has skew, tilt, amp etc from the zones on each corner of AS, plus you can add envelope shapes which are stored in the menu. Pretty much what AI's have but it's been added in AS.
So you'll have the same as time selection, but you can choose not all tracks, right?
No , is a single simple area selection.
A single area selection is enough.
In my experience I have never felt the need of selecting items with an area selection, nor ever used multiple areas tbh even if I could.
Complexity Vs simplicity .. simplicity wins. All the tools we historically have in life have a simple and defined purpose, and do it well.. it's the crafter ability to manage and combine them that matters.
If it is enough for you, doesn't mean it is enough for others. And how Ableton deals with midi items when stretching?
Yes , but kind of. Having a good single Saw makes you able to make the job, if you need to use it 10 times you use 10 times. Selecting multiple areas takes almost the same effort as repeating the process with single areas, with much more higher chances of faults and mistakes eventually added and not ability to listen the mistakes you made on the selection can be very counter productive and confusing... So I am not sure .. but yeah it's only my perspective.
I am not using Ableton for long time so I don't know how selection works .. I am almost sure tho area selection does not have anything to do with timestreching midi or audio tho
while dragging there should be no changes commmited, make a transparent ghost area with an "allow" or "not allow" sign with a transparent background , .. and commit only after drop !
Linear Mode
