Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Some may recall the drag and drop code for the ReMap window was fairly tricky.

In fact, there is separate code for Mac and Windows, PITA.

With the new approach, do we even need drag and drop anymore ?

[jacksoonbrowne]

Originally Posted by Geoff Waddington

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 ?

What ever you would prefer.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

What ever you would prefer.

Yeah, it's a close call, but the standalone function would have to be passed the surface, widget, feedbackProcessor, and colour, so I think the duplicated encapsulated code is slightly better, as it will likely never change, so maintenance isn't really an issue.

[Funkybot]

Originally Posted by Geoff Waddington

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.

I'm thinking about how this will play out and I'm not sure I love the idea of another window popping up on screen with focused FX mapping on. The windows popping up can get annoying in use. We already had a similar pop up window and nixed it.

I think it's better to have the surface in learn mode or AutoMap mode myself. That will be less intrusive and put the users in control. If AutoMap mode, the FX just maps. No action necessary. If Learn Mode you can Learn or do nothing. But on screen windows popping up can be peevish. I would say keep it as a "remap" for remapping things after the fact.

Also, how would this system work with GoFxSlot+NoMap? Same deal? Again, I would rather the surface do something and AutoMap or jump into Learn mode than an on screen pop-up window.

Just my two cents. I'm open to being wrong on this but I feel like we tried this already and nixed it for similar reasons.

[Geoff Waddington]

Originally Posted by Funkybot

I'm thinking about how this will play out and I'm not sure I love the idea of another window popping up on screen with focused FX mapping on. The windows popping up can get annoying in use. We already had a similar pop up window and nixed it.

I think it's better to have the surface in learn mode or AutoMap mode myself. That will be less intrusive and put the users in control. If AutoMap mode, the FX just maps. No action necessary. If Learn Mode you can Learn or do nothing. But on screen windows popping up can be peevish. I would say keep it as a "remap" for remapping things after the fact.

Also, how would this system work with GoFxSlot+NoMap? Same deal? Again, I would rather the surface do something and AutoMap or jump into Learn mode than an on screen pop-up window.

Just my two cents. I'm open to being wrong on this but I feel like we tried this already and nixed it for similar reasons.

Good points all !

The thinking is that if you have Focused FX mapping on and there is no map, you would like to map it, so the window only opens if there is a no map.

Same for GoFXSlot.

Another benefit is for surfaces with low, or even nonexistent button counts, like an extender.

The jury is definitely still out on all of this...

[edit] One thing important to note -- in this new approach the Remap window is Learn mode.

[jacksoonbrowne]

Found a problem with Shutdown() when OSC messages per slice is active (message queueing active).
This is not X32 specific.

void Shutdown()
{
    // We want to stop polling
    shouldRun_ = false;
        
    // Zero out all Widgets before shutting down
    if (pages_.Get(currentPageIndex_))
        pages_.Get(currentPageIndex_)->ForceClear();
}

Because OSC message queueing is on, the ForceClear() will cause immediate queueing of all shutdown messages.

And then Shutdown() returns and Reaper exits before all queued messages have been sent.

What we need is a way to ensure all queued message have been flushed out before Shutdown() returns.

Something like this

void Shutdown()
{
    // We want to stop polling
    shouldRun_ = false;
        
    // Zero out all Widgets before shutting down
    if (pages_.Get(currentPageIndex_))
        pages_.Get(currentPageIndex_)->ForceClear();

    // PSUEDO CODE HERE
    FOR each OSC surface
    {
        IF queue NOT empty
            SLEEP(100)
    }
}

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Found a problem with Shutdown() when OSC messages per slice is active (message queueing active).
This is not X32 specific.

void Shutdown()
{
    // We want to stop polling
    shouldRun_ = false;
        
    // Zero out all Widgets before shutting down
    if (pages_.Get(currentPageIndex_))
        pages_.Get(currentPageIndex_)->ForceClear();
}

Because OSC message queueing is on, the ForceClear() will cause immediate queueing of all shutdown messages.

And then Shutdown() returns and Reaper exits before all queued messages have been sent.

What we need is a way to ensure all queued message have been flushed out before Shutdown() returns.

Something like this

void Shutdown()
{
    // We want to stop polling
    shouldRun_ = false;
        
    // Zero out all Widgets before shutting down
    if (pages_.Get(currentPageIndex_))
        pages_.Get(currentPageIndex_)->ForceClear();

    // PSUEDO CODE HERE
    FOR each OSC surface
    {
        IF queue NOT empty
            SLEEP(100)
    }
}

Nice catch !!

Will look into it.

[Geoff Waddington]

Does this flush the queue properly ?

    void Shutdown()
    {
        // GAW -- IMPORTANT
        
        // We want to stop polling
        shouldRun_ = false;
        
        // Zero out all Widgets before shutting down
        if (pages_.Get(currentPageIndex_))
        {
            pages_.Get(currentPageIndex_)->ForceClear();
            pages_.Get(currentPageIndex_)->Run(); // To flush queues
        }
    }

[Geoff Waddington]

Hmmm...

Wondering what it would be like if we reversed the Learn workflow.

Focus an FX for which there is no map
Learn Window (Remap) appears
Move a surface control
That control is selected in the Learn Window
Move a gui FX control with the mouse
They are linked

What say you ?

[Funkybot]

Originally Posted by Geoff Waddington

Hmmm...

Wondering what it would be like if we reversed the Learn workflow.

Focus an FX for which there is no map
Learn Window (Remap) appears
Move a control
That control is selected in the Learn Window
Move a gui FX control with the mouse
They are linked

What say you ?

What does that look like on screen? You wouldn't want users having to scroll through a long list of plugin parameters to find what Fader1 is mapped to. Some plugins have hundreds of parameters. Workflow wise it sounds good with my prior concerns about pop up screens remaining.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Does this flush the queue properly ?

    void Shutdown()
    {
        // GAW -- IMPORTANT
        
        // We want to stop polling
        shouldRun_ = false;
        
        // Zero out all Widgets before shutting down
        if (pages_.Get(currentPageIndex_))
        {
            pages_.Get(currentPageIndex_)->ForceClear();
            pages_.Get(currentPageIndex_)->Run(); // To flush queues
        }
    }

Nope.

I have my Messages Per run set to 16 and when there are more than 16 messages queued, for example 54,
"pages_.Get(currentPageIndex_)->Run();" will only flush 16 messages

Seems we need a way to do multiple Run()'s if the queue is not empty.

Maye something like this:

    void Shutdown()
    {
        // GAW -- IMPORTANT
        
        // We want to stop polling
        shouldRun_ = false;
        
        // Zero out all Widgets before shutting down
        if (pages_.Get(currentPageIndex_))
        {
            pages_.Get(currentPageIndex_)->ForceClear();
            
            // PSUEDO CODE
            WHILE queue IS NOT EMPTY
                pages_.Get(currentPageIndex_)->Run(); // To flush queues
        }
    }