All my 2.10 RC3 patches have vibrato added
Closed this issue · 19 comments
I like the new firmware a lot, but all my 2.1 RC3 patches sound different after the upgrade. For instance; The original patch has VIB SPEED 80 with VIB AMOUNT 03 and after the update it has SPEED 88 and AMOUNT 28. The strange thing is that I have checked the VIB settings of many other patches and almost every patch now has this 88 - 28 setting! Isn't this very strange?
Per MIDI_Spec manual page 3 I've imported my entire (lower 'storage version 7' 2.1 RC3) patch bank via "Patch Management Mode" into the new v2022 firmware. Unfortunately, after exporting (dumping), they are not "properly converted" like the manual suggests and still sound different (the 88 - 28 vibrato settings still being added).
When I save the original (unaltered) 2.1 RC3 patch in memory, the sysex data also changes significantly. See screenshot below.
This really puts me off to use the otherwise improved and better firmware! Is there anything I did wrong, or could do to prevent this change of patches? I have many, many, many other patches stored on my computer and this means they are all useless with this firmware... [:cry]
By the lack of response (I guess due vacation) I did some more experiments and have found the following:
When I edit the storage code 07 and change to 08 in my 2.1 RC3 sysex file with Hex Fiend (Mac), and send the patch to my P600 with firmware v2022 loaded, it sounds normal (mind you, this is NOT in "Patch Manage Mode", just send the sysex file with SysEx Librarian and press REC + 0.0 in this case)
If I then dump this new 'saved' patch with F0 00 61 16 02 <00> F7, there are other bites changed, but it sounds the same non the less:
I'm I correct in saying that if I manually change the storage code from 07 to 08 in all my 2.1 RC3 patches, I'm good to go? This of course means a LOOOOT of work, but it is doable... perhaps somebody could write a batch script to change all the patches at once? The storage code is always in the same location so it could not be that hard to program... (wishful thinking).
Secondly, I really like to know if something is malfunctioning on my side... It doesn't seem right manually have to alter the sysex file in order to make it right...
I have partly 'solved' this last particular issue by editing the storage code in my ALL patches sysex file with the Find & Replace function in Hex Fiend (I highly recommend this app). But I have many single patch sysex files editing them one by one is a PITA...
Check out around line 413-456 of storage.c, I think this is directly related to what you are looking at.
Are you running this version: https://github.com/image-et-son/p600fw/releases/tag/v2022
Yes, this is exactly what's happening, thanks. But I don't understand why it's doing this "storage magic" with v7 patches, when the exact same file with manually pre-changed the storage code (v8) does not convert the VIB settings and does sound right. It seems to me there is a bug in the storage magic script for <8?
Hi hotswank. Sorry for the alte reply. I don't get notified automatically and that is the reason why I didn't answer: I hadn't seen it until just now. I will absolutely look into this in detail, but I will take a few days. Let me just give you a little bit of information which might be useful:
- The goal is to make older patches work fine on the newer version and significant testing effort has gone into this. There could still be bugs, and I would want these found to I can fixe them.
- The import looks at storage version and there are considerable rescalings from versions 7 to 8 (for example the LFO range has been decommissioned and the LFO frequency must cover to entire range, (linear) envelope ranges changed, too), so there are bound to be DATA CHANGES in order to make the patch sound THE SAME
- The conversions are applied when storage 7 is loaded into active parameters. So when you send patch data to storage directs (=patch management mode) they are stored as delivered. Only when you load and store them (REC+Nbr) are they stored in the storage version 8 format. Note: I may implement a load and store routine in the future to force conversion to version 8 in storage.
Note that when you manually change the version from 7 to 8, upon load you would miss the necessary rescalings. I would expect this to make this worse, rather than fix them.
Hi imogen, no problem... I've reverted to RC3 for the time being ;-) The strange thing is when I load my storage 7 patches, almost all of them suddenly have this VIB SPEED 88 (edit) and VIB AMOUNT 28 (edit) settings applied and sound not right (check my before-after-mp3.zip attachment earlier on). When I save the patch with REC+Nbr, the storage bit indeed has changed (08), but it does not sound right. If I manually edit the storage bit with Hex Fiend and then load it, it does sound right, even without the rescaling? I don't fully understand this storage magic, but I'm sure you do!
Would you share the version 7 (or 2.1) SysEx file for the example patch? Then I load that on mine and check where it is being changed.
Here you go...
Techno Lead Chord-8.syx.zip
OK, I found an error in the rescaling function for vib amount. To be concrete, in the 2.1 version, the parameter response was linear, but with a reduction factor of 4. In the factor of 4 is missing in the rescaling in v2022. There is also an additional small error in relation to the lower cut-off value (i.e. the value below which there is no vib amount applied). That latter bug is also present for LFO amount rescaling but it is unlikely that this would have a noticable effect.
@hotswank: in the attachment you find a test version. Could you please try it and tell me if that works ok? Maybe you have a patch with vibrato so you can also confirm that that strength is properly perserved? Please don't distribute this version as it will not be treaceable. I am collecting issues before I publish a correction (i.e. v2022.1).
Sorry about this. No matter how hard you try to consider everything these things happen. I am grateful that you took the time to bring it up. I guess there are also people out there who try the version and then dismiss it if they find a problem. So: big thank you.
p600firmware_test_#192.zip
Here you go... Techno Lead Chord-8.syx.zip
Nice patch by the way
Thanks for the test fw version, here's what I found: with zero MODWH action, the original patch had a slight LFO INIT AMT 03~04 (Live Mode display value) and VIB SPEED 80, VIB AMT 03, in v8 this is now LFO INIT AMT 00 and SPEED 88 and AMT 03. But most importantly there is some heavy "tuning" going on when min to max MODW is applied!! This alters the patch significantly in a bad way. Attached a montage of the differences in the following order:
Note C3:A=original w/zero MODW > B=test w/zero MODW > C=original max. MODW > D=test w/max. MODW;
Note C4: etc;
Note C5: etc;
Note C2: etc.
It seems the modulation wheel range "amount" in the test version has doubled: I did a AB comparison with a looped original part C and found out if I dial down the mod wheel to 50 (Live Mode display value), the amount of modulation is the same as the original's was at max. MODW VALUE...
This made me thinking the (333) MOD WHEEL RANGE is the culprit? In the RC3 v2.1 the options where (33): min, low, high, full. Now they are called (333): touch, soft, high, full. (The MIDI_Spec manual says on page 13: "The (333) Modulation Wheel Range has been reconfigured with new value which also produce different wheel actions.").
Good news.... I examined the original patch again and it has MODW RANGE set to "min" and after loading in the test fw, this is set to "soft (low)". If I manually set to "touch (min)", the modulation amount sounds the same at max. MODWH!!
I double checked this by re-loading the RC3 v2.1 fw again and manually set the MOD WHEEL RANGE in the newly loaded original v7 patch from "min" to "low (soft)" and low and behold: it sound exactly the same as test part D!
Problem solved??? Except for the INITIAL AMOUNT ISSUE perhaps....
PS I've loaded the original patch in both Patch Management Mode and Preset Mode (after REC+Nmb) and they sound identical.
BTW I love your new firmware and documentation! You must have spent many, many weeks of your life perfecting the already pretty solid firmware and made it even better... Kudos to you sir!
PS I did not test a patch with VIBRATO but will do shortly after.
Hi, thanks for testing this. Am I right that you find the MODWH action too strong? Maybe it would be better to map the old "MIN" to "TOUCH" rather than "SOFT"?
The idea with the new mod wheel actions is that people needed more travel for pitch modulation, meaning in the old setting (which was linear) is was too much very early on so that you don't have a lot of travel to play around. But since now this is exponential and ends up at high values when turning up the mod wheel fully, you get a very strong action in the last thrid of the mod wheel. Is that what you were experiencing?
To be honest I did not notice this exponential behaviour while testing, and indeed found it too strong (twice as much to be exact). If storage magic converts the old "MIN" to "SOFT" while it should be "TOUCH", I would opt for the latter because of v7 compatibility. But on the other hand if all I need to do is manually change the MODW RANGE setting, I can live with that and only a problem when playing back old MIDI projects)
I have also tested a VIBRATO patch and noticed the same thing: the original VIBRATO was set to "LOW" and in the test fw is called "SOFT" (the same) but it sounds like the old "min" setting. If manually set the new patch to "HIGH", it sounds the same again. Question though: why did you rename MIN and LOW, TOUCH and SOFT?
I have also tested a VIBRATO patch and noticed the same thing: the original VIBRATO was set to "LOW" and in the test fw is called "SOFT" (the same) but it sounds like the old "min" setting. If manually set the new patch to "HIGH", it sounds the same again. Question though: why did you rename MIN and LOW, TOUCH and SOFT?
the renaming was totally arbitrary :-) but, I guess, the main reasons were that the mod wheel action is totally different (exponential vs. linear). MIDI CC recording from a DAW will not produce the same results, even if I change it to map "MIN" to "TOUCH".
BTW I love your new firmware and documentation! You must have spent many, many weeks of your life perfecting the already pretty solid firmware and made it even better... Kudos to you sir!
PS I did not test a patch with VIBRATO but will do shortly after.
Hi there, have you had a chance to try installing the test version I sent in this thread (#192 (comment)) to see if your patch from the prior version loads and sounds correctly? I am about to publish an update version v2022_1 which includes (among other things) this fix. Thanks!
Yes, I already did: I stated that it sounds the same and only need to change the MOD and VIB settings one up or down to match the original settings (doubled or halfed). Please feel free to scroll back my and your original comments about the matter :-)
OK, sorry, I did not read your reply properly. Good, so at least the offset is OK now I think this is important for everyone, so I will publish this asap.
Thanks again for reaching out on this!