Thoughts on rapid patch change in this new universe

[snhirsch]

Since the Katana sysex map is much richer than expected, restoring a remotely managed preset presents additional challenges. My experimentation indicates that writing in the entire MIDI address range leaves a significant audible gap and is not going to play nicely with live performance. So, why not take the approach of comparing current state with target state on the controller and sending only the differential? The algorithm would have to be aware of locations that require writes to start on specific boundaries, but it would seem straightforward to implement. Thoughts?

[Beanow]

So far I have not done any testing with "best sounding" patch uploads explicitly in mind. But indeed several optimizations spring to mind that I think are worth testing.

This probably depends on how far you want to go down the optimization rabbit hole. You could use an audio interface to send a loop or a saw wave to your input, record your rec out. Measuring the audio gap. While having your hands free to send commands and change the program.

When it comes to patch changes though, my very first thought would be to try out an alternative mode, where CH1-4 are uploaded at the same time, so you can use 6 CC messages for Bank Up/Down, switch to CH1-4 using the Katanas memory alone during a song, using the banks between songs. (Again you can apply difference algorithms between the CH1-4 patches to skip sections if they are the same)

See how much of this audio gap is actually caused by SysEx protocol overhead and how much is the DSP module needing time to reconfiguring itself.

Identifying all the addresses that are linked and which can be skipped without affecting the patch.

Test if uploading deep parameters for disabled effects is audible. And if not reorder their blocks to be written last.

The difference algorithm like you mentioned. Although in a live situation that means the bridge software would need to keep a local copy of the state in advance, otherwise the extra queries would translate into latency. Wouldn't sound as bad, but still bad for live performances if switching takes an extra 100ms.

[Beanow]

One that I can certainly recommend is to read the FX1 (Mod) and FX2 (FX) type, and only write deep parameters for the relevant effect.

These are the [xx xx 01 41] and [xx xx 03 4D] values. That should save roughly 2x 200 bytes.
And the left out values are only relevant if you want to open BTS and change the type of effect and preserve the old values you had for the different effect.

[snhirsch]

That's what my bridge code is currently doing. It checks to see exactly what's assigned to button colors and saves/restores the minimum to cover these.

[skconrad]

Great work!

Just leaving a comment to let folks know Ive finally joined Github.

so "skconrad" = elantric @ VGuitarForums

Here are the known applicable URLs

• Katana - Not 5 but 28 (Sneaky) Amps and Bright setting in the Katana
  http://www.vguitarforums.com/smf/index.php?topic=20609.0

• Gumtown's Katana FxFloorBoard Editor
  http://www.vguitarforums.com/smf/index.php?topic=20625.0

• KATANA - Snhirsch's Katana MIDI Bridge for RPI / BeagleBone SBC
  http://www.vguitarforums.com/smf/index.php?topic=19782.0

TGP Thread: BOSS KATANA 刀 amplifiers (where the users are)
https://www.thegearpage.net/board/index.php?posts/23891522/

[Beanow]

Welcome @skconrad.
Since it's off topic for this issue, let's resume in #2.

[gumtown]

For fast patch change, you will need to determine the speeds and change gaps (audio dropout).
Sending random parameter differences can make the total data slower, as one byte here and one byte there can make the total package quite large mostly with sysx headers and addresses just to send one byte at a time.
The whole patch file contains a lot of redundant data, including blocks of text data, initially designed in the GT-100 patch as "Quick effects" titles for each effect.
I think a patch of relevant data can be rendered down quite small for live performance, the Katana is not going to care about patch name, or GT-100 only related data (preamp B, NS2, accel, pedalFX, Chorus, Comp, channel settings, and assigns).

If speed is not a requirement and gapless audio preferred, then toggling Katana channels 1 and 2, and writing the next patch to the alternate channel might work.
with the current patch in KAT channel 2, the next patch change, the patch data can be written to KAT Channel 1, and then a program change (P.C.) message issued for the Katana to handle the data exchange to the next patch.

[Beanow]

Perhaps you might be able to do this with a single channel. Because on recall of a CH I believe the patch is mirrored to the 60 00 region.

Even for the relevant bytes there are different upload strategies that come to mind. For example a patch like this:
Boost > Amp > Delay (Off) > Reverb (Off)

You might have configured the delay and reverb to be used with your stompbox later. Kill the boost for clean sound. Delay + reverb.

For a faster change though you might order this to be:

1. Send CH1 Boost+Amp in single bulk write (since they happen to be close).
2. Send OFF to FX1, FX2, Delay, Reverb. (4x single byte writes).
3. Recall CH1 (initial tone sounds correctly now)
4. Send remaining deep effect params to temp 60 00. (stompboxes are ready now)
5. Send remaining deep effect params to CH1. (recalling would be correct now)
6. Write anything else. Name, further FX1/2 parameters, etc.

Is that actually faster though?
Maybe not, because delay and reverb can be written in a single bulk write.

[snhirsch]

Am I correct that the maximum single-message length is 255 bytes? Unless I miscounted that seems to be how the amp quantizes returned data.

I'm going to make a quick hack to my bridge code that snapshots all preamp, boost, mod, delay, efx, reverb and chain setup ranges from 60 00 rather than trying to be clever. I can think of many schemes for optimizing write operations, but over the years I've learned that complexity often invites more problems than it solves. I want to see if this causes objectionable gaps.

With such expanded coverage of the 60 00 block, is it even necessary to save/restore the 00 00 04 xx block? That particular range tends to act like controller assigns and may be redundant in the case where we fully manage 60 00.

[Beanow]

I suspect that due to the 60 00 12 .. range being added to patches, the 00 00 04 .. section is fully redundant. Furthermore, the 00 00 04 .. part is only implemented once, so it has to be capable of being replicated from a patch.

Message size is 255 including everything, from F7 to F0 yes, that should give you 241 bytes you can write per message.

[snhirsch]

Thanks, Robin. Your observation about the single 00 00 04 .. section is right on point. I think when we start deciphering the controller assigns we'll find that the 00 00 04 .. addresses are treated as "external" controllers that are linked in various manners to the 60 00 .. region. If you think about what's possible with controller assigns, e.g. having the first 1/2 of the range make one device active as it adjusts it and the second 1/2 doing the same for a different device, this may be exactly how they deal with the boost/mod and delay/fx knobs. Have you dug into that at all?

[snhirsch]

This is looking promising. In Python, I can read the range from 60 00 01 40 - 60 00 06 1A in about 80 ms. I do need to pickup a couple of much smaller blocks below and above those limits and will have to evaluate whether its quicker to do this piecewise or in a single shot.

[snhirsch]

Question: What does the 'Volume' block in Gumtown's Fx editor map to in the GT-100 spec? Is it 'FOOT VOLUME: LEVEL' at xx xx 0x06 0x33 ?

[Beanow]

Only 1 out of 4 values actually works there, the others are fixed. https://github.com/katana-dev/docs/blob/master/tables/patch-capabilities.md#sysex-patch-blocks perhaps it changes GA-FC behavior?

[snhirsch]

So the answer appears to be "yes" to my question? That's great news. I was jumping through hoops to manage volume such that toe-down on the Midi controller never moved panel volume (04 xx block) above it's setting at capture time. The real answer is to tie the pedal to 0x60 0x00 0x06 0x33. If I need to limit the range, I can do that in the FCB1010 configuration. Cool. Should have this working in another hour or so.