Still no built-in way to collaborate with other musicians, it seems. While I understand the technical difficulties, it's also very frustrating to work remotely with other musicians on an Ableton project. I don't need real-time Google Docs like editing, but it would be nice to have something better than "freeze the project, dump it in Dropbox, and don't touch anything until they've made their edits".

Any Ableton Live users here that can chime in on how they solve that?

▲

crucialfelix an hour ago | parent | next [-]

There is a this live collaboration project: https://api-production-006c.up.railway.app/

https://www.reddit.com/r/ableton/comments/1xrbj82/been_an_ab...

> mainly it uses the underlying control surface layer to receive events with a python bridge then communicates those out to a central server, from there there's a websocket room you have to be invited to and you get all the updates.

> For changes or additions of samples/tracks it sends it to an incoming temp directory and edit's the ALS to read from it instantly

> The git portion is heavily inspired by git lfs, and stores your data in r2's but only diff's between the last version and current version.

It's a hosted product, but self hosting is possible even now. I think the code is up on github.

▲

coldtea an hour ago | parent | prev | next [-]

>Still no built-in way to collaborate with other musicians, it seems..

Asynchronous collaboration, there are a few non-native solutions.

Or you can always exchange files via Dropbox or something as you said. Or share screen.

Live playing over the public internet, there's no good way to do it , and can't really be due to latency. Many projects tried, all suck.

Live playing locally, there's Ableton Link.

This is a huge update (ARA alone, the step sequencer, etc) anyway, and many long awaited and several non expected items.

▲

vectordust 3 hours ago | parent | prev | next [-]

This is a pain point for me as well, but I'm not sure what solving this would truly look like. At the moment whenever I'm collaborating with anyone else, one of us will have the "primary" project file containing the entire mix/session, and the collaborator will be sent all stems individually, and they'll send their stems back for ingest in to the main project. It's pretty clunky, but it prevents the awkward "I don't have that plugin/VST/etc" issues that passing project files has.

I dream of a git-like workflow for Ableton, ideally with some sort of clever solve for the inevitable missing device issue (maybe freezing could solve this with some tweaks?).

I'm also curious to hear from others on how they solve this, especially when collaborating remotely.

▲

PhunkyPhil 2 hours ago | parent [-]

This is very solvable in theory, we've been doing package management and version control in software for decades. I'm not familiar with the plugin/VST ecosystem enough but I'm assuming there's no real central registry ala pypi/maven/npm?

	▲	vectordust 2 hours ago \| parent \| next [-]
		> I'm assuming there's no real central registry ala pypi/maven/npm? that's exactly right, unfortunately. it's a bit of the wild-west the it comes to plugins/VSTs in terms of distribution. and I agree, this feels like the sort of thing that should be pretty solvable, but I think there's a lot of hidden complexity in this problem space. Solving the "version control" aspect of this feels like it should be rather straightforward for a single user, involving multiple users with different Ableton Live versions, different plugins/VSTs (and different versions within those) is where things would undoubtedly get messy. I do think there is a niche market for this sort of thing, however.
	▲	diskzero an hour ago \| parent \| prev [-]
		Many of the producers of the plugins are against a central repository for reasons you can guess; licensing and revenue generation. One annoying part of working with various plugins is the companies tend to have gatekeeper applications the user needs to interact with to get plugins authorized and installed on their system. You will find applications like this one, https://www.pluginhubapp.com, show up frequently to try and manage this complexity. I am in no way at all recommending this application, but it is an example. This application does ship with all of its python code in the app under (possibly a mistake) so you can see the hoops they have to jump through to try and make their system work.

▲

dleeftink 2 hours ago | parent | prev | next [-]

I rememeber trying blend.io and Splice studio back in the day, but they weren't too ergonomic due to lack of a 'project package' convention. There also was an inkling of native sharing for a while [0]:

> Officially, it was known as "Ableton Link Share" during early development and then launched as “Ableton Live’s ‘Share’ feature” — introduced around Live 9.1 (2013–2015 era).

> It allowed users to upload their Live Sets directly from Ableton Live to a personal web page (via ableton.com) to share projects with others — including audio previews and downloadable Live Sets.

> Ableton eventually discontinued the Share feature in 2017, citing limited use and the shift in focus toward Ableton Cloud / Splice / Link integration as alternative collaboration tools.

[0]: https://forum.ableton.com/viewtopic.php?t=252909

▲

steveBK123 2 hours ago | parent | prev | next [-]

It seems to me that the super customizable, plug-in heavy architecture of modern DAWs.. especially Ableton makes collaboration almost impossible, at least without a change in IP/licensing model.

▲

devin an hour ago | parent [-]

Right. How often are you collaborating with users who agree to only use vanilla Ableton plugins? Every time I've collaborated we have to start the conversation with what plugins we share, which ones are freely available, which ones would are not cost prohibitive for the other side to acquire, and so on.

That said, I think that vanilla Ableton provides a whole lot to collaborate with. Maybe there are a lot of people for whom the base set works, but "do you have Apollo UAD + the Neve preamp plugin?" or something like it is not a rare occurrence.

▲

butlike an hour ago | parent [-]

Why aren't you bouncing stems? You bounce the stems, they load them into their DAW, make edits with whatever tools they want, then bounce them out again. There's no need to transfer around whole projects...

▲

diskzero an hour ago | parent | next [-]

True, but this is how we used to do it in the old days, when track limitations forced us to bounce with all the outboard effects baked into the track. Producers might not physically ride the faders anymore, but a lot of them are very reluctant to even track vocals through compression onto disk. They want to keep everything available for processing later on.

Now, is this a good idea? There is a lot to be said about having an upfront plan about the usage of effects and placement of parts on the soundstage and committing. This might be a lost art, as I keep seeing Pro Tools files with hundreds of tracks, with stacks and stacks of effects.

	▲	butlike 44 minutes ago \| parent [-]
		I mean, as an older fart, I do think there's value in committing to an idea. Though, I could also see benefit in having the processing be malleable until the last possible second. I mean, imagine if you're working with an egomaniac artist who keeps being wishy-washy on which sound they like best. If the effects are being printed and they want to go back, it could become a huge pain in the ass. AT THE SAME TIME, I think there's merit in telling someone 'no' so the project can move forward. I dunno, I guess it depends. I can see it both ways.

▲

vectordust an hour ago | parent | prev [-]

yep this is what I do, though I haven't collaborated in a bit. it really is the best workflow at this point and it can be as granular as you need/want it to be.

▲

EastLondonCoder 2 hours ago | parent | prev | next [-]

I meant to reply to you here but managed to post a comment of my own

https://news.ycombinator.com/item?id=50441616

▲

cromka an hour ago | parent | prev | next [-]

I always thought they'd eventually implement some sort of version control, ideally git based, or a timeline similar to Fusion360.

▲

dango369 3 hours ago | parent | prev | next [-]

version control for it hmmmmmmmm

▲

Juliate 2 hours ago | parent | prev | next [-]

This is the recurrent pain point I have and see my friends have with Live. An exported project always has something missing/blocking.

The procedure to ensure your project is properly fully exported should be one button in a single place, not a 4 steps checklist in different configuration views.

▲

nonethewiser 3 hours ago | parent | prev | next [-]

What would you envision?

▲

diskzero 2 hours ago | parent | next [-]

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.

▲

hn_throw2025 an hour ago | parent [-]

Wow, SAW… there’s a name from the past.

Wasn’t that the one written in assembler? Kudos!

	▲	diskzero an hour ago \| parent [-]
		Yes. It helped to basically write your own operating system to work around kernel issues. Not really recommended though... Amazingly, the website is still alive: https://www.sawstudio.com/products_sawstudio.htm I am not brave enough to download and try it out. (I want to point out that I was not the author of SAW, Bob Lentini was. I worked on integrating SAW with MasterTracks Pro from Passport Designs.)

▲

marceldegraaf 2 hours ago | parent | prev [-]

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.

	▲	butlike an hour ago \| parent [-]
		Question: what happens when you share a project made on a Mac version of Ableton with a windows user? All of the internal pathing in Project.xls will be macOS paths. It's not as simple as sharing a bare-bones project. Bounce stems.

▲

reminitone 2 hours ago | parent | prev [-]

[dead]