RIP

it adds significantly more / better functionality
Except the AF2-10 is stereo only and has no overall gain adjustment. It would be nice to have a mono version at least!

@anahata: ? ! The gain control is on the righthand side of the EQ graph, as shown in the manual, contained in the download and being a VST, you can use it as mono or stereo, provided the host application supports the standard routing behaviour expected (I think even Ardour now sorts this out reasonably well). There’s some other stuff like filter algorithms that can be swept across the entire audio range, while maintaining the correct (equivalent analogue) gain at Nyquist, in some cases equating to an effective cut-off point beyond Nyquist, but that’s probably not important.

Well, colour me embarrassed for not RTFM! There it is indeed.
Also when I tried it in a mono channel before there was a jump in level (first I thought I’d done something wrong, but it’s understandable if the two outputs were being summed back to mono). I’ve just tried it again and that doesn’t seem to be happening, and anyway if it does there’s 6dB of gain cut available to compensate.

Unrelated (and back on topic) josander makes a good point:

And as a pragmatic Linux fanatic, I think it's much better for the "sake" of Linux that the symbols of Windows, OSX and Linux stands side by side when you want to buy or download a product.

Having now looked at the overtonedsp web site, I have to agree. It’s good to see Linux “up there” with Windows and Mac OS without further comment, and in a funny way the linux audio world may gain more credibility amongst Windows users when they see that people are actually paying for Linux based products.

@anahata: The plug-in itself doesn’t do any summing in ‘mono’ mode - it just provides a ‘canMono’ or some such ‘canDo’ indicator to the host (may not even be necessary in VST2.4, I would have to look again at the code) - the host may handle mono channel -> stereo plug-in in various ways (all of which it should level-correct for) e.g.

  1. Use left (or right) only - no correction needed.
  2. Feed the same signal to all the plug-in’s channels and sum (average) the output, in which case, implicit in the ‘average,’ there should be no level increase. I don’t know which of these options Ardour now provides.

The AF2-10 was envisaged as a stereo buss / mastering EQ rather than ‘one in every channel’ processing - of course - CPU / memory resources permitting - you can use it however you need, but I find myself normally using simpler EQ / Dynamics for channel processing.

Ardour’s signal flow graphics with the AF2-10 imply splitting mono to both inputs. If the output is average of L and R that’s perfect.

Now that LinuxDSP is ‘ported’ over to OvertoneDSP will there be a MBC2B equivalent at some point? Regarding the AF2-10 EQ, it seems really nice & I suspected it was intended to replace the Black-EQ but… there’s still a place and a need for a mono EQ that does at least what the Black (MK II Graph-EQ) did. Not necessarily for it’s graphical use (though it would almost go without saying) but for it’s use in audio track diagnostics. I usually agree that for mono tracks a ‘fancy’ mastering quality EQ is not needed; but for those other times, not every bare-bones notch filter out there has is usually as free of comb-filtering and similar artifacts as what you’ve been able to do with your plug-ins filter algorithms, Nyquist wizardy etc.

It may be a little late to ask but I’ve been wondering all this time what the real difference was between the MK II Graph-EQ and the Black which replaced it as an unsupported upgrade, and likewise, the difference between the MBC2 and MBC2B which replaced it (other than the increase from a -20db to -40db threshold)?

I really like your multi-band compressor (still on the original MK II Graph-EQ and MBC2) as it’s my ‘Go To’ plug-in of the sort on the Linux platform and hope you continue to develop it. As well as the VC-2B. With regards to the OP, let RIP stand for Resurrection In Progress!!

Reading the last few posts I may have misunderstood the mono-compatibility of the AF2-10 when being used on a mono track in Ardour. Maybe paul or linuxdsp can clarify if this plugin indeed works properly, exactly as a mono version of the plugin would, when used in Ardour. Not an exact quote but: Summing the output, implicit in the average, ‘should’ be no level increase just eludes me a little regarding this inquiry, i.e. if it works exactly the same in mono. Still, the AF2-10 being admittedly designed for stereo use, it’s probably excessive in CPU when used for mono tracks, thus adding to the case for a ‘Black EQ-uivalent’ in frills to still exist for mono use. Good day.

@BigstevE: There will be more plug-ins ported across, what there is at the moment is not an definitive list, but it made sense to prioritise the plug-ins for which there were already Mac / Windows ports.

'should' be no level increase...
The plug-in just has left and right channels, signals at the left input go to the left output, signals at the right input go to the right output. It doesn't have any concept of mono or stereo in that sense. If the host application implements mono->stereo processing by feeding the same (mono) signal to left and right inputs on the plug-in, then logically the host should also deal with the plug-in's outputs in a sensible manner. That might include averaging left and right (since in this case the same signal would be on left and right it equates to adding the signal to itself and dividing the result by 2, hence no level change). Or If the host application implements mono by feeding the (mono) signal to the left (or right) only, then the host application should deal with the plug-in's output by listening only to that one output, in which case there is no need for level adjustment either.

The point is, the plug-in doesn’t know or care about any of this, it just provides two (in this case, independent) channels and advertises to the host that it can do mono - in other words, that it makes sense to use one or other of the two options previously mentioned. Therefore I use the word ‘should’ because beyond that ‘recommendation’ , I have no control over what the host application will actually do with the plug-in (or its output).

...probably excessive in CPU...
With the FFT switched off, the CPU usage is minimal.

@linuxdsp: Thanks for the very detailed response. That mini-lesson helped me understand what to discern regarding plug-in/DAW compatibility. Good to know there’s more plugins to port as well as how the CPU use can be conserved with the AF2-10.

Just to be clear, VST’s “canDo” feature for plugins is not used by all hosts to deal with plugin I/O configuration. this is why some plugin manufacturers produce separate mono + stereo versions of their plugins. In Ardour at present we only support the notion that a plugin can alter its I/O configuration in response to a host request for AU format plugins. All other formats are assumed to defined fixed I/O configurations that cannot be changed by the host. For VST, the I/O configuration is discovered during a plugin scan and the information is then cached.

@paul: In this case, that’s exactly what happens. The plug-in reports that it has two input and two outputs. It doesn’t / cannot change its configuration. It relies on the host application to manage the translation between mono / stereo if it is inserted into a mono channel. It reports ‘canDo’ as a courtesy to those host applications which might query that option.
Obviously AudioUnits are a different matter. The AudioUnit standard explicitly defines a mechanism which allows both the host and the plug-in to agree on which formats the plug-in can / will support and the host (should) then use that information intelligently.

For anyone not certain about how the plug-in works, regarding mono / stereo configuration, another way to think of it is like this:

If the VST plug-in was physical hardware it would have two input sockets and two output sockets. How you wire that up for mono operation is not a function of the unit itself. It’s the same here. We provide two input and output connections to the host application. The plug-in is not involved with how they get wired up to achieve mono / stereo or other configurations.

If the AudioUnit version was physical hardware it would have two input sockets and two output sockets. One I / O pair would be labelled ‘Left / Mono’ and the other other would be labelled ‘Right’. In this case more as a recommendation / hint about how it should be used, but not a mechanism to enforce that.

That’s not strictly correct. VST allows the detection (in theory) of which inputs (and outputs) are connected, just as a physical device could use “jack sensing” to do the same. The behaviour of both a plugin and a piece of physical hardware could differ (internally) depending on what was connected. I am not familiar with the details of their “pin is connected” stuff and I don’t know if current Ardour 3 supports it (it may be an option only in VST3 … not sure).

<blockquoteThat’s not strictly correct…

I was deliberately simplifying it (by excluding that which wasn’t relevant to how this plug-in works).

After reading the info page at linuxDSP along with the comments here and elsewhere, AFAICT it’s all a good thing for everyone if it means Mike keeps creating high-quality plugins for Linux.

Best,

dp

@linuxdsp… one thing I’m not clear about is how I get my “cross-grade” to the vst versions of the plugins?

If you have the LV2 version and want the VST version of the same plugin, you have to buy it.
But if you are using Ardour 3 there’s no need, as both are equally well supported.