Converting between MHA signal types and self-developed object types

Post Reply
Posts: 15
Joined: Fri Feb 14, 2020 1:50 am

Converting between MHA signal types and self-developed object types

Post by mandolini_ » Sat Feb 29, 2020 1:15 am

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.

Posts: 27
Joined: Mon Jun 24, 2019 12:51 pm

Signal representation adaptation

Post by tobiasherzke » Sat Feb 29, 2020 3:48 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> {
  // 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.

Post Reply