The original version of the CCL framework dates back to 1999 when I started to work on the classic Crystal Audio Engine for my diploma thesis in engineering school. Meanwhile, it’s been (almost) rewritten three times. The most recent incarnation that’s used by most apps and certain embedded products at PreSonus is the code I’ve started with in 2004 for the K2 project. There used to be an intermediate version of CCL in my Cash Manager application and in KAE before that.

So, what’s meant by framework here? It’s basically a class library written in C++ that abstracts the underlying operating system so that application code can be written on top in a platform-agnostic way. As of today, CCL runs on Windows, macOS, iOS, and Android. A subset of it (the core library) works on Linux and certain RTOS flavors used in PreSonus hardware products, e.g. in the StudioLive AI Series, Series III digital mixers, and the FaderPort family. The broad platform coverage evolved over time based on new product requirements and I think it’s the best way for a framework to survive in the long run - it needs to adapt.

There are probably as many reasons not to write a new framework as there are to do so. It really depends on what the scope of a project is. If the focus is primarily to build an app then there’s most likely enough out there to choose from... but if it’s about creating a platform for many products that need to run on many operating systems including embedded devices the choices are narrowing down quite quickly. Nowadays, there are additional options available to desktop developers based on web technologies. They are all kind of cool but very UI-centric in the programming patterns they enforce which feels top-down to me. I prefer to start with the data model and controller design before thinking about how to reflect it in a user interface.

One of the fundamental design goals of CCL I’ve set more than 15 years ago was to support large-scale applications by encouraging modularity - to break down complexity into manageable pieces. By setting hard boundaries between modules, developers can’t circumvent and mess with it because the linker simply wouldn’t build it. In other words, most of the implementation details are hidden behind object-oriented interfaces and linked dynamically and there is a plug-in architecture built into the framework. Other highlights include a UI definition language (actually two meanwhile, JSON and XML-based), and support for scripting (primarily JavaScript). In 2015 with Studio One 3, we’ve released probably the world’s most sophisticated hardware-accelerated 2D graphics engine for Windows based on Direct2D and DirectComposition, as well as high DPI support across all platforms. More details here.

But frankly, aside from any technical or business justification the way I used to approach my then-hobby projects was by the “I can do it better” impulse. It works perfectly if you don’t know what’s ahead of you. You learn your lessons on the way. This is how to change the world - at least a little bit as we are just doing software. If you are always happy with what someone else has done before nothing is going to improve. If you reinvent the wheel it doesn’t either. You need to be better.

I’m not sure if I would do it the exact same way again today. I would certainly think about it more thoroughly. The good thing is we (PreSonus) are fast and flexible with adapting to changes made by the operating system vendor or to support new (non-standard) platforms and features. You only need to fix your own bugs and not wait for another company to do so - the downside is the additional burden of having to do it.

Do you wonder what CCL stands for? Simple answer: Crystal Class Library

For more information, see ccl.dev