Control Surface Integration (CSI) Technical Feature Discussion

[Funkybot]

Originally Posted by Geoff Waddington

I still think the box is slightly too busy -- would vote for removing the Associated Zones description.

My thinking for keeping the AssociatedZones is: people will most likely be editing existing files, and if we show them a simplified version with IncludedZones only, they may panic and think "wait, my X-Touch zone doesn't look like that, it's got all this other stuff". Whereas, using color to highlight the included section, let's them break it down into smaller chunks. Like "ok, these included zones are different than the others". Would be open to the opinions of others.

Note: as I build out the AssociatedZones section, I could totally end up going back and redoing this and drop it anyway. I'm kind of feeling this all out.

[Funkybot]

Originally Posted by Geoff Waddington

Patrick, from controller manufacturer Asparion, Ok'd that I post this email content.

Interested in everyone's thoughts:

"Thanks for the reply. If you really wanna go that way without the menu I would at least always do an AutoMap. If it is not mapped, automatically create it. In our experience no one ever reads a manual. So no one will ever know that he has to press a button. And if its not intuitive people tend to think there is a problem and something it not working right. This will either lead to a support case or a bad review.

My preferred way of handling this would be: If there is no map, auto map it. And I would remove the SaveLearnedFXParams, and just auto save. Because no one can remember this button … and will think it is not working right because it is not saving. And also remove the EraseLastTouchedControl, because same thing …, just overwrite it.

Or even better: I like the remap window, but it could use some improvements. Make learn possible with a button in there. Automatically focus the last touched control and the last adjusted parameter and then connect both with the press of a button or automatically. This is also how e.g. Studio One or Cubase work."

So basically:

1. Automap automatically. I'm down with that. I've been a proponent of automap because of how well it works on small effects. Automation params usually either follow the GUI order or some logical hierarchy when it comes to small FX. It also simplifies for users and creates transparency.

2. Automatically save maps. Love it. Also, if you ultimately decide NOT to do this I can't help but think: we have the "Save" and "Cancel" buttons on MCU/X-Touch controllers. Why aren't those mapped to Save and Erase [respectively] in the Learn zone? But I digress.

3. Remap window adds the Learn functionality. The only thing I don't like about this is if an automap was created, it's going to be a pain to remap properly for large FX/instruments. I'd rather start from scratch.

Building on that, here's what I'd propose instead:

1. Add an option to "AutoMap" or "AutoLearn" - put this in the CSI Device Setup and CSI.ini so every user is presented with it on first setup. It's a surface-level preference (haven't thought this through with broadcast/listen yet).

2. If AutoMap, it works as indicated above.

3. If AutoLearn, and FocusedFX is on, you jump right into the LearnFocusedFX mode. No extra buttons to press to get there. The mapping works as indicated above: move param, move control, next. It should auto-save along the way. If FocusedFX is off, you would get to the LearnFocusedFX zone by activating the FX via "GoFXSlot" in a TrackFXMenu. Still auto-saves.

4. Remap window basically stays the same.

5. You could then have a GoAssociatedZone LearnFocusedFX button to "re-enter" Learn mode to finish what you started if you say, did half a map the first time or wanted to edit an Auto-Map. Wouldn't hate the idea of putting a button on the GUI of the Remap window to get there too.

[Freex]

I'd agree with most of that, seems like the logical approach.

May only thought, and I may have only picked it up wrong.

The AutoMap AutoLearn option, do we have a way to have "Auto" on or off?

I'm thinking the prompt box or dialog box can be annoying with you are just "trying out" an FX.

So maybe have an "Auto" On/Off
If On we're presented with the options, its no that difficult to click an option.
If Off no promts no boxes, no control.

[Funkybot]

Additional thought: if we get to where we've got a good list of included surfaces, the Remap window would ideally also be able to assign Reaper actions to the Buttons.zon. Most users wouldn't need to remap Track/Send/Receive controls or the Home zone in meaningful ways, but they may want to edit button assignments. Particularly where the stock files have NoActions.

The goal would be to get 90% users a great out-of-the-box experience where only us CSI old-timers really need to know the finer details of zone mapping.

Last, last thought before I go back to watching the Arsenal game then on to yard work...this would be a nice controller to integrate into CSI:

https://nektartech.com/panorama-cs12/

Maybe with CSI becoming more official, Nektar would be inclined to give you the details to get that working and/or a unit for you to develop with.

[Funkybot]

Originally Posted by Freex

I'd agree with most of that, seems like the logical approach.

May only thought, and I may have only picked it up wrong.

The AutoMap AutoLearn option, do we have a way to have "Auto" on or off?

I'm thinking the prompt box or dialog box can be annoying with you are just "trying out" an FX.

So maybe have an "Auto" On/Off
If On we're presented with the options, its no that difficult to click an option.
If Off no promts no boxes, no control.

Perhaps you could just GoHome and it would save a blank map. Just thinking out loud. Need to Learn later on, and use a Learn button.

I'm a big fan of keep it simple even if you lose some flexibility. Which I feel like MM would hate. But I'm trying to keep people away from having to visit the wiki as much as possible.

[Funkybot]

Or maybe have 3 options. Call the setting something like, "Default behavior when no FX map" then have a dropdown with options for:

1. Automap (default)
2. Autolearn
3. Do nothing (users would then have to know to enter the Learn zone or Automap manually)

Ok...back to sports now!

[Geoff Waddington]

Originally Posted by Funkybot

My thinking for keeping the AssociatedZones is: people will most likely be editing existing files, and if we show them a simplified version with IncludedZones only, they may panic and think "wait, my X-Touch zone doesn't look like that, it's got all this other stuff". Whereas, using color to highlight the included section, let's them break it down into smaller chunks. Like "ok, these included zones are different than the others". Would be open to the opinions of others.

Note: as I build out the AssociatedZones section, I could totally end up going back and redoing this and drop it anyway. I'm kind of feeling this all out.

I totally agree with what you are showing for the exact reasons you state.

I'm talking about the Associated Zone description in the lower left text box, I think it clutters the text with non applicable info.

[Geoff Waddington]

Great thoughts on Learn/Map section.

Was trying to avoid a plethora of options, but maybe that's what does make sense.

[Funkybot]

Originally Posted by Geoff Waddington

I totally agree with what you are showing for the exact reasons you state.

I'm talking about the Associated Zone description in the lower left text box, I think it clutters the text with non applicable info.

Ahh.. will remove that!

[Geoff Waddington]

Originally Posted by Funkybot

Ahh.. will remove that!

Lookin' good, lookin' good !

[ldhall1856]

Originally Posted by Geoff Waddington

Great news !!

Let's wait until they fix the firmware, then look at supporting colour.

Then you could go ahead and rename MCU.mst to Icon.mst and post it here, so that we can include it in the support files.

Hi all,

I just got a icon V1-M with 2 V1-X. I made a mst and zone file to reflect Geoff changes. And i downloaded the CSI exp. It kinda worked...

I'm using a 2022 M1 Max. and using the 7.14.

Basically it was so buggy, it wasn't useable. Reaper was running so slow. I couldn't page without it freezing the surface and software.

Could it have been that I used the same files for the V1-M and the V1-X?

I'm uploading the files.

On a positive note, the displays worked!

[jakeman19]

Originally Posted by ldhall1856

Hi all,

I just got a icon V1-M with 2 V1-X. I made a mst and zone file to reflect Geoff changes. And i downloaded the CSI exp. It kinda worked...

I'm using a 2022 M1 Max. and using the 7.14.

Basically it was so buggy, it wasn't useable. Reaper was running so slow. I couldn't page without it freezing the surface and software.

Could it have been that I used the same files for the V1-M and the V1-X?

I'm uploading the files.

On a positive note, the displays worked!

I'm curious, is the touchscreen function screen working like the F1-16 on an old MCU? Thanks for any insight you may provide?

Jd

[ldhall1856]

Originally Posted by ldhall1856

Hi all,

I just got a icon V1-M with 2 V1-X. I made a mst and zone file to reflect Geoff changes. And i downloaded the CSI exp. It kinda worked...

I'm using a 2022 M1 Max. and using the 7.14.

Basically it was so buggy, it wasn't useable. Reaper was running so slow. I couldn't page without it freezing the surface and software.

Could it have been that I used the same files for the V1-M and the V1-X?

I'm uploading the files.

On a positive note, the displays worked!

Giving a few more details, you the bank over. 85% of the time, the display stay the save but the fader changes.

[ldhall1856]

Originally Posted by jakeman19

I'm curious, is the touchscreen function screen working like the F1-16 on an old MCU? Thanks for any insight you may provide?

Jd

So iMap still works and i'm currently mapping all of those icons in the touch screen with that. but short answer, Yes it is functional.

[Geoff Waddington]

@jacksoonbrowne, pushed a commit that subclasses OSC_ControlSurfaceIO for the X32.

Let me know if it works, and I'll include it in the Exp build.

[Geoff Waddington]

"And also remove the EraseLastTouchedControl, because same thing …, just overwrite it."

That doesn't work if you just made a mistake and want to erase that mistake and not replace it.

Other than that:

I like the three choice dropdown:

1. Automap (default)
2. Autolearn
3. Do nothing (users would then have to know to enter the Learn zone or Automap manually)

Don't forget, we changed to Focused FX, so this thing can get ugly pretty quick, as you soon as you focus an FX the Action happens.

Therefore, I agree we need a per surface setting on the config panel.

As soon as you Learn or Erase a control, we could save immediately, so that's doable.

We'll leave ReMap for now, with an eye to upgrading it down the road.

We can leave all of the Actions except Save alone, so you can still map buttons to them.

Make sense ?

[Funkybot]

Makes sense to me!

[jacksoonbrowne]

Originally Posted by Geoff Waddington

@jacksoonbrowne, pushed a commit that subclasses OSC_ControlSurfaceIO for the X32.

Let me know if it works, and I'll include it in the Exp build.

Will start testing it right now

[jacksoonbrowne]

Originally Posted by Geoff Waddington

@jacksoonbrowne, pushed a commit that subclasses OSC_ControlSurfaceIO for the X32.

Let me know if it works, and I'll include it in the Exp build.

It works

I suggest that in the GUI when X32 is selected as the surface that you default:

    SURFACE
    -------
    rxPort     = 10023
    txPort     = 10023
    maxPackets = 16


    ASSIGNMENTS
    ------------------
    numChannels = 16

[Geoff Waddington]

Originally Posted by jacksoonbrowne

It works

I suggest that in the GUI when X32 is selected as the surface that you default:

    SURFACE
    -------
    rxPort     = 10023
    txPort     = 10023
    maxPackets = 16


    ASSIGNMENTS
    ------------------
    numChannels = 16

Excellent !!

Good idea for default values, will look into doing that nicety once the basics are all operational.

[Geoff Waddington]

I'm thinking we also want to add checkboxes for EnableFocusedFXMapping and EnableFocusedFXParamMapping to the gui, since most users don't know about the toggle Actions.

[MixMonkey]

Originally Posted by Geoff Waddington

Interested in everyone's thoughts:

"Thanks for the reply. If you really wanna go that way without the menu I would at least always do an AutoMap. If it is not mapped, automatically create it. In our experience no one ever reads a manual. So no one will ever know that he has to press a button. And if its not intuitive people tend to think there is a problem and something it not working right. This will either lead to a support case or a bad review.

Always creating a map when one doesn't exist will be fine for plugins with a small number of parameters, but will create a pointless mess for those with large parameter sets. There are some plugins that probably shouldn't be AutoMapped. Kontakt and Reaktor spring to mind.

Also, if AutoMapping is happening without any user intervention, how do you accomodate Learn? - the plugin will already have been mapped.

Putting a checkbox in the prefs for this seems like the best option - AutoMap focused plugin on/off.

I would remove the SaveLearnedFXParams, and just auto save. Because no one can remember this button … and will think it is not working right because it is not saving.

This will remove the ability to escape the Learn process without creating a map. Personally, I like the way the Save button lights up when I enter Learn mode, remembering to push it hasn't been a problem. Don't we have an on screen prompt that you're exiting without saving?

And also remove the EraseLastTouchedControl, because same thing …, just overwrite it.

This would be fine if you always wanted to overwrite one parameter with another but will remove the ability to leave a blank control.

I like the remap window, but it could use some improvements. Make learn possible with a button in there. Automatically focus the last touched control and the last adjusted parameter and then connect both with the press of a button or automatically. This is also how e.g. Studio One or Cubase work."

Learning directly from the ReMap window sounds interesting, but might be a coding nightmare. Is the ReMap window capable of updating immediately to live changes?

[TheFancyWolf]

Originally Posted by ldhall1856

Basically it was so buggy, it wasn't useable. Reaper was running so slow. I couldn't page without it freezing the surface and software.

I just wanted to mention I am not experiencing this on the P1-M/X. But it will definitely take a bit of effort to get it to function in a way that is usable with CSI.

I think DrivenByMoss is the way to go if you need to work immediately. I plan on doing a full "template" (not sure terminology) that I will share once we get the display sorted. I have grand plans...

[fourdogslong]

Personally, I would not want any plugins to be auto mapped unless I tell CSI otherwise.
There are some plugins that I do not want mapped at all intentionnaly, like meters for example, so I can have a meter focused and still be able to control my mixer.

[TheFancyWolf]

Lol, also the display bugs are in their promo pictures on their website. On the second/bottom display the offset is there. ^_^

https://iconproaudio.com/product/d4/

[Funkybot]

Originally Posted by fourdogslong

Personally, I would not want any plugins to be auto mapped unless I tell CSI otherwise.
There are some plugins that I do not want mapped at all intentionnaly, like meters for example, so I can have a meter focused and still be able to control my mixer.

The proposed approach will allow you to configure the default behavior for each surface between Auto Map, Auto Learn, and No Action at all, so you'll be covered. The latter approach will be the same as it is today where the user needs to take some action to engage the Learn or AutoMap process. The former two approaches will do something.

I think I'd set it to AutoLearn myself.

[Geoff Waddington]

Originally Posted by MixMonkey

This will remove the ability to escape the Learn process without creating a map. Personally, I like the way the Save button lights up when I enter Learn mode, remembering to push it hasn't been a problem. Don't we have an on screen prompt that you're exiting without saving?

I agree with you, but I think folks that think like us are a shrinking group

Most everything I use nowadays saves automatically, whether it's my Mac desktop, iPad, or iPhone.

However, maybe a viable solution is to simply go into ReMap and remove the Zone if you don't want it.

Originally Posted by MixMonkey

This would be fine if you always wanted to overwrite one parameter with another but will remove the ability to leave a blank control.

Yup.

As above, if you have finally mapped everything, and still have an unwanted param mapped, it's time for a visit to ReMap to erase the param, just like you remove the Zone in the Save scenario above.

The nice thing that happens for surfaces with small button counts is the elimination of the need for Save and Erase buttons.

Originally Posted by MixMonkey

Learning directly from the ReMap window sounds interesting, but might be a coding nightmare. Is the ReMap window capable of updating immediately to live changes?

Yeah, that's future feature stuff, but definitely interesting.

[Geoff Waddington]

Haha, sometimes stepping away and returning does wonders

Just re read the last post.

Seems all roads lead to the Remap window

I'll look into that approach.

It takes care of all of the Save/Cancel/Remove operations without using any surface buttons.

Ironically, it's closely related to the old old mapper we tried to build way back when

[MixMonkey]

Originally Posted by Geoff Waddington

However, maybe a viable solution is to simply go into ReMap and remove the Zone if you don't want it.

Actually, reconsidering the save/erase question, getting rid of the two buttons needed and using the ReMap window instead to delete the map/mapping is preferable. It's simpler and concentrates map editing/deletion in one place (the ReMap window).

Also, Learn becomes faster if you can overwrite one mapping with another, instead of having to delete the existing mapping first.

[Geoff Waddington]

Originally Posted by MixMonkey

Actually, reconsidering the save/erase question, getting rid of the two buttons needed and using the ReMap window instead to delete the map/mapping is preferable. It's simpler and concentrates map editing/deletion in one place (the ReMap window).

Also, Learn becomes faster if you can overwrite one mapping with another, instead of having to delete the existing mapping first.

Yup, and the option quagmire is sorted too

If you have EnableFocusedFXMapping on (the default), and there is no Zone definition, the ReMap window appears in Learn mode, ready to go.

Buttons at the bottom for AutoMap, EraseLastTouched, RemoveZone, Save, and Cancel, done.

[jacksoonbrowne]

Hi Geoff,

I just tested out the latest commit for the and so far it seems it's working except for colors on the X32.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

I just tested out the latest commit for the and so far it seems it's working except for colors on the X32.

Are you using FB_X32Processor and FB_X32IntProcessor ?

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Are you using FB_X32Processor and FB_X32IntProcessor ?

Yes, I modified mt .ost file with those

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Yes, I modified mt .ost file with those

Ok, obviously I can't debug the X32 from here.

Can you see where I went wrong converting the code to use subclasses ?

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Ok, obviously I can't debug the X32 from here.

Can you see where I went wrong converting the code to use subclasses ?

I am currently debugging, and so far I can see in wireshark trace that the color packet being sent is wrong.

The packet should be
"/ch/01/config/color" with an int value

But what the trace shows me is
"/-stat/selidx/01/Color" with a string value such as "#0000ffff"

I believe I can find the issue and make a fix.

Stay tuned

[jacksoonbrowne]

I set breakpoints in both

1 - "OSC_FeedbackProcessor::SetColorValue(const rgba_color &color)"
2 - "OSC_X32FeedbackProcessor::SetColorValue(const rgba_color &color)"

It breaks in 1

[jacksoonbrowne]

virtual void SetColorValue(const rgba_color &color) override;

Is in

class OSC_X32FeedbackProcessor : public OSC_FeedbackProcessor

It also be should be in

class OSC_X32IntFeedbackProcessor : public OSC_IntFeedbackProcessor

[Geoff Waddington]

Originally Posted by jacksoonbrowne

virtual void SetColorValue(const rgba_color &color) override;

Is in

class OSC_X32FeedbackProcessor : public OSC_FeedbackProcessor

It also be should be in

class OSC_X32IntFeedbackProcessor : public OSC_IntFeedbackProcessor

Thanks for the sleuthing !!

When you have it working could you please post the changes here, and I will include them in the next build.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Thanks for the sleuthing !!

When you have it working could you please post the changes here, and I will include them in the next build.

Got it fixed

Here's my change:

int  X32GetColorValue(const rgba_color &color)
{
    int surfaceColor = 0;
    int r = color.r;
    int g = color.g;
	int b = color.b;

    if      (r == 64 && g == 64 && b == 64)                          surfaceColor = 8;    // BLACK
    else if (r > g && r > b)                                         surfaceColor = 1;    // RED
    else if (g > r && g > b)                                         surfaceColor = 2;    // GREEN
    else if (abs(r - g) < 30 && r > b && g > b)                      surfaceColor = 3;    // YELLOW
    else if (b > r && b > g)                                         surfaceColor = 4;    // BLUE
    else if (abs(r - b) < 30 && r > g && b > g)                      surfaceColor = 5;    // MAGENTA
    else if (abs(g - b) < 30 && g > r && b > r)                      surfaceColor = 6;    // CYAN
    else if (abs(r - g) < 30 && abs(r - b) < 30 && abs(g - b) < 30)  surfaceColor = 7;    // WHITE
	
    return surfaceColor;
}

void OSC_X32IntFeedbackProcessor::SetColorValue(const rgba_color &color)
{
    if (lastColor_ != color)
    {
        lastColor_ = color;

        int surfaceColor = X32GetColorValue(color);

        string oscAddress = "/ch/";
        if (widget_->GetChannelNumber() < 10)   oscAddress += '0';
        oscAddress += int_to_string(widget_->GetChannelNumber()) + "/config/color";
        surface_->SendOSCMessage(this, oscAddress.c_str(), surfaceColor);
	}
}

void OSC_X32FeedbackProcessor::SetColorValue(const rgba_color &color)
{
    if (lastColor_ != color)
    {
        lastColor_ = color;

        int surfaceColor = X32GetColorValue(color);

        string oscAddress = "/ch/";
        if (widget_->GetChannelNumber() < 10)   oscAddress += '0';
        oscAddress += int_to_string(widget_->GetChannelNumber()) + "/config/color";
        surface_->SendOSCMessage(this, oscAddress.c_str(), surfaceColor);
	}
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_X32IntFeedbackProcessor : public OSC_IntFeedbackProcessor
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
public:
    OSC_X32IntFeedbackProcessor(CSurfIntegrator *const csi, OSC_ControlSurface *surface, Widget *widget, const char *oscAddress) : OSC_IntFeedbackProcessor(csi, surface, widget, oscAddress) {}
    ~OSC_X32IntFeedbackProcessor() {}

    virtual const char *GetName() override { return "OSC_X32IntFeedbackProcessor"; }

    virtual void SetColorValue(const rgba_color &color) override;
    virtual void ForceValue(const PropertyList &properties, double value) override;
};

I still have a few issues left to resolve, so don,t add it yet

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Got it fixed

Here's my change:

int  X32GetColorValue(const rgba_color &color)
{
    int surfaceColor = 0;
    int r = color.r;
    int g = color.g;
	int b = color.b;

    if      (r == 64 && g == 64 && b == 64)                          surfaceColor = 8;    // BLACK
    else if (r > g && r > b)                                         surfaceColor = 1;    // RED
    else if (g > r && g > b)                                         surfaceColor = 2;    // GREEN
    else if (abs(r - g) < 30 && r > b && g > b)                      surfaceColor = 3;    // YELLOW
    else if (b > r && b > g)                                         surfaceColor = 4;    // BLUE
    else if (abs(r - b) < 30 && r > g && b > g)                      surfaceColor = 5;    // MAGENTA
    else if (abs(g - b) < 30 && g > r && b > r)                      surfaceColor = 6;    // CYAN
    else if (abs(r - g) < 30 && abs(r - b) < 30 && abs(g - b) < 30)  surfaceColor = 7;    // WHITE
	
    return surfaceColor;
}

void OSC_X32IntFeedbackProcessor::SetColorValue(const rgba_color &color)
{
    if (lastColor_ != color)
    {
        lastColor_ = color;

        int surfaceColor = X32GetColorValue(color);

        string oscAddress = "/ch/";
        if (widget_->GetChannelNumber() < 10)   oscAddress += '0';
        oscAddress += int_to_string(widget_->GetChannelNumber()) + "/config/color";
        surface_->SendOSCMessage(this, oscAddress.c_str(), surfaceColor);
	}
}

void OSC_X32FeedbackProcessor::SetColorValue(const rgba_color &color)
{
    if (lastColor_ != color)
    {
        lastColor_ = color;

        int surfaceColor = X32GetColorValue(color);

        string oscAddress = "/ch/";
        if (widget_->GetChannelNumber() < 10)   oscAddress += '0';
        oscAddress += int_to_string(widget_->GetChannelNumber()) + "/config/color";
        surface_->SendOSCMessage(this, oscAddress.c_str(), surfaceColor);
	}
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_X32IntFeedbackProcessor : public OSC_IntFeedbackProcessor
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
public:
    OSC_X32IntFeedbackProcessor(CSurfIntegrator *const csi, OSC_ControlSurface *surface, Widget *widget, const char *oscAddress) : OSC_IntFeedbackProcessor(csi, surface, widget, oscAddress) {}
    ~OSC_X32IntFeedbackProcessor() {}

    virtual const char *GetName() override { return "OSC_X32IntFeedbackProcessor"; }

    virtual void SetColorValue(const rgba_color &color) override;
    virtual void ForceValue(const PropertyList &properties, double value) override;
};

I still have a few issues left to resolve, so don,t add it yet

Cool, going to do it a bit differently.

Seems strange to have the standalone function int X32GetColorValue(const rgba_color &color) that replaces some of the repeated code, but then in each of the overrides there is this repeated code:

       lastColor_ = color;

        int surfaceColor = X32GetColorValue(color);

        string oscAddress = "/ch/";
        if (widget_->GetChannelNumber() < 10)   oscAddress += '0';
        oscAddress += int_to_string(widget_->GetChannelNumber()) + "/config/color";
        surface_->SendOSCMessage(this, oscAddress.c_str(), surfaceColor);

No perfect answer here, but I prefer to see all of the code repeated and encapsulated in X32 classes, rather than having it spread out amongst class methods and standalone functions.

void OSC_X32FeedbackProcessor::SetColorValue(const rgba_color &color)
{
    if (lastColor_ != color)
    {
        lastColor_ = color;

        
        int surfaceColor = 0;
        int r = color.r;
        int g = color.g;
        int b = color.b;
        
        if (r == 64 && g == 64 && b == 64)                               surfaceColor = 8;    // BLACK
        else if (r > g && r > b)                                         surfaceColor = 1;    // RED
        else if (g > r && g > b)                                         surfaceColor = 2;    // GREEN
        else if (abs(r - g) < 30 && r > b && g > b)                      surfaceColor = 3;    // YELLOW
        else if (b > r && b > g)                                         surfaceColor = 4;    // BLUE
        else if (abs(r - b) < 30 && r > g && b > g)                      surfaceColor = 5;    // MAGENTA
        else if (abs(g - b) < 30 && g > r && b > r)                      surfaceColor = 6;    // CYAN
        else if (abs(r - g) < 30 && abs(r - b) < 30 && abs(g - b) < 30)  surfaceColor = 7;    // WHITE
        
        string oscAddress = "/ch/";
        if (widget_->GetChannelNumber() < 10)   oscAddress += '0';
        oscAddress += int_to_string(widget_->GetChannelNumber()) + "/config/color";
        surface_->SendOSCMessage(this, oscAddress.c_str(), surfaceColor);
    }
}

void OSC_X32IntFeedbackProcessor::SetColorValue(const rgba_color &color)
{
    if (lastColor_ != color)
    {
        lastColor_ = color;

        
        int surfaceColor = 0;
        int r = color.r;
        int g = color.g;
        int b = color.b;
        
        if (r == 64 && g == 64 && b == 64)                               surfaceColor = 8;    // BLACK
        else if (r > g && r > b)                                         surfaceColor = 1;    // RED
        else if (g > r && g > b)                                         surfaceColor = 2;    // GREEN
        else if (abs(r - g) < 30 && r > b && g > b)                      surfaceColor = 3;    // YELLOW
        else if (b > r && b > g)                                         surfaceColor = 4;    // BLUE
        else if (abs(r - b) < 30 && r > g && b > g)                      surfaceColor = 5;    // MAGENTA
        else if (abs(g - b) < 30 && g > r && b > r)                      surfaceColor = 6;    // CYAN
        else if (abs(r - g) < 30 && abs(r - b) < 30 && abs(g - b) < 30)  surfaceColor = 7;    // WHITE
        
        string oscAddress = "/ch/";
        if (widget_->GetChannelNumber() < 10)   oscAddress += '0';
        oscAddress += int_to_string(widget_->GetChannelNumber()) + "/config/color";
        surface_->SendOSCMessage(this, oscAddress.c_str(), surfaceColor);
    }
}

The other alternative would be to put it all in a standalone function, dunno, what do you think ?