rodio icon indicating copy to clipboard operation
rodio copied to clipboard

Feature channelrouter (sparse matrix, other version of #656)

Open PetrGlad opened this issue 1 year ago • 4 comments

The branch is based on #656.

Not necessarily for merge but I could not help implementing it, wanted to see how this would look actually. I admit that 'next` looks more verbose, but to me it seems it should be the fastest (especially when most of the coefficients are zero). This can be made even tighter by supporting only smaller number of channels (max of 256 could save 2 bytes on each matrix entry). When channel count changes, this should still keep working, but I'd expect users may want to handle that (or maybe even have several presets for each expected channel count). Also maybe duplicate entries should be rejected - this works just fine but maybe surprising.

There is another idea to consider: the whole matrix is set every time, letting users to modify it any way they see fit. This avoid the problem of keeping track which coefficients are non null or not.

PetrGlad avatar Jan 07 '25 17:01 PetrGlad

@iluvcapra @dvdsk Can you have a look at this PR? What would you not like in this version?

I think the code is ready. Both versions (this and #656) are functional but one may be better than another depending on context. So I would even consider to have both of them. I stated my preference, though :)

PetrGlad avatar Feb 02 '25 11:02 PetrGlad

I'll have a look :+1: Would you mind postponing the merge of this till #694 lands? Since that is already going to be a monster PR, keeping this off for a while makes #694 easier to write.

yara-blue avatar Feb 02 '25 11:02 yara-blue

@dvdsk This PR is based on #656 to show alternative implementation. So tests are kept from that PR. Generally I tried to keep the API (except for the mixer itself) and tests from that PR intact.

This is not urgent, I just wanted to get some feedback, primarily whether there are any objections against this version compared to one in #656.

PetrGlad avatar Feb 02 '25 12:02 PetrGlad

I have no objections to this version. I think we can keep improving on it but we need benchmarks for that. API-wise there is still a lot to be done. But that would require first hammering out #658.

yara-blue avatar Feb 03 '25 10:02 yara-blue