Developing Custom Signal Processing Plugins for DewesoftX Using C++

Course overview

The Developing Custom Signal Processing Plugins course equips software engineers to build advanced, C++-based processing modules that integrate seamlessly into DewesoftX. Unlike legacy plugins, this modern framework offers powerful C++ capabilities with easier development and debugging workflows

You’ll begin by setting up your development environment—installing Visual Studio and the DewesoftX development version, and adding the official C++ Processing Plugin template via the VSIX installer. With these foundations, you’ll generate a new plugin project, configure project metadata, and remove sample boilerplate code.

The course then walks through reimplementing core logic such as “latch math” using modern C++. You’ll learn to read data from input channels, execute custom processing pipelines, produce output channels, and tie into DewesoftX configuration settings and GUI components. The framework supports full custom GUI integration, enabling developers to create user-facing control elements that interact directly with plugin behavior.

Further modules will get you comfortable with debugging techniques, unit-test patterns using Google Test, and managing plugin settings across sessions. You’ll also learn how to package your code into deployable bundles that automatically register with DewesoftX, facilitating easy sharing and deployment across teams.

By the end of the course, you’ll be well-versed in the full lifecycle of plugin development—from creating templates, writing robust processing logic, designing interactive interfaces, and deploying usable plugins for end users. This training builds directly on the previous C++ Script Pro course and deepens your ability to extend DewesoftX with high-performance C++ modules.

Extending Dewesoft in the past was a daunting task. Writing a proper plugin for Dewesoft required extensive knowledge of how the software operated under the hood.

C++ Script demonstrated that it really doesn't need to be that way, that writing plugins could (and should) be an easy process. The problem with the "legacy" plugin system was that it was written too generically. It gave the programmer great power over Dewesoft, but it was really difficult to write even a trivial plugin from scratch. 

Processing plugin tries to fix this. It uses Dewesoft's DCOM interface to access its internals, but abstracts the interaction away from the programmer (almost) completely. The end result is that while you can directly control Dewesoft as you would with more bare-bones plugin system, you can write the plugin almost as if you were writing C++ Script - except with much more powerful debugging tools C++ Script could ever offer. You can take arbitrarily many input channels, process the data using modern C++, output the results into output channels, change Dewesoft settings, and much much more!

C++ Processing Plugin also allows you to create your very own user interface which is, together with your C++ code, compiled into an external library and automatically recognised and loaded by Dewesoft. This is why your plugin can be easily exported and imported for use on other computers.

In order to start using C++ Processing Plugin, you must have Visual Studio IDE installed on your system. Some of the reasons we have chosen Visual Studio are its combination of powerful developer tooling and debugging.

You can download the DewesoftX Processing Plugin Template from the Dewesoft webpage under Support > Downloads > Developers > C++ Plugin. Note that you have to be logged in to access the C++ Plugin section. After downloading, just double-click the file and VSIX installer will guide you through the installation process. Once Visual Studio Development tool is installed you will be able to download the Dewesoft plugin template using the New project window and selecting the DewesoftX Processing plugin template. 

In this pro training we will again be recreating latch math, as we did in C++ Script training, so the C++ Script pro training and its understanding is the prerequisite for this tutorial and we will only build on the knowledge. This is so that the parallels between C++ Script and Processing plugin are as apparent as possible. So, to follow along, we recommend that you first read that tutorial available at Dewesoft > Training > PRO Training > Develop > C++ Script, and prepare the same setup as created in its Example: Latch math chapter.

To create a new C++ Processing Plugin we click the Project button in File tab -> New -> Project. We select the DewesoftX C++ Processing Plugin Template as our template. After clicking the Ok button a wizard window will appear to guide us through the creation of the plugin.

Since your plugin will be integrated inside Dewesoft, it needs to know Dewesoft's location. We can define the location by ourselves and the installer will create DEWESOFT_EXE_X86 (for 32-bit Dewesoft) and DEWESOFT_EXE_X64 (for 64-bit Dewesoft) system variables for us. In that case, Visual Studio will have to be restarted so it will update its used environmental variables state. 

Once those system variables are set, installer will automatically find those fields for you and you will not have to specify the location for further usages.

If we want to set those variables ourselves, we can do this using System properties window (it can be found pressing Windows key and searching for Edit the system environment variables), and under advanced tab clicking the Environment variables. 

After clicking the Next button the following window appears which is used to set Plugin information such as plugin name, its ownership, and version.

• Plugin name - The name that will be seen in Dewesoft.

• Description - Short description of your plugin.

• Vendor - Company that created the plugin.

• Copyright - Owner of the plugin.

• Major version - Sets the initial major version. The value should change when a breaking change occurs (it's incompatible with previous versions).

• Minor version - Sets the initial minor version. The value should change when new features and bug fixes are added without breaking compatibility.

• Release version - Sets the initial release version. The value should change if the new changes contain only bugfixes.

All fields are optional except for the Plugin name, and they can all be modified later from the code.

After clicking the Next button a final window appears. This window is used to set your Base class name. It is used as a prefix for class and project name. When the Base class name is set, we can click the Finish button and the wizard will generate the plugin template based on your choices. 

Once the plugin is created and you stumble upon Error MSB8036: The Windows SDK version sdk_version was not found. You should retarget your solution to use the one you have installed. You can do this by right clicking on your solution node in Solution explorer and selecting Retarget solution.

Once the Retarget solution window is opened, you can select "Latest installed version" item.

Structure of the solution

When a new C++ Processing Plugin project is created, the wizard will create the basic files and project structure needed for development. In the picture below you can see the structure of a project in a tree view with collapsed items. In our case, LatchMath refers to text which was used as the Base class name.

• LatchMathPlugin - The actual plugin implementation

• LatchMathPluginTest - Solution for writing unit tests for LatchMathPlugin. 

• gtest - Google test library, required by LatchMathPluginTest for unit testing your plugin. This project should not be modified. 

As mentioned before, our plugin implementation is inside the LatchMathPlugin project. It contains files for writing the UI of the plugin, for writing the main code, and dewesoft_internal folder with methods your plugin is going to use behind the scenes for interacting with Dewesoft. In addition you can also see the icon.png file containing the icon used by the plugin. plugin.h and plugin.cpp serve as the entry points for your plugin, and contain the base class with the same name as defined with Base class name. Here we connect the input channels, mount the output channels and write the logic of the plugin, much like we would in C++ Script. We can also set additional properties of the plugin and save the setup variables.

The UI folder is split into two additional folders for editing the setup UI and for the settings UI. The setup UI is the one you see when you enter the plugin setup form, and the settings UI can be found by clicking Options -> Settings -> Extensions and locating your plugin. Both setup and settings folders have .xml file for writing the UI, a .h header file for defining the methods and variables and a .cpp file for writing the logic for the UI.

When our project is successfully generated, we will be able to extend Dewesoft. But before implementing the logic behind our plugin, let's take a look at how our plugin is integrated into Dewesoft by default. In order to do that, we have to start our program using the shortcut F5 or pressing the Start button in the center of Visual Studio's main toolbar. 

After Dewesoft loads, our plugin can be accessed in Dewesofts main toolbar in Measure mode under Ch. setup -> More... -> Latch math - scalar. As we can see, it already contains some example elements which were automatically added to the user interface. 

It is important to keep in mind that C++ uses header files (you can recognize them by the .h extension) in addition to source files. Header files are designed to provide information about your class and are used for declaration of variables and methods, while their initialization is done in the source files with .cpp extension. 

When we first create a new plugin the project LatchMathPlugin also contains an example of a plugin for adding an offset to the input signal. Before writing our own code, we will first remove the sample code as it is not needed for the plugin we will write in this tutorial. 

Our ui/setup/setup_window.h should look like this:

1#pragma once
2#include "generated/ui/setup/plugin_setup_window.h"
3#include "plugin.h"
4
5class LatchMathSetupWindow : public LatchMathSetupWindowBase
6{  
7  public:    
8    virtual void bindEvents() override;    
9    virtual void initiate() override;
10};

and ui/setup/setup_window.cpp should look like this: 

1#include "StdAfx.h"
2#include "ui/setup/setup_window.h"
3
4using namespace Dewesoft::MUI;
5
6void LatchMathSetupWindow::bindEvents()
7{
8}
9
10void LatchMathSetupWindow::initiate()
11{
12}

Let's also remove everything but the very basics from the ui/setup/setup_window.xml:

1<?xml version="1.0" encoding="utf-8"?>
2<Window xmlns="https://mui.dewesoft.com/schema/1.1">
3</Window>

We will also remove any sample code from the plugin.h and plugin.cpp file. We only keep the methods that will be used later.

The plugin.h file should look like this

1#pragma once
2#include "interface/plugin_base.h"
3
4enum class OffsetType
5{
6    Fixed = 0, 
7    Dynamic = 1,
8};
9
10class LatchMathModule : public Dewesoft::Processing::Api::Advanced::Module
11{
12  public:
13    static void getPluginProperties(PluginProperties& props);
14
15    void configure() override;
16    void calculate() override;
17   
18    void updateSetup(Setup& setup) override;
19   
20    void connectInputChannels(InputChannelSlots& slots) override;
21    void mountChannels(OutputChannels& fixed, OutputChannels& dynamic) override;
22};
23
24class LatchMathSharedModule : public Dewesoft::Processing::Api::Advanced::SharedModule
25{
26};

and the plugin.cpp file should look like this.

1#include "StdAfx.h"
2#include "plugin.h"
3
4namespace adv = Dewesoft::Processing::Api::Advanced;
5using namespace Dewesoft::Utils::Dcom::Utils;
6
7void LatchMathModule::getPluginProperties(PluginProperties& props)
8{
9    props.name = "Latch math - scalar";
10    props.description = "Pro Tutorial example.";
11    props.pluginType = PluginType::application;
12    props.hasProjectSettings = false;
13}
14
15void LatchMathModule::connectInputChannels(InputChannelSlots& slots)
16{
17}
18
19void LatchMathModule::mountChannels(OutputChannels& fixed, OutputChannels& dynamic)
20{
21}
22
23void LatchMathModule::configure()
24{
25}
26
27void LatchMathModule::calculate()
28{
29}
30
31void LatchMathModule::updateSetup(Setup& setup)
32{
33}

With these changes we are ready to start writing our latch math plugin.

Let's start by writing the logic of our plugin. This is done by editing plugin.h and plugin.cpp files of the project. Much like in C++ Script, these files contain classes with methods that Dewesoft automatically calls whenever appropriate (e.g. when measuring is started, when measuring is stopped, when setup is saved,...). 

Let's first create the two input channels required by our plugin. Unlike in C++ Script where we were able to just click on the user interface to add the channels, we have to create these "by hand" in Processing plugin. We do this by making changes to the plugin.h and plugin.cpp files. In the plugin.h file we define the two input channels as public variables of the Module class.

1class LatchMathModule : public Dewesoft::Processing::Api::Advanced::Module
2{
3  public:    
4    // ...
5    ScalarInputChannel criteriaChannelIn;
6    ScalarInputChannel inputChannelIn;
7};

Note that the types of the channels are ScalarInputChannel, exactly like in C++ Script. This is not by accident. In fact, channels in Processing plugin have very similar interfaces as the ones defined there, so if you are familiar with C++ Script, it shouldn't be such a jump to master Processing plugin channels. 

In the plugin.cpp file we now reserve two input slots (top left panel on the settings window) that will hold our channels and connect them with the variables we just defined. We do this by modifying the connectInputChannels() method:

1void LatchMathModule::connectInputChannels(InputChannelSlots& slots)
2{
3    slots.connectChannel("Input channel", &inputChannelIn, ChannelTimebase::Synchronous);
4    slots.connectChannel("Criteria channel", &criteriaChannelIn, ChannelTimebase::Synchronous);
5}

With this, we specified that our two input slots will be called "Input channel" and "Criteria channel", and their timebases will be synchronous.

The last thing we need to do to get the code to compile is to edit the getPluginProperties() method. Here we can change the general behaviour of our plugin - how many channels it accepts, where in Dewesoft it appears, if it has a settings form or not, etc. For our purposes, the only thing that really matters is the inputSlotsMode property which will allow our plugin to accept multiple inputs.

1void LatchMathModule::getPluginProperties(PluginProperties& props)
2{
3    props.name = "Latch math - scalar";
4    props.description = "Pro Tutorial example.";
5    props.pluginType = PluginType::application;
6    props.hasProjectSettings = false;
7    props.inputSlotsMode = InputSlotsMode::multiple;
8}

Compile the project and you should be able to find our plugin under "More..." menu. Adding it you can see the two input slots we prepared for our plugin:

Next, let's prepare variables that will control the behaviour of our latch math. We will do this in the plugin.h file where we define the public variables for the criteria limit and for the edge type. We will also create a custom enum for edge type so the code will be more descriptive.

1enum edgeTypes
2{    
3    RisingEdge = 0,    
4    FallingEdge = 1
5};
6
7//...
8
9class LatchMathModule : public Dewesoft::Processing::Api::Advanced::Module
10{
11  public:    
12    // ...
13    double criteriaLimit = 0;    
14    edgeTypes edgeType = RisingEdge;
15};

mountChannels

Next, let's add some output channels to our plugin. Again, in C++ Script this was done by clicking on the UI, but here we have to do it all by hand. First let's add a variable that will hold our output channel to plugin.h:

1class LatchMathModule : public Dewesoft::Processing::Api::Advanced::Module
2{  
3  public:    
4    // ...
5    ScalarOutputChannel outputChannel;
6};

To actually register the channel with Dewesoft, we use a special method called mountChannels(). Here we set basic channel properties like the name of the channel that is seen by the end-user, the channel index, which should always be unique. The type of value that the channel will output is determined from the definition of the channel in the plugin.h file, and since we defined our channel as ScalarOutputChannel it means that our channel will output scalar values.

We also need to set the timebase of the output channel. We do this by mounting the channel with the mountSyncChannel() function if we want the timebase to be synchronous, mountAsyncChannel() for asynchronous timebase or mountSingleValueChannel() if we want the timebase to be a single value. In our example, the output channel should be of an asynchronous type because we do not know exactly when a new sample will be added. 

As you can see from the code snippet below we can mount channel as fixed or dynamic channel. The difference between the two is that Fixed must always contain a constant number of channels, while Dynamic may contain a different number of channels every time the mountChannel() method is called.

1void LatchMathModule::mountChannels(OutputChannels& fixed, OutputChannels& dynamic)
2{
3    fixed.mountAsyncChannel("Latch", 0, &outputChannel);
4}

configure

The configure() method gets called every time before the measurement is started. This is the place to set the final settings dependent on and regarding channels. 

Here we set the output channels' expectedAsyncRate and can also change the output channels' name, unit and description.

Another important thing to be set here is the properties of the resampler. 

1void LatchMathModule::configure()
2{
3    resampler.blockSizeInSamples = 1;
4    resampler.samplingRate = ResamplerSamplingRate::Synchronous;
5    resampler.futureSamplesRequiredForCalculation = 1;
6
7    outputChannel.setExpectedAsyncRate(5);
8}

To make sense of the code above we will take a detour and take a closer look at the resampler and its properties:

resampler

The C++ Processing Plugin works so that all the input channels of the plugin get resampled to the same sample rate, which means that all the input channels have samples at the same timestamps. In C++ Script this is done automatically, with every input channel getting resampled to the timebase of the first assigned input channel. In Processing plugin we get a lot more control over the behaviour of the resampler.

The sampling rate can be: 

• Synchronous  - all the samples will be spaced equidistantly based on the acquisition sample rate;

• SingleValue - the input channels only have one sample as an input, and the calculate() function will get called once every couple hundred milliseconds; and

• AsynchronousSingleMaster - the samples get resampled to the asynchronous rate of the master channel. To set the master channel we need to call setMasterChannel() function like so: resampler.setMasterChannel(&inputChannelIn);

We also need to set the number of samples we receive in every calculate() call. This is set with the blockSizeInSamples property, if we choose it to be 1 then the calculation will be sample-based and we only receive one sample per calculate() call, but if we set it higher then we receive a block of samples every time.

Sometimes we need access to previous or future samples in order to correctly process our signal, in this case, we use the futureSamplesRequiredForCalculation or pastSamplesRequiredForCalculation which allows us to access these samples. 

calculate

This method is called repeatedly during Measure mode. Here we can safely read from and write to the channels. In this method, we add the actual logic for our plugin:

1void LatchMathModule::calculate()
2{
3    float currentSampleCriteriaChannel = criteriaChannelIn.getScalar(0);
4    float nextSampleCriteriaChannel = criteriaChannelIn.getScalar(1);
5
6    // check if the two samples from Criteria channel are on different sides of Latch criteria
7    bool crossedRisingEdgeCriteria = currentSampleCriteriaChannel <= criteriaLimit && nextSampleCriteriaChannel >= criteriaLimit;
8    bool crossedFallingEdgeCriteria = currentSampleCriteriaChannel >= criteriaLimit && nextSampleCriteriaChannel <= criteriaLimit;
9
10    // if user set the type of edge to rising edge and the Criteria channel crossed it
11    // or user set the type of edge to falling edge and the Criteria channel crossed it
12    if ((crossedFallingEdgeCriteria && edgeType == FallingEdge) || (crossedRisingEdgeCriteria && edgeType == RisingEdge))
13    {
14        // add the value of the next sample from Input channel to the Latched channel
15        float value = inputChannelIn.getScalar(1);
16        outputChannel.addScalar(value, inputChannelIn.getTime(1));
17    }
18}

We have now implemented all the logic required by our latch math plugin, but we have a big problem: the users are not able to change any settings of our module, so the criteria limit is always going to be 0 and we are always going to be looking for the rising edge! Let's create a user interface so they get a chance to modify these values. 

We are now ready to start creating the UI for Latch math. We will start by taking a look at the already existing UI for latch math that is integrated into Dewesoft. It can be found in Measure mode -> Math -> Add math -> Latch value math. Keep in mind that this is a basic tutorial so we will keep things simple.

Remember that in our getPluginProperties() we defined our module to have 2 input slots, so that's where the first difference from the built-in latch math will be. In addition to that, the Output value will be set to Actual by default, and we will not allow the user to change it. But we will also allow the user to choose if they are looking for the latch condition at rising or falling edge, and change the criteria limit.

Therefore, we will need a TextBox (control, which displays a user-editable text) so the user will be able to enter Criteria limit and a Label (control, which displays read-only text) that will be added to the TextBox so it will be more descriptive. We will also need a ComboBox (control, which creates a drop-down menu) for determining whether we are calculating rising or falling edge.

We will visually group settings using CaptionPanel (layout control with a title) and a Grid (a type of layout, which arranges its child controls in an arbitrary number of rows and columns that can be spanned).

The user interface is defined in the ui/setup/setup_window.xml file by using simple, XML-like syntax. The XML code for our UI will be presented in smaller pieces so it will be easier to explain and understand. But first, let's open up a preview window for our UI called MUI Designer. MUI Designer allows for live previews of your design. It can be found under View > Other windows > MUI Designer (Dewesoft).

In the picture below you can see our final user interface in MUI Designer. The preview is automatically refreshed when the code is changed and if we run the plugin in Dewesoft the UI will look and behave exactly as shown in the MUI Designer.

Let's go through the XML code piece by piece:

1<?xml version="1.0" encoding="utf-8"?>
2<Window xmlns="https://mui.dewesoft.com/schema/1.1">
3  <CaptionPanel Title="Latch criteria settings">

First, we write the code to add the CaptionPanel to the UI.

1  <Grid PaddingLeft="5">
2      <Grid.ColumnDefinitions>
3        <ColumnDefinition Width="170"/>
4        <ColumnDefinition Width="100%"/>
5      </Grid.ColumnDefinitions>
6      <Grid.RowDefinitions>
7        <RowDefinition Height="20"/>
8        <RowDefinition Height="20"/>
9        <RowDefinition Height="10"/>
10        <RowDefinition Height="20"/>
11        <RowDefinition Height="20"/>
12        <RowDefinition Height="100%"/>
13      </Grid.RowDefinitions>

This part of the code contains a Grid that will split your UI into five rows. There will only be one column because all the elements will be stacked one below the other. This column has a width of 170 pixels. 

1  <Label Grid.Column="0" Grid.Row="0" Text="Criteria limit" />
2      <TextBox Grid.Column="0" Grid.Row="1" Name="latchCriteriaEdit" Text="0" />
3      <Label Grid.Column="0" Grid.Row="3" Text="Edge type" />
4      <ComboBox Grid.Column="0" Grid.Row="4" Name="edgeTypeCBox" />      
5    </Grid>
6  </CaptionPanel>
7</Window>

And lastly, we add the code for the actual components to our UI. Elements need to be aligned and visually grouped (items that are connected should be closer. e.g. Criteria limit caption Label and TextBox). 

We have now designed our UI components we will need for our example, but they don't do anything yet. To bring them to life we need to introduce events to our code (i.e. Click, CheckedChanged, etc.). To create an event all you have to do is provide a method with the same signature as the control's event handler and then bind it to the control.

Event handlers are declared in the header files. Here you can see the declaration of event handlers that will be executed when an event is triggered. This part of the code should be placed inside the private section in ui/setup/setup_window.h file. In our case we want to add 2 event handlers: when user changes the Criteria limit, and when he changes the edge type.

1class LatchMathSetupWindow: public LatchMathSetupWindowBase
2{
3  // ...
4  private:
5      void onLatchCriteriaEditChanged(Dewesoft::MUI::TextBox& editBox, Dewesoft::MUI::EventArgs& args);
6      void onEdgeTypeCBoxChanged(Dewesoft::MUI::ComboBox& cBox, Dewesoft::MUI::EventArgs& args);
7};

Because a component can have multiple event handlers bound to the same event, we use += operator for adding and -= operator for removing event handlers. Events should be bound inside the bindEvents() method. The code for how to bind events to our controls in ui/setup/setup_window.cpp can be seen below. 

1void LatchMathSetupWindow::bindEvents()
2{
3    latchCriteriaEdit.OnTextChanged += mathEvent(&LatchMathSetupWindow::onLatchCriteriaEditChanged);
4    edgeTypeCBox.OnChange += mathEvent(&LatchMathSetupWindow::onEdgeTypeCBoxChanged);

With this, we can move on to actually implementing the event handlers. These functions will be used to set the variables in the Module class, which we access by using a special variable called module.

Event handlers are defined in ui/setup/setup_window.cpp file. The following pictures will show which event handler is called when a certain action is performed. 

This part of the code is triggered if we edit the text in component marked with the red square in the picture above. It is used for setting the criteriaLimit property of the module. Because the latchCriteriaEdit is a text box the value we read from it is a string and we need to change it to a number in order to assign it to criteriaLimit variable.

1void LatchMathSetupWindow::onLatchCriteriaEditChanged(Dewesoft::MUI::TextBox& editBox, Dewesoft::MUI::EventArgs& args)
2{
3    module->criteriaLimit = std::stod((std::wstring) latchCriteriaEdit.getText());
4}

This part of the code is triggered if we click on the component marked with the red square in the picture above. It is used for setting the edgeType property of the module.

1void LatchMathSetupWindow::onEdgeTypeCBoxChanged(Dewesoft::MUI::ComboBox& cBox, Dewesoft::MUI::EventArgs& args)
2{
3    module->edgeType = edgeTypes(edgeTypeCBox.getSelectedIndex());
4}

Initialization

We also need to fill the edgeTypeCBox with values and set the components to some default values. This can be done in the initiate() method in the ui/setup/setup_window.cpp file like so:

1void LatchMathSetupWindow::initiate()
2{
3    edgeTypeCBox.clear();
4    edgeTypeCBox.addItem("Rising");
5    edgeTypeCBox.addItem("Falling");
6}

We are now ready to test our plugin. We can do this by running your plugin by pressing F5 on your keyboard and going to Ch. setup tab, then click More and choosing the Latch math - Scalar button. A window like this should appear. 

Remember the setup we created and saved in Dewesoft before (from the start of C++ Script pro training)? We are going to use it here. We go to the Setup files tab and double-click on the setup we want to load. The setup we loaded should include the two signals we created earlier and a blank setup Latch Math - Scalar setup window.

We assign the signals to the Input and Criteria channel, set the Criteria limit, and decide whether we are looking for a latch condition at rising or falling edge. Our setup should now look like this:

Now we can go to the Measure tab, where we can see a visual representation of the Latch.

Note that to get the exact picture below we turned off the Interpolate asynchronous channels option in the Drawing option of the recorder setup, to better demonstrate that our values are "latched".

In image 20 we can see that every time the sine signal passes 0 at the rising edge threshold, the output channel outputs the current value of the time signal. The outputted value represents the time at which the sine signal passed 0.

We can now change the edge type to the falling edge and the criteria limit to 0,5.  

We have created a working plugin for performing latch math. In the previous sections, we took advantage of the C++ Processing Plugin to allow multiple input channels and thus simplifying the code of the example. But let us now change the plugin to copy the latch math setup even more. One thing that looks like an obvious target is the input channels on the left-hand side of the setup window. But to modify that we need to take a look at the other class found inside plugin.h/.cpp files that we have been ignoring until now: SharedModule.

Module vs. SharedModule

After taking a closer look at the plugin.h file you have probably noticed that it contains two classes, one being the Module class which we modified in the previous sections, and the other one being the SharedModule class. 

As you can see from other applications in Dewesoft (e.g. FFT Analysis) you can choose more than one input channel by checking the checkboxes next to the available channel. This creates a new object of the class Module for every input channel selected. The different Module classes exist as their own entities and are completely independent of each other, except for all the settings that they store (via updateSettings() function, which will be explained shortly) are copied between them. 

But sometimes it could be very useful to have either an overview of these classes, or be able to have a setting that is shared between them. This is where the SharedModule class comes into play. The SharedModule class has an overview of every Module class that exists inside this application. This means that every new application has a SharedModule class which is accessible by all the Module classes we create by choosing new input channels. 

If we take a look again at the Latch value math setup inside Dewesoft we see that the criteria channel is set only once, no matter how many input channels we choose. Every input channel we check is its own Module class and the Criteria channel is a channel belonging to the SharedModule class, so let's recreate this in our example.

To mimic the Latch value math in our plugin we will first need to change it to accept only one input channel. We do this by changing the inputSlotsMode property to accept a single input channel (or we can remove the property altogether as Dewesoft automatically uses single as the default value):

1void LatchMathModule::getPluginProperties(PluginProperties& props)
2{
3    // ...
4    props.inputSlotsMode = InputSlotsMode::single;
5}

In order to use the criteria channel read from UI, we need to first read it and connect it to a channel in the SharedModule class of the plugin. In the plugin.h file we define a new variable for our channel:

1class LatchMathSharedModule: public Dewesoft::Processing::Api::Advanced::SharedModule
2{
3  public:
4    void connectInputChannels(InputChannelSlots& slots) override;
5
6  private:
7    ScalarInputChannel criteriaChannelShared;
8};

And to the plugin.cpp we connect a channel to the variable. When we connect the input channel we connect it to a slot and it is really important to give it a unique name, because we can use it later to search for the slot by its name.

1void LatchMathSharedModule::connectInputChannels(InputChannelSlots& slots)
2{
3    slots.connectChannel("Criteria channel", &criteriaChannelShared, ChannelTimebase::Synchronous);
4}

Now we need to tell the main class of the plugin, the Module class, to use this channel. We reconnect the SharedModule channel to the same channel in Module class we used before when we had two input channels by modifying the connectInputChannels() function:

1void LatchMathModule::connectInputChannels(InputChannelSlots& slots)
2{
3    slots.connectChannel("Input channel", &inputChannelIn, ChannelTimebase::Synchronous);
4    slots.useSharedModuleChannel("Criteria channel", &criteriaChannelIn);
5}

With this, the "Criteria channel" is now redirected to each individual module, so the code in configure() and calculate() functions stays the same.

We will now make changes to ui/setup/setup_window.xml file to add the dropdown for selecting the channel. We need to add a ComboBox to our UI and to do this we add an additional column to the grid and group the components accordingly.

1<?xml version="1.0" encoding="utf-8"?>
2<Window xmlns="https://mui.dewesoft.com/schema/1.1">
3  <CaptionPanel Title="Latch criteria settings">
4    <Grid PaddingLeft="5">
5      <Grid.ColumnDefinitions>
6        <ColumnDefinition Width="140"/>
7        <ColumnDefinition Width="30"/>
8        <ColumnDefinition Width="120"/>
9        <ColumnDefinition Width="100%"/>
10      </Grid.ColumnDefinitions>
11      <Grid.RowDefinitions>
12        <RowDefinition Height="20"/>
13        <RowDefinition Height="20"/>
14        <RowDefinition Height="10"/>
15        <RowDefinition Height="20"/>
16        <RowDefinition Height="20"/>
17        <RowDefinition Height="100%"/>
18      </Grid.RowDefinitions>
19     
20      <Label    Grid.Column="0" Grid.Row="0" Text="Criteria channel"/>
21      <ComboBox Grid.Column="0" Grid.Row="1" Name="criteriaChannelCBox" />
22      <Label    Grid.Column="2" Grid.Row="0" Text="Criteria limit" />
23      <TextBox  Grid.Column="2" Grid.Row="1" Name="latchCriteriaEdit" Text="0" />
24      <Label    Grid.Column="0" Grid.Row="3" Text="Edge type" />
25      <ComboBox Grid.Column="0" Grid.Row="4" Name="edgeTypeCBox" />
26    </Grid>
27  </CaptionPanel>
28</Window>

With the code above we now create the UI that looks like this. 

Adding the new ComboBox component means we also need to add the event handler for it. The declaration of the event handler in the setup_window.h file should look like this

1class LatchMathSetupWindow: public LatchMathSetupWindowBase
2{
3    // ...
4    void onCriteriaChannelCBoxChanged(Dewesoft::MUI::ComboBox& cBox, Dewesoft::MUI::EventArgs& args);
5}

Every input channel has a designated input slot, we connect the input channel to the slot in the connectInputChannels() and we can then access the slot by searching for it by the unique slot name we defined earlier. So, the definition in ui/setup/setup_window.cpp looks like this:

1void LatchMathSetupWindow::onCriteriaChannelCBoxChanged(Dewesoft::MUI::ComboBox& cBox, Dewesoft::MUI::EventArgs& args)
2{
3    sharedModule->getInputSlot("Criteria channel").assignChannel(criteriaChannelCBox.getSelectedItem());
4}

Note that much like we accessed Module via the module variable, we can use sharedModule to access the SharedModule object. We use it to retrieve the input slot used for criteria channel, and then assign a channel to it whenever a user selects a different value in the combo box.

And let's not forget to bind this event in bindEvents() method:

1void LatchMathSetupWindow::bindEvents()
2{
3    // ...
4    criteriaChannelCBox.OnChange += mathEvent(&LatchMathSetupWindow::onCriteriaChannelCBoxChanged);
5}

If we now run our plugin we will notice that the new ComboBox is empty even though there might be channels available in Dewesoft. The Criteria channel ComboBox needs to be filled manually with channels. We do this in the initiate() method inside the ui/setup/setup_window.cpp. 

1void LatchMathSetupWindow::initiate()
2{
3    // ...
4    
5    criteriaChannelCBox.clear();
6    ChannelSlot& slot = sharedModule->getInputSlot("Criteria channel");
7    for (std::string& channelName : availableChannelsFor(slot))
8        criteriaChannelCBox.addItem(channelName);
9}

When we now enter the setup of our plugin, the criteria channel dropdown will be filled with all the channels currently available in Dewesoft that are scalar and synchronous. The filtering of available channels is done automatically, it uses the properties we defined when we connected the channel to a slot, and because we connected ScalarInputChannel with synchronous timebase as criteria channel, the availableChannelsFor() function returns all synchronous and scalar channels available in Dewesoft at the moment the setup is entered.

The setup of the plugin with assigned input channels will now look like this

At roughly this point in our C++ Script pro training we decided we wanted to add support for Vector input channels to our script. How about we try doing the same for our Processing plugin?

To continue following along with the pro training, prepare the setup file we created in C++ Script > Example II: Vector latch math, and while you are there, refresh your knowledge on different channel types found in Dewesoft. All that knowledge transfers seamlessly to the Processing plugin!

Let's start with the project which was created in Example I and modify it to support vector channel. 

The first thing we need to do is change the input and output channels to be vector channels. This is simply done by changing the declaration of the channel to be a vector channel and not scalar as before. The criteria channel stays the same.

1class LatchMathModule : public Dewesoft::Processing::Api::Advanced::Module
2{
3  public:
4    // ...
5    VectorInputChannel inputChannelIn;
6    VectorOutputChannel outputChannel;
7}

We also need to change the connectChannel() for our vector channel, as we don't want it to be synchronous anymore. Vector channels always have either asynchronous or single-value timebase, and connectChannel() function is smart enough to figure out we are now connecting Vector channel on its own.

1void LatchMathModule::connectInputChannels(InputChannelSlots& slots)
2{
3    slots.connectChannel("Input channel", &inputChannelIn);
4    slots.useSharedModuleChannel("Criteria channel", &criteriaChannelIn);
5}

calculate

To get from Example I to Example II we only need to fix the reading from and writing to vector channels. To read from the InputChannelIn channel we now use the function .getVector() and to write to OutputChannel we use the .addVector() function.

We will also move the checking of whether the criteria limit has been crossed to a new function and make the code more readable. We declare this new function in the plugin.h file:

1class LatchMathModule : public Dewesoft::Processing::Api::Advanced::Module
2{
3public:
4    // ...
5    bool checkCrossedEdgeCriteria(float currentSampleCriteriaChannel, float nextSampleCriteriaChannel);
6};

and write the function in plugin.cpp like this:

1bool LatchMathModule::checkCrossedEdgeCriteria(float currentSampleCriteriaChannel, float nextSampleCriteriaChannel)
2{
3    bool crossedRisingEdgeCriteria = currentSampleCriteriaChannel <= criteriaLimit && nextSampleCriteriaChannel >= criteriaLimit;
4    bool crossedFallingEdgeCriteria = currentSampleCriteriaChannel >= criteriaLimit && nextSampleCriteriaChannel <= criteriaLimit;
5
6    return (crossedFallingEdgeCriteria && edgeType == FallingEdge) 
7        || (crossedRisingEdgeCriteria && edgeType == RisingEdge);
8}

The calculate() can now be changed to this:

1void LatchMathModule::calculate()
2{
3    float currentSampleCriteriaChannel = criteriaChannelIn.getScalar(0);
4    float nextSampleCriteriaChannel = criteriaChannelIn.getScalar(1);
5
6    bool crossedEdge = checkCrossedEdgeCriteria(currentSampleCriteriaChannel, nextSampleCriteriaChannel);
7
8    if (crossedEdge)
9    {
10        adv::Vector value = inputChannelIn.getVector();
11        outputChannel.addVector(value, inputChannelIn.getTime());
12    }
13}

configure

Because our output channel will now be a vector channel we have to set the OutputChannel channel's axis to fit the vectors we want to output. We do this in the configure() function of the plugin. In our case, we are just copying the values from the input channel to output, meaning we can simply build the axis from the input channel by calling the .copyAxis() function and giving it the input channels axis as a parameter. 

Our input channel will be a vector channel which is of the asynchronous type, this means that we also need to change the resampler settings. We will set the samplingRate to be AsynchronousSingleMaster. This change is necessary because the resampler resamples all the input channels to the same sampling rate and if we have a vector channel as an input and we want a synchronous sampling rate then the channel will get resampled to be synchronous, but a vector channel with synchronous sampling rate does not exist in Dewesoft since that would be extremely time and space consuming. If we change the sampling rate we also need to set a master channel to which all other input channels will be resampled to. In our case, the master channel will be the inputChannelIn channel and the criteriaChannelIn will get resampled to the samples of inputChannelIn, in other words, the samples of criteriaChannelIn will have the same timestamp as the samples of inputChannelIn.

1void LatchMathModule::configure()
2{    
3    resampler.blockSizeInSamples = 1;
4    resampler.samplingRate = ResamplerSamplingRate::AsynchronousSingleMaster;
5    resampler.setMasterChannel(&inputChannelIn);
6    resampler.futureSamplesRequiredForCalculation = 0;
7
8    outputChannel.axes[0].copyAxis(inputChannelIn.axes[0]); 
9    outputChannel.setExpectedAsyncRate(5);  
10}

There is one thing we need to keep an eye on: expectedAsyncRate property of our output channel. This warrants a slight detour:

Expected async rate per second

Much like in C++ Script, if our module contains asynchronous output channels, we have to set their expected rate per second. You can think of this as "approximately how many samples will I be adding to this channel per second". We can change the value of this setting in configure()  method by modifying the channel's setExpectedAsyncRate(). This setting is required because we need to help Dewesoft figure out much memory it needs to reserve for our channel. While we can calculate this value in any way we want, it can be useful if we know the rate of our output channel is somehow going to be connected to the rate of some other input channel, in which case we can simply set the outputChannel.setExpectedAsyncRate(inputChannel.expectedAsyncRate()).

We can set expectedAsyncRate() to a completely arbitrary value, but if the expectedAsyncRate() is set too high Dewesoft will reserve too much memory and if it is set too low we might lose some important data. We don't need to set expectedAsyncRate() to the exact value, but we need to specify it to within an order of magnitude.

In fact, if we do not set the expected async rate for every single asynchronous output channel, our plugin will refuse to load.

You might have noticed that whenever you reopened Dewesoft, the settings in our plugin got reset to their default values. It would be great if we could somehow store our plugin's setup and load it whenever we load an old setup. In our case, we could save information about Criteria limit and whether we are looking for rising or falling edge.

• The first parameter is the name under which your setting is saved. This parameter should be unique for every setting, must not contain any whitespace, and must start with a letter.

• The second parameter is the actual value to be stored.

• The optional third parameter specifies what the default value should be.

Updating our settings inside plugin.cpp file is done in updateSetup() as seen in the code below. It is used to read stored values whenever we load a setup and write the values whenever we save a setup in Dewesoft.

1void LatchMathSetupModule::updateSetup(Setup& setup)
2{
3    setup.update("criteriaLimit", criteriaLimit, 0.0);
4
5    int intEdgeType = int(edgeType);
6    setup.update("edgeType", intEdgeType, 0);
7    edgeType = edgeTypes(intEdgeType);
8}

We also need to make sure that input fields on the UI get filled with correct values every time the user loads the setup. We do this in the initiate() method of the ui/setup/setup_window.cpp file:

1void LatchMathSetupWindow::initiate()
2{
3    // ...
4    if (slot.getAssignedChannel())
5        criteriaChannelCBox.setSelectedIndex(criteriaChannelCBox.getIndexOf(slot.getAssignedChannel().name()));
6
7    latchCriteriaEdit.setText(std::to_string(module->criteriaLimit));
8    edgeTypeCBox.setSelectedIndex(int(module->edgeType));    
9}

Because C++ Processing Plugin uses Visual Studio IDE, it supports great debugging tools. It helps you find semantic errors, see variable values in real-time, set breakpoints, add watches on variables to see values changing during program execution, and much more. 

If we now run our plugin by pressing the F5 on the keyboard, load the setup we created for testing the plugin and try to assign the channels as seen in image 27.

We quickly get an error message.

We can see that the error is thrown in the CalculateBlock() method which means that the error occurs in the calculate() method of our plugin. We will now set a breakpoint inside of this method, start our plugin with F5 keystroke again, and again try to assign the channels. When the program execution reaches our breakpoint we will be able to look at every line of code to find out, which one is causing our plugin to crash. To move to the next line use the F10 keystroke (this will step over function calls).

We will try to find the error using Visual Studio Debugger. 

After moving through the code we see that we are trying to access a sample at position 1 in the line 46, but it does not work. 

The first thing we need to check is if we actually have access to this future sample. We need to check the 

1configure()

 method. Here we see that the 

1futureSamplesRequiredForCalculation

  is set to 0, this means we are trying to read a sample that does not exist yet and this is why we get an error.

To fix this error we just set the 

1futureSamplesRequiredForCalculation

 to 1 and the plugin should now work as intended.

One of the important stages of plugin development is testing. Unit testing is a software testing method that tests your plugin by running predefined test cases and checking if the result is correct.  C++ Processing plugin allows you to write and run automated tests almost trivially, which will shorten both your development as well as testing time.

We can test each segment without having to start Dewesoft. All the tests are defined in the plugin_test.cpp file which can be found inside the LatchMathTest solution. We will create two simple unit tests, to test our method checkCrossedEdgeCriteria() . If the returned value is the same as the one set, the unit test will mark it as "PASSED".

Here you can see some examples of unit tests:

1TEST(LatchMathModule, CheckCriteriaLimitRisingEdge)
2{
3    LatchMathModule p;
4
5    p.criteriaLimit = 0.5;
6    p.edgeType = RisingEdge;
7
8    EXPECT_TRUE(p.checkCrossedEdgeCriteria(0.49, 0.51));
9    EXPECT_TRUE(p.checkCrossedEdgeCriteria(0, 1));
10    EXPECT_TRUE(p.checkCrossedEdgeCriteria(0, std::numeric_limits<float>::infinity()));
11    EXPECT_TRUE(p.checkCrossedEdgeCriteria(-std::numeric_limits<float>::infinity(), std::numeric_limits<float>::infinity()));
12    EXPECT_FALSE(p.checkCrossedEdgeCriteria(0.51, 0.49));
13    EXPECT_FALSE(p.checkCrossedEdgeCriteria(1, 0));
14    EXPECT_FALSE(p.checkCrossedEdgeCriteria(0, -std::numeric_limits<float>::infinity()));
15    EXPECT_FALSE(p.checkCrossedEdgeCriteria(0.49, 0.4999999));
16}
17
18TEST(LatchMathModule, CheckCriteriaLimitFallingEdge)
19{
20    LatchMathModule p;
21
22    p.criteriaLimit = 0.2;
23    p.edgeType = FallingEdge;
24
25    EXPECT_TRUE(p.checkCrossedEdgeCriteria(0.21, 0.19));
26    EXPECT_TRUE(p.checkCrossedEdgeCriteria(1, 0));
27    EXPECT_TRUE(p.checkCrossedEdgeCriteria(std::numeric_limits<float>::infinity(), 0));
28    EXPECT_TRUE(p.checkCrossedEdgeCriteria(std::numeric_limits<float>::infinity(), -std::numeric_limits<float>::infinity()));
29    EXPECT_FALSE(p.checkCrossedEdgeCriteria(0.19, 0.21));
30    EXPECT_FALSE(p.checkCrossedEdgeCriteria(0, 1));
31    EXPECT_FALSE(p.checkCrossedEdgeCriteria(-std::numeric_limits<float>::infinity(), 0));
32    EXPECT_FALSE(p.checkCrossedEdgeCriteria(0.19999999, 0.219999));
33}

We can use Visual Studio's Test Explorer to run and see the results of our unit tests. In order to open the Test Explorer go to Test > Windows and click on Test Explorer. 

The tests are run by clicking the Run All option in the Test Explorer. And after the testing is completed there will be a green checkmark before the test name for all the tests that passed, and a red cross for all the failed tests.

If you now start your plugin and set your Input channel to AI 1/AmplFFT and Criteria channel to sine(1), as seen in the picture below,

You are able to see the outputted vectors on a 3D graph. A new vector is outputted every time the sine(1) signal passes the value 0 on the rising edge.

As you can see, whenever sine(1) crosses the Criteria limit, we output the last vector sample from our input channel AI1/AmplFFT to our Output channel.

We have now just about recreated everything we did in the C++ Script pro training. But let's introduce one last twist to our problem: let's say that calculating the crossing criteria is not as trivial as just checking the last and next values of some input channel. Let's say that checking whether we should output value into an output channel is a computationally expensive operation. For example, we could simulate this by modifying the checkCrossedEdgeCriteria() function as so:

1bool LatchMathModule::checkCrossedEdgeCriteria(float currentSampleCriteriaChannel, float nextSampleCriteriaChannel)
2{
3    std::this_thread::sleep_for(std::chrono::milliseconds(100));
4
5    bool crossedRisingEdgeCriteria = currentSampleCriteriaChannel <= criteriaLimit && nextSampleCriteriaChannel >= criteriaLimit;
6    bool crossedFallingEdgeCriteria = currentSampleCriteriaChannel >= criteriaLimit && nextSampleCriteriaChannel <= criteriaLimit;
7    return (crossedFallingEdgeCriteria && edgeType == FallingEdge) 
8        || (crossedRisingEdgeCriteria && edgeType == RisingEdge);
9}

How could we possibly speed up the overall performance of our plugin in such a case? SharedModule to the rescue!

The trick is simple: currently, every single module individually calls the checkCrossedEdgeCriteria(), and figures out if the edge was crossed or not. We might have 5 modules, meaning the total time spent checking for the same condition will be close to 0.5 seconds. But note that the check is completely independent from the actual modules - it uses the criteria channel plus settings that are completely synchronized between all Modules. Meaning we could just as well run this check only once, on SharedModule, and have a constant 0.1 second delay regardless of how many Modules we have. So how do we do that?

Modifying our code to use SharedModule as master resampler

Let's use the code from Example I as the starting point. To use SharedModule as the master resampler, really all we need to do is set the resamplerBase in SharedModule's configure() function to ResamplerBase::SharedModule. But let's go step by step: first, let's clean up the LatchMathModule class. We need to strip down the following procedures, as they will now not be used:

1void LatchMathModule::connectInputChannels(InputChannelSlots& slots)
2{
3    slots.connectChannel("Input channel", &inputChannelIn, ChannelTimebase::Synchronous);
4}
5
6void LatchMathModule::configure()
7{
8    outputChannel.setExpectedAsyncRate(5); // we still need to set output channel's expectedAsyncRate
9}
10
11void LatchMathModule::calculate()
12{
13}

Feel free to completely remove calculate() and checkCrossedEdgeCriteria(), as they will now be implemented by the SharedModule. So, in plugin.h, let's add a few more procedures to LatchMathSharedModule:

1class LatchMathSharedModule : public Dewesoft::Processing::Api::Advanced::SharedModule
2{
3  public:
4    void configure() override;
5    void calculate() override;
6
7    bool checkCrossedEdgeCriteria(float currentSampleCriteriaChannel, float nextSampleCriteriaChannel);
8    // ...

and in plugin.cpp let's implement them:

1void LatchMathSharedModule::configure()
2{
3    resampler.resamplerBase = ResamplerBase::SharedModule;
4    resampler.samplingRate = ResamplerSamplingRate::Synchronous;
5    resampler.blockSizeInSamples = 1;
6    resampler.futureSamplesRequiredForCalculation = 1;
7}
8
9bool LatchMathSharedModule::checkCrossedEdgeCriteria(float currentSampleCriteriaChannel, float nextSampleCriteriaChannel)
10{
11    LatchMathModule* m = static_cast<LatchMathModule*>(getModule(0));
12    bool crossedRisingEdgeCriteria = currentSampleCriteriaChannel <= m->criteriaLimit && nextSampleCriteriaChannel >= m->criteriaLimit;
13    bool crossedFallingEdgeCriteria = currentSampleCriteriaChannel >= m->criteriaLimit && nextSampleCriteriaChannel <= m->criteriaLimit;
14
15    return (crossedFallingEdgeCriteria && m->edgeType == FallingEdge)
16        || (crossedRisingEdgeCriteria && m->edgeType == RisingEdge);
17}
18
19void LatchMathSharedModule::calculate()
20{
21    float currentSampleCriteriaChannel = criteriaChannelShared.getScalar(0);
22    float nextSampleCriteriaChannel = criteriaChannelShared.getScalar(1);
23
24    bool crossedEdge = checkCrossedEdgeCriteria(currentSampleCriteriaChannel, nextSampleCriteriaChannel);
25
26    if (crossedEdge)
27    {
28        for (auto& m: getModules())
29        {
30                auto& inputChannel = static_cast<LatchMathModule*>(m)->inputChannelIn;
31                static_cast<LatchMathModule*>(m)->outputChannel.addScalar(inputChannel.getScalar(), inputChannel.getTime());
32        }
33    }
34}

Let's slowly walk through what we actually did here:

• In configure() we have set resampler's resamplerBase to SharedModule. This makes it so SharedModule's resampler overrides the individual Modules' resamplers and takes control over all resampling. The rest of the function should be self-explanatory at this point, but we don't need to set the expectedAsyncRates of output channels, as SharedModule has no output channels.

• In checkCrossedEdgeCriteria() we use getModule(0) to retrieve 0-th module (which always exists) so we can read off its criteriaLimit and edgeType. We could also move these variables to the SharedModule class, but we don't need to.

• In calculate(), we now first check whether we crossed the edge or not, and if we did, we use getModules() to loop over all the Modules, read the value of their input channels, and fill it into their output channels.

And that's all there is to it. But let's look over one last possible optimization.

Using variable block size

There is one last optimization we can do here which C++ Script is incapable of. In configure() procedure we currently set the resampler's blockSizeInSamples to 1, which means Dewesoft will split data from input channels on chunks of the length of 1. This is extremely wasteful and can be very slow. In C++ Script we could set blockSizeInSamples to some bigger number (say, 1024) to get more samples into the calculate() call at once. This is a fine solution, but how do we determine the exact number to use for blockSizeInSamples? In Processing plugin, what we can do instead, is say we want a so-called variable block size, meaning we want Dewesoft to pass all the data it has available for processing at any moment down to us, at once. To do that, add the following piece of code to configure():

1void LatchMathSharedModule::configure()
2{
3    // ...
4    resampler.blockSizeType = ResamplerBlockSizeType::Variable;
5}

With this, we must now also modify the calculate function to loop over all the samples Dewesoft sent us (the actual count is retrieved via callInfo structure):

1void LatchMathSharedModule::calculate()
2{
3    for (int i = 0; i < callInfo.newSamplesCount; ++i)
4    {
5        float currentSampleCriteriaChannel = criteriaChannelShared.getScalar(i);
6        float nextSampleCriteriaChannel = criteriaChannelShared.getScalar(i + 1);
7
8        bool crossedEdge = checkCrossedEdgeCriteria(currentSampleCriteriaChannel, nextSampleCriteriaChannel);
9
10        if (crossedEdge)
11        {
12            for (auto& m: getModules())
13            {
14                auto& inputChannel = static_cast<LatchMathModule*>(m)->inputChannelIn;
15                static_cast<LatchMathModule*>(m)->outputChannel.addScalar(inputChannel.getScalar(i), inputChannel.getTime(i));
16            }
17        }
18    }
19}

In this Pro Training, we have created a pretty useful plugin, which we might want to use in other setups or on other computers. C++ Processing Plugin packs your plugin into an external library, which can be inserted into any Dewesoft around the world.

Your C++ Processing Plugin is found inside a file with .ilk and .prc extension (they contain instructions that Dewesoft can call upon to do certain things, based on the purpose of your plugin). To export it, you need to locate these files first. They can be found inside DEWESoftX\DEWEsoft\Bin\Addons folder if the plugin was built using the 32-bit version of Dewesoft (or inside DEWESoftX\DEWEsoft\Bin64\Addons folder if the plugin was built using the 64-bit version of Dewesoft) in a folder with the same name as the plugin base class name.

To import your plugin you have to copy and paste files with .prc extension into any Dewesoft that requires your plugin. You need to paste it inside Addons folder and Dewesoft will be able to automatically recognize and load it.

At this point, you might have a pretty good grasp on how to use C++ Processing Plugin. But C++ Processing Plugin is just one of many ways of extending Dewesoft to suit your needs, and it might be slightly confusing to try and figure out if it actually is the best solution for your task. So in this section, we briefly compare different approaches and list a couple of pros and cons which can hopefully help you pick the right tool.