If you are working i.e. with drum hits directly in the timeline or many other situations causing many little snippets itīs a real PITA to work with them in Reaper...like duplicating, selecting not to speak of loosing any ability for looping the whole group...
Grouping doesnīt help neither very much as the fact alone that you often donīt have any item ends reaching exactly on the next grid/bar and the extra need of a seperate command to select all in a group...
Glueing them together eliminates any editing posibilities like changing the fades of the single hits/snippets...
Looking at many others like Cubase, Studio One or even Bitwig I am really jealous of their ability to put these hits/snippets into manageable containers of user defineable size and leaving the actual audio items intact...
The general overview alone is already a complete different experience...
Having a i.e. a few drum tracks layed out with single audio items as drum hits is such a mess to look at respectively to keep a general overview of them...
Am I the only one missing a feature like this or am I missing some secrets to make my life easier??
It's not easy without knowing your methods. I've not had much problem, TBH. I like the way Reaper lets you do everything in several ways, but I do live with the feeling that everybody else is doing it right, and I'm doing it wrong.
Quote:
Originally Posted by Trancit
you often donīt have any item ends reaching exactly on the next grid/bar
I crack down on that crap immediately. I set a time selection spanning from the end of the item to where I want it to end, Insert >Empty item, and Glue those suckers together. Now I can copy and paste. If it's a snare on the 2nd and 4th beat, I can insert an empty space spanning the entire bar, and glue it to the two snare hits. Now I can easily loop the whole thing across the whole song. I often find myself splitting those loops to mess with parts of the arrangement (reduce gain on specific kick hits, remove snare hits), and maybe gluing things back together again....
Quote:
Originally Posted by Trancit
If you are working i.e. with drum hits directly in the timeline or many other situations causing many little snippets itīs a real PITA to work with them in Reaper...like duplicating, selecting not to speak of loosing any ability for looping the whole group...
Yes, it can get very messy, especially when there's a lot going on in the project other than drums. That's why I sometimes prefer to arrange drums independently, in some other project. I was doing this before Reaper had subprojects (I still haven't explored these), and before Reaper even had project tabs. Project tabs made it a lot easier. I render everything but drums to MP3, start a new project, import the MP3, cut any drum tracks from the main project and paste into the drum project, and get to work with the drums (and only the drums, of course). When I'm not working on the drums, they are represented in the main mix by an MP3 render of the drum project. When I'm ready to mix, I import the drum tracks from the drum project to the main project. There are advantages to rendering the drum tracks to stems at that point.
Another approach is not to work with many drum snippets in the arrange view at all. For hits that will recur frequently without changing (often kick, sometimes snare, it depends on genre etc), I will load samples into RS5Ks and progam the hits as MIDI. This creates the possibilty of putting the whole drum part on a single track, and still being able to program specific drum hits.... but I usually keep the main drum elements on separate tracks anyway.
There's always a balance to be found between the convenience of being able to change something right now and keeping things tidy. Eg, I can't mix the drums from the main project while drums are all in some other project, but it's probably a good thing while I'm supposed to be still focussed on arranging, and not yet mixing.
Looking at many others like Cubase, Studio One or even Bitwig I am really jealous of their ability to put these hits/snippets into manageable containers of user defineable size and leaving the actual audio items intact...
Never really had this problem so may be getting the wrong end of the stick, but why don't you make empty items of defined size and group them to your audio snips and use them for arranging (you can even hide or minimise the audio if it helps)?
I crack down on that crap immediately. I set a time selection spanning from the end of the item to where I want it to end, Insert >Empty item, and Glue those suckers together. Now I can copy and paste. If it's a snare on the 2nd and 4th beat, I can insert an empty space spanning the entire bar, and glue it to the two snare hits. Now I can easily loop the whole thing across the whole song. I often find myself splitting those loops to mess with parts of the arrangement (reduce gain on specific kick hits, remove snare hits), and maybe gluing things back together again....
...
Another approach is not to work with many drum snippets in the arrange view at all. For hits that will recur frequently without changing (often kick, sometimes snare, it depends on genre etc), I will load samples into RS5Ks and progam the hits as MIDI. This creates the possibilty of putting the whole drum part on a single track, and still being able to program specific drum hits.... but I usually keep the main drum elements on separate tracks anyway....
I often tend to stay away from glueing because of loosing any ability to shape the including single hits any further if needed...
Thatīs imho the biggest advantage of i.e. Cubaseīs and Studio Oneīs audio parts... you got one manageable clip containing the "original" hits with all settings like i.e. fades intact...
In terms of working with i.e. RS5K: For my needs itīs (and most of other samplers too) much much too limited for really shaping the sounds...
I am still searching for a little lightweighted drum sampler which has the features of i.e. Kick 2...
This thing is perfect for drum shaping with having a MSEG directly over the waveform reflecting immediately the changes you make on the waveform... this makes editing a breeze... but these outdated standard ADSR envelopes without adjustable slopes and without a hold parameter let me miss about 90% of what I really need/want...
So working with the audio directly in the timeline is still for me the most flexible way ...
Doesnīt take any CPU, nor RAM via resizing, fades and clip volume there is everything I want...
Never really had this problem so may be getting the wrong end of the stick, but why don't you make empty items of defined size and group them to your audio snips and use them for arranging (you can even hide or minimise the audio if it helps)?
This would be at best a wonky workaround for copying and duplicating but wouldnīt eliminate all the other problems...
Itīs really a pity that such a little handy detail nearly every of Reaperīs competitors got since ages and was already requested since 2008 didnīt got any attention until today...
Reaper DOES have a system to put multiple audio streams into a single item in the "take" system. The one you get with: Options-> New recordings that overlap an existing recording add a new take to that existing item.
I know this is geared up for the comp/take feature. Maybe you could make a custom action or script to commandeer this functionality? You'd have a multi item (audio stream) item. Not sure how you'd get it to let you drag an edge to loop it though.
This would be at best a wonky workaround for copying and duplicating but wouldnīt eliminate all the other problems...
Itīs really a pity that such a little handy detail nearly every of Reaperīs competitors got since ages and was already requested since 2008 didnīt got any attention until today...
I'm curious as to what the problems are - i do usually work with lots of separate drum hits, noises etc. but area selection and the nudge (duplicate) options etc. have always worked fine for what i do, but then again i've never used the container method you talk about, so i don't know what i'm missing, probably
I'm curious as to what kind of complex machinations compel Trancit to avoid gluing in an environment where splitting is still a thing. I'm not arguing for my way of doing things - just curious.
Quote:
Originally Posted by n997
I thought of subprojects after reading that.
In your opinion, can they be used for such purpose efficiently?
Subprojects are a very exciting development, I think - almost like having a very powerful sampler within a Reaper project, where another Reaper project is that sampler.
I'm curious as to what kind of complex machinations compel Trancit to avoid gluing in an environment where splitting is still a thing. I'm not arguing for my way of doing things - just curious.
The answer is quite simple... itīs simply much easier to edit already sliced items if needed later on than having to split everything again just because Reaper lacks of that quite simple functionality...
I mean the advantages are quite clear... having i.e. 20 audio snippets and wrapping them into one single item while leaving the single snippets intact vs. making the adjustments glueing them together working with them... of f*ck made an error... so splitting everything again before I can make adjustments to the single snippets again...
There are always methods one could argue to workaround...
At the very end itīs a workaround and works like all workarounds 100 times more complicated than having the needed feature...
Quote:
Subprojects are a very exciting development, I think - almost like having a very powerful sampler within a Reaper project, where another Reaper project is that sampler.
I am a bit scared about subprojects as I often heard they would be buggy, so I never tried...
Nevertheless itīs an interesting idea though!!
It’s convenient the way it works in Bitwig. REAPER is a bit more crude with glueing but I actually prefer it as it’s wysiwyg and more robust. You don’t rely on the software to properly assemble your bits and bobs. But yeah, different strokes.
I'm curious as to what the problems are - i do usually work with lots of separate drum hits, noises etc. but area selection and the nudge (duplicate) options etc. have always worked fine for what i do, but then again i've never used the container method you talk about, so i don't know what i'm missing, probably
For me, in the arrangement I mostly work at a zoom level of about having 32 bars visible on a 1080p resolution...
Itīs very easy to work at this zoom level with items of 1 bar or longer...
At this zoom level there is nearly no general overview over little snippets and every even slight editing forces me to zoom far in... out again...in...out again...in... out again...
The workflow in i.e. Cubase or Studio One: Take the snippets and put them into one audio part leaving everything snippet related alone and which is big enough to
1. keep the general overview and
2. big enough to select at this zoom level and one doubleclick opens the editor already zoomed in to edit and one click to close it... back to arrangement... done...
I would guess for this task Cubase and S1 are about 20 times faster...
What stands the first "R" in Reaper for??? Rapid???
Its convenient the way it works in Bitwig. REAPER is a bit more crude with glueing but I actually prefer it as its wysiwyg and more robust. You dont rely on the software to properly assemble your bits and bobs. But yeah, different strokes.
Bitwig has a very nice system too in this regard...
The only thing I like better of the others I mentioned is that there you can select a bunch of items and wrap them into one container while in Bitwig I have to extend the container first and drag the other items in...
Nevertheless: At least they implemented something working!! So thumbs up!!
If you are working i.e. with drum hits directly in the timeline or
many other situations causing many little snippets itīs a real PITA
to work with them in Reaper...like duplicating, selecting not to
speak of loosing any ability for looping the whole group ...
Yeah, this problem is known for a loooooong time already.
Quote:
Originally Posted by Trancit
Looking at many others like Cubase, Studio One or even Bitwig I am
really jealous of their ability to put these hits/snippets into
manageable containers of user defineable size and leaving the actual
audio items intact ...
And I am surprised that so few only realize that this is missing in Reaper.
I guess that most just do not create complete songs, only fractions?
Whatever, this is the fundamental structural disadvantage of
Reaper compared to other modern DAWs - IMO.
You can do repetitive arrangements for midi-items and
automation items by making "pooled copies". But you can't
do such arrangement with an area of edited audio-clips and
audio-fade-fragments.
Yeah, this problem is known for a loooooong time already.
And I am surprised that so few only realize that this is missing in Reaper.
...
Me too...
Of course this affects media composers especially rythm heavy ones where you need in first place very detailed control of many elements and less the traditional recording producers working with longer audio takes...
Nevertheless especially the products aimed at them like Protools and Cubase had this since the 90īs, Studio One and Bitwig at least since day one...
I think this is in first place to blame the fact for that we donīt got any Audio editor window, which would be even more handy for...
The next very big oversight in Reaper imho...
Who likes to work primarily in the timeline... fine... but this is neither a reason nor an excuse for the lack of any detailed audio editor...
Why do we got a midi editor (not that I dislike that we got one)??? There were many programms, which offered inline editing only...
Why is there the need for one editor and the ignorance for the other??
I never understood this especially by looking at the changelogs how many gimmicks were implemented perhaps a handful people can find use for...
Yeah, I know. If I remember correctly, Justin said we have subprojects and called it non-destructive glue.
I guess we could employ either these or just using empty MIDI item and grouping it with all other items to at least make some kind of "movable container".
What I like about the second is that you can use it in case your grouped audio items don't start exactly on beat/bar so you can easily move them around.
Are the issues fixed with PIPs?
I dont remember them all off hand, but one that killed PIPs as audio pattern containers was having to save each and every individual PIP in the project when you saved the main project.
__________________
Stop posting huge images, smaller images or thumbnail, it's not rocket science!
Are the issues fixed with PIPs?
I dont remember them all off hand, but one that killed PIPs as audio pattern containers was having to save each and every individual PIP in the project when you saved the main project.
PIPs work awesome, you just move items to subproject and the subproject gets saved in main project media directory. It's a really good workflow, completely transparent.
So it save sthe PIPs even if they alreday exist on the drive ? (Duplicates)
I donīt know, what you mean with "it saves..."
As far as I understood PIPīs and like this it works well:
I.e
- I made a track with some sound source and move it to new subproject,
- Reaper takes this track and puts it into itīs own project,
- puts start and end markers around the section containing events,
- saves the project file into your main project folder or subfolder inside if you defined it so
- and places a media item into your main project with a bounce of the subproject respecting the size and position of the start and end markers of your subproject...
Everytime you make a change to the subproject, YOU have to save it to include your changes into the media item in your main project...
If you save your main project there is no need to save the subprojects again and afaik Reaper doesnīt do this itself as this would have the risk that changes would be rendered into the media file which you perhaps didnīt wanted to make permanent...
I made several changes to my subprojects of the actual song and I got in my media folder of this song per subproject a ".rpp", a ".rpp-BAK" and a ".rpp-PROX"...
No additional copies...
Additional the .rpp file of the main project has a later timestamp when the file was written as the subproject .rppīs...
So my conclusion is that Reaper autosaves a subproject only at itīs creation but after that never again automatically...
All changes made to a subproject afterwards have to be saved by the user or they are lost!!
And I am surprised that so few only realize that this is missing in Reaper.
I guess that most just do not create complete songs, only fractions?
Quote:
Originally Posted by Sibben
Yeah, thats probably it! Not everyone is asking for the same niche workflow as you so probably theyre just horsing around and not working.
Niche workflow?
I guess you misunderstood. I will say something about this in the
second part - see below.
I really believe that Reaper's focus is on mastering, radio plays,
live recording and postproduction. Because the linear structure with
its markers, regions and automation is well suited for this.
But as soon as it comes to song composition, where not only linear
structures but also repetitions suddenly become important, things
look relatively bad in Reaper.
Quote:
Originally Posted by enroe
Whatever, this is the fundamental structural disadvantage of
Reaper compared to other modern DAWs - IMO.
Quote:
Originally Posted by Sibben
Really? The one fundamental flaw REAPER has happens to be the one you want. What are the odds of that?
Yes, it is a fundamental disadvantage!
Why?
A major advantage of DAWs over earlier tape machines is
precisely that they got away from the linear recording
requirement to record and they were enabled to really
edit and arrange the recorded parts. And one capital
element in arranging are repetitive structures. Music has
repetitive parts (unless you do very modern classical music
or free jazz).
Repetitive parts are an essential property of music!
And so it is very comprehensive that almost every DAW
supports repetitive structures: Logic is founded around
its folder-philosophy, Cubase has shared parts,
Samplitude also has folders etc.
Only Reaper fails at this fundamental feature: You cannot
pool-copy a subset of audio-clip arrangements (and yeah:
Subprojects are a poor cumbersome workaround).
So think about it twice: All the Synth- and effects-plugins
can be changed and added from elsewhere, they are not
bound to a specific DAW - thanks to the VST-protocol.
But the handling of repetitive parts is very DAW-specific.
And it is fundamental! And unfortunately here Reaper does
not look good.
If you like to go through the whole discussion please visit
"this thread".
I really believe that Reaper's focus is on mastering, radio plays,
live recording and postproduction.
And so it is very comprehensive that almost every DAW
supports repetitive structures
Only Reaper fails at this fundamental feature:[/color][/url].
Your missing the whole point of my post. I'm specifically questioning the way you argument and not the feature. You present broad generalizations, cherry-pick facts and make your personal expectations on what REAPER should be the basis of your argumentation. It's just not a serious way to discuss software features.
As far as I understood PIPīs and like this it works well:
I.e
- I made a track with some sound source and move it to new subproject,
- Reaper takes this track and puts it into itīs own project,
- puts start and end markers around the section containing events,
- saves the project file into your main project folder or subfolder inside if you defined it so
- and places a media item into your main project with a bounce of the subproject respecting the size and position of the start and end markers of your subproject...
Everytime you make a change to the subproject, YOU have to save it to include your changes into the media item in your main project...
If you save your main project there is no need to save the subprojects again and afaik Reaper doesnīt do this itself as this would have the risk that changes would be rendered into the media file which you perhaps didnīt wanted to make permanent...
I made several changes to my subprojects of the actual song and I got in my media folder of this song per subproject a ".rpp", a ".rpp-BAK" and a ".rpp-PROX"...
No additional copies...
Additional the .rpp file of the main project has a later timestamp when the file was written as the subproject .rppīs...
So my conclusion is that Reaper autosaves a subproject only at itīs creation but after that never again automatically...
All changes made to a subproject afterwards have to be saved by the user or they are lost!!
What do i mean by "It saves"
When we originally requested PiPs or actually audio parts, the idea was that you could save them as you would save any sample, so I could have a folder of audio parts, load them as I would any other sample, use them, chop them, change them, edit them, and Reaper would not need to save them or resave them to the project folder, like it wouldn't save any other sample unless instructed to do so.
Also, there is little to no reason that an audio part should create an entirely new file that needs saving, that is why PiPs never really caught on, an audio part would just be part of the main project file and certainly would not need to be saved whenever you make changes.
Example...
I load an audio part from my collection of audio parts, I edit it, I click save and I'm off, Oh shit, I used that audio part in twelve other tracks, and now non of them work anymore, extreme example but shows a silly mistake that would kill interest in these straight away.
So by the sounds of it the PiPs development didn't go much further than with all their problems intact, so for instance they would create a render to play back in the main project, so they are treated as audio files, not Project in Project as named, because a Project in Project would allow hosting of VSTi and VSTfx and be run in realtime, but on the other hand you still have to save as a project so it is not actually a container/part either as per the OP, it gets split in to a half way house between the two (Project vs container/part) and simply just didn't catch on for that reasons.
There was other issues too, I think the render was/is forced in to RAM, but obviously time moves on and that is less concern nowadays vs when PiPs first was a hidden option in Reaper, but still you wouldn't want to use a lot of big PiPs if that is still the case.
So as we stand, for them to be used as audio parts we need
Saved as part of the host project.
Option : Play PiP from RAM or HD.
For them to be used as real Project in Project.
Run in realtime.
Sadly it is the usual Reaper quandary, incomplete feature, not much interest, very little requests for making it complete, when the developer finally gets round to it, ends up one of a the majority of users most used features, go see how long I had to campaign for Automation items, and note how many people poo pooed the idea like it simply wasn't needed and was pointless etc etc etc, and now is one of the most powerful feature sets of Reaper and used by pretty much everybody.
__________________
Stop posting huge images, smaller images or thumbnail, it's not rocket science!
Ok, valid points if you look at it this way round...
I never read anything about it as it was implemented so I cannot comment on this but I have the feeling you want PIPīs to act completely different as what they do in reality...
1. more like .alc containers of Ableton for saving something for later use
2. more like a realtime one running in parallel to the main project...
All of this isnīt what I expect from them to do... so I am quite happy of how they work atm... though I do not have any deeper experience with them
I agree that the name "PIP" doesnīt really reflect what they do... I think the term "subproject" would be a better match...
Do you miss audio containers??
( -> REAPER = Rapid Environment for Audio Prototyping and Efficient Recording)
Linear Mode
