http://syntheway.net – Promenade (Demo from Pictures At An Exhibition – Modest Mussorgsky) using VSTi software.

- Aeternus Brass VSTi
http://aeternusbrass.syntheway.net

- Syntheway Strings VSTi
http://strings.syntheway.net

- Percussion Kit VSTi
http://percussion.syntheway.net

Additional Info: Demo based on a famous suite of ten piano pieces composed by Modest Mussorgsky in 1874.

Aeternus Brass VSTi: Is a Virtual Brass instrument, featuring solo Trumpet, Cornet, Trombone, Tuba, French Horn, Flugelhorn.

Syntheway Strings VSTi: Is a “rich-sounding” sample based string VST instrument.
Multi-sampled Ensemble Strings includes: Violin, Viola, Cello & Double Bass

Syntheway Percussion Kit: Is a collection of percussion instruments designed for creating Orchestral Percussion, Auxiliary Percussion, Mallet Percussion, Latin Percussion and African Percussion.

http://syntheway.net
http://syntheway.com

And stylish little brother (or sister?):

See you soon!

- Stability improvements when loading bridged plugins.
- better GUI handling for 32bit VST plugins.
- Fixed a problem where in some hosts jBridgeM’s controls would not be displayed.

more info here.

( note to all registered users: if you don’t receive this update in your email during the next 24h please contact me. )

I discovered this beautiful collection on Flickr recently and have since become really enthusiastic about product design from the 1970s. There’s just something about those simple color schemes, the clean fonts, a sense of futuristic minimalism from a time forgotten. But whatever the case, looking at these things has been somewhat of an inspiration for the GUI direction of my new VST synth project for Psychic Modulation, which I will be posting more about soon. The interface design I’m working on is an attempt to strike a perfect balance between form and function. The design aspect seems to reflect what I hope to achieve in the instrument itself. A tool designed with functionality in mind, very fun and inspiring to work with, that can get quick results without the stress. That’s kind of how I imagine the products in these images. They must have been, at least in their time, a real pleasure to use. And even though they might be rendered obsolete, a real inspiration to look at.

First, I want to post some “fan-art” stuff for alpha version.

1. Blue skin by Ade Emsley. Use it with alpha version if you like it.

[Limiter6 alpha with blue theme (Windows 32-bit and 64-bit versions)]

[Limiter6 alpha with blue theme (Mac OS X 32-bit version)]

(NOTE: Mac OS X version has small bug. If you change “Dry Mix” parameter with mouse wheel it’s OK. But it you change it with mouse drag the shown parameter value is not updated.)

2. Cleaned up Limiter6 manual by Paul Schwartz

[Limiter6 manual]

3. I almost completed photo-realistic version of GUI. There’re some draft screenshots:

And this is something original. Japanese GUI translation! Thanks to Ryoma Nishiyama.

Also some working moments:

You can also check this: http://vimeo.com/42123234

Sorry for a long waiting but I try to complete it as soon as possible. See you soon!

- Fixed a problem where in some cases the installer could cause a crash.
- Several stability improvements.

more info here.

( note to all registered users: if you don’t receive your update in your email during the next 24h please contact me )

- Reduced memory usage.
- Stability improvements for plugins running in the same auxhost.
- other minor fixes.

more info here.
( note:  You can install this update over your existing installation, no need to re-create the bridging files.   )

- fixed crash during startup in SAWStudio.
- fixed crash that could happen with Halion.
- Reduced memory usage ( Specially relevant if you’re using a 32bit VST host ).
- Unlimited number of inputs/outputs and all buffer sizes are now supported.
- Optimized resource usage.
- auxhosts should now quit after the main host on a forced shutdown ( thanks for the hint and the help, Jeremy! )
- added workaround for plugin scanning problem with Kore2.
- Other minor bugfixes.

jBridger 1.21:

- added option to reset origin and destination folders for bridging files.
In some situations, user was unable to access the desired folders, enabling this option on a new scan should clear the problem.

Note to all registered users: if you don’t receive your update during the next 24h ( check the spam folder if needed ) please contact me.

more info here.

This is my first experience programming for Mac OS X, so there’s still a lot of room for improvements of this, but I hope that it may of some use as is currently.

Your feedback is much appreciated.

Thanks!

1. Use VST3 format.
2. Use 4 inputs (1, 2 for signal and  3, 4 for sidechain) and DAW that supports 4 inputs routing (Reaper for example).

My choise for Molot 0.3 is #2. If you select external sidechaining in GUI it looks something like this:

But if your DAW doesn’t support 4 inputs, this is the version of Molot 0.3 with 2 inputs and disabled external sidechaining support:

[Molot 0.3: 2 channels version (VST, Windows 32-bit, 64-bit)]

1. External stereo sidechaining support (inputs 3 and 4).
2. Linear phase oversampling support (latency 344 samples).

See more details on [Molot] compressor page.

PS. Yes, I know this GUI for extended parameters doesn’t look so good. It will be changed to more usable one in the next release.

This plugin is unique combination of slow RMS-compressor, peak limiter, high-frequency limiter, oversampled clipper and inter-sample limiter. The idea of this combination is “gain staging” when each stage used a little to make a most clean sound.

This is not a plugin with 1 knob and smart brain inside, which allow making your mix 0 dB RMS. All settings are manual and there’re a lot of knobs.

The GUI is a draft yet and will be redrawn to photorealistic military style.

[Windows 32-bit version VST ]

[Windows 64-bit version VST]

[Mac OS X 32-bit version VST]

[Manual (en)]

[Manual (ru)]

<Check also this updated stuff>

PS. My plans are:

1. Prepare new Molot release
2. Draw a GUI for this plugin and make beta-version

This is my old work for Sound on Sound “Flags” remix competition. Just mixdown. No mastering processing. “Molot” was the only type of compressor used for this mix. 

http://soundcloud.com/vladg/flags-54-remix-competition-no

(as usual I recommend you do not press “play” and listen soundcloud’s encoded mp3 but download wave file by pressing “arrow down” button)

And this is my try to use new limiter plugin on master.

http://soundcloud.com/vladg/flags-54-remix-competition

This is the screenshot of settings (public alpha will come soon and you’ll be able to try it).

And also Sound on Sound’s Mike Senior version of remix just for kicks.

http://soundcloud.com/flagstheband/54-mike-senior-remix-1

Check also this:

http://www.soundonsound.com/sos/mar11/articles/mix-rescue-0311.htm

And a note about last freeware compressors released. I like these compressors very much:

http://www.tokyodawn.net/tdr-feedback-compressor/

http://varietyofsound.wordpress.com/2012/03/02/thrillseekerla-released-today/

Thumbs up!

It is an interesting test. To compare the character of new plugin with Molot I used both of them for 8 track drum record which is the part of the mix I was experimenting with.

NOTE: These are soundcloud links but don’t press “play” button because due to mp3 soundcloud’s encoder they contain a lot of encoding artifacts. Just download these records (as 32-bit waves ~70 Mbytes each, press “arrow down” button to do it) and then listen to them.

#1. Molot compressor. Presets “kick”, “snare”, “overheads”, “room”, “DRUM BUSS”, “Master BUSS” were used. The sound is… aggressive and hammering!

http://soundcloud.com/vladg/molot-compressor-test

#2. New plugin was used for kick, snare, room tracks and drum and master busses. The sound is… For me it’s very soft, wide and with a lot of depth.

http://soundcloud.com/vladg/limiter6-vs-molot-compressor

#3. Molot plus new plugin. Molot plugin was used for kick, snare, overheads and room tracks. New plugin was used for drum and master busses. For me these plugins are like the best friends

http://soundcloud.com/vladg/molot-compressor-plus-limiter6

Also the screenshot of settings that were used:

The signal chain is: RMS compressor -> Peak limiter -> HF limiter -> Clipper -> True peak limiter

The plan is:

1. Prepare public alpha version of limiter plugin. This version will have draft GUI but all functionality included and working.
2. Prepare next release of Molot compressor.
3. Take a break and make photorealistic GUI for limiter plugin.

Good luck!

After that I’ve made union of all modules to new Limiter6 plugin mentioned here. Unfortunately it has too many parameters and without GUI and levels indication it’s truly brain damage to try to use it:

The concept was changed a bit. Now this is slow RMS limiter followed by very fast peak limiter followed by the clipper and ended with true peak limiting stage. All stages can be turned on and off. Peak limiter and the clipper can work in M/S mode. Peak limiter can also work as high-frequency limiter. The whole plugin can work in stereo mode for master or mix busses and in mono mode for instrument tracks which I believe can be useful.

The conclusion? I have to do simple GUI for it and try to use the plugin in sample projects to find its strongest and weakest points. That’s the way.

It’s -20 C (-4 F) behind the window, a lot of snow and I’m really disappointed with peak limiter module. So I did a try to enhance it. You can check this [peak limiter VST plugin (x86,x64)]. I think it sounds better this time.

Now  I can continue to build up my new mega-limiter from all modules I have (see previous post). The codename for this project is now “Limiter 6″ (in japanese it sounds like “rimitta roku” which I like).

On the first look it’s gonna be too many knobs and switches. So it’s really a challenge to place them all on GUI and make it usable. Maybe I should remove or hide some of them…

I’m continuing my work. Good luck!

The signal chain will be: DC Cut Filter -> RMS Limiter -> Peak Clipper -> Peak Limiter -> Output Clipper

• DC Cut Filter – to cut unnecessary lows (and to remove DC offset);
• RMS Limiter – to stabilize crest factor and to average loudness;
• Peak Clipper – to cut very strong peaks to help peak limiter not to “thump” on them (can work in M/S mode, have different knees to switch);
• Peak Limiter – to limit peaks (can work in M/S mode, can work as high-frequency limiter just to soften the sound);
• Output Clipper – (can work in true peaks mode to avoid inter-sample clipping or in simple mode just to clip samples, has switchable auto-gain mode to automatically level up the sound to -0.3 dbFS).

Maybe soft-knee control can be useful for Peak Limiter (I’ll check this soon). Maybe DC Cut Filter is better to place just before output clipper (I’ll check this later). I have no ideas about GUI yet.

By the way, I found that use regular compression curves with no high ratios (4:1 for example) for RMS limiter is better than limiting curve. I reimplemented the last RMS Limiter module (see previous post) with “Ratio” parameter and I think it sounds now pretty good. (Actually, I love how it sounds .) If you interested in you can check this [RMS limiter VST plugin (x86,x64)].

Good luck!

PS. I think the idea to show each small step of development of new plugin is better than keeping silence for year and after that to show only the last final step: the release version. I prefer continuous development process on each step of that you have something to check and to listen.

My idea is the slow RMS limiter before peak limiter/clipper helps to maintain constant crest factor and improves sound. So I did simple plugin to check this idea. Download it here: [slow RMS limiter VST plugin (x86,x64)].

The plugin parameters:

• “Gain” – input gain boost before any processing;
• “Thresh.” – RMS limiting threshold;
• “Attack” – think of it like RMS window size for signal level detector. The attack time is in seconds. The minimum value is 0.05 = 50 ms.
• “Release” – gain reduction release time. This time is time constant based (the time for GR to fall from 100% to 36.8%). In minimum “Off” position release time for gain reduction is not used;
• “Sidechn.” – sidechain high-pass filter (based on Molot one);
• “DryMix” – mix output with raw input (before gain boost) to fatten it up;
• “Lookahd.” – control lookahead. If “On” 10 ms lookahead is used. If “Attack” parameter has minimum value lookahead really helps to limit kick peaks for example. For greater attack times it helps to soften the sound. You can turn it off for taste or for realtime usage (if “Off” the plugin has zero latency).

The plugin is a bit tricky to tune up but I like it! Now I think it’s time to mix all my module prototypes to single cool limiter plugin!

PS. According to this site statistics “Most visitors came from The United States. Germany & Japan”. Maybe it’s a good idea to make translation of Molot GUI or even Molot manual to German & Japanese languages? Does anyone eager to help? Ж-)

Let’s talk about 32-bit vs. 64-bit sound processing in VST plugins (not only talk but also I have [3 plugins to perform audio tests]!)

1. 32-bit single precision floating point format (a.k.a. float)

Used in most DAWs. The main format for VST plugins to process (AudioEffect::processReplacing).

Got:
- Sign bit: 1 bit
- Exponent width: 8 bits
- Significand precision: 24 (23 explicitly stored)

The sample values for 0 dbFS are between -1.0 and 1.0. So it’s actually 24 bits per sample.

2. 64-bit double precision floating point format (a.k.a double)

Optional format for VST plugins to process (AudioEffect::processDoubleReplacing starting from VST 2.4). Some DAWs declare if all plugins in chain use 64-bit processing the whole signal chain has 64-bit processing.

Got:
- Sign bit: 1 bit
- Exponent width: 11 bits
- Significand precision: 53 bits (52 explicitly stored)

The sample values for 0 dbFS are between -1.0 and 1.0. So it actually 53 bits per sample.

There’re 2 main questions to use double instead of float:

1. How much is performance degradation?
2. Is it noticable audio quality enhance?

My answers to these 2 questions are:

For question 1:

1a) Long mathematical calculations (not DSP) works ~2 times faster with single precision.

1b) Typical (my) plugin code with a lot of border conditions and some calculations between conditions works faster with double precision! I don’t know is it related with branches prediction or instructions reordering in CPU or with data alignment or with compiler optimizer (Visual C++ 2005 compiler with full optimizations on).

1c) SSE/SSE2 with manual assembler coding for bulk data processing (such as convolution) works 2 times faster with single precision (because SSE can process 4 floats instead of 2 doubles simultaneously).

For question 2:

For my ears there’s a noticable sound difference! But what is the compromise between speed and quality? I think the compromise is to use the dithering!

Check your ears and monitoring!

These are [3 versions of VST clipper plugin (x86,x64)] to check. This is the same plugin as in my last post but I added new parameter “Ovr.mode” – Signal/GR. If “Signal” is set the whole signal is upsampled, processed and downsampled. If “GR” is set only Gain Reduction signal is oversampled. To better hear the difference use “Signal” oversampling mode.

Version 1 [double]. Upsampling and downsampling use 64-bit double precision processing.

Version2 [float]. Upsampling and downsampling use 32-bit single precision processing.

Version3 [float-dither]. Upsampling and downsampling use 32-bit single precision processing but with the dithering.

TEST 1. Process the same audio sample with 3 versions of plugin and try to hear the difference. Use “Signal” mode. All another parameters set for taste but they must be the same for all of the tests! (For example I used 0 dB gain, -9 dB threshold, “A” shape, hardclip “Off”)

What is my result? I used 32-bit float wave-file for output so even fot the case of internal 64-bit audio processing I heard the output in 32-bit. But there’s a difference! And the difference is in depth! “Double” version sounds just amazing, “Float” version has sound with lack of back planes, “Float-dither” version sounds much better than regular “float”.

TEST 2. Now use “GR” mode with the same audio samples and the same settings.

In “GR” mode for performance reasons if gain reduction not needed for a relatively long period the signal bypasses oversampling. That’s why in this mode the difference is hardly noticable. But I think “float” version sounds bad and both “double” and “float-dither” versions sound quite good! So my choise was “float-dither” (the clipper plugin in my last post had exactly these settings hardcoded).

I want to share 2 fresh conclusions I’ve got:

1. Hard-clipping sounds bad.
2. If hard-clipping sounds good it’s really soft-clipping.

My old opinion was: “Hard clipping sounds better than soft clipping because hard clipping starts later and affect signal for a shorter time”. Now I think I was wrong.

And I did VST clipper plugin just to check idea:

[download VST clipper plugin (windows 32-bit, 64-bit)]

DETAILS:

• 4x linear phase oversampling
• 256 samples of latency
• The main signal is not resampled. Only gain reduction signal passes through oversampling stage.

PARAMETERS:

1. “Gain” – input gain before clipping. Just set it to +6 dB and see the result!
2. “Thresh.” – clipping threshold. I limited maximum value to -0.3 dBFS.
3. “Shape” – soft knee shape (A: -6 dB knee, B: -3 dB knee, C: -1.5 dB knee).
4. “Hardclip” – due to oversampling imperfection (and Gibbs phenomenon too) output signal can overshoot threshold given. To deal with that the output signal have to be digitally clipped controlling by this parameter:
   - “Off” – no output digital clipping is used. Use this value if the threshold is very low or this plugin is not the last plugin in chain (for example it used before brickwall limiter to reduce pumping effect).
   - “Thresh+” – output digital clipping has threshold +0.2 dB higher than soft clipping threshold but can’t exceed -0.15 dBFS. So if you set clipping threshold to -0.5 dBFS output signal can’t exceed -0.3 dBFS.
   - “-0dbFS” – output digital clipping has threshold of -0.15 dBFS regardless of soft clipping threshold.
5. “DC.flt” – if “On” the 2nd order high-pass filter for 25 Hz is turned on. Filter works in the beginning of the chain e.g. before clipper. Added just to experiment. I think it doesn’t sound good. BTW, the best high-pass filter I ever heard was in preFIX plugin of Variety of Sound).

LIMITATIONS:

1. Plugin doesn’t prevent inter-sample peaks to exceed threshold level.

SEE ALSO:

See how soft clipping works in Lavry AD122 converter (see p.18 in [manual]).

MY PLANS:

Now I should work on slow limiter to limit not signal peaks but signal “body” for upcoming clipper/limiter plugin.

Happy holidays!

I think I’ve got some kind of concept for upcoming clipper/limiter plugin. This plugin is planned to contain these modules:

• input clipper
• peak limiter (a.k.a “thin” limiter)
• signal limiter (a.k.a “thick” limiter)
• peak meter / output clipper

All modules are optional and can be turned off. Peak limiter has very fast attack/release and used only to limit peaks of signal. This “thin” limiter can optionally be used as HF limiter to limit only high-frequency components of peaks. Signal limiter has long attack/release settings to limit signal “body”. This “thick” limiter can be used in brickwall mode or in analog-style mode to pass parts of attacks through. Final clipper can work in inter-sample peaks suppression mode. And I think some high-pass filter to remove DC offset can be useful. That’s the concept.

Also I already implemented some ideas for peak limiter as test plugin. You can [download] it to check (Windows VST 32-bit and 64-bit).

What’s done in this test plugin:

• very fast attack/release limiter plugin
• only 6 samples of latency (in 44.1 kHz) so it can be used realtime
• it’s intended to limit signal peaks only so it sounds bad when limiting the signal “body”

What’s not done in this test plugin:

• no oversampling
• no inter-samples peaks detection
• no high-frequency limiting yet

So that’s it.

PS.

It’s hard not to tell something about politics and last weeks events.

“Brain slugs I didn’t vote for you”. The girl with this poster for [fair elections] had a part in action of protest and was arrested by local police ten days ago. Fortunately she was freed on the next day by judge decision with small fee as penalty. Sad = Funny

Anyway it’s holidays soon. So let’s think about presents and shopping now

- fixed no sound problem with some plugins.
- fixed hang that could happen with several plugins hosted in the same auxhost, when some where using the “integrated GUI mode” and others the “separated GUI mode”.
- compatibility tweaks added for more versions of WaveShell’s.
- added a button to quickly edit the settings file in the settings dialog.
- fixed garbled audio problem with some hosts.
- tweaked compiler performance options.
- fixed machine-gun-like sound problem with Nomad-Phaser ( and possibly other effects ).
- Fixed problem where settings would not be saved with some plugins.
- Fixed issue where changing the patch in the plugin’s GUI would not update the current patch in the main host’s preset selector.
- Fixed VST SDK version incorrectly reported.
- Fixed issue with plugins that use the audioMasterTempoAt opcode.
- Compatibility/Performance enhancements for automation handling.
- Other minor fixes/improvements.

For faster future updates (above 1.4) and beta versions, a new section will be available here:

http://jstuff.wordpress.com/jbridge/updates/

Note to all registered users: if you don’t receive your update in the next 24h ( check the spam folder if needed) please contact me.

more info here

Using SoX resampler inside plugin is quite simple. First, append these files of libsox (see the image, sox-14.3.2 was used in my example):

Next, SoX interface uses integer sample type. But SoX resampler uses floating point. To avoid multiple conversion it’s better to use not libsox interface but functions in rate.c directly. And also to add interface to access internal functions outside of rate.c file. This can be done by directly including “rate.c” file in your file:

/*
 * the only way to access private SoX rate functions is to include rate file here
 */
#include “rate.c”

/*
 * now implement our interface to access private SoX rate functions
 */

#include “soxrate.h”

struct soxrate {
    rate_t          rate;
    rate_shared_t   shared;

    int             linear_phase;
    double          bandwidth;
    int             allow_aliasing;
};

static int      g_libsox_init = 0;

struct soxrate *
soxrate_create(double factor, int linear_phase, double bandwidth, int allow_aliasing)
{
    struct soxrate *r;

    if (g_libsox_init++ == 0) {
        // init globals
        init_fft_cache();
    }

    r = calloc(1, sizeof(*r));
    if (r == NULL)
        return NULL;
   
    r->linear_phase = linear_phase;
    r->bandwidth = bandwidth;
    r->allow_aliasing = allow_aliasing;

    rate_init(&r->rate, &r->shared, factor, Very, -1, linear_phase ? 50 : 0, bandwidth, allow_aliasing ? sox_true : sox_false);

    return r;
}

…

See complete implementation in soxrate.c file in [archive]. This archive contains Molot source code cutted in such a way so only saturator has left. Project “molotsat.vcproj” uses standart Molot oversampler. Project “molotsat2.vcproj” uses SoX resampler. You can compare how they sounds.

The “C” interface h-file for soxrate.c is quite simple:

#ifndef _soxrate_h_
#define _soxrate_h_

/*
 * abstract interface to SoX rate internal interface
 */

struct soxrate;

struct soxrate  *soxrate_create(double factor, int linear_phase, double bandwidth, int allow_aliasing);
struct soxrate  *soxrate_clone(struct soxrate *param_r);

void    soxrate_delete(struct soxrate *r);

void    soxrate_process(struct soxrate *r);
void    soxrate_flush(struct soxrate *r);

const double    *soxrate_output(struct soxrate *r, size_t *n);

double  *soxrate_input(struct soxrate *r, size_t n);

#endif

But VST SDK is a set of C++ classes. So it’s better to implement Upsampler/Downsampler C++ classes. Upsampler’s main function looks like this:

void
Upsampler::processSample(double x, double *y)
{
    double *input_fifo;
    const double *output_fifo;
    size_t size;

    // feed input
    input_fifo = soxrate_input(m_rate, 1);

    _ASSERT(input_fifo != NULL);

    *input_fifo = x;

    // process!
    soxrate_process(m_rate);

    // get new fifo
    size = m_xN;

    output_fifo = soxrate_output(m_rate, &size);

    if (size < m_xN) {
        _ASSERT(size == 0);

        memset(y, 0, m_xN * sizeof(double));
   
    } else {
        _ASSERT(size == m_xN);

        memcpy(y, output_fifo, m_xN * sizeof(double));
    }
}

The downsampler’s function is not complex too:

double
Downsampler::processSample(double *x)
{
    double *input_fifo, y;
    const double *output_fifo;
    size_t size;

    // feed input
    input_fifo = soxrate_input(m_rate, m_xN);

    _ASSERT(input_fifo != NULL);

    memcpy(input_fifo, x, m_xN * sizeof(double));

    // process!
    soxrate_process(m_rate);

    // get new fifo
    size = 1;

    output_fifo = soxrate_output(m_rate, &size);

    if (size < 1) {
        y = 0.0;
    } else {
        y = *output_fifo;
    }

    return y;
}

See moloteng.h and moloteng2.cpp files in archive. Also I used dithering there but you can remove it.

Usage of these upsampler/downsampler classes is simple:

double
ChannelCompressor::processSample(double x)
{
    double over[MAX_OVERSAMPLING];
    unsigned int i;

    m_upsampler.processSample(x * m_gain, over);

    for (i = 0; i < m_oversampling; i++) {
        //over[i] = m_saturator.processSample(over[i]) * m_master;
    }
    return m_downsampler.processSample(over);
}

It works! But too-o-o-o slow! Why? Because SoX resampler is optimized not for easy 2x or 4x upsampling/downsampling but for fractional resampling (44.1 -> 48 kHz for example). It uses DFT for filter implementation regardless of filter type. There’s a comment in rate.c:

       /* Start setting up post-stage; TODO don’t use dft for short filters */

How to make it faster? The answer is not to use DFT but to use simple FIR filter. The idea:

1. Use SoX library only to get FIR responses for filters
2. Implement FIR filters convolution

I did FIR responses for upsampler and downsampler for cases of 2x, 4x and so on oversampling in this way:

            char str[256];
            double *f;
            int i, num_taps;

            f = lsx_design_lpf(0.931, 1.0, 2.0, sox_true, 34.0 / 33.0 * 170.0, &num_taps, 0);
            //f = lsx_design_lpf(0.931, 1.0, 2.0, sox_false, 170.0, &num_taps, 0);
            //f = lsx_design_lpf(0.931, 1.0, 4.0, sox_true, 34.0 / 33.0 * 170.0, &num_taps, 0);
            //f = lsx_design_lpf(0.931, 1.0, 4.0, sox_false, 170.0, &num_taps, 0);
            //f = lsx_design_lpf(0.931, 1.0, 8.0, sox_true, 34.0 / 33.0 * 170.0, &num_taps, 0);
            //f = lsx_design_lpf(0.931, 1.0, 8.0, sox_false, 170.0, &num_taps, 0);
            //f = lsx_design_lpf(0.931, 1.0, 16.0, sox_true, 34.0 / 33.0 * 170.0, &num_taps, 0);
            //f = lsx_design_lpf(0.931, 1.0, 16.0, sox_false, 170.0, &num_taps, 0);

            for (i = 0; i < num_taps; i++) {
                if (f[i] != 0.0)
                    sprintf(str, “%0.15e,\n”, f[i]);
                else
                    strcpy(str, “0,\n”);

                printf(“%s”, str);
            }

            free(f);

Parameters for functions were get like sox utility used in maximum quality mode. Aliasing for upsampling is allowed to make FIR shorter but is not allowed for downsampling.

Finally I’ve got files with numbers. For example fir4_dn.dat (used for 4x downsampling):

/*
 * generated using libsox library
 * lsx_design_lpf(0.931, 1.0, 4.0, sox_false, 170.0, &num_taps, 0);
 */
7.591330618410162e-011,
1.315100930944295e-010,
1.176132593954115e-010,
6.273241512488595e-012,
…

Now all I have to do is to write fast convolution implementation and some helpers. For speed up I used SSE and 32-bit floating point to make 4 multiplications per time. I’m not a great programmer for speed and optimizations so my implementation is far from perfect but fast enough.

// fir must be aligned! fir_size must be %16!
double
FirFilter::fast_convolve(float *x)
{
    unsigned int i;
    double y;

    // convolution

    __m128 xy1, xy2, xy3, xy4;

    xy1 = _mm_setzero_ps();
    xy2 = _mm_setzero_ps();
    xy3 = _mm_setzero_ps();
    xy4 = _mm_setzero_ps();

    for (i = 0; i < m_fir_size; i += 16) {
        xy1 = _mm_add_ps(xy1,
            _mm_mul_ps(
                _mm_loadu_ps(x + i),
                _mm_load_ps(m_fir + i)
            )
        );
        xy2 = _mm_add_ps(xy2,
            _mm_mul_ps(
                _mm_loadu_ps(x + i + 4),
                _mm_load_ps(m_fir + i + 4)
            )
        );
        xy3 = _mm_add_ps(xy3,
            _mm_mul_ps(
                _mm_loadu_ps(x + i + 8),
                _mm_load_ps(m_fir + i + 8)
            )
        );
        xy4 = _mm_add_ps(xy4,
            _mm_mul_ps(
                _mm_loadu_ps(x + i + 12),
                _mm_load_ps(m_fir + i + 12)
            )
        );
    }

    xy1 = _mm_add_ps(
            _mm_add_ps(xy1, xy2),
            _mm_add_ps(xy3, xy4));

    float xy_flt[4];

    _mm_storeu_ps(xy_flt, xy1);

    y = xy_flt[0] + xy_flt[1] + xy_flt[2] + xy_flt[3];

    return y;
}

Some more details for source code. As upsampling is done by zero inserting, e.g. append (x, 0, 0, 0) for case of 4x oversampling in the input of the filter and get (y1, y2, y3, y4) to get oversampled output some optimization was used. The FIR is splitted into 4 parts to avoid multiplications on zero (see FirFilterN class). UpsamplerNx/DownsamplerNx are the classes for SoX FIR filters. Upsampler/Downsampler are the classes for standart Molot oversampling.

See the complete source code in this [archive]. This archive contains source code for simple acceleration limiter plugin. The idea for plugin is to limit vinyl cutter speed. But in this plugin simple waveshaping is used so it’s just an example and not intended for real work.

The original Molot oversampler also included in both archives so you can compare how the different oversampling implementations differs in sound.

Hope it helps.