Pitch or tuning shifting depending on preset

[jmechnich]

Dear P600 lovers,

I have recently (yesterday) acquired a P600 with the old GliGli mod and immediately updated to the most recent version of the FW from here. I also uploaded the standard patch set in order to be able to start out with a "clean environment".

Apparently the device has not been played in a while as the pots and switches were a bit glitchy but after using it for a bit, the condition improved significantly (probably I will still do some proper cleanup at some point).

One thing I noticed was that with a few presets, the tuning of the keyboard seemed to change by one or two semitones (IIRC preset six was one semitone off, preset seven two semitones, preset eight was fine again). Has anyone experienced something similar or has an idea what could be going on there?

It is probably a good idea to do a calibration of the synth first but as most of the presets had the same tuning, it seemed sort of odd to me.

Thanks in advance!
Jörg

[matrix12x]

I had a similar problem, but not with this preset batch. on my unit, sometimes some patches have individual notes that are mistuned. in my case it ended up being the per/note tuning. If you export the sysex for a patch you think it might be happening to, and use the syxconverter.py in terminal, it will output the patch parameters, and maybe you can see the per note tuning may be messed up.
I run it like this (with an example patch called Patch00.syx, change that to your patch name)

python3 syx_converter.py Patch00.syx

[jmechnich]

The "Tuning per Note" values all seem identical for the few presets I checked (what struck me though is that the first value of Voice Pattern (6 voices) is quite often at zero, does that mean that the voice is disabled?). I will have a closer look over the weekend but thanks so far!

[image-et-son]

As posted on Gearspace: these are patches with the frequency unit of OSC B set to semitones or free and where OSC B ist set to a base frequency which is not C. I am undecided whether to update the patch collection or jaust leave it...

BTW: the pattern is used for chord latch. Each number is the number of semitones above the base note. The fisrt note is the base note so the number of semitones is: 0. Nothing worrisome there.

[image-et-son]

I am working on it :-)

Some of the patches are tricky in that respect, especially when the base note comes from OSC A rather than OSC B. Personally, I find that the "Fine Tune" control should have been associated with OSC A rather than OSC B: OSC B is providing the base note for Sync and heavy poly-mod. Also, there's the poly-mod drift for which you need to compensate. And if you do so by using "Fine Tune" you're out of tune on the base note :-( I wonder how users managed before it was possible to choose "free" for OSC A frequency and "octave" or "semi" for OSC B. I might even think about changing the firmware so that detune is applied to OSC A (in reverse polarity) rather than OSC B. Makes much more sense. Most people wouldn't even notice, I think.

Will provide a "tuned" collection shortly.

[jmechnich]

I agree that it is a great idea to fix the set, as there are quite a few nice sounding patches in there (and to avoid confusion of people upgrading that there might be something wrong with the firmware or their synth). Let me know if I can do anything to help.

[jmechnich]

There is something else I have noticed while writing/dumping patches: when dumping a patch, there will be random characters appended to the (so far unused) name of the patch. I am not completely sure why that happens (somewhere I have read that NULL-bytes at the end of SysEx messages are ignored, but it could also be a bug). In any case, I think that an easy fix would be to put white-spaces instead. IIRC this is also how it is done on some other synths.

[image-et-son]

Hi, concerning the patch name characters; does this happen for completely new patches, e.g. based on the the default patch, for example? In the patch collection SysEx, the patch data contains the proper names of the patches as listed in the collection documentation! I thought if someone started to implement an (extended) editor, it would directly show the name. But, maybe you are areferring to additional gibberish? (I have't checked yet)

[jmechnich]

Specifically, I have uploaded P600_v2022_Patch_Collection_1.syx to the P600 and dumped it with SysEx Librarian on the Mac (triggered full dump on the P600).

The resulting SysEx file is: dump_full.syx.gz

Here the original file, the dumped file and an sdiff of both files in human-readable format, respectively:
P600_v2022_Patch_Collection_1.txt
dump_full.txt
dump_full.sdiff.txt

[image-et-son]

Hi, here's the tuned collection 1. It would be good if you could check it, e.g. tune it once and check each patch untouched against a tuned chord. Or, like Matrix12x, use a tuner, A double check is always good.

P600_v2022_Patch_Collection_1 (tuned).zip

[jmechnich]

• Patches 37, 39 are 5 semitones up
• Patch 63 is either a SFX or is 8 semitones up
• Patch 68 is either a SFX or is 4 semitones up
• Patch 80 is a bit hard to tell, maybe about a semitone up
• Patch 83 is 7 semitones up
• Patches 86, 90 are tuned sharp

There are still few which sound slightly flat or sharp but those differences are minor (and hard to tell if there is some movement).

[matrix12x]

Is that for all voices? i had found that each voice was slightly different on my synth with regards to this.

[jmechnich]

Is that for all voices? i had found that each voice was slightly different on my synth with regards to this.

Are you referring to the last sentence? I would have to take another look...so far I was only cross-checking e.g. with the previous preset. On the other hand, I have not experienced very noticeable per voice de-tuning so far (like you mentioned in your reply above from a few weeks ago), only a few envelope inconsistencies but that's for another thread here or over at GS... 😅

[image-et-son]

• Patches 37, 39 are 5 semitones up
• Patch 63 is either a SFX or is 8 semitones up
• Patch 68 is either a SFX or is 4 semitones up
• Patch 80 is a bit hard to tell, maybe about a semitone up
• Patch 83 is 7 semitones up
• Patches 86, 90 are tuned sharp

There are still few which sound slightly flat or sharp but those differences are minor (and hard to tell if there is some movement).

Ah, OK, still some patches off? I'll see to it.

I haven't changed the decade of the 60s because these are SFX. Also, I think the slightly sharp/flat patches are largely those for which a string "Fine Tune" was used to compensate for the poly-mod drift. You can fine tune much more easily using the "Fine Tune" control compare to the OSC A frequency control in setting "Free". This is precisely why I think that "Fine Tune" should apply to OSC A as a matter of principle...

[image-et-son]

OK, so now anther try. This shoudl be OK now!

In this versio I have corrected the wrong characters in patch names. When I do an export I get the same random characters. I already have an idea where it comes from...
P600_v2022_Patch_Collection_1 (tuned).zip

[jmechnich]

Thanks for the work you put into this! It seems that the presets with major offsets are fixed.

At least with my P600, there are still quite a few presets that sound a little bit wonky but that might really be due to a combination of different drifts of part values compared to your synth, and the large sensitivity to a few parameters, especially OSC (A) tuning and OSC B poly-mod amount. Sometimes it is almost impossible for me to improve on the preset because adjusting the pots is so finicky.

At some point I will have to take a closer look at some of the caps inside...

[image-et-son]

Due to the chips specific and "untuned" poly-mod feed from OSC B to OSC A, there are voice dependent differences which can lead to detuning effects. For a given note, this effect depends on which voice is assigned. It should only happen with poly-mod amount above 2 or so.

I have one P600 in which the voices are very similar with little detuning. And another one with significant differences on two voices (but all 6 from the same batch of chips :-| ). You can test it by activating square on OSC B, PWM to high value, turrning up poly-mod fully and then checking for each voice how much you need to adjust OSC A to make it harmonic. High stability means that one setting works for all voices. It still can be collectively off compared to another unit, though.

Also: calibrating the oscillators makes a difference for poly-mod tuning consistency, I found.

[image-et-son]

Can you please point out 2 - 3 patches which are "wonky" on your machine?

[jmechnich]

86 is still slightly sharp and sounds oddly out of tune
02, 17, 22 show some detuning in between voices (hence wonky), adjusting OSC B poly-mod a few steps fixes that
99 is an example where just the OSCs are a bit weirdly out of tune (so e.g. adjusting OSC A tuning fixes it)

[jmechnich]

Due to the chips specific and "untuned" poly-mod feed from OSC B to OSC A, there are voice dependent differences which can lead to detuning effects. For a given note, this effect depends on which voice is assigned. It should only happen with poly-mod amount above 2 or so.

I have one P600 in which the voices are very similar with little detuning. And another one with significant differences on two voices (but all 6 from the same batch of chips :-| ). You can test it by activating square on OSC B, PWM to high value, turrning up poly-mod fully and then checking for each voice how much you need to adjust OSC A to make it harmonic. High stability means that one setting works for all voices. It still can be collectively off compared to another unit, though.

Also: calibrating the oscillators makes a difference for poly-mod tuning consistency, I found.

I am considering @matrix12x 's DC de-coupling mod that he recently mentioned on GS as I am liking the idea a lot. As for calibrating the scaling: I have done that quite recently...but still need to find a solution for getting more easily to the pots below the panorama board I installed on top of two of them 😅

[image-et-son]

OK, now with a fix for 02, 17 and 22. Haven't touched 86 and 99. I think there might be some unit specific issues. It sounds ok on mine. If you think this could be ok, I'll publish this as the tuned version of collection 1.
P600_v2022_Patch_Collection_1 (tuned).zip

[jmechnich]

Sorry for the late reply! After the update, patch 02 is even more out of tune but 17 and 22 have slightly improved. If I find the time I might give it a go myself to fine-tune on my P600, so maybe someone else can cross-check.

[image-et-son]

Thanks! Now, there can also be instrument specific differences. In the case of 02 through poly-mod and in the case of 22 since it uses unison across 4 octaves. In any case, I tweaked it again on those 3 patches. Please let me know if it's better.
P600_v2022_Patch_Collection_1 (tuned).zip