Feature: Performance View

[seangoodvibes]

Performance View

Description:

Polyend Play inspired Performance View for the Deluge.

Each column represents a different "FX" and each pad/row in the column corresponds to a different FX value.

Specifications:

• Perform FX menu to edit Song level parameters and enable/disable editing mode.
• 16 FX columns
  • 1 Param assigned to each column
• 8 FX values per column
  • Long press pads in a column to change value momentarily and reset it (to the value before the pad was pressed) upon pad release
  • Short press pads in a column to the change value until you press the pad again (resetting it to the value before the pad was pressed)
• Editing mode to edit the FX values assigned to each pad and the parameter assigned to each FX column
• Save defaults as PerformanceView.xml file
  • Adjustable default Values assigned to each FX column via "Value" editing mode or PerformanceView.xml
  • Adjustable default Param assigned to each FX column via "Param" editing mode or PerformanceView.xml
  • Adjustable default "held pad" settings for each FX column via Performance View or PerformanceView.xml (simply change a held pad in Performance View and save the layout to save the layout with the held pads).
• Load defaults from PerformanceView.xml file

Usage:

1) Enter performance view from song view / grid view / arranger view by pressing keyboard button

2) Short press a pad in the columns to hold that pad's value (parameter and held value is displayed on the screen)

• Note: If you save the layout while pad's are in a "held" state, the next time you re-load that layout it will re-load the held pad's and change the associated parameter's value based on the previous held state.

3) Long press a pad in the columns to play the FX but not hold it (when you let go of the pad it will snap back to previous value).

4) You can edit the default values for each pad in the Performance View by entering a "Value Editing Mode." Here are the instructions for Value Editing mode:

Enter using Shift + Keyboard button

or

Enter using the menu

• Enter/Exit Editing Mode by pressing down on the Select Encoder to open up the Perform FX Menu
• In the Perform FX menu, select the "Editing Mode" sub menu and press down on Select Encoder to enter the menu
• Change Editing Mode to "Value"

Value Editing Mode:

• While in the Value Editor, pressing any pad on the grid will open up the menu corresponding to the parameter for that pad. It will display the current value assigned to that pad when you pressed it.
• You can edit that pad's value by turning the select encoder while selecting a single pad (so it's highlighted white) or holding down on that pad. The updated value will be reflected on the display.
• After you have edited a value, the Save button will start flashing to indicate that you have "Unsaved" changes. Press the save button to save your changes. Once saved, the Save button will stop blinking. To avoid being distracting, the save button will only blink when you are in editing mode. If you exit editing mode it will stop blinking and if you re-enter editing mode it will blink again to remind you that you have unsaved changes.
• You can re-load saved changes using the Load button. This will cause you to lose unsaved changes and the Save button will stop blinking.
• Defaults are saved in an XML file on your SD card called "PerformanceView.XML" - deleting this file will cause the PerformanceView to revert back to its regular default values for each pad.
• Once you are done with editing mode, repeat the steps above to set editing mode back to "Disabled" and exit out of the menu to use Performance View in its regular state

5) You can edit the Parameter assigned to each FX column by entering a "Param Editing Mode." Here are the instructions for Param Editing mode:

Enter using Shift + Keyboard button. You will need to cycle passed the Value Editing Mode to enter the Param Editing Mode.

or

Enter using the menu

• Enter/Exit Editing Mode by pressing down on the Select Encoder to open up the Perform FX Menu
• In the Perform FX menu, select the "Editing Mode" sub menu and press down on Select Encoder to enter the menu
• Change Editing Mode to "Param"

Param Editing Mode:

• Param Editing will show you an overview of the parameters that are assignable to the FX columns in Performance View by lighting dimly the shortcut pads for these parameters.
• Parameters that have been assigned to one or more columns will have their shortcut pads lit up bright white.
• Press on a shortcut pad to illuminate the FX columns that that parameter has been assigned to.
• While holding a shortcut pad, press on the FX columns to assign or unassign a parameter to/from a column.
• Press <> + back to clear all existing Parameter assignments.
• When a Parameter has not been assigned to a column, that column will be lit grey and be unusable in Performance View until you assign a Parameter. This applies to editing the values for that FX column as well (assign a Parameter first, then you can edit the values).
• Parameters are saved to PerformanceView.xml. You can manually edit the Parameters in the xml as well, but you must use the exact Parameter names. It is recommended to save a fresh PerformanceView.xml and back it up so you have a record of the Parameter Names.

6) You can Undo/Redo your changes in Performance View

Default FX and Colour Assignments

• The default Param and Colour Assignments for each FX column in Performance View are as follows
• Note: if you re-arrange the parameters to different FX columns, they will bring the colours noted below with them.

Columns:

Red:
1 = LPF Cutoff
2 = LPF Resonance

Orange:
3 = HPF Cutoff
4 = HPF Resonance

Yellow:
5 = Bass EQ
6 = Treble EQ

Light Green:
7 = Reverb

Light Blue:
8 = Delay Amount
9 = Delay Rate

Light Pink:
10 = MOD-FX Rate
11 = MOD-FX Depth
12 = MOD-FX Feedback
13 = MOD-FX Offset

Dark Pink:
14 = Decimation
15 = Bitcrush

Dark Blue:
16 = Stutter Rate + Stutter Trigger

PR Summary

Summary of additions provided as part of this PR:

• New performance view (accessible using the Keyboard button from Song View and Arranger View)
• Render "Song View" on the display in Song View
• Render "Arranger View" on the display in Arranger View
• Add new Song FX menu to Song View and Arranger View (accessed by pressing Select Encoder)
• Adjusted Quantized Stutter implementation from PR Quantized Stutter FX #357 so that it does not need to change the value of the stutter rate parameter in order to do it's quantized stutter calculation

[sapphire-arches]

I'm somewhat concerned about the memory use of this feature but it's probably worth the squeeze. For posterity after this change, we're 23712 bytes larger than the nightly from yesterday.

[m-m-adams]

Haven't looked at performance_session_view yet

[m-m-adams]

I think this is looking pretty good! I'd like to see the change from using knob pos to directly using param values instead for future compatibility, no reason to limit the internal resolution of performance view to 7 bits

[m-m-adams]

I think you should be storing the param value and not the knob pos - params have higher accuracy than knob position allows and this could cause issues in the future

Also you're converting the knob pos back to a param value before using it anyway

[seangoodvibes]

Does this change need to be a part of this PR? As much as I want to make it, I don't know if I have the energy atm to go through and change everything from knobPos to value. I know it's not a complex change, but I do use the knobPos for the value displayed on the screen, for quantized stutter calculations, for delay calculations, etc so I would want to make sure I'm not breaking things.

[m-m-adams]

This function should work on param values instead of knob pos - will allow greater accuracy in the future (particularly for things like stutter where the knob pos is very coarse)

[m-m-adams]

This is a sanity check to make sure the timeline counter is the song level global effectable?

[seangoodvibes]

yea it's a sanity check to make sure you're dealing with the same model stack as the active mod controllable stack. I've seen it used elsewhere in the codebase so I just adopted the same practice.

[m-m-adams]

I think this should use the param value range instead of knobpos

[m-m-adams]

You should implement a copy method instead of using memcpy - memcpy is brittle and any speed differences won't matter here

[seangoodvibes]

you mean like this?

copyLayout(layoutForPerformance[xDisplay], defaultLayoutForPerformance[xDisplay]);

PerformanceSessionView::copyLayout(ParamForPerformance& layoutTo, ParamForPerformance& layoutFrom) {

layoutTo.paramKind = layoutFrom.paramKind;
layoutTo.paramID = layoutFrom.paramID;
layoutTo.xDisplay = layoutFrom.xDisplay;
layoutTo.yDisplay = layoutFrom.yDisplay;
layoutTo.rowColour[0] = layoutFrom.rowColour[0];
layoutTo.rowColour[1] = layoutFrom.rowColour[1];
layoutTo.rowColour[2] = layoutFrom.rowColour[2];
layoutTo.rowTailColour[0] = layoutFrom.rowTailColour[0];
layoutTo.rowTailColour[1] = layoutFrom.rowTailColour[1];
layoutTo.rowTailColour[2] = layoutFrom.rowTailColour[2];

}

[PaulFreund]

I need to look in more detail but this would generate a lot more code compared to memcpy and is more error prone, any particular reason?

[seangoodvibes]

I need to look in more detail but this would generate a lot more code compared to memcpy and is more error prone, any particular reason?

Yea cause I'd need to create copy functions for each type of struct I'm trying to copy (so 3 copy functions). I initially thought of this but thought memcpy was cleaner so I went with memcpy.

[m-m-adams]

I need to look in more detail but this would generate a lot more code compared to memcpy and is more error prone, any particular reason?

In case something is added to the type that requires re initialization, or otherwise wouldn't be valid following a memcpy. I don't have super strong opinions but memcpy on a class makes me nervous

Using memcpy to move over the colour arrays individually would make sense to me