Allow pipeline filter steps to process several channels

[JWahle]

Currently, importing calibration results from external programs into CamillaDSP is a rather manual process for anything else except convolution filter files. This is kind of an extension to the idea of #289.
Programs like Cavern Quick EQ or Audiolense generate room correction settings for a set of channels, but currently the best they can do is generate invalid CDSP config snippets or just give you a set of files to embed in a config.
For me, a lot of trial and error is involved in finding good room correction or headphone equalization settings. So, being able to try out new stuff quickly is essential.
Also, I noticed, that there are certain aspects of a config, which I frequently reuse and would like to have in a separate file.
These are:

• Loudness correction
• Headphone equalization
• Room correction
• Bass/Treble

My idea is, to be able to define complete, self contained pipeline snippets in a separate file. These would contain, filters, mixers and pipeline steps. In the main config pipeline section, one would add a pipeline step referencing the snippet file with the specific channel range to apply to.

So with an 8 channel audio interface in my 5.1 home cinema system, I could set up a pipeline with device configuration and pipeline setup like this:

1. 6 channel input
2. Mixer to 8 channels with HP downmix to channels 1&2 and all channel passthrough to channels 3-8
3. Headphone equalization for channels 1&2
4. Room correction for Channels 3-8
5. 8 Channel Bass/Treble
6. 8 Channel Loudness correction

In the GUI there could be a different file section for pipeline snippets, besides configs and coeffs.

What do you think?

[JWahle]

I just thought of this again. A much easier solution for this problem might be, to allow setting multiple channels for pipeline filter steps.
In the GUI, we could show a series of number buttons (one for each channel) + All/None buttons.
Then I could just add Loudness, Bass and Treble filters, add them to one pipeline step, hit "All" and done.
This brings similar comfort than what I proposed earlier, but has much less complexity.

Room correction programs might just ask for a basic config and enhance it - so referencing external files isn't strictly required for their use case.

[HEnquist]

That's an interesting idea! This could get rid of a lot of duplication from configs.
It could even be done in a backward compatible way by adding a new pipeline step type, for filters applied to several channels. A lot of the plumbing can likely be borrowed from the compressor, both here and in the gui.
V2.0 is already long overdue, so I'll mark this for 2.1.

[JWahle]

I thought about either enhancing the channel attribute of the filter pipeline step or adding a mutually exclusive channels attribute, that accepts a comma separated list of channel numbers.
Both would be backwards compatible.
And the first option would even mean, we don't carry any old baggage with us, plus it's easier to implement.
Though, it's a little surprising, if you're editing configs by hand.

[HEnquist]

Another option is to just rename the channel property of the filter step to channels and change it to a list. Giving null could maybe mean all channels. That would be a breaking change, so it would mean skipping v2.1 to go straight to v3.0. This would give zero baggage. Old config obviously have to be upgraded but the changes are easy and could be automated.

[JWahle]

If you want to support all channels as a special value, I would prefer giving it a distinct value like all.
I think from the UI perspective, it makes sense, to be able to have no channel selected as a default.

In the GUI, we could show a series of number buttons (one for each channel) + All/None buttons.

Otherwise, in most cases one would have to first deselect the default and then select the desired channel.
I think this kind of UI would even be beneficial right now. I'll implement it, so you can get an idea - minus the none/all buttons, of course.

[HEnquist]

Using a special string value like "all" for all channels gets quite clunky to handle. Using null for default, meaning all channels, is much easier.

channels: null --> default, all channels
channels: [] --> no channels
channels: [0, 2, 4] --> channels 0, 2 and 4

The ui could be done in a way similar to how you select channels to monitor and process for a processor:

Of course without the monitor_channels row. And the row of checkboxes could start with an "all" checkbox that greys out the others when selected.

[JWahle]

Ok, the channel mapping format looks reasonable.
I think, we are on the same page for the UI.

[JWahle]

I just implemented the new channel selection mode in HEnquist/camillagui@84ccced
It's only active, when there are at most 10 channels available, otherwise the old text input box is shown.
If you move the filter to a place, where the selected channel number becomes invalid, it is still shown, but in red.

I'll extend the GUI to handle multiple channels once you implemented multiple channel selection in CDSP.

[HEnquist]

Why not use the much more compact checkboxes like in the compressor? Now there are two quite different solutions to the same problem.

[JWahle]

Now there are two quite different solutions to the same problem.

If we decide on one solution and it works nicely in both places, I will implement it in both places.

Why not use the much more compact checkboxes like in the compressor?

I implemented it like this, because it has no drawbacks compared to the status quo.
Advantages are (assuming, there are no more than 10 channels):

• filter steps take the same amount of space as before
  • the checkboxes are higher and would probably have to go into the body of the filter step, further increasing the height
• if I made the buttons as small as the checkboxes, this would be more space efficient (usability would suffer naturally, though)
• you get a visual indicator where you are in the pipeline, if you organize the filter steps properly
• channel selection is faster than before and equal to checkboxes
• it is better usable on mobile devices (though still on the small and fiddly side)
• IMHO it looks nicer than the checkboxes

I could also switch to a small version of the buttons, if space is getting tight. The checkboxes are 14px * 14px. Going this small would allow 2 rows of buttons to fit in the title bar.

[JWahle]

@HEnquist can you implement this for the next release?
I would make the necessary UI changes for this.

[HEnquist]

That is the idea. It will be a breaking change, so I moved it to v3.0. Shouldn't matter since this was anyway the next thing I planned to change after I'm done with fixing small things in the v2.0.x series, and I don't have any other plans for new features that would fit in a v2.1.

[HEnquist]

implemented in #324