Control Surface Integration (CSI) Technical Feature Discussion

[tompad]

Originally Posted by Manwë

It's an open source keystroke input viewer used mostly for program tutorials like Blender.

Whats the name on the open source keystroke input viewer??

I thought it might relieve some possible confusion as to what page you are using at the moment without having to utilize a display on your control surface.

Sorry if this is a dumb question!

There are no dumb questions! :-)
I was thinking in the same way about relieve possible confusion
about what the F1-F8 buttons do on my XTouch, especially when having
different zones with different F-button-functions.

[Manwë]

Originally Posted by tompad

Whats the name on the open source keystroke input viewer??



There are no dumb questions! :-)
I was thinking in the same way about relieve possible confusion
about what the F1-F8 buttons do on my XTouch, especially when having
different zones with different F-button-functions.

It's called Carnac

http://code52.org/carnac/

[tompad]

Originally Posted by Manwë

If you're willing to share you script, I'd love to give it a shot!

Its just a window that shows what function is on F-button - nothing fancy.
My window stays on top until I press a button again, maybe its possible
to make window close after some seconds, dont know, have to check it out.

...and yeah, you need Reaper Toolkit installed from Reapack to run it.
...but I think the script take care of that (havn't tested without RTK).

...and I have only tested this on Win10.

[tompad]

Originally Posted by Manwë

It's called Carnac

http://code52.org/carnac/

Thanks, will check it out!

[Manwë]

Originally Posted by tompad

Its just a window that shows what function is on F-button - nothing fancy.
My window stays on top until I press a button again, maybe its possible
to make window close after some seconds, dont know, have to check it out.

...and yeah, you need Reaper Toolkit installed from Reapack to run it.
...but I think the script take care of that (havn't tested without RTK).

...and I have only tested this on Win10.

Awesome thank you!

[Funkybot]

Remember: if you have a spare tablet or old phone, you can use it display all kinds of stuff from CSI via OSC.

[Wayland]

Hi guys! sorry to ask noob question.
My last CSI install was some 1.* version

With Mackie MCU
But my System HDD died with my Reaper Config(((

So now i try everything once again from scratch, and here is CSI 2

The one feature i loved the most - Surface and Reaper banks were totally independent.
So i could scroll MCP in reaper and select any tracks without changing MCU layout
(Brilliant to have main VCA always on surface, and to avoid fader noise with every MCP selection)
And in CSI wiki there was function - smth like show selected track on surface.
Wich instantly jumps banks on surface to see selected track as a first fader ( or 2-3-4 etc fader if it's in the end of the project)

For the moment in CSI 2 i cannot find this action. A looked across all actions for several times - tracks, navigation, all the rest. And i cant find this HUGE timesaver action.
Im definitely going to learn all CSI wiki in details later and tweak my zones and buttons.

But for the moment - pls help me find action to quickly sync selected track in reaper and surface active fader bank.
Thanks a lot!

P.S.
Ok, it's ToggleScrollLink
But it works like on/off for ALWAYS scroll link. And i want it to work only once when pressed

P.S.S.
Yeap, the ForceScrollLink is not working

[MixMonkey]

Originally Posted by Wayland

Yeap, the ForceScrollLink is not working

I'm pretty sure ForceScrollLink is deprecated.

I do this to scroll the Reaper Mixer to the selected track:

    SomeButton     Reaper _MM_Scroll_mixer_to_selected_track
    SomeButton     ToggleScrollLink
    SomeButton     ToggleScrollLink

.....where "_MM_Scroll_mixer_to_selected_track" is a simple lua script:

--MixMonkey: Scroll mixer to selected track
SelTrack = reaper.GetSelectedTrack
reaper.SetMixerScroll(SelTrack(0,0))

[Wayland]

Thanks, double ToggleScrollLink for same button does the trick

Except it only works with only one track selected, wich is not a big deal i hope.

I suppose scroll mixer for track - is Reaper related command to keep view in sync with surface?


Oh, and extra question - Exporting Reaper Theme - Does it includes CSI folder and zone files, FX maps, and all CSI related settings?
Or i should take care of it separately?

[MixMonkey]

Originally Posted by Wayland

I suppose scroll mixer for track - is Reaper related command to keep view in sync with surface?

I think I might have put that in when I was experimenting with another script that was refusing to scroll automatically. If it works without, all the better!

Oh, and extra question - Exporting Reaper Theme - Does it includes CSI folder and zone files, FX maps, and all CSI related settings?
Or i should take care of it separately?

You have to take care of it yourself

[jacksoonbrowne]

New version of X32 support files posted:

//---------------------------------------------------------------//
// Reaper CSI X32/Xair/Midas32 support files installation notes. //
//---------------------------------------------------------------//

Version     0.0     original 

Version     0.1     21 November 2022

                    Almost complete set of all X32 widgets added.
                    
                    CSI code now supports
                       "Select" buttons.
                       "Scibble Strip" colors.

To obtain the X32 support files:
    Go to: https://www.dropbox.com/scl/fo/upw6b...zbeqjyob5e69d2
    and retrieve the most recent versions of support files and place
    them in the CSI file structure appropriately.

NOTE:
    You will need to modify the .ost file for the IP address of your Behringer surface.

Having done that:
    Load the X32 scene file from "CSI\Behringer X32 Scene\CSI-X32-Config.scn",
    and place it on a USB thumb drive that is 32Gbytes or less, and
    formatted as "FAT32".

Follow the instructions from Behringer web site for the X32 on how to
    download a scene from a USB stick and install the scene.
Then load that scene on the X32.

This scene will configure the "Assignable sections:
    rotaries and buttons" to control the:
        "Transport" as per the current X32 .ost and .zon files.

Enjoy :)

[Manwë]

Originally Posted by Funkybot

Remember: if you have a spare tablet or old phone, you can use it display all kinds of stuff from CSI via OSC.

I took your advice and dug out my old 2012 Ipad Mini and found a way to achieve what I was looking for!



Top half is always info on:
Track Number
Track Name
Page Name (which is now a bit redundant with the "LED" buttons)
Focused Parameter
Focused Parameter Value
Fx Name

And then buttons with "LEDs" for Page and Zone selection!


Thank you again Funkybot for the suggestion!

[AtmanActive]

Originally Posted by Manwë

I took your advice and dug out my old 2012 Ipad Mini and found a way to achieve what I was looking for!



Top half is always info on:
Track Number
Track Name
Page Name (which is now a bit redundant with the "LED" buttons)
Focused Parameter
Focused Parameter Value
Fx Name

And then buttons with "LEDs" for Page and Zone selection!


Thank you again Funkybot for the suggestion!

This combination really highlights CSI's awesomeness!


@Manwë: maybe consider sharing your CSI/OSC project here when you're happy with it?

I remember how much MixMonkey's MM_iPad_Mixer helped me get up to speed with CSI, I'm hoping your project could do the same for someone.

Thanks.

[Manwë]

Originally Posted by AtmanActive

This combination really highlights CSI's awesomeness!


@Manwë: maybe consider sharing your CSI/OSC project here when you're happy with it?

I remember how much MixMonkey's MM_iPad_Mixer helped me get up to speed with CSI, I'm hoping your project could do the same for someone.

Thanks.

Of course! This is my first time using CSI and it's been really fun going through the ins and outs of whats possible!

This TouchOSC instance is going to be the main "Broadcast" controller in charge of most of the Global functions for the rest of my controllers:

X-Touch One
X-Touch Mini
X-Touch Extender x2
CMD DC-1
CMD DV-1 x2

Once everything is up and running smoothly, I'll do a full post of the config and setup!

[Funkybot]

Originally Posted by Manwë

I took your advice and dug out my old 2012 Ipad Mini and found a way to achieve what I was looking for!

Thank you again Funkybot for the suggestion!

Happy to help! Glad you were able to get a solution up and running so quickly!

[Geoff Waddington]

This post is for @diesel or anyone else interested in supporting WidgetModes.

The current design sucks

It sets the mode directly on the FeedbackProcessor.

This has terrible side effects.

Before you leave an active Zone you must remember to reset any FeedbackProcessor WidgetModes.

The WidgetModes should really be stored in the ActionContext, and the FeedbackProcessor Widget should query the current ActionContext (in the active Zone) for its values.

That way no cleanup is required when you switch Zones.

I will work on this over the next few days and will post a build with a better design.

[Funkybot]

I love that you continue to refine things like this in CSI's design Geoff. Thanks for all your work on CSI and the SCE-24! 'Tis the season for giving thanks here in the US, so consider this a belated Candadian Thanksgiving wish!

[Geoff Waddington]

Originally Posted by Funkybot

I love that you continue to refine things like this in CSI's design Geoff. Thanks for all your work on CSI and the SCE-24! 'Tis the season for giving thanks here in the US, so consider this a belated Candadian Thanksgiving wish!

Thanks, and a Happy Thanksgiving to all south of the border !

[Geoff Waddington]

Working through the new Widget Mode design.

    Rotary|          	  	TrackPanAutoLeft
    Rotary|			WidgetMode Dot
    Toggle+Rotary|              TrackPanAutoRight
    Toggle+Rotary|		WidgetMode Dot

This syntax has the same problem that the old "Property" syntax has -- it needs an extra line per WidgetMode, and the affinity is not as clear as it could be.

It works OK in the above case but for this, not so much:

    SomeDisplay    FXParam 8
    SomeDisplay    WidgetMode LargeText
    SomeDisplay    WidgetMode Center
    SomeDisplay    WidgetMode ModeValue 10

First stab at a new approach that reinforces the WidgetMode affinity to a particular Widget->Action combo:

    SomeDisplay       FXParam 8 "WidgetMode Size=Large Align=Center ModeValue=10"
    Shift+SomeDisplay FXParam 6 "WidgetMode Size=Small Align=Right ModeValue=5"

This borrows heavily from a web Tailwind CSS approach, and, although a bit verbose, I think it improves the situation.

As always, comments and suggestions more than welcomed, the floor is open...

[MixMonkey]

Originally Posted by Geoff Waddington

    SomeDisplay       FXParam 8 "WidgetMode Size=Large Align=Center ModeValue=10"
    Shift+SomeDisplay FXParam 6 "WidgetMode Size=Small Align=Right ModeValue=5"

If you put the Widget mode stuff in quotes, won't it be seen as a parameter alias?

Notwithstanding that, it's easier to read with the WidgetMode statement on the same line as the Widget it's intended for.

[Geoff Waddington]

Originally Posted by MixMonkey

If you put the Widget mode stuff in quotes, won't it be seen as a parameter alias?

The parser will see "WidgetMode" and know that what follows are WidgetMode parameters.

We might need to rename it to "*WidgetMode" or some such, in case anyone might want to use "WidgetMode" as an alias.

Originally Posted by MixMonkey

Notwithstanding that, it's easier to read with the WidgetMode statement on the same line as the Widget it's intended for.

Agree.

[Funkybot]

That looks much cleaner to me too. I like it!

Thinking ahead, any thoughts on how that would look in an EZFX zone?

[MT4U]

Hi there.

I wanted to share this little script with you people.

It's for AutoSteps files.

CSI limits the number of steps to 30 (for obvious performance reasons), and since I came across a couple FX that had like 31, 32 and so on I put up this EEL script to generate an AutoStep file for an individual FX. (First effect on the selected track for this purpose) with a limit of 95 . I thought it may be usefull to someone else.

Greetings to you all!

Mars

PS: I'm new to EEL, so please don't judge my coding.

[Geoff Waddington]

Originally Posted by Funkybot

That looks much cleaner to me too. I like it!

Thinking ahead, any thoughts on how that would look in an EZFX zone?

Dunno, maybe something like this:

Zone "VST: UAD Fairchild 660 (Universal Audio, Inc.)" "Fair660"
	FXParams      9      1     2      3     6    7      0     8
 	FXParamNames  HdRoom Input Thresh Ratio Knee Output Meter WetDry
 	FXWidgetModes Dot    Fill  Fill   Dot   Fill Fill   Dot   Spread

[Funkybot]

Originally Posted by Geoff Waddington

Dunno, maybe something like this:

Zone "VST: UAD Fairchild 660 (Universal Audio, Inc.)" "Fair660"
	FXParams      9      1     2      3     6    7      0     8
 	FXParamNames  HdRoom Input Thresh Ratio Knee Output Meter WetDry
 	FXWidgetModes Dot    Fill  Fill   Dot   Fill Fill   Dot   Spread

Yeah, I feel like that's where they're going to get tricky. I'm imaging your example above with Display alignment and size in an EZFX zone and that could get messy fast. Here's just one...

Zone "VST: UAD Fairchild 660 (Universal Audio, Inc.)" "Fair660"
	FXParams      9      1     2      3     6    7      0     8
 	FXParamNames  HdRoom Input Thresh Ratio Knee Output Meter WetDry
 	FXWidgetModes Dot    Fill  Fill   Dot   Fill Fill   Dot   Spread
 	FXWidgetModesAlign Center Left  Left   Center   Left Right   Left Center

Maybe better to do something like this

Zone "VST: UAD Fairchild 660 (Universal Audio, Inc.)" "Fairchild 660"
     FXParams                 1            2         3               7             4           6           9        8
     FXParamNames             "Input Gain" Threshold "Time Constant" "Output Gain" "SC Filter" "DC Thresh" Headroom Mix
     FXValueWidgets           RotaryA|
     FXParamNameDisplays      DisplayUpperA|
     FXParamValueDisplays     DisplayLowerA|

     FXWidgetMode DisplayUpperA| Size=Large Align=Center ModeValue=10
     FXWidgetMode DisplayLowerA| Size=Small Align=Left   ModeValue=5
ZoneEnd

...I'm using a pipe there, but you could have individual lines for individual widgets with the idea being to append them at the end of the EZFXZon's like we had been doing for stepped params.

[Geoff Waddington]

Originally Posted by Funkybot

Maybe better to do something like this

Zone "VST: UAD Fairchild 660 (Universal Audio, Inc.)" "Fairchild 660"
     FXParams                 1            2         3               7             4           6           9        8
     FXParamNames             "Input Gain" Threshold "Time Constant" "Output Gain" "SC Filter" "DC Thresh" Headroom Mix
     FXValueWidgets           RotaryA|
     FXParamNameDisplays      DisplayUpperA|
     FXParamValueDisplays     DisplayLowerA|

     FXWidgetMode DisplayUpperA| Size=Large Align=Center ModeValue=10
     FXWidgetMode DisplayLowerA| Size=Small Align=Left   ModeValue=5
ZoneEnd

...I'm using a pipe there, but you could have individual lines for individual widgets with the idea being to append them at the end of the EZFXZon's like we had been doing for stepped params.

Except that, stepped parameters are per FX param, and Widgets can have modifiers, which means we might need more than one definition for a given Widget.

Good points though, will have to ponder this a bit more.

Maybe something more like your first example:

	FXParams      9      1     2      3      6    7      0     8
 	FXParamNames  HdRoom Input Thresh Ratio  Knee Output Meter WetDry
 	FXWidgetStyle Dot    Fill  Fill   Dot    Fill Fill   Dot   Spread
 	FXWidgetAlign Center Left  Left   Center Left Right  Left  Center

[Funkybot]

Originally Posted by Geoff Waddington

Except that, stepped parameters are per FX param, and Widgets can have modifiers, which means we might need more than one definition for a given Widget.

Good points though, will have to ponder this a bit more.

Maybe something more like your first example:

	FXParams      9      1     2      3      6    7      0     8
 	FXParamNames  HdRoom Input Thresh Ratio  Knee Output Meter WetDry
 	FXWidgetStyle Dot    Fill  Fill   Dot    Fill Fill   Dot   Spread
 	FXWidgetAlign Center Left  Left   Center Left Right  Left  Center

That could indeed work. Would just mean having to build more of those FXWidget[whatever] actions for the various widget modes, but that could allow for standardizing WidgetModes across various surfaces (FaderPort, SCE-24, etc).

[Geoff Waddington]

Originally Posted by Funkybot

That could indeed work. Would just mean having to build more of those FXWidget[whatever] actions for the various widget modes, but that could allow for standardizing WidgetModes across various surfaces (FaderPort, SCE-24, etc).

Agreed, it does make the assumption things don't get out of hand

Seriously, I think there will tend to be a small number of attributes, so we would likely be fine using that approach.

[diesel]

Hi guys,

I've been meaning to post this all week and have been too busy - apologies. Another long one I'm afraid, but I think it will play into the current conversation. I had some trouble with widget modes this week as I wanted the MFTwister (in my case) to change state depending on itself rather than any state in REAPER or the FX or CSI. Namely, to change the colour of the LED when the encoder is pushed. It doesn't latch to any parameter or condition - it's just a temporary state.

So I came up with the idea of a new action. I achieved what I wanted with SendMididMessage, but it's uuuugly. So I made a new action called "TellMFT" so that this:

Push7 SendMIDIMessage "b1 06 3d"
Release7 SendMIDIMessage "b1 06 2a"

becomes this:

Push7 TellMFT "cc06 yellow"
Release7 TellMFT "cc06 green"

Also this:

OnZoneActivation SendMIDIMessage "b2 06 2f"
OnZoneActivation SendMIDIMessage "b5 06 5f"
OnZoneActivation SendMIDIMessage "b1 06 2a"

can become this:

OnZoneActivation TellMFT "cc06 on hue 42"

The following are examples of what is possible:

TellMFT "cc06 off"
TellMFT "cc06 on"
TellMFT "cc06 half"
TellMFT "cc06 brightness 50%"
TellMFT "cc06 ring 50% led 75% hue 61"
TellMFT "cc06 #7f0843 bright 100"
TellMFT "cc06 orange on"
TellMFT "make the color of control cc06 to be #7f0843 and make the led 100% bright but make the ring 50% bright"

The algorithm uses regular expresssion matching (regex) to isolate keywords and word/number combinations to determine what midi messages to send. So the complete lexicon is:

"ccXX" = "cc XX" = the CC address of the control/knob/encoder to which to apply the colours and brightnesses.

"on" = "full" = maximum brightness for both ring and LED.
"half" = 50% brightness on both ring and LED.
"off" = 0% brightness on both ring and LED (the ring doesn't turn off completely which is weird).
"brightness X" sets ring & LED brightness to X%. Percentage signs are optional. Spaces (whitespace) are optional.
	ie. "brightness X" = "brightnessX" = "brightness X%" = "brightnessX%"
"led X" set LED brightness to X%. Same rules as "brightness".
"ring X" set ring brightness to X%.

"#RRGGBB" sets the LED colour using hex values. IT DOES NOT AFFECT BRIGHTNESS, only hue.
"hue X" sets the LED colour using the MFT values (1 - 126) from the manual.
"blue" = "hue 1" = sets the colour using a name instead of having to know the MFT hue value. I've chosen some others as follows:
"sky" = "hue 17"
"cyan" = "hue 32"
"sea" = "hue 38"
"green" = "hue 43"
"lime" = "hue 57"
"yellow" = "hue 61"
"orange" = "hue 70"
"red" = "hue 80"
"lipstick" = "hue 90"
"pink" = "hue 106"
"purple" = "hue 112"
"violet" = "hue 126"

For calculation speed sake, some keywords will prevent the detection of others. For example a control can not be both "on" and "off" at the same time. And if no CC address is provided, the whole thing is a bust. If you understand regex and if..then statements, then the code is pretty straight forward. Here it is:

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class TellMFT : public Action
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
private:
	inline static const regex cc_regex = regex(" cc\\s*([0-9a-fA-F]+)");
	inline static const regex hex_regex = regex("#([0-9a-fA-F]{6})");
	inline static const regex hue_regex = regex(" hue\\s*([0-9]+)");
	inline static const regex name_regex = regex(" (blue|sky|cyan|sea|green|lime|yellow|orange|red|lipstick|pink|purple|violet) ");
	inline static const regex bright_regex = regex(" (bright|brightness|dim)\\s*([0-9]+)");
	inline static const regex led_regex = regex(" led\\s*([0-9]+)");
	inline static const regex ring_regex = regex(" ring\\s*([0-9]+)");
	inline static const regex on_regex = regex(" (on|full) ");
	inline static const regex half_regex = regex(" half ");
	inline static const regex off_regex = regex(" off ");
public:
	virtual string GetName() override { return "TellMFT"; }

	virtual void RequestUpdate(ActionContext* context) override
	{
		context->UpdateColorValue(0.0);
	}

	void Do(ActionContext* context, double value) override
	{
		// get parameter string
		string what = " " + context->GetStringParam() + " ";
		// cc of knob
		int cc = 0x00;
		smatch match;
		if (regex_search(what, match, cc_regex))
		{
			sscanf(match.str(1).c_str(), "%2x", &cc);
		}
		else
		{
			DAW::ShowConsoleMsg(("\n" + what + "\n ... No CC specified. I don't know where to send the message").c_str());
			return;
		}
		// LED color by hex
		if (regex_search(what, match, hex_regex))
		{
			rgba_color rgb;
			sscanf(match.str(1).c_str(), "%2x%2x%2x", &rgb.r, &rgb.g, &rgb.b);
			vector<int> mft_values = rgb.mft();
			int hue = mft_values[0];
			context->GetSurface()->SendMidiMessage(0xb1, cc, hue);
		}
		else
		{
			// LED color by MFT hue
			if (regex_search(what, match, hue_regex))
			{
				string hue = match.str(1);
				context->GetSurface()->SendMidiMessage(0xb1, cc, stoi(hue));
			}
			else
			{
				// LED color by name
				if (regex_search(what, match, name_regex))
				{
					map<string, int> mft_colors;
					mft_colors["blue"] = 1;
					mft_colors["sky"] = 17;
					mft_colors["cyan"] = 32;
					mft_colors["sea"] = 38;
					mft_colors["green"] = 43;
					mft_colors["lime"] = 57;
					mft_colors["yellow"] = 61;
					mft_colors["orange"] = 70;
					mft_colors["red"] = 80;
					mft_colors["lipstick"] = 90;
					mft_colors["pink"] = 106;
					mft_colors["purple"] = 112;
					mft_colors["violet"] = 126;
					string name = match.str(1);
					int hue = mft_colors[name];
					context->GetSurface()->SendMidiMessage(0xb1, cc, hue);
				}
			}
		}
		// full brightnesses
		if (regex_search(what, match, on_regex))
		{
			context->GetSurface()->SendMidiMessage(0xb2, cc, 47);
			context->GetSurface()->SendMidiMessage(0xb5, cc, 95);
		} else {
			// minimum brightnesses
			if (regex_search(what, match, off_regex))
			{
				context->GetSurface()->SendMidiMessage(0xb2, cc, 17);
				context->GetSurface()->SendMidiMessage(0xb5, cc, 65);
			}
			else
			{
				// half brightnesses
				if (regex_search(what, match, half_regex))
				{
					context->GetSurface()->SendMidiMessage(0xb2, cc, 32);
					context->GetSurface()->SendMidiMessage(0xb5, cc, 80);
				}
				else
				{
					// LED & ring brightness -------
					if (regex_search(what, match, bright_regex))
					{
						int brightness = stoi(match.str(1)) % 100;
						int led_brightness = brightness * 30 / 100 + 17;
						int ring_brightness = brightness * 30 / 100 + 65;
						context->GetSurface()->SendMidiMessage(0xb2, cc, led_brightness);
						context->GetSurface()->SendMidiMessage(0xb5, cc, ring_brightness);
					}
					// LED brightness -------
					if (regex_search(what, match, led_regex))
					{
						int brightness = stoi(match.str(1)) % 100;
						int led_brightness = brightness * 30 / 100 + 17;
						context->GetSurface()->SendMidiMessage(0xb2, cc, led_brightness);
					}
					// ring brightness -------
					if (regex_search(what, match, ring_regex))
					{
						int brightness = stoi(match.str(1)) % 100;
						int ring_brightness = brightness * 30 / 100 + 65;
						context->GetSurface()->SendMidiMessage(0xb5, cc, ring_brightness);
					}

				}
			}
		}

	}
};

Also, Geoff, I moved the "rgb2mft" function into the rgba object itself. You may or may not think that's a good idea. I include it below for completeness:

vector<int> mft ()
{
	vector<int> hsv = this->hsv();
	int hue = hsv[0];
	int brightness = hsv[2];
	int mft_hue = 127 - (int)(fmod((hue + 120), 360) / 360 * 125 + 1);
	int mft_led_brightness = brightness * 30 / 100 + 17;
	int mft_ring_brightness = brightness * 30 / 100 + 65;
	return {mft_hue, mft_led_brightness, mft_ring_brightness};
}

Maybe some of these lexical ideas are useful?

The problem I couldn't find how to fix with widget modes was state management. There is much I don't understand, but is it possible to store an arbitrary state with widget mode? Does it listen as well as talk?

Anyway - another long post. I hope some of this is useful.

Also:

Originally Posted by Geoff Waddington

This post is for @diesel or anyone else interested in supporting WidgetModes.

The current design sucks

ROFL!

Kind regards,
Diesel

[Geoff Waddington]

What are these "CC addresses" you speak of, never heard of them

[Geoff Waddington]

There is a lingering design issue in CSI that has been driving me nuts for years.

It exists because of this:

Widget Fader1
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
	Touch 90 68 7f 90 68 00
WidgetEnd

For the coders, here is the uuuugly fragment:

    if(GetActionContexts(widget).size() > 0)
    {
        shared_ptr<ActionContext> context = GetActionContexts(widget)[0];
        context->RequestUpdate();
    }

It basically says "If you find Action(s) in this Zone for a given Widget, make sure you only update the first one."

This prevents the dreaded "psychedelic display effect" from way back in the day.

I find it quite remarkable that the solution has been glaringly staring me in the face for years.

With all of the bitching I do about separating the Message Generator from the Feedback Processor -- I'm talking to you OSC, Console1, etc the following construct does exactly the opposite:

Widget Fader1
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
	Touch 90 68 7f 90 68 00
WidgetEnd

Here we are doing exactly what I constantly bitch and moan about -- bundling the Message Generators and Touch Generators with the Feedback Processor.

Ughhh.

Methinks it's time to consider CSI 3.0.

Time to break up the components thusly.

Widget MG_Fader1
	MG_Fader14Bit e0 7f 7f
WidgetEnd

Widget TG_Fader1
	TG_Touch 90 68 7f 90 68 00
WidgetEnd

Widget FB_Fader1
	FB_Fader14Bit e0 7f 7f
WidgetEnd

OK, that cleans up the .mst/.ost part of the bargain.

How about the Zone part ?

If we use the same approach, we end up with an explosion of Actions.

So, I don't think it's necessary to add Actions.

The existing Actions can operate in the context of the assigned Widget.

Currently we have this:

   Touch+DisplayLower| 	TrackVolumeDisplay
   Fader|               TrackVolume

Here, the TrackVolume concept is split.

The TrackVolumeDisplay is a Feedback only Action, whilst the TrackVolume is triple purpose, Message Generator, Touch Generator, and Feedback Processor.

Propose we do the following:

   Touch+DisplayLower| 	TrackVolumeDisplay
   MG_Fader|            TrackVolume 
   TG_Fader|            TrackVolume 
   FB_Fader|            TrackVolume

This does make the Zone definitions more verbose, but it does state the intentions much more explicitly.

All of this was triggered while thinking about the "NoFeedback" Widget Mode -- needless to say that disappears if we use this approach.

It would also clean up the parameter lists that follow the Action.

Message Generator parameters like step size, step lists, etc. would be on the MG_Fader line.

Feedback Processor parameters like, Widget LED ring style, colours, etc. would be on the FB_Fader line.

As far as code, the internals would clean up considerably -- the ActionContext class is currently pretty much a dog's breakfast

Just some very early morning ponderings...

[AtmanActive]

+1

[Funkybot]

Geoff, what you're saying totally makes sense and is entirely logical, but I also kind of hate it.

I couldn't imagine doing that across entire zone files (verbosity), in addition to complicating zone authoring further for new users. It feels too "programmery" to me because you'd be asking end-users have to conceptually think of each control as a message generator, a feedback processor, and possibly a touch generator. From a "what's really happening" perspective, yeah, that makes sense, but from an end-user perspective, they're seeing: button, fader, knob when zone authoring for an existing surface. Note: I'm only looking at it from the perspective of zone authoring, and it's already the biggest thing CSI users struggle with.

Just to throw the idea out there: can you make the necessary changes to the .mst's and then have the zone assume that FB_Fader1 belongs to MG_Fader1 so no additional syntax changes are required? Or does that defeat some of the purpose?

I'd just lean against complicating zone authoring in this case because remember the ReaperBlog video with Jon struggling to get CSI setup? Why make it worse by splitting out the FB and MG portions when most people just see a single control and expect them to be linked? But if the changes were at the .mst level and the parser could look at existing .zon files and make some assumptions, maybe that's a best of both worlds scenario. Then you could just make "NoFeedback" a modifier like...

Zone "Buttons"
      NoFeedback+Up      Reaper _XENAKIOS_TVPAGEUP     
      NoFeedback+Down    Reaper _XENAKIOS_TVPAGEDOWN

You know me, just trying to pushback and provoke you into thinking about these things from another perspective. Maybe the extra syntax wouldn't be so bad and I'm just being a Chicken Little!

[Geoff Waddington]

Originally Posted by Funkybot

Geoff, what you're saying totally makes sense and is entirely logical, but I also kind of hate it.

I couldn't imagine doing that across entire zone files (verbosity), in addition to complicating zone authoring further for new users. It feels too "programmery" to me because you'd be asking end-users have to conceptually think of each control as a message generator, a feedback processor, and possibly a touch generator. From a "what's really happening" perspective, yeah, that makes sense, but from an end-user perspective, they're seeing: button, fader, knob when zone authoring for an existing surface. Note: I'm only looking at it from the perspective of zone authoring, and it's already the biggest thing CSI users struggle with.

Just to throw the idea out there: can you make the necessary changes to the .mst's and then have the zone assume that FB_Fader1 belongs to MG_Fader1 so no additional syntax changes are required? Or does that defeat some of the purpose?

I'd just lean against complicating zone authoring in this case because remember the ReaperBlog video with Jon struggling to get CSI setup? Why make it worse by splitting out the FB and MG portions when most people just see a single control and expect them to be linked? But if the changes were at the .mst level and the parser could look at existing .zon files and make some assumptions, maybe that's a best of both worlds scenario. Then you could just make "NoFeedback" a modifier like...

Zone "Buttons"
      NoFeedback+Up      Reaper _XENAKIOS_TVPAGEUP     
      NoFeedback+Down    Reaper _XENAKIOS_TVPAGEDOWN

You know me, just trying to pushback and provoke you into thinking about these things from another perspective. Maybe the extra syntax wouldn't be so bad and I'm just being a Chicken Little!

Your points are entirely valid, as usual !

Still think it's worth pursuing this a bit further, especially from the .mst/.ost perspective, we could eliminate Widgets altogether -- that's a blatant tease to a post Im working on, should have it ready soon

[Geoff Waddington]

This is just a very preliminary idea.

The idea is to further leverage what we already have done with the Widget class concept.

Encoder b0 |  7f
Fader14 |  7f 7f
Switch  90 |  7f
Press   90 |  7f

StepSize
    Encoder   0.003
StepSizeEnd

AccelerationValues
    Encoder   Dec 41     42    43    44    45    46    47  
    Encoder   Inc 01     02    03    04    05    06    07  
    Encoder   Val 0.0006 0.001 0.002 0.003 0.008 0.04  0.08 
AccelerationValuesEnd

Switch  Track  28
Switch  Send   29
 ...
Switch  Play   5e
 ...
Encoder JogWheel 3c 
 ...
Switch  Touch  68-6f
Switch  Select 18-1f
Encoder Rotary 10-17
Fader14 Fader  e0-e7
Fader14 Master e8

where Switch means press and release, and Press means press only.

We would have to add feedback, AnyPress, etc., but you get the idea.

Still thinking this through, but it would make for much simpler .mst/.ost files.

[edit]

Or maybe this reads better:

Select Switch  18-1f
Rotary Encoder 10-17
Fader  Fader14 e0-e7
Master Fader14 e8

[Geoff Waddington]

Thinking about Widget Modes, maybe we just state them as key/value pairs separated by an "=" sign, that way the parser can still differentiate without confusing them with aliases.

Zone "Buttons"
      Up      Reaper _XENAKIOS_TVPAGEUP   Feedback=No
      Down    Reaper _XENAKIOS_TVPAGEDOWN Feedback=No

[Geoff Waddington]

With all of these changes, EZFXZones are starting to lose their lustre.

Perhaps they have served their purpose, getting us to think outside the box with regard to step sizes, step value lists, etc.

Maybe time to retire them ?

[Funkybot]

Originally Posted by Geoff Waddington

With all of these changes, EZFXZones are starting to lose their lustre.

Perhaps they have served their purpose, getting us to think outside the box with regard to step sizes, step value lists, etc.

Maybe time to retire them ?

Does this mean auto mapping FX Zones is off the table? That seemed to me like the reason to keep them.

[Funkybot]

Originally Posted by Geoff Waddington

Thinking about Widget Modes, maybe we just state them as key/value pairs separated by an "=" sign, that way the parser can still differentiate without confusing them with aliases.

Zone "Buttons"
      Up      Reaper _XENAKIOS_TVPAGEUP   Feedback=No
      Down    Reaper _XENAKIOS_TVPAGEDOWN Feedback=No

I like this a lot.

[Geoff Waddington]

Originally Posted by Funkybot

Does this mean auto mapping FX Zones is off the table? That seemed to me like the reason to keep them.

Not off the table at all.

With these new changes -- well, really where I think we will end up -- doesn't seem to be a need for the EZFXZone for auto mapping anymore.