I have several overlapping MIDI parts on a midi track. When I click “show lanes”, they are shown nicely underneath in separate lanes. I wish to cut some of these parts with the scissors tool. When I try, it cuts all of the parts in that position across all of the lanes. How do I stop this happening?
I like the new C6 behaviour for comping a perfect take of something, but when I’m not assembling a composite take like that, it’s not a good way of working …
In particular, trying to get a GROUP of parts to be unmuted / muted together , seems very hit and miss, when there are many parts playing at the same time (eg hihats in one part, kick in another, snare in another etc etc., all layered up) They are turning on and off like a christmas tree at the moment. haha.
It’s worse when the start points of the MIDI events dont match each other perfectly… I think Cubase has a hard time figuring out which midi parts are actually related to each other, so they unmute and mute in strange unpredictable groupings when you select one of them. It’s grouping them by start position I think : events with the same start position belong to the same “mute group” … But of course that doesn’t always translate to real world recording situations !!!
So I want to ungroup the lanes, basically, so they behaved like they did in C5 (ie. no automatic cutting)
I agree.
While I do like the new behavior for “comping”, I think it should be considered a New Mode (can get even more frustrating when muting events)… or at least, let’s cut through all takes only when using a modifier key.
As regards the multiple cuts (seemingly unavoidable), best I have found so far is… let it happen, then glue the other parts back together!
Another workaround would be to drag the takes down to new (separate) tracks.
No - no workaround, but I’ve been waiting for this topic to come up - hoping it’s not only me that finds something very wrong with the new lanes methods.
Very nicely put, in the original post.
As for me - I rarely complain, and normally learn to love the way Cubase evolves, but I cannot see myself using Cubase 6 for my studio work unless something changes here.
For Audio Comping - it’s great, as you said above, the way it now works when all takes in lanes have a similar timing. Snip & click - couldn’t be simpler.
But we record a lot of stuff where, the musician / singer might loop around a chorus or something and Ad-Lib … and we catch some great stuff this way. Of course nothing in the lanes lines up afterwards (each take is very different) and then the auto-cutting of all of the lanes becomes a real problem.
For Midi - I used C5 lanes, on drum tracks, with diff. instruments in diff. lanes - all playing together. Again having all lanes cut when I snip is NOT what I want.
There are some occurances, when I just click on a MUTED midi part (that I have earlier muted with the Mute tool) to select it … and it becomes Un-Muted !!! (and sends-to-back all the other lanes) … imho something muted with the mute tool should ONLY be unmutable by using the same tool.
I never use part grouping.
My personal hope for this to be useable again would be a switch per track for the cutting behaviour - and a change so that anything muted by mute tool (or info line) stays muted unless unmuted by same methods.
I don’t have C6 yet so I’ll keep this to what I think the problem is… Take with a grain of salt until I can confirm (soon I hope… Come on UPS drivers … the ice isn’t that bad!). The only reason I’m commenting is because I use the take system extensively on almost every track of every project I’ve ever done. I only want the new comping process on a very small subset of those takes. But, where appropriate it will be absolute gold. It just isn’t appropriate for the majority of the takes a make.
In my mind I was hoping that you (Steinberg) have ADDED an ability to the old take system. But it seems from the OPs comments that you have REPLACED it.
There are many uses for takes. Two of the primary uses for take are.
Loop recording multiple but independent passes for quick build up of song structure. This can includemutliple instrument, patches and phrasings per pass.
2)Loop recording to capture a single version of a specific passage.
My personal opinion based on this same discussion on other forums, is that people confuse “takes” and “comping”. What I was hoping is that the current take system had added a comping tool option. Because, the editing needs for just those two scenarios is completely different.
It sounds like from the OP comments, that some of the editing/comping functions from the prior take system no longer work like they used to. IMO that would be bad.
Thanks for the reply!
I would like the MIDI lanes to behave like they did in C5 when lane type was set to “Fixed”. All parts on the lanes for that MIDI track are completely independent from each other.
That is, any edit operations on one MIDI part (sizing, cutting, muting, unmuting etc) had no effect on any other parts in other lanes. There was also no automatic muting/unmuting when using the object selection tool
You could implement this by changing the “lanes” button on the MIDI track panel to have 3 modes instead of 2
“Off” - lanes off (as now)
“Auto” - the lanes operate as C6, with linked edits, parts mute/unmute on object selection
“Manual” - the lanes operate as C5, no linked edits, no mute unmute on object selection
I think I’d be happy with that solution too (in any case, I really do feel that this new behavior should at least be switchable somehow… or, alternatively, a separate “Comping” button).
Here’s one, of many, instances where auto-cutting of all lanes gets in the way.
Note Lanes one and two, which have long held notes, about 4 bars long.
The fast bit in lane 3 is what I want to edit. I like the bit between bars 3 & 4, so I want to snip this, and repeat it 4 times to fill the loop
See what happens to my long notes in the upper lanes
Notes that I didn’t want to change have been split (and now retrigger in the wrong places).
I only wanted to edit lane 3, but the upper lanes have been altered too. Not cool.
So let’s try with the range tool instead … ??
Note that I copied the part to a LANE - but instead a new TRACK was created … ((bug??))
(happens with audio too…)
Yes it does, because MIDI tracks can play back more than one part simultaneously.
By having different groups of notes in different parts you can move thinjgs around easier (eg
for a drum machine VSti I frequently put hi hats in one part, kick in another, snare in another…
MIDI lanes shouldn’t be just for comping, the lanes are a creative workspace for combining MIDI parts in various interesting ways (well, they used to be before c6)
Not everything that gets recorded in MIDI, needs “comping” in the traditional sense !!
I defy anyone to disagree with that statement with a sensible argument.
Thanks for the additional information. You should maybe start using the Resize handles for MIDI Parts instead of doing cuts (one open question for me still is, what you exactly want to do with the snippets after cutting (delete them, use them for copies?).
The old Lane system was quite a mess sometimes and did some things not very logically. When we started to rebuild the Lanes for audio comping we wanted to streamline its operation in favour of not getting rid of what you do not want to be part of a comp - but instead focussing on what you want to keep. The result is a much faster workflow. We also wanted to add consistency when comping with MIDI as far as possible. You are right to say that MIDI can not be treated exactly as audio but there is one use case where you want to work the same way: Recording e.g. a keyboard solo performance in several cycles to comp the best take after it.
The other one is the mentioned Drum Parts workflow, where you want to hear multiple parts with different notes at the same time on one track.
But both can be done in Cubase 6. New things do require some adjustments on how to approach the working with it. The general consensus is, that the new Lane system works much better for the main use case and that is Comping. It always was about this theme, also with the old Lanes.
Hi Christian,
if you think Steinberg will maintain the current Lanes behavior, might I suggest a different Feature Request?..
a Menu item, “Explode Lanes of Selected Track(s) to new Tracks”?
That way, we could keep the convenience of recording in Lanes, but, via this option, convert the result to separate tracks, to enable editing “the old way” (without having to move the Lanes manually).
I think Christian wants to know what WE want to do with the parts, once we’ve snipped them ??
Could be anything Christian.
One example … fits the first video above (almost)…
I’m a rubbish keyboard player.
I sometimes use “Stacked no mute” mode to build up a keyboard part in layers (on an Instrument track).
Lets say I’m playing HalSonSE - Piano String patch.
Start recording in an 16 bar loop.
First pass 4 notes, each about 4 bars long
second pass (lane 2 while listening to lane 1) 4 harmony notes, half octave up.
So far I have done a “left hand octaves” thing.
Drop out of record & practice a bit.
Find a nice (right hand) arpeggio to add.
Drop back into record (lane 3) while lanes 1 & 2 play back.
Sounds lovely.
…but I played the arpeggio badly in 2 of the 4 bars.
I want to keep bars 2 & 4 of the arpeggio, delete bars 1 & 3 of the arp. and have lane 3 play bars 2,2,2 & 4.
See first video above that when I cut the parts in lane 3, lanes 1 & 2 get corrupted.
…
At least give us a modifier key (even if it’s alt-ctrl & shift all together) that stops the other lanes ((audio OR midi)) from being effected by the scissors.
With audio, dont forget people who like to ad-lib & do something different on every lane !! Disaster to have all the lanes cut up in the wrong places. (we ad-lib midi here too !!)
I must say I have not used Cubase 6 on a real session yet so can’t give too much input on lanes but I did liked the way the old lanes works for editing unless I was doing a cross-fade, that would always mess up if it had more than 2 stacked up. Has anyone tried this yet, whats it like?
I do like the way the new lanes stay the same hight now. It was very hard to cut into a vocal takes with too many stacks before. I will try and make some time after my clients have gone this weekend to do some tests on lanes and post back here with some suggestions.
I have a slightly different issue with the new Lane behavior:
For comping vocals, etc, it’s excellent and I was looking forward to it.
However, another way I use Lanes frequently is for multiple takes of whole songs - with no click.
After a take I group all the new tracks and then move on to the next take.
Sometimes it’s even a different song.
The idea is I have an audio track set up with EQ, effects, whatever for each instrument and all the takes are nicely stacked. Don’t have to create new tracks or projects.
When I want to listen I mute all but one group. Muting/unmuting just one lane on a track lets me hear the entire band for that take. I can even cut and edit within the groups.
This is impossible with the new function.
Any suggestions on how I might achieve this same behavior in C6?
I really would love to see an option as discussed above.
What I do is record all the bands songs in one project and on the same tracks, but one song after the next one . This way I can jump from one song to the next and so on when over dubbing parts or replacing guides. I use the project like a reel of multi-track tape as one project holds all songs in a row. If you haven’t already tried working this way it might be worth a shot and may give you what you need. At least you can use the lanes for takes within each song.
JMCecil has, imo, made an important point about logical level, by which I mean: Comping is a function of loop-recording, loop recording is not a function of comping. There are many uses of loop recording, of which comping is one. C6 has made great advances to SOME methods of comping by ADDING elements, and those DEPEND on loop recording. Loop recording is, as it were, the ‘parent’ function.
I urge that old behaviour be a retained choice.
IMO, Christian is right in saying that new things require adjustment, and it is right for Bredo and others to pinpoint their personal favourite use of lanes. Consensus need not result in losing the present streamlined workflow for those uses of looping which are unconnected with this * new variant of comping.
My main intended thrust of this post is to promote the following principle: There is no consensus which will account for individual ecology and preferences. When evolving, if practicable, do not take away old choices, but do add the new choices.
Offer people extra choices to do what they are already doing, but unless unavoidable, do not take away their old choices.
Historically, [cf the manual for version 1], the Steinberg Principle was ‘try something … if you want to do it, guess and click, and it will probably work the way you wanted’. This was in the early days, and avoided preconceived notions of how people might want things to work. It simply accepted that people might want to work … in whatever individual ways they might want to work, and this was honoured by the simple process of retaining and developing ‘things that could be done’, and as many ways as possible of doing even the same thing. This early stage of conceptualization did not require consensus … it was a winning PRINCIPLE.
Why ask people to justify their professional workflow, when the principle of “Add New Choice and do not take away old choice Unless it Wrecks Crucial Coding Requirements,” bypasses not only present friction and embarrassment, but guarantees future integration?
‘Lose Transparent Parts’ is a good example of Temporary necessity. It is like when a traffic ‘Diversion Sign’ ruins our journey home for a few weeks while great improvements are being done.
‘Lose compatibility with Windows 98’ is a harsh but inevitable one-way break with the past, because otherwise, new choices would be UNable to be added.
The question **“Why would you want to do something in a way you already do which is streamlined just the way it is?” does not make sense to me unless retaining the old choice necessitated an active bottleneck to development.
I emphasise that this post is not intended as only a feature-specific whine or a whinge.
It is about more than just this - according to me- ‘Reduction of Loop Recording to Comping’ feature.
It is about moving beyond any ‘one person’s’ or ‘one consensus’ preconceptions of purpose and means, and into a model of adding, wherever possible, choice on top of what is already working.
Best wishes
Glyn
\
new variant of comping: [paraphrase]‘focussing on what we want to keep RATHER than what we want to delete’[/paraphrase] … imo this ‘rather than’ removes an important half of the general human selection and decision making process. I’m happy to reason it out, but reckon it’d be for a different post or thread.
** Christian - I appreciate you are questioning to gather info on what users want, and to help them find ways of achieving it. I can see that in your style of writing here and elsewhere. Does it make sense to you that the principle ‘retain the old choices as options whenever possible’ guarantees a high level of satisfaction for customers who are beyond your reach during earlier phases of product/upgrade development cycle? You would not even need to know the ‘Why’ of those old choices - the reason might even be senseless to you and to me, but if there is not a high cost in terms of coding-requirements, then why miss out on an assured ‘success’ in addition to delighting people with the new elements you have worked, with the aid of your colleagues and beta-testers, to produce?
(in any case, I really do feel that this new behavior should at least be switchable somehow… or, alternatively, a separate “Comping” button).
