problem with 8 channel mono mixer patch
In the following patch I am trying to mix 8 mono sources down to 1 output. There is a solo bus and mix bus with mute control on the mix bus.
The problem is that I seem to get poor control with the faders in the sense that they are not scaling the source signals in a useful way (e.g. it feels like a linear fader, a fader half way up does not give a half amplitude signal)
I am doing something wrong: maybe the settings for the faders? the input weightings? Maybe there are also issues with how I am handling the matrix~ objects.
I would really appreciate if someone could look at the patch and see how I could improve it and if I am violating any design concepts.
thanks!
Danjel
I loaded your patch and had a look, though didn't have the time to
run anything through it, so these remarks are a bit preliminary.
1) What's the purpose of scaling the input signals by .1 before
feeding into the faders? Your signal-to-noise (actually signal -to-
error in the digital world) would seem to be hampered by this, since
you can do whatever scaling you need with the fader itself.
2) Audio faders are usually not 'linear' but logarithmic in their
taper - to more closely match the logarithmic nature of loudness
perception. A 3dB drop is half the amplitude. The standard MSP signal
faders have 'unity gain' at a fader position (reported out the right
outlet) of 128. The +3dB point is at approx. 133, the -3dB point is
at approx. 123.
On Sep 7, 2007, at 11:03 AM, Danjel van Tijn wrote:
>
> In the following patch I am trying to mix 8 mono sources down to 1
> output. There is a solo bus and mix bus with mute control on the
> mix bus.
>
> The problem is that I seem to get poor control with the faders in
> the sense that they are not scaling the source signals in a useful
> way (e.g. it feels like a linear fader, a fader half way up does
> not give a half amplitude signal)
>
> I am doing something wrong: maybe the settings for the faders? the
> input weightings? Maybe there are also issues with how I am
> handling the matrix~ objects.
>
> I would really appreciate if someone could look at the patch and
> see how I could improve it and if I am violating any design concepts.
>
> thanks!
>
> Danjel
>
>
----
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe
Home
SFIFEM
Atrium Sound Space
OVOS
CMP
It turned out that I had different scaling values in the other faders. I have set all of their values to the same now.
I had put the input pre-scaling in just to see if it made a difference to how all the signals were summed but obviously the fader is supposed to be doing the scaling
thanks!
Danjel
cool! I had to add 8 inlets for audio in and then a sigle one for the output.
Looks like a useful patch! I will have to add pan and aux sends next...
thanks,
Danjel
what steven wanted to say is this:
Bertrand Fraysse schrieb:
> I started to work on your patch and it was interesting, so I
> continued and here is what I get. It's pretty complicated, but it
> does not use any [matrix~]. It's all based on the good old [if]
> object. I hope you'll enjoy.
I must say I really liked the original matrix~ solution for the mute and
solo functionality. Clear, precise and easy to understand. It might be
even more effective, because matrix~ is highly optimized...
There are some things which could have been streamlined, for example the
unpack is not necessary, and you must not hit any of the matrixctrls by
hand, then the toggles don't reflect the actuall state. (For that some
kind of feedback would be necessary.) In general nothing to complain (as
it does what its supposed to do...)
But back to the original question about the levels, I always use a
customized coll to translate Midi fader values to levels. But thats a
matter of taste...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Roman Thilenius schrieb:
> what steven wanted to say is this:
These functions are now part of the normal distribution and have correct
names: atodb converts amplitude to db, and dbtoa converts db to
amplitude... 0 db is 1., and -inf is 0. ...
(Roman is still on OS 9 which still is a great operating system running
on not so great computers compared to what you can get today...)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
I took your idea of generating a table of db vs. scaling values.
I simply took a range of 100 values (-86db to +14db) and computed the scale value as being 10^[(value in dB)/20]
I then used a linear fader with range 0-100 to lookup values in the coll stored with the lookup table and used the output to *~ my audio signal being attenuated.
however, using my above range and formula I did not get useful results in the sense that it only felt like I had a very small movement range of the fader to control the volume (e.g. right around 0 dB). It beyond unity I got ashapr gain or sharp attenuation.
Should I be taking a different approach?
I made my own fader using a simple combination of a float number box,
[dbtoa~], and [*~]. Put in the dB level desired (i.e. +3, -10.5,
etc.) into the number box and it does the rest. A more elegant
version uses [line~] to interpolate between the current and new level
over a very short time constant - something on the order of 7 ms is
usually fine - to get rid of snaps/pops on discontinuities.
Keep in mind that 100 dB is a very large amplitude range - beyond the
theoretical maximum for a 16 bit system (which is approx. 98 dB). A
smaller range is usually sufficient - try something like 70-80 dB or
so. Even so, the bottom portion of the range will often be below
audibility in the context of a full mix.
On Sep 9, 2007, at 1:02 PM, Danjel van Tijn wrote:
>
> I took your idea of generating a table of db vs. scaling values.
>
> I simply took a range of 100 values (-86db to +14db) and computed
> the scale value as being 10^[(value in dB)/20]
>
> I then used a linear fader with range 0-100 to lookup values in the
> coll stored with the lookup table and used the output to *~ my
> audio signal being attenuated.
>
> however, using my above range and formula I did not get useful
> results in the sense that it only felt like I had a very small
> movement range of the fader to control the volume (e.g. right
> around 0 dB). It beyond unity I got ashapr gain or sharp attenuation.
>
> Should I be taking a different approach?
----
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe
Home
SFIFEM
Atrium Sound Space
OVOS
CMP
Here's my approach to log fading. You could do the same thing with dbtoa but this does exactly what I want. 1. -> 1., 0. -> 0., and it converts a linear scale in between to a log scale. The argument to the patch specifies the number of orders of magnitude contained in the full linear scale. I usually use 3.
Dan
> (Roman is still on OS 9 which still is a great operating system running
> on not so great computers compared to what you can get today...)
>
> Stefan
when i dont get my free iPhone within the next
7 days i will downgrade my computers to OS 7
to make a statement.
actually some nice log or exp functions could as well be part of a max slider object, isnt it?
nobody ever used the "offset" possibility of the max slider, why is that there.
;)
Danjel van Tijn schrieb:
> however, using my above range and formula I did not get useful
> results in the sense that it only felt like I had a very small
> movement range of the fader to control the volume (e.g. right around
> 0 dB). It beyond unity I got ashapr gain or sharp attenuation.
>
> Should I be taking a different approach?
Yes, use your ears instead of a formula. My curve looks a bit like an S,
but not exactly. I need high resolution around loud levels and very soft
levels...
In my St.ools collection there is a file called fadercurve, thats it...
(I guess only for me, my taste might be different than yours, just
change it with your ears...;-)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
> Keep in mind that 100 dB is a very large amplitude range - beyond the
> theoretical maximum for a 16 bit system (which is approx. 98 dB). A
> smaller range is usually sufficient - try something like 70-80 dB or
> so.
> Steven M. Miller
> Professor, Contemporary Music Program
> College of Santa Fe
well, we have 24 bits of precision in MSP, so one should use -90 db.
not 100 or 80 :)
btw, the big advantage from "live" expr calculation over the use of tables (wtf stefan :P) is that this will work _always, and is not limited to a certain range (or to a caretain slider size!)
-110 dB/A
On Sep 9, 2007, at 5:37 PM, Roman Thilenius wrote:
>
>
> well, we have 24 bits of precision in MSP, so one should use -90 db.
> not 100 or 80 :)
Yes, but a final output of (usually/typically/often) 16 bits...
>
> btw, the big advantage from "live" expr calculation over the use of
> tables (wtf stefan :P) is that this will work _always, and is not
> limited to a certain range (or to a caretain slider size!)
I'm assuming [dbtoa~] and [atodb~] also depend on the settings in the
DSP setup (in terms of sample resoution)? I.e., when sample size is
set to x bits, it calculates 0 dB accordingly? Can anyone confirm/
deny this?
----
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe
Home
SFIFEM
Atrium Sound Space
OVOS
CMP
> Yes, but a final output of (usually/typically/often) 16 bits...
when converting a range (in dB) from a higher to a lower resolution there is no precision lost. db/A display claulated and displayed with 24 bits of precision fits exactly the
corresponding 16 bit audio stream.
(at least the inaccuracy added by converting the db/A messages to 16 bit shorts would be higher than the inaccuracy which might occure from dithering. if you want to take that into account you should convert the 16 bit version of the output to 32 bit again and tzhen calculate the linear to db stuff in 32 bit again ;))
> I'm assuming [dbtoa~] and [atodb~] also depend on the settings in the
> DSP setup (in terms of sample resoution)? I.e., when sample size is
> set to x bits, it calculates 0 dB accordingly? Can anyone confirm/
> deny this?
i dont know of any other resolution than 32 bit float in MSP.
if you?d use the hr objects for double float, such a resolution would be gone as soon as we convert it to messages ... and within DSP one normally do not need dezibel. (except for hr.biquad~ maybe?)
-110 bit
Roman Thilenius schrieb:
> well, we have 24 bits of precision in MSP, so one should use -90 db.
> not 100 or 80 :)
No, we have 32-bit float with 23-bit mantissa and sign bit which would
give you -138 db of signal to noise ratio and a lot more of theorethical
dynamics...,
16-bit is alread -96 db...
Real life dynamics is closer to 48 dB...
> btw, the big advantage from "live" expr calculation over the use of
> tables (wtf stefan :P) is that this will work _always, and is not
> limited to a certain range (or to a caretain slider size!)
wtf, my faders (and not only those) have different sizes and all pull
out values between 0 and 127... But of course you are right, I should
update my colls to allow 14-bit controllers - oh no, I prefer to make an
interpolating patch to recall everything inbetween...
Then I can go shopping for 14-bit controllers - oh no, first I have to
make money... ;-)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com