Forums > MaxMSP

Why Mixer Crossfade latency value must be greater than the ramp time?

April 29, 2014 | 4:30 pm

In the MSP tutorial "MSP: Audio Input and Output", I could not understand why "the latency value must be greater than the ramp time for a crossfade to work as expected", when Ramp Time sets the crossfading when starting and stoping a patch, while Mixer Crossfade latency sets the crossfading time when editing a patch.
As I read the sentences, it seems that they respectively affect in completely different moments.

I appreciate much for a bit more explanation.

Many thanks in advance,
Masa

  • This topic was modified 2 months by  Masa.
  • This topic was modified 2 months by  Masa.

April 29, 2014 | 11:04 pm

Think of mixer latency described there as the time between the unedited version of your patch and the edited version. If you have a latency set to less than the ramp time, the newly edited version will start to play before the ramp has completed, thus possibly creating a click or pop. The ramp time in this case, even though it refers to a ramp down in volume from the old version, and an additional ramp up from the newly edited version, is easier to think about when simply isolating the ramp down. It needs to ramp down completely before rebuilding/outputting-audio from the freshly edited version of your patch.
(This is just my guess, since there are no max objects or patches or code where we can see exactly what’s going on behind the scenes in this case…)

Hope it helps.


May 1, 2014 | 10:09 am

Thank you very much for your response.

I still find it difficult to understand why the newly edited version should not start to play before the ramp has completed, as with conventional crossfade, always the new fade starts before the old fade completes.


May 1, 2014 | 12:39 pm

Oooo! I think i figured it out(ah, the docs are so extensive, but still sometimes so minimal and cryptic with certain wordings… ;D).

Please forgive me, as i’m just trying to imagine it in my head, so it may be that i’m completely wrong and have instead invented a new form of writing called max-science-fiction:
In a more technical way, we could imagine ‘latency’ to describe a signal-vector(a section of consecutive memory areas that hold samples of audio), and in order to rebuild the dsp chain, max needs to have two parallel signal-vectors describing both the old and the new versions of your patch running at the same time.
The crossfade actual begins after the period of latency(because this is the time allowed for the newer signal-vector to fill up with audio/samples from the rebuilt dsp-chain).
Although the docs are not entirely clear whether ramp time refers to total crossfade time, or just the time of a single down or up ramp, we can surmise that it refers to just the down or up ramp(half the total crossfade time), because for the definition further down it reads, "Ramp Time sets the duration of time (in milliseconds) over which a patcher is faded out when stopping or faded in when starting."
This is where i think Cycling74 got cleverly minimal in their doc writing.
The definition there is not referring to any crossfade, but implies the ramp-down time when you turn audio off, or the ramp-up time when you turn audio on.
But i believe they use the same value for the ramp in both halves of the crossfade too.
Since you need 2 parallel signal-vectors equal to the latency value(to give enough time to rebuild) running at the same time, and the ramp-down will activate on the signal-vector carrying the older version, while the ramp-up will activate on the signal-vector carrying the newer version, you need a single ramp to act only within the time-period that the signal-vector allows.
If the ramp-down was larger than the signal-vector of the old version, the old version would disappear before the ramp was complete(alternately, the ramp-up on the signal-vector of the newer version would not complete in time, and you’d hear a fade-up after everything was completed, and the crossfade point in the middle wouldn’t be so smooth).
Therefore, the ramp-time can be anything less than the latency, but cannot be equal to it(or you’d get a single point of silence between two versions), or greater(then you get the older signal-vector(equal in size to the amount of latency) disappearing before the fade-out part of the crossfade completed).

If I am wrong, i would at least like to title this max-science-fiction as
"Litz Frang’s ‘Maxopolis’"!

:D


May 7, 2014 | 11:02 am

Hi, thanks so much for your further explanation!

But i believe they use the same value for the ramp in both halves of the crossfade too.

I didn’t know that. That makes my understanding clearer.

The crossfade actual begins after the period of latency(because this is the time allowed for the newer signal-vector to fill up with audio/samples from the rebuilt dsp-chain).

I’m still confused because the document says "Crossfade Latency specifies a time value (in milliseconds) that provides the time to rebuild a new DSP signal chain while the current signal chain is active prior beginning a crossfade". (prior "to" I guess, typo?)
In this sentence, which is "prior to beginning a crossfade", "the current signal chain" or "Crossfade"? I assume it is "the current signal chain" thanks to your explanation.

Could you kindly tell me which two events "Crossfade Latency time" measures? Is it the time between beginning of the ramp-down and the completion of the ramp-up?


May 8, 2014 | 12:56 pm

again i’m only guessing, and cycling74 would have to answer for a full authoritative answer,
but you touched on a very good part of it, a part that shows why confusion here is reasonable:
"Crossfade Latency specifies a time value (in milliseconds) that provides the time to rebuild a new DSP signal chain while the current signal chain is active prior beginning a crossfade". (prior "to" I guess, typo?)"

First, ya i think they mean ‘prior to’.
But also, i think they probably could rewrite it with a few more commas for those of us in the rest of the world who aren’t so used to a… uh… slurred form of english :D
(Cycling74 is a very ‘American’ company, haha ;D)
Even though it isn’t written this way, i read it like this:
"Crossfade Latency specifies a time value (in milliseconds),
that provides the time to rebuild a new DSP signal chain while the current signal chain is active,
prior to beginning a crossfade"
(C’mon Cycling74! look at all those prepositions in a semi-run-on sentence! you gotta make it a bit easier for us :p ;D)

Reading it like that, you can imagine:
1) the current signal chain is already active
2) a new signal chain is built within the time alloted for ‘crossfade latency’
3) the crossfade begins only after the new signal chain is built

so ‘crossfade latency’ specifies the time before you hear any crossfade at all(it’s the ‘latency’ before it crossfades to a new version of the signal chain, therefore, the time in ms that max is allowed to delay the crossfade entirely, while it builds the new signal chain…).
specifically, it is the time between when you edit the patch, and when the first ramp-down of the crossfade begins(just the time between editing and the start of the crossfade).

maybe it’s worth mentioning the purpose of this crossfade feature: my guess is that it’s mainly for live-coding performances, where you intend to constantly edit or build your patch as part of the performance. if during your performance, your patch is completed and locked, you never really need this feature.
‘crossfade latency’ allows max some time to calculate your edits before changing the sound(it requires some sort of time or delay to do this because it can’t predict what you will do).
(alternately, at home or in the studio, it can also help save your speakers from clicks and pops when you edit… but personally, keeping things at a low volume while editing is enough for me and i would only use the specific ‘mixer crossfade’ feature if i needed it for live-coding. it can be confusing because it’s part of the ‘mixer’ which has other features that are useful more often(volume, muting, etc.)… but… the crossfade isn’t necessary for everyone…)
…just something to consider…

-RajaTheGrammarNazi


June 10, 2014 | 2:51 pm

Hi Raja, thanks again for this topic too!
As this topic is more difficult for me, I will take time later this week to read your explanation carefully. Then I will get back here with my response.
Many thanks,
Masa


Viewing 7 posts - 1 through 7 (of 7 total)