Attack Compensation: Now +, Before -?

Cubase
,
1

Before C15, “Track Delay” could be + or -. Now, with the new Attack Compensation setting in the Expression Map setup, only + values are allowed (per articulation), where track delay previously required a - value to move the onset of sound earlier. Consistency problem? The global Track Delay is still present, so if both are set to 100, (-100 and 100 respectively) does that equal 200 ms delay? Can’t find help in the manual.

Also, the Attack Comp doesn’t seem to work properly on the Celli and Basses instruments of Iconica Sections & Players. If an attack comp is set for either on, say, Sustain or Legato articulations, going from staccato to sustain or legato seems to disable the held aspect of the note and truncates a whole note into an eighth. Doesn’t seem to affect violins or viola. Bug, or is there something unique about lowest strings?

Thanks.

2

We had a detailed discussion to work out the best naming and numerical convention, and we decided to call it ‘Attack Compensation’ and not ‘delay’ or ‘pre-delay’, and to ensure that it used only positive numbers to reduce potential confusion. A positive value for the attack compensation will cause the notes to start earlier, so it if you have a 50ms attack compensation and a track delay of -100 then this means notes will be started 150ms earlier.

For the issue you mention, could you attach a project that shows the issue?

3

Ok, understood, but still confusing. We’ve all been using neg vals, now inverted. Oh well.

Can’t upload the project, file too large (19.7 Mb). Note: the project was originally created in Nuendo 14. I installed Cubase 15 on the same machine and open the Nuendo project in Cubase. Seems to work, but who knows if there are conflicts. When I save the project when in Cubase, it does not create a .cpr file, it remains a .npr file & opens (successfully) on either platform. I use save, not save as. Still, the prob only affects the low strings. All other instruments work as expected.

How can I get you the info you need?

Thanks

4

Negative values can still be used for delay because a positive delay means increasing time. Part of the hope of using a positive value for latency compensation is to reduce confusion because it’s only possible to use a positive value.

I won’t need any audio, just the npr/cpr file. You might find it zips up quite small to send in a DM, otherwise are you able to upload to Google Drive, OneDrive, Dropbox etc?

5

I’d say this is the result of a closed group of people overthinking the philosophical aspects of a feature rather than looking at reality and the actual context. The result is immensly confusing.

First, philosophy aside: discrepancy of the concept of “negative” between the full track delay and the articulations within the same software is an absolute no-no in every aspect of product development. So already there should someone have said “stop”. Inconsistency is the best way of minimizing the greatness of user experience.

Then, let’s move to the philosophical aspect: Audio and music is on a timeline. That is how most people look at it. That is the numbers displayed in the Transport that everyone is used to working on. When time increases, the cursor moves to the right and the value of the position increases. Not just audio, anything interactice determined starts as 0 and ends at X.

An event happens on point 0 relative to itself (if zero index, which time as an unit is by default). If we want that to be played earlier, we subtract time from it, pushing it earlier, which gives a negative value. “Left” of the cursor.

If we pre-determine it’s position we say “it starts at 100”. If we want it earlier, we say “move it to 80”. Which is 100 minus 20. Not a single user I’ve ever met, or any video on the subject I’ve ever seen, has found it confusing that minus equals earlier. It’s crystal clear for everyone.

We say “move the vocals 10 bars earlier”, where “earlier” equals minus. That’s how communication works in a studio. We don’t say “increase the earlyness of the event with 10 bars”.

In this particular context, the thinking would be: “the sound is 100ms late". To compensate for that, we subtract 100ms. We don’t think “increase the negative value with +100ms”.

I suggest you take another look at this and change it to what “everyone” believes is the logical view of this in a timeline based context. I understand the mathematical “riddle” behind it, but it makes no sense in the context of reality. It’s a simple frontend fix that can easily be translated in the backend.

6

So, all Paul has to do is add a permanent “-” (minus) in front of the number that you can enter?

7

All needed is a method on the back end that reverses the value the user enters (if lazy, it’s a dirty fix). Or just rewrite the code, but it might take more effort since there’s probably dependencies in multiple instances.