Is the application of a volume envelope to an audio signal a linear transformation?

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

Actually I think that additions and multiplications are dual in this sense. Multiplications become nonlinear by turning the gain coefficients into input-dependent signals. Additions of input-dependent signals are linear but become nonlinear by turning the terms into constants.

Post

Z1202 wrote: Mon Oct 26, 2020 7:36 pm Actually I think that additions and multiplications are dual in this sense. Multiplications become nonlinear by turning the gain coefficients into input-dependent signals. Additions of input-dependent signals are linear but become nonlinear by turning the terms into constants.
I think part of this problem comes from the lack of proper type system. If addition is only defined between like types, then addition of signals and scalars is not well-typed. So in order to add a constant term, you need to construct a constant signal with a scalar value and in a sense it's the constructor that is the non-linear operation. Similarly scalar-signal (linear) and signal-signal (non-linear) multiplications are really two distinct operations, because they act on different types.

edit: If we then define convolution as a binary operator of two signals, then we can pretty much do away with the notion of time completely. This type system is a bit too simplistic to deal with all the corner cases (eg. multiplication of a general signal and a scalar-constructed signal), but I'm sure with some additional effort we can come up with a "slightly" more elaborate type-system that can directly capture the linearity of the system into the type of it's output signal (or kind of the type of the output signal, whatever).

Post

mystran wrote: Mon Oct 26, 2020 9:03 pm
Z1202 wrote: Mon Oct 26, 2020 7:36 pm Actually I think that additions and multiplications are dual in this sense. Multiplications become nonlinear by turning the gain coefficients into input-dependent signals. Additions of input-dependent signals are linear but become nonlinear by turning the terms into constants.
I think part of this problem comes from the lack of proper type system. If addition is only defined between like types, then addition of signals and scalars is not well-typed. So in order to add a constant term, you need to construct a constant signal with a scalar value and in a sense it's the constructor that is the non-linear operation. Similarly scalar-signal (linear) and signal-signal (non-linear) multiplications are really two distinct operations, because they act on different types.

edit: If we then define convolution as a binary operator of two signals, then we can pretty much do away with the notion of time completely. This type system is a bit too simplistic to deal with all the corner cases (eg. multiplication of a general signal and a scalar-constructed signal), but I'm sure with some additional effort we can come up with a "slightly" more elaborate type-system that can directly capture the linearity of the system into the type of it's output signal (or kind of the type of the output signal, whatever).
I think this boils down to distinction between control signals ("scalars") and audio signals ("signals"), because otherwise you'd have to switch the types in the system in order to allow parameters to be changed in time. Of course you could argue that a time-varying parameter is a different type anyway. But if this type system becomes a part of a framework it might complicate the maintainability of the code. As far as convolution goes - theoretically yes, but is there any practical impact?

Post

Z1202 wrote: Tue Oct 27, 2020 8:53 am I think this boils down to distinction between control signals ("scalars") and audio signals ("signals"), because otherwise you'd have to switch the types in the system in order to allow parameters to be changed in time.
I don't want to differentiate between the two at all. Either it's a signal or it's an argument to a function from parameters to systems. The only third option that I can see is to assume that the system might order pizza.

Post

I guess that could obliterate the difference between linear and LTI, but I wonder if that has any practical benefits. E.g. distinction between control and audio signals lets one talk of an "approximate" transfer function even if parameters are changing, which has lots of practical use. I assume this would be plainly impossible in your framework?

Post

Z1202 wrote: Tue Oct 27, 2020 11:05 am I guess that could obliterate the difference between linear and LTI, but I wonder if that has any practical benefits. E.g. distinction between control and audio signals lets one talk of an "approximate" transfer function even if parameters are changing, which has lots of practical use. I assume this would be plainly impossible in your framework?
Didn't we already come to the conclusion that a bilinear function is linear with respect to each of it's arguments, even if it isn't linear with respect to the input space as a whole? This is the exact same situation, you can still talk about transfer functions with respect to a subset of inputs that are linear with respect to particular constant parameter signals.

The thing is, the practical reason why I think this whole "time-varying" thing needs to die is because it's precisely what leads to the type of non-sense where we take a direct-form filter and then modulate it's coefficients over time and it blows up in random ways, because we never bothered to worry about anything beyond transfer functions. It's garbage in, garbage out. Linearity without time-invariance did nothing for us, because ordering pizza wasn't disallowed. If you explicitly treat it as time-invariant non-linear system of multiple inputs, then (IMHO) it's a lot easier to figure out whether or not the possible state-trajectories are sensible or not and there is no more hand-waving about when and how it's safe to update coefficients, because you're not updating coeffients and the system either works or it doesn't.

Also just to clarify: my position is that whether you actually implement such a system with some type of a general non-linear solver or a by simply changing coefficients of a linear system is implementation detail as long as it computes the same values up to whatever numerical tolerance you care for. I'm just objecting to the notion that a "time-varying system" is a sensible mathematical object.

Post

I also think that it's silly to rule out "time-invariance" in particular, when there is a more general problem of unaccounted side-channels.

For example, if we take a well-behaved linear continuous-time system and discretize using trapezoidal integration, then a bit of algebraic manipulation will give us a direct-form filter. When we change coefficients and it blows up, it's because we optimized the system under the assumption that coefficients don't change. This is the traditional time-invariance.

Maybe we want to change coefficients so we choose to "preserve topology" but with a bit of algebraic manipulation we can fold the integrators into TDF2 one-poles and save some unit-delays. When we then vary the time-step and it blows up, it's because optimized the system under the assumption that sampling rate is uniform.

Great, so we'll implement trapezoidal integration as DF1 one-poles instead and it works great. Then we send it to space, out of earth's gravity well and when we measure the output back on earth it's now resonating at the wrong frequency?!? Well sure, because we optimized the system under the assumption of a local frame of the space-time manifold and the clock of the system doesn't match our clock back on earth anymore.

So my point is that if we're going to insist on always spelling out "linear time-invariant" then we might as well always spell out that it's "linear time-invariant under uniform sampling and within a single local frame of the space-time manifold." There's certainly other potential side-channels in other situations, but personally I feel like it's much easier to just insist that our mathematical model is strictly from inputs to output with no side-channels.

Any absolute notion of time is relative to some epoch. If you don't take the epoch as an input, then that's a side-channel and the system is only inputs to outputs in some local frame of reference (and your inputs better be defined in the same local frame of reference or it's garbage in, garbage out).

Post

mystran wrote: Tue Oct 27, 2020 1:01 pmyou can still talk about transfer functions with respect to a subset of inputs that are linear with respect to particular constant parameter signals.
But doesn't this get us exactly where we are, just under a way more difficult formulation "a transfer function in respect to a subset of inputs"? Especially considering that the entire systems will then be non-linear and not have a transfer function at all? I find that LTI is a useful shortcut to the common clustering of problems occurring in practice, because we have an obvious way to approximate time-varying scenarios with time-invariant once. So I see the theoretical clarity of what you propose, but somehow feel it's gonna be way more confusing in practice. Maybe it's because I'm used to the current terminology. Dunno.

Post

To get back to the example of multiplication of volume envelope by a fixed envelope, what's the epoch?

Suppose we put the epoch at note-on, great, it's a linear process... however we have a problem when we want to play more than one note, because all the signals for different notes are now in different frames of reference, so we can't meaningfully add them together. If we unify them into the same frame of reference, with a shared epoch, then clearly the envelopes aren't fixed with respect to this frame anymore, so the process isn't linear anymore. See the problem here?

Post

I think I see the problem, but I don't understand why is it such a big deal. If the envelope is a part of the system, clearly systems with different envelopes are different systems and can't be compared. You could also raise the same question about multiplication with a constant, if the two constants are different.
I like the elegance of your proposal, and maybe in certain situations it can even be insightful, but I wonder if in typical situations it creates more understanding problems than it solves. So I'm far from considering it as a "go-to POV", just one of the POVs - for sure.

Post

Z1202 wrote: Tue Oct 27, 2020 3:22 pm I like the elegance of your proposal, and maybe in certain situations it can even be insightful, but I wonder if in typical situations it creates more understanding problems than it solves. So I'm far from considering it as a "go-to POV", just one of the POVs - for sure.
Well, I'm not seriously proposing that we should adopt "linear" as a drop-in replacement for LTI, because that would just cause pointless confusion, but I'm just suggesting that the notion of a system that is not time-invariant is a much bigger can of worms than non-linearity and that you don't really ever need time-varying systems if you account for all inputs properly.

Post

I was interested in the "bandwidth expansion" aspect which mistakenly I thought it was related with the linear "part", but it seems that it's related with the time invariant "part"

What I really wanted to ask was if there's bandwidth expansion in the case of volume envelope. If not, why so?

Post

As mystran mentioned "linear" is often used as short hand for "linear time invariant" (either non linear, or non time invariant will expand the bandwidth). In your case a volume envelope is not LTI and the maximum bandwidth expansion multiplying two signals is x2. Multiply two sine waves and you get the sum and the difference of the frequencies

Post

cyberterror wrote: Wed Oct 28, 2020 1:08 am I was interested in the "bandwidth expansion" aspect which mistakenly I thought it was related with the linear "part", but it seems that it's related with the time invariant "part"

What I really wanted to ask was if there's bandwidth expansion in the case of volume envelope. If not, why so?
Multiplication of two signals results in convolution of their spectra. Convolution with a zero-bandwidth signal (which is Dirac delta in spectral domain and DC offset in time domain) thus doesn't change the bandwidth. Notice that we mean complex-spectrum bandwidth, rather than real-spectrum one, which essentially means that the bandwidth is defined as the largest frequency "contained" in the signal, so a 400Hz sine has a 400Hz bandwidth, even though intuitively you might want to say it has zero bandwidth (but that'd be just for the real spectrum).

As your DC signal begins to slowly change, this widens the bandwidth (order-of-magnitude estimation will grow, very roughly put, as a reciprocal of the "frequency of change"). The convolution "adds" the bandwidths, thus your bandwidth will grow.

The problem is that typically signals do not have hard-cut bands, rather their spectra decay to zero faster or slower. So you cannot exactly say what is the signal's bandwidth, typically, it's a matter where you draw the line. Still, you can say that "the bandwidths add". Thus, multiplying with an envelope will extend your signal's bandwidth by the envelope's bandwidth (approximately, since the bandwidths are defined approximately as well). However, there is a property of Fourier transform which says, that if you speed up your signal by some factor, your bandwidth will grow by the same factor. So, if your envelope speed is doubled, so will it's bandwidth.

With a linear-segment (or any polynomial-segment) envelope the only source of non-zero bandwidth are actually breakpoints, which cause the spectrum to decay as 1/f^2. If the segments are exponential, the question is a bit more complicated, I didn't do the math, but wouldn't expect the picture to change drastically, unless your exponentials are very strongly bent, in which case the decay speed might behave closer to 1/f (at least for lower frequencies).

As a very ballpark envelope bandwidth estimation I'd simply take the duration of its shortest segment and reciprocate, which means that the bandwidth expansion is minimal: for the segment duration of the order of 0.1-1s, the bandwidth would be somewhere around 10Hz order of magnitude.
Last edited by Z1202 on Wed Oct 28, 2020 8:09 am, edited 3 times in total.

Post

Double post. As usual, pressed "quote" instead of "edit" and didn't notice.

Post Reply

Return to “DSP and Plugin Development”