TI2 and Big Sur - Disappointment

Zitat von serano

In fairness, Apple changed their architecture and security policies (Catalina), rendering the software obsolete. So it's more than just some settings. Access on the other hand released their last product in 2009 and have only been maintaining the code base.

When I read these forums, it's like everybody is mad at Access while in fact they should be mad at Apple... They made the changes, they rendered your 2K toys useless if you counted on the integration. Also everyone complaining about buying a new virus ti and not having the integration were negligent on their part for not doing the research.

I'm not sure who that comment was directed at "it's more than just some settings". Absolutely it's Apple who have made significant architectural changes - firstly the move to only supporting 64-bit (which is what this thread is about really) - and then the move to user-mode drivers going forward.

However Access have been completely non-comital around whether they are going to update their Mac software or not. That's unacceptable. Some of us would quite happily pay for them to work on an update.

Also I strongly disagree with your comment around the buyers of a new TI hardware being at fault and negligent if they don't research Mac compatibility. Access should be actively highlighting the Mac compatibility issue. If they aren't then it's Access that is negligent and at fault.

Zitat von hugol

I'm not sure who that comment was directed at "it's more than just some settings". Absolutely it's Apple who have made significant architectural changes - firstly the move to only supporting 64-bit (which is what this thread is about really) - and then the move to user-mode drivers going forward.

However Access have been completely non-comital around whether they are going to update their Mac software or not. That's unacceptable. Some of us would quite happily pay for them to work on an update.

Also I strongly disagree with your comment around the buyers of a new TI hardware being at fault and negligent if they don't research Mac compatibility. Access should be actively highlighting the Mac compatibility issue. If they aren't then it's Access that is negligent and at fault.

+1. I bought a new Darkstar last year thinking they would eventually sort this mess out.

Zitat von hugol

I'm not sure who that comment was directed at "it's more than just some settings". Absolutely it's Apple who have made significant architectural changes - firstly the move to only supporting 64-bit (which is what this thread is about really) - and then the move to user-mode drivers going forward.

However Access have been completely non-comital around whether they are going to update their Mac software or not. That's unacceptable. Some of us would quite happily pay for them to work on an update.

Also I strongly disagree with your comment around the buyers of a new TI hardware being at fault and negligent if they don't research Mac compatibility. Access should be actively highlighting the Mac compatibility issue. If they aren't then it's Access that is negligent and at fault.

The comment was made against the general sentiment going around this thread.

Now the '64bit only' was not the killer, Access has a 64bit application available and works just fine. What killed the Virus in Catalina was the new rule to prohibit kernel extensions. The philosophy that Apple has determined where you as a user cannot determine what a computer can or cannot do within its hardware possibilities is beyond apprehension. The trend from the app store only is being propelled further on their platform and you have to tweak settings to actually be able to install 3rd party plugins, even on Mojave. It's ridiculous. All this to vendor lock you in, and so they can get their 30% piece of the pie from any sales.

Could you as a developer (Access) have foreseen this in the past? Not really. Now the task at hand to make it compatible with the ARM architecture makes it even more complicated than it was before and boy it would mean a full code overhaul. So I'll go on a limb here and guess that Apple knew what was coming and correctly scheduled it on their last intel branch models and quote 'security' as their main reason, taking away scrutiny from the M1 that would have caused the same issues and even on a lower architectural level.

As for my previous statement about Access not being at fault for Integration part, I stand by it. Also they do their due diligence by making sure the information is available on their site and forum that Mac currently has issues. The one part where I do agree with you, is that their transparency in regards to the future and a possible resolve, are sub-par.

Zitat von serano

Could you as a developer (Access) have foreseen this in the past? Not really. Now the task at hand to make it compatible with the ARM architecture makes it even more complicated than it was before and boy it would mean a full code overhaul. So I'll go on a limb here and guess that Apple knew what was coming and correctly scheduled it on their last intel branch models and quote 'security' as their main reason, taking away scrutiny from the M1 that would have caused the same issues and even on a lower architectural level.

As for my previous statement about Access not being at fault for Integration part, I stand by it. Also they do their due diligence by making sure the information is available on their site and forum that Mac currently has issues. The one part where I do agree with you, is that their transparency in regards to the future and a possible resolve, are sub-par.

I work for a developer/electronics manufacturer which uses both iOS and MacOS so I have background knowledge of how this works. Apple does release confidential memos notifying developers of upcoming changes in each OS version when they start to appear beta builds for SDK holders. These changes are known well enough in advance so that developers can make necessary changes to maintain compatibility. So that part of your argument is invalid.

Also, I am acquainted with Sean Costello who is the driving force behind Valhalla DSP. He recently posted that it took him a day to re-code one of his plugins for the new M1 platform - https://www.facebook.com/ValhallaDSP/posts/10158708762617226 He's also released M1 compatible builds of his commercial plugs for the new platform as well within a month of the new platform becoming fully available. So this is not the massive code overhaul you are describing, even with the simplistic GUIs he is using in his products.

So from my perspective based on my knowledge of how these situations work, Access/Kemper and Ploytec had MONTHS of advance knowledge of these forthcoming changes with Catalina. The problem I often find is that many developers either wait until the last minute to get their code compatible with new OS releases or don't do it until the new OS version is already released to the Public. Ploytec updated the drivers and passed them on within a reasonable amount of time so the fault for this lapse lies squarely with Access/Kemper.

Zitat von serano

The comment was made against the general sentiment going around this thread.

Now the '64bit only' was not the killer, Access has a 64bit application available and works just fine. What killed the Virus in Catalina was the new rule to prohibit kernel extensions. The philosophy that Apple has determined where you as a user cannot determine what a computer can or cannot do within its hardware possibilities is beyond apprehension. The trend from the app store only is being propelled further on their platform and you have to tweak settings to actually be able to install 3rd party plugins, even on Mojave. It's ridiculous. All this to vendor lock you in, and so they can get their 30% piece of the pie from any sales.

Could you as a developer (Access) have foreseen this in the past? Not really. Now the task at hand to make it compatible with the ARM architecture makes it even more complicated than it was before and boy it would mean a full code overhaul. So I'll go on a limb here and guess that Apple knew what was coming and correctly scheduled it on their last intel branch models and quote 'security' as their main reason, taking away scrutiny from the M1 that would have caused the same issues and even on a lower architectural level.

As for my previous statement about Access not being at fault for Integration part, I stand by it. Also they do their due diligence by making sure the information is available on their site and forum that Mac currently has issues. The one part where I do agree with you, is that their transparency in regards to the future and a possible resolve, are sub-par.

Alles anzeigen

I don't disagree that Apple has moved the goal posts and broken backward compatibility. Indeed they have taken a very different approach to Microsoft - who ship endless backward compatibility layers. I strongly disagree that the changes are about Apple controlling what you can or can't do on your computer. It's just about trying to enhance security. Personally (as painful as it is) - I think the Apple approach is better from a security perspective.

Replacing kernel level extensions with user-mode equivalents - is surely a positive thing - providing the user-mode replacements offer equivalent real-time performance / latency. I agree with Apple here, from a security perspective.

As for the M1 - it's trivial to re-compile your application via Xcode for compatibility with both X86 and M1.

As a software engineer myself - I am a firm believer in constantly/ incrementally updating the libraries/frameworks that your application relies upon - and not just leaving your application to rot. We've long adopted this approach for our own software - and it's served us well.

Zitat von hugol

I don't disagree that Apple has moved the goal posts and broken backward compatibility. Indeed they have taken a very different approach to Microsoft - who ship endless backward compatibility layers. I strongly disagree that the changes are about Apple controlling what you can or can't do on your computer. It's just about trying to enhance security. Personally (as painful as it is) - I think the Apple approach is better from a security perspective.

Replacing kernel level extensions with user-mode equivalents - is surely a positive thing - providing the user-mode replacements offer equivalent real-time performance / latency. I agree with Apple here, from a security perspective.

As for the M1 - it's trivial to re-compile your application via Xcode for compatibility with both X86 and M1.

As a software engineer myself - I am a firm believer in constantly/ incrementally updating the libraries/frameworks that your application relies upon - and not just leaving your application to rot. We've long adopted this approach for our own software - and it's served us well.

Alles anzeigen

Absolutely. I 100% agree with you. Apple is making changes for the best and developers need to follow and update their software. We're in 2021, it's not 2005 anymore.

Zitat von hugol

As a software engineer myself - I am a firm believer in constantly/ incrementally updating the libraries/frameworks that your application relies upon - and not just leaving your application to rot. We've long adopted this approach for our own software - and it's served us well.

Moving drivers out of kernel space, is definitely a good thing security-wise.

In the case of USB streamed audio via a plug-in, since Elektron are now using the Apple frameworks for their system, it also means that they're not reliant on Ploytec to get their act together every time the OS changes.