how can you identify the unique patch number?

[fotosettore]

Hello
another question, this time about identifying the effects of the patch.
As mentioned in the patch data table (https://github.com/g200kg/zoom-ms-utility/blob/master/midimessage.md), the 70CDR zoom returns a set of 146 bytes.
To identify (for example) the parameters of the CRY effect, we know that we need to look for the number 0x40600004 (as mentioned in effectlist.js).

In case the effect is the first, I understood that 60 is the byte 6, 00 is the byte 7, 04 is the byte 9 but I have not understood which is the rule to understand the 40.
Is should be the byte n.5 but this number changes in relation to the change in the values of the parameters, so it is impossible for me to understand the calculation logic.
In other words: if I have selected the CRY effect, how can I find the corresponding number 0x40600004 within the 146 bytes?
Thanks for your help.

[g200kg]

It comes from byte5.

First of all, this ID representing the effect type is not an official number.
It is just made by connecting the bits that seem to represent the effect type from the patch data.

From midimessage.md:
Byte 5, byte 6, byte 7, byte9 contain bits that represent the type of effect, but I don't know how to use bit5 ... 4 of byte 5 and bit6..3 of byte7. However, these may also be reserve bits that represent the type of effect.

Therefore, I made IDs by mask only the bits that are used for other purposes:
ID = ((byte5 & 0x70) << 24) | ((byte6 & 0x7e) << 16) | ((byte7 & 0x7f) << 8) | (byte9 & 0x1f);

[fotosettore]

First of all, thank you so much for your useful reply, I've been able to obtain the info using the mask but only for the effect in the first position.
Before to write here again, I tried to put two "similar" effects in position 2
EXCITER ---> 0x00600004
CRY --------> 0x40600004
please note that there is only a byte that is different is the first : 40 instead of 00

So, output for my test is :

EXITER
byte 21 : 00
byte 25 : 60
byte 26 : 00
byte 30 : 04

CRY
byte 21 : 04
byte 25 : 60
byte 26 : 00
byte 30 : 04

and i noted that byte 21 make difference.

Using the bitshifting of your reply, the "40" of CRY never appears, so formula to obtain the right number is different.
Unfortunately I'm not able to use the bitshifting formula so please help me to get the ID of effects 2 and 3 too.

Thank you in advance
Domo arigatou gozaimashita

[g200kg]

Oh I see. I was misunderstanding.
The previous formula was incomplete.

The most significant byte of the ID value is always 0x00 or 0x40.
And this reflects the bits in strange places like byte5.bit6 represented by message.md.

1st byte5.bit6
2nd byte21.bit2
3rd byte 45.b5
4th byte64.bit4
5th byte85.bit5
6th byte101.bit0

then,...

1st : ID = ((byte5 & 0x40) << 24) | ((byte6 & 0x7e) << 16) | ((byte7 & 0x07) << 8) | (byte9 & 0x1f);
2nd : ID = ((byte21 & 0x04) << 28) | ((byte26 & 0x7e) << 16) | ((byte27 & 0x07) << 8) | (byte30 & 0x1f);
3rd : ID = ((byte45 & 0x02) << 25) | ((byte47 & 0x7e) << 16) | ((byte48 & 0x07) << 8) | (byte50 & 0x1f);
4th : ID = ((byte61 & 0x02) << 29) | ((byte67 & 0x7e) << 16) | ((byte68 & 0x07) << 8) | (byte71 & 0x1f);
5th : ID = ((byte85 & 0x10) << 26) | ((byte88 & 0x7e) << 16) | ((byte89 & 0x07) << 8) | (byte91 & 0x1f);
6th : ID = ((byte101 & 0x01) << 30) | ((byte108 & 0x7e) << 16) | ((byte110 & 0x07) << 8) | (byte112 & 0x1f);

The exact formula for retrieving the ID from the patch data is as above. These processes are based on the apatch.prototype.bits table of apatch.js.

Thank you :-)

[fotosettore]

Really many thanks again for your help.
please confirm me two little errors in your previous message:

4th byte64.bit4
is wrong and must be corrected in
4th byte61.bit4

3rd : ID = ((byte45 & 0x02) << 25) ....
is wrong and should be corrected in
3rd : ID = ((byte45 & 0x20) << 25) ...

all other effects seem work fine.
in 3rd effect, using 20 instead 02, seems work fine too. but i need your confirmation.

thanks

[g200kg]

I'm sorry I made a mistake again.

you are right.
Thank you!!

[vincent1000]

@g200kg sorry to contact you here. I have interest in rovee and want to integrate it into my app. But I don't find any license about it, I am not sure whether the integration is feasible and what license I should follow. Could you provide email? I can show more details.

[shooking]

So I believe this project works with the raw sysex right?
That is what comes out from the pedal?
If these pedals are anything like the B1On or the B1XFour then to really see the values you need to translate from raw to binary and the patterns become clearer

I dont have one of these 70CDRs (I might get one if I can find one cheap enough)
On my page here I reference the Sysex for a B1XFour

https://github.com/shooking/ZoomPedalFun/wiki/De-re-B1XFour

This has slightly more rich sysex than these pedals. For example Mungwell discovered you can "ask" the pedal for its contents.

You can find more details of how we decoded the FXID and Group ID here.
mungewell/zoom-zt2#28

So on a B1XFour one can do stuff like

probeString="F0 52 00 6E 64 03 00 ${hexSlot} ${OnOff} ${hexFXValueLow} ${hexFXValueHigh} 00 ${hexGroupVal} 00 F7"

And notice these are the processed values, not the raw
There are still some fun and games - the GID seems to need to be bitshifted.
But on the B1X at least one can send params to set FX slot N to take a new FX and one can set the parameters.

For the B1On I am stuck - I can indirectly find the FXIDs and I can set those.
But I cannot find a way to set the group ID and I KNOW this is required else I get Missing Effects ... and I used to get that on the B1X until I discovered a way to "see" it either from the firmware, the patch dumps or via Mungewell's "just tell me pedal!".

I think that is what you are looking for with these pedals right?
So often times same FXID but different group ID
If you dont get these right you get either the wrong FX or missing.

[shooking]

I did get a MS70 CDR. And I am updating info about them on my wiki and site:

https://github.com/shooking/ZoomPedalFun/tree/main/MS70CDR

I will write up the 7bit (raw) -> 8bit(cooked) format. It is a bit easier to understand what happens to the bits than what g200kg has done, but it all ends up in the same result.

Please look at the wiki (creating it soon) to find what you are looking for.