Beiträge von thetechnobear

  • Virus TI - OS 5.1.1.0 - causing MIDIServer crash

    sure.... so your saying
    Mac Book Pro, has been upgraded to 5.1.1.0 and NO problems
    Mac Pro, was a clean install to 5.1.0.0 and has problems (with Midi crashes)


    ok, so go to /Library/Audio/MIDI Drivers/
    In there you will find : Virus TI MIDI Driver.plugin


    tell me that date and size of this for both the MBP and the MP.


    also, as mentioned in the first post, on your MP go check the console (details in the above post) and see if you can find a MIDIserver crash file,
    and if it looks similar the one at the top of my post.


    THEN... if you feeling brave :)
    on the MP, copy the Virus TI MIDI Driver.plugin somewhere safe (you can get it back, but easier to know)
    then copy the Virus TI MIDI Driver.plugin FROM the MBP to the MP, to exactly the same place
    restart the machine, and see if it helps. (in particular the test cases I list at the top... I cannot say this is the cause of ALL issue, just the ones I've encountered)


    (but still let us know time/sizes ... as then we can see if the MBP had the 5.0.8 driver, or the 5.1.0 driver)



    Im assuming Access will be trying some fresh installs, and also some upgrade installs to help determine if this is a possible issue,
    and then advise us... the slight issue is 5.1.0.0 is no longer on the beta downloads, luckily I found a copy on my Time Machine :)

  • Virus TI - OS 5.1.1.0 - causing MIDIServer crash

    ok, Ive just (double) checked 5.0.8, 5.1.0 and 5.1.1
    I did this in two ways...
    a) check my Time Machine backup.
    b) took the official packages for each supplied, and unpacked the package manually (i.e. not installing) and checked both the BOM, and also extracted the payload.
    the result: all have drivers with different sizes binaries and dates.


    and as I stated in the original post, they all have not been packaged 'correctly' with different versions....
    basically they are all (except the getinfo string) have 1.7.0.0 (they should have been, at least, 1.7.0.0, 1.7.0.1, 1.7.0.2)
    as i said a developer 'mistake', and makes @Marc and other supports jobs alot harder.


    so Im wondering, perhaps, if you do an upgrade, its comparing the bundle version, says its not changed, and so doesn't bother replacing them.
    - Ive not looked into this, I'll leave this to the 'reader' :)
    but this might explain the why some users are not affected... they are still running the driver from a previous version.


    (btw, I tested, Im thorough :), not only does the 5.1.0 driver work with the rest of 5.1.1.0 but also the driver with 5.0.8 ... both do not exhibit the issue of 5.1.1.0)


    just seen @ChrisCabbage post, your experience would also tend to support the 'upgrading' not installing the new driver theory too

  • Virus TI - OS 5.1.1.0 - causing MIDIServer crash

    Zitat von Marc

    technobear,


    thanks for the report. works fine here. on a mac pro 2013 and on a macbook pro from 2011. i can re-scan in AMS, switch it on and off etc and it doesn't crash. on top, i think we would have had a lot of people writing into support if there would be a general issue. the adoption rate of apple updates is faster than ever and we are not the only ones on 10.10.


    it doesn't crash, does this mean you checked your console logs?


    I agree, I was also very surprised... which is why I said little until I had looked into it extensively,
    but two separate machines, one of which is completely 'clean room install', how can this be specific to me?


    as for people not reporting, I think its possible most would not notice anything other than 'odd behaviour', as they don't check the console logs,
    but who knows... and as a developer, I try to stick to facts... one clear crash is enough for investigation :)


    I do however, wonder why your not getting it.... perhaps something to do with it not being a 'clean room' install... either an upgraded virus install, or a continually upgrade Mac OS X install? If I were in your QA/Dev department, this is what I would be testing.
    also, why does just replacing the Midi driver fix the issue?


    again, I can't say why it works on other machines, as it doesn't work on any of mine... but as we all know, there are so many variations between machines, working (or not working) does not mean it will be the same on (lots of) others... such is the joy of qa/support for software products ;)



    Zitat von Marc


    so again, thanks for the report but not thanks to a general advise to our users to downgrade. i don't think that's necessary for the most of us.
    marc


    I meant don't upgrade if you haven't already... as it could lead to issues... but I can see it might be misinterpreted, so I'll remove

  • Virus TI - OS 5.1.1.0 - causing MIDIServer crash

    Ive now established that 5.1.1.0 is crashing MIDIServer on OS X 10.9.5 and 10.10.3.


    This includes crashing on a brand new Mac Book Pro, which has NO other software/drivers/hardware on it (other than supplied by Apple pre-installed)
    (tested with a TI Keyboard mk1), and also on an iMac which was working perfectly with 5.1.0.0


    Note: this only affects 5.1.1.0, 5.1.0.0 and prior do NOT exhibit this issue.


    Ive reported this to support @ access, but Im repeating here for information purposes, and to see how widespread a problem it is, and why you might see issues with this version of the driver, and Id suggest if you see this issue, then report it to Access (as they told me it was not a known issue), and perhaps mention on this thread.


    Causes of crash:
    a) Rescan MIDI - 100%
    b) Put Virus TI into standby - 100%
    c) adding new USB devices - sometimes
    d) exiting midi applications (DAW) - sometimes


    Implications:
    Crashing the MIDIServer process will halt ALL midi activity, and will not be restarted until a new MIDI enabled application is started. (eg. a DAW)
    In practice this means, you loose midi until you restart you DAW, this is how I first noticed the issue, as I plugged in a new USB midi device (case c) , and lost all midi.
    also some daws may have other issues, apparently unrelated, but caused by suddenly losing all midi devices, which would be pretty 'unexpected'.
    (Ive never seen midi server crash, prior to this driver issue)


    I think it is a pretty serious bug.



    How can you see if its affecting you:
    start 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 (de.access-music.virusti.driver.midi) crashing you will see the
    Thread 0 crashed, and a line like:
    1 de.access-music.virusti.driver.midi 0x00000001022ad45f 0x1022aa000 + 13407


    (a fuller example of the crash report is shown at the bottom of this post)


    Replacing (just) the midi driver with 5.1.0.0 fixes the issues
    Finally today, I have proved this is the 5.1.1.0 Midi driver....
    I took the virus midi driver (only) supplied in 5.1.0.0, and replaced the one installed in 5.1.1.0
    and surprise, surprise (not!)... it fixes the problem, and still works with VC/audio interface etc :)
    (don't try this ... Im a developer and I know what I'm doing etc., wait for a fix from Access :))


    other notes:
    I noted that @Marc said, in a post on this forum, that 5.1.1.0 and 5.1.0.0 were identical for the Mac ( a little secret, only the pc version changed, he said ;) ) ,
    I think this was mistake caused by a small version management issue by the developers of the midi driver.
    the driver in 5.1.1.0 has been in labelled as 1.8.0.0 (info string), but crucial in areas (mis)labelled as 1.7.0.0 (bundle info), as a change, it should have had its version number increased to 1.8.0.0
    the 1.7.0.0 driver is the driver supplied by 5.1.0.0, and its build tags and binary size are different (and has been demonstrated, its behaviour), so its definitely not the same build/driver version.


    as I mentioned on the other thread, I suspect 1.8 (5.1.1.0) aimed to fix a sleep related bug, but unfortunately has introduced a more severe bug.


    technical info:
    you can see the cause of the crash is a SIGTRAP, caused in CFRelease, due to CFRelease being called with NULL.
    this is completely correct! Apple clearly states in the SDK documentation for CFRelease


    void CFRelease ( CFTypeRef cf );
    ....
    Special Considerations
    If cf is NULL, this will cause a runtime error and your application will crash.


    (https://developer.apple.com/li…pple_ref/c/func/CFRelease)


    there is some additional info, on the original post I made about this on a different thread : Virus TI 5.1.1 Ableton 9.1 and Push


    example crash report (part of)
    trace will vary slightly depending upon which case (as detailed above) causes the crash, but the top two lines for the virus driver are always the same (well the 'code offset' is which is the important bit)
    0 com.apple.CoreFoundation 0x00007fff87e77010 CFRelease + 912
    1 de.access-music.virusti.driver.midi 0x000000011011545f 0x110112000 + 13407
    2 de.access-music.virusti.driver.midi 0x0000000110115d8f 0x110112000 + 15759


  • Virus TI 5.1.1 Ableton 9.1 and Push

    Zitat von ChrisCabbage

    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 :))

  • Virus TI 5.1.1 Ableton 9.1 and Push

    @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' ;) )

  • Using the Virus TI without the TI

    you can also copy to RAM, no?


    I do my sound design on the Virus itself, and don't really keep that many presets, so don't see it as an issue.
    there has been some talk of a 3rd party Editor, Im not sure if that works well or not? MysteryIslands or something?)


    you can also use the 'old school' way and 'midi dump' the patches (only in/out of the RAM banks)
    either from the 'store' menu, or using the config/midi ... transmit/receive midi dump.
    (id assume, that the .mid files you have stored from VC are in this format)


    I think the 'general' idea, is you do most of your work in the RAM banks, then once they have settled down,
    you then copy them form the RAM banks, into ROM, to give yourself some more RAM bank to play with.
    (given the RAM can store 4x128 = 512 presets, its not too bad)

  • Using the Virus TI without the TI

    no, loading VC puts it into VC mode... if you dont load this, then you will see the "Virus Synth" midi device


    latency, sorry i dont use cubase, but there will be some preference to tune the audio latency (some times called audio recording latency),
    but try it first, and then you can dig into it, if you find the audio your recording seems a few millseconds late or early
    (usually DAWs try to set it to a sensble default, so it may be ok)

  • Using the Virus TI without the TI

    Single mode = single patch, single midi channel
    Multi mode = multitimbral, so 16 different patches loaded in different parts, each (by default) on a different midi channel.
    Seq mode = very similar to multi mode, but midi channel is fixed to part number.
    (Seq mode, doesn't really add much imho, you may as well use multi ... I suspect it only exists for VC)


    which mode, well depends if you need to use multiple patches at one time.... if not, then single works well :)


    Tempo - set your Virus to midi / sync external , then you can get Cubase to send it midi clock...
    this keep the TI in sync with Cubase, and also match tempo.


    I use the TI this way.... a couple of things id highlight.
    - use USB midi, not midi din cables... its faster, and so sync is much better.
    - you may need to adjust your audio input latency in cubase to ensure things are in sync.

  • Virus TI 5.1.1 Ableton 9.1 and Push

    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)



  • Hardware Issue??

    sounds unlikely to be hardware... as it simply sounds like something is coming thru on the wrong midi channel,
    and thats more a software (firmware) thing, than a piece of hardware...
    (given the complexity of the TI and the Octatrack, easy to have confusion :))


    for whatever reason, it sounds like you are only sending in on channel one.
    (I assume if you change the patch on channel 1, then the sounds does change?)


    what I would try is:
    a) monitor midi messages - send the midi from the octatrack thru a computer back out to Virus, and then use a midi monitor to see if the octatrack is sending on the correct channels. (take care some daws, e.g. Live force things on to one channel)
    b) test the Virus alone, e.g. from a daw (or keyboard) where you explicitly set the midi channel.
    c) SEQ mode, is interesting... so perhaps worth following up on... i.e. what does 'strangely' mean, the reason its interesting, is you cannot change midi channels so its forced.
    d) try with the octatrack into a DAW, sending to multiple channels, does this work properly?


    the other thing I would do, is really dig into why Live/Logic 'went awry' and why SEQ mode 'behaves strangely', I suspect they point to a similar issue... all work fine for me here, (including external sequencing via a Spectralis which is 'similar' to the octatrack.)


    anyway, check the midi messages first, so you know for sure... where the fault lies.

  • Virus Ti2 and Midi Keyboard doesn't communicate

    when you have the USB connected to the virus, the Virus becomes a 'midi hub' for the computer.
    essentially connecting a Virus to a computer 'says' let the computer do the routings explicitly, and disconnect 'internal' default routings from TI keyboard and midi ports to the synth engine.


    so if you want to connect your (NI) keyboard to the Virus sound engine, you need to make this 'connection' in your DAW.
    using Virus Midi (in) to Virus Synth(out), in a similar way to the way you connect Virus Synth(in) to Virus Synth(out) to connect your TI keyboard to the synth engine (and you can connect Virus Synth (in) to Virus Midi (out), to connect the TI keyboard to an external synth)


    it may seem like a 'faff', but actually I find it quite useful now...
    e.g. I leave my Virus connected to my Spectralis via midi cables
    when the Mac is off, is a direct midi connection, but when I turn it on, and start Live (with my template) , Live is 'magically' in the loop for recording midi and looping etc.

  • Does Anyone have a perfectly working Virus TI setup?

    Mine, works fine for me...
    TI1 Keyboard 5.1.0 , MTT Hub, Mac OSX 10.9.5, Live/Logic.
    I tend to only use USB and analog outs, out of choice... rather than VC (which works ok too, but just I prefer to be hands on hardware)


    Zitat von djantimatter

    The issues I do have:
    Virus always goes into USB mode when my Mac is switched on and to play it standalone I have to disconnect the USB Cable from it.


    This is by design, as local is turned off, but you can turn it on again, without unplugging usb cable.
    (unlike midi ports which you have to unplug cable for, or route virus synth (in) to virus midi (out) using a daw)


    Zitat von djantimatter

    Powering on any of my other synths mentioned above while Logic is already running connected via USB will cause the Virus keys to stop sending MIDI on/off. It will respond to the other devices Midi ON/OFF though and the knobs still respond.


    Does the Midi device disappear? ( check in audio/midi settings)
    if so, its possibly 'sleep' related, after waking from sleep, if you power up the TI it will work fine,
    but if you then power up any other USB device after the TI, then the TI midi device disappears.
    workarounds: power up TI last, or when it disappears re-scan midi, or power TI on/off.
    its a bit of a pain, since Live, sees it as a new device (Virus TI Synth #2) , so if you have tracks targeting Virus TI Synth, then they have to be change to the new device name.
    (Ive reproduced this with quite a few usb devices, and with direct connections/hubs etc)

  • Recommended USB hub

    @mofi heres some background into why MTT hubs are important : http://www.tomshardware.com/re…usb-technology,677-3.html


    you'll note its been an issue with USB hubs for a long time (2003), the issue is, recently, apple and pc manufactures have started using internal usb hubs, and these like external hubs tend not to be MTT, this means when connecting multiple 1.1 devices, your not getting the required throughput on any of them, as its shared.
    this will mean high throughput devices like the Virus (but not exclusively, e.g. usb 1.1 audio interfaces/webcams) suffer as hub cannot buffer the data required.


    the fault really lies with the motherboards, which should give full 1.1 bandwidth, but the manufactures have assumed everyone has moved to usb 2.0 (or even 3.0) or has few 1.x devices.


    so in answer..


    Id assume VC would work BUT you will get sync issues, and audio artefacts if the USB traffic is running a system which shares a TT with multiple UBS 1.x devices,
    (but this technical 'working' might not be your definition of working :) )
    also remember this is will affect any USB work with the virus, i.e. USB midi and audio, not just VC.


    as such its not really latency, 12mbps is ample to cover both midi and the digital audio used by the Virus... but if your system is having issues with buffer overruns/sync etc, then you might perceive this as latency... but that would be a symptom rather than the cause.



    so you either :
    a) need to know your PC/Mac architecture and know what USB hubs are in use and their spec, and ensure that the Virus is not put on any (internal or external) hub that has not got MTT.


    b) use a MTT hub, and ensure you plug all USB 1.x (including the Virus) into it *
    (one MTT hub should be sufficient, as USB 2.0 (480mbps) can cope with 10-20 USB 1.1 devices (12mbps))


    as for which hubs are MTT, what I did was look up on the manufactures website, and/or contact them... and being specific about the model,
    as Marc said, the hub manufactures change the specs pretty frequently and often do not say explicitly if they use MTTs or not, so best to check.

  • Recommended USB hub

    I bought a Manhattan : http://www.amazon.co.uk/gp/product/B0035LXOPY
    and then later a Pluggable usb2.0 10 : http://plugable.com/products/usb2-hub10c2


    both appear to work fine with the Virus (both are MTT), but I will say I rarely use VC, and often just use midi + audio cables.


    The pluggable is very nice, Ive had no issues with. I got the USB 2.0, as I believe the 3.0 are NOT MTT.


    The Manhattan, I think I have a faulty one, 4 of the ports (on the left hand side) are fine, but the 3 (on the right side) I have issues with, seems like a fault connection... its not a big issue for me, as I use these to just provide power to a couple of devices, but if I needed more ports Id be upset!

  • TI2 - Metronome sound to the headphones

    there is no metronome on the TI.
    but what you could do, is use multi part mode, program one patch that used the ARP and arp hold, set to a suitable arp pattern of regular beats (user in standalone), set resolution to match beats you want, set note length to -100, then used the cutoff etc to create a reasonable sound. you can then redirect this to one of the 3 stereo outputs.
    (if your a bit smart with a clocked LFO you can also create a accent beat)


    not ideal, by any means, seems to be a waste of resource... but it should work.

    alternatively get a standalone metronome that can output midi clock and sync the virus to it :)