Passing raw data through the filter chain (e.g. FIRProcessin

[boulay]

I'd like to pass two channels through the FIRProcessing chain untouched.
(I'm not providing feedback on these channels, but my task progression relies on the raw trigger channel and the application then stores the trigger-locked ERP to a database for a separate process).

It seems like the only modules in the chain that can't be avoided for a specific set of channels are FIRFilter and LPFilter. I'm thinking of making the parameters mFIRIntegration (for FIRFilter) and mDecayFactor (for LPFilter) be per-channel. Does that seem reasonable to you? Am I missing something simple?
I'm new to C++ so I'd like some feedback that what I'm doing makes sense before I spend a lot of time figuring out how to do this.

[mellinger]

Hi,

this or a similar feature have been requested a number of times, so I will make it a general feature of the framework, such that it will be possible for each individual filter in the chain to operate only on a subset of channels.

Expect it to be ready in about a week.

Regards,
Juergen

[boulay]

Thanks Juergen, that's great! I look forward to it.

[boulay]

I guess I was too naive in my previous question. What will happen when you have different N elements for the various M channels? e.g., if I use ARFilter then N will change. Furthermore, if I use LinearClassifier then N will be reduced to 1. What will the data structure (passed to the application) look like if any of my channels skip the LinearClassifier (and possibly other) steps?

There are probably more solutions, but some that I can think of now include:
A - I can only use this technique if I only use filters that do not change N.
B - Channel_i with N_i < max(N) will duplicate its elements until N_i = max(N).
C - The data structure will work with unequal Ns but it's up to the application to index the data properly.

Based on my limited understanding of GenericSignal::AssignValues and GenericSignal::SetProperties, it seems like (C) is not currently possible.

Please let me know how this will work so I can plan accordingly.
Thank you.

[mellinger]

Hi,

sorry for the delay. The solution will be compatible with option C. Due to hiding the internal data representation of GenericSignal from client code, it is no problem to adapt the mentioned functions as required. However, in modern systems memory is not an issue, so I might as well choose to stick to rectangular data, and pad unused entries with NaNs.

Regards,
Juergen