Behringer X32 DAW Controller with Reaper

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Doh, too early in the morning for me

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_FeedbackProcessor : public FeedbackProcessor
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
protected:
    OSC_ControlSurface* const surface_ = nullptr;
    string oscAddress_ = "";
    
public:
    
    OSC_FeedbackProcessor(OSC_ControlSurface* surface, Widget* widget, string oscAddress) : FeedbackProcessor(widget), surface_(surface), oscAddress_(oscAddress) {}
    ~OSC_FeedbackProcessor() {}

    virtual void SetRGBValue(int r, int g, int b) override;
    virtual void ForceValue(double value) override;
    virtual void ForceValue(int param, double value) override;
    virtual void ForceValue(string value) override;
};

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_IntFeedbackProcessor : public OSC_FeedbackProcessor
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
protected:
    OSC_ControlSurface* const surface_ = nullptr;
    string oscAddress_ = "";

public:
    OSC_IntFeedbackProcessor(OSC_ControlSurface* surface, Widget* widget, string oscAddress) : OSC_FeedbackProcessor(surface, widget, oscAddress) {}
    ~OSC_IntFeedbackProcessor() {}

    virtual void ForceValue(double value) override;
    virtual void ForceValue(int param, double value) override;

Note to self -- if you actually plan on using the superclass vars, it's a real good idea not to override them

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_FeedbackProcessor : public FeedbackProcessor
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
protected:
    OSC_ControlSurface* const surface_ = nullptr;
    string oscAddress_ = "";
    
public:
    
    OSC_FeedbackProcessor(OSC_ControlSurface* surface, Widget* widget, string oscAddress) : FeedbackProcessor(widget), surface_(surface), oscAddress_(oscAddress) {}
    ~OSC_FeedbackProcessor() {}

    virtual void SetRGBValue(int r, int g, int b) override;
    virtual void ForceValue(double value) override;
    virtual void ForceValue(int param, double value) override;
    virtual void ForceValue(string value) override;
};

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_IntFeedbackProcessor : public OSC_FeedbackProcessor
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{

/*
protected:
    OSC_ControlSurface* const surface_ = nullptr;
    string oscAddress_ = "";
*/

public:
    OSC_IntFeedbackProcessor(OSC_ControlSurface* surface, Widget* widget, string oscAddress) : OSC_FeedbackProcessor(surface, widget, oscAddress) {}
    ~OSC_IntFeedbackProcessor() {}

    virtual void ForceValue(double value) override;
    virtual void ForceValue(int param, double value) override;

That works

[jacksoonbrowne]

New issue.

Whenever reaper/csi starts up, it sends a ForceClear() with a value of 0.

virtual void ForceClear()
{
    ForceValue(0.0);
    ForceValue(0, 0.0);
    ForceValue("");
    ForceRGBValue(0, 0, 0);
}

This causes all my X32 and reaper channel mutes to turn "On" when reaper.exe starts

Widget Mute1
    Control      	/ch/01/mix/on
    FB_Processor 	/ch/01/mix/on
WidgetEnd

Then I must manual turn off the mutes so as to to cause "InvertFB+Mute| TrackMute" to happen.

Zone "Channel"
    TrackNavigator	
    ....
    InvertFB+Mute|	TrackMute
    ....
ZoneEnd

Am I missing something here?
Should ForceClear() respect InvertFB+Mute| TrackMute?

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Should ForceClear() respect InvertFB+Mute| TrackMute?

Yup, have a look at fixing it, I call that a bug.

ActionContext is likely where all this happens -- it's one ugly mofo class that one

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Yup, have a look at fixing it, I call that a bug.

ActionContext is likely where all this happens -- it's one ugly mofo class that one

In these functions, what would I need to test to know if I need to invert the "value"?

void OSC_IntFeedbackProcessor::ForceValue(double value)
{
    lastDoubleValue_ = value;
    surface_->SendOSCMessage(this, oscAddress_, (int)value);
}

void OSC_IntFeedbackProcessor::ForceValue(int param, double value)
{
    lastDoubleValue_ = value;
    surface_->SendOSCMessage(this, oscAddress_, (int)value);
}

[Geoff Waddington]

Originally Posted by jacksoonbrowne

In these functions, what would I need to test to know if I need to invert the "value"?

void OSC_IntFeedbackProcessor::ForceValue(double value)
{
    lastDoubleValue_ = value;
    surface_->SendOSCMessage(this, oscAddress_, (int)value);
}

void OSC_IntFeedbackProcessor::ForceValue(int param, double value)
{
    lastDoubleValue_ = value;
    surface_->SendOSCMessage(this, oscAddress_, (int)value);
}

Nope, catch it a bit earlier.

If you trace back to ActionContext, that's where the isFeedbackInverted_ lives.

So there will be a method that eventually calls OSC_IntFeedbackProcessor::ForceValue via the Widget and maybe other various indirections

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Nope, catch it a bit earlier.

If you trace back to ActionContext, that's where the isFeedbackInverted_ lives.

So there will be a method that eventually calls OSC_IntFeedbackProcessor::ForceValue via the Widget and maybe other various indirections

Bin trying to track that through the VS2019 debugger, but can't figure it out.

Any more help would be so helpful ... Please, Please

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Bin trying to track that through the VS2019 debugger, but can't figure it out.

Any more help would be so helpful ... Please, Please

Thanks for finding this bug, it's a bit of a fix, but here it is -- I think

Just make the existing look like this:

void ActionContext::ClearWidget()
{
    double value = isFeedbackInverted_ == false ? value : 1.0 - value;

    widget_->Clear(value);
}


void  Widget::Clear(double value)
{
    for(auto processor : feedbackProcessors_)
        processor->Clear(value);
}



in FeedbackProcessor in the h file

    virtual void Clear(double value)
    {
        SetValue(value);
        SetValue(0, value);
        SetValue("");
        SetRGBValue(0, 0, 0);
    }
    
    virtual void ForceClear(double value)
    {
        ForceValue(value);
        ForceValue(0, value);
        ForceValue("");
        ForceRGBValue(0, 0, 0);
    }

I didn't show the whole trail for ForceClear(), but you get the idea.

Try it and let me know.

[Geoff Waddington]

Was just playing around with this, it's a big can of worms.

I would suggest you live with the Mute problem until I can provide a proper fix...

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Was just playing around with this, it's a big can of worms.

I would suggest you live with the Mute problem until I can provide a proper fix...

Cool, that sounds good as I was having compile issues with the suggestion

[jacksoonbrowne]

I have another issue, but it can wait until after you get the MUTE stuff figured out.

When I move a fader on the Reaper GUI, CSI will move the fader on the x32, that's good.

When I move a fader on the X32, CSI will move the fader in the reaper GUI, that's good, but then the FB_Processor for the fader sends a message to the X32, causing a "boxing match".

IE: moving the x32 fader feels like it's fighting you.

Not an issue right now, but something I feel needs to addressed at sometime, unless it is already addressed and I have an ost issue.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Cool, that sounds good as I was having compile issues with the suggestion

Yeah, it's a fundamental design flaw.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

I have another issue, but it can wait until after you get the MUTE stuff figured out.

When I move a fader on the Reaper GUI, CSI will move the fader on the x32, that's good.

When I move a fader on the X32, CSI will move the fader in the reaper GUI, that's good, but then the FB_Processor for the fader sends a message to the X32, causing a "boxing match".

IE: moving the x32 fader feels like it's fighting you.

Not an issue right now, but something I feel needs to addressed at sometime, unless it is already addressed and I have an ost issue.

This often cleans up when you add touch to your widget, but not sure, this is the first motorized OSC use case

[Geoff Waddington]

Thanks for you effort, it has opened my eyes to a way out of an ongoing battle with Surfaces/Widgets/Zones.

However it means that CSI will undergo a compete re-arch and implementation.

So nice to be involved in a non commercial project where you can just decide to start again, with no opposition from anyone

Most of this should skirt around what you are doing, just giving you a heads up.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

This often cleans up when you add touch to your widget, but not sure, this is the first motorized OSC use case

Not sure that "touch" will work,

The X32 doesn't send any messages when a fader is touched, only when it it is moved.

In the mean time, i will live with the "boxing match"

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Not sure that "touch" will work,

The X32 doesn't send any messages when a fader is touched, only when it it is moved.

In the mean time, i will live with the "boxing match"

You're kidding !!!! -- that's amazing, even the old eMagic Logic (predecessor to the MCU) from around 2000 had touch -- I had one for years !

How the hell do they expect you to use it for automation ? !!!

You think you have a boxing match now, just wait !!!!!

Are you triple sure ?

If true, that would make me personally think seriously about dropping the project...

Well, OK, maybe a bit hyperbolic , but geeez, really ?

Seems impossible.

[EcBaPr]

X32 doesnt have touch because it's primarily designed as a live console.. I recall conversations on gearslutz with Behringer staff before it was even released over 10 years ago and people were already asking for more control surface feature back then which they pretty much said wouldnt happen.. adapting the use is cool though where possible..

[Geoff Waddington]

Originally Posted by EcBaPr

X32 doesnt have touch because it's primarily designed as a live console.. I recall conversations on gearslutz with Behringer staff before it was even released over 10 years ago and people were already asking for more control surface feature back then which they pretty much said wouldnt happen.. adapting the use is cool though where possible..

Wow, I can't believe I'm saying this , they should have listened to the folks on Gearslutz

[jacksoonbrowne]

You're kidding !!!! -- that's amazing, even the old eMagic Logic (predecessor to the MCU) from around 2000 had touch -- I had one for years !

How the hell do they expect you to use it for automation ? !!!

You think you have a boxing match now, just wait !!!!!

Are you triple sure ?

If true, that would make me personally think seriously about dropping the project...

Well, OK, maybe a bit hyperbolic , but geeez, really ?

Seems impossible.

About a year ago I was working on an X32 oscci-bot script and ran into the "boxing Match" issue.

I was able to resolve it by modifying my script.

I will revisit the script and let you know how I accomplished it.
That may give you some ideas

Cheers,
Roy

[Geoff Waddington]

Originally Posted by jacksoonbrowne

About a year ago I was working on an X32 oscci-bot script and ran into the "boxing Match" issue.

I was able to resolve it by modifying my script.

I will revisit the script and let you know how I accomplished it.
That may give you some ideas

Cheers,
Roy

Cool, hope you know I was kidding a bit there -- while I do believe that's an important omission, I also believe we can get the rest of the stuff working well

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Cool, hope you know I was kidding a bit there -- while I do believe that's an important omission, I also believe we can get the rest of the stuff working well

No worries Geoff,
I knew you were kidding

Apart from the X32 not supporting Touch, I firmly believe we can get almost everything else functional.

[jacksoonbrowne]

Hi Geoff,

RE: X32 fader boxing match.

Currently:
When the X32 sends a fader message to CSI, CSI updates the reaper gui, and then invokes FB_Processor with the same OSC message back to the X32.

This is what causes the boxing match.

Leaving out FB_Pocessor prevents reaper fader movements from being sent to the X32, so no boxing match

I think what we need is a way to tell CSI, not to use feedback and still send its fader movements to the X32

Thinking out loud here, what do u think.

Widget Fader1 
    ControlSurface    /ch/01/mix/fader
    FB_Processor      None
    ReaperGui         /ch/01/mix/fader
WidgetEnd

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

RE: X32 fader boxing match.

Currently:
When the X32 sends a fader message to CSI, CSI updates the reaper gui, and then invokes FB_Processor with the same OSC message back to the X32.

This is what causes the boxing match.

Leaving out FB_Pocessor prevents reaper fader movements from being sent to the X32, so no boxing match

I think what we need is a way to tell CSI, not to use feedback and still send its fader movements to the X32

Thinking out loud here, what do u think.

Widget Fader1 
    ControlSurface    /ch/01/mix/fader
    FB_Processor      None
    ReaperGui         /ch/01/mix/fader
WidgetEnd

Here is the problem.

It's not hard to tell Reaper to stop sending feedback when it sees incoming messages from the surface.

However, on the back end there is an inherent latency issue.

Since there is no "Touch Release", Reaper must guess at when to again start sending feedback.

There is a soft takeover volume class in Actions -- have a look.

Reaper has some settings/checkboxes somewhere regarding this soft takeover release stuff too...

[jacksoonbrowne]

Hi Geoff,

Testing on the X32 is progressing well.

Widget Fader		works  (with known boxing match when moving fader on X32)
Widget Pan		works
Widget Mute		works
Widget Solo		works
Widget Scribble         works
Widget Select		not working correctly

But I am having an issue with track selection.

It appears that when I select a track in reaper,
CSI only sends a value of 0 or 1 to the X32 not the actual track number I selected.
/-stat/selidx, value= 0
/-stat/selidx, value= 1


And when I select a track on the X32 the message sent to CSI is valid, but CSI doesn’t appear to select the reaper track.
Selecting track 6 on the X32 sends: /-stat/selidx, value= 6

Widget Select1
	Control /-stat/selidx
	FB_IntProcessor /-stat/selidx
WidgetEnd

Zone "Channel"
	TrackNavigator	
	Select| TrackUniqueSelect 
ZoneEnd

Any ideas?

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

Testing on the X32 is progressing well.

Widget Fader		works  (with known boxing match when moving fader on X32)
Widget Pan		works
Widget Mute		works
Widget Solo		works
Widget Scribble         works
Widget Select		not working correctly

But I am having an issue with track selection.

It appears that when I select a track in reaper,
CSI only sends a value of 0 or 1 to the X32 not the actual track number I selected.
/-stat/selidx, value= 0
/-stat/selidx, value= 1


And when I select a track on the X32 the message sent to CSI is valid, but CSI doesn’t appear to select the reaper track.
Selecting track 6 on the X32 sends: /-stat/selidx, value= 6

Widget Select1
	Control /-stat/selidx
	FB_IntProcessor /-stat/selidx
WidgetEnd

Zone "Channel"
	TrackNavigator	
	Select| TrackUniqueSelect 
ZoneEnd

Any ideas?

Hmmm...

Might take some coding on either or both ends.

Sounds like Select is implemented differently than Mute or Solo.

You don't really want to send an index, you want a Widget named Select1 (Select2 ... Select32) to send a 1 upon press.

The indexing gets sorted out within CSI via the | character in your Channel Zone def.

An index of say 6, doesn't mean "Select Track 6", it means "Depending on where you are currently banked in CSI, Select the Track to which this Channel on the Surface is currently pointing".

It's all done with | characters and TrackNavigators.

Clear as mud ?

Ask away !!

[jacksoonbrowne]

Not quite clear as mud

This is the X32 OSC spec for track selection requirement as sent or received by the X32.

"/‐stat/selidx int32 index"
"Where index 0-31 corresponds to channels Ch 1-32"

For example, pressing the track select button on channel 12 on the X32 will send this message to CSI:

/‐stat/selidx value = int32 11


Maybe this might help?

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Not quite clear as mud

This is the X32 OSC spec for track selection requirement as sent or received by the X32.

"/‐stat/selidx int32 index"
"Where index 0-31 corresponds to channels Ch 1-32"

For example, pressing the track select button on channel 12 on the X32 will send this message to CSI:

/‐stat/selidx value = int32 11


Maybe this might help?

I understand that part

You need something conceptually more like this:

Widget Select1
    Control /‐stat/selidx/0
WidgetEnd

Widget Select2
    Control /‐stat/selidx/1
WidgetEnd

Widget Select3
    Control /‐stat/selidx/2
WidgetEnd

What does your .ost file look like for Select, Mute, Solo, that may help me understand.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

I understand that part

You need something conceptually more like this:

Widget Select1
    Control /‐stat/selidx/0
WidgetEnd

Widget Select2
    Control /‐stat/selidx/1
WidgetEnd

Widget Select3
    Control /‐stat/selidx/2
WidgetEnd

What does your .ost file look like for Select, Mute, Solo, that may help me understand.

.ost

//--------------------------------------------------
//--------------------------------------------------
//--------------------------------------------------
// MUTE												
//--------------------------------------------------
//--------------------------------------------------

Widget Mute1
    Control      		/ch/01/mix/on
    FB_IntProcessor 	/ch/01/mix/on
WidgetEnd

Widget Mute2
    Control      		/ch/02/mix/on
    FB_IntProcessor 	/ch/02/mix/on
WidgetEnd

Widget Mute3
    Control      		/ch/03/mix/on
    FB_IntProcessor 	/ch/03/mix/on
WidgetEnd

Widget Mute4
    Control      		/ch/04/mix/on
    FB_IntProcessor 	/ch/04/mix/on
WidgetEnd

Widget Mute5
    Control      		/ch/05/mix/on
    FB_IntProcessor 	/ch/05/mix/on
WidgetEnd

Widget Mute6
    Control      		/ch/06/mix/on
    FB_IntProcessor 	/ch/06/mix/on
WidgetEnd

Widget Mute7
    Control      		/ch/07/mix/on
    FB_IntProcessor 	/ch/07/mix/on
WidgetEnd

Widget Mute8
    Control      		/ch/08/mix/on
    FB_IntProcessor 	/ch/08/mix/on
WidgetEnd

Widget Mute9
    Control      		/ch/09/mix/on
    FB_IntProcessor 	/ch/09/mix/on
WidgetEnd

Widget Mute10
    Control      		/ch/10/mix/on
    FB_IntProcessor 	/ch/10/mix/on
WidgetEnd

Widget Mute11
    Control      		/ch/11/mix/on
    FB_IntProcessor 	/ch/11/mix/on
WidgetEnd

Widget Mute12
    Control      		/ch/12/mix/on
    FB_IntProcessor 	/ch/12/mix/on
WidgetEnd

Widget Mute13
    Control      		/ch/13/mix/on
    FB_IntProcessor 	/ch/13/mix/on
WidgetEnd

Widget Mute14
    Control      		/ch/14/mix/on
    FB_IntProcessor 	/ch/14/mix/on
WidgetEnd

Widget Mute15
    Control      		/ch/15/mix/on
    FB_IntProcessor 	/ch/15/mix/on
WidgetEnd

Widget Mute16
    Control      		/ch/16/mix/on
    FB_IntProcessor 	/ch/16/mix/on
WidgetEnd

Widget Mute17
    Control      		/ch/17/mix/on
    FB_IntProcessor 	/ch/17/mix/on
WidgetEnd

Widget Mute18
    Control      		/ch/18/mix/on
    FB_IntProcessor 	/ch/18/mix/on
WidgetEnd

Widget Mute19
    Control      		/ch/19/mix/on
    FB_IntProcessor 	/ch/19/mix/on
WidgetEnd

Widget Mute20
    Control      		/ch/20/mix/on
    FB_IntProcessor 	/ch/20/mix/on
WidgetEnd

Widget Mute21
    Control      		/ch/21/mix/on
    FB_IntProcessor 	/ch/21/mix/on
WidgetEnd

Widget Mute22
    Control      		/ch/22/mix/on
    FB_IntProcessor 	/ch/22/mix/on
WidgetEnd

Widget Mute23
    Control      		/ch/23/mix/on
    FB_IntProcessor 	/ch/23/mix/on
WidgetEnd

Widget Mute24
    Control      		/ch/24/mix/on
    FB_IntProcessor 	/ch/24/mix/on
WidgetEnd

Widget Mute25
    Control      		/ch/25/mix/on
    FB_IntProcessor 	/ch/25/mix/on
WidgetEnd

Widget Mute26
    Control      		/ch/26/mix/on
    FB_IntProcessor 	/ch/26/mix/on
WidgetEnd

Widget Mute27
    Control      		/ch/27/mix/on
    FB_IntProcessor 	/ch/27/mix/on
WidgetEnd

Widget Mute28
    Control      		/ch/28/mix/on
    FB_IntProcessor 	/ch/28/mix/on
WidgetEnd

Widget Mute29
    Control      		/ch/29/mix/on
    FB_IntProcessor 	/ch/29/mix/on
WidgetEnd

Widget Mute30
    Control      		/ch/30/mix/on
    FB_IntProcessor 	/ch/30/mix/on
WidgetEnd

Widget Mute31
    Control      		/ch/31/mix/on
    FB_IntProcessor 	/ch/31/mix/on
WidgetEnd

Widget Mute32
    Control      		/ch/32/mix/on
    FB_IntProcessor 	/ch/32/mix/on
WidgetEnd


//--------------------------------------------------
//--------------------------------------------------
// SOLO												
//--------------------------------------------------
//--------------------------------------------------

Widget Solo1
    Control      	/-stat/solosw/01
    FB_Processor 	/-stat/solosw/01
WidgetEnd

Widget Solo2
    Control      	/-stat/solosw/02
    FB_Processor 	/-stat/solosw/02
WidgetEnd

Widget Solo3
    Control      	/-stat/solosw/03
    FB_Processor 	/-stat/solosw/03
WidgetEnd

Widget Solo4
    Control      	/-stat/solosw/04
    FB_Processor 	/-stat/solosw/04
WidgetEnd

Widget Solo5
    Control      	/-stat/solosw/05
    FB_Processor 	/-stat/solosw/05
WidgetEnd

Widget Solo6
    Control      	/-stat/solosw/06
    FB_Processor 	/-stat/solosw/06
WidgetEnd

Widget Solo7
    Control      	/-stat/solosw/07
    FB_Processor 	/-stat/solosw/07
WidgetEnd

Widget Solo8
    Control      	/-stat/solosw/08
    FB_Processor 	/-stat/solosw/08
WidgetEnd

Widget Solo9
    Control      	/-stat/solosw/09
    FB_Processor 	/-stat/solosw/09
WidgetEnd

Widget Solo10
    Control      	/-stat/solosw/10
    FB_Processor 	/-stat/solosw/10
WidgetEnd

Widget Solo11
    Control      	/-stat/solosw/11
    FB_Processor 	/-stat/solosw/11
WidgetEnd

Widget Solo12
    Control      	/-stat/solosw/12
    FB_Processor 	/-stat/solosw/12
WidgetEnd

Widget Solo13
    Control      	/-stat/solosw/13
    FB_Processor 	/-stat/solosw/13
WidgetEnd

Widget Solo14
    Control      	/-stat/solosw/14
    FB_Processor 	/-stat/solosw/14
WidgetEnd

Widget Solo15
    Control      	/-stat/solosw/15
    FB_Processor 	/-stat/solosw/15
WidgetEnd

Widget Solo16
    Control      	/-stat/solosw/16
    FB_Processor 	/-stat/solosw/16
WidgetEnd

Widget Solo17
    Control      	/-stat/solosw/17
    FB_Processor 	/-stat/solosw/17
WidgetEnd

Widget Solo18
    Control      	/-stat/solosw/18
    FB_Processor 	/-stat/solosw/18
WidgetEnd

Widget Solo19
    Control      	/-stat/solosw/19
    FB_Processor 	/-stat/solosw/19
WidgetEnd

Widget Solo20
    Control      	/-stat/solosw/20
    FB_Processor 	/-stat/solosw/20
WidgetEnd

Widget Solo21
    Control      	/-stat/solosw/21
    FB_Processor 	/-stat/solosw/21
WidgetEnd

Widget Solo22
    Control      	/-stat/solosw/22
    FB_Processor 	/-stat/solosw/22
WidgetEnd

Widget Solo23
    Control      	/-stat/solosw/23
    FB_Processor 	/-stat/solosw/23
WidgetEnd

Widget Solo24
    Control      	/-stat/solosw/24
    FB_Processor 	/-stat/solosw/24
WidgetEnd

Widget Solo25
    Control      	/-stat/solosw/25
    FB_Processor 	/-stat/solosw/25
WidgetEnd

Widget Solo26
    Control      	/-stat/solosw/26
    FB_Processor 	/-stat/solosw/26
WidgetEnd

Widget Solo27
    Control      	/-stat/solosw/27
    FB_Processor 	/-stat/solosw/27
WidgetEnd

Widget Solo28
    Control      	/-stat/solosw/28
    FB_Processor 	/-stat/solosw/28
WidgetEnd

Widget Solo29
    Control      	/-stat/solosw/29
    FB_Processor 	/-stat/solosw/29
WidgetEnd

Widget Solo30
    Control      	/-stat/solosw/30
    FB_Processor 	/-stat/solosw/30
WidgetEnd

Widget Solo31
    Control      	/-stat/solosw/31
    FB_Processor 	/-stat/solosw/31
WidgetEnd

Widget Solo32
    Control      	/-stat/solosw/32
    FB_Processor 	/-stat/solosw/32
WidgetEnd

//--------------------------------------------------
//--------------------------------------------------
// SELECT											
//		Not quite working properly					
//--------------------------------------------------
//--------------------------------------------------

Widget Select1
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd
 
Widget Select2
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select3
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select4
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select5
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select6
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select7
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select8
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select9
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select10
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select11
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select12
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select13
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select14
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select15
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select16
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select17
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select18
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select19
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select20
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select21
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select22
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select23
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select24
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select25
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select26
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select27
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select28
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select29
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select30
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select31
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select32
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd

[jacksoonbrowne]

The X32 message for Select is

/‐stat/selidx/

with an int32 param specifying the selected channel.

So the x32 for channel 4 select button will send

/stat/selidx, i<selected channel 3>

[Geoff Waddington]

Originally Posted by jacksoonbrowne

The X32 message for Select is

/‐stat/selidx/

with an int32 param specifying the selected channel.

So the x32 for channel 4 select button will send

/stat/selidx, i<selected channel 3>

Aha, you have some coding to do

If you look at the way CSI recognizes which Widget sent the message, you will see that the incoming message is used as a key to a map (dictionary).

Given that, you can easily see how this will work:

Widget Mute1
    Control      		/ch/01/mix/on
    FB_IntProcessor 	/ch/01/mix/on
WidgetEnd

Widget Mute2
    Control      		/ch/02/mix/on
    FB_IntProcessor 	/ch/02/mix/on
WidgetEnd

Widget Mute3
    Control      		/ch/03/mix/on
    FB_IntProcessor 	/ch/03/mix/on
WidgetEnd

and this will fail, all the keys are the same -- no uniqueness here:

Widget Select1
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd
 
Widget Select2
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd 

Widget Select3
	Control			/-stat/selidx
	FB_IntProcessor	/-stat/selidx
WidgetEnd

You will have to trap /-stat/selidx for special handling.

Perhaps morph it into something like this before the CSI handling:

/-stat/selidx/01

First time I've seen something like this in OSC, trust Behringer

[jacksoonbrowne]

You will have to trap /-stat/selidx for special handling.
Perhaps morph it into something like this before the CSI handling:
“/-stat/selidx/01

Ok, got it working in the X32 to CSI direction
Changed ost to

Widget Select1
	Control		/-stat/selidx/01
	FB_IntProcessor	/-stat/selidx/01
WidgetEnd

And morphed the incoming X32 message as you suggested above.

Now to morph the CS1 to X32 direction 

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Ok, got it working in the X32 to CSI direction
Changed ost to

Widget Select1
	Control		/-stat/selidx/01
	FB_IntProcessor	/-stat/selidx/01
WidgetEnd

And morphed the incoming X32 message as you suggested above.

Now to morph the CS1 to X32 direction 

Ok, you need a FB_X32SelectProcessor a la OSC_IntFeedbackProcessor : public OSC_FeedbackProcessor.

Override virtual void ForceValue(string value) and split the string into the message part and the int value.

So far so good.

You can turn the light on.

Now to be able to turn it off.

Is there a /-stat/deselidx/ ?

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Ok, you need a FB_X32SelectProcessor a la OSC_IntFeedbackProcessor : public OSC_FeedbackProcessor.

Override virtual void ForceValue(string value) and split the string into the message part and the int value.

So far so good.

You can turn the light on.

Now to be able to turn it off.

Is there a /-stat/deselidx/ ?

There is no deselect on the X32, only select.
When a track is selected in reaper, CSI appears to send two messages.
One to deselect and one to select. The order depends on whether the selected track number is less or greater the previous selected track.

I kludged the source code so that a select sent from reaper is ignored if the OSC parameter is 0;

I also in the same kludge code set a "/-stat/chfaderbank" with a parameter of selectedChannel/16 immediately following the select so that the X32 will change its channel banks appropriately.

Yeah a few kludges to the code now, but is just to get a quick and dirty build running

Will readdress the proper way to implement in a fashion that follows CSI after I get everything working and your new arch comes out

[Geoff Waddington]

Originally Posted by jacksoonbrowne

There is no deselect on the X32, only select.
When a track is selected in reaper, CSI appears to send two messages.
One to deselect and one to select. The order depends on whether the selected track number is less or greater the previous selected track.

I kludged the source code so that a select sent from reaper is ignored if the OSC parameter is 0;

I also in the same kludge code set a "/-stat/chfaderbank" with a parameter of selectedChannel/16 immediately following the select so that the X32 will change its channel banks appropriately.

Yeah a few kludges to the code now, but is just to get a quick and dirty build running

Will readdress the proper way to implement in a fashion that follows CSI after I get everything working and your new arch comes out

Cool, working the re-arch, probably a few days to an alpha...

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Cool, working the re-arch, probably a few days to an alpha...

Will the source code for the alpha be available?

[jacksoonbrowne]

Hey Geoff,

A little sample of a recording in my humble bassment studio "HubWallStudios.com"
Last November.
A local Ottawa vocalist Maricor Wagner.
My friend of over 35 years on Guitar - Gabe Obert
One of the best drummers in Ottawa - Dave Hubenig
And of course - the balding senior citizen bassist is my self.

No midi, all live tracking

Enjoy

https://www.youtube.com/watch?v=PdI2TBotstA

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Will the source code for the alpha be available?

Well, alpha is just a label man

Seriously, github is always up to date, so much so that the current builds are broken, stay tuned

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hey Geoff,

A little sample of a recording in my humble bassment studio "HubWallStudios.com"
Last November.
A local Ottawa vocalist Maricor Wagner.
My friend of over 35 years on Guitar - Gabe Obert
One of the best drummers in Ottawa - Dave Hubenig
And of course - the balding senior citizen bassist is my self.

No midi, all live tracking

Enjoy

https://www.youtube.com/watch?v=PdI2TBotstA

Great stuff !!!

[Sound asleep]

I was wondering about using x32 as a controller. I'm pretty basic in my needs for it, but I was wondering if it was possible to get this sort of functionality. Maybe with realearn?

Is it possible to have it setup so that I just assign specific tracks to specific faders on the x32, and they communicate together to keep track of the Fader position?

Or is it necessarily to create more of a sort of software interface where the faders need to control like 1-16 17-32 and so on with pages?

If mute and solo works, that would be great. I personally don't really need anything else other that being able to assign any track to any fader. If I could assign any Reaper track to any fader across the while thing, so the 16 input faders, plus the 8 buss ones, that would be amazing.

[mschnell]

Originally Posted by Sound asleep

I was wondering about using x32 as a controller.

I seem to remember that there have been some discussions about using the X32 with the "CSI" Reaper extension.
-Michael

[jacksoonbrowne]

Originally Posted by Sound asleep

I was wondering about using x32 as a controller. I'm pretty basic in my needs for it, but I was wondering if it was possible to get this sort of functionality. Maybe with realearn?

Is it possible to have it setup so that I just assign specific tracks to specific faders on the x32, and they communicate together to keep track of the Fader position?

Or is it necessarily to create more of a sort of software interface where the faders need to control like 1-16 17-32 and so on with pages?

If mute and solo works, that would be great. I personally don't really need anything else other that being able to assign any track to any fader. If I could assign any Reaper track to any fader across the while thing, so the 16 input faders, plus the 8 buss ones, that would be amazing.

Hello SoundAsleep,

I am responsible for the X32 implementation on CSI.

It will do what you want.
But it requires setting up configuration files to achieve what you want.
I can do that for you.

Let me know if you would like to proceed


Cheers,
Roy