New issue with SST and switching Combis in 3.0.2 :(

[BillW]

No, not able to reproduce. Have footswitch set to program up. Hold notes, push footswitch to advance to new, different init combi in SetList, let up on notes. Play new ones on the different combi. Everything sounds fine.

Busch.

Ah, you are in setlist mode. Try combi mode.... Any two sequential initialized combis will do it. I just tried set list mode and that appears to function correctly! It looks like a bug with the foot switch increments in combi mode.

[danatkorg]

No, not able to reproduce. Have footswitch set to program up. Hold notes, push footswitch to advance to new, different init combi in SetList, let up on notes. Play new ones on the different combi. Everything sounds fine.

Busch.

Ah, you are in setlist mode. Try combi mode.... Any two sequential initialized combis will do it. I just tried set list mode and that appears to function correctly! It looks like a bug with the foot switch increments in combi mode.

I tried Combi mode as well. Same result: everything seems fine.

[BillW]

I'm emailing you a wave file.

Update: Sent w/15MB wave file attached.

[psionic311]

Bill, I've reproduced something similar to what you described. However, I get massive voice stealing, notes not sounding and some of that doubled/tinny sounds.

I ran across it trying how you described it -- from Combi Mode, select an Init Combi, then use the foot pedal to increment up to the next Combi. Play some notes, hold them, then increment to the next Combi... that next Combi is where the sound issues happen.

However, the next Combi I went to was my own "initialized Combi" I called "Blank". It's the same thing as a factory init combi (all 16 timbres are the I-A000 Kronos German Grand), with one difference --- all 16 timbres are set to MIDI channel 1.

I've found a solution, and though maybe this might help you if you've not already solved it.

Previously, I went to I-A000 and enabled that simulated sympathetic resonance, and SAVED it (wrote over the factory sound, yes). But now I've turned off the sympathetic resonance, and re-saved to the same slot I-A000. That has greatly alleviated the problem.

Toggling the sympathetic resonance on/off at then going back to the Init Combi shows that is the cause of the voice stealing and tinny sound.

[SynthKeyWizard]

SST issue was almost the same in OS 2 as I found.

[SynthKeyWizard]

https://www.youtube.com/watch?feature=p ... jpvlPkPpkU

Kronos SST issue example

[danatkorg]

Sorry, can't reproduce.

If you can reproduce this using the factory sounds, please note the exact sounds used.

Note that KARMA can interfere with SST, as noted in the manuals. It's possible that this is the cause in your case.

Also - do you know for certain that these same combis behaved differently before OS 3.0?

- Dan

[SynthKeyWizard]

Sorry, can't reproduce.

If you can reproduce this using the factory sounds, please note the exact sounds used.

Note that KARMA can interfere with SST, as noted in the manuals. It's possible that this is the cause in your case.

Also - do you know for certain that these same combis behaved differently before OS 3.0?

- Dan

Karma is OFF. All of these combis were work fine before OS 3.0.2. SST issue happens on some custom combis after upgrade to 3.0.2. And this happens only when damper pedal is not pressed, as You can see. When I use damper - SST works fine. I think this happens because new midi processing algothythms in OS 3.0.2 works differently than before. For example "All Sounds Off" message can be sent after last "note off" message if any controller isn't activated.

But I'm perfectly sure that exactly this combis worked fine before OS update.

[danatkorg]

Sorry, can't reproduce.

If you can reproduce this using the factory sounds, please note the exact sounds used.

Note that KARMA can interfere with SST, as noted in the manuals. It's possible that this is the cause in your case.

Also - do you know for certain that these same combis behaved differently before OS 3.0?

- Dan

Karma is OFF.

But, that doesn't mean that it's not affecting the system. Try setting all of the KARMA modules to GE #0000.

All of these combis were work fine before OS 3.0.2. SST issue happens on some custom combis after upgrade to 3.0.2. And this happens only when damper pedal is not pressed, as You can see. When I use damper - SST works fine. I think this happens because new midi processing algothythms in OS 3.0.2 works differently than before. For example "All Sounds Off" message can be sent after last "note off" message if any controller isn't activated.

Nope. I just went through a bunch of factory Combis, and everything worked properly. It's not a general problem.

But I'm perfectly sure that exactly this combis worked fine before OS update.

If you send me the data, I can try it on both versions and confirm.
(Make sure to send me your old version of the data; PCGs from 3.0 can't be read on earlier versions.)

[chini]

After reading a lot of others reaching similar conclusions and seeing yet another thread appear here today I have retested my initial findings again to no avail and felt compelled to detail it here as much as I can to make it very clear to Korg that this is definitely an issue with OS3.

Please listen to these 3 audio clips and read the full explanation below:

https://soundcloud.com/henry-frampton

"OS 2 version" shows the original patch change in SetList mode (triggered from my Roland A-50 to the KRONOS) working perfectly! SST doing its job as expected and no cut off notes (listen to OS3 sample cut off!")

"OS3 patch change" shows the same combie in OS3. The moment the patch change takes place you can quite clearly hear all tails getting cut off: SST simply not working! Note also that my external synths get cut off too! regardless of the fact that I have made sure there are no timbres/KARMA channels assigned to them!

"OS3 sample cut off!" shows the same patch change this time inadvertently cutting off the second combies drum loop!

Each clip features the same passage of music. These are completely customed combies of my own making. The first combie was actually played for about 60 seconds as I follow its drum pattern. For the sake of demonstration I have just recorded the very end of this passage of music and the patch change to the following combie. There may be a mild difference in "sound" between each audio clip simply because I have tweaked a little eq since the OS2.1 version plus you will actually hear an extra external synth playing some layered percussion running in sync with the Kronos on the OS2 version after the patch change. Both combies have not been altered at all in their basic timbre/KARMA set up. The patch change actually takes place in the obvious break between the two passages of music.

Please be aware that I am remotely patch changing the Kronos setlist slots from my Roland master keyboard. i.e. I am not using the Kronos front panel or any pedal attached to the Kronos to change patches. This is how I have to change the Kronos at the same time as being able to relay other patch changes to the rest of my rig live on stage with every patch change from the A-50. I use the A-50 because it allows the actual patch change to be hit but not actually released until all keys and/or damper pedal are released. There is something within the midi protocol spec that has obviously changed in OS3 that has upset the way the Kronos receives the patch change from my A-50. Please also note that my global patch has not changed except that I have made sure all new OS3 features are not active (including the new metering feature) but I do have optimise RAM on (as I did in OS2) and mute set to "LIVE" (ditto as I did in OS2)



The first combie actually has very few timbres invloved: 1 drum part, 4 x timbres playing the chords/pads, 2 of these set to EXT. The patch combie I change to is using all 16 timbres including all 4 KARMA modules that have been assigned to "key zones" enabling me to use the scene switches to select different combinations of the 16 timbres as this combie is used to play out rather a long passage of music with different sounds being selected at various points. The break in the music is where I patch change to this combie which is maxed out but the rhythm part is not a drum pattern playing but an audio loop of an originally recorded custom Kronos drum track!.. Hence my demonstration of the OS3 sample cut off! clip where this loop starts to play but then a split second later actually gets cut off when it should be playing out as normal within the allocated timbre slot! (the timbre containing the loop is simply a one oscillator program with the "hold" function switched on). Both OS3 audio clips were of course played separately and interestingly the first one chose to cut off the following combies drum loop timbre and the "OS3 patch change" cut off all tails instead! More often than not its the SST that suffers.

I also retested all of this after having discovered I had some timbres muted on the first combie but still set to "INT" potentially eating polyphony so have reset them to "OFF" However this also has made no difference yielding the same result as these audio clips show!

To prove my finding here please note that it is important to realise that the abnormal effect is a cumulative one as I have had mixed results when attempting to play the first combie for only a few seconds before patch changing. However it of course imperative to show how this patch changing anomaly occurs in a real live performance situation as one plays the patches over a period of time and my audio clips reflect this! This all points to added pressure on the main processing chip to perform properly no doubt related to polyphony/sustained notes that effect the state of the performance meter at the point of patch change.

I am convinced it is either: the added functions in OS3 have stretched the main processor too much to cope with the same performance quality that was working fine in OS2 or: something has been added to the MIDI protocol in OS3 on patch change that labours the main processor enough to diminish its power to deal with polyphony and run SST as smoothly as it was doing in OS2.

Whatever it is that's causing this, personally I am now concerned for my live shows which is what I use the Kronos for: I can not revert back to OS2.1 without loosing a lot of work I have carried out in OS3 because (as Dan pointed out) OS2 will not read OS3 saved files. This is worrying as smooth patch changing throughout my live rig is essential. I played a solo gig just the other night and people in the audience certainly noticed the difference when rhythms and sounds were suddenly cut off! When I play with my full group at least the drums wont disappear! However this really is not acceptable and I hope Korg can release a small bug fix soon as this is preventing me from gaining the same performance through my way of patch changing the Kronos that ran smooth as butter in OS2 !



I have spoken to Korg UK about all this and they said they will be getting back to me!

[AntonySharmman]

I can not revert back to OS2.1 without loosing a lot of work I have carried out in OS3 because (as Dan pointed out) OS2 will not read OS3 saved files.

Actually you can revert to stable OS212 as I did , without loosing your work !
- Use PCG tools and open a previous or factory PCG written with OS <=v.212
- Then open your latest PCG file and copy-paste all Prog/Combis you have edited with OS3 in first PCG and save it "as" ...
The saved PCG file will be saved in the same format that it was opened !

What can you actually loose in that case :
- Wave Sequencer & Drumkits edited with OS3 , that can't be copied with PCG tools.
- Any newer effect of OS3 in Prog/Combis which will be blank (not assigned)
- Any SGX2 edited sound that is not compatible with OS212
- SET lists edited with OS3

Another thing you have to be extremely careful before downgrading OS is to load first shipped factory.PCG file because
a newer SET list or SGX2 settings will freeze previous OS !!!

If you think that you can minimize losses doing that , go ahead until an updated OS will be released , and all of you remember
that always develop your work in the previous stable OS , as I always do , and note that PCGs of WavesArt Kronos EXs libraries
are still in OSv.212 format since OS3 is not ready to support them in polyphony and CPU resources demands.

[chini]

Hi Anthony,

Thanks very much for the info and I am sure this will get other users out of jail ! Unfortunately the programing I have foolishly continued to do in OS3 is far too intense in all areas of the architecture you mention to transfer back to OS2.1 so I will continue to work around the problem through other means until Korg release a "bug" update. I would rather not risk grinding to a complete halt! This has taken up enough of my time as it is however I should indeed take on board your sensible code of working within different OS versions!... On my behalf it's indeed a case in point here of a "lesson learned the hard way!"

One further thing that has also cropped up in OS3 is an anomaly with the relationship between KARMA midi channels and EXT assigned timbres in the same combie. Now in OS3 even if the KARMA switch is not active and even if no timbres are assigned to EXT on the following combie one changes to, the actual KARMA midi channels will continue to send CC120 (all sounds off) on those KARMA channels to the Kronos midi output to any EXT synths that were receiving on those same KARMA channels the moment the patch change takes place, hence immediately muting anything that was left to die out naturally on my external sound modules/FX from the previous combie as I continue to play the new combie I have just changed to! This means making sure that the proceeding combies KARMA channels are not transmitting on the same channels as my EXT synths. Even if one switches off "KARMA to midi output on the Global page" the Kronos still sends out this message to its midi output! This is of course a pain in the arse when I run out of convenient midi channels to set the KARMA channels to to avoid the problem!

Hopefully all my hollering recently has awakened Korg to the problems here and they will issue a quick update soon!

Apologies to all if this subject has taken up rather a lot of thread room recently but considering the increasing number of users complaining about this I hope you agree that my actions are justified!

[Rigel]

My Blofeld module is connected to midi out of Kronos. After 3.0 update, if I change the program on the Kronos, the Blofeld is muted, though it is set not to receive program changes. It is as if Kronos sends a "notes off", and "stay off!" message to Blofeld when a program change is carried out. Any ideas?

They -kronos&blofeld- worked in harmony before 3.0..

[StephenKay]

One further thing that has also cropped up in OS3 is an anomaly with the relationship between KARMA midi channels and EXT assigned timbres in the same combie. Now in OS3 even if the KARMA switch is not active and even if no timbres are assigned to EXT on the following combie one changes to, the actual KARMA midi channels will continue to send CC120 (all sounds off) on those KARMA channels to the Kronos midi output to any EXT synths that were receiving on those same KARMA channels the moment the patch change takes place, hence immediately muting anything that was left to die out naturally on my external sound modules/FX from the previous combie as I continue to play the new combie I have just changed to! This means making sure that the proceeding combies KARMA channels are not transmitting on the same channels as my EXT synths. Even if one switches off "KARMA to midi output on the Global page" the Kronos still sends out this message to its midi output! This is of course a pain in the arse when I run out of convenient midi channels to set the KARMA channels to to avoid the problem!

I can't really make sense of this whole discussion. But if you can provide me with the simplest possible test case, on how to configure an INIT combi such that this CC#120 is sent out, I'd like to check it.

In any case, you keep talking about KARMA and I have just verfied in the code that there should be no way that KARMA itself (the KARMA engine) is responsible for this CC being sent out. KARMA itself does not send out any CC#120's. So perhaps Korg may be sending this message if they determine that there is a match on some MIDI channel situation - in any case, I would like to see the simple test situation.

Hopefully all my hollering recently has awakened Korg to the problems here and they will issue a quick update soon!

So far, I haven't seen any acknowledgement from Korg that there *is* a problem.

[chini]

One further thing that has also cropped up in OS3 is an anomaly with the relationship between KARMA midi channels and EXT assigned timbres in the same combie. Now in OS3 even if the KARMA switch is not active and even if no timbres are assigned to EXT on the following combie one changes to, the actual KARMA midi channels will continue to send CC120 (all sounds off) on those KARMA channels to the Kronos midi output to any EXT synths that were receiving on those same KARMA channels the moment the patch change takes place, hence immediately muting anything that was left to die out naturally on my external sound modules/FX from the previous combie as I continue to play the new combie I have just changed to! This means making sure that the proceeding combies KARMA channels are not transmitting on the same channels as my EXT synths. Even if one switches off "KARMA to midi output on the Global page" the Kronos still sends out this message to its midi output! This is of course a pain in the arse when I run out of convenient midi channels to set the KARMA channels to to avoid the problem!

I can't really make sense of this whole discussion. But if you can provide me with the simplest possible test case, on how to configure an INIT combi such that this CC#120 is sent out, I'd like to check it.

In any case, you keep talking about KARMA and I have just verfied in the code that there should be no way that KARMA itself (the KARMA engine) is responsible for this CC being sent out. KARMA itself does not send out any CC#120's. So perhaps Korg may be sending this message if they determine that there is a match on some MIDI channel situation - in any case, I would like to see the simple test situation.

Hopefully all my hollering recently has awakened Korg to the problems here and they will issue a quick update soon!

I haven't seen any acknowledgement from Korg that there *is* a problem.

Hi Stephen,

You are absolutely right!.. the CC is not being sent by the KARMA module because the modules are not even active when this happens! This is something that Korg have implemented within the general midi output data packet protocol whenever a program change takes place.

It is easy to replicate: place 2 combies consecutively in any setlist, edit the first combie so that one of its timbres is assigned to EXT on any of midi channels 2, 3 or 4 (these channels are the default KARMA channels as you well know!). Connect the midi output of the Kronos to an external synth using a sound you know has a nice long release envelope. On the second combie you are going to patch change to make sure you have no timbres assigned to EXT. Starting on the first combie make sure the KARMA switch on the front panel of the Kronos is not active and start triggering your external synth, let go of the keys to send your external sound into the release part of its envelope. Now in OS2 when you patch change the Kronos remotely from another keyboard that external synth would die away as normal running through the release stage of its envelope which makes sense because there is no patch change message to that midi channel programmed in the following combie- indeed we have programmed this combie we are patch changing to with absolutely nothoing assigned to your external synth so logically it should simply be left in peace to carry on ringing out to the end of its env cycle. But it doesn't because Korg have added some extraneous data to the patch change protocol which I have analysed as CC120 which is "all sounds off!" If you now patch change here in OS3 you should find that indeed it cuts off your external synth immediately the patch change takes place!

In fact I have just tested it triggering the patch change from the SetList window itself on the Kronos and it still does it! It cuts off the external sound when it shouldn't do at all! In fact if the KARMA switch was active, as you well know having designed it (!) one would expect the external sound to be given a simple "note off" message as the KARMA engine stops playing on the patch change.

If you go back to your first combie and set the EXT timbre to say midi channel 16 you will see when you do the patch change this time your external synth will happily finish its normal routine!

Hope this makes sense! And please let me emphasise Stephen: this is nothing you have programmed into KARMA!.. its obviously something Korg have changed hopefully inadvertently!