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

[mystran]

I was clearly referring to the one implied by linear maps, since this is the one implicitly contained in the LTI. Furthermore, if I understood you correctly, you are implicitly extending the statements made in respect to functions of one argument to the functions of two arguments.

The argument I was trying to make is that multiplication of two signals is linear IFF you treat one of the signals as constant. This is exactly the same as taking a bilinear function and fixing one argument to get a linear function with respect to the other argument. Also whether or not it's two arguments or a single vector argument of two dimensions makes absolutely no difference whatsoever.

Now, with LTI the time/shift-invariance the condition is that the system is not parameterized over time, hence anything that is parameterized over time must be an input (or output) signal. Now, if you want to have a system that multiplies two signals together, then you have two choices: if you treat it as a bivariate (bilinear) quadratic, then it is no longer linear. If you fix one of the signal in order to obtain a linear function of one variable, then it's no longer time/shift-invariant.

That's the original point I was trying to make: you have a choice whether you want to treat it as linear or time-invariant, but you can't have both.

[Z1202]

The argument I was trying to make is that multiplication of two signals is linear IFF you treat one of the signals as constant.

I assume by "constant" here you mean "fixed", not "constant over time", right? In which case I agree.

Now, with LTI the time/shift-invariance the condition is that the system is not parameterized over time, hence anything that is parameterized over time must be an input (or output) signal. Now, if you want to have a system that multiplies two signals together, then you have two choices: if you treat it as a bivariate (bilinear) quadratic, then it is no longer linear.

This is where I'm having a problem. Because we begin to mix different ideas of linearity. One is linearity as a map, which doesn't have a nonambiguous generalization to the case of two (or more) arguments. The most obvious generalization is IMHO bilinearity, because we still stay linear (as a map) in each argument. The other generalization is a linear combination of linear maps, but in this case the result is not linear (as a map) in either argument. Therefore for me it's the first generalization which is default one.

The other is linearity as a "first degree polynomial". It even doesn't equal the "linearity as a map" in the simplest case, because it admits a DC term, where as the map doesn't.

If you fix one of the signal in order to obtain a linear function of one variable, then it's no longer time/shift-invariant.

Whether the signal is fixed is completely orthogonal to the question whether the signal is constant over time. So I fail to see the point here.

That's the original point I was trying to make: you have a choice whether you want to treat it as linear or time-invariant, but you can't have both.

Of course I can. As mentioned, these are orthogonal. To become linear you need to fix the other signal, e.g. you could choose it to be sin(t). To become time invariant you need to make the other signal constant over time, but this constant doesn't have to be fixed. These are two different types of fixation. One is having the same value regardless of t (time-constant), the other is simply not changing the signal function and leaving it with a predefined choice.

In fact even this predefined chose may be varied but "in a containing context", not unlike loop nesting. It's like the classical definition of a limit: for any eps>0 exists N such that for any n > N...
In this case we're "having two nested loops", one is over all eps, and then there is a nested loop over all n, where within each nested loop "only n is changing".

Edit: as an example. I can choose my transformation to be y(t)=F[x(t)]=x(t)*sin t. The transformation F[x] is linear. Of course it's not time-invariant, because F[] internally depends on t. To make it time-invariant I have to choose a constant multiplier: y(t)=F[x(t)]=C*sin t. I can however treat C as a parameter of the transformation and write y(t)=F[x(t),C]. Now transformation has two arguments and is linear in either one. I can also replace C by a function of time: y(t)=F[x(t),u(t)]=x(t)*u(t). F is still linear in either argument.

[mystran]

One is linearity as a map, which doesn't have a nonambiguous generalization to the case of two (or more) arguments.

What? You just concatenate all the arguments into a single vector. Then you can throw a constant 1 in there as well and you've got an affine map.

The other is linearity as a "first degree polynomial". It even doesn't equal the "linearity as a map" in the simplest case, because it admits a DC term, where as the map doesn't.

Affine maps do admit a DC term.

If you fix one of the signal in order to obtain a linear function of one variable, then it's no longer time/shift-invariant.

Whether the signal is fixed is completely orthogonal to the question whether the signal is constant over time. So I fail to see the point here.

Let's say we have f(x,y) = x*y and we fix y=u(t) for some specific signal u(t), such that g(x)=f(x,u(t))=x*u(t), then the time t is a free variable in g(x), hence the function is no longer time-invariant. On the other hand, the original f(x,y) is time-invariant, but not linear.

[Z1202]

One is linearity as a map, which doesn't have a nonambiguous generalization to the case of two (or more) arguments.

What? You just concatenate all the arguments into a single vector. Then you can throw a constant 1 in there as well and you've got an affine map.

I'm sorry but I refuse to see that as an obvious generalization. Especially the irregularly appearing DC term.

The other is linearity as a "first degree polynomial". It even doesn't equal the "linearity as a map" in the simplest case, because it admits a DC term, where as the map doesn't.

Affine maps do admit a DC term.

Exactly. While neither linear or bilinear or multilinear maps, or the LTI systems (for the sake of the current topic) do.

If you fix one of the signal in order to obtain a linear function of one variable, then it's no longer time/shift-invariant.

Whether the signal is fixed is completely orthogonal to the question whether the signal is constant over time. So I fail to see the point here.

Let's say we have f(x,y) = x*y and we fix y=u(t) for some specific signal u(t), such that g(x)=f(x,u(t))=x*u(t), then the time t is a free variable in g(x), hence the function is no longer time-invariant. On the other hand, the original f(x,y) is time-invariant, but not linear.

I agree to the first statement. The second statement is arbitrary in its interpretation of linearity, which bears little connection to the idea of linearity in LTI (again, LTIs do not admit a DC term, while the idea of linearity to which you switch in case of 2 arguments suddenly does)

Edit: maybe I need to repeat this again. There are two (or more) different ideas of linearity. One means "linear graph of the function (straight line or plane or whatever)" (this essentially boils down to 1st order polynomials), the other one means commutativity with mixing. LTI is about the second one.

These two definitions do not coincide even in single-argument case (commutativity with mixing doesn't admit the DC term). With two or more arguments they become much more different. E.g. f(x,y)=x+y is linear in the first sense but not in the second one where it doesn't commute with mixing in respect to either argument.

[mystran]

One is linearity as a map, which doesn't have a nonambiguous generalization to the case of two (or more) arguments.

What? You just concatenate all the arguments into a single vector. Then you can throw a constant 1 in there as well and you've got an affine map.

I'm sorry but I refuse to see that as an obvious generalization. Especially the irregularly appearing DC term.

Ok, let me put it this way then: affine maps are linear maps between affine spaces and projective maps are linear maps between projective spaces. The definition of an LTI systems still works just fine in affine and/or projective spaces, so I fail to see the problem as long as the projection back to Euclidean spaces is linear.

Whether or not generalization to higher dimensions is obvious, I don't know, but that's how you usually analyze MIMO systems, whether or not you are interested in linearity, shift-invariance or some other property (eg. if you want to prove that a system is unitary with respect to it's input/output space for composition in loss-less reverb prototype or whatever).

This is not really relevant with respect to the original discussion though, which is about whether or not multiplication of two signals is linear and/or time-invariant and I think we can agree that it's either linear or time-invariant (depending on what is a system and what is an input), but not both.

[Z1202]

This is not really relevant with respect to the original discussion though, which is about whether or not multiplication of two signals is linear and/or time-invariant and I think we can agree that it's either linear or time-invariant (depending on what is a system and what is an input), but not both.

It is linear for F[x(t)]=x(t)*sin t, it also time invariant for F[x(t)]=C*x(t) (the second signal is constant), it is not linear if two signals are dependent (but that would turn pretty much any multilinear system into a nonlinear one).

So, if you put a ringmodulator inside some system, I'd agree that it's nonlinear, since the signals are dependent "by definition" (or rather context) and thereby so is the whole system. If one of the signals is external, while the other one is purely internal (doesn't depend on the external signal), the system is still linear in respect to the external signal (as a "black box").

Thus a typical ringmodulator guitar pedal (which modulates with an internally-generated sine) is a linear processor (if we ignore the nonidealities of the analog modulator).

Back to the VCA envelope. Since the VCA envelope hardly ever depends on the VCA input, multiplication with the VCA envelope is a linear transformation (unless the envelope parameters are modulated by the VCA input in realtime).

Edit: conversely, an addition of two signals inside a system keeps the system perfectly linear (if it was otherwise already). However an addition of an external signal (unrelated to the input signal) makes the system nonlinear (and hence non-LTI). On the other hand, if both signals are treated as inputs (multiinput system), then it's linear again. So it's also a matter of POV in this case (whereas not so much with the VCA, because treating envelope input on par with the main input feels quite awkward to me, one is control signal, one is audio signal).

Edit2: maybe I finally see your point: if we treat ringmodulator as a multiinput system, where all inputs are collected into a vector, this one is not linear. But then, as I wrote, this is not what I would imagine with an env VCA, maybe that's why it took me so long Particularly, multiplication by VCA env commutes with mixing (if we talk about mixing the audio signals, not mixing the amplitude envelopes).

[mystran]

Edit2: maybe I finally see your point: if we treat ringmodulator as a multiinput system, where all inputs are collected into a vector, this one is not linear. But then, as I wrote, this is not what I would imagine with an env VCA, maybe that's why it took me so long Particularly, multiplication by VCA env commutes with mixing (if we talk about mixing the audio signals, not mixing the amplitude envelopes).

Right, so my point from the beginning was simply that whether the envelope is considered part of the operator (ie. a VCA with built-in envelope) or an additional input (ie. a VCA with a CV input, as you would generally find in an analog modular) will lead to a violation of either time-invariance or linearity and while you can choose one or the other depending on how you define the system, in practical DSP terms neither linearity or time-invariance is (usually) terribly helpful on it's own.

This then goes all the way back to my original comment: more often than not when someone in the field of DSP (informally) say "linear" what they really mean is "linear time-invariant" because it is the LTI property that gives us most of the goodies like the ability to reason about transfer-functions and not worry about aliasing.

I also made an argument (that I'm going to formulate in slightly more precise, though still somewhat informal terms) that if you do not allow free variables (that is, we treat the system as a black box function from inputs to outputs), then linearity and time-invariance are pretty much the same thing, because if time (or whatever other free variable you might have) is explicitly bound as an additional argument, then all time-variant systems become non-linear systems, where as all linear systems with no free variables are LTI. Perhaps my former interest in programming language theory is showing through here, but basically what I'm trying to say is roughly that when you lambda-lift a closure (eg. over time) into a pure function, if it remains linear, then it must have been LTI to begin with.

In fact, this informal notion of implicit assumption of linearity in a time-invariant context (ie. no free variables) was precisely what matt42's answer (#2 in thread) was based on and personally I don't think this practice is even worth fighting, because whether or not linearity alone or linearity with time-invariance is a property of interest is usually clear from the context (to those skilled in the art of DSP, at least).

Now, obviously there are practical situations where just having linearity or time-invariance on it's own can be helpful (eg. linear systems can be solved using linear-algebra, even if you had to solve a different system for every time-step), but I would argue that these are usually practical considerations more so than any strong theoretical guarantees with respect to the signals involved.

[mystran]

Another way to look at it, we can treat signals as function of time and systems as higher-order functions:

f(x,y)=𝜆t.x(t)*y(t) is non-linear in t, g(x,y)=𝜆(s,t).x(s)*y(t) is bilinear in (s,t), but as soon as we bind both notions of time to the same value then 𝜆(x,y).𝜆t.g(x,y)(t,t)=f(x,y), so we can have envelopes as linear transforms in this framework iff we allow multiple dimensions of time. So basically "linear" is the same as "linear time-invariant" whenever only one dimension of time is allowed (which is obviously just the good old "time-invariance" condition, but what I'm trying to point out is that if we assume linearity without time-invariance then stuff does get a bit weird).

[Z1202]

g(x,y)=𝜆(s,t).x(s)*y(t) is bilinear in (s,t)

I guess this idea might need a bit of further shaping. At least in the context of the previous discussion we don't care if g(x,y) is bilinear in (s,t), but we do care if it's bilinear in (x,y). Furthermore, the envelope and the audio signal are clearly dependent on the same t, which still doesn't make the whole thing nonlinear in either variable (although, it's nonlinear in two as a whole).

PS. Or maybe I'm being confused by the substitution of "linear" for LTI, which I guess is what you're trying to get at.

[mystran]

PS. Or maybe I'm being confused by the substitution of "linear" for LTI, which I guess is what you're trying to get at.

You're probably confused by my hand-wavy notation and I don't blame you for that.

The idea I was getting at is that if you want to have a fixed envelope over time as part of a linear operator, then you need a separate notion of time for the envelope and the input signal in order to close over one and not the other.

edit: I guess (yet) another way to put this idea is that in order for the system to be a black box (ie. strictly inputs to outputs) and time-variant, it has to take time as an additional input, which then breaks the linearity (with respect to the input space that now includes time).

[Z1202]

edit: I guess (yet) another way to put this idea is that in order for the system to be a black box (ie. strictly inputs to outputs) and time-variant, it has to take time as an additional input, which then breaks the linearity (with respect to the input space that now includes time).

Let F[x,t] = x+t. We have time as an additional input, but the system is linear with respect to [x,t] space.

[mystran]

edit: I guess (yet) another way to put this idea is that in order for the system to be a black box (ie. strictly inputs to outputs) and time-variant, it has to take time as an additional input, which then breaks the linearity (with respect to the input space that now includes time).

Let F[x,t] = x+t. We have time as an additional input, but the system is linear with respect to [x,t] space.

Yes and in this case it's now an LTI system because t is no longer a property of the system and whether or not you happen to patch in a signal from a clock or something else is no longer relevant for the purpose of analysis of the system, which is the whole point I'm trying to make: you don't really have a black box if time is a free variable and if it is not, then linear implies linear time-invariant, because the question of time is no longer relevant when time does no longer exist in the traditional sense: "time" in the sense meaningful in terms of "time-invariant" can only exist when it is allowed to violate the blackbox condition of strictly inputs to outputs.

[mystran]

To put it bluntly, what I'm trying to say is that if a system is "time-varying" then it's not really a well-behaved self-contained object to begin with (because it contains a side-channel) and it seems quite reasonable to expect that if side-channels are allowed, then it might potentially order pizza (to take an analog with "undefined behaviour" in programming languages). So as far as I'm concerned "time invariant" basically means that we can remain confident that it's not going to order pizza. Once we know that it's not going to order pizza, it is then sufficient to just worry about linearity.

[Z1202]

How to put integrators or unit delays into this scheme. You can't really claim they are time-unaware, right?

[mystran]

How to put integrators or unit delays into this scheme. You can't really claim they are time-unaware, right?

But they are time unaware in the sense that they only depend on time-offsets, never wall-clock.