Question about Boss Parameter Query Range

[SNewtown]

Hi Steven,

I've been building a Boss Waza Air app in Swift UI as a one page controller and your documentation of the SysEx has been invaluable, thanks for that!

I did however have one question around the querying of parameters (i.e. effects levels, state, etc) for a given preset. Presently I query 1 parameter at a time and as I increase the count of queries fired at the headphones, it's starting to behave strangely, I don't think it likes numerous sequential calls. Now I noticed you refer to a "range", the 2nd set of 4 bytes on the query (11) type messaging. So far I've left the first 3 of that second set at 0 and only used the last byte to be more or less a length (and typically set at 1 except for the preset name that is 16 bytes).

If I wanted to query more than one parameter, how does that work exactly and will I receive individual responses or one big response filled with data?

Really appreciate any input you might have based on your experience working with the Boss Katana (btw, the Boss Waza Air codes are 99% the same).

Cheers,
Stephane

[snhirsch]

Hi, Stephane. Ooof. I haven't looked at, or thought about, this code in 5 years or so. I'll need to refamiliarize myself with the SysEx signaling (i.e. reading my own document) before I'd be able to supply an intelligent answer. From the top of my head, 'range' is the size of the block you wish to write or read. It is exactly a length. I won't be able to dig back into this until Monday as I'll be out of town. Will get back to you ASAP.

[SNewtown]

Hi Steven,Thanks for responding!  Much appreciated!!No rush at all.  My specific issue is that while my individual queries for effect values work fine, when I switch presets and want to grab all the values I need, it hangs the headphones on sending all the query messages (12 of them or so).If I put delays between groups of calls it works but not consistently so it does seem like a volume of request hitting the headphones at one time.  Hence I was curious if I can get more than one effect value setting with one request (hence the range thing on the query got me curious if it would work for that).  Alternatively if you know of a SysEx query message to trigger the return of multiple effect settings for the current present preset.  Anything to bring down the number of queries as that seems to be what works best.Everything else works great, this is the last bit that has me stumped.Again your documentation of the katana messages and the checksum, etc has been super helpful, even if I’m coding this in SwiftUI not python.Thanks again!StephaneSent from my iPhoneOn May 19, 2023, at 5:24 PM, Steven Hirsch ***@***.***> wrote: Hi, Stephane. Ooof. I haven't looked at, or thought about, this code in 5 years or so. I'll need to refamiliarize myself with the SysEx signaling (i.e. reading my own document) before I'd be able to supply an intelligent answer. From the top of my head, 'range' is the size of the block you wish to write or read. It is exactly a length. I won't be able to dig back into this until Monday as I'll be out of town. Will get back to you ASAP. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[gumtown]

It is easy to request blocks of data any size you want, if you have already mastered requesting one byte, just increase the request size (00000001) to the size required (7bit base).
The requested data block will start from the given address, I would recommend requesting the entire patch in one go, which several blocks of sysx data will be received.
Then once you have the entire patch, data sections/parameters can be sifted out from that, one entire patch transaction is a lot cleaner & quicker than requesting small blocks of a patch.
Some parameters use more than one byte, such as Delay time and preDelay time, which use two bytes.
To request the whole patch, just make the request size the last address + 1.
You can request more in size up to the last of an address range (7F)
So to request a Katana patch (assuming the WAZA is the same) block size would be 00001700
Another option is to set the WAZA into editor (verbose) mode (Katana Mk1 uses F0410000000033127F000001017FF7 )
when the WAZA will send patch data when the patch is changed, and parameter values as data is changed in real-time.

[SNewtown]

Hi Colin,That is awesome info, truly appreciated and I’m happy to learn that there is indeed a way to get the entire preset settings in one query!That said, I’m a little unclear on the size/range approach when it comes to consuming the response, will each setting be identified with the same 4 byte address but concatenated?Alternatively if the verbose works for the Waza as it does for the katana, do you know if will that affect the BTS app adversely if it’s also running?  Cheers,StephaneSent from my iPadOn May 19, 2023, at 10:50 PM, Colin Willcocks ***@***.***> wrote: It is easy to request blocks of data any size you want, if you have already mastered requesting one byte, just increase the request size (00000001) to the size required (7bit base). The requested data block will start from the given address, I would recommend requesting the entire patch in one go, which several blocks of sysx data will be received. Then once you have the entire patch, data sections/parameters can be sifted out from that, one entire patch transaction is a lot cleaner & quicker than requesting small blocks of a patch. Some parameters use more than one byte, such as Delay time and preDelay time, which use two bytes. To request the whole patch, just make the request size the last address + 1. You can request more in size up to the last of an address range (7F) So to request a Katana patch (assuming the WAZA is the same) block size would be 00001700 Another option is to set the WAZA into editor (verbose) mode (Katana Mk1 uses F0410000000033127F000001017FF7 ) when the WAZA will send patch data when the patch is changed, and parameter values as data is changed in real-time. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[SNewtown]

Hey Guys, Just to let you know that I FINALLY wrap my head around this range business and I’m now down to about 4 queries when I switch presets by targeting specific regions with different query ranges. Elected to go this way since the verbose didn’t seem to work with the Waza for some reason. And retrieving a larger block would mean dissecting where things would show up based on multiple responses was getting bit unwieldy to keep track of. So I settled for what seemed to be a nice middle ground with a few queries (that return a manageable number of values and relatively easy to index and grab values). Thanks to both of you for your input! Cheers, Stephane

…

On May 19, 2023, at 10:50 PM, Colin Willcocks ***@***.***> wrote: It is easy to request blocks of data any size you want, if you have already mastered requesting one byte, just increase the request size (00000001) to the size required (7bit base). The requested data block will start from the given address, I would recommend requesting the entire patch in one go, which several blocks of sysx data will be received. Then once you have the entire patch, data sections/parameters can be sifted out from that, one entire patch transaction is a lot cleaner & quicker than requesting small blocks of a patch. Some parameters use more than one byte, such as Delay time and preDelay time, which use two bytes. To request the whole patch, just make the request size the last address + 1. You can request more in size up to the last of an address range (7F) So to request a Katana patch (assuming the WAZA is the same) block size would be 00001700 Another option is to set the WAZA into editor (verbose) mode (Katana Mk1 uses F0410000000033127F000001017FF7 ) when the WAZA will send patch data when the patch is changed, and parameter values as data is changed in real-time. — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7NVJGCKLRYWX3ZSOBNRLETXHAWP3ANCNFSM6AAAAAAYIFPN4I>. You are receiving this because you authored the thread.

[SNewtown]

Hi Steven, While I now have a better grasp on the range filtering, I have one more question for you...  How did you manage to monitor these messages?  Since I'm working with the Waza Air, there's some additional codes that aren't in the Katana line (i.e. the battery level, etc.) and while I can monitor the messages coming back from the headphones with just about any midi monitoring, I can't seem to get anything "going into" the headphones (i.e. what the app is sending as requests, commands, etc.).   Just curious to see if you used a tool capable of monitoring midi both ways. Cheers,Stephane On Friday, May 19, 2023 at 05:24:41 p.m. EDT, Steven Hirsch ***@***.***> wrote: Hi, Stephane. Ooof. I haven't looked at, or thought about, this code in 5 years or so. I'll need to refamiliarize myself with the SysEx signaling (i.e. reading my own document) before I'd be able to supply an intelligent answer. From the top of my head, 'range' is the size of the block you wish to write or read. It is exactly a length. I won't be able to dig back into this until Monday as I'll be out of town. Will get back to you ASAP. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[snhirsch]

Hi, Stephane. At the time I was working with the Katana (2016) Wireshark and USBpcap were not able to see both sides of the communication. I ended up using the demo of a commercial tool called USBlyzer. It's sort of a pain, since the demo is time-limited. There is a way to completely remove and reinstall it when time runs out, but I'm hesitant to post it publicly. Since then there has been a lot of work on Wireshark and USBpcap, so it's possible you may get that to work for you now.

[SNewtown]

No worries, and thanks!  Was wondering if I was missing something obvious, so at the very least I know it's not just me seeing only one side of the communication :) On Monday, June 5, 2023 at 10:04:55 a.m. EDT, Steven Hirsch ***@***.***> wrote: Hi, Stephane. At the time I was working with the Katana (2016) Wireshark and USBpcap were not able to see both sides of the communication. I ended up using the demo of a commercial tool called USBlyzer. It's sort of a pain, since the demo is time-limited. There is a way to completely remove and reinstall it when time runs out, but I'm hesitant to post it publicly. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[SNewtown]

Hi Steven, Last question!  (I think, well I hope)... Have you ever figured out how the preset export/import works for Boss and do you know if this can be invoked via midi commands (not sure how the data file would be passed in that concept so maybe not feasible) but maybe through a midi stream of some sort.  I'm asking cause it would amazing if presets could be exported/imported. Cheers,Stephane On Monday, June 5, 2023 at 10:04:55 a.m. EDT, Steven Hirsch ***@***.***> wrote: Hi, Stephane. At the time I was working with the Katana (2016) Wireshark and USBpcap were not able to see both sides of the communication. I ended up using the demo of a commercial tool called USBlyzer. It's sort of a pain, since the demo is time-limited. There is a way to completely remove and reinstall it when time runs out, but I'm hesitant to post it publicly. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[snhirsch]

Colin may have better suggestions, but I took a simple approach: There's an area of the Sysex address space that holds the current "live" panel settings. If you look at my code you'll see a mechanism to capture the settings and restore them as a block. That should give you some ideas.

[gumtown]

Finally logged in, had to reset my password.
You need a sysex midi implementation chart, Boss Tone Studio apps usually have this info built in the apps working folder, Windows is usually in
C:\Users\your.name\AppData\Local\Roland\BOSS TONE STUDIO for KATANA MkII\html\js\businesslogic\bts
you should find a file labelled something like "addressmap.js"

To extract sysex midi data from a device is simple, by pointing to an address start point and specifying the size of the data block required.
I have recently created and posted a simple Windows app which you enter the device, address, and block size, and it will generate the required checksum and send the data to the selected midi device. Use a midi monitoring program like "Bome's SendSX" to view the returned data.

Alternatively you could use the Katana Mk1 or Mk2 FxFloorBoard app, set it to "deBug Mode" and view the sent sysex data block requests in the bottom status-bar.