| ▲ | nonethewiser 3 hours ago | ||||||||||||||||
What would you envision? | |||||||||||||||||
| ▲ | marceldegraaf 3 hours ago | parent | next [-] | ||||||||||||||||
An easy way to share a project with collaborators. This is obviously hard because of the gazillion VSTs and multiple platforms that Live supports, but if I could just share the bare bones project (channels, tempo, and all built-in plugins that all Live users have) it would already be an improvement over the current situation. In terms of workflow I can imagine a "shared project" view in Live that loads the shared bare bones project file and allows you to easily lay your own tracks on top (with whatever VSTs you have installed locally), and then allows you to freeze and share those recordings as audio in one go, in the shared project. | |||||||||||||||||
| |||||||||||||||||
| ▲ | diskzero 3 hours ago | parent | prev [-] | ||||||||||||||||
I have worked on the code of legacy applications like MasterTracks Pro, Studio Vison and SAW and my opinion would be that you need to start from the ground up with collaboration as the guiding light. The existing applications have workflows and data models that are very monolithic and tied into the concept of a single user, using a single application with application logic and workflows implemented in code. That code sometime exposes functionality through scripting dictionaries or plugin APIs, but the this is backward in my opinion. Other commenters have stated what a pain it is to just get two environments in sync. A complex production will have tons of plugins, various MIDI and audio interfaces, differing outboard gear and other variables that make life hard when sharing files. You also have asset management issues; where are the audio stems, vocal tracks, library resources, etc. stored and how are they shared. If you want to collaborate in real-time, then there is another layer of technical challenges. I have been working on a system that is influenced from my earlier experience building audio tools for earlier generations of sequencers and DAWs, rendering pipelines for Dreamworks and configuration management systems for Amazon. I feel you really need a system that uses a DSL and all operations are defined at that level. There shouldn't be anything you can do in the user interface that isn't available at the DSL level. You can then think about techniques used in Docker, k8s, etc. to define and deploy both the environment and the interpretation of the DSL in the user interface. | |||||||||||||||||
| |||||||||||||||||