"Empty" audio events = mute

I used “empty” audio events quite a lot in previous versions - ie double clicking between locators in an audio channel to create an event which doesnt contain any actual audio. Usually to help me bounce audio edits to accurate events.
In ver 8 empty audio events seem to mute the audio beneath them. before it used to play everything beneeth.
Any idea how I configure them to be transparent? ie play whats beneeth them?


This is wanted behavior, and it should works (and worked) like this always. You can use only one “active” layer in the Audio track. One layer is the audio event with the signal, and the second one is the empty Audio Part. Only one is on top, and only one is audible.

it didnt used to be like that in previous versions. at least not with these empty events.
when theres an audio piece on top of another than yes of course whats on top will play but im talking about those blank events with no info in them.

I’m also talking about the empty Audio Parts (these are not events, but parts). In which version did it work to you, please?



I have the same “problem” with that.

That WASNT the way it worked in 5 and previous versions - and it DOESNT make sense (parts are “containers”, not actual events )

This is horrible for my workflow (and anyone who uses parts as containers) - and also makes cubase not backwards compatible with older (5 and down) projects (!)

(Btw - Same goes for the audio “lanes” behavior - you have the comp tool (which is like a “mute all in range” macro - but why not enable a simple “layering” approach likein the old cubases ??!?

I opened this as an issue and waiting for moderation…

Btw - this also seemed to be the case in Cubase 6 (parts are just “containers” and do not mute


P27 table 2.1


I’m just thinking, couldn’t an Arranger track, and an Arranger event helps to your workflow?

Same as a folder track - not really, because parts give you control over many small elements (events, automation, etc …)

Also, according to the current behavior - if I take one “area” (in a folder track or arranger) and move it ontoo of another area - the original events will be muted (even if the new events dont “cover”/overlap with them (because the parts will mute them …)

In short - there is no sense in this behavior of “parts”
Seems like a fail/shortcoming/regression/“bug” that resulted from the “comping” “feature” - which is a lot of loss for a little bit of gain
(Ruining the workflow and heirarchy logic for a “shiny”/“marketable” added “feature” …)

Im waiting for an official response (and hopefully a fix)


I’m sorry… I think I must be having a “I left my brain on the pillow this morning” moment! :stuck_out_tongue:… but…
Very simply… if you want to hear what is underneath an empty event, why is that empty event there in the first place? (sorry if I am being dumb, but that is just what I understood from your post :wink: )

One example - The parts allow the events in them easier to duplicate and position on the grid …

Ah… so I am guessing you mean a Part that contains some audio in it (maybe starting not on a bar/beat), but maybe blank at the beginning and/or end, and the part does start on a bar/beat?
How about simply placing the cursor at a convenient position somewhere after the start of the audio event, then Audio menu>“Snap Point to Cursor” (then you can move the event while using the Snap function). Or use the “Relative Grid” snap option?
Jumping way ahead here, but have you also gotten into Cubase’s audio comping functions yet? (see pages 141 and 151 of the Cubase 8.5 pdf manual :wink: )
Just suggesting that there are several ways of moving audio events easily :wink:.

Yes I read about comping.

  1. The reaons to use parts with empty areass in them are much deeper … Snap points are not a good way to go about it (i.e. duplicating parts - and parts containing hits that are on top of other parts containing hits at different times)

  2. This was the way Cubase used to handle parts - and the new behavior makes older projects incompatible because of overlapping parts - which ruins backwards compatibility.

    I am (/We are) still waiting for an official response from cubase team (…!)