Is the application of a volume envelope to an audio signal a linear transformation?
-
- KVRAF
- 1606 posts since 12 Apr, 2002
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.
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
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.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.
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).
-
- KVRAF
- 1606 posts since 12 Apr, 2002
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?mystran wrote: ↑Mon Oct 26, 2020 9:03 pmI 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.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.
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).
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
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.
-
- KVRAF
- 1606 posts since 12 Apr, 2002
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?
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
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.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?
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.
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
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).
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).
-
- KVRAF
- 1606 posts since 12 Apr, 2002
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.
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
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?
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?
-
- KVRAF
- 1606 posts since 12 Apr, 2002
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.
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.
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
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.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.
-
- KVRer
- Topic Starter
- 20 posts since 9 Jun, 2006
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?
What I really wanted to ask was if there's bandwidth expansion in the case of volume envelope. If not, why so?
-
- KVRian
- 1273 posts since 9 Jan, 2006
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
-
- KVRAF
- 1606 posts since 12 Apr, 2002
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).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?
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.