Beiträge von DSS

Hello,

As above, it's true. Access Control is included when you download the latest software you need from the downloads area of this website.
Included is typically the plugin for TI, the control center software, and the software update itself. However, I agree that this is not particularly rational, or simple for those of us who aren't using a computer.

What I do:

I use a Sysex Utility - there are many free utilities like this, I use SysEx Librarian - and connect midi from the computer to the virus, and then from the virus to the computer so it's in and out. Then I initiate a dump of each bank and once received in the Librarian I label is correctly so I don't get confused later. Then I have a safe backup of all my sounds and multis.

Now I'm free to mess around without getting lost, or losing access to sounds. The virus allows us to save single patches, whole memories, or individual banks, and this is also handy.
The only other note I would add is that you can "force" a bank you wish to send to your virus into a specific bank - Check the manual out and red up on bulk system dump and load. This will help you better understand the concept, but what I like about this is that often there are sounds in a bank I'm checking out which I'd like to keep, but it's pretty rare I want a whole bank. So I will send the bank I'm checking out into bank A by forcing it to go there. Then I will copy whichever sounds I like into bank B, and then send my original bank A back to bank A where it belongs and go from there...

But with a SysEx utility you can make a good backup of all your sounds and then proceed to mess around and back that stuff up too...
Hope that helps you.

Zitat von EvilGus

I've noticed this on my Snow, but I thought it was a problem with GMS on my iPad. I'll try changes from Cubase and see if I get the same delays.

EG

Thank you.

I really appreciate it.

Zitat von 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?

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.

"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.

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.