Avid asking for developer feedback

Just got an email from Avid asking for developer feedback. I think it would be great if many of us provide their feedback and let them know about our pain points.

OPEN SURVEY

  • Not being able to discuss AAX related topics because of an NDA
  • Tedious sign-up process
  • Being forced to use PACE code signing even if we have free plugins or other means of authentication, platform code signing (Apple / Win codesigning) should be enough.
  • Would be great to have full and official JUCE support from their side.
  • …

6 Likes

I got the same email and was going to just ignore/delete it. But after reading this, and whole-heartedly agreeing with your first 3 points… I think I will respond to their survey.

Not having to use PACE code signing would be amazing, trying to use their Eden code signing + the iLok dongle always has troubles on our build machine

1 Like

Yeah, it also means you can build on cloud servers…

2 Likes

I was initially very supportive of the AAX signing requirement. Maintaining a chain of trust through Avid and Pace for plugin binaries would have been a great way to make Pro Tools a secure platform right down to the plug-in’s signature, assuming Pro Tools wasn’t compromised (and I think we can assume Avid would make a more secure job of copy protection than individual devs rolling their own schemes in general). It is trivial to get a regular code signing cert for a hacker so I’m generally not in favour of OS signing as a security mechanism, but I doubt many hackers would get certs through Pace and it would be very easy to get them revoked meaning anybody that wants to stay current with Pro Tools couldn’t generally use cracked plugins.

So, yes an annoying a hoop to get through, but a big win for the small dev. It could have been a real business win for Avid too, if cracks never appeared for the AAX plugins then some devs that didn’t want the hassle of going deep into copy protection might choose to only support AAX. If Pro Tools was the place to get unique boutique plugins it could have been a nice little USP for the platform.

While Avid maintained the policy of disallowing AAX plugins that could load unsigned binaries it all made sense to me. It didn’t take long for that policy to change though. I guess they got a lot of pressure from a few devs that found this to be extremely hostile to their interests as they couldn’t implement genuinely useful plugins that loaded other plugins.

At this point in time I think the code signing should be dropped as a mandatory requirement. What is the benefit? I don’t see one at all in practice. People that want cracked plugins to load in Pro Tools will just follow the path of least resistance, which is loading cracked VSTs in a low cost legit AAX plugin that can load VSTs.

This is coming from a fairly strong proponent of using the entire iLok system for copy protection, I like the idea of strong copy protection in principle whatever the effect is on sales (up or down), and I use the full suite of Pace tools so I am not bothered by this signing requirement as the signing comes as part of my standard iLok workflow anyway. So I’m not just expressing some generic anti-Pace or anti-Avid or pro-freedom sentiment here. I’m simply saying for smaller devs it feels like a totally missed opportunity and I don’t see why they should have to jump through this hoop anymore if it doesn’t benefit them.

5 Likes

I took the survey and it would be awesome if all JUCE users using AAX could join.

You could actually build on a cloud server but then sign on a local machine, just needs to be another stage in your build process that runs on a local node.

Yeah it’s possible, it just kind of ruins the complete delivery method. Having to build everything on a remote machine, move aax bundles to a local machine, sign, upload and then continue with the installer build process is a real pain.

There’s all kinds of possibilities such as having a local GitLab Runner but the nice idea about simply renting a cloud server and having everything build automatically and pushed out to testers means you don’t have to worry about any build and can maintain the VMs from anywhere in the world.

It’s just another pain point with AAX.

4 Likes

They could do that but it won’t be 100% the same experience. There’s a hassle of always doing extra steps, and then there’s situations where you want to load something someone else made which uses those plugins directly and they won’t work there. Also are the plugins loaded via the other plugin are well integrated with automations, control surfaces and accessibility?