Mini Effect Gizmo X MIDI commands for loop order

Not in the immediate release, but it shouldn't be too hard to add later. People have been asking to adjust loop order using CCs, but it's not too clear on how something like that would work. Sysex does make a lot more sense for that purpose. MIDI 2.0 will be better still, but nothing really supports that yet.
 
I'm fine with any MIDI way of controlling loop order ;), but I understand SysEx could be quite foreign for some folks, and CCs are more widely supported. Depending on how many CCs you have remaining for use in your implementation, I wonder if something like the following could work.

DISCLAIMER: THESE DO NOT REPRESENT OFFICIAL MIDI CC NUMBERS FOR ANY RJM PRODUCT; this is a design proposal.

To lay out what a CC based approach to change loop order might look like, it would be useful to have an overview of the complete MIDI implementation. I'm sure you have something planned already, but I might guess these are the CCs needed for turning loops on/off, assuming the loops can be split from stereo to mono and controlled independently:

CC880
127
Loop 1 (stereo/mono) OFF
Loop 1 (stereo/mono) ON
CC892
CC903
CC914
CC925
CC936
CC940
127
Loop 7 (split mono) OFF
Loop 7 (split mono) ON
CC958
CC969
CC9710
CC9811
CC9912

Following a similar pattern to account for behavior in either stereo or split mono modes, loop reordering CCs might look like:

CC (Refers to a position)Value (Loop to assign)Position in audio chain
CC1011
2
3
4
5
6
7
8
9
10
11
12
First position = Loop 1
First position = Loop 2
First position = Loop 3
First position = Loop 4
First position = Loop 5
First position = Loop 6
First position = Loop 7
First position = Loop 8
First position = Loop 9
First position = Loop 10
First position = Loop 11
First position = Loop12
CC1021..12CC102 controls which loop is SECOND
CC1031..12CC103 controls which loop is THIRD
CC1044th
CC1055th
CC1066th
CC1077th
CC1088th
CC1099th
CC11010th
CC11111th
CC11212th

Possible point of confusion: The above CCs refer to a POSITION, whereas the value refers to a LOOP. Position 1 is the loop that comes first; for example, L6 could be in position 1, so L6 is the first loop (in this case, L1 is not referred to as the "first loop" even though it has the number "1" in the name).

The following are some examples of how these CCs might be used to control loop order.

Example 1A: Swap order of two stereo loops (stereo mode).

Loop order before:
L1, L2, L3, L4, L5, L6

CC message:
CC = 102, value = 6

Loop order after:
L1, L6, L3, L4, L5, L2

What happened:
Because CC102 was sent, this points to the loop that was in the second position, which in this example was L2 before the CC was sent. The value of 6 always refers to L6, regardless of what position L6 is in. So "CC102, 6" says, "move L6 to the second position." Whatever was in position 2 is moved to the position that L6 was in previously. This effectively swaps L2 and L6.

Example 1B: Swap order of two stereo loops (stereo mode).​

Loop order before:
L6, L5, L4, L3, L2, L1

CC message:
CC = 102, value = 6

Loop order after:
L5, L6, L4, L3, L2, L1

What happened:
Here we see the same CC message as in the example before, but the starting loop order is different. CC102 points to the second position, which contains L5. In the message "CC = 102, value = 6" the value 6 always refers to L6. The first step is the assignment of L6 to position two. The second step is to move what was in position two to wherever L6 was. This effectively swaps L6 and L5.

Example 2: Set the loop order (stereo mode).​

For this example, we introduce a new CC to support setting the order of multiple loops in bulk, rather than individually:

CC1000
127
BEGIN loop reordering
END loop reordering

Loop order before:
L3, L1, L4, L2, L5, L6

CC messages:
CC = 100, value = 0 // begin loop reordering
CC = 101, value = 1 // assign L1 to be first loop <--- hardware defers changes until final CC100 message received
CC = 102, value = 2 // assign L2 to be second loop
CC = 103, value = 3 // assign L3 to be third loop
CC = 100, value = 127 // end loop reordering <--- hardware sound matrix changed at this point

Loop order after:
L1, L2, L3, L4, L5, L6

What happened:
All the CC messages between the first and last CC100 messages create a transaction, such that the loop reordering happens at once, rather than individually. To construct the final result, a proposed ordering is built up by each CC message:

after "CC = 101, value = 1" --> L1, L3, L4, L2, L5, L6
after "CC = 102, value = 2" --> L1, L2, L4, L3, L5, L6
after "CC = 103, value = 3" --> L1, L2, L3, L4, L5, L6

Once the final "CC = 100, value = 127" (end loop reordering) is received, then the resulting loop order is activated. If loop ordering is fast enough in hardware, supporting begin/end transactions with CC100 would be overkill.

Example 3: Set the loop order (split mono)​

Split mono mode should work similarly to the other examples, with the understanding that e.g. for "CC = 101, value = 7" would mean, "place L7 in the first position," where L7 is the right channel of Loop 1.
 
Thanks for that, those are good ideas. I'll consider that for sure. I need to think through each method and try to find the potential issues.
 
Ok, I did some late night programming and added a Sysex command. I decided against using CCs due to their limitations. The first CC method makes it hard to specify a complete loop order, since you are always moving 2 loops per command. The second one requires the start/stop commands to get into the loop reordering mode, which makes it error prone. The method I implemented requires a controller that can send sysex, but if you have that, you can specify the whole loop order in one go.

The command is

F0 00 01 5B <sysex id> 23 00 <position 1> <position 2> ... F7

Sysex ID is configurable on each MEG unit using the editor, default is 21 or 15 in hex.

After the command ("23 00"), you specify the loop numbers in the order you need them. Loop numbers are specified as 1 through 12 (01 through 0C hex). Any loop numbers not specified are added to the end of the loop order, in numerical order.

Examples:

F0 00 01 5B 15 23 00 06 05 04 03 02 01 F7
Loop order: 6, 5, 4, 3, 2, 1, 7, 8, 9, 10, 11, 12

F0 00 01 5B 15 23 00 03 05 F7
Loop order: 3, 5, 1, 2, 4, 6, 7, 8, 9, 10, 11, 12

F0 00 01 5B 15 23 00 F7
Loop order: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

(FYI, the system requires all of the possible 12 loops be accounted for in the loop order specification, even if you aren't using them all. That's why the MEGX fills in the missing loops. If the loops don't exist in your configuration, or are turned off, they are ignored. But they still need to be in the loop order in case you ever do change your configuration. If a loop isn't in the loop order, you would never be able to turn it on).

I may add other methods to specify loop order later, but at least this gives you something to work with.
 
Ok, I did some late night programming and added a Sysex command. I decided against using CCs due to their limitations. The first CC method makes it hard to specify a complete loop order, since you are always moving 2 loops per command. The second one requires the start/stop commands to get into the loop reordering mode, which makes it error prone. The method I implemented requires a controller that can send sysex, but if you have that, you can specify the whole loop order in one go.

The command is

F0 00 01 5B <sysex id> 23 00 <position 1> <position 2> ... F7

Sysex ID is configurable on each MEG unit using the editor, default is 21 or 15 in hex.

After the command ("23 00"), you specify the loop numbers in the order you need them. Loop numbers are specified as 1 through 12 (01 through 0C hex). Any loop numbers not specified are added to the end of the loop order, in numerical order.

Examples:

F0 00 01 5B 15 23 00 06 05 04 03 02 01 F7
Loop order: 6, 5, 4, 3, 2, 1, 7, 8, 9, 10, 11, 12

F0 00 01 5B 15 23 00 03 05 F7
Loop order: 3, 5, 1, 2, 4, 6, 7, 8, 9, 10, 11, 12

F0 00 01 5B 15 23 00 F7
Loop order: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

(FYI, the system requires all of the possible 12 loops be accounted for in the loop order specification, even if you aren't using them all. That's why the MEGX fills in the missing loops. If the loops don't exist in your configuration, or are turned off, they are ignored. But they still need to be in the loop order in case you ever do change your configuration. If a loop isn't in the loop order, you would never be able to turn it on).

I may add other methods to specify loop order later, but at least this gives you something to work with.
I was trying to add a sysex that completely re-orders the pedals as a test, but unfortunately after about 7 or 8 loops the MMGT editor wouldn't allow me to enter a space between the loop numbers (ie, after loop 05 I couldn't place a space and finish entering the rest of the loops).Screen Shot 2021-08-04 at 9.30.25 AM.png
 
The problem is that the Mastermind editor only allows Sysex messages of 16 bytes. You'll have to create two messages, maybe one for everything up to "23 00" and the actual loop order in the second message.
 
Back
Top