Virus TI 5.1.1 Ableton 9.1 and Push

  • The beta update (5.1.1) is awesome and it fixed all my latency issues BUT if I plug in my PUSH controller then I lose all control over my TI and all the control goes over to the Push. 5.1.0 allowed both controllers! What happened??
    Any ideas would be awesome. THX
    :):):)

  • Doh, Ive just upgraded to 5.1.1 ( in prep to move to 10.10, I'm still on 10.9.5), and I now see the TI crashing MIDIserver whenever i connect the push (or any other usb midi device)
    Ive emailed support @ access to see if they have suggestions...


    bit fed up, as Ive had the TI really stable on 5.1.0... and swore i wouldn't upgrade, as i didn't want to risk this kind of thing happening... but other projects have forced my hand (need a newer version of Xcode),
    arghhhhh.....


    Im considering marching on to 10.10 and hoping the driver is stable there....
    the alternative is to uninstall and go back to 5.1.0, but that will stop me going to yosemite ... arghhh..


    @Marc suggestions? I've tried the normal rebooting, resetting virus, usb changes (despite the setup being fine on 5.1.0.0)


    EDIT: ok, turning on other devices doesnt always lead to the midi server crashing (fortunately),
    but doing a midi rescan is crashing midi server every time...


    EDIT2: also turning devices off (specifically the virus) also is crashing midi server....


    if the midi server crashes, I can only get it to back by rebooting my machine....


    EDIT3: ok ive upgraded to Mac OSX 10.10.3, and still exactly the same issue... Ive found a way to restart MIDIServer, but thats not really the way forward!
    Ive also tried with just the TI connected directly to the Mac, with no other USB/Firewire devices connected, and still the same thing, if you rescan midi or turn the Virus TI, you can clearly see in the console logs that MIDIServer has crashed. *


    *this means any DAW that is currently running, looses all midi activity....
    (so not same issue as above)



  • Thanks technobear. It seems like a deeper problem.


    Yes, with 5.1.1 I can put the sample rate at 128 in Ableton Live 9.1 and I get little to NO latency. This is a must for live performance and for anything really...

  • @JonGee , yeah I think this might not be related to your problem... but as you say something a bit deeper.
    Ive just installed the Virus (5.1.1.0) software on a brand new mac book pro (which has had no other software/drivers installed, its 'vanilla' Apple), with no other hardware connected and I can reproduce the same issue.
    So it looks like a general issue with the 5.1.1.0 driver.


    Ive reported to support@access with logs, crash reports etc so hopefully they will look carefully into the issue....


    for those interested, you can try a simple test.
    a) power up your virus with it connected via USB.
    b) turn off our virus whilst your mac is still ON


    (another way to provoke the issue is to use the Audio Midi application, and press Rescan MIDI whilst the Virus is ON.)


    the open the Console App (Utilities/Console)


    then under "Diagnostics and Usage information" , then User Diagnostic reports look for something beginning with MIDIServer
    e.g. MIDIServer_2015-05-14-165356_bear.crash
    (the name includes the date and time of the crash)


    If you click on it, if its the virus driver crashing you will see the Thread 0 crashed, with a line like:
    1 de.access-music.virusti.driver.midi 0x00000001022ad45f 0x1022aa000 + 13407


    if you see this, Id suggestion you email it to support, you can simply drag n drop the file from the console to your email application.
    this , I think, would be useful to Access so they can see different examples.
    also let me know here... if others are seeing it, then I will start a new thread, to see 'how common' it is.
    NOTE: this only occurs with 5.1.1.0, all prior drivers (including 5.1.0.0) did not exhibit this issue.


    the symptoms and consequences of this crash can be a bit varied, as the midi server will restart when you start a new midi enabled application,
    but generally, it will mean any running application (e.g. DAW) will loose all midi until the application is restarted.
    (Im not sure if some applications could restart MIDI server whilst running.... I've not seen it yet, but may be some do)


    note: the above is only a reproducible test, and as such its not a big issue, BUT the issue is this can happen at other times too, in particular sometimes when other usb devices are connected which is a bigger issue*.... so the only reason to highlight this test, is because its easy to reproduce and involves no other devices.


    * Im an experience software developer, so can see that the stack traces provide in the crash reports, point to the same area in the code.
    in essence there are a number of cases where the virus driver stops/restarts in response to MIDIServer requests, in these cases it is releasing a resource which is not valid (null).
    frankly this is a 'classic bug', which only takes 5 mins to fix, and only a little more to discover the underlying cause, as the causes also tend to follow a pattern that any experienced developer has seen plenty of times before.
    (ps. Id bet a nice cold beer, on it being caused by an attempted fix on the 'disappearing Virus TI midi driver bug' ;) )

  • Ah yes - the classic null pointer de-reference issue.


    :)


    I've recently started working with ARM after years of working with MIPS.


    You get used to MIPS handily core-dumping on null pointer de-references, then you get a shock because ARM maps addressable memory down at address 0, and for a while you can't understand how your program is still running!

  • Ah yes - the classic null pointer de-reference issue.


    not quite, CFRelease has a 'trap' when passed a null pointer, so, probably caused by an 'optional' resource being released when not allocated, or a double release (possibly by a code being called back from 2 handlers)... but still simple to fix :)


    (pity the driver code is not open source :))

  • The beta update (5.1.1) is awesome and it fixed all my latency issues BUT if I plug in my PUSH controller then I lose all control over my TI and all the control goes over to the Push. 5.1.0 allowed both controllers! What happened??
    Any ideas would be awesome. THX


    can you elaborate this a little? what do you mean by all control? can you provide a short step by step on what i need to do to replicate your issue?
    marc


  • not quite, CFRelease has a 'trap' when passed a null pointer, so, probably caused by an 'optional' resource being released when not allocated, or a double release (possibly by a code being called back from 2 handlers)... but still simple to fix :)


    (pity the driver code is not open source :))


    MIPS also traps NULL pointer access and control is passed to an installed handler.


    I know we're getting a bit off-topic, but...


    The methods for a pointer incorrectly becoming NULL are many and varied. As you say - over release/free on multiple instance resources, or a multi-threading ordering issue in allocating / freeing. I've seen people really tie themselves up in knots on C++ systems which don't keep proper track of their resources. Multi-threaded systems which don't properly protect the resource whilst it's deconstructed can also result in confusion. Critical section / mutex / semaphore protection is often not implemented well - at least on the systems I've worked on.


    ...but I/we digress. :)


    I'll bow to your knowledge of the OSX system. Haven't had chance to do much with that myself.