Protools 12.4 uses THREE runtime libraries.

[eesn]

Originally Posted by tengai

Unfortunately, optimism has nothing to do with software maintenance; it all comes down to discipline.

Hang on, Avid didn't get to have such an important DAW because they developed software the way nice software is developed. Read through the EULA, high change reverse-engineering is mentioned in there :] Don't get your hopes up that this will change. The arcane code is a known issue to anyone who's ever dared to give Pro Tools even a passing technical look. No wonder the screams of OSX users echo throughout this and other forums.

(I'm on your side)

[21 Junipers]

Originally Posted by darbyclash34

And again, I hear what you're saying and in theory what you're saying is correct, but you didn't actually answer any of the reasons why doing this is not possible. Oh really, redesigning what you admittedly call the very foundations of this software is minimal compared to changing plugin standards, and by your proposal forcing ALL plugin developers to update their code as well or Pro Tools won't allow it to run? Well, that's crazy. That's a ridiculously large project, and trying to go through and do this with the existing code is 100% going to make the program less stable than it currently is, at least for a good long while. Rewriting it to modern standards is probably slightly less work, but either one is a mountain of work not just for Avid but every 3rd party who wants to develop Pro Tools plugins.

You never touched on backwards compatibility, or really any of my points. Just keep repeating that this may theoretically (in a couple of years, as pointed out new code is generally buggier than old until it's out in the field and has some time to mature) make Pro Tools more stable, and ignoring that doing so would certainly kill off Pro Tools as a product and end the market for 3rd party development. You asked what we prefer? We prefer Pro Tools to exist, and be able to use our plugins in it.

I'm done with this thread, I've got enough to worry about actually using the program than to try and armchair quarterback the Pro Tools development process without ever looking at the code itself. Particularly since it's not a discussion, apparently the original is IS RIGHT and doesn't want to talk about the incredibly obvious and huge problems with what he's talking about.

To quote a musician, "Stop Making Sense".

Software engineering suffers from the same disease as audio engineering. "Everyone" has done it, is doing it, or thinks they have and therefore believes that they understand the entire matrix of the problem at hand.

[deanrichard]

As a retired software engineer of 25 years, one who wrote tons and tons of Microsoft code, I couldn't agree more. this makes no sense. None. The only excuse would be if completely different components (for example VIs and FX) were the ones using the other libraries. Even so, they should standardize.

I'm guessing the Pro Tools codebase is a complete mess right now. It went from the US team, to the Ukraine team, to the Poland team. It can't be fun to work on right now.

Originally Posted by tengai

I've been probing the running state of Protools 12.4 x64 on Windows 7 to help me to better understand of how Protools is built and why there are these strange anomalies with the behavior of Protools; such as, noise blasts and random crashes.

Using ProcessExplorer (tool) from Microsoft you can review the DLLs that are loaded with a given process and Protools.exe loads three Microsoft C/C++ runtime libraries: V8.0, V9.0, and V10. V8.0 is provided by VisualStudio 2005 (released in 2005), V9.0 by VisualStudio 2008 (released in 2007) and V10 by VisualStudio 2010 (released in 2010). Three very old compilers to boot! Lets be clear it is NEVER a good idea to mix runtime libraries in the same process; especially THREE versions. I can't stress enough, passing file handles, memory pointers, and data structures between different runtime libraries is a very bad idea. You will have problems that will be almost impossible to find and no way to fix. Other than standardizing on one runtime library.

Even Microsoft highly recommends against it: https://blogs.msdn.microsoft.com/old...11-00/?p=91611

Avid needs to get their house in order and invest time in building with only one compiler version, preferably something current such as, VS 2015; otherwise we may be seeing strangeness with Protools for some time. Or we might want to drop "Pro" from Protools.

Why a company would wont to perpetuate this type of build and run environment makes no sense. Avid is only setting itself and its customers up for incredible heartache. Perhaps this is what we are experiencing now.

Patrick

[tengai]

Originally Posted by 21 Junipers

...they understand the entire matrix of the problem at hand.

I'm not suggesting I understand the entire problem at hand; however, there are glaring clues to suggest the product foundation is not stable and there are known and simple disciplines to correct it.

And let's be clear requiring a AAX plugin developer to build with a minimum compiler version makes complete sense. Not only does it make the playing field level; it just eliminates stupid unforeseen incompatibilities problems that no serious software developer would give you the time of day if you suggest it. The software industry does this all the time.

Most likely you'd wouldn't want a plugin compiled with VS2005, a 11 year old compiler, because it would most likely be dog-slow, consume all CPU resources and make other plugin look bad. Pentium 4 code is not ideal code to run on modern CPUs.