Beiträge von MrMowgli

    Yes, the Virus is USB 1.0 so you should hook it up to the USB 2.0. While 3.0 and 2.0 ports work, you slow down the entire bus for the lowest speed device, in this case the Virus. So the rule is:


    A) Have the virus on it's own internal USB hub (the 2.0 ports should be on their own) and
    B) Don't share the hub with any other devices


    Also you should know that sometimes windows allocates other things to those hubs (Like keyboard and Mouse), AND sometimes it re-uses IRQ's (Hardware requests) that the hub is connected to. If you experience many pops / clicks you might want to get familiar with the windows device manager.

    Well assuming you are setting the Virus at 48khz, you should try with 192 first and see how that works. At 96khz, it might be too low. I wonder what will happen for you using it at the different sample rate. I would think you would be fairly safe using 48/96 together, but you should try it and let us know :)

    The buffer size is the size of extra memory used by ASIO, and only affects latency. It should be as low as possible without hitting under runs. So for practical settings, try it with 128, and work your way up until there are no more over/underruns. I mean yes, there is a relationship there, but it has more to do with how fast your system can process the buffer.

    One of the other posts mentioned there was a problem that Windows had over subscribed an IRQ for his USB port, and that by reassigning it he fixed his initial problem, which was latency. I don't know about the surface, but I suspect it could be something similar, worth looking into.

    Actually the CTRLR version for me never loaded banks or saved them. I can't pull patches, but I CAN edit and store the current patch. To get the panel: http://ctrlr.org then downloads, then panels. The TI is in there. Probably works fine on Windows, including making a VST version. I'm on linux though so nothing perfectly for me. It DOES actually run, and since I'm not holding my breath that Access will magically build a linux version of it, I'll keep trying to get the CTRLR version working.

    Yeah looks seriously awesome. Wish there were something like that built into the Virus ;) But until then I will stalk them. The CV gates look cool, are they 1 volt per octave? Did you pick that up as well or are they still in creation phase?

    Hiya! I'm assuming you mean the Sequencer mode? I'm not familiar with the TI having an actual Multi-Single mode...?


    Multi-Single mode (Which is originally from the original Virus A/B/C) was for editing the actual patch used in the Multi. Now this has been cleaned up a lot in the TI series, and if you make changes to banks A/B those are stored in the multi itself, but every other bank requires you to store it in A/B first. Multi-Single mode held the patch in memory until you decided to save it in a real slot. The other reason to be in that mode was setting edit parameters for the patch including things like Analog Boost etc, which didn't make sense in multi mode, since they use that menu for the actual multi.


    Sequencer Mode is a quick and dirty way to assign all the slots to channels appropriately, saving us from having to set up custom multi's all the time just to get a patch per channel.

    Really it's down to the delay in your audio setup, and it changes for everyone based on their hardware. My setup introduces roughly 6-11ms latency, so I often have to adjust for that. Most of the time it's not noticeable, and usually only when I record something as opposed to just sequencing it- There all the outboard gear is synced up pretty tightly.

    There is a version made with CTRLR - You can write panels in LUA, and someone made an awesome panel set for the TI, including librarian. However it was made for an older version and I can't get recent versions to work. You could check that out? Maybe also work on updating it for newer versions or something :)

    It doesn't sound like there are any problems with your Device ID, I believe most ID's are set to 1 and Omni would work as well. Are you sure you are actually transmitting sysex? How are you doing it?


    The device ID is the unique identifier sent from the original sysex dump. When you send a patch up with SYSEX or any other SYSEX it transmits the devices current ID, and when it comes back down the ID's have to match or be set to OMNI to listen to that SYSEX. The original reason for it was so you could chain multiple synths to the same midi port and specify which device it went to.