Yet another case where I may not be understanding something:
I'm using the +~ object to mix audio streams in some of my patches. In most cases it does that, but there are a few points in which it seems to be modulating one stream with the other, rather than just mixing them. This is most pronounced when at higher volumes. I thought that I might be overloading my amplifier, but it acts the same if listened to through headphones.
Is there a way to keep this from happening?
...
mixing them. This is most pronounced when at higher volumes. I thought that I might be overloading my amplifier, but it acts the same if listened to through headphones.
If the sample values going into [dac~] are outside of [-1, 1] then you are clipping the signal... (that's the soundcard clipping not the amp) solution; place before the dac~, [/~ n] for n = the number of signals you've added together.
andy
or you could even just change the +~ object into a [/~ n] object, and put all of the inputs in the first inlet, since all the audio streams on an inlet get summed automatically. except for the [+~ int] usage, the +~ object is usually redundant.
debatable if it "improves readability"... for example, adding 40 audio streams together in a binary tree of [+~] objects probably isn't the most elegant visual representation.
does anyone know which way is more efficient? potentially the "all in one inlet" approach could be (since pd knows more about what is really going on).
On 28 Dec 2001 14:41:55 -0800 "Andrew (Andy) W. "Schmeder andy@eh2o.ws wrote:
...
mixing them. This is most pronounced when at higher volumes. I thought that I might be overloading my amplifier, but it acts the same if listened to through headphones.
If the sample values going into [dac~] are outside of [-1, 1] then you are clipping the signal... (that's the soundcard clipping not the amp) solution; place before the dac~, [/~ n] for n = the number of signals you've added together.
andy
does anyone know which way is more efficient? potentially the "all in one inlet" approach could be (since pd knows more about what is really going on).
I usually use throw~ and catch~ to mix signals. I don't know about difference in CPU usage between catch~ and +~ Anybody?
/Soeren
Should be no difference in execution time.
In throw~/catch~ you should watch order of execution so that the catch~ comes later, otherwise you pick up a 64-sample delay. (I take care of this by using subpatches with signal connections between them; as long as a subpatch with throw~ objects is audio-connected somehow to the subpatch with a catch~ you won't get the delay.
cheers Miller
On Wed, Jan 02, 2002 at 06:58:17PM +0100, Søren Bovbjerg wrote:
does anyone know which way is more efficient? potentially the "all in one inlet" approach could be (since pd knows more about what is really going on).
I usually use throw~ and catch~ to mix signals. I don't know about difference in CPU usage between catch~ and +~ Anybody?
/Soeren
On 28 Dec 2001, Andrew (Andy) W. Schmeder wrote:
If the sample values going into [dac~] are outside of [-1, 1] then you are clipping the signal... (that's the soundcard clipping not the amp) solution; place before the dac~, [/~ n] for n = the number of signals you've added together.
andy
Just curious about this - I've seen several times lately on various lists, the recommendation to divide by the number of voices, but I've always thought that if the signals aren't correlated, then scaling by the inverse of the RMS sum of the signal amplitudes is what would result in the same overall output level as just one signal by itself.
At least this would have to be mathematically true for white noise, would it not?
Consider for example, mixing a full orchestra - would you really wnat divide by the number of instruments in the orchestra? Would you then be able to hear a solo?
My guess is that there is a tradeoff between keeping the final RMS output the same as that of an individual signal (1/RMS-sum) vs an absolute guarantee that there is zero chance of clipping (1/sum-of-peak-amplitudes).
I'd love to be enlightened about this.
Larry
My guess is that there is a tradeoff between keeping the final RMS output the same as that of an individual signal (1/RMS-sum) vs an absolute guarantee that there is zero chance of clipping (1/sum-of-peak-amplitudes).
Assuming our n-input-signals have amplitude constrained to [-1, 1],
max(RMS) = 1 => max(RMS-sum) = n
So 1/RMS-sum >= 1/Peak-sum.
1/Peak-sum is guarenteed to never clip... but at the cost of very low amplitude for single voices.
RMS is computed with a moving average which means it dynamically adjusts with the signal. However this implies latency which means that clipping is still possible.
You can calculate exactly how much error there will be by analyzing the input signals (e.g. distribution type or by sinusoidal components).
andy
-
Andrew (Andy) W. Schmeder -
Joseph Zitt -
Larry Troxler -
Miller Puckette -
pix -
Søren Bovbjerg