Glue muted MIDI parts and not-muted midi parts leads to odd results

Using the glue tool on a combination of muted and un-muted midi clips results in a new midi region that doesn’t follow the correct muted/unmuted state.

  1. Create Empty Project
  2. Create an instrument track or MIDI track
  3. Create two separate midi part containing some notes.
  4. Mute the first part
  5. select both parts with the lasso tool
  6. Use the glue tool to merge the two part
  7. Result > The newly merged MIDI part is MUTED

Repeat the above steps muting the second part. It will cause to create a new merged MIDI part that is instead unmuted. It seems like Cubase looks at the first part (left to right) to determine the muted state of the region it will create using glue operations…obviously this is a bug.
Similar behavior occurs with muted MIDI notes inside parts, but that is another bug report.

As much as it might be undesired in your workflow, the function is consistent in doing what you describe, which would also be true for midi notes within a part. So personally, imo, it’s not a bug.

I agree with @steve, this is exactly what I would expect to happen tbh.

I am curious, what exactly would be your desired behaviour?

Two parts are joined so they cannot be half muted and unmuted (unless the notes inside are muted, which is not part of the joining function). So Cubase/Nuendo takes the first part and follows that.

If you want a behaviour that mutes even when joined, you can create a macro that will mute the notes inside the part before you join it.

This could be resolved in 2 ways:

behavior 1: the content of what it used to be a muted clip is not present in the new, glued version. After all there is a reason why you muted it in the first place.

behavior 2: the content of what used to be a muted clip is carried over in the new glued version but the midi notes are muted.

Results: no event mute state is altered. Glued or not it will sound exactly the same.
No data loss in the second scenario, full data loss in the first scenario. But at least it will sound the same. I would prefer behavior 2. Not a fan of a feature that mutes your music automatically.

Add mentioned above.

  1. Deletes notes. Nope definitely not. Cannot be unmuted. This is a mute not a delete.
  2. Mutes notes inside the part. Not for me. This would destroy workflow.

Macro. Key command. Set it up to work however you want. Then can be done with 1 press.

1 Like

I agree with @steve and @Phil_Pendlebury .

Actually the most logic behavior would be to mute the notes, but, let’s say the user is gluing a lot of muted and unmuted parts together on multiple tracks, if they are not aware that the notes will be muted in the process (and even it they are), they’ll have to remember exactly where the muted parts were, and spend a lot of time searching for those muted notes to unmute them with the Mute tool.
I am aware that muted notes aren’t displayed in the project window parts, but that would still be a very fastidious job, and this even more true when the project is dozens of minutes long.
As said just above, this would just kill the workflow.

The best is to not glue the parts at all unless we are sure we won’t touch it anymore, and keep them muted so we can seek them faster.

1 Like

I will work on a PLE or LE that deals with this when time permits. It may help a bit. :pray:t3:

well it might not be a bug but…
Just looking at what happens when we perform glue operations on audio. It actually does what I am suggesting here:

I feel like a good software should be as consistent as possible in its editing behavior… what do you think?


Audio Events glue is something totally different. This will make an Audio Part containing both Audio Events.

Yes exactly that…glue audio events is totally different from gluing midi event despite using the same tool for it. These are the types of inconsistencies that do nothing else but confuse the user. Shouldn’t we strive for a software that is more intuitive…?In recent years, even more traditional DAWs have implemented a more uniform editing across audio and midi. Cubase should follow along


This is by design and there are use cases behind the implementation.

would love to know more about these use cases. In the meantime I suppose we can close the ot

This is not a correct description. In the first case you are Gluing Audio Events while in the second case you are Gluing MIDI Parts (not Events).

Apples & Oranges, Parts & Events

Parts are containers that hold Events.


You are correct, and you are actually revealing another huge incongruence that I was never able to comprehend…you can have audio parts and audio events, but you can’t have MIDI parts, only chord events…
I would assume that midi clips are automatically “parts” HOWEVER!!:
if you right click on a midi part(?) the contextual menu reveals some very questionable options such as:

Colorize Selected Events…(wait wasn’t this a midi part?)
Move Event Starts to Cursor (see above)

The reality is that you cannot have a midi part. Only MIDI events.
Can you group these midi events (by creating a part?) NO. The only way to do that is by using the glue tool…hence the OT.

Can you group the audio events? yes, right click on multiple selected audio events and you can do “Events to Part”.

More incongruences, more confusion…
if I’m missing something let me know please…

Screen Shot 2022-07-19 at 2.48.03 PM

And to corroborate my analysis:


So both MIDI events and MIDI parts are created automatically when you record.
so what should they be referred as?
Parts or Events ?
@Martin.Jirsak is this also “by design”?

More like Tomato Tomato…:frowning:

MIDI Events are the data that is inside the container (notes, velocity, CC, etc).
MIDI Parts are the containers.
Usually we refer to these containers as Events to remove the confusion.

Audio Events are audio data, just like MIDI notes, except they are directly on the Project Window.
Audio Parts are containers of multiple Audio Events.
Audio Clips are the whole audio files.

Let’s keep using the term “Event” to name what can be arranged in the Project Window.
We don’t care if it’s Audio or MIDI, just simply call it an Event.
That’s why the contextual menus for working in the Project Window are always referring to Events.

In all your posts you keep playing with words like that, just, what is your point ?
Other than making things more confusing than they already are, I can’t see.

Parts and Events are specialized terms the Steinberg developers defined for Cubase back in the 1980s.

Maybe it will be helpful to you to have a look at this area of the manual in regard to this.

thank you @steve for that,
while I get what parts and events are, all I am saying is that the differences between audio events, audio parts, midi events and midi parts is not very consistent with the definition in the manual and it can create very loopy situations when you apply static tools like the glue tool to such 4 distinct elements (which really its only 3, audio parts, audio events and MIDI event since MIDI event and MIDI part appear to be…the same…? somehow?)
The original post was in fact to what happens when you apply the glue tool to MIDI events and MIDI part (which happen to be the same in the manual…somehow).
Such behavior is not consistent with what occurs by using the glue tool on 2 or more Audio Events.
However I’ve just been told that such inconsistencies are “by design”

This comes from the fact that midi and audio are fundamentally different.

Of course, they are not. Midi events reside inside the part.

If you are saying that it’s confusing to you how the terms are used, that’s one thing. After all, you do understand what is meant by those terms.

Different daws use similar jargon differently, I’ve been using Cubase since almost the beginning, and I have also used Opcode Studio Vision and MOTU DP which have very different paradigms for presenting the data, yet similar terms are used. In my view this jargony stuff is something we get used to after using the software.

If you don’t agree, I suggest you start a topic explicitly about that, so it’s clear.

1 Like

Thanks for your answer I think I will do just that.