MIDI Bypass state of blocks doesn't change after setting scene

[fret]

I'm not 100% sure this is a bug but it's making my life a right pain at the moment. For my foot controller I take the approach of querying the state of instant access switches using the MIDI_GET/SET_PARAMETER(0x02) sysex command and the bypass parameter ID. This works great when switching presets, the instant access buttons track the new state of their blocks. The problem occurs when I switch scene. I basically have to update the IA switches as if I had changed preset. Which is fine, except the results I get back are the same as when I first changed to that preset (i.e. scene 1 not the new scene).

E.g.

Axefx2 is on preset 1
Foot controller changes to preset 2 with:
9, out: b0 00 00 c0 01
Then the controller issues a bunch of commands to update the UI:
10, out: f0 00 01 74 03 02 05 01 07 00 00 00 00 00 07 f7
11, in: f0 00 01 74 03 02 05 01 07 00 00 00 10 3f 00 00 00 00 30 2e 30 30 00 36 f7
// GET/SET_PARAM Block=0x85(Drive1) ParamId=7 ParamVal=0 Text='0.00'
12, out: f0 00 01 74 03 02 70 00 16 00 00 00 00 00 62 f7
13, in: f0 00 01 74 03 02 70 00 16 00 07 00 1c 3f 00 00 00 00 31 2e 30 30 00 59 f7
// GET/SET_PARAM Block=0x70(Delay1) ParamId=22 ParamVal=7 Text='1.00'
14, out: f0 00 01 74 03 0f 09 f7
15, in: f0 00 01 74 03 0f 42 6f 75 74 69 71 75 65 20 44 6f 74 38 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 6a f7
// GET_PRESET_NAME 'Boutique Dot8 '
16, in: f0 00 01 74 03 10 f7
17, in: f0 00 01 74 03 21 27 f7
// Unknown cmd '0x21'

This is fine, preset 2 has Drive1 engaged (value&0x01 = 0 so engaged right?) and Delay1 off (value&0x01 is 1 so bypassed).

Now I change to scene 3 where Drive1 AND Delay1 are bypassed (both should have bit 0x01 set to TRUE).
37, out: f0 00 01 74 03 29 02 2d f7
38, in: f0 00 01 74 03 29 02 2d f7
// MIDI_SET_SCENE_NUMBER Scene=3
39, out: f0 00 01 74 03 02 05 01 07 00 00 00 00 00 07 f7
40, in: f0 00 01 74 03 10 f7
41, in: f0 00 01 74 03 02 05 01 07 00 00 00 10 3f 00 00 00 00 30 2e 30 30 00 36 f7
// GET/SET_PARAM Block=0x85(Drive1) ParamId=7 ParamVal=0 Text='0.00'
42, out: f0 00 01 74 03 02 70 00 16 00 00 00 00 00 62 f7
43, in: f0 00 01 74 03 02 70 00 16 00 07 00 1c 3f 00 00 00 00 31 2e 30 30 00 59 f7
// GET/SET_PARAM Block=0x70(Delay1) ParamId=22 ParamVal=7 Text='1.00'
44, out: f0 00 01 74 03 0f 09 f7
45, in: f0 00 01 74 03 0f 42 6f 75 74 69 71 75 65 20 44 6f 74 38 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 6a f7
// GET_PRESET_NAME 'Boutique Dot8 '
46, in: f0 00 01 74 03 21 27 f7
// Unknown cmd '0x21'

Now nothing has changed in the GET_PARAM responses but the Drive1 block has obviously switched to bypassed. This causes my footcontroller user interface to lose sync with what's happening in the Axefx2.

 

[pauly]

G'day Fret,

Funnily enough, I seem to have the inverse of your problem!.. Have you looked at Control->I/O-> SCene Revert?

Pauly

 

[sean.e]

0x21 --> x/y state changed or scene changed. Sync at some point after you get that -- I queue a sync for 20ms after receipt of 0x21.

 

[fret]

0x21 --> x/y state changed or scene changed. Sync at some point after you get that -- I queue a sync for 20ms after receipt of 0x21.

Is the delay important?

Why is 0x21 not documented in the wiki? (Where did you find out about it?)

 

[sean.e]

Is the delay important?

I don't remember -- I have to assume it was because I can't imagine why I would have done it that way to start with. But maybe with more current versions of the firmware it is not necessary. Here's one way to find out -- try without a delay.

Why is 0x21 not documented in the wiki?

I never got around to it. Now you can do it.

(Where did you find out about it?)

The same way I found out about all of the ones that I did document -- kept my eyes open.

 

[fret]

I don't remember -- I have to assume it was because I can't imagine why I would have done it that way to start with. But maybe with more current versions of the firmware it is not necessary. Here's one way to find out -- try without a delay.

I've tried without a delay and with a delay... the IA states never update after the preset change.

21, out: f0 00 01 74 03 29 02 2d f7
22, in: f0 00 01 74 03 29 02 2d f7
MIDI_SET_SCENE_NUMBER Scene=3
23, in: f0 00 01 74 03 21 27 f7
MIDI_STATE_CHANGED_EVENT
24, out: f0 00 01 74 03 02 05 01 07 00 00 00 00 00 07 f7
25, in: f0 00 01 74 03 02 05 01 07 00 04 00 10 3f 00 00 00 00 30 2e 30 30 00 32 f7
GET/SET_PARAM Block=0x85(Drive1) ParamId=7 ParamVal=4 Text='0.00'
26, out: f0 00 01 74 03 02 70 00 16 00 00 00 00 00 62 f7
27, in: f0 00 01 74 03 02 70 00 16 00 07 00 1c 3f 00 00 00 00 31 2e 30 30 00 59 f7
GET/SET_PARAM Block=0x70(Delay1) ParamId=22 ParamVal=7 Text='1.00'
28, out: f0 00 01 74 03 0f 09 f7
29, in: f0 00 01 74 03 0f 42 6f 75 74 69 71 75 65 20 44 6f 74 38 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 6a f7
GET_PRESET_NAME 'Boutique Dot8 '

In scene 3, Drive1 is disabled and Delay1 is enabled (the opposite of scene 1). Yet the values are indicating scene 1's state. I'll try updating to v19 and see if it's any different.

Edit: Firmware v19 has the same issue. In fact manually enabling / disabling the drive1 block using the front panel doesn't reflect in the GET_PARAM result either. So I think it's like the GET_PARAM code is reading the value straight from the (const) preset memory instead of the working values of the blocks.

 

[FractalAudio]

You can't use GET_PARAM to read the bypass state. The bypass state is a bit field with each bit representing a scene. There is a GET_BYPASS_STATES message to get the bypass state.

 

[fret]

You can't use GET_PARAM to read the bypass state. The bypass state is a bit field with each bit representing a scene. There is a GET_BYPASS_STATES message to get the bypass state.

Yah, OK that sounds reasonable. Is GET_BYPASS_STATES the same thing as "MIDI_GET_PRESET_EFFECT_BLOCKS_AND_CC_AND_BYPASS_STATE" on the public wiki?

Edit: Well the GET_PRESET_EFFECT_BLOCKS_AND_CC_AND_BYPASS_STATE works... I implemented it in my foot controller firmware and got it to pickup the IA block state after a scene change. Yay!