Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ths61]

Is there any reason why Multi-pass (serial) convolution can not be added to MC27 ?

Desired Use Case (2 input channels and up to 8 output channels), there may be others:

convolve "room correction/aggregated channel correction/house curves" on left input channel (aggregate filter)
convolve corrected left input channel into left sub, bass, midrange and tweeter channels (driver specific filters)

convolve "room correction/aggregated channel correction/house curves" on right input channel (aggregate filter)
convolve corrected right input channel into right sub, bass, midrange and tweeter channels (driver specific filters)

This would allow changing of house curves by just changing the first 2 left and right aggregate convolution filters without touching the individual XO/driver filters. 

It should also simplify individual driver filter creations because the individual driver XO filters would not have to be concerned with room correction.  Example:  An OB/Dipole sub filter could contain the requisite XO and Dipole rolloff compensation filter.

Thanks for the consideration.

[JimH]

I split this from the Feature Requests thread because it deserves discussion. 

[mattkhan]

If you were to make this change, i would think the UI page in dsp studio for convolution would need an overhaul (as well as fixing the filter reloading bug) and you would need to decide whether it would be implemented as a 2nd convolver or for more complex routing in a single convolver.

One downside of this is that it implies 2x the filter length (assuming equal length filters) which can be avoided if you combine the filters offline (unless filter one is creating input channels for filter 2 that is)

[ths61]

If you were to make this change, i would think the UI page in dsp studio for convolution would need an overhaul ...

Make the ANALYZER window it's own stand alone window so it is independent of the DSP STUDIO configuration windows.  The user should have the option of having both windows open simultaneously versus currently being mutually exclusive.

The multiple traces in the ANALYZER window is very helpful in validating the XOs are functioning as expected before powering up the DAC and amps.

... (unless filter one is creating input channels for filter 2 that is)

That is the exact USE CASE stated in the original request.  First filter is an aggregate filter applied to the entire frequency range of the given input channel (e.g. house curve).  The subsequent filters would be sub-bands of the filtered aggregate input channel (e.g. sub channel, bass channel, midrange channel, tweeter channel).


Left House Curve N Filter (aggregate frequency range)
- Left Sub XO Filter
- Left Bass XO Filter
- Left Midrange XO Filter
- Left Tweeter XO Filter

Right House Curve N Filter (aggregate frequency range)
- Right Sub XO Filter
- Right Bass XO Filter
- Right Midrange XO Filter
- Right Tweeter XO Filter

House Curve N could be swapped out without impacting the individual driver filters, otherwise one would need N * (# of driver filters) to do the equivalent off line.

Latency would be multiplied by the number of serial/multi-passes unless there are some software/mathematical tricks that can be done with multiple cores and CUDA cores to minimize the total latency.

QUESTION:  Could JRiver aggregate the serial filters at runtime (track startup) to minimize the latency ?  If so it would have to take driver delays into consideration.

[glynor]

I'm just here to say that every time I see this thread in the Interact thread listing, it makes me, for a second, think of


I have nothing useful to contribute. I'll see myself out. 

[mattkhan]

Make the ANALYZER window it's own stand alone window so it is independent of the DSP STUDIO configuration windows.  The user should have the option of having both windows open simultaneously versus currently being mutually exclusive.

The multiple traces in the ANALYZER window is very helpful in validating the XOs are functioning as expected before powering up the DAC and amps.

the analyzer window could also be improved significantly but I'm talking about the convolution window and this bug in particular - https://wiki.jriver.com/index.php/Convolution#Config_File_Reloading

not being able to see the routing inside a cfg file can already be slightly hard to manage, especially when you have no idea what is actually loaded into memory, so moving to a more complex setup with inputs and outputs would be quite painful I think. Something like the way routing is done in plogue bidule or qjackctl (https://qjackctl.sourceforge.io/qjackctl-screenshots.html) would be great but probably unlikely to happen.

First filter is an aggregate filter applied to the entire frequency range of the given input channel (e.g. house curve).

the simple solution in this case is to apply this layer via PEQ given that such EQ curves are typically fairly simple, if you have a particularly complex curve that needs a lot of filters to approximate then the UI makes it a fairly tedious operation but it's certainly an option.

Latency would be multiplied by the number of serial/multi-passes unless there are some software/mathematical tricks that can be done with multiple cores and CUDA cores to minimize the total latency.

it can be done offline by convolving the filters and then reducing the length back down to the original length.

[ths61]

the simple solution in this case is to apply this layer via PEQ given that such EQ curves are typically fairly simple, if you have a particularly complex curve that needs a lot of filters to approximate then the UI makes it a fairly tedious operation but it's certainly an option.

2 things are lost with this approach:

1) PEQs are limited and give up the functionality offered by other convolution tools.
2) The manual loading of numerous PEQs into MC is cumbersome and a PITA.  Numerous requests have been made to automate this feature, but sadly fallen on deaf ears.  It defeats the motive of this feature request to allow easy replacements of "house curves" using more feature rich filters.

it can be done offline by convolving the filters and then reducing the length back down to the original length.

Repeat #2, it defeats the motive of this feature request.  Breaking up a house curve to create N permutations of the same 8 driver filters is the cumbersome procedure that we have now and makes it more difficult/restrictive for novices/newbies to utilize convolution and house curves to their fullest, not to mention more pilot and tool error prone.  Automation and convenience is the feature request being made here.

[mattkhan]

I understand all of that, just giving you the currently available workarounds as I would think that history suggests this is v unlikely to be implemented.

[ths61]

I understand all of that, just giving you the currently available workarounds ...

You keep repeating the obvious which was the genesis for the request.  No reason to repetitiously parrot the known cumbersome workarounds (which people are already forced to use due to lack of multi-pass).

Most of the features requested for V27 are convenience, automation and improved usability requests.  This is no different other than it adds unimplemented convolution functionalities.  Using your argument, VST3 shouldn't be supported because MC already has VST2, or a popup menu or mouse button shortcut shouldn't be added because it can be done in another window, but yet there they are.

The WIKI already indicates convolution multi-pass is NOT currently supported.

https://wiki.jriver.com/index.php/Convolution

The unsupported feature are:

    Input line delays
    Multiple output channels in a path
    Output channel weights
    Multi pass convolution

[Awesome Donkey]

Using your argument, VST3 shouldn't be supported because MC already has VST2, or a popup menu or mouse button shortcut shouldn't be added because it can be done in another window, but yet there they are.

I don't think this is a good example I'm afraid.

VST3 support was added because you can't get a license from Steinberg to create VST2 plugins unless you already have a license, and as of now potential plugin developers can only get VST3 licenses from Steinberg. So JRiver adding VST3 support was kinda forced upon them because of that fact. If it wasn't because of that, there's a good chance JRiver wouldn't have added VST3 support to Media Center yet.

[ths61]

I don't think this is a good example I'm afraid.

VST3 support was added because you can't get a license from Steinberg to create VST2 plugins unless you already have a license, and as of now potential plugin developers can only get VST3 licenses from Steinberg. So JRiver adding VST3 support was kinda forced upon them because of that fact. If it wasn't because of that, there's a good chance JRiver wouldn't have added VST3 support to Media Center yet.

Interesting business/licensing factoid, but why the hesitation in supporting audio-only customers requests ? 

The phrase "how can bit perfect be improved upon" is often bandied about here to squelch audio feature enhancement requests.  Well, a more complete convolution spec implementation is one way. 

I don't use VST, but I would assume VST3 adds additional functionality over VST2 other than just a 3rd party business licensing policy.

I have used MC exclusively for just audio for over a decade and would like to see some useful audio features added to justify multi-platform version upgrade costs.  I have no problem supporting MC, but would like to see some value add over time.

More multi-channel DAC vendors are entering the market and PCs are getting stronger to support them.  A more complete convolution spec implementation is not out of the question and may just demonstrate continuing support for audio customers that use convolution.

My request has been made, no more comments shall be.