Zoom 07 sysex seems to return number of patches and size?

[shooking]

f0 52 00 6e 06 32 00 78 05 f7

I recall when @mungewell was looking at deconstructing the midi the 0x7805 kept appearing.
This I believe is 0x5 78

But look - maybe a coincidence - except the other pedals are returning values corresponding to their number of patches ...

b1xfour

pi@raspberrypi:~/Software/ZoomPedal $ !he
hexdump -C p_07_007.bin 
00000000  f0 52 00 6e 06 32 00 78  05 f7                    |.R.n.2.x..|
0000000a

b1on

pi@raspberrypi:~/Software/ZoomPedalB1ON $ !hex
hexdump -C p_07_007.bin 
00000000  f0 52 00 65 06 64 00 70  00 f7                    |.R.e.d.p..|
0000000a

ms-70 cdr

pi@raspberrypi:~/Software/ZoomPedalMS70CDR $ !hex
hexdump -C p_07_007.bin 
00000000  f0 52 00 61 06 32 00 7a  00 f7                    |.R.a.2.z..|
0000000a

Will follow up on my other pedals.

pi@raspberrypi:~/Software/ZoomPedal $ grep 78 *.sh
GetZD2Block.sh:amidi -p ${MIDI_DEV} -S "F0 52 00 6E 60 04 23 00 00 04 00 78 05 00 00 00 00 00 00 00 F7" -r temp.bin -t 1 ; hexdump -C temp.bin
GetZT2Block.sh:amidi -p ${MIDI_DEV} -S "F0 52 00 6E 60 22 40 00 00 00 00 78 05 00 00 00 F7" -r temp.bin -t 1 ; hexdump -C temp.bin

[mungewell]

You are probably right, but I think this may be 7bit (ie 0x05 * 128 + 0x78).

It's also returned by "f0 52 00 6e 44 f7"
https://github.com/mungewell/zoom-zt2/blob/master/zoomzt2.py#L455

GCE-3 pretending to be G5n

$ amidi -p hw:1,0,0 -S  "f0 52 00 6e 44 f7" -r temp.bin -t 2; hexdump -C temp.bin

30 bytes read
00000000  f0 52 00 6e 43 48 01 78  05 48 01 04 00 02 00 00  |.R.nCH.x.H......|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 f7        |..............|
0000001e

[shooking]

Yes for sure it is 7bit. I checked - seems to make sense.
Recall I also told you about 0x44 a while back when I requested if you can make the ZD2 parse variable size rather than 760 (5 x 128 + 7x16 + 8). The above sysex message is called a Lewis in my house (after his F1 car number - albeit Dec rather than hex).

If your zt2 could accommodate the differing patch size (given we have the evidence it does change) then likely I can simply include your program rather than my hack.

I do need to make a DB of the FX and compare the ZT2 with the DB. If I have it cached then use that. Else pull from pedal, add to DB cache. Will make pedal state determination much quicker.

Oh forgot to mention the 44 also returns the bank size and number of patches. Older pedals only have this 0x7 - they don't have the 0x44. My guess is when there were more than 127 patches then Zoom had to invent new way to annotate the access?

[mungewell]

I have this list of effects:
https://github.com/mungewell/zoom-zt2/blob/master/zoom_fx/master.txt

But isn't the zt2 file more appropriate?

[shooking]

So I followed your lead here;

Identify pedal
Determine patch size, number of patches, bank size.
Modify the ZD2 size to accept patch
Read ZT2
Iterate thru the pedal- pull out the FX and stick them in python array
Iterate thru the patches - replace FXId pointer with FX and fold in parameters
Render in gui

So this gets me a basic representation of the.state of a pedal.

It seems a lot of embedded friends don't want to wait for the above. Young people and their need for instant gratification detests me ...

So like your master list - an easy way to compare any ZD2 to the list and merge it in could make sense - though no idea where the average embedded proc will save that info. I was thinking for my own project to cache to make it easier.

I can see Zoom also looks up the Ascii - so as to present the values in pedal format rather than midi.

I was also thinking it would be possible to persit the ZD2 and dynamically load them in depending on what patch someone attempts to upload. Could be quite kinky.

There again today I have a few patches on the G5n with pedal params for appropriate control - mostly volume. Didn't need to bend down and fine turn params. Just FX on or off. I would likely want fine control when setting up patches or using with a synth