Beiträge von reno

Zitat von oliAtBass

May I suggest you read this:
https://forums.developer.apple.com/thread/65232

Seems like random USB drivers don't work anymore with Sierra.
Enjoy!

Doesn't really seem to apply to our problem.
But after reading your post, I did a bit of searching , and I'll bet my limited edition Whiteout TI2 Keyboard that THIS is the issue :
https://forums.developer.apple.com/thread/50380

And indeed, the Virus driver has exactly the problematic layout they describe :

$ file /Library/Extensions/AccessVirusTI.kext/Contents/MacOS/AccessVirusTI
/Library/Extensions/AccessVirusTI.kext/Contents/MacOS/AccessVirusTI: Mach-O universal binary with 2 architectures: [x86_64: Mach-O 64-bit kext bundle x86_64] [i386: Mach-O object i386]
/Library/Extensions/AccessVirusTI.kext/Contents/MacOS/AccessVirusTI (for architecture x86_64):    Mach-O 64-bit kext bundle x86_64
/Library/Extensions/AccessVirusTI.kext/Contents/MacOS/AccessVirusTI (for architecture i386):    Mach-O object i386

Which confirms that this is at most a one day job to fix.
(Don't want to push the envelope too much, but look at the date of the Apple forum describing the fix : June 28th... )

Zitat von Stache

Well in my opinion a lot of people can complain this and that about Access, but most of these people seem to forget that Access has always provided a support for the virus that was second to none.
This from day 1 back in 1997.
And once the Virus TI hit the market back in mid 2000 the support and growth has been amazing for this unit.
Take note that most hardware music oriented material drops in support after 2 or 3 years, this is a hard fact except for a small select few companies.
Then more important, is that really most people here think Access (Kemper) is a giant company, and this is not correct as it's a company that is not huge but is very demanding on quality of the products they develop and construct.
So when development and construction for one or more of their products has to be done to supply the retailers (their Amp or the Virus) ; this then is in my opinion always priority number one as smaller companies stand or fall by their sales, no sales would mean no Access anymore and then really no solutions in time.
As you might have noticed Access is still selling a lot of Virus units, and the demand is not really going down as some really think.
I follow a lot about synths and sales for it all over the internet and i can tell you that even the Snow is still very popular and people still want it.

Alles anzeigen

Completely agree with you here. Don't get me wrong, I love Access and realise they are a small shop.

Just pointing out that this mentality of "let's not hurry testing with the new OS, our clients don't upgrade anyway" that is prevalent in the audio world, is disappointing when Apple gives developers an easy opportunity to test and solve problems more quickly.

Zitat von Stache

I do realize very well what SIP is and does.
But like most serious studio geeks that work full time in the studio we all use a Mac/PC that i uniquely used for the music and is not even really connected to the internet most of the time.
So disabling SIP is really not a concern for me and for some others.

Carry on !
I'm back in my studio, enjoying my TI's on Sierra.

Alles anzeigen

That is cool, but not everyone has both the luxury of a dedicated studio machine, AND the knowledge to disable system stuff like this

Zitat von Stache

This should give the staff at Access some breathing space for the official driver.

It should yes, and I'm happy we now have this workaround.
But you know what, the real breathing space is called "macOS beta testing period" and it's from June to September each year.
Some of us are angry that (as far as we have been told) this hasn't been taken advantage of to avoid the whole mess, and a user had to find and provide this workaround.

Zitat von Stache

I really don't understand some people here crying like little babies and moaning towards Mark and the other Access Staff members.

You don't understand because you don't seem to realise what disabling SIP does. It's like driving your Mac without a safety belt.
The procedure is also not easy for complete novices to do (and people will 100% forget to switch it back on later), which is probably why Access isn't mentioning it.

Finally, because you are the 3rd person here to confirm that everything works fine with SIP disabled, it means that there is only a signature problem, which means almost zero code changes required from Access or their supplier.
Unless Apple currently has a serious bug with driver signatures in Sierra (not impossible, but unlikely because a lot more hardware would be affected and you would hear about it), then I reasonably believe that getting a new certificate and signing the existing code with no other changes at all, is at most a half-day's job for a developer. Is someone on holiday or in the hospital ?

Zitat von oliAtBass

Fascinating... with all your cleverness, education and skill level, how keen you are to condemn Access and cast the first stone...

With 20+ years experience in SW development, I can tell you it's always these "< 1h" jobs that turn out to be a huge headache. It may be a 1 hour job if you know exactly what to do. But what if not. What if there are problems. And even if you get it done within an hour, there's still the whole build process, testing, packaging, publishing. And all of a sudden you face weeks of unplanned work load.

If the fix is actually to switch off signature checks, then this could (and should) have been announced by the manufacturer. But maybe that's just the surface...

I have a similar level of SW dev experience (although not first hand on Apple platforms) and you have a point of course, maybe that's just the surface : this is why I didn't want to jump to conclusions and I said "this MIGHT mean".

However, we have two people here (skittb123 who found the workaround, and wascal) who are saying that disabling signature checks seem to be enough to restore full functionality.

It may well mean that this is the only issue, and if that is true then I'm sure you'll agree that doing a new build and signing it with whatever new type of certificate is required for Sierra, sounds like a 1 hour job (excluding any further testing / QA). And even if it turns out to really be a 1 month job, my point is that there was plenty of time since June to do it.

Unless of course, this is an Apple bug around kext signatures that only they can fix (a good clue that it might be the case here is that kext signing certificates are not new : they were introduced with Yosemite, so the current driver for El Capitan should already have that). In that case of course, Access or Ploytech are not to blame at all, Apple is.

My money is still on the first scenario though...

I've looked a little closer ... the issue doesn't seem to be with system files that can't be written.
It's rather that the driver's signature can't be verified anymore ("ERROR: invalid signature for de.access-music.virus_ti.driver.audio, will not load"), and so SIP prevents it from loading... (*)

I haven't tested yet but I'm pretty sure that in this case, instead of "csrutil disable" in your solution, you can use "csrutil enable --without kext"
This should be enough to make it work and is slightly safer for your Mac, as it will not disable all security systems but only the "kext integrity" one which is causing the problem (still not ideal, but hey...)

(*) BTW this MIGHT mean that the fix for the developer is really just a matter of getting a new Developer Certificate, building the driver again and signing it, which requires zero code changes and is a <1 hour job... Ok, there is a small chance that the driver is fine, and there's a bug with signature checking in Sierra that only Apple can fix... but let's be serious : my money is 80% on the former (which of course should make everyone very angry, because if this is indeed the problem, then it could have been addressed since June...... )

This is interesting because SIP was actually introduced in El Capitan last year, not Sierra, and a quick search shows it's not supposed to have changed since : https://forums.developer.apple.com/thread/48983

In any case, if SIP really is the problem, this was definitely testable from June 13th.

Zitat von Marc

at least take the time to read the relevant posts in this forum we are not silent on it. we've said that we will be late for 10.12 before 10.12 was released. we've also said we are waiting for the company who we license the driver from. i'll post something here once we there are news. of course this has priority.

Hi Marc,
Don't want to speak for everyone but I think we can all understand that you're relying on a third party (Ploytech?) and their timing is now beyond your control. There are 2-3 things that should be in your control though:
1. Please start pressuring your supplier asap when things break. Maybe you did, but it is not clear from your Sept 8th announcement when you found out about the incompatibility : I hope it's rather in June than early September ! It is too late to fix it for this year and blaming won't make things go faster, but please please please, do that next year ! A lot of precious development time has potentially been lost over the summer
2. It's not a nice feeling as a customer to read you telling people not to panic, or judging that nobody should be in a rush to upgrade. Please own the problem.
3. In the meantime, would you consider the idea of releasing a stripped-down audio-less version of VC that doesn't rely on any drivers, just plain MIDI ? Even if USB Midi doesn't work, that would be a much more future-proof fallback solution !

Zitat von TNTRox

Just a note though, Apple keeps doing this, I have already thrown out my firewire gear because it is not compliant with mac's new thunderbolt to usb converter..

Apple should understand that people have gear attached to their hardware, that is why they supply ports, so they should inform users of changes that can effect their hardware integration before installing.

I don't get it. You're saying that your FW gear doesn't work with a TB->USB converter. That's for sure... but why don't you get a TB->FW converter then ?
I'm using an OWC Thunderbolt 2 dock for my Mac, it has a FW 800 port which works just fine with my MOTU Ultralite mk3.

Zitat von oliAtBass

A funny thing to say about two of the oldest and most successful audio software companies.

And yet this is what they're doing despite making great instruments / DAWs : being notoriously worse at getting ready for OS releases than the rest of the Mac ecosystem.
There is not a great reason for that (if you know one, I'm curious), so it is probably just "musicians are not very aggressive at upgrading their OS, no need to rush, they'll let us get away with it"

Zitat von oliAtBass

You generally don't want to develop against beta versions of libraries with that sort of complexity involved.

Except that Apple knows a thing or two about software development best practices, they're not crazy, so major API changes are completed and frozen in time for the first Developer Preview, until the next year. As a developer you can rely on being able to code against that, without Apple pulling the carpet under your feet again in 2 weeks time. Everyone would be furious if they did that.

It's not the case of course, so this 3 months time is the opportunity to discover any major changes you should start adapting to straight away.
What seems acceptable to me maybe is to leave QA / final testing for the golden master if not the final release, and that means everything should in any case be ready within 1-2 weeks max. 2-3 months is simply unprofessional.

Zitat von oliAtBass

Did you guys see the announcements by Native Instruments and Steinberg to NOT upgrade to Sierra?!

And yes, it's the same every OSX release... with the aforementioned companies. Sometimes not even Logic works any more as desired.

Funny that you expect Access to be better than some of the big players in audio software...

Well it just means NI / Steinberg are not an example to follow.
I don't think anybody will blame them if the Apple changes were so disruptive that it took them more than 3 months of work to fix and QA, starting in June (but that's unlikely)
No, the real problem is that each year, the way they communicate makes it seem like they're only starting the work in September, at the end of the Apple beta cycle, not taking advantage of developer previews at all. And that, frankly, is not respectful of customers *

What I would really like to understand is why it seems to be such a big problem in the audio industry in particular : I don't think it's for technical reasons alone (it's not like Apple isn't making changes all over the place that affects most non-audio developers too !)... no, the thing is, I saw updates coming all over the summer for most of my other apps. It seems like everyone else is taking advantage of developer previews and many are ready on day 1. So I can only guess that audio devs know they'll get away with starting in September, because their customers (musicians) have a rather conservative attitude towards upgrades. This isn't good for anyone...

*last year was an exception, as clearly Apple broke something on their end with AU validation, that was only fixed in 10.11.1, so they were the ones to blame here. But it's an exception.

Just wanted to show support, completely agree with your points.
Let developers like us become contributors instead of whiners

I also suggested in another thread that, at least, a stripped-down version of VC that acts as a librarian with no USB functionality but still allows you to open existing projects, would be better than nothing if the TI were to be abandoned at some point.

Zitat von Marc

thetechnobear: i've already posted something re. future Sierra support. we are waiting for the company who supplies the drivers. and since i've posted a warning some time ago, you can see that we are receiving developer previews. that's why i know that it doesn't work.apple doesn't remove the download option from the app store for users who have downloaded a specific OS already. and the minimum specs for all apple apps are way below 10.10 - there is no reason to rush and upgrade. don't panic.

It is a bit disappointing to see you downplay the problem so much, instead of sticking to the (much more appropriate) apologies you made in the announcement : many people have good reasons to upgrade which are not all yours to judge, and others don't even have a choice. It feels slightly insulting as a customer to read "no reason to rush" or "don't panic", coming from someone who's late : if this is indeed your opinion that there's no rush, that explains a lot and doesn't help us trust that you're doing everything you can to pressure your supplier or looking for workarounds in the meantime...

You suggest downloading 10.11, but downgrading an OS is not a supported operation (when it even works, it's likely to leave a huge mess in an existing installation)
And the reality is that people buying new Macs for the past 2 weeks simply can't use the Virus TI as intended. The timing is especially bad because you can expect many people to upgrade to the new Macbook Pros scheduled in late October : anything < 10.12.1 will *definitely* not be able to support the new hardware. So, you might have even more annoyed people very soon if your supplier doesn't hurry up.

As Technobear rightly says, the disappointing part is that like every year, it was possible to know about this since June 13th and to start working on it (or in your case maybe warn customers / start putting pressure on the 3rd party driver company). You mention a warning you posted some time ago, as proof that you're watching developer previews : was it the Sept 8th announcement ? I couldn't see anything else. That's not very early, I hope you didn't first find out about the issues in September and contact your supplier only then...

That being said, let's try and be constructive : is VC completely broken or is it just the CoreAudio driver functionality ?

Would you consider at some point releasing a stripped down version of VC without USB audio streaming, just analog outs and the librarian/editor functionality over MIDI ?
This kind of "VC lite" should be relatively future-proof and immune to new OS changes, and it would allow people to at least open existing projects and use the Virus with the analog outputs forever.
Even if you completely moved on to a different line of products and stopped supporting the TI/TI2 someday, or got fed up with Apple

Hi,

OS X 10.11 El Capitan is released this Wednesday Sept 30th.
Has anyone tried the latest Virus software (audio drivers + VC) with it ?

Fingers crossed that it already works

Zitat von Organik

Hello everyone I was just wondering how come no one mentioned about the preset browser in Virus TI Software ? It is very difficult to navigate at the moment. I am sure VIrus team can make it lot more organized . For example Native instruments browser set up is fantastic . You simply can chose type of instrument , attributes and type of sound sort of categorization which is lot easire to navigate that the current in Virus TI. It will give the software a great boost and more user friendly any chance to get this update in 2014 ????? I would event pay for such an update because I love my virus TI . thanks

I came here to say just that.

The TI has this marvelous backwards compatibility down to the Virus A almost 20 years ago !

But as a consequence, I now have over 200 soundsets in my Patches directory and it's really, really hard to browse through them.
One single "Category" dimension is just too little, to the point of becoming useless : for example, my "ARP" category has 17 pages (!!)

In this situation I will usually find the right sound by chance, after I get bored going through dozens of pages, and it's frustrating to know that I might have had the perfect patch in my collection but didn't have a chance to narrow the search down by music genre, aggressiveness, etc to find a great fit. (DSP usage would be cool to have too )

In 2015, other software (I'm thinking of Native) is handling that much better.
I understand that for backwards compatibility reasons and because banks currently need to be saved as MIDI files, there is only so much metadata one can add and we will probably never have something as great in VC as the Native stuff, or arbitrary tags etc. (well actually, I wouldn't mind if VC moved to a more feature-rich file format to enable this, as long as you could export/import to MIDI ! I personally don't even care if the hardware browser only retains "Category" as long as something better is available in VC)

I think at least something should be done to the UI to better handle 100s of soundsets better. Productivity is a big deal and it's a strong point of soft synths, VC shouldn't fall behind

Hi,

I've just sent this to support, but I thought I'd reproduce it here so that anyone with the same issues know that they're not alone.

Since I sent support an email, I've also found out the TI may not be the only driver with this problem (see http://stackoverflow.com/a/20407016 ), it sounds like it might be significant work to fix

-------------

The latest 5.1.0.0 driver is causing problems in OS X Yosemite with some CoreAudio software, especially (and strangely) when the Virus is *NOT* connected to the Mac, or NOT selected as the default CoreAudio device in Audio/Midi Setup.

Just having the driver loaded causes issues, such as : the new Facetime feature that allows to make calls on a Mac through an iPhone, fails each time.

After some digging around in system logs (I'm a software engineer) I suspected that the Virus driver might be the cause of these issues : I've uninstalled it and indeed all went back to normal.

Here are some of the logs I get in the OS X console when trying to make a call on the Mac through the iPhone, with the Virus *POWERED OFF* :

17/10/2014 16:02:42,935 callservicesd[17016]: Enter CreateAudio
17/10/2014 16:02:42,936 callservicesd[17016]: CreateAudio: CurrentprocessName callservicesd PGKernelDeviceVirus
17/10/2014 16:02:43,879 callservicesd[17016]: Failed to get the bundle id

17/10/2014 16:33:21,762 callservicesd[37439]: CurPID=37439, curUID=501 process=NO_NAME
17/10/2014 16:33:21,763 callservicesd[37439]: CurrentprocessName is callservicesd
17/10/2014 16:33:21,763 callservicesd[37439]: Found a device of class PGKernelDeviceVirus (won't write), result 00000000.
17/10/2014 16:33:21,765 callservicesd[37439]: fwUpdaterActive: No updater detected
17/10/2014 16:33:21,765 callservicesd[37439]: before m_cTreadStartStopSemaphore.wait
17/10/2014 16:33:21,766 callservicesd[37439]: after m_cTreadStartStopSemaphore.wait
17/10/2014 16:33:21,766 callservicesd[37439]: UID= VID_133E_PID_0815_BUS_80110000

18/10/2014 00:03:32,295 sandboxd[6929]: ([8469]) FaceTime(8469) deny iokit-open AudioUserClientVirus
18/10/2014 00:04:31,954 coreaudiod[396]: PtASPlugInAddDeviceClient Bundle Ref: com.apple.FaceTime, clientID 871
18/10/2014 00:04:31,967 FaceTime[8528]: Enter CreateAudio
18/10/2014 00:04:31,967 FaceTime[8528]: CreateAudio: CurrentprocessName FaceTime PGKernelDeviceVirus
18/10/2014 00:04:32,074 FaceTime[8528]: getHogID failed
18/10/2014 00:04:32,074 FaceTime[8528]: CurPID=8528, curUID=501 process=NO_NAME
18/10/2014 00:04:32,074 FaceTime[8528]: CurrentprocessName is FaceTime
18/10/2014 00:04:32,075 FaceTime[8528]: Found a device of class PGKernelDeviceVirus (won't write), result 00000000.
18/10/2014 00:04:32,075 FaceTime[8528]: Could not open device - exit
18/10/2014 00:04:32,618 sandboxd[6929]: ([8528]) FaceTime(8528) deny iokit-open AudioUserClientVirus

FaceTime(8528) deny iokit-open AudioUserClientVirus

Process: FaceTime [8528]
Path: /Applications/FaceTime.app/Contents/MacOS/FaceTime
Load Address: 0x108da9000
Identifier: com.apple.FaceTime
Version: 2142 (3.0)
Build Info: 6-FaceTime~2142000000000000
Code Type: x86_64 (Native)
Parent Process: launchd [1]

Date/Time: 2014-10-18 00:04:32.076 +0100
OS Version: Mac OS X 10.10 (14A389)
Report Version: 8

Thread 0:
0 libsystem_kernel.dylib 0x00007fff8f0a352e mach_msg_trap + 10
1 IOKit 0x00007fff8f2c9dfc io_service_open_extended + 144
2 IOKit 0x00007fff8f26dd91 IOServiceOpen + 45
3 de.access-music.virus_ti 0x000000010d381093 DriverConnection::ioOpenConnection() + 115
4 de.access-music.virus_ti 0x000000010d38100a DriverConnection::DriverConnection(unsigned int) + 138
5 de.access-music.virus_ti 0x000000010d388c91 PGOSXDevice::PGOSXDevice(AudioHardwarePlugInInterface**, DeviceManagerClient*, unsigned int, OSXDeviceManager*) + 65
6 de.access-music.virus_ti 0x000000010d388c43 PGOSXDevice::PGOSXDevice(AudioHardwarePlugInInterface**, DeviceManagerClient*, unsigned int, OSXDeviceManager*) + 51
7 de.access-music.virus_ti 0x000000010d37ac90 OSXDeviceManager::notifyNewDevice(unsigned int) + 80
8 de.access-music.virus_ti 0x000000010d37ae8b OSXDeviceManager::ServicePublished(unsigned int) + 27
9 de.access-music.virus_ti 0x000000010d37adef OSXDeviceManager::ServicesPublished(unsigned int) + 79
10 de.access-music.virus_ti 0x000000010d37a6b7 OSXDeviceManager::ScanServices() + 71
11 de.access-music.virus_ti 0x000000010d37a5ae OSXDeviceManager::OSXDeviceManager(AudioHardwarePlugInInterface**, DeviceManagerClient&, bool) + 2174
12 de.access-music.virus_ti 0x000000010d379d24 OSXDeviceManager::OSXDeviceManager(AudioHardwarePlugInInterface**, DeviceManagerClient&, bool) + 52
13 de.access-music.virus_ti 0x000000010d37b3cb PGAsioDriver::onInitialize(unsigned int) + 107
14 de.access-music.virus_ti 0x000000010d37c12b PGAsioDriver::onInitializeWithObjectID(unsigned int) + 27
15 de.access-music.virus_ti 0x000000010d37c103 AudioDriverInitializeWithObjectID(AudioHardwarePlugInInterface**, unsigned int) + 35
16 CoreAudio 0x00007fff922e335f HALPlugInManagement::CreateHALPlugIn(HALCFPlugIn const*) + 1263
17 CoreAudio 0x00007fff922e2450 HALPlugInManagement::Initialize() + 306
18 CoreAudio 0x00007fff922e024f HALSystem::CheckOutInstance() + 147
19 CoreAudio 0x00007fff922fb668 AudioObjectGetPropertyDataSize + 126
20 AVConference 0x000000010ce8ffb5 +[AVInternalDeviceList newDeviceList] + 67
21 AVConference 0x000000010ce90337 -[AVInternalDeviceList init] + 93
22 AVConference 0x000000010ce90a1e -[AVAudioDeviceList init] + 87
23 AVConference 0x000000010ced0614 -[AVAudioClient init] + 87
24 IMAVCore 0x0000000108f2ee45
25 IMAVCore 0x0000000108f2ed89
26 libdispatch.dylib 0x00007fff8be63c13 _dispatch_client_callout + 8
27 libdispatch.dylib 0x00007fff8be63b26 dispatch_once_f + 117
28 IMAVCore 0x0000000108f2ed43
29 IMAVCore 0x0000000108f084f0
30 TelephonyUtilities 0x00007fff885505b9 -[TUCallCenter initWithDaemonDelegate:] + 1429
31 TelephonyUtilities 0x00007fff8854fe1f __50+[TUCallCenter _sharedInstanceWithDaemonDelegate:]_block_invoke + 51
32 libdispatch.dylib 0x00007fff8be63c13 _dispatch_client_callout + 8
33 libdispatch.dylib 0x00007fff8be63b26 dispatch_once_f + 117
34 TelephonyUtilities 0x00007fff8854fdea +[TUCallCenter _sharedInstanceWithDaemonDelegate:] + 98
35 FaceTime 0x0000000108ded299
36 AppKit 0x00007fff917a8a49 -[NSCustomObject nibInstantiate] + 346
37 AppKit 0x00007fff917a888b -[NSIBObjectData instantiateObject:] + 309
38 AppKit 0x00007fff91c8ada1 -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] + 452
39 AppKit 0x00007fff9179d055 loadNib + 384
40 AppKit 0x00007fff91d0b020 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 313
41 AppKit 0x00007fff9179c725 -[NSBundle(NSNibLoading) loadNibNamed:owner:topLevelObjects:] + 201
42 AppKit 0x00007fff9179c4f1 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 344
43 AppKit 0x00007fff91797f59 NSApplicationMain + 605
44 libdyld.dylib 0x00007fff879425c9 start + 1

Binary Images:
0x108da9000 - 0x108e9afff com.apple.FaceTime (3.0 - 2142) <c9d2e404-be45-3975-8e91-698bd27fabe1> /Applications/FaceTime.app/Contents/MacOS/FaceTime
0x108ef1000 - 0x108f50fff com.apple.imavcore (10.0 - 1000) <e69fe779-0254-3f7b-8689-8e55ae06ce2f> /System/Library/PrivateFrameworks/IMAVCore.framework/Versions/A/IMAVCore
0x10cdd2000 - 0x10cf33ff3 com.apple.AVConference (3.0 - 734.4) <1ef03188-706d-3c08-8d22-bc09ee145708> /System/Library/PrivateFrameworks/AVConference.framework/Versions/A/AVConference
0x10d368000 - 0x10d3a8fff de.access-music.virus_ti.util.hal (3.3.0) <b08d36ed-c9de-3b3b-91d5-a627e7295263> /Library/Audio/Plug-Ins/HAL/de.access-music.virus_ti.plugin/Contents/MacOS/de.access-music.virus_ti
0x7fff8793f000 - 0x7fff87942ff7 libdyld.dylib (353.2.1) <19faf435-c165-3374-9def-d7bba7d61db6> /usr/lib/system/libdyld.dylib
0x7fff88541000 - 0x7fff8856fff7 com.apple.TelephonyUtilities (1.0 - 1.0) <72b8d7a4-c6be-330e-942b-c90f824cdc89> /System/Library/PrivateFrameworks/TelephonyUtilities.framework/Versions/A/TelephonyUtilities
0x7fff8be62000 - 0x7fff8be8cff7 libdispatch.dylib (442.1.4) <502cf32b-669b-3709-8862-08188225e4f0> /usr/lib/system/libdispatch.dylib
0x7fff8f092000 - 0x7fff8f0affff libsystem_kernel.dylib (2782.1.97) <93e0e0a9-75b6-3904-bb4e-4bc7c05f4b6b> /usr/lib/system/libsystem_kernel.dylib
0x7fff8f268000 - 0x7fff8f2d9ff7 com.apple.framework.IOKit (2.0.2) <ed3b0b22-aacc-303b-bfc8-20ecd1af6ba2> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x7fff91795000 - 0x7fff922d6fff com.apple.AppKit (6.9 - 1343.14) <1732c412-257b-340e-8863-b8162d4eb2e2> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7fff922df000 - 0x7fff92330ff7 com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <af72b06e-c6c1-3fae-8b47-af461cae0e22> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio

Zitat von optik

usb 1 is enough for what it does - you guys asking for usb would most likely have the same issues with your pc/mac hardware even if it was usb3...it works fine on usb 1 for me, both on my PCs and on my macbook.the problem isn't usb1 - it's your computer.

Oh yes it is... It took YEARS and probably very smart engineering inside the TI plugin to work around the limitations of USB1 and the unreliability of its timing in particular.Thunderbolt would be ideal, but it's not popular outside of the Mac world yet, so it would make most commercial sense for Access to go with USB3.

Any updates ?

Yosemite is now 2-4 weeks away from public release and already is widely available to developers & beta testers.
Despite billcarroll's encouraging report I haven't dared take the plunge yet (one reason is that I know for sure that my MOTU interface drivers aren't ready)

I second this request.
I understand the "no hub" check is there to avoid countless support questions, but let advanced users try it at their own risk, unless there's a real technical reason.

Thank you, thank you Access !!!!

Ok actually, I didn't make music with the new driver yet... BUT still, I was so happy to have my very expensive white soundcard at last able to play a sweet iTunes playlist on my speakers, just when I was in good company ...

So I hereby give your kext, the award of the most useful piece of 64-bit code I've ran in Snow Leopard so far

And to the whiners out there : who cares about Windows, girls prefer Macs (and Polars) anyway
(kidding ... or maybe not!)

Zitat von DunklerEngel

Works fine for me when using the 32 bit kernel. Using Logic Pro 9, Snow Leopard Retail, and Virus TI Desktop. In the 64 bit kernel however, the Virus isnt recognized on VC startup.

Can you confirm these 2 problems that I still have ?
- Can't use the TI as an audio device in other apps (iTunes for example)
- Need to have the TI connected and running when Snow Leopard boots up to have it recognized.