presets are named "FM1...FMx".
enjoy
--
Showing posts with label dsp. Show all posts
Showing posts with label dsp. Show all posts
Saturday, September 22, 2012
#Sound Toy presets
last month i've sent a couple of presets to InogoQuilez's online sound generator - Sound Toy.
Sunday, February 27, 2011
#"optimal-l" filters
after having discussions with some very kind people on the topic of "legendre / optimal-l" filters, we have ended up expanding its knowledge base a bit more. i have written a short article providing maxima files for calculating n-th order of the filter, also there are links to the original papers and list of the people involved.
https://sites.google.com/site/neolit123/home/legendre_filters
lubomir
https://sites.google.com/site/neolit123/home/legendre_filters
lubomir
Saturday, December 19, 2009
#axonlib: A cross-platform VST effect framework
ccernn, not so long ago, started the work on a cross-platform vst framework for linux and windows.
axonlib home
Its in an early version currently, but has proven quite stable already.
some screenshots:
I've joined in to help (as much as i can) with some cross platform tests, ideas and possibly with development once we set a version control repository.
Lubomir
axonlib home
Its in an early version currently, but has proven quite stable already.
some screenshots:
I've joined in to help (as much as i can) with some cross platform tests, ideas and possibly with development once we set a version control repository.
Lubomir
Saturday, August 1, 2009
#JSFXGEN - Modular environment for generating dsp code. (update 01.10.09)
I've started working on a "modular environment for generating dsp code" similar to synthmaker/max/synthedit. The target dsp platform is JesuSonic.
First on the list is an online version made with flash/php?/javascirpt/html/xml.
The idea is to be able to add different editable modules, design custom routings and possibly some graphic front-ends.
I'm going to take my time with this one, while keeping it as simple-to-code and user-friendly as possible.
Working project title for now is "jsfxgen".
update v0.1.0 (01.10.09)
screenshot from 0.1.0
new stuff:
- moved to air/flex sdk for primary local version with save/load (online version is still possible)
- integrated a build in editor with scrollbar, undo, line numbers, syntax highlighting.
- variable based drag and drop routing between modules
tbd:
- solid xml data model for the modules
- module export
- open/save file format structure
Lubomir
The idea is to be able to add different editable modules, design custom routings and possibly some graphic front-ends.
I'm going to take my time with this one, while keeping it as simple-to-code and user-friendly as possible.
Working project title for now is "jsfxgen".
update v0.1.0 (01.10.09)
screenshot from 0.1.0
new stuff:
- moved to air/flex sdk for primary local version with save/load (online version is still possible)
- integrated a build in editor with scrollbar, undo, line numbers, syntax highlighting.
- variable based drag and drop routing between modules
tbd:
- solid xml data model for the modules
- module export
- open/save file format structure
Lubomir
Thursday, March 5, 2009
#Designing an analog VU meter in DSP
Here are some notes on how to design a VU meter DSP fx.
I won't be getting much into the signal detection, but mostly into the visual of the plugin. If you wish to know more about it, please feel free to send me an email and I will be happy to respond to your questions.
Here is what we are going to use as an example. This is a very simple JesuSonic fx:
Setting some dimensions
We begin by setting the width and height for the visualization.
Its important to set the dimensions first, because they will determine the radius of the needle and the span of our scale.
We are going to make a rather large VU meter - 425x260px, with needle radius of 200px. You should be able to create an arch withing these dimensions using the needle radius.
Designing the VU meter scale
After the dimensions are set we can start creating our scale.
You can very easily design the scale, try to approximate other scales, or use ready equations.
In this example we are going to design our own scale by roughly approximating to an actual scale. There are a lot of photos of analog VU meter over the net. Different manufacturers have patented different scales. We will create our own (in a way).
Similar to this one for example:
We can use it as our base. In general its very difficult to make the approximation 100% accurate if you don't know the original function. Still there are ways to (try) to do so. For example LaGrange polynomials can help you with that. It may require a lot of points to be interpolated and the resulting function and the algorithm may became much more inefficient than a simple exp(). Also by using interpolation there might be some minor unavoidable and unwanted deviations between points.
First thing to do is to set some scale markings in dB:
-20, -10, -7, -5, -3, -2, -1, 0, +1, +2, +3
Here is how to convert amp signal in dB and then get the value of X (dB -> pixels on the X axis):
xl is the result we are looking for here, after converting amp into dB.
A very useful thing to do is to use some sort of a plotting program which can make calculations and draw some lines at the same time. I've used Adobe Flash which is quite fast to work with.
fig.1
The vertical lines on the left and right represent our width. Point O is the center the circle. Point A lies on the circle therefore OA = r. Point S0 represents a point from our scale using the above equations. To draw the actual lines from the scale, two additional large arches may be used (colored in blue). If we connect O with S0 an intersection will occur between the new cirlces and OS0. These are points D01, D02. So lines such as D01D02 will be visible on our scale. When we know all the coordinates of the points we can make an arrayand draw these 'markings' on plugin initialization.
Drawing the needle in realtime
After we have the result on the X axis we can start drawing the needle.
Of course if you wish to use a bitmap as the needle you should use a different method here (i.e. calculate angle of rotation).
fig.2
The math method used here to calculate point A's X,Y coordinates is by using proportional triangles and Pitagor theorem - as simple as it gets. Where: S0A / AO = P1A / AP2 etc. And since we know some of the lengths and coordinates of points we can get point A very easily.
The results - xlt & ylt are the A's x,y coordinates and after we have them, we can draw a line between O and A in realtime.
Needle response
Updating the needle per sample is not advisable so I suggest that you use some sort of a countdown before make the above calculations. After some trial and error you will get an acceptable 'response' speed. You should know that the magnetic-electric system (inductor+constant magnet) of an analog vu-meter has response of 300ms. This is quite slow but of course you can tweak it.
Another characteristic of the needle response is the inertial fallback. This is due to the inductor exponential discharge. After executing the x,y calculation code you can add the fallback by simply subtracting pixels from X (original exp() scale) while multiplying the result by some factor for adding inertia (emulating the discharge).
Limiting x and y of A may also be a good thing since the given log scale in dB can go as low as -350db. Or you can just limit the input gain value to -25,+3.5 db
RMS window
Adding a RMS detector isn't very difficult to make in DSP either. Here is an example:
So 'rms' would be our RMS value for a 300ms window.
Thats all...well mostly. If you have any question post a comment here or send me an email.
I leave that task of making the VU meter look good to you.
Lubomir
I won't be getting much into the signal detection, but mostly into the visual of the plugin. If you wish to know more about it, please feel free to send me an email and I will be happy to respond to your questions.
Here is what we are going to use as an example. This is a very simple JesuSonic fx:
Setting some dimensions
We begin by setting the width and height for the visualization.
Its important to set the dimensions first, because they will determine the radius of the needle and the span of our scale.
We are going to make a rather large VU meter - 425x260px, with needle radius of 200px. You should be able to create an arch withing these dimensions using the needle radius.
Designing the VU meter scale
After the dimensions are set we can start creating our scale.
You can very easily design the scale, try to approximate other scales, or use ready equations.
In this example we are going to design our own scale by roughly approximating to an actual scale. There are a lot of photos of analog VU meter over the net. Different manufacturers have patented different scales. We will create our own (in a way).
Similar to this one for example:
We can use it as our base. In general its very difficult to make the approximation 100% accurate if you don't know the original function. Still there are ways to (try) to do so. For example LaGrange polynomials can help you with that. It may require a lot of points to be interpolated and the resulting function and the algorithm may became much more inefficient than a simple exp(). Also by using interpolation there might be some minor unavoidable and unwanted deviations between points.
First thing to do is to set some scale markings in dB:
-20, -10, -7, -5, -3, -2, -1, 0, +1, +2, +3
Here is how to convert amp signal in dB and then get the value of X (dB -> pixels on the X axis):
//code executed at bigger intervals - 1024 samples for example
//amp2dB
//take only abs(input) of input
//6/log(2) is our dB scale
in_db = log(abs(input))*6/log(2);
//then
//xl - is the value of X
//in_db - is the value in decibels
//use numbers 2.1 and 285 to tweak the equation
xl = floor(exp(log(1.055)*2.1*in_db)*285);
xl is the result we are looking for here, after converting amp into dB.
A very useful thing to do is to use some sort of a plotting program which can make calculations and draw some lines at the same time. I've used Adobe Flash which is quite fast to work with.
fig.1
The vertical lines on the left and right represent our width. Point O is the center the circle. Point A lies on the circle therefore OA = r. Point S0 represents a point from our scale using the above equations. To draw the actual lines from the scale, two additional large arches may be used (colored in blue). If we connect O with S0 an intersection will occur between the new cirlces and OS0. These are points D01, D02. So lines such as D01D02 will be visible on our scale. When we know all the coordinates of the points we can make an arrayand draw these 'markings' on plugin initialization.
Drawing the needle in realtime
After we have the result on the X axis we can start drawing the needle.
Of course if you wish to use a bitmap as the needle you should use a different method here (i.e. calculate angle of rotation).
fig.2
The math method used here to calculate point A's X,Y coordinates is by using proportional triangles and Pitagor theorem - as simple as it gets. Where: S0A / AO = P1A / AP2 etc. And since we know some of the lengths and coordinates of points we can get point A very easily.
//get y from x and radius - r
//Pitagor and proportional triangles used here
l=sqrt(sqr(r)+sqr(212-xlt));
h=((l-r)*r/l);
m=sqrt(sqr(l-r)-sqr(h));
ylt=35+h;
xlt < 212 ? xlt=xlt+m : xlt=xlt-m; // check if x is < of middle point 212
The results - xlt & ylt are the A's x,y coordinates and after we have them, we can draw a line between O and A in realtime.
Needle response
Updating the needle per sample is not advisable so I suggest that you use some sort of a countdown before make the above calculations. After some trial and error you will get an acceptable 'response' speed. You should know that the magnetic-electric system (inductor+constant magnet) of an analog vu-meter has response of 300ms. This is quite slow but of course you can tweak it.
Another characteristic of the needle response is the inertial fallback. This is due to the inductor exponential discharge. After executing the x,y calculation code you can add the fallback by simply subtracting pixels from X (original exp() scale) while multiplying the result by some factor for adding inertia (emulating the discharge).
Limiting x and y of A may also be a good thing since the given log scale in dB can go as low as -350db. Or you can just limit the input gain value to -25,+3.5 db
RMS window
Adding a RMS detector isn't very difficult to make in DSP either. Here is an example:
//***per sample
//cs - current sample counter
//300 - window in ms
//sum - peak values stored here
if (cs == (0.001*300*44100)) {
cs = 0;
sum = 0;
} else {
cs += 1;
//square the abs value of the input
sum += sqr(abs(input));
}
//***execute at bigger intervals - at sample block for example
//calculate value while converting into dB
//*100/100 is to output the values in the X.XX format
rms = floor(6/log(2)*log(sqrt(sum/cs))*100)/100;
So 'rms' would be our RMS value for a 300ms window.
Thats all...well mostly. If you have any question post a comment here or send me an email.
I leave that task of making the VU meter look good to you.
Lubomir
Saturday, February 7, 2009
#Inter-sample peaks and audio compression
Inter-sample peaks have been more of a problem recently with the constant struggle for louder sound. This post includes some tests of the consistency of ISP clear audio signals after performing compression .
The above article at Gearslutz explains inter-sample peaks quite well. Just to simplify it a little bit here is a time-domain plot of a sample. This could be part of any type of sound - bass guitar, synthesizer, but this is more of a 'designed' plot, since the chance of a similar sequence appearing is minimal (there are drastic changes in sample values).
view image
The areas marked with 'ISP' are the actual problems. ISPs are a digital-to-analog (DAC) conversation issue. Your digital medium such as CD-A may contain tracks that does not clip at all on normal meters, but in theory there is a chance that at certain sample configurations such as the shown above, the reconstructed (via interpolation) analog audio signal, exceeds 0 db. Such peaks will be introduced as distortion in listening conditions.
"Would this type of distortion be really that audible?"
It really depends on the playback system (DAC), the listener, the audio material. But it may be quite audible.
"Well how to prevent it?"
There are algorithms in some DSP limiters, that deal with the problem quite well. From my understanding of interpolation in mathematics, the only way to deal with such problems is to change values of the neighbor points (samples) forward and probably backwards in the time domain. Another important thing that must be done is to over-sample the signal so that more points are introduced in the plot.
Here is the list of the know limiters that prevent ISP:
Sonnox Limiter, Voxengo Elephant, TC Limiter, Izotope Ozone, PSP Xenon and others.
Note, that you must engage the oversampling mode of the limiter to enable the desired functionality.
As you may know most of these limiters are commercial products. The only free tools you would find are the meters, such as: John Schwartz's Bitter, SSL's X-ISM and others.
Still, if you are willing to buy a DSP limiter for your needs, I could not recommend a better limiter than Elephant. Its the cheapest, the most flexible and arguably the best sounding one.
Do the listed above tools really work for ISP?
Well here is the tricky part. There are certain conditions in which the ISP prevention may not work for any of the above products. However most of these conditions are quite extreme.
Recently I've conducted some tests with two very popular audio compression formats - MP3 and FLAC. The idea behind the test was a simple question: Does audio compression over a ISP free signal, introduces back the ISPs? Well the answer to that question ended up slightly complicated.
My first test was with a "designed" WAV file with series of samples that would positively introduce ISPs:
view image
I've used Elephant 2 to add 24db of gain to the signal, while oversampling to x2 and limiting at -0.1 db. Then created a MP3 file directly from Reaper with LAME encoder at 320kbps, normal quality. While decoding the resulted MP3 file into Cooledit I've noticed that there is no sample clipping or eventual inter-sample peaks. Then I repeated the same test with lower bitrate MP3 - still no problems were found, after the decoding. But then I've realized that this test is flawed for the following reasons:
- the frequency response of the input signal wasn't really 'sufficient' for testing (it was just a waveform peaking around 2khz)
- the average RMS level after limiting was still quite low.
So I'vee decided to do a little bit more testing on the subject. This time with pink noise and some extreme settings.
Without explaining more I will directly post the test results. There are two tests included (for FLAC, MP3) at different RMS levels.
Test files can be downloaded from here:
mirror1
mirror2
Regarding the MP3 tests:
Decoded MP3 audio signal would only clip if the RMS of the input is very high.
There are ways to deal with this problem:
You can use the --scale command in LAME or tools like mp3gain to fix this.
But still this is sample clipping. There is a chance that no ISP will be present after normalizing the MP3 singal!
Still I should point out that there are way to many parameters involved, when conduction these tests and the test results may vary a lot.
I've also did a another much more extreme test with -1db RMS values (not included). Various limiters did not perform well in prevent ISP in these extreme conditions.
Excessive levels does not do well for ISP prevention and for audio compression.
"How to deal with compression of audio?"
- always use ISP prevention over the track.
- lower the limiter roof to -0.3, -0.5db, or even -1db
- decode the resulted mp3 file with an audio editor and check for clipping
- use statistics in your encoder (such as --clipdetect in LAME)
- of course use the best encoder possible
But still, as the above test proved moderate RMS levels, may not need any normalizations and lowering of the limiter roof at all.
Lubomir
The above article at Gearslutz explains inter-sample peaks quite well. Just to simplify it a little bit here is a time-domain plot of a sample. This could be part of any type of sound - bass guitar, synthesizer, but this is more of a 'designed' plot, since the chance of a similar sequence appearing is minimal (there are drastic changes in sample values).
view image
The areas marked with 'ISP' are the actual problems. ISPs are a digital-to-analog (DAC) conversation issue. Your digital medium such as CD-A may contain tracks that does not clip at all on normal meters, but in theory there is a chance that at certain sample configurations such as the shown above, the reconstructed (via interpolation) analog audio signal, exceeds 0 db. Such peaks will be introduced as distortion in listening conditions.
"Would this type of distortion be really that audible?"
It really depends on the playback system (DAC), the listener, the audio material. But it may be quite audible.
"Well how to prevent it?"
There are algorithms in some DSP limiters, that deal with the problem quite well. From my understanding of interpolation in mathematics, the only way to deal with such problems is to change values of the neighbor points (samples) forward and probably backwards in the time domain. Another important thing that must be done is to over-sample the signal so that more points are introduced in the plot.
Here is the list of the know limiters that prevent ISP:
Sonnox Limiter, Voxengo Elephant, TC Limiter, Izotope Ozone, PSP Xenon and others.
Note, that you must engage the oversampling mode of the limiter to enable the desired functionality.
As you may know most of these limiters are commercial products. The only free tools you would find are the meters, such as: John Schwartz's Bitter, SSL's X-ISM and others.
Still, if you are willing to buy a DSP limiter for your needs, I could not recommend a better limiter than Elephant. Its the cheapest, the most flexible and arguably the best sounding one.
Do the listed above tools really work for ISP?
Well here is the tricky part. There are certain conditions in which the ISP prevention may not work for any of the above products. However most of these conditions are quite extreme.
Recently I've conducted some tests with two very popular audio compression formats - MP3 and FLAC. The idea behind the test was a simple question: Does audio compression over a ISP free signal, introduces back the ISPs? Well the answer to that question ended up slightly complicated.
My first test was with a "designed" WAV file with series of samples that would positively introduce ISPs:
view image
I've used Elephant 2 to add 24db of gain to the signal, while oversampling to x2 and limiting at -0.1 db. Then created a MP3 file directly from Reaper with LAME encoder at 320kbps, normal quality. While decoding the resulted MP3 file into Cooledit I've noticed that there is no sample clipping or eventual inter-sample peaks. Then I repeated the same test with lower bitrate MP3 - still no problems were found, after the decoding. But then I've realized that this test is flawed for the following reasons:
- the frequency response of the input signal wasn't really 'sufficient' for testing (it was just a waveform peaking around 2khz)
- the average RMS level after limiting was still quite low.
So I'vee decided to do a little bit more testing on the subject. This time with pink noise and some extreme settings.
Without explaining more I will directly post the test results. There are two tests included (for FLAC, MP3) at different RMS levels.
input: 20 sec pink noise (WN trought 6pole 'pink' filter, simple pseudo-random
numbers generation, extended with XOR)
limiter: voxengo elephant2, default settings, 4x os, roof -0.2db, test dependant
input gain.
decoding: outputs decodeded with reaper 2.55
meter: SSL X-ISM
### test 1 -12db rms:
output wav (-12db_rms_24bit.wav): 24bit, 44100hz, no dither
* result: no ISP & no clipping
output mp3 (-12db_rms_320kbps.mp3): lame 3.98, CBR 320kbps, normal q
* result: no ISP & no clipping on decode
output mp3 (-12db_rms_96kbps.mp3): lame 3.98, CBR 96kbps, normal q
* result: no ISP & no clipping on decode
output flac (-12db_rms_q8.flac): flac 1.2.1, 24bit, q8
* result: no ISP & no clipping on decode
output flac (-12db_rms_q0.flac): flac 1.2.1, 24bit, q0
* result: no ISP & no clipping on decode
### test 2 -6db rms:
output wav (-6db_rms_24bit.wav): 24bit, 44100hz, no dither
* result: no ISP & no clipping
output mp3 (-6db_rms_320kbps.mp3): lame 3.98, CBR 320kbps, normal q
* result: ISP present & clipping on decode
output mp3 (-6db_rms_96kbps.mp3): lame 3.98, CBR 96kbps, normal q
* result: ISP present & clipping on decode
output flac (-6db_rms_q8.flac): flac 1.2.1, 24bit, q8
* result: ISP present & no clipping on decode
output flac (-6db_rms_q0.flac): flac 1.2.1, 24bit, q0
* result: no ISP & no clipping on decode
### Tests summary:
Lower RMS levels for both MP3 and FLAC decode with no clipping and ISP.
Decoding of mp3 streams with higher RMS level introduce clipping,
but when normalized, ISPs are not present. Higher RMS level flac q8 does
not clip, but strangly ISP are present. Lower compression q0 for FLAC preforms
very well for higher RMS values.
The tested compressors deal much better with lower RMS values.
Test files can be downloaded from here:
mirror1
mirror2
Regarding the MP3 tests:
Decoded MP3 audio signal would only clip if the RMS of the input is very high.
There are ways to deal with this problem:
lame -b 320 --clipdetect [file]
...
WARNING: clipping occurs at the current gain. Set your decoder to decrease
the gain by at least 0.1dB or encode again using --scale [arg]
(For a suggestion on the optimal value of [arg] encode
with --scale 1 first)
You can use the --scale command in LAME or tools like mp3gain to fix this.
But still this is sample clipping. There is a chance that no ISP will be present after normalizing the MP3 singal!
Still I should point out that there are way to many parameters involved, when conduction these tests and the test results may vary a lot.
I've also did a another much more extreme test with -1db RMS values (not included). Various limiters did not perform well in prevent ISP in these extreme conditions.
Excessive levels does not do well for ISP prevention and for audio compression.
"How to deal with compression of audio?"
- always use ISP prevention over the track.
- lower the limiter roof to -0.3, -0.5db, or even -1db
- decode the resulted mp3 file with an audio editor and check for clipping
- use statistics in your encoder (such as --clipdetect in LAME)
- of course use the best encoder possible
But still, as the above test proved moderate RMS levels, may not need any normalizations and lowering of the limiter roof at all.
Lubomir
Sunday, January 4, 2009
#JesuSonic plugins for Reaper
JesuSonic from Cockos proved to be a very efficient and flexible platform for designing DSP effects. The JS engine is bundled with Reaper (aka the ultimate secret weapon DAW).
I have created a small pack of JS fx that I regulary update (or used to) at the Cockos forum. The pack includes various filter implementations such as the the classic Moog, Butterworth, Chebyshev Type I and various fx that I have either ported/modified from other programming languages or designed from scratch.
You can always check for the latest version of the pack at this page:
Link
Lubomir
I have created a small pack of JS fx that I regulary update (or used to) at the Cockos forum. The pack includes various filter implementations such as the the classic Moog, Butterworth, Chebyshev Type I and various fx that I have either ported/modified from other programming languages or designed from scratch.
You can always check for the latest version of the pack at this page:
Link
Lubomir
Subscribe to:
Posts (Atom)
Posts
