Virus Ti Snow - Late Pgm Changes

  • Hello,


    I'm using the Snow in a midi only setup, and attempting to create and enjoy program changes on 1 channel.


    I insert a program change (0) at 1.1.0.
    Notes also begin at 1.1.0 and continue for 4 bars.
    I believe this is standard - put a program change at the top of the track/loop so that when I begin playing the track the Snow will execute the program change and play the correct sound.


    What I'm experiencing:
    The sound will not change until after the first notes have played and finished. Doesn't matter if it's a long 2 bar sustaining chord, or if it's an 1/8th note percussive hit. The program change simply does not take effect audibly until after the notes have played and finished.


    So at 1.1.0 when the program change is sent the new sound's name appears, but it doesn't report until after the first sounds have played and stopped.
    Midi channel is set to low priority. Doesn't matter if the sound is a lush pad, or a simple bass sound using a single osc. The results are the same.
    It's crazy. I've never seen a synthesizer do this before. I tried the exact same sequence/pgm change on a few other synths and they snap instantly to the CC's preset number and don't skip a note.


    I took a little clip of this in action and sent it to Jörg and asked for guidance, but haven't received a response yet.


    I am wondering if I am alone. Does anyone else use the Snow, or any Ti Virus in a midi only/hardware sequencer scenario, and rely on program changes to switch your patches around and have trouble with the patches changing and reporting at the 1.1.0?


    If no one else is having this trouble... Is my Snow hosed? Does it need service or repair? Everything appears to be working well, sounds good, so this would be an odd service issue.
    Have you optimized your OS or Multi settings to make things happen faster?


    I could really use a hand, this is pretty frustrating.

  • "Thank you for your reply. One thing upfront: the Virus basically reacts to incoming Midi notes "blind", so it doesn't see which device sends data to it. In other words trying something like this in a software sequencer or a hardware sequencer should not make a difference if both send out nothing else than the data you actually want to be sent. I also definitely do not have access to any hardware sequencer here.Also the amount of notes played does not reflect the amount of voices the TI has to reproduce. If a sound makes use of the UNISON function, the amount of voices triggered can increase exponentially. Example: if you have UNISON set to 4 and you play 2 notes, you trigger 8 voices in one go. If you then have a sound that has a long amplifier release time, then the notes can easily overlap and then the unit has to produce 16, 24 or even 32 voices depending on how quickly the voices will overlap and how long an amplifier release time is set. So can the TI Snow run out of voices with just 2 notes? If it is a sound using UNISON and/or a long release phase and you play a 1 bar loop, then this can very easily happen, since the unit will calculate every voice until the end of the amplifier release time.The sounds you used in the video do not sound like these were very simple sounds either. The reason why I also bring this up is simple: the TI Snow (and all other TI units) uses a dynamic voice allocation. This means the units possible voice count heavily depends on what features are used. DSP heavy features like Reverb, the new oscillator models (Hypersaw, Wavetable, Grain, etc.) the analog modeling filter and the third oscillator increase the load on the DSP.Best wishes,
    Jörg Hüttner"


    So essentially Jörg is saying nothing about the time factor in relation to midi program changes, but that sounds which have complexity can slow down the Virus.
    I'm playing three 2 note chords. The preset is fairly pure and simple.


    I am totally willing to turn off functions, and further simplify my sounds, but really, I'm stunned that the Virus can't execute a basic program change on time.

  • So following Jörg's lead I went into the Snow and switched off all the delays, reverbs, arpeggiators, and EQ. I switched off all imperceptible OSC and other filters etc.


    Program changes were not effected. They continue to report audibly at the next key. Not when the program change is set to occur.


    I further went in and applied different program changes:


    1 four bar 2 note progression playing single oscillator sounds with no effects. Pgm change 1 at 1.1.0 and pg. change 2 at 3.1.0
    The program changes still do not audibly execute until after the first set of notes are played at both 1.1.0 and also at 3.1.0


    So sadly this doesn't appear to have anything to do with the number of voices or resources used. It's just that this particular Snow in unable to respond correctly to program changes.
    I can't imagine why, or what to do apart from manually change multi's in a live scenario in order to establish the correct sounds.


    Bummer.


    I am still totally open to anyone who has experienced this problem, or (hopefully) actually solved it.
    Thanks.

  • I insert a program change (0) at 1.1.0.
    Notes also begin at 1.1.0 and continue for 4 bars.
    I believe this is standard - put a program change at the top of the track/loop so that when I begin playing the track the Snow will execute the program change and play the correct sound.


    one thing to try (unless i don't understand the actual problem right): position the program change before the note. the virus needs some time to change a program, 1/8th note should be fine.
    marc


  • Yes, totally. I've tried moving things around to get the program changes to work... and yes, I am able to put a PGM Change at the end of the bar, and then by the time 1.1.0 of the loop comes around the change has happened, but this is troublesome.


    So imagine you are playing a song, and you're using a single part on the Virus. All is well.
    Now you need to move on to the next song, and require a program change...


    (I know that I can use part 2 for the next song's sound, but for the purposes of expressing the urgency of this issue, please indulge me)


    The notes begin at 1.1.0 - the first beat of the first bar - and thus the program change must happen before this... and so I place it at 1.1.0 but the sounds won't change until 3.1.0
    This is a problem.


    So if I place a program change at 4.4.0 and trigger it a 1/4 beat before the loop cycle I can indeed successfully enjoy a program change on the 1 of the loop.


    But this is a real hassle. In the sense that I am operating many devices, and in order to stop what I'm doing, and focus in on this one technical issue only to ensure that this device will respond correctly without playing the wrong patch as its first notes is kind of asking a lot...


    I would be better off simply creating new multi patches for each song and manually pressing a single button for those moments instead of attempting to hover and wait and even then risk getting it wrong and blowing it...


    I've always always loved that on a virus the player can be holding a note from one patch, and change the patch on this part and make a few other sounds, and then switch back and keep going... it's one of the really fun aspects of performing with a Virus live. But for mission critical patch assignments, I think we need program changes to be fast and reliable and hold priority over other internal operations.
    When it's time to change - bam! - it's time to change...


    I'm having trouble believing that I'm the only person who's noticed this - I have searched and searched for anyone discussing this matter, and looking for a solution. I'm in doubt because this hasn't always been how the Virus worked. My Virus A was very quick to make program changes, and a tank in a live scenario. That's why I wondered if my choice of size (Snow) over power and polyphony (A,B,C,Ti) was a bad one... if this is just how these work now, or if mine is broken?

  • Ok, I just found a way to get around this! Rather than just trying to use 1 MIDI channel, you use 2 MIDI channels and divide up your MIDI notes across those 2 channels, with the appropriate patch changes where you want them. For example, Ch1 starts with a MIDI pattern specifying ROM A-1 patch. The bar before Ch1 finishes playing, there's a 1-bar empty MIDI clip on Ch2 with a program change to specify ROM A-2 patch. Then the next lot of MIDI notes. Because you are just switching MIDI channels, the part on Ch1 finishes cleanly and the part on Ch2 starts playing cleanly, using the right patch. Voila! When you want to switch patches again, do the same thing and switch back to a new patch playing on Ch1. It does look a bit silly and ties up an extra channel, but at least it means you can switch between as many patches as you like, with no delays!


    P.S: If it doesn't make sense, I'll make an effort and do a screen-shot. :)


    Cheers,


    EG


  • I insert a program change (0) at 1.1.0.
    Notes also begin at 1.1.0 and continue for 4 bars.
    I believe this is standard - put a program change at the top of the track/loop so that when I begin playing the track the Snow will execute the program change and play the correct sound.


    To have the program change events at the same time as the first note events is a problem with any synth, hardware or software. Loading patches generally takes time, and must be done quite before the first note is to be played with the new sound. When I was still using midi events to set up everything (not anymore with plugins these days), I always had at least one bar where all the program change and controller events where placed. The music started at bar 2 or even later.


    The Virus TI (as well as other modern synths) is nice enough to let you change the sound wihtout cutting off the currently playing notes, so you can add your program changes for the next part to the end of the current part.

    Bass Player and Synthesist.
    Virus TI2 Darkstar | Virus TI2 Desktop | Sub 37 | Voyager RME | Machinedrum | Analog Four | Digitone | MPC Live | NI Maschine+
    Mac OS 13.5.1 (Ventura) | Cubase Pro 11.0 | Ableton Live 9.6 | Logic 10.4 | MainStage 3.4 | NI Komplete Ultimate 13 | RME Fireface UFX+