Still under investigation: Switching from poly mode to unison with the seq running leads to CV glitches. On a still cold p600

[el-folie]

Okay, sorry, not a bug per se, seems to be completely related to cold hardware not being ready for fast CV action for about 20 minutes. After that no glitchy behaviour anymore. Will monitor this further though. And this doesn´t occurr on the Z80, even with a still cold p600. So it must be a timing relevant problem connected to the much faster update rate and higher precision of the Teensy. On the Z80 this problem probably doesn´t occurr because of the slower refresh rate and lower resolution, so much more forgiving in terms of variances.

Weird behaviour: I tested this through all imogen alphas back to gligli 2.1rc3 (no seq on 2.0) - so it´s an old bug or glitch. There is no such glitchyness with the Z80 in place, so it must be a gligli software issue. The glitches don´t always occurr at slow seq speeds but always at high seq speeds.

1. It sounds as if the multitude of simultaneous "note ons" are freaking out the DAC timing-wise. My first thought was, that on the Sequential OS they maybe managed to prevent this by tiny wait-states between the simultaneous "note-ons".
2. BUT - it also sounds as if the "envelope hold" aspect in unison mode might be the problem, because sometimes the DAC spits out three same pitched notes in a row even though the sequence is high-low-high-low with C0 and C5. So it seems as if the DAC for a split second can´t decide if the pitch CV is meant for the high or the low note and makes a wrong decision. So the question could be, which parts before the DAC may lead to a wrong decision in timing of the CVs. I suspect timing is the critical thing with this bug or glitch.
3. I now think the glitch is solely unison mode/hold-related because it also happens in one-note unison.
4. I verified the problem by turning off all voices but one. I went through each voice individually, the glitch is happing in every single voice.
5. Now the next weird thing: the issue seems to be related to the p600 still being cold right after 1st powering up. After warmed up for 20 min it seems to become more stable and the sequence running having less and less glitches. That would lead me more to the direction of hardware/chips not being at their operating point soon after powering up, leading to wrong timing/CV.
6. What´s funny: in 6-note-unison the max seq speed is slower than in poly mode or single note unison. Weird machine...

I´ll need to investigate this further to know if it´s only my machine again.

I will do audio files to exemplify.

Just to be clearer, the glitches also happen in unison mode and then switching on a running sequence. Switching between poly and unison only instantly shows the difference between "no glitches - switching to unison - glitches". So the glitches are not connected to the switching itself but the unison mode.

(These random glitches made me crazy for years already, they were hidden/masked also by the former pitch wheel glitches, which have gone after imogen´s pitch wheel fix.)

[el-folie]

OT: https://www.youtube.com/watch?v=DvRv0TlMI5M&ab_channel=AlexBall

The outro starting at 10:03. I think I desperately need a P5rev3. Every noise this damn thing makes is my youth in the 70s/80s...

[image-et-son]

This brings me back to one issue that I put on the backlog: a function to restore the equal tempered tuning. I even think that the "in memory" live patch should always restore the equeal tempered tuning. You see what happens if something goes wrong: you can never restore it! I even think that the patch should only store the deviation from equal tempered, not the full tuning.

Anyway, the bug needs to be found.

And thinking about it: if the tuning gets lost inside the live patch then SysEx firmware does also not help you - you need the hex. It's a really dangerous design flaw of the firmware! I wonder how many people had accidents because of that ...

[el-folie]

Well, you´re already on it! All notes´ tuning on zero - that´s quite some news! :-)

[el-folie]

But why does SysEx not help to reflash the tuning information? Is it only contained in the hex file? I so far thought that the tuning bug somehow also destroyed the resident OS´s capability to load SysEx data because the "moving square" on the LCD stopped while reflashing by SysEx...

Generally I´d think not too many people would rely on the new alphas to make music, most will be on a stable release and would wait for a new one...

[matrix12x]

"But why does SysEx not help to reflash the tuning information?" because that seems to be patch level info.

[matrix12x]

ok, never thought about this, but better question is, why is per note tuning stored in the patch? Seems dangerous, like if you get a corrupted patch, there is no fix and you lose the patch.

[el-folie]

"But why does SysEx not help to reflash the tuning information?" because that seems to be patch level info.

(And where does the panel/live mode "patch" get its tuning from?) Forget it - over my head anyway...

As to per patch tuning memory: I guess it makes sense because a patch could also contain specific micro tuning information or similar. It should at least be possible to reprogram it, if it´s getting lost.

[matrix12x]

In real life does anyone actually use micro tuning?

[el-folie]

I mostly wouldn´t... but some guys with extremely sensitive ears might want to tune individual chords harmonics... I might try it one day just to hear how it sounds/feels ;-)

[image-et-son]

But why does SysEx not help to reflash the tuning information? Is it only contained in the hex file? I so far thought that the tuning bug somehow also destroyed the resident OS´s capability to load SysEx data because the "moving square" on the LCD stopped while reflashing by SysEx...

Generally I´d think not too many people would rely on the new alphas to make music, most will be on a stable release and would wait for a new one...

The SysEx firmware leaves all part of the storage intact which contain patch data, including the storage for the parameters in manuel mode for which there are no controls on the panel. That includes all menu parameters and tuning. The idea is that you do the upgrade an continue working as before. When there is NO patch data stored in that special place where manual patch parameters are stored, the default patch is used as a new starting point and that default patch contains that equal tempered tuning. This is why when the fault occurs you can still use the default patch normally.

[image-et-son]

ok, never thought about this, but better question is, why is per note tuning stored in the patch? Seems dangerous, like if you get a corrupted patch, there is no fix and you lose the patch.

Yes, that is a bad idea. The better way - if anything - would be to stored the deviation from equal tempered in the patch. That defaults nicely to zero.

[matrix12x]

I can't seem to force this to happen. I've been in panel mode for maybe an hour and no issues. Alpha 14. I've hit every button possible in panel mode also. I switched back and forth from gligli to SCI, left it in SCI. turned all the knobs. pressed "to tape." initiated the default patch. went pack and forth to preset mode.

I'm going to leave it on and check it in an hour.

[matrix12x]

ok, never thought about this, but better question is, why is per note tuning stored in the patch? Seems dangerous, like if you get a corrupted patch, there is no fix and you lose the patch.

Yes, that is a bad idea. The better way - if anything - would be to stored the deviation from equal tempered in the patch. That defaults nicely to zero.

I agree 100%!

[image-et-son]

I can't seem to force this to happen. I've been in panel mode for maybe an hour and no issues. Alpha 14. I've hit every button possible in panel mode also. I switched back and forth from gligli to SCI, left it in SCI. turned all the knobs. pressed "to tape." initiated the default patch. went pack and forth to preset mode.

I'm going to leave it on and check it in an hour.

My suspicion: it happens in the synth_init() routine, so directly after you switch in on. I have no idea what condition is necessary, but it only happened on power up in my case. --> el-folie?

[el-folie]

Okay, some news:

• tried to reflash by hex to get back tuning
• doesn´t work by using RC14 until alpha13.4
• had luck with "p600firmware_v2.x-alpha-12.20220119.hex"

So, maybe the tuning bug first bit into alpha 13.... But just a guess of course.

[el-folie]

I can't seem to force this to happen. I've been in panel mode for maybe an hour and no issues. Alpha 14. I've hit every button possible in panel mode also. I switched back and forth from gligli to SCI, left it in SCI. turned all the knobs. pressed "to tape." initiated the default patch. went pack and forth to preset mode. I'm going to leave it on and check it in an hour.

My suspicion: it happens in the synth_init() routine, so directly after you switch in on. I have no idea what condition is necessary, but it only happened on power up in my case. --> el-folie?

I think it´s half a yes, because I somehow remember it also happening in use...

[image-et-son]

I'll be off for two hours or so now. But with a good feeling: I think this can be fixed and I am very happy we came across this general issue

[matrix12x]

So I just turned it off and on while in manual mode and Drive went to zero and the tuning went to zero. I'll post the patch.

[el-folie]

I'll be off for two hours or so now. But with a good feeling: I think this can be fixed and I am very happy we came across this general issue

I´m happy that you feel the bug can be solved. :-)

[el-folie]

So I just turned it off and on while in manual mode and Drive went to zero and the tuning went to zero. I'll post the patch.

Was it GliGLi or SCI mode? But I guess happens in both modes.

[matrix12x]

SCI mode. also the sysex patch is smaller, its 101 instead of 161.

[image-et-son]

SCI mode. also the sysex patch is smaller, its 101 instead of 161.

The SysEx stops at the last non-zero value

[matrix12x]

so maybe whats happening is panel mode is not storing this values at all, and when you switch off and then on, they are zero values

[matrix12x]

Patch Number: 23 Storage version is 8 Fequency A : 21728 Volume A : 65518 PWA : 8064 Fequency B : 15856 Volume B : 65521 PWB : 51136 Frequency Fine B : 53570 Cutoff : 65520 Resonance : 0 Filter Envelope Amount : 32768 Filter Release : 62464 Filter Sustain : 35264 Filter Decay : 65280 Filter Attack : 34816 Amp Release : 36608 Amp Sustain : 39360 Amp Decay : 25344 Amp Attack : 0 Poly Mod Envelope Amount : 32768 Poly Mod OSC B : 42368 LFO Frequency : 44224 LFO Amount : 48 Glide : 0 Amp Velocity : 0 Filter Velocity : 0 Saw A : 1 Tri A : 0 SQR A : 0 Saw B : 1 Tri B : 0 SQR B : 0 Sync : 0 Poly Mod Frequency A : 0 Poly Mod Filter : 0 LFO Shape : 1 LFO Sync : 0 LPF Targets : 1 Tracking Shift : 2 Filter Envelope Shape : 0 Filter Envelope Speed : 0 Amp Envelope Shape : 0 Amp Envelope Speed : 0 Unison : 1 Assigner Priority : 0 Bender Semitones : 0 Bender Target : 0 Envelope Routing : 0 Chromatic Pitch : 0 Modulation Delay : 0 Vibrato Frequency : 0 Vibrato Amount : 0 Unison Detune : 0 (unused, arp/seq clock slot) : 0 Modulation Wheel Target : 0 Vibrato Target : 0 Voice Pattern (6 voices) ( 1 of 6 ): 0 Voice Pattern (6 voices) ( 2 of 6 ): 0 Voice Pattern (6 voices) ( 3 of 6 ): 0 Voice Pattern (6 voices) ( 4 of 6 ): 0 Voice Pattern (6 voices) ( 5 of 6 ): 0 Voice Pattern (6 voices) ( 6 of 6 ): 0 Tuning per Note (12 notes) ( 1 of 12 ): 0 Tuning per Note (12 notes) ( 2 of 12 ): 0 Tuning per Note (12 notes) ( 3 of 12 ): 0 Tuning per Note (12 notes) ( 4 of 12 ): 0 Tuning per Note (12 notes) ( 5 of 12 ): 0 Tuning per Note (12 notes) ( 6 of 12 ): 0 Tuning per Note (12 notes) ( 7 of 12 ): 0 Tuning per Note (12 notes) ( 8 of 12 ): 0 Tuning per Note (12 notes) ( 9 of 12 ): 0 Tuning per Note (12 notes) ( 10 of 12 ): 0 Tuning per Note (12 notes) ( 11 of 12 ): 0 Tuning per Note (12 notes) ( 12 of 12 ): 0 PW Bug : 0 Vintage : 0 Ext Voltage : 0

[matrix12x]

BTW, I got a corrupted patch again. not corrupted like above, but corrupted like "Storage Magic is not found"

[image-et-son]

BTW, I got a corrupted patch again. not corrupted like above, but corrupted like "Storage Magic is not found"

Irritating. After the last time I didn't really follow up on this topic. I would have thought that with a wrong "Storage Magic" the patch wouldn't load normally because if the check in the function storageLoad() in storage.c. It would load as the default patch instead. Could you please try to 1) re-load the SysEx in preset mode (e.g. into the active controls) and 2) into storage in patch management mode and then select it and see if that patch creates problems, e.g. loads as the default patch instead in the two cases?

BTW: you should download the last storage spec file from the repository. The one you were using here is outdated.

[matrix12x]

In both cases, they were not patches that were preexisting. Thus they never were never sent over the P600's MIDI IN. I didn't assume they were corrupt in the P600's memory, because the patch sounded/sounds fine. I kind of assumed it was corrupted the process of exporting. But maybe you are right.

I made them on the spot (I.e., I tweaked some knobs and hit save), and in both cases (this time and the time you pointed it out to me), they were both stored as patch 20.

I just updated the storage spec file. I will try 1 and 2 above. I'll send the P600 this corrupted file in preset and MIDI management mode.

Edit: note) I first turned up mix on the patch. Then I went into MIDI Management mode and resent the patch to my computer and saved as patch20ok.syx This one reads fine in your syx_converter.

Archive.zip .syx patches attached.

I now stored a new very different patch in plot 20 so I could hear the differences when I send the patch 20 syx to it.

1) I sent the 'bad" patch (renamed Patch20Bad.syx) to the P600 from my computer in preset mode. It loads - no problem into memory. note, for some reason mix is zeroed out and all of the waveform switches are zeroed out for this "bad" patch."

2) I sent the 'bad" patch to the P600 from my computer in MIDI Management mode. The P600 ignores the patch and will not load it. I then sent the "good" patch 20 and it sends fine.

[image-et-son]

Thanks. when I load you "bad" patch then it does not work either way: in preset mode sending the patch forces the P600 to load the default patch (with the flag "makesound=0" - the same as the normal default patch but with no wave shape selected). In patch management mode it is ignored as you say.

Do you have that consistently from slot 20? Or is it kind of random / no perceivable pattern?

[matrix12x]

these two times are the only times I have seen it. But I have not been looking for it. I would still not have you bother doing anything about it. I'll keep an eye out for it now with other patches. If I discern a pattern, I'll let you know.

Also, to make things stranger, this patch was the default patch. Made in SCI mode.

[image-et-son]

Hi, I made a few changes. I haven't really 100% understood why the "zero load" exactly happens, to be honest. I did change some things related to load the live mode menu parameters. I haven't had the problem since - but in my case it was sporadic anyway (this is probably the worst case you can think of as you feel you can never be sure). But I think it's worth a shot.

In any case I made a change so that whenever you change from live mode to preset mode and back to live mode the equal tempered per note tuning is restored. If someone wants to apply per note tuning then it is necessary to do the tuning and then store that patch. I guess that if the "zero load" case happened again it would now no longer show up as all notes in an octave having the same pitch but the bender would still be dead and the osc pitch setting would be "free", etc.

BTW: I wondered in this context if there should be a function like the "default patch" but specifically for the menu parameters (and the hidden data like per note tuning) in live mode. But I guess you can't (and probably shouldn't) have everything...

p600firmware_alpha14_c_20220213.zip

[matrix12x]

for me this Alpha 14_C seems to have fixed the zero tuning on reboot in panel mode (manual mode), bur now it starts up with "ext Voltage" (noise on mine) at a non-zero value (66). I saved the syx file and have attached it.

Also, vintage is at a non-zero value (33).

If I store a patch I just made in panel mode, exactly the same thing happens as when I reboot.

But not if I save the patch in preset mode. Then all is normal. Patch20Noise.syx.zip

[el-folie]

Thanks imogen! Í can confirm what matrix12x found in alpha14_c:

• on first boot, also on reboot after setting it to zero, vintage at 33, ext voltage at 66.
• when switching to preset and back, again vintage and ext volt. have the above values.

And very very nice to have back the full range/smooth onset mod wheel curve - it´s just excellent!

And I tried to emulate the P5rev3 unison bass from Alex Ball´s video on the P600, I got too fascinated about it. Here it is: AlexBall_P5rev3_unisonbass.zip

It lacks a bit of the bite/livelyness and filter roundness, but it´s quite ok. A bit compression and chorus and it should sound similar to Alex´ video. I´m aware he maybe uses tri and square for osc B, but on the P600 waveform addition behaves differently, so I only used squares.

[el-folie]

Also found this: When switching between SCI/GliGli panel modes and staying in panel mode and reboot, the last used panel mode is not being retained in memory. It is only being stored (on a reboot) after one time switching to preset mode and back to panel mode.

[image-et-son]

OK, sorry about the vintage 33 and ext volt 66 - my mistake. Please find the proper code here. I also made that change so that panel choice is retained.

BTW: will try your Alex Ball patch

p600firmware_alpha14_c_20220213_2.zip .

[matrix12x]

@el-folie Thanks. The patch sounds great. BTW, I had to turn down "Ext_Voltage" because of the noise mod on my unit. The squares added a note roundness to it.

@image-et-son the new Alpha fixed the issues I noted above re: vintage and ext_voltage. Great work!!! :-)

[image-et-son]

@el-folie Thanks. The patch sounds great. BTW, I had to turn down "Ext_Voltage" because of the noise mod on my unit. The squares added a note roundness to it.

@image-et-son the new Alpha fixed the issues I noted above re: vintage and ext_voltage. Great work!!! :-)

OK, thanks! Question is if the general "zero load" problem is solved?

It certainly now prevents the problem of missing per note tuning which I solved by brute force. But anyway, I think that there must always be an easy way to remove any tampering with the equal tempered tuning. The solution to never store and recall this in live mode is reasonable - I am sure there are many people who spend absolutely no time on reading the manual or go beyond the first 5 seconds of thinking about a problem. For them there must be a bullet proof solution, e.g. power cycle or switching modes back and forth in panic :-).

But if the "zero load" problem persists it would still manifest itself in Bender=Off and PitchMode=Free, etc. It haasn't happened on my machine...

[image-et-son]

Just an additional piece of information: technically it seems that the array loaded from the memory page slot where the manual/live mode values are stored (actually: only the menu parameters and "hidden" patch data is needed - for everything else the control positions are directly applied) loads up as an array of zeros. What I have not yet determined is whether the code erroneously writes zeros to that slot or if there is a bug that make the page load up as zeros.

Those are the instances in which the load of the manual/live mode values happens: 1) Synth start-up 2) After patch dump in live mode 3) After switch to live mode 4) After storage in live mode

Those are the instances in which the storage of the manual/live mode values happens: 1) After a menu parameter change (I actually changed this - it is only stored once another menu parameter is changed - to reduce the number of storage events... maybe I should think about this change!?) 2) After changing the unison switch (why? for patch storage of the latch pattern!) 3) Before switching to preset mode 4) Before patch storage while in live mode 5) Upon very first start-up of the synth or more precisely, when the load of the live patch page fails the instrument takes the default patch and stores it there. This is basically the initialisation of the manual/live mode menu parameter slot and this is where the per note tuning for live mode comes from.

So for me it would help to know for instance if the problem only ever occurs after a power cycle. But el-folie already wrote that there are other instances where it happened...?

[matrix12x]

Regarding the "zero load" it seems fixed on my unit. Since the last two Alphas (14_c and 14_c_2) I was unable to get the issue to repeat.

I was only able to get the issue to reliably happen on a power cycle. I could swear the very first time I had it happen (unexpectedly) was not on a power cycle, but honestly I could never get that to repeat.

[el-folie]

Yes, I remember too, the zero load bug once/twice happened just with the synth being used, like when switching one time to preset mode and back to live mode, tuning got lost. But to 99% it occurred right after flashing a new OS. So far, with RC14_c2 no such bug anymore.

[el-folie]

Edit: This must have been caused by dust or similar reason, see next comment please...

(Found some unresponsiveness with knobs sometimes. The Speed knob with a running seq in unison mode sometimes doesn´t even react to dialling anymore and requires to slow down knob movement until it finally tracks the values again.

Once in a while also the Main Volume seems a bit sluggish.)

[el-folie]

I remember you mentioned that you reduced the refresh rate of some knobs/functions in the process of bug fixing/testing. Maybe the lightning fast knob reaction can now be reintroduced?

Edit: There might some other cause to this, I need to monitor this, it seems as if wheel data is blocking the knob scanning, maybe just dust in the wheel pot. After moving the bender a few times knob response was fast again.

Edit2: Still one thing that feels a bit off in use is the "first touch knob delay", that it reacts slower to dialling when right before another knob had been active. Is there maybe a way to make this "knob reaction delay" shorter?

Also, I know I earlier said that I liked the slow-ish knob value pick-up, but after some weeks with it I must recognize that a more instant value pick-up would feel better. I still find myself dialling over the pick-up value a few times with mid-fast movements, before finally slowing down to catch the value.

[el-folie]

As I´m still trying to find the reason for the note on glitches I went back to z80 and made the same extreme experiments, like max arp speed/slow downs on 6 voice unison/poly/1 voice unison sounds, and really - not a single glitch, abslutely no fault occurred. Then I went back to RC14_c2 and recorded a slow to slower seq of just two notes like above, first 6 voice unison, after about 130 seconds switching to poly mode (you will hear the difference), then to 1 voice unison. The glitch only occurrs in unison mode, where legato tries to never stop the gate cv (or maybe there are short pauses at note transitions which may cause the bug?), while in poly mode the gate stays high for the time of the envelope, so every voice is ringing out individually. I think there is a problem with how the gates/note on/pitch timing is being handled and maybe it´s a hardware fault but I can´t know. In the recording one can almost microsopically hear what´s happening in slow motion: as if the gate is not closed on note off but after the next note on, so that the old pitch wrongly gets put on the new note for a short time until the gate for the old note is being closed (or something like that, I´m aware that there are no gate cvs on a P600).

Please have a listen, this time it´s really extreme and might lead to something conclusive. Maybe you can even instantly hear what´s happening as an EE and physicist...

note on glitches_6Vunison_poly_1Vunison.zip

[matrix12x]

@el-folie is this an example of what you are talking about (image from your file above) @31.3 or so:

and this at 35.2 seconds:

[matrix12x]

If that is the case, it looks like some oscillators either 1) are not switching frequencies right away (to the new note) when the new note starts; or 2) some oscillators (at the new freq) are being amplitude modulated by the other oscillators at the old freq

at my best guess

would you mind posting the .syx of this patch so I can try and replicate? Is it VCO A and B or just VCO A for all the voices? Also to try and isolate this, have you tried individually muting voices one at a time to see if it is still there and/or if it follows a specific voice? for example, leave on voices 1-5 and turn off voice 6. then leave on voices 1-4 and 6, turn off voice 5. etc.

[el-folie]

Thanks for visualizing, Matrix12x!

Yes I already tried isolating voices - it happens on every voice 1 to 6 in unison, so also in mono legato. It also doesn´t matter if only A or B osc are being used. It must be gate/legato/envelope/trigger/timing related. What´s happening is some kind of spillover of the last note´s frequency onto the new note, which shouldn´t happen at all because at the moment of the note on the last note and its freq must be completely shut off - but on my P600 and only with GliGLi (also all older versions) this is not the case. As soon as I put the z80 in everything is fine. So, I really think either some hardware fault/spec that only poses a problem with Teensy refresh rates, or, GliGli and SCI OS just have a different way of gating notes on/off in unison.

I also remember having singular note on freq glitches in poly mode sometimes, but very very rarely in the case of long release times and overlapping notes (so maybe the same glitch logic applies when all 6 voices are sounding and a seventh voice needs to be stolen at a certain time, which effectively pushes one voice in the mono legato unison glitch state), so the problem must be related to handling note on/offs at the moment of stealing. I guess exactly that is happening in unison mode (also in 1 note unison) every time a new note is being played, every new keypress is a "steal", so to speak. And I also remember from hand playing and provoking the glitch that it occurred when one note/key is still being held and a new note/key is being pressed. So there must be some kind of conflict when there´s still a "gate high" state but a new note needs to get assigned to that same gate. Then some overlapping and delayed pitch assigning (=the glitch) happens. As to why, no idea. And really, no such thing happening on z80/SCI OS. It´s really a mystery...

I´ll do the syx and post it here...

[matrix12x]

I don't think the term gate is correct for describing this. It looks like one or more voices are being assigned their pitch too late, or in other words, the pitch CV is not being updated for about 70ms or so (zoomed in to count it) for one or more voices.

With the various optimization changes what is the current rate at which the voices pitch CV is updated? is it possible some times it does not catch one of the voices during an pitch CV update and catches it shortly thereafter on the next cycle of updates?

"(so maybe the same glitch logic applies when all 6 voices are sounding and a seventh voice needs to be stolen at a certain time, which effectively pushes one voice in the mono legato unison glitch state)" I think this makes sense to me. Maybe the slight additional CPU usage to assign that 7th voice or just the assigner processing time may be slightly too much?

It seems in every case where this happened in your audio file, it was for between about 70ms and 150ms. I looked for patterns in the audio, it seems like generally from high note to low note the glitch was a shorter duration 70ms-90ms or so, and from low note to high note it was generally slightly longer.

Does this happen if you set everything identical (unison etc) and you manually play C1 C6 C1 C6 etc... (instead of using the sequencer or arpeggiator)?

Also, of note, I can't get this to happen. I've been trying. unison mode, full sustain, long release, slow arp C1 C6.

[el-folie]

Ha!!! Guys... I found something out, can´t believe it yet but it´s 100% sure/confirmed and a yes:

It makes a difference if the seq plays in live mode or preset mode! Holy sh##! The glitches occurr in live mode all the time while switching over to preset mode patch 05, where I saved the glitch patch for Matrix12x, leads to no glitches (in this instance). So when you load the glitch patch to your p600, make sure to also prgram it to the live mode and then compare back and forth with the seq running at different speeds and wait for the glitches to happen. When they do switch over to the glitch preset and the glitches are gone. This IS weird!!!

At least now I´m 100% sure this must be software related. The live mode somehow handles something differently from preset mode. On the z80 it doesn´t matter if live or preset mode, both modes don´t show the glitch bug. And maybe I only experience this bug all the time because I´m mostly in live mode to experiment with new sounds, tweaking around...

At least these are some new and 100% confirmed hints (on my P600... so who knows...).

Have fun: The glitchy glitchyness patch.zip

[matrix12x]

lol. I have never tried this in live mode (manual mode/panel mode). I almost exclusively play in preset mode. hahaha. I'll go and try this out again.

[el-folie]

It´s unbelievable really... I mean how on earth would anyone find this bug, one wouldn´t just assume there´s a difference somehow between live or panel mode when playing the P600, crazy bug/glitch, whatever it is... Amazing wonders of technical things ;-)))

Here it is, audio to confirm the observation. 30 secs of glitch patch in live mode followed by 30 secs in preset mode (exact same patch), and again. So two minutes with a clear distinction marked by glitch/no glitch every 30 secs. What on earth could cause this? Hahaha...

glitchSEQ_30secLive_30secPreset_and again.zip

[el-folie]

But then again I def remember having had that same bug in preset mode for said long release sounds with all voices playing and note stealing - then it happened too. So, there must be more to it than just live/preset mode. Something technical that only happens at certain times under special conditions with note stealing/freq assigning or note on/off timing.