Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

Ok, just to get my testing started on the new X32 heartbeat code encapsulation as you suggested.
I added the changes you mentioned, but this piece of code fails to compile:

void ControlSurface::RequestUpdate()
{
....

    if (GetName().find("X32") != string::npos || GetName().find("x32") != string::npos)
        surfaceIO->SendX32HeartBeat();
....
}

..... 'surfaceIO': undeclared identifier


Am getting brain fog now, any thoughts?

Yup, missing an underscore, which denotes a member variable, an instance variable in this case (as opposed to a class variable):

void ControlSurface::RequestUpdate()
{
    if(GetName() contains the phrase X32)
        surfaceIO_->SendX32Heartbeat();   

}

[JP_]

Originally Posted by MixMonkey

That's as it should be. I'm afraid it rather looks like the native mode of the X-Touch Compact enables some kind of local control of the LEDs. I hope I'm wrong.

How would I find out more about this?

[MT4U]

Hi there.

Do you guys have any suggestion of a decent free Synth plug-in worth mapping with CSI, in order to make some tutorial of advanced FX mapping that anyone could try?

Thanks!

[Funkybot]

Originally Posted by MT4U

Hi there.

Do you guys have any suggestion of a decent free Synth plug-in worth mapping with CSI, in order to make some tutorial of advanced FX mapping that anyone could try?

Thanks!

Depends on how advanced you want to get.

Simple:
DiscoDSP OB-Xd

Complex:
Surge XT
Vital

...I'd think those are probably among the most commonly used freebie synths.

[MT4U]

Originally Posted by Funkybot

Depends on how advanced you want to get.

Simple:
DiscoDSP OB-Xd

Complex:
Surge XT
Vital

...I'd think those are probably among the most commonly used freebie synths.

Excellent. DiscoDSP is an old acquaintance I'll check the other two before I choose.

Thank you, FB!!!

[MixMonkey]

Originally Posted by JP_

How would I find out more about this?

You can try what passes for a manual, but I doubt it would go into this. I just checked my XTouch and it behaves the same way in native mode. If you're on Windows you can check out the editor app and see if that holds any answers.

[JP_]

Originally Posted by MixMonkey

You can try what passes for a manual, but I doubt it would go into this. I just checked my XTouch and it behaves the same way in native mode. If you're on Windows you can check out the editor app and see if that holds any answers.

Yeah the manual doesn't, and ah I forgot about that. Might be worth a punt. So with regards to the LED not lining up on panning, what can I do about that?

I believe it worked in MCU and I think it worked in standard mode too (can't remember), but since moving to the latest build etc it's not lined up at all.

[Funkybot]

Originally Posted by JP_

Yeah the manual doesn't, and ah I forgot about that. Might be worth a punt. So with regards to the LED not lining up on panning, what can I do about that?

I believe it worked in MCU and I think it worked in standard mode too (can't remember), but since moving to the latest build etc it's not lined up at all.

I'd take a look at the .mst file.

You've got no feedback there.

Widget RotaryA1
	Encoder7Bit 	b0 0a 7f
WidgetEnd

I'd expect you still need to add the Feedback line. Try this (note: it's ok to use Fader7Bit feedback with encoders, I do that on my MFTwister)...

Widget RotaryA1
	Encoder7Bit 	b0 0a 7f
        FB_Fader7Bit    b0 0a 7f
WidgetEnd

Or that...

Widget RotaryA1
	Encoder7Bit 	b0 0a 7f
        FB_Encoder      b0 0a 7f
WidgetEnd

...if one of those works on RotaryA1, then make the same changes to the remaining Rotary widgets.

If that does solve it, let me know which one worked and I'll update the example on the Wiki.

[MixMonkey]

Originally Posted by Funkybot

Widget RotaryA1
	Encoder7Bit 	b0 0a 7f
        FB_Encoder      b0 0a 7f
WidgetEnd

This one works on the XTouch Mini in native mode.

[Funkybot]

Originally Posted by MixMonkey

This one works on the XTouch Mini in native mode.

Thanks for confirming!

JP_, once you add the feedback messages to the .mst it will almost certainly solve the issue with the rotary encoder feedback not working.

[MixMonkey]

Originally Posted by Geoff Waddington

It displays the state of the Global modifier.

This was done as part of the work (your suggestion I think) that now that VCA and Folders are Associated Zones, they are radio buttons, just like all the other Associated Zones.

Actually I think my suggestion was that it could display which of the Associated Zones were active (providing we could come up with enough signifiers), but as long as it's not supposed to be displaying TR, CA and FL anymore it's cool

[MixMonkey]

Originally Posted by Funkybot

Thanks for confirming!

JP_, once you add the feedback messages to the .mst it will almost certainly solve the issue with the rotary encoder feedback not working.

Alas, I fear the button indicators are going to be more of a problem. It's actually the same issue that the new TouchOSC has, locally controlling the button indicators, only without the same recourse to a fix

[Funkybot]

Originally Posted by MixMonkey

Alas, I fear the button indicators are going to be more of a problem. It's actually the same issue that the new TouchOSC has, locally controlling the button indicators, only without the same recourse to a fix

Yeah, agree. What kind of lunatic would design a control surface with local control of button lights? What purpose would that serve!?! And "Property+WidgetName NoFeedback" wouldn't even work to shut off the button lights because it's not getting the light state from Reaper anyway, it's all local.

Trying to think outside the box: might it be possible to use SendMIDIMessage to set the button states to off OnZoneActivation? That wouldn't keep them in sync, but would at least give you a blank state as a starting point. Then maybe even do the same on Bank. It's a mess.

I'd definitely encourage anyone thinking about getting an X-Touch Compact to go with the full-blown X-Touch Universal instead. At least for CSI. Hoping we can can find a "good enough" solution that JP_ can live with.

[MixMonkey]

Originally Posted by Funkybot

Yeah, agree. What kind of lunatic would design a control surface with local control of button lights? What purpose would that serve!

They do it because they don't envision any use case where the host provides feedback to the surface (at least not in native mode).

Which is daft beacause they eqip the surface to receive feedback- the LEDs respond to incoming messages, but then those messages are overridden by the local control on the surface.

It's a shame on the XTouch Compact because the extra rotaries are only available in native mode, otherwise you could just use MC mode and all would be well.

[Funkybot]

Originally Posted by MixMonkey

They do it because they don't envision any use case where the host provides feedback to the surface (at least not in native mode).

Which is daft beacause they eqip the surface to receive feedback- the LEDs respond to incoming messages, but then those messages are overridden by the local control on the surface.

It's a shame on the XTouch Compact because the extra rotaries are only available in native mode, otherwise you could just use MC mode and all would be well.

I was thinking maybe create two pages: one for MC Mode (use that for mixing) and another for Native mode (used for plugin mapping), but even then, you'd still need to physically reset the mode on the hardware, which would be annoying.

Maybe shoot an email to Behringer and ask that they update the native mode to turn off local feedback on buttons, but I'd be shocked if that were effective or didn't take years.

[JP_]

Originally Posted by Funkybot

I'd take a look at the .mst file.

You've got no feedback there.

Widget RotaryA1
	Encoder7Bit 	b0 0a 7f
WidgetEnd

I'd expect you still need to add the Feedback line. Try this (note: it's ok to use Fader7Bit feedback with encoders, I do that on my MFTwister)...

Widget RotaryA1
	Encoder7Bit 	b0 0a 7f
        FB_Fader7Bit    b0 0a 7f
WidgetEnd

Or that...

Widget RotaryA1
	Encoder7Bit 	b0 0a 7f
        FB_Encoder      b0 0a 7f
WidgetEnd

...if one of those works on RotaryA1, then make the same changes to the remaining Rotary widgets.

If that does solve it, let me know which one worked and I'll update the example on the Wiki.

We can blame Monkey for not adding feedback hahahahahaha (completely ignoring he re-wrote the entire thing for 2 layers like an absolute legend).

Thanks for finding a solution guys! I'll check it soon after some food <3

That local control thing sounds mental... Makes me want to contemplate getting a full x-touch and selling the compact on hahaha, but I can't, I'm a glutton for punishment!

[Geoff Waddington]

Originally Posted by MixMonkey

Actually I think my suggestion was that it could display which of the Associated Zones were active (providing we could come up with enough signifiers), but as long as it's not supposed to be displaying TR, CA and FL anymore it's cool

Ah, yes, I meant the radio button part

As far as the display, it's actually a series of mostly terrible choices

It's a 7 segment LED, so "5E" and "SE" are exactly the same thing, it goes downhill from there

[MT4U]

Originally Posted by MixMonkey

They do it because they don't envision any use case where the host provides feedback to the surface (at least not in native mode).

Which is daft beacause they eqip the surface to receive feedback- the LEDs respond to incoming messages, but then those messages are overridden by the local control on the surface.

It's a shame on the XTouch Compact because the extra rotaries are only available in native mode, otherwise you could just use MC mode and all would be well.

There's a Firmware dated 2022-06-15. Dunno if it fixes any of this...

[Geoff Waddington]

Originally Posted by MixMonkey

They do it because they don't envision any use case where the host provides feedback to the surface (at least not in native mode).

Which is daft because they equip the surface to receive feedback- the LEDs respond to incoming messages, but then those messages are overridden by the local control on the surface.

The Console One has this problem as well, pretty amazing.

[MixMonkey]

Originally Posted by Geoff Waddington

Ah, yes, I meant the radio button part

As far as the display, it's actually a series of mostly terrible choices

It's a 7 segment LED, so "5E" and "SE" are exactly the same thing, it goes downhill from there

Yeah, I thought as much The indicators on the buttons are fine and if you double up the global and selected track versions of the same Zone on one button using a modifier, the assignment display makes sense as is

[MixMonkey]

Originally Posted by MT4U

There's a Firmware dated 2022-06-15. Dunno if it fixes any of this...

That's pretty new! Any release notes?

[MixMonkey]

Originally Posted by Geoff Waddington

The Console One has this problem as well, pretty amazing.

What was the solution?

[Geoff Waddington]

Originally Posted by MixMonkey

What was the solution?

That's why there is an "AnyPress" Widget type.

The "AnyPress" Widget treats any press as a press (as opposed to a press or release -- 1 or 0), as well as providing feedback to the light.

In Console One, if the light is on, the next button press turns off the light and sends a 0.

If the light is off, the next button press turns on the light and sends a 1.

CSI works around this mess with "AnyPress".

So if Reaper tells the light to turn on, the stupid Console One linkage tells the button it is in the on (1) state.

The next button press will generate a 0, and the light will turn off.

CSI receives the 0 in the "AnyPress" Widget and says, "Yeah right", completely ignores it and sends a 1 to CSI/Reaper.

Then Reaper tells CSI what really happened and the light gets set correctly.

Not pretty, but it works.

[Funkybot]

Originally Posted by Geoff Waddington

That's why there is an "AnyPress" Widget type.

The "AnyPress" Widget treats any press as a press (as opposed to a press or release -- 1 or 0), as well as providing feedback to the light.

In Console One, if the light is on, the next button press turns off the light and sends a 0.

If the light is off, the next button press turns on the light and sends a 1.

CSI works around this mess with "AnyPress".

So if Reaper tells the light to turn on, the stupid Console One linkage tells the button it is in the on (1) state.

The next button press will generate a 0, and the light will turn off.

CSI receives the 0 in the "AnyPress" Widget and says, "Yeah right", completely ignores it and sends a 1 to CSI/Reaper.

Then Reaper tells CSI what really happened and the light gets set correctly.

Not pretty, but it works.

There you go JP_, you may want to try replacing the non-RotaryPush buttons with AnyPress widgets.

So change this...

Widget ButtonA_A1
	Press           90 10 7f 90 10 00
	FB_TwoState     90 10 7f 90 10 00
WidgetEnd

To that...

Widget ButtonA_A1
	AnyPress        90 10 7f 90 10 00
	FB_TwoState     90 10 7f 90 10 00
WidgetEnd

...and see if that helps.

[MixMonkey]

Originally Posted by Funkybot

Thanks for confirming!

JP_, once you add the feedback messages to the .mst it will almost certainly solve the issue with the rotary encoder feedback not working.

Scratch what I said about it working I was mistaken.

The more I look into it, the more I realise how utterly incompatible the feedback in native mode is with CSI on these Behringer boxes.

[Funkybot]

Originally Posted by MixMonkey

Scratch what I said about it working I was mistaken.

The more I look into it, the more I realise how utterly incompatible the feedback in native mode is with CSI on these Behringer boxes.

Damn, even the rotary feedback is still borked?

JP_, sell now! Get an X-Touch Universal!

...or maybe just stick to the MC Mode and the limitations that offers. Which sucks.

[MixMonkey]

Take a look at what we're dealing with:



Regarding the encoder rings, it's expecting to receive (for rotary 1) Controller9 with a value between 1 and 13. A value of 0 turns all the LEDs off. A value of 27 turns them all on.

[MixMonkey]

Originally Posted by Funkybot

JP_, sell now! Get an X-Touch Universal!
...or maybe just stick to the MC Mode and the limitations that offers. Which sucks.

'fraid so

[JP_]

Originally Posted by MixMonkey

Take a look at what we're dealing with:



Regarding the encoder rings, it's expecting to receive (for rotary 1) Controller9 with a value between 1 and 13. A value of 0 turns all the LEDs off. A value of 27 turns them all on.

I don't understand that stuff mate sorry haha.

I can confirm that:

Widget RotaryA1
Encoder7Bit b0 0a 7f
FB_Fader7Bit b0 0a 7f
WidgetEnd

Makes the Pan LED work perfectly, but it breaks the pan control and it starts panning in the opposite direction etc.

The AnyPress made no differencce at all.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Yup, missing an underscore, which denotes a member variable, an instance variable in this case (as opposed to a class variable):

void ControlSurface::RequestUpdate()
{
    if(GetName() contains the phrase X32)
        surfaceIO_->SendX32Heartbeat();   

}

That was a typo in my response, I did have it as "surfaceIO_" when the compile failed.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

That was a typo in my response, I did have it as "surfaceIO_" when the compile failed.

Doh, my bad, you need OSC context:

In control_surface_integrator.h

ControlSurface class:

change this

    void RequestUpdate();

to this:

    virtual void RequestUpdate();

then a bit further down in OSC_ControlSurface class, add this:

    void SendOSCMessage(OSC_FeedbackProcessor* feedbackProcessor, string oscAddress, string value);
    
    virtual void RequestUpdate() override
    {
        ControlSurface::RequestUpdate();

        if (GetName().find("X32") != string::npos || GetName().find("x32") != string::npos)
            surfaceIO->SendX32HeartBeat();
    }
    
    virtual void HandleExternalInput() override
    {
        surfaceIO_->HandleExternalInput(this);
    }

[Geoff Waddington]

Originally Posted by MixMonkey

Take a look at what we're dealing with:



Regarding the encoder rings, it's expecting to receive (for rotary 1) Controller9 with a value between 1 and 13. A value of 0 turns all the LEDs off. A value of 27 turns them all on.

[Rant on]

Geeez, I wish these fools would use hex, I know you are tired of me beating this dead horse, but control surface protocol is not MIDI, it's not MIDI, it's not MIDI !!!

It's been hijacked to mean something completely different.

When is the last time Reaper played an A note when you hit Mute, I mean really, arrgh !!

[Rant off]

Anyway, meanwhile, back at the ranch, I will have a look at these hieroglyphs and see if we can make a special MIDI widget for this puppy.

[edit] Can someone post the .mst currently being used, so that I can change as little as possible to support this thing.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Doh, my bad, you need OSC context:

In control_surface_integrator.h

ControlSurface class:

change this

    void RequestUpdate();

to this:

    virtual void RequestUpdate();

then a bit further down in OSC_ControlSurface class, add this:

    void SendOSCMessage(OSC_FeedbackProcessor* feedbackProcessor, string oscAddress, string value);
    
    virtual void RequestUpdate() override
    {
        ControlSurface::RequestUpdate();

        if (GetName().find("X32") != string::npos || GetName().find("x32") != string::npos)
            surfaceIO->SendX32HeartBeat();
    }
    
    virtual void HandleExternalInput() override
    {
        surfaceIO_->HandleExternalInput(this);
    }

Compiles like a charm

Now to implement the body of "OSC_ControlSurfaceIO::SendX32Heartbeat()"

Stay tuned Will likely have it implemented and ready for merging later tonight

That will be the last baby step for X32.
I will then provide support files .ost,.zon for the X32 physicals that I have implement to date

My next step will be for FX

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Compiles like a charm

Now to implement the body of "OSC_ControlSurfaceIO::SendX32Heartbeat"

Yup, that should be a LOT less verbose, now that you have the correct context, no more sifting through lists.

[MixMonkey]

Originally Posted by Geoff Waddington

Anyway, meanwhile, back at the ranch, I will have a look at these hieroglyphs and see if we can make a special MIDI widget for this puppy.

[edit] Can someone post the .mst currently being used, so that I can change as little as possible to support this thing.

Could I suggest looking at the issue with the button indicators first? If this is insoluble because of hardware/firmware in the device, it's hardly worth going to the trouble of creating a feedback processor to fit the specific needs of the rotaries.

Also, although I only have an X-Touch Mini, I should point out that in native mode the button messgaes are somewhat unconventional. It would be sensible to check if the X-Touch Compact behaves similarly.

Perhaps @JP could take a look at the messages that are actually being sent by the buttons.

[Geoff Waddington]

Originally Posted by MixMonkey

Could I suggest looking at the issue with the button indicators first? If this is insoluble because of hardware/firmware in the device, it's hardly worth going to the trouble of creating a feedback processor to fit the specific needs of the rotaries.

Also, although I only have an X-Touch Mini, I should point out that in native mode the button messgaes are somewhat unconventional. It would be sensible to check if the X-Touch Compact behaves similarly.

Perhaps @JP could take a look at the messages that are actually being sent by the buttons.

Good idea, let's have a look at that first.

Is there any documentation available on the buttons ?

[MixMonkey]

Originally Posted by Geoff Waddington

Good idea, let's have a look at that first.

Is there any documentation available on the buttons ?

Not really. There's a diagram showing note numbers and the table I posted showing what it expects to receive to work the LEDs. That's why we need someone with the actual device to look at the messages.

We can't necessarily assume that it will behave in the same way as the Mini. For instance, in native mode the mini sends out 90 00 7f on press and 80 00 00 on release in momentary mode and the same messages on successive pushes in toggle mode. This makes the .mst a bit meaningless at this point

[jacksoonbrowne]

Hi Geoff,

Thanks so much for the BreadCrumbs you provided for encapsulation of the X32 HeartBeat

Below are the modifications I made for the X32 HeartBeat.
Tested with my X32 and working like a charm.

With your approval, this last baby should be ready to be merged into your source code.

Next I will put together X32 support files I have to date.

Then tackle X32 track unique select which I had put on hold, as it is UNIQUE to the X32
Then FX, followed by, Automation which some of my gray matter has ideas for




X32 HeartBeat modifications:

In: control_surface_integrater.h Add

class ControlSurface
{
public:
    ....
    virtual void RequestUpdate();
    ....

class OSC_ControlSurfaceIO
{
public:
    ....
    void SendX32HeartBeat();
    ....

class OSC_ControlSurface : public ControlSurface
{
    ....
    virtual void RequestUpdate() override
    {
        ControlSurface::RequestUpdate();

        if (GetName().find("X32") != string::npos || GetName().find("x32") != string::npos)
            surfaceIO_->SendX32HeartBeat();
    }
    ....

In: control_surface_integrater.cpp Add

void OSC_ControlSurfaceIO::SendX32HeartBeat()
{
    // X32 REQUIRES THE OSC MESSAGE "/xremote" BE SENT TO THE X32
    //    AT AN INTERVAL THAT MUST BE LESS THAN 10 SECONDS.
    // 5 SECONDS IS IDEAL AND IS HARD CODED HERE (NO NEED TO EVER CHANGE)

    const double X32HeartBeatRefreshInterval = 5000; // HeartBeat INTERVAL IN MILLISECONDS
    static double X32HeartBeatLastRefreshTime = 0;
    double currentTime = 0;

    // NOTHING TO DO UNTIL HeartBeat INTERVAL
    currentTime = DAW::GetCurrentNumberOfMilliseconds();
    if ((currentTime - X32HeartBeatLastRefreshTime) < X32HeartBeatRefreshInterval)
        return;

    // ARRIVED AT HeartBeat INTERVAL

    // RESET INTERVAL
    X32HeartBeatLastRefreshTime = currentTime;

    // SEND X32 HeartBeat
    oscpkt::Message msg_xremote("/xremote");
    oscpkt::PacketWriter pw;
    pw.init().addMessage(msg_xremote);
    outSocket_->sendPacket(pw.packetData(), pw.packetSize());
}

Cheers,
Roy

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

Thanks so much for the BreadCrumbs you provided for encapsulation of the X32 HeartBeat

Below are the modifications I made for the X32 HeartBeat.
Tested with my X32 and working like a charm.

With your approval, this last baby should be ready to be merged into your source code.

Next I will put together X32 support files I have to date.

Then tackle X32 track unique select which I had put on hold, as it is UNIQUE to the X32
Then FX, followed by, Automation which some of my gray matter has ideas for




X32 HeartBeat modifications:

In: control_surface_integrater.h Add

class ControlSurface
{
public:
    ....
    virtual void RequestUpdate();
    ....

class OSC_ControlSurfaceIO
{
public:
    ....
    void SendX32HeartBeat();
    ....

class OSC_ControlSurface : public ControlSurface
{
    ....
    virtual void RequestUpdate() override
    {
        ControlSurface::RequestUpdate();

        if (GetName().find("X32") != string::npos || GetName().find("x32") != string::npos)
            surfaceIO_->SendX32HeartBeat();
    }
    ....

In: control_surface_integrater.cpp Add

void OSC_ControlSurfaceIO::SendX32HeartBeat()
{
    // X32 REQUIRES THE OSC MESSAGE "/xremote" BE SENT TO THE X32
    //    AT AN INTERVAL THAT MUST BE LESS THAN 10 SECONDS.
    // 5 SECONDS IS IDEAL AND IS HARD CODED HERE (NO NEED TO EVER CHANGE)

    const double X32HeartBeatRefreshInterval = 5000; // HeartBeat INTERVAL IN MILLISECONDS
    static double X32HeartBeatLastRefreshTime = 0;
    double currentTime = 0;

    // NOTHING TO DO UNTIL HeartBeat INTERVAL
    currentTime = DAW::GetCurrentNumberOfMilliseconds();
    if ((currentTime - X32HeartBeatLastRefreshTime) < X32HeartBeatRefreshInterval)
        return;

    // ARRIVED AT HeartBeat INTERVAL

    // RESET INTERVAL
    X32HeartBeatLastRefreshTime = currentTime;

    // SEND X32 HeartBeat
    oscpkt::Message msg_xremote("/xremote");
    oscpkt::PacketWriter pw;
    pw.init().addMessage(msg_xremote);
    outSocket_->sendPacket(pw.packetData(), pw.packetSize());
}

Cheers,
Roy

Great work !!

I might make these instance variables:

    const double X32HeartBeatRefreshInterval = 5000; // HeartBeat INTERVAL IN MILLISECONDS
    static double X32HeartBeatLastRefreshTime = 0;

and maybe remove some of the comments.

I have a somewhat different view than most about comments:

If there is a comment:

// HeartBeat INTERVAL IN MILLISECONDS

and the code changes, the coder must also remember to change the comment.

I've seen this end badly far too many times in the last 35 years

I go with the guideline "Better no comment at all than a misleading one"

In this case the variable naming you used:

X32HeartBeatRefreshInterval

tells you it's a heartbeat.

The method used to get the time:

DAW::GetCurrentNumberOfMilliseconds()

tells you it's in milliseconds.

In my view the comment is unnecessary and only serves to clutter things.

I know it's a very different view than a lot of folks, but that is how CSI is coded and I want to keep things consistent.

No need to say the X32 needs a heartbeat, the very existence of the method tells you that

I'll put one comment after the 5000 // must be less than 10000.

[Geoff Waddington]

Here's what I'm talking about, to me this reads much better:

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_ControlSurfaceIO
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
private:
    string const name_ = "";
    oscpkt::UdpSocket* inSocket_ = nullptr;
    oscpkt::UdpSocket* outSocket_ = nullptr;
    oscpkt::PacketReader packetReader_;
    oscpkt::PacketWriter packetWriter_;
    const double X32HeartBeatRefreshInterval_ = 5000; // must be less than 10000
    double X32HeartBeatLastRefreshTime_ = 0.0;

    void SendX32HeartBeat()
    {
        double currentTime = DAW::GetCurrentNumberOfMilliseconds();

        if(currentTime - X32HeartBeatLastRefreshTime_ > X32HeartBeatRefreshInterval_)
        {
            X32HeartBeatLastRefreshTime_ = currentTime;
            
            oscpkt::Message heartbeatMessage;
            heartbeatMessage.init("/xremote");
            packetWriter_.init().addMessage(heartbeatMessage);
            outSocket_->sendPacket(packetWriter_.packetData(), packetWriter_.packetSize());
        }
    }