Print

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

[JimH]

mattkahn and mwillems,
Would you accept responsibility for vetting the ideas in this thread?

https://yabb.jriver.com/interact/index.php/topic,99096.msg686024.html#msg686024

Whatever you think should be done, we'll try to do.  Any help you can provide would be appreciated.

Thanks,

Jim

[mwillems]

I think mattkhan was editing the first post in that thread (https://yabb.jriver.com/interact/index.php/topic,99096.msg685880.html#msg685880) as the thread went along to try and capture all the asks in one place and remove them as they were done, but it's been a few years and I know that some of the items on that list have since been implemented. 

Under PEQ/Crossover Flexibility I think items 1) and 4) have both effectively been implemented.   Item 1 was effectively implemented by allowing for adjustable Q's on the low pass and high pass filters, although I think the Q values reported are non-standard, which makes the feature slightly more challenging to use (that might be a good new thing to add to the ease of use list).  Item 4 was directly implemented as part of the "too easy" efforts, I think.  Items 2, 3, and 5 have not (to my knowledge) been implemented, but all of those would, IMO, be helpful additions to the DSP functionality.

On the items under Ease of Use & Interoperability item 1) has been implemented (I just used it a few days ago actually!), although mattkhan has written some software that relies on the text output so he may have some additional thoughts on the implementation.  I think item 2) may also have been implemented, but I don't spend much time in that DSP block, so I could be wrong.  As far as I know items 3-6 in this section are still open, and would be helpful additions.

I invite correction on any of these points from mattkhan, though, as he's been tracking DSP issues and has done some heroic work documenting the DSP and PEQ functions on the JRiver wiki.  Thanks for giving us a chance to provide some input Jim!

[mattkhan]

Thanks for considering improvements in this area.

I can take a bit of time in a day or so to consolidate outstanding feature requests/suggestions in one place. Would you like that in this thread or should I start another one in the 29 forum to cover it?

[JimH]

Thanks for considering improvements in this area.

I can take a bit of time in a day or so to consolidate outstanding feature requests/suggestions in one place. Would you like that in this thread or should I start another one in the 29 forum to cover it?

Thanks.  Let's keep it here until later.

[mattkhan]

I compiled a list from various threads, tried to group them in some sensible way and provide links where possible


Missing Features

1) All Pass Filter
Added in MC 29.06

2) Raw Biquad filters
* i.e. allow user to input a0/a1/a2/b0/b1/b2
* useful to power users, lets them enter literally any biquad they like without having to ask for support from J River
* user interface will be ugly and/or tricky because coefficients vary by sample rate (i.e. you'd need to make user enter the coefficients n times (once per valid sample rate based on Output Format config)
Under consideration -- what things would you use this for?

3) Allow channel count & mix target to vary independently
* to make J River more attractive to users with active multiway speakers, particularly for multichannel setups
* e.g. 5.1 target with 12 channel output (2 way mains with 2 subs) or 2.1 target with 10 channel output (e.g. 3 way L + R with 4 subs)
* NB: MC DSP configuration already includes an "Output Padding Channels" which plays this role
This is basically a rewrite of how audio is processed so we're not very keen on it.  The mix target can be any number of channels you choose.

4) Extend range of High/Low Pass filter types
* any order for BW, LR or Bessel as low or high pass
Low pass and high pass already allow picking the slope and Q.  What else are you looking for?

5) Allow DSP to be applied to the source content independently of the output format
* https://yabb.jriver.com/interact/index.php/topic,98492.0.html
* allow output format to be specified later in the dsp pipeline so that you can apply DSP to the source content, e.g. for a custom downmix
* might have to be implemented by duplicating all current DSP blocks (except output format but including Analyser) and inserting the duplicates before the current output format
Similar to "Allow channel count & mix target to vary independently" and is a really big change.

DSP Bugs

1) Variable Q High/Low Pass filters specify Q incorrectly
* the value has to be scaled by 2 ** 0.5
* see https://yabb.jriver.com/interact/index.php/topic,127946.msg889106.html#msg889106
This has been corrected in MC29.

2) Shelf filters specify Q incorrectly
* the value provided is used as S not Q
This has been changed in MC29.

3) Known convolver bugs
* https://wiki.jriver.com/index.php/Convolution#Known_Issues
A reload was added.  The channel bug I thought was fixed a while ago.  If there are more, please start a thread.

4) Subwoofer limiter applies boost instead
* https://yabb.jriver.com/interact/index.php/topic,114574.0.html
Limiter no longer does anything until it limits.  Changed for MC29.


DSP Improvements

1) Improve bass management filters to avoid cancellations
* https://yabb.jriver.com/interact/index.php/topic,127245.0.html

2) Genuinely fast/transparent filter switching for A/B testing
* https://yabb.jriver.com/interact/index.php/topic,131945.0.html


Small(ish) User Experience Improvements

1) Rework the PEQ window
* keyboard shortcuts
* bulk select + delete + move up/down

2) Analyser tweaks
* Add labels to tick marks on y axis
* Allow user control of y axis limits
* Allow user selection of displayed channels

3) Improved granularity in Room Correction
* allow choice of units (ft/m/cm)
The distance changes to m if you select that in MC.  Look at Tools > Language.
* allow delay to be specified in ms
Delay comes from the distance away, so I'm not clear why you would want to set in another format.

4) Ability to rename channels
The channels are pretty fixed in MC, so I'm not sure how to make the changes carry through everywhere.

5) Create named blocks of PEQs
* can be approximated using the text "filters"


Bigger UX Changes

1) Visual PEQ editor and/or visualisation of current DSP

2) Ability to manage DSP configuration from another MC instance

3) Provide custom views tailored for common uses of mixing
* channel routing via a matrix mixer
* crossover design


Playback Improvements

1) Make per track DSP genuinely usable
* provide a mechanism to load/unload a configuration on a per track basis
* allow for overriding/extending a base configuration (e.g. to add just a few PEQ filters on top of existing configuration)
* allow for configuration to vary on a per zone basis
MC29 now unloads the DSP when the track finishes.  This should make it a lot better.

(more details in https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809)

[mattkhan]

there are a few things listed here which are already implemented in my app using the Load/Save DSP MCWS call - https://beqdesigner.readthedocs.io/en/latest/ui/manage_mc/ - which means for me personally I would put assorted UX things on this list as a lower priority they are still obviously valid improvements to make to MC itself though (as I wouldn't have implemented those features if MC had them already).  The app above is free so you can download it and try it out yourself to see how that is designed if you like.

I suspect "Make per track DSP genuinely usable" is the most broadly useful feature though it's also probably the most complex and/or difficult to do.

For smaller things, I feel like "Raw Biquad filters" and "Allow channel count & mix target to vary independently" would be good (and hopefully relatively simple) additions because they make MC that much more flexible.

I also suspect there are other features out there that are audio pipeline related but the below is what I could easily find through search

[mwillems]

I compiled a list from various threads, tried to group them in some sensible way and provide links where possible


Missing Features

1) All Pass Filter
* implemented in 29.0.6

2) Raw Biquad filters
* i.e. allow user to input a0/a1/a2/b0/b1/b2
* useful to power users, lets them enter literally any biquad they like without having to ask for support from J River
* user interface will be ugly and/or tricky because coefficients vary by sample rate (i.e. you'd need to make user enter the coefficients n times (once per valid sample rate based on Output Format config)

3) Allow channel count & mix target to vary independently
* to make J River more attractive to users with active multiway speakers, particularly for multichannel setups
* e.g. 5.1 target with 12 channel output (2 way mains with 2 subs) or 2.1 target with 10 channel output (e.g. 3 way L + R with 4 subs)
* NB: MC DSP configuration already includes an "Output Padding Channels" which plays this role

4) Extend range of High/Low Pass filter types
* any order for BW, LR or Bessel as low or high pass


DSP Bugs

1) Variable Q High/Low Pass filters specify Q incorrectly
* the value has to be scaled by 2 ** 0.5
* see https://yabb.jriver.com/interact/index.php/topic,127946.msg889106.html#msg889106

2) Shelf filters specify Q incorrectly
* the value provided is used as S not Q

3) Known convolver bugs
* https://wiki.jriver.com/index.php/Convolution#Known_Issues

4) Subwoofer limiter applies boost instead
* https://yabb.jriver.com/interact/index.php/topic,114574.0.html


DSP Improvements

1) Improve bass management filters to avoid cancellations
* https://yabb.jriver.com/interact/index.php/topic,127245.0.html

2) Genuinely fast/transparent filter switching for A/B testing
* https://yabb.jriver.com/interact/index.php/topic,131945.0.html


Small(ish) User Experience Improvements

1) Rework the PEQ window
* keyboard shortcuts
* bulk select + delete + move up/down

2) Analyser tweaks
* Add labels to tick marks on y axis
* Allow user control of y axis limits
* Allow user selection of displayed channels

3) Improved granularity in Room Correction
* allow choice of units (ft/m/cm)
* allow delay to be specified in ms

4) Ability to rename channels

5) Create named blocks of PEQs
* can be approximated using the text "filters"


Bigger UX Changes

1) Visual PEQ editor and/or visualisation of current DSP

2) Ability to manage DSP configuration from another MC instance

3) Provide custom views tailored for common uses of mixing
* channel routing via a matrix mixer
* crossover design


Playback Improvements

1) Make per track DSP genuinely usable
* provide a mechanism to load/unload a configuration on a per track basis
* allow for overriding/extending a base configuration (e.g. to add just a few PEQ filters on top of existing configuration)
* allow for configuration to vary on a per zone basis

(more details in https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809)

These all look good and jibe with my understanding of what's missing/might need fixing. 

Just to clarify, can you be more explicit about what Missing Feature 4) means?  I assume you mean, at minimum, offering filter slopes above 8th order?  But do you mean something else too?  I think we can currently dial in LRs and Bessels by specifying the Q (after conversion of course), or am I confused on that?  Maybe you mean offering labelled "pre-sets" for those filter types that will set the Q appropriately?  Or some combination of higher orders and labelled presets?

I think both would be helpful improvements, but the first is definitely missing functionality but the second is QOL (unless I'm mistaken, obviously).  I just wanted to make sure the "ask" is clear :-)

there are a few things listed here which are already implemented in my app using the Load/Save DSP MCWS call - https://beqdesigner.readthedocs.io/en/latest/ui/manage_mc/ - which means for me personally I would put assorted UX things on this list as a lower priority they are still obviously valid improvements to make to MC itself though (as I wouldn't have implemented those features if MC had them already).  The app above is free so you can download it and try it out yourself to see how that is designed if you like.

I suspect "Make per track DSP genuinely usable" is the most broadly useful feature though it's also probably the most complex and/or difficult to do.

For smaller things, I feel like "Raw Biquad filters" and "Allow channel count & mix target to vary independently" would be good (and hopefully relatively simple) additions because they make MC that much more flexible.

I also suspect there are other features out there that are audio pipeline related but the below is what I could easily find through search

For my part, "Allow channel count & mix target to vary independently" is a longstanding wish of mine and has no good workarounds right now. 

Also, I know that Visual PEQ Editor is a heavier lift, but every time that's come up it's a very popular idea.  That said, I agree with mattkhan that BEQDesigner is a good solution for that right now, so it might make more sense to focus on the missing features and or outright bugs first.

[JimH]

Thank you!

[mattkhan]

Just to clarify, can you be more explicit about what Missing Feature 4) means?  I assume you mean, at minimum, offering filter slopes above 8th order?  But do you mean something else too?  I think we can currently dial in LRs and Bessels by specifying the Q (after conversion of course), or am I confused on that?  Maybe you mean offering labelled "pre-sets" for those filter types that will set the Q appropriately?  Or some combination of higher orders and labelled presets?

I just mean named filters up to some reasonable order (upto 24th perhaps which is pretty much a brick wall) limit. I called it a missing feature from the perspective of a typical MC user and was ignoring workarounds.

I.e. you can do it today using the variable Q filter but realistically no one can do that accurately without using a computer (e.g. beqdesigner), partly because how to calculate the required Q is not common knowledge and partly because of the Q bug in pass filters. I think even if you fixed the Q bug it would still be practically impossible for any normal user.

[mwillems]

I just mean named filters up to some reasonable order (upto 24th perhaps which is pretty much a brick wall) limit. I called it a missing feature from the perspective of a typical MC user and was ignoring workarounds.

I.e. you can do it today using the variable Q filter but realistically no one can do that accurately without using a computer (e.g. beqdesigner), partly because how to calculate the required Q is not common knowledge and partly because of the Q bug in pass filters. I think even if you fixed the Q bug it would still be practically impossible for any normal user.

Got it!  Thanks for clarifying. 

[Matt]

Is adding an A/B switch like asked for here important:
https://yabb.jriver.com/interact/index.php/topic,131945.0.html

Thanks.

[JimH]

Is adding an A/B switch like asked for here important:
https://yabb.jriver.com/interact/index.php/topic,131945.0.html

Thanks.

No.  Let Mitchco have the business.

[mwillems]

Is adding an A/B switch like asked for here important:
https://yabb.jriver.com/interact/index.php/topic,131945.0.html

Thanks.

So there's two related issues in that thread: there's interest in a new feature (a/b buttons) and a longstanding bug/issue in the convolution DSP user interface (listed in mattkhan's link above).

In re: the bug, the current behavior of the convolution UI is kind of counterintuitive in that unlike most of JRiver's DSP (which can be changed on the fly during playback) the convolution block doesn't detect changes to the config files on the fly.  Currently when changes are made to the underlying convolution configs or filters MC silently ignores changes until you completely restart MC, which is unexpected (stopping and starting playback is not enough).  This has the practical effect of making convolution configs or filters very hard to test or tune on the fly because MC silently ignores changes to the configuration until MC is restarted. 

So I think the issue with convolution configs or filters requiring a restart of JRiver to pick up changes is important to fix.  Especially because the fact isn't obvious from the interface at all so it leads to confusion/frustration.  Like mattkhan mentioned in the A/B thread, either watching the underlying file so that when it changes JRiver respects the changes, or including a manual "reload" button would probably resolve the issue. 

As to the feature request, I think a seamless DSP A/B switch (whether convolution specific, or more general) would be very nice to have for testing or critical listening.  But I suspect (as mattkhan alluded to in the A/B thread) fixing the convolution reloading behavior might need to happen first, and would help get people closer to being able to do some limited A/Bing on their own using the tools available.

[Matt]

I added a reload button to the Convolution DSP for the next build.  I've done one of the requests in this thread!  Thanks.

[mattkhan]

I think it is a valid feature request but I think it is hard to see that as important to jriver unless you were going to seriously go after that sort of market.

I think there are steps in this direction you could take, probably quite cheaply, and which would be more generally useful. Two spring to mind

1) LoadDsp mcws call does result in an audible gap as the new config takes over, eliminate this
2) allow for a some keyboard shortcut to switch between DSPs quickly (e.g ctrl+some other keys+Fnn)

I know that 2 could be done through zones, but i think that does not play nicely with zoneswitch (NB: generally speaking I would overhaul zones, zoneswitch and DSP configs but I realise that is a big, disruptive, lift) so some hotkey based system for a single zone would still be useful.

[mattkhan]

btw the above shows there are a class of DSP related problems that are more about playback then DSP per se, I (mostly) stuck to DSP itself in my earlier post otherwise thread scope is out of control

[Mitchco]

No.  Let Mitchco have the business.

I really appreciate that Jim, thank you.

Re: spalmgre's comment: He has after all been using JRiver for years and developed this competing software from a need of features that he can not get by using existing JRiver software.

It is true that I am a long time JRiver user for years, listening to tunes right now on MC :-) But no, I did not develop HLC as a competing product, lol! It is just another complimentary plug-in for JRiver with a specialised purpose as described here: https://yabb.jriver.com/interact/index.php/topic,129475.0.html

Kind regards,
Mitch

[mattkhan]

another mentioned thread is https://yabb.jriver.com/interact/index.php?topic=98492.0 . It's a slightly hard to follow thread but I think the concrete feature request is to be able to move output format (as opposed to pinning it at the top) which would allow some DSP stages to be applied to the input signal as opposed to the output. I can see one concrete use for this would be a custom downmix (which is currently impossible unless you have a device with as many channels as the input).

I would think this would potentially mean duplicating the existing dsp studio so you could have all the blocks available to work on the input then feed that into the output (and be able to repeat them again). No doubt a snazzier UI could be implemented for this but the above sounds correct from the point of view of a processing pipeline.

added as item 5) under Missing Features in the earlier post

[Hendrik]

I think the concrete feature request is to be able to move output format (as opposed to pinning it at the top) which would allow some DSP stages to be applied to the input signal as opposed to the output.

Output Format is not a DSP in the sense of the others, its configuration is just included in the list for convenience. Its hard-wired into the audio engine and moving it would be a major change with lots of caveats (eg. rather unrealistic), for seemingly minor advantages.

If you want eg. a custom downmix, it would be easier to let DSPs change the channel configuration afterwards.

[mattkhan]

I don't think I understand the distinction drawn, perhaps because I have no clue how MC is implemented internally.

If a new DSP block is added that allows for changing the channel configuration downstream of output format then it means changing the parameters of the audio device (eg channel count) which is currently driven by output format. If you can decouple this then what else is output format doing that is baked into the audio engine?

[Hendrik]

Its just an architectural point, you cannot run anything before it, since its basically the entry point of the audio engine, after which all processing gets delegated to where it needs to go.

[Matt]

Hendrik is right.  What's the end goal?  Couldn't you pick the proper number of channels and mix with Parametric?

[mattkhan]

conceptually it doesn't seem that hard, implement a fake audio device which the audio engine can write to while also giving it an audio stream like interface (however your actual content looks to the audio engine), but I leave that to you

Hendrik is right.  What's the end goal?  Couldn't you pick the proper number of channels and mix with Parametric?

the use cases in that thread are concerned with being able to operate on the source content before up/down mixing (particularly down), for example to implement a custom downmix. This is impossible at present unless your audio device is capable of operating on the no of channels in the source content. I think the minimum required to support such a use case is

* add another PEQ block
* move mixing related configuration from output format to a separate dsp block
* change output format so it just controls the actual output format (no of channels, sample rate, output encoding)

I would think the new mixing block would have to be mandatory and the options available might be best constrained by whatever is selected in output format.

[Matt]

What if you could push all the channels through MC but then tell the ASIO plugin to use less?  Not sure how hard that might be.

[Matt]

For the next build I'm going to try labeling the low and high shelf filters with "S" instead of "Q".

Please test and let us know if you think that's right.

Thanks.

[mattkhan]

For the next build I'm going to try labeling the low and high pass filters with "S" instead of "Q".

Please test and let us know if you think that's right.

It's not right. S applies to shelf filters only. Technically this  would be correct for shelf filters but practically it doesn't help because almost no other filter design tool outputs S

I really think you need to change your implementation for both shelf filters and variable Q pass filters, the latter is just wrong after all (albeit it is at least wrong in a predictable way so easy enough to work around)

[Matt]

Sorry, I said pass but should have said shelf.  Updated my post.

[mattkhan]

I would change your definition of alpha, if you look at the cookbook then you can see alpha is defined at sin omega / 2Q rather than the more complex definition for S

Obviously it is a breaking change though so you may want to add a new Q parameter to go with the existing new one (or recalculate for people automatically?)

[Matt]

I'm trying to reproduce your subwoofer limiter adding a boost, but I'm not able to.

I'm playing volume calibration pink noise through the subwoofer channel and looking in the "Analyzer" DSP.

If I turn the limiter on and off it makes basically no changes.

It's splitting the signal into two and adding them back together.  It should be lossless and looks like it to me.

Any tips?  Thanks.

[mattkhan]

I'm playing volume calibration pink noise through the subwoofer channel and looking in the "Analyzer" DSP.

that is band limited pink noise (20Hz at low end) as far as I recall whereas I used full bandwidth noise, have you tried with full bandwidth noise? you can use the REW generator to create such noise or generate it yourself

the analyser is much too jittery for signal analysis of pink noise anyway so I doubt you could see anything there

[Matt]

I tried full bandwidth and don't see it there either.

Could you mail me a file to show it?  I'm matt at jriver.

Thanks.

[mattkhan]

I can reproduce this measuring as per https://wiki.jriver.com/index.php/Verifying_DSP_Studio using REW RTA

play signal in MC, 100% internal volume, is flat in RTA
add limiter at -5, small (~2dB) boost around 40Hz
add some gain in MC, response progressively becomes a 40Hz BW LPF

basically the limiter is not transparent in the face of full bandwidth content

I emailed you the pink pn content I'm using for this

[mattkhan]

repeated this with band limited pn (10Hz and 20Hz), same boost around 40Hz is visible so this is not a function of infrasonic content

[Matt]

In the build that's out now, we switched the high and low shelf filters to use "Q" instead of "S".  This was widely requested.

An all pass filter was recently implemented.

Today I looked at the subwoofer limiter.  It splits the signal into low and high at 40 Hz.  If it's not limiting, it adds the split together and outputs.  It should be transparent, but it produces a couple dB gain for some reason.  We could try attenuating by a couple dB, but I'm not clear if that would be a win.

I'll look at the Q factor for the high and low passes soon.  It sounds like the value needs to be scaled.  We might just make the change and tell people to update.  We'll see.

Thanks for the help so far.

[Matt]

We also added a reload button to Convolver.

[Hendrik]

Today I looked at the subwoofer limiter.  It splits the signal into low and high at 40 Hz.  If it's not limiting, it adds the split together and outputs.

These aren't brickwall filters that snip the spectrum like a scissor, there is a roll-off on both sides. If you do it like that without any further considerations, you'll get a bump in the center - which is exactly what is being reported here. The entire concept basically cannot work like this.

Perhaps an EQ-style filter based on FFTs could work instead. Or just use the low-pass to measure the sub, and use a lowshelf to adjust it as needed, leaving the signal entirely untouched otherwise.

[mattkhan]

The described behaviour of the limiter is that it uses an LR4 on each side so will introduce large phase shift normally but should sum to flat. Clearly it doesn't so something is wrong there.

However I think the implementation of fundamentally flawed because it actually eliminates the bass instead of limiting it. I can't imagine why anyone would want this behaviour.

I think the actually useful feature here is a compressor with configurable attack/release/ratio/threshold, ideally a multiband one so you can adjust different frequency bands independently. I would discard the current implementation in favour of that.

[Matt]

I'm working on a couple requested changes today.

First, I'm scaling the Q factor for high and low pass filters by sqrt(2.0).  It was reported that this was needed.

Second, I'm making the subwoofer limiter lossless until it's limiting.  I don't have a great test bed for the limiter, so hopefully somebody here will be willing to test once the build ships.

Thanks for the help.

[mattkhan]

I don't have a great test bed for the limiter, so hopefully somebody here will be willing to test once the build ships.

happy to test it for you as required, it's a good incentive to make a linux build btw as testing this stuff is simpler for me on linux

I usually refer people to https://wiki.jriver.com/index.php/Verifying_DSP_Studio which explains how to measure MC output quite easily without needing any external hardware. If you want to try that yourself & need any help then happy to provide guidance.

[mwillems]

happy to test it for you as required, it's a good incentive to make a linux build btw as testing this stuff is simpler for me on linux

Ditto!  I'm happy to kick the tires when a new build lands, but its much easier for me to test on Linux (I've only got one windows box left in the house!)

[mattkhan]

thanks for the linux build, not sure if it's a problem with that build but the all pass filter is completely broken. The analyser goes bonkers and the output appears to be full scale throughout.

[Matt]

thanks for the linux build, not sure if it's a problem with that build but the all pass filter is completely broken. The analyser goes bonkers and the output appears to be full scale throughout.

I reproduced and we'll try to fix it in the next build.  In the old code I had the signs flipped.  I unflipped them, but that causes problems.  I'll play a little more on Monday.  Thanks.

[Matt]

The build that's out to beta now implements several changes talked about here. 

The AllPass filters should now be working.

We adjusted the Q for low and high pass filters based on the suggestions here.

The subwoofer limiter should now be lossless until it is limiting.

Testing and feedback appreciated.  Thanks

[Matt]

If you were to pick one or two things from your request list as highest priorities, what would you pick?

I've been chipping away, and am wondering what a good next step would be.

Thanks.

[mattkhan]

For me personally

Small = Allow channel count & mix target to vary independently

Big(ger) = making per track DSP work properly

[Matt]

What doesn't work with per track DSP like you want?

[mattkhan]

What doesn't work with per track DSP like you want?

Linked thread has lots of comments - https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809

There have been other threads though

The short answer is that it needs to "unload" after the track ends and you need to be able to compose a dsp configuration, eg specify just a track specific part to merge into the zone specific part. It also needs to respect zones as they may have different capabilities.

I think what you actually want is much like what has been discussed for jrvr tbh

[JimH]

Linked thread has lots of comments - https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809

There have been other threads though

The short answer is that it needs to "unload" after the track ends and you need to be able to compose a dsp configuration, eg specify just a track specific part to merge into the zone specific part. It also needs to respect zones as they may have different capabilities.

A default setting per zone?

And then a track specific setting that will over-ride the default?

[Matt]

I agree about unloading the DSP after playing a file.  I have a hopefully pretty good idea about how to implement it for tomorrow's build.

[mwillems]

Small = Allow channel count & mix target to vary independently

This would also be my next pick.

I've been a bit stuck in at work which has limited my test time.  So far I've tested the convolution reload button and it seems to be working correctly so far,  but I'm hoping to do more serious testing on the weekend.