Question about N5.5 Events "on top" behavior

Mh, they are gray, I would say :slight_smile:

Ah, yes… But this is too slow for me. I’m using alt+click all the time. And need modifier to use it with alt+click.

Hold Shift and select your events

Yes, but if you shift+click on another event, it’s ADDING another event to selection. And it doesn’t allow to move event avoiding its activation.

Yes, when set to “transparent events”! But now look:

tested the new lanes feature again but could not use it due to the awful on top behaviour.
btw, what is so new in this feature? there were already lanes since n3 iirc.

you can still use the old and much more useful editing in the normal tracks. this behaviour is still the same as in n5.

…you do know some of us do some audio editing for post production audio?
…where the new lanes and on-top-with-a-click editing is just killing workflow.

I actually think there is some implementation flaws. I’m pretty sure the feature was designed 100% this way, it must be a small “interpretation” bug between program management and developer(s)…

Pål

Don’t you agree that it is highly irritating that if you just want to cut an event with alt+click, that the event suddenly is selected for playback, even you didn’t want it to be?
So you have to remember WHICH event originally were the playing one.
If you are working with a lot of lanes and many small events, this is close to impossible.

There MUST be some form of concept error here. Either with double use of modifier keys (shift also multi selecting events being one), or a design interpretation error.

Pål

This is currently my main problem with N5.5 and this is why I went back to C5.5 - hoping that this will be changed someday. Because this is a general behavior. When editing 20+ tracks simultaneous or just in the lanes.

And this is why I can’t use new lanes.

The new concept is bullshit.

I do not want to split ALL events, I do not want an event to jump on top just because I edit it in some way (sometimes I just cut someting out to place on top) - I do not want that THE COMPLETE event is on top when I only want a part of it to be playbacked.

The concept works when you compile some easy stuff which is sliced at the beginning of the bars with no overlapping. Here you might safe a few clicks.

But what a complete mess of takes during recording difficult parts? Takes featuring the full song, takes only the chorus, maybe 5 of them, then another 10 takes of difficult parts - usually during that process there is a point where events are just a few millimeters in high. Now clicking on the “full take” somewhere below that chaos just because you want to cut out a phrase which looks like it was a cool take - it will F*CK UP everything what you did, left you in a chaos of snipplets - you have to reselect the wanted events again - which is impossible when dealing with projects 60min long and featuring 500 or more takes on one lane.

PLEASE - the new lanes needs modifikation!

On top behaviour is not good!
Going back to 5.1 !!!

Things like this should NOT happen. Who need this new behaviour???

I don’t know…

Sometimes I have the feeling that Nuendo Developer are not REALY using Nuendo, same for beta-testers.

The ideas and concept and design etc etc is as always quite brilliant - but so often there is just something small what renders the whole thing useless for the daily hardcore use.

Ok - often things are depending on the individual workflow. I know about dudes who barely record more than one song in one project, barely recording more than one track at the same time, barely editing more than here and there. Most likely they will never suffer from bugs like “if you have more than 666 events on one track (switched to lanes), event 667 and above will be away after close/reopen Nuendo”. (No joke, this was there some years ago…)

Don’t touch beta-testers. :imp:

Yes I do - because I don’t understand why they don’t complain when things are messed up…

Why nobody said “well, great feature, BUT”…

Really, why? Why do you think so?

Because in every release - as good as it might be - there are so many “design errors” - things where zillions of users complaining about later. I am not talking about small bugs - they are usually no showstopper and might have been overseen as well as it might was not possible to fix them in time - at some point a release has to be released I would say…

In this particular case: Why there was nobody who went into serious editing trouble because of the new “you touch it and then it is on top” behaviour? Not only regarding the lanes - but when moving events on regular tracks as well.

Again, why do you think nobody “went into serious editing trouble because of the new “you touch it and then it is on top” behaviour?”

Because in my humble understanding of the situation a beta tester is a USER - ( while a developer/programmer might not spent that much time with serious recording/editing/mixing because this is not his job) - and in a perfect world the beta-testers are the “real life frontend” of the development-chain…

That means:

Development implements a feature from what they think that everything is great and cool

Betatester try that and give feedback: Dudes, this is great, BUT…

Development says: ah, cool - well, we were not aware of that because we are not using the application in a serious way, so we will chance that

:slight_smile:)

Am I dreaming of a perfect world?

Sometimes this works.


:slight_smile:> )

Am I dreaming of a perfect world?

Partially…

I should add that I am not here to blame all or certain beta testers or whatever neither the Steinberg developers…

I just can’t understand why basic features are touched/modified - and that in a very bad way.

Why are basic features that often changed? This kills the workflow all the time! I am not an hobby-engineer who is able to spend his time trying out things…

I agree.