I. The Dilemma of Audio: Many Versions, No Control.
Version control is not at all a new concept for iterative endeavors, having been used in industrial manufacturing and design, before it was ported to the domain of programming.
However, given the meteoric rise of complex software, it has become ubiquitous, with the star player being git. In less than a century from the genesis of the field, programming has effectively solved the issue of version control.
Now, it is time for the creative domain to evolve, and adopt version control, as a integral part of its existence. A quick look around the internet will make it clear that the creative domain, has not progressed beyond First-generation version control, simply saving file names with appended and incremented series of numbers, and sharing work by emailing files.
While that may work for individual local projects, it's inefficient, unwieldy, and makes collaboration painful, providing no way to way to synchronize changes, and combine work done on various parts of creative projects. It offers no utility in the way back-ups, leading to a common problem in, for example, the music industry, where files are lost forever.
In 2008, a fire at Universal Studios Hollywood destroyed roughly one to two hundred thousand master recordings, belonging to iconic artists and bands like Elton John, Nirvana, Janet Jackson, Niel Diamond, Aerosmith, Aretha Franklin, Ray Charles, Lynyrd Skynyrd and Slayer.
Lucian Grainge, the CEO of Universal Music Group said in response to the event that
"...the loss of even a single piece of archived material is heartbreaking."
He's correct.
ArtRiver exists to make it so that none of these problems afflict the creative process any longer. No one, from the humble hobbyists, to the greatest artists of our time, and times gone by, should lose entire pieces of artwork, due to freak accidents, and human error.
In an era where the creation of art is highly technological, and iconic art from the analog era becomes digitized, version control, which is so pivotal in creating the tools for making and translating art to a new medium, has a powerful and necessary role to play.
II. Music Must Meander to be Made: Rafting Toward Watershed Moments.
ArtRiver is a distributed version control system for musicians, that will allow artists to track and navigate the various branches and possibilities a creative work went through, on the way to completion.
Artriver exists to allow artists to draw from a granular record of the various tweaks and changes they make to various pieces of art, by coalescing these creative excursions in various directions into a navigable digital construct.
Artists can avoid the worry of accidental deletions, not just of whole works, but of parts of versions of works, and the like. From another perspective, it offers a new methodology to hone their craft, pin-pointing the mixing or synthesizer settings that didn't resonate, blossom fully, or highlight those that put the art on the path to becoming a finished product.
The creative process, rather than culminating in this point, can in fact have a life beyond it.
III. From Tributaries to Deltas: Internal Concepts & Constructs.
The ArtRiver: Every creative project is an ArtRiver, which will exist locally, and is live, in that it is open to edits and alterations.
The TimeShore: For each ArtRiver (read: project) there will be an associated TimeShore, a metadata focused data structure that will chronicle major and minor changes, and save points, throughout the lifetime of an ArtRiver.
The Glacier: Once a change to an ArtRiver project is finalized, it will enter into the Glacier state, wherein desired changes will be pulled from the TimeShore associated with the underlying ArtRiver. It is analogous to a remote, and allows for collaboration and synchronization/distribution of changes to an ArtRiver.
The Iceberg: Once a change has been preserved in a Glacier, said change will be written to the Iceberg, an encrypted, compressed replica of the project and its history, to be stored in a highly secure and resilient location. It is a last resort redundancy solution, for extreme situations where all Glaciers or ArtRivers become corrupted or destroyed, or otherwise inaccessible.
IV. Onward Lies The Estuary: Riparian Prospects
Visual Engine: Waveform and spectrogram visualizations provide a different perspective from which to analyze and refine creative works.
Access Control Engine: Fine grained control over what parties are authorized to access and make or write edits to projects.
Automation Engine: Define rules for applying effects when conditions are met, save sets of effects for application to later components if desired.
Plugin Engine: Develop personal tooling for ArtRiver that can be shared with other creatives.
V. Addenda
There are a couple of reasons why I think this should exist, as a bespoke solution, as opposed to just using Git to achieve the same result:
Git is deeply coupled to text, and programs: text is incredibly different from audio, and programs are incredibly different from projects, and DAWs are incredibly different from IDEs/text editors.
Git has a file size limitation that can easily be blown past by meaningful audio projects, and while there is GitLFS, it is limited to 2GB, and if you want to remove LFS objects, you have to delete and recreate the entire repository, as opposed
Git can track project files, but getting it to track various pieces of an audio project, such as synthesizer and mixing board settings, could be incredibly messy, and difficult, as opposed to a DVCS designed to be aware of such things.
Git is not designed for interfacing with audio hardware: if I'm using a DAW, but have physical synthesizers, such as a Minimoog, that adds an additional layer of messiness, as mentioned above.
In the event that I use git to track a project done in Audacity, I have an .aup3 file, which is recognizable by Audacity, but I cannot then reopen this project and access it's history in Ableton: This would require an abstraction layer that would have to be bolted onto Git. A bespoke solution would allow for the abstraction layer to handle conversions between DAWs, and their (~proprietary) project file encodings.
Convincing musicians to learn Git seems an order of magnitude more difficult than convincing them to learn a DVCS that is crafted specifically for their tools as they already exist. Plenty of musicians are technical, but that doesn't dissolve the friction of using a familiar tool in a new context.
Git primarily, or most heavily uses snapshot storage, and I suspect (though possibly incorrectly), delta is better for my purposes.
Using Git naturally requires musicians to use Github, to update versions of collaborative projects, and, while it is amazing for code, it simply does not appeal to the musician in me, and it doesn't do much in the way of allowing for visualization: I can view the diff between two versions of the same text file, but there's no facility for "diffing" audio tracks and seeing that the dB level, EQ settings, etc, were changed.
Git syntax. I know, I know, skill issue, but if a solution that provides a simpler set of commands (for those inclined to use a CLI version of ArtRiver) could be created, why not? (See Pijul and Jujutsu). Many musicians are technical, and yes, some are audio programmers, but many are not. Should I release an ArtRiver plugin, it makes more sense to wrap commands built into it, than to wrap git commands and then present an in-DAW GUI that abstracts Git commands away, to create the illusion of them being made bespoke for audio project management.
Text/programs are naturally more discrete than audio projects, and audio itself, and changes in Git must be added and committed manually. I'd like a solution that tracks things in a more automated manner, so that cataloguing changes doesn't disrupt the creative process, which is continuous, and not amenable to logging discrete changes. Mixing and mastering engineers often take notes of settings but they're not the artist (which is who this is for primarily (though they are creatives, the crowd this is primarily for), and note taking is not version control, it's data collection.
There are more reasons I could list perhaps, but I think I've made my overall point: while Git certainly could be used to version audio projects, I believe a much more robust, flexible, powerful and enjoyable version control experience for audio projects requires a bespoke solution that must, from day one, be designed with audio in mind. A final tidbit is that, some DAWs, like Ableton, do provide pseudo-version control, but this is entirely within Ableton, and suffers from a vendor lock in of sorts, because I can't open that project in Logic and have access to my history. A solution that provides an abstraction/conversion layer, and exists outside of a given DAW, allows for greater freedom, and offers an artist greater control over their project.
Is this idea feasible? It is reasonable? Maybe, maybe not, and it will certainly change extensively as it becomes implemented and used, and mature: who knows what of the idea as expressed here will survive to become a part of ArtRiver, and who knows what will be added.
At the end of the day, I'm a musician and a programmer, with a wild dream, and enough ambition to try it, and if it fails, at least I will learn volumes upon volumes about digital audio and programming. That alone makes it worth it to me.