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]

CV glitches at power-on & warming up_at the end speed diff of unison&poly.zip

Okay, here is some audio. P600 was already turned on before I thought about recording, maybe 2 minutes. So the audio file starts at about 2 minutes of warm-up time. The glitches then can be heard for about 1 minute before the seq runs smoothly. I´m just changing the speed, poly/mono-unison a few times, decay/sustain a bit.

At the end of the audio I demontrate the max seq speed difference of unison and poly mode by just switching to poly mode without touching the speed dial at all. Maybe this exact speed difference/timing relevant information may lead to a clue what´s going on in the CV distribution timing that might freak out the DAC or demultiplexing, which may leads to the glitches. At least I hope so.

However, I assume this to be a very tough glitch to solve, if possible at all.

One other important note: When I first wrote about this glitch yesterday, it stayed for about 20-30 minutes before it went away - so it´s very hard to verify any other precise/specific prerequisite or circumstance that makes the glitches appear, apart from the P600 still being cold. Tough one!

[el-folie]

Another important clue!

With a seq or arp running in unison mode the LCD pulses with each "note on". With a seq or arp running in poly mode no pulsing of the LCD occurs.

So unison somehow puts the whole system under stress.

[image-et-son]

Hi el-folie, I don't have this issue, at least I could not create it yet, neither the glitches nor the speed differences :-\

But definitely: LED pulses also in poly mode, I think that it becomes 6 times as intense in unison mode. I find no display specific functions that are connected with key on events let alone being different between poly and unison mode. I conclude that it is related to hardware, e.g. very short voltage cannibalisation or something like that. As for the glitches, I really don't know.

[el-folie]

Okay - I also think that some issues might be completely hardware related, like only there on specific main board revisions. Or chip specifics where we´ll never know which parameter (reaction time) causes it... probably too complicated to find at all.

And really no speed change on poly to unison with sequence at max speed? Then my P600 must be different somehow... ;-)

[matrix12x]

I can test mine. What are the specific parameters to test this bug/issue?

As I understand it, with the P600 cold, run a sequence (any sequence) and when in poly mode the led flashes/pulses, when in unison it flashes/pulses more. in unison the max speed is lower.

[el-folie]

Yes, cold P600, a simple two note sequence like only C0-C6 is best to monitor if there are glitches like double triggering the same note twice. Just switching back and forth from poly to unison on my machine causes the glitches. And secondly, max speed slowdown in unison. Weird! I just tested it again and yes, still all there on my cold P600.

Maybe it´s just one bad/too slow logic gate/switch, but there are so many...

(I´ll solder out all the lag caps on the analog board next, maybe that does something too)

[image-et-son]

We'll keep this open

[matrix12x]

I just ran a simple 2 note sequence, on a cold P600, I switched from poly to unison and the display did not blink on mine. The max speed stayed the same between poly and unison while the sequence ran.

I was not getting any double triggering or anything. I hate these mystery bugs. ugh. lol

[el-folie]

Okay, by chance today I tried a simple ASSGN arp with latch at a slow speed and there again the "note on" glitches occurred. The P600 was already warmed up, so component drift may not be the issue here. As soon as I switch to poly mode the glitches are gone (never switched to poly mode on the recording).

So it might have to do with simultaneous data knocking out the DAC/multiplexing. Luckily I could record while this was happening. It´s just so weird that this only seems to happen on my P600 so far. Maybe my DAC is shot?

unison arp note on pitch glitches - warmed up P600.zip

[image-et-son]

As a matter of principle, the firmware always completes voltage set and read operations - there is no possibility of parallel operations. However, there are generally two competing cycles: 1) all time based operations and the voice updates and 2) the user interaction. (In principle there is an additional one, which is MIDI interrupt.) The first cycle always dominates, e.g. it interrupts the second one (but never during a voltage read or write operation, these are guarded). arp notes are played during cycle 1. So the only thing I could image creating glichtes like this from the software side is that the Teensy doesn't manage the entire cycle and is being interrupted by it's one cycle. To my understanding the slow down of the arp/seq during external MDI pitch bend is exactly that: it created too much computation effort for the Teensy to complete the cycle. I thought I noticed that the glitches happened in regular intervals, is that correct? That would support that theory. Do the interval (in terms of beats) change when you change the speed?

However, mine does not do the same things as yours, e.g. unison arp, even with long envelopes...!?

[el-folie]

Those are some great pointers, thank you. I´ll need to look into this problem further before I can say anything of value. More testing...

[el-folie]

I suddenly had some weird faults happening tuning-wise and needed to reflash using hex and Teensy loader to get the AVR back to working normally. Fault was so that every octave only played the same note 12 times, each one octave higher. I shortly freaked out, put the Z80 in - all good, so I knew it´s the AVR. Then reflashed 13.4 by hex and reflashed the old patch dump by MIDIOX. Machine working again. But what a weird fault! Adding to the weirdness, in preset mode the octaves played fine, every note correct, only in panel mode octaves were only one same note and the osc AB frequency controls only switched between octaves too, inbetween only squelchy glitchyness around the octave base notes. I instantly thought multiplexing/DAC but it really only was the shot panel memory on the Teensy board for whatever reason.

Then I recorded a latched and dead slow arp up/down pattern in unison to better hear the note on glitches, which were still there even after complete erase and reflash of the Teensy board. I´m not able to hear a pattern. The recording is quite long to show many of the glitches and maybe find a pattern. Here it is:

unison_note on glitches_slow_arp_updown.zip

What I completely don´t understand, is, why this only happens with the Teensy board. And I have two of them and it happens with both. On the Z80 nothing of this happens, just clean up/down at all speeds. Also, the speeds are the same in poly mode and unison. With the Teensy in my P600 the speeds are different, poly mode is a bit faster - really as if something puts a brake on the whole digital system and provokes those glitches.

[image-et-son]

OK, I see. This definitely point to missed cylces and that would definitely produce glitches. I will check on mine if speed are different. I tried it by ear once: nothing I could hear. I will measure it now.

[el-folie]

Ha! Found something!!! I can provoke those note on glitches playing by hand! They occur exactly when there is no pause between the first and the second note, so legato provokes the glitches. Which totally makes sense as unison also switches to legato for seq and arp, right???

Maybe this hints to something...

[image-et-son]

Priotity low and high also switch to legato in poly. No, sorry, that's wrong - I got confused.

[el-folie]

The glitches are most apparent in prio Last playing by hand and only occur when a key is still being held and then playing a high key and held, then a low key and held, like this:

glitches_unison_prio Last_played by hand.zip

My assumption is, that SCI/Z80 somehow handles the "gate" signals/envelope legato differently timing-wise. But just a hunch, I have no idea what´s happening here. Maybe it´s still just a hardware fault on my P600, that only becomes obvious with the Teensy.

[el-folie]

Another idea: maybe the VCA/VCF CEM rev also has an influence on gate/hold behaviour. I´ll later try my other set of 3160-01 filters. Atm 3160D are used.

[matrix12x]

I can't picture the CEM devices causing this behavior.

[el-folie]

Speed differences: arp_ticking_6voiceUnison_vs_poly_vs_1voiceUnison.zip

[el-folie]

I can't picture the CEM devices causing this behavior.

I can´t too... But something weird´s going on on my machine...

[el-folie]

After flashing alpha 13.5 to my Teensy board by MIDI the octave fault was there again, all keys of one octave had the same frequency again, reflashing via MIDI didn´t help, only reflashing by hex. I need to keep an eye on this, maybe my 2nd Teensy board is slowly dying. What´s strange about this fault, in preset mode all keyboard notes/frequencies are still there when the fault happens, only in panel mode all keys in one octave play one same frequency .

(This "easteregg" paragraph was deleted because it was just user error, double triggering the arp in local on, so by internal keys AND a MIDI loop while testing local on/off modes. Sorry)

[image-et-son]

Hi, I suddenly had the same octave problem myself today. It is not solved by power cycle. As in your case, after hex flashing it was gone. I did not try syx. I need to think of what this could be. It's a tricky thing. I also observed that playing via MIDI had the same effect. Next time it happens (if it does) I will analyse further.

I am still digesting this entire issue ...

[el-folie]

Ahhh - veeerrry good to know I´m not alone with this, thx!

So maybe this could be some random "panel memory" wipe on flashing the OS...

Never had this happen before 13.4, just as a hint.

[el-folie]

I can add some more weirdness to the "panel memory erase error".

When on alpha13.5 I wanted to reflash 2.1rc3 by MIDI to test Tape Sync behaviour again. But for the first time ever, the "spinning square" on the LCD didn´t show up. After a power cycle I tried it a 2nd time, this time the square showed up but the reflashing stopped with a half a square and not the S for success. After the next power cycle the U for ready to receive OS didn´t even show up anymore. A moment of fear... I then reflashed 13.5 by hex and it worked again, but the panel mode was silent, nothing to hear at all on key presses. After reflashing the patch dump, the patches played fine but panel mode stayed silent. Then I heard that the fiters were working (headphones on) and made them track keyboard and resonance high, then the keys played and tracked fine, but still no oscillators. Then I switched back and forth the GliGLi/SCI panel switch and suddenly in GliGLi mode the oscillators reacted to volume knobs again. Switching back to SCI panel mode still no osc volume though, so back to GliGLi panel mode. Now I think I did this: switched from panel to preset mode and back one time, then a power cycle. After the power cycle and still in GliGLi mode I switched to SCI mode and then the oscillators had volume again.

So, maybe this is some weird "panel memory" store/restore yes/no in some/not all cases. How this could be linked to reflashing by MIDI not working anymore I have no idea, but maybe you. Maybe the memory layers are somehow interlinked? Also, after successfully reflashing by hex also reflashing by MIDI worked again, so something about "how to receive OS memory" must have gone south for some reason in some instances, which may be linked to panel mode/preset mode saving layer and/or GLiGLi/SCI panel mode saving layer. All just hypothetical, you know I know nothing about code. I can just observe and hope this helps in investigating what´s going on.

[image-et-son]

Hi, here is a candidate for alpha 14. It should be a new alpha as it also contains the change that the mod wheel range parameter is back (you'll find it at 333). That change also affects the patch storage.

Furthermore, I have also changed some DAC voltage times which may add to stability. In short: I had changed the times for "static" - e.g.: non-modulated - voltages such as volumes, resonance etc. to the same fast DAC routine as the fast moving oscillator voltages. I only realized late that this also affected maintenance functions such as tuning, so I reversed it. It is thinkable that it could have affected general stability too. Please let me know what you assessment on the "smoothness" and "responsiveness" is.

alpha_14_candidate.zip

[el-folie]

Hi, thanks for RCalpha14!

Here are my findings so far: The former full range mod wheel scaling with the smooth onset is dearly missed! Could we have it back on 333 at "full"? The "new full mode" doesn´t have the same smooth modulation onset (I assume it´s the old hard full mode).

At first I thought my brain was playing tricks on me, but really, the resonance sounds smoother/less aggressive on RCalpha14. Maybe due to less CV refresh rate? It feels as if the resonance snuggles itself a tiny bit softer/smoother to the oscillator waveforms at lower resonance settings. Also full self resonating sine together with osc waveforms seems to sound a bit rounder/less aggressive. Am I crazy? I tried a few times back and forth with alpha13.6 and yes, the behaviour to my ears was different. But maybe that was also due to drive being different after reflashing Oss´, hard to say. When I wanted to do a last defnitive comparison and flashed back to alpha13.6 the panel mode and keyboard tuning were erased again and could only be retained via reflashing by hex/teensy loader. So I´m half-way convinced now that alpha13.6/5 might be the cause of the memory losses. So far no losses on RC14, but need to monitor further while reflashing older OSs.

Smoothness overall, sometimes a knob doesn´t react as instantly as before, but could be imagination, need to monitor further.

The note on glitches in unison are still there, both in arp and playing by hand. As this doesn´t occur on z80 I slowly assume that the "gate on/off" timing may be different (or an equivalent to that), so that when gate off and a new on are too close together timing-wise the former gate on and its correspondent pitch is shortly being triggered. There´s def some kind of overlapping happening that doesn´t occur on z80.

Edit: As the "wrong pitch" error also occurrs playing by hand in legato-style, so that the old key is still being held when a new key is pressed it might have to do with how the gates are handled timing-wise for overlapping notes. But as I sometimes also get these glitches in poly mode, just very rarely, the cause might still be a hardware fault on my machine, maybe some digital gate (ic chip) doesn´t always react exactly as it should due to its response time vs. gligli refresh rate, but still reacts fast enough on z80. It´s just so hard to say when seemingly no other P600 exhibits this behaviour.

[image-et-son]

Hi the max modulation wheel setting with "full" selected should be exactly the same as before. I will check it again to be sure. I did make the exponential less curved as you noticed (but linear as in 2.1 RC3) because I thought for that you could choose a lower setting. Question to you: would you like both in the same setting, the slow onset and the full modulation at max?

As for the glitches: I am paying very close attention to this, but I really haven't heard anything like it (so far).

[el-folie]

Honestly, if I could have back the ultra smooth onset mod wheel behaviour of alpha13.4 I wouldn´t ever need any other setting than that, whether for smooth or extreme modulation. It was abolutely perfect for everything for me. Even so good that I wouldn´t mind having more VCO depth on mod wheel full up.

So yes, I´d totally like the exact behaviour back (prior to halving the depth). So, full range mod plus ultra smooth onset, like in alpha 13.4. It´d really be the only setting I´d ever use...

[el-folie]

"Fun fact": I shortly reflashed to 13.4 to be sure about the smooth mod wheel version and when flashing back to RC14 the keys had lost their tuning again. So 13.4 also causes the panel memory loss. And maybe also RC14.

[matrix12x]

@el-folie you seem really good at thoroughly testing these releases.

Do you have a checklist that you follow? I am looking for a more organized way of testing. I tend to hyper focus on only the function that was changed. But we all know that changes have unintended consequences. So I almost always miss something.

I wonder if there are a set of things I should always check, such as: 1) turning on unison (because of a heavier load), before testing operation, 2) tweaking every panel knob, 3) etc.....

[el-folie]

Actually I´m also just playing the machine as if I would normally use it and look if something suspicious comes up. I mostly only shortly check preset mode for LFO speeds, then back to live/panel mode as that´s where the magic happens for me, just playing live, using all the functions one time when testing, nothing special really. One thing I do though is always testing with headphones as the tiny digital step timing differences or frequencies may not be that apparent with additional delay from studio monitors to the ears. So for critical microscopic listening I use headphones.

Mostly about this procedure

1. SCI panel mode - as I love it!!! :-) (and still sometimes levels are not up after reflashing)
2. detune/spread 0, setting 2osc SAW fine-detune @ 0
3. drive 45
4. testing arp/seq for glitches in unison and general response/speed differences
5. playing live with lots of wheel action, subtle and extreme, listening for digital noise/steps and note on glitches on huge octave steps with legato/glide/unison/poly/long release
6. listening closely to filter sine plus osc behaviour for smoothness in sound
7. listening closely to envelope behaviour for steps/snappiness
8. If a knob/wheel is laggy I mostly just feel it while tweaking around
9. sendig back/forth a few OSs and lastly back to most current alpha OS for stability check
10. checking new functions and comparing them to last OS
11. when done I ask myself how does the new release feel to me, then report

So, just toying around with the machine and sometimes something new comes up by chance. The panel/tuning table erase thing is still spooky. I hope it was just the reflashing to 13.4 which caused it...

[el-folie]

BTW, totally unrelated to our topic here, but one of the most spooky things in Win10 to me is the "Data Execution Prevention" which obviously after a Win update suddenly decided to prevent an old and much loved Piano VST2 32bit plugin from loading at all. I was searching for this error for like a 3/4 year. And then finally today I read about this "DEP function" in windows on the internet, what a f##### up thing to not tell the Windows user why a program is not being started. It took me ages to understand what was going on. I was a microsecond short of reinstalling Windows... and it wouldn´t have changed a thing for the better probably. Confusingly complicated machines computers and their OSs are... :-///

[el-folie]

Something new: I can now definitely confirm that panel memory tuning loss happens over night out of no reason while the P600 was powered off. When switchin on today the panel tuning was lost again.

Also new: When saving the "lost tuning panel setting with 12 notes in one oct playing the same frequency" to a free preset memory, then the exact keyboard behaviour also occurrs in preset mode.

So, all of this must be "panel memory" related. (All of this confirmed for RC14).

[matrix12x]

I'm wondering if what JPRO600K was seeing on the gearspace forum is related to this.

[image-et-son]

Thanks, this topic is the reason why I haven't put out any new version. I had the same one more time after the one I reported to you. Now I have a version installed with monitoring tools activated and I am "waiting" for it to happen again so I can find out more. I noticed that in this situation the pitch bender also has no effect but the behaviour is totally normal when switching to preset mode. I am pretty much finished with everything else (even documentation) so this must be solved.

BTW: do you have I clear picture which version was first affected by this? Is it 13.0? Or a later version?

[el-folie]

Tough question as to when it first occurred... I´d have to go back and test specific versions. But generally I "think..." around the time when SCI mode was added and later/around the same time you also said some memory handling had been optimized. I guess somewhere around those topics happened the weird bug... But I´d need to go back and test.

[el-folie]

I'm wondering if what JPRO600K was seeing on the gearspace forum is related to this.

To me it seemed totally like a hardware fault, therefore it´s hard to believe he fixed it by reflashing with OS2.32, which then again would say it actually IS software related... Oh my...

[image-et-son]

I'm wondering if what JPRO600K was seeing on the gearspace forum is related to this.

To me it seemed totally like a hardware fault, therefore it´s hard to believe he fixed it by reflashing with OS2.32, which then again would say it actually IS software related... Oh my...

At least to me the situation is inconsistent. It is not realistic that there is a problem in alpha 13 which is solved by 2.32 but reappears in 2.0 or 2.1. I will also ask him to try a newer version once I am confident the problem here is sloved.

[matrix12x]

I agree, the facts as presented on gearspace were too inconsistent to understand what happened.

[el-folie]

I agree, the facts as presented on gearspace were too inconsistent to understand what happened.

My thoughts exactly.

[matrix12x]

I'm going to try and force this to happen on mine. I've only had it happen that once, but I really don't use manual/panel mode. I almost always start from a preset. When you left it off, was it last in Panel Mode? (the time described below where tuning was lost again)

Something new: I can now definitely confirm that panel memory tuning loss happens over night out of no reason while the P600 was powered off. When switchin on today the panel tuning was lost again.

[image-et-son]

I wish I knew how to "force" it :-) If it does happen in your case please store the patch and dump it to SysEx. It could contain a clue but I was particularly wondering if there is an anomaly in the notes tuning data of the patch.

[image-et-son]

Please also check if Pitch Bend, Fine Tune B and Master Tune have an effect

[el-folie]

I'm going to try and force this to happen on mine. I've only had it happen that once, but I really don't use manual/panel mode. I almost always start from a preset. When you left it off, was it last in Panel Mode? (the time described below where tuning was lost again)

Something new: I can now definitely confirm that panel memory tuning loss happens over night out of no reason while the P600 was powered off. When switchin on today the panel tuning was lost again.

Yes, I was in panel mode with SCI mode all the time. (Reprogrammed some awesome patches from Alex Ball´s latest video. THAT P5 unison bass - OMG!!!)

[el-folie]

Please also check if Pitch Bend, Fine Tune B and Master Tune have an effect

In my case when tuning gets lost:

• pitch bend lost as well (PB range and target get set to zero/off (and can be reset to work))
• fine tune and master tune still work
• only chromatic tuning of keys and osc AB freq knobs unresettable on tuning loss (without reflashing by hex)

[el-folie]

Will store the weird patch and upload it here... tuning loss patch for analysis.zip

[image-et-son]

Please also check if Pitch Bend, Fine Tune B and Master Tune have an effect

In my case when tuning gets lost:

• pitch bend lost as well (PB range and target get set to zero/off (and can be reset to work))
• fine tune and master tune still work
• only chromatic tuning of keys and osc AB freq knobs unresettable on tuning loss (without reflashing by hex)

Now that is interesting! I didn't notice that the bend range was set to zero - I thought it was a related effect but in fact it is just a completely independent manifestation of one root cuase. What I now think happens is that all the values from a certain parameter on a set to zero, including the per note tunings. I'll check you patch data now...

[el-folie]

What I find noticeable, is that the file is smaller at 101kb compared to a normal patch dump at 161kb.

[el-folie]

Please also check if Pitch Bend, Fine Tune B and Master Tune have an effect

In my case when tuning gets lost:

• pitch bend lost as well (PB range and target get set to zero/off (and can be reset to work))
• fine tune and master tune still work
• only chromatic tuning of keys and osc AB freq knobs unresettable on tuning loss (without reflashing by hex)

Now that is interesting! I didn't notice that the bend range was set to zero - I thought it was a related effect but in fact it is just a completely independent manifestation of one root cuase. What I now think happens is that all the values from a certain parameter on a set to zero, including the per note tunings. I'll check you patch data now...

Cool! Totally hope it leads you on the right track... 👍

[image-et-son]

Ah! The tunings in the end should be the 12 values of equal tempered tuning. So that explains what is happening, but not yet why.

Storage version is 8

Fequency A :  19696 Volume A :  16400 PWA :  14912 Fequency B :  18176 Volume B :  15342 PWB :  30656 Frequency Fine B :  33837 Cutoff :  3856 Resonance :  13056 Filter Envelope Amount :  52497 Filter Release :  37632 Filter Sustain :  8384 Filter Decay :  37632 Filter Attack :  0 Amp Release :  37888 Amp Sustain :  22272 Amp Decay :  39936 Amp Attack :  0 Poly Mod Envelope Amount :  32972 Poly Mod OSC B :  0 LFO Frequency :  26560 LFO Amount :  48 Glide :  0 Amp Velocity :  0 Filter Velocity :  0 Saw A :  0 Tri A :  0 SQR A :  1 Saw B :  0 Tri B :  1 SQR B :  0 Sync :  1 Poly Mod Frequency A :  0 Poly Mod Filter :  0 LFO Shape :  1 LFO Sync :  0 LPF Targets :  1 Tracking Shift :  0 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