Converting between MHA signal types and self-developed object types

mandolini_
Posts: 9
Joined: Fri Feb 14, 2020 1:50 am

Converting between MHA signal types and self-developed object types

I understand this is going off the beaten path, but I am attempting to create a plugin that can convert the incoming signal to an object format that many of my own, self-developed C++ algorithms commonly use. Specifically, I am trying to create a plugin from the plugin template that has the following as member functions of my plugin class, convert_t

Code: Select all

mha_spec_t* convert_t::process(ComplexFloatArray2D* pInputStreamCplx)
ComplexFloatArray2D* convert_t::process(mha_spec_t* s)
Can I do this without rewriting mha_plugin.hh? If not, what would be my starting point? It seems that the main issues surrounding this revolve around the C wrapper macros, MHAPLUGIN_CALLBACKS and MHAPLUGIN_PROC_CALLBACK.

tobiasherzke
Posts: 21
Joined: Mon Jun 24, 2019 12:51 pm

Adapting between different conventions of signal representation is something you need to do when you want to integrate existing C or C++ signal processing code into openMHA. It will always look something like this:

Code: Select all

// This is a sketch to point out the general idea.
// The sketch will not work as is.
// You need to adapt it, and fill in missing parts.
class my_plugin : public MHAPlugin::plugin_t<runtime_config_type> {
public:
// signal representation used by existing code
other_signal_type * other_signal;
void prepare(mhaconfig_t dimensions) {
// use info from dimensions to allocate other_signal:
other_signal = new other_signal_type(...);
}
void release() {delete other_signal; other_signal=nullptr;}
mha_spec_t * process(mha_spec_t * openmha_signal) {
// copy signal from openmha_signal to other signal
...
// call existing code to operate on current signal block
...
// copy output signal modified by existing code back to openmha_signal.
...
return openmha_signal;
}
// Everything else (unrelated to signal representation adaptation):
...
};
If your code can change the number of channels, then you also need to allocate a signal container for the openMHA output signal.

Signal container adaptation is routine work, no need to change openMHA headers to achieve it.