It's based on USB sniff logs I received from Stephen Rigler.
As I don't have GeNetX capable device - this needs *serious* testing
before commiting.
Possible test case would be as follows:
1. Download some .g3kp files from Sound Community, ideally if you
never applied those before to your device
2. Apply them using gdigi, saving each one to next slot
3. Run X-Edit, and save patches for the slots you saved using gdigi
4. Compare output files with original
If something goes wrong, please attach both the original and output files.
I've already spotted two mistakes in it:
1. I wan't explicitly NULL-ing Preset genetxs on creation.
2. There was endless loop.
I hope attached patch will make it working.
Test case is still just like I described in previous mail.
Attached is a g3kp file I applied with Gdigi and two g3kp files saved
out of X-Edit. 4 lines are different, but since they are "data" I have
no idea what they mean. Otherwise, the patch applied just fine with
Gdigi.
--Steve
This data is base64 encoded. In both cases there's one and only one
byte changed.
Please apply attached patch (genetx-debug-printf.patch) on top of
latest gdigi checkout with applied genetx-preset-fixed.patch (it'll
apply with few offset warnings).
Then do "./gdigi > ERICJHNS-log", apply ERICJHNS.g3kp, quit, and send
me ERICJHNS-log.
Is this the only patch you've tested? Or the only broken one?
I can't see anything wrong with messages that are sent to device, they
contain completely correct data.
Could you please apply this patch using gdigi, export it using X-edit,
and check if the changes are exactly in the same place (diff the newly
exported file with "from_gdigi.g3kp" you attached earlier)?
Please repeat above action few times.
If the changes appear in different places, please attach resulting files.
Also, it'd be nice if you did "the original" testing procedure with
few different patches.
Sorry it took so long to get to this, but I'm in the process of doing
the tests with different patches.
Attached is "ZAKKWAH.g3kp" and the result of applying it with Xedit and
Gdigi. I only found one difference this time and the log is attached.
--Steve
This looks somehow worrying as xedit couldn't re-create the data.
It might be due to some bug in earlier X-Edit version (which generated
the original file), but you never know.
Speaking of the corruption, I think we might be sending the data with
too fast pace to the device.
Could you please apply on top of your already patched (with
genetx-preset-fixed.patch and genetx-debug-printf.patch) patch that's
attached to this message (genetx-drain.patch)?
Then retry testing procedure with the ERICJHNS.g3kp and ZAKKWAH.g3kp,
and do tests with some more patches.
Applied the patch and then did the same steps with ERICJHNS.g3kp and
ZAKKWAH.g3kp. This time both presets of ZAKKWAH were identical, but
ERICJHNS had one difference. Will test a few more to see if it's just a
problem with the one patch.
--Steve
Interesting.
I guess some automated tests would help ;)
To implement those, I'd need:
1. Apply some .g3kp file using gdigi
2. Quit gdigi, type following command: "amidi --port hw:1,0,0 --dump"
(this shouldn't really print anything, press ctrl+c to stop it)
3. Type following command: "amidi --send-hex f0 00 00 10 7f 7f 7f 2a
00 04 00 41 f7 --port hw:1,0,0 --dump --receive=preset-data" (press
ctrl+c after it no longer reads data)
Then email me that .g3kp file and preset-data created by amidi (or
whatever you call it)
Please give it a fair testing.
Test case is following:
1. Download some .g3kp or .g4p files from Sound Community (depending
on your device)
2. Apply those using gdigi and store them under some slot.
3. Start X-Edit, export the patches previously stored using gdigi.
4. Compare the files for changes, if there're any, please attach both
original and newly exported files.