The Project :
To help working pieces of music with others musicians, each of them may record a track within a shared audacity project.
The project is shared between computers by synchronisation with , for exemple the software Syncthing. So each musician can work with the tracks of his fellows in standalone.
The problem to solve :
It may happen that the shared project is opened by several computers at the same time. Writing to it at the same time will damaged the project.
So, Audacity may detect this state , preventing musicians to save their work at the same time.
Proposal :
When a project is going to be opened, Audacity looks for an existing lock file for this project. If this file exists and contains an identificator different of the user one, some action may be done , such as prompting unlocking request to the user.
The same test can be done when saving the project.
If there is no lock file for the project to be opened, Audacity create one with the user identificator.
This lock file will be synchronized to the other linked active computers and so seen by the distant Audacity instances.
Hello Steve,
Thanks for your response.
I am used with Version Control. It needs some commands to manage the process. Here, the users are musicians and the process of synchronization must be completly automatic. It is not possible to ask them to manage the versions.
It is the advantage of machine synchronisation. The users have always the same objects without doing anything. Syncthing is responsible for the job.
But in fact, a local versioning is managed by Syncthing. But it is very basic; it doesn’t create version for local modifications.
Due to the pandemic, there has been a much more interest in on-line collaborations (which I think is a good thing in itself). For reasons that you have already described, there are difficult technical challenges when collaborating on Audacity projects - mostly around how to avoid one person’s changes colliding with another person’s changes. I’m thinking that this could be a very interesting area of development in the near future.
I don’t have “the answer” for how it would work, but making changes to a project is much like checking in / checking out changes to a database. Currently a project is like a single user database. Perhaps one approach could be to develop a fully automatic multi-user project database. All transactions would need to be “atomic”, but not necessarily synchronous. I think this could be a very exciting area for future development.
Steve,
I will try to make a first sketch of what I think about the functionality with a Nyquist script, I start to write a few lines of specs and get started with Nyquist. Regarding this last point, you will certainly have some advice for me.
Thank you in advance for your help.
Xaintrailles
Just a thought…
Maybe each contributor could have one or more dedicated tracks. When a contributor creates a track it gets something like a locking password (which could, at the contributor’s discretion, be shared with other contributors). This would, at least, keep one contributor from accidentally destroying the data of another contributor. At a bare minimum, this could be done with the current Audacity, an agreement of who “owned” any given track and good communication between contributors.
Sadly this is how a lot of tutorials teach Git. By installing a GUI like TortoiseGit/TortoiseSVN most or even all console magic incantations are replaced by simple Explorer commands that streamline the collaboration process. For a less-technical user using the console to do stuff like Git checkout/commit is complete overkill.
I would therefore also advise to use a versison control software for this sort of thing, but alongside a GUI that is usable for non-programmers too. In your case Subversion is probably the best choice, since you don’t want the possibilities (and pitfalls) of Git and want to ensure that everyone must always work with the most current version. This can of course still cause problems if 2 people edit files at the same time and want to commit (it won’t let you just overwrite, but one of them will have to re-do their work), but at least the project itself should no longer just become corrupted, and if it does you can just revert.