I don’t think anybody would care about the name. After all you are talking about removing the requirement to put midi events into a part. You are not talking about removing (optional) midi parts altogether.
Superb clarification!
If you use In-Line Editing you can basically ignore the existence of MIDI Parts for most stuff.
You’d get a taste of it but the In-Place-Editor only works within the boundaries of a midi part. You’d need to create a midi part from beginning to end of the project on each midi track and then use the In-Place-Editor for a simulation.
I guess it’s de facto for Midi, maybe. I’m not even sure any more. The “in-place” editor is probably what you’d like to use. But it’s not de facto for audio.
Events are still non destructive in a subtractive timeline sense yes, it’s when you want to add, group or merge them where it differs.
To merge two separate events into one you would need to render a new audio file, whereas parts allow you to do that in a non-destructive fashion and apply crossfades automatically to reduce any pops or clicks… Who’s fade is also non-destructive.
Anyone who deals with vocal or instrument events knows the advantage that comping offers, and that relies on the part system to exist. It’s a fundamental part of the DAWs design as far as I see it.
This idea that it’s some kind of bad habit I just don’t agree with, sorry.
Yes, that’s an advantage when it comes to editing.
Yes, if you create an empty part and just leave it there.
You see the results of your actions.
Isn’t it obvious by now? So many have already said why. It’s the same reason why you say things like “2 bar pattern”, “this phrase”, “this cadence”, “this chorus”, “this intro”. You put the events in the container, you name the container, you color the container. Then you act upon the container and it’s as if you are acting upon the collection of events within.
I don’t know, I don’t know, I don’t know.
You can also weed 1 hectare with a scythe. Please explain; how is it easier to go fishing with the range tool on a busy drum track, to find a half-fill somewhere about 3 measures before the chorus, instead of directly clicking on the part that contains it. (and is probably named “awesome fill that I will probably regret” and colored red.)
Do you not see the need to organize music in larger chunks? Are you ok with bars and beats? Are you ok with seconds? Because those too could be deemed overcomplicated if we get right down to it. You could stretch all events in the project to make things slower and squeeze them to make things faster. Who needs time? It’s all in the length. Who needs bars and beats? It’s all in the relative length of events among them.
And what would happen if I took a bunch of events with the stretch tool and pulled? They would fall right into following events and get jumbled. What would I do at this point if I wanted to select that collection of events again? Ctrl Click picking them out from within the fray? How is this better in simplicity than having two distinct entities that you can independently move, stretch, resize, glue, split? How is it faster? How is it more efficient?
You seem to care a lot.
People don’t get it because they got used to it , there are many unnecessary actions there
with the parts creation resize etc.
OK Why not for audio ?
I,m not talking about the arranger.
I just re-read you’re original post. Not very clear on what you’re driving at here. What is your point?
The fact that he’s going back and cherry picking little sentences to reply to from posts he’s already replied to makes me think he’s just here to argue and make people listen to his griping heh.
4 Likes
Monotremata this is rude.
You’ve got your opinion of the matter, the rest of us have our own as well.
I’d say the point is to question whether it must be compulsory to put midi events into a midi part or whether this could be optional.
We have already established that audio should be removed from this topic as audio parts already are optional.
1 Like
One difference is that Audio & MIDI Parts & Events operate at different levels of abstraction. A MIDI Event is a single thing - a Note, a cc message, etc. While an Audio Event is a single piece of sound which can be an entire melody with harmonies. percussion, vocals, whatever you want.
When you render a MIDI Part the result is an Audio Event and they both sound the same.
Audio & MIDI are kind of apples & oranges when comparing Events & Parts.
The sooner we stop thinking about audio in this topic the better.
The question that I asked myself was: What do I, as a user, gain from the requirement to put midi events into a container at all times? What would be the disadvantage if it becomes optional to put midi events into a midi part?
Midi parts are a great concept. They should be kept in the program. It is just the compulsion that I question.
In all honesty, I did not create this topic back then when I started to think about it. As long as there isn’t a really great point for changing the status quo Steinberg should not put resources into the endeavour of a massive re-design of the code IMO.
Well you are always going to need to put MIDI data somewhere, into some type of container. Without Parts that container becomes the Track. That’s a design choice that other DAWs have chosen & it works fine.
Conceptually it is viable but I can’t imaging it being practical to implement in Cubase. MIDI Parts aren’t just data structures in Cubase. They are fundamental to the underlying architectural design of Cubase. Things like that really don’t become optional in a preexisting design.
While it might be possible to design a new car that doesn’t use car wheels. You really can’t retrofit a current car to loose the wheels - at least not in any practical manner.
I think the closest they might get is some kind of ‘stealth Part’ which exists for the length of the Project and has no visible elements. Maybe a Preference.
I still wonder what the actual advantages would be. Just “simplification” doesn’t cut it for me. Simplifying doesn’t necessarily mean improving.
1 Like