Posts by odd

    [...] having a standalone VC Editor & Librarian (which includes multi's) is a reasonable request of the manufacturer..

    Is it my bad english skills or did you just say that Access wants to have a standalone VC editor?

    Anways, have you monitored this topic? It's 3 years old!, and nothing, absolutely nothing happend, not even a comment about the theoretical possibility. The manufacturer is obviously not going to do anything about this, I mean, this would kinda be like admitting that TI is broken for many of us, and that's not going to happen, I guarantee it!

    It's time for someone else to chimp in and fullfill this feature request, so why not right here were Virus owners can easily find it?

    That comes a little late, but I appreciate it, even with this undertone. However I'm definitely not going to deliberately hard-crash my current working system, no chance. I can give it a try in case my next system upgrade will take place before I can sell the unit, but other than that I'm leaving this to others having the same issue, I'm not in the mood to invest anymore time into this, it has cost me more than enough time and nerves already.

    [...] how can you be sure that what you read there doesn't have a different background? just because it is a BSOD, it doesn't mean that it is identical to another BSOD.

    I only picked a few BSODs that occour when switching the Virus off, and expect for the one post where it doesn't state the exact message, it's all about "DRIVER_UNLOADED_WITHOUT_CANCELING_PENDING_OPERATIONS". Of course I cannot tell for sure that it all stems from the exact same problem, but obviously they seem to have quite something in common.

    All I wanted to say is that this should be known as an unresovled problem. But I have to admint that as a software developer I may have been a little biased, as I would have expected that this is kept in a bug tracker until it's finally fixed for all those who reported it, no matter whether it has been 4 days, 4 months or 4 years.

    [...] we can do a lot once we can replicate a problem, without replication, nothing will change.

    Maybe someone should have asked me to help with that, I would have been more than glad to help getting this fixed. But in the last 4 years ever since I first reported it, neither Access nor those who develop the drivers have asked me for any further information, not even on further requests on my part.

    Anways, by now I'm about to sell this device since I'm not using it anymore anyways, TI was the only reason for me to buy it in the first place. So I guess I'll butt out at this point...

    let me just say that we don't have BSODs on our radar. so if you suffer from those, get in touch by email, supply details and we'll see how we can help.
    best, marc

    Win7 x64 BSOD
    Sending Virus to sleep causes BSOD
    No more features before troubleshooting!!!
    BSOD caused by faulty USB-driver on Windows 7 64-bits with Virus TI2?

    SI00019099 (couldn't find the other tickets/emails anymore, some mailbox archives got lost)

    So apparently util today they haven't done much, like stated in that ticket years ago, they never asked for anything to reproduce the problem, and neither did the access support. From there on the only answer has been that you guys cannot do anything about it, as it's company xyz developing the driver.

    This problem exists for ages, it was reported numerous times, and seemingly ignored by those who are responsible. So what else do you want us to do now years later? I don't want to step on anyones toes, but hearing something like "we don't have BSODs on our radar ... get in touch by email" kinda feels like being kicked in the you know what :pinch:

    Over the years with the Virus my system was upgraded 3 times, 2xAMD, 1xIntel, so I had the chance to try something like ~40 different ports, USB1/2/3, internal as well as external (PCI expansions) ones. The only thing that changed over the time was the frequency of occurrence.

    I'm not at home right now so I can' test it, but try a single square wave on OSC2 with a little bit noise FM modulation, I think that should give you the basic sound characteristica. For this vibrating touch try modulating the pitch with an fast LFO, and then some fine tuning, a litle bit of portamento, EQ, etc...


    In case you've already tested it it's indeed pretty unlikely, just wanted to note it since that's often the cause for this BSOD.

    It worked fine with ~1.8 GB usage on a friends machine (Win 7 32bit, Cubase 6 32bit, TI1). I've just tested it on mine (Win 7 64bit, Cubase 6 32bit, TI2), and at first it worked fine too, but on the second try it happend to me too :(


    Have you checked your RAM, it might as well be damaged? This BSOD can also happen when the system searches for data in the pagefile and cannot access it for whatever reason (faulty harddrive, anti virus programs going wild, etc), however most of the time it's the RAM.

    Even though you've found a workaround i would recommend that you remove all RAM, and then try every single module one by one, or add them one after another, and also check them with for example Memtest86+ .


    I'm experiencing this DRIVER_UNLOADED_WITHOUT_CANCELING_OPERATIONS BSOD for ages now, throughout 3 different systems, 3 Major Cubase versions, and various Virus OS versions, at least for me some kind of DMA or IRQ conflict is very very very very unlikely. At one point it used to happen every god damn single time i've send the Virus to sleep, so that i started making backups of all my current working data every time before switching the Virus off :wacko:. Now with Cubase 6 and the lates 4.5 Virus OS it happens waaaay more infrequently, but it still happens once in a while :(

    I received an error message about my buffer sizes because I use the Emu 1616m which (for some reason) only allows for really strange buffer settings.

    What are the implications of using incompatible buffer settings (which I have been all along)?

    I'm pretty sure my crackling issue isn't derived from this issue as Jorg was able to reproduce crackling on a resource intensive patch with a TI2. Nonetheless, I seem to be getting much more crackling than ever before and the audio buffer seems to be a likely suspect (although I have also tested the TI as a soundcard to no avail).

    Same here with the EMU 0404. Unfortunately the EMU support couldn't tell me the corresponding buffer size values, or whether they are considering to add a buffer sample size option :(

    I've coded a small application to check the buffer size, and assuming i got it right it looks like none of the available ms options (2ms to 745ms) results in a buffer size that would be a multiple of 64, so there's not even a chance to test whether any of the problems i'm experiencing with the TI is related to odd buffer sizes :( ²

    Guess that's a question for the support... IMHO the pure lack of power beeing the culprit seems a little odd, i mean, even when i strip down the sounds in my example so that they are not using any effects, only a single OSC, etc., the LFO is still stumbling depending on the release of the sound in part 1. One should think that the DSP would be able to handle such little load, but who knows, maybe the LFOs sit so far at the bottom of the DSP priority list so that they get very easily interrupted.


    I only had a minute to test it, but from what i could hear and by what you desribe it sounds like something that i'm pretty familiar with. For me it basically happens in two situations, one is with special combinations of unison and amplitude release. This is what i've sent to the support, you can hear the sound's totally going wonky when you add a longer release:

    No news regarding that one till today, the support said that they could reproduce it, but couldn't telly me any more yet (Mai 2010). The other situation is, and that seems to be what you are experiencing, when you have two or more sounds on either even or uneven parts producing a lot of load. According two the support the even parts are processed by one DSP, and then uneven parts by the other DSP. So when you have a lot of load on only even or uneven parts, ie on only one DSP, then the parts begin to fight for the available processor power for the LFOs, and then you'll end up with stumbling that we are experiencing:…

    You can test it in your project by muting all parts except for part one, three, and five, then toggle part three and five and you'll notice that this will toggle the problem. Try the same with the even parts and you'll notice that they do not have any effect on it.

    According to the support (October 2010) there is unfortunately currently no other solution for this problem apart from organizing your sounds on even and uneven parts so that the load is distributed more or less evenly across the two DSPs.


    BSOD when starting or turning the Virus off respectively sending it to sleep happend to others before, your definitly not the only one.

    For me it's mostly always DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS when turning off, refering to vtimidi.sys, so definitly a driver problem, it happend yet only once when turning on, and i don't remember the error code. However, 0x00000050 stands for PAGE_FAULT_IN_NONPAGED_AREA if i'm not mistaken, so it could also be faulty RAM.

    You can use for example WinDbg to gather more details on the crash, and then contact the Access support, maybe they can help you (they couldn't in my case ;(, i always save and backup everything before turning the Virus off... that's so ridiculous)…g_part1.aspx#_Toc64133675

    Ok, now that the MIDI via USB thingy is sorted i've tried it, and i have problems too, storing and retreiving single dumps seems to work more or less fine, but multis do not work.

    When sending back a dump of a "non saved" multi it disables all parts of the current multi, and changes some aspects of the patches of the current multi patches (for example delay send, though the display shows no change it is set to zero), it doesn't change to the dumped patches.

    When sending back a dump of a "saved" multi it correctly changes the current multis name, but it doesn't change to the dumped patches, again only some aspects of the current multi patches.

    Another strange thing is, after trying to send a multi dump to the Virus without luck, i've tested the single dump again, and i ended up with a very strange dump that consisted of 19 kinda empty entries (00 c7 8a 04 a0 0d 8a 04 00 00 00), plus one containing the actual single patch data.