Andy, I just learned about your Genesis project, and it's great to see people pushing towards collaborative DAWs. I've been doing detailed planning for my own vision for a collaborative DAW for years now, though various other projects have kept distracting me from giving it enough coding time to get it off the ground!
I'm curious how you're thinking of solving latency & disconnection issues between participants. It looks like you're representing things as a sequential list of transactions, and immutable transactions are definitely the starting point for everything I've considered! The question is: what happens if multiple people send each other conflicting transactions at the same time? Google Wave solved this by enforcing a single server-side ordering of all events, and making sure that all transactions would be accepted using Operational Transformation even if they occurred out of order. Without OT, you may have cases where Alice makes a change, only to have it invalidated and essentially erased by Bob's change that may have "won" on the server side. And while OT may be largely "solved" for text content, it doesn't seem well-studied for music or other timeline-based content.
As an alternative, source control manages to get along fine without automated conflict resolution/OT, since we're willing to dive into merge conflicts and resolve things ourselves. So theoretically, you could create "Git for Music" and drive that from your app. But what's the UI equivalent of version control in a DAW? What, exactly, does a "diff" look like in musical notation? And how do you make it unobtrusive to non-coder musicians?
All very interesting problems, and it's always great to have multiple innovators in this space! Would be happy to connect offline if you'd like.
> The question is: what happens if multiple people send each other conflicting transactions at the same time? Google Wave solved this by enforcing a single server-side ordering of all events, and making sure that all transactions would be accepted using Operational Transformation even if they occurred out of order. Without OT, you may have cases where Alice makes a change, only to have it invalidated and essentially erased by Bob's change that may have "won" on the server side. And while OT may be largely "solved" for text content, it doesn't seem well-studied for music or other timeline-based content.
I've planned this out on paper. It's going to be solved in a peer to peer manner, no central server. It will work the same way that git rebasing works. When conflicting transactions occur simultaneously, there is a deterministic way to determine the order, then each peer rebases the transaction and resolves conflicts automatically in a deterministic way.
Undo/redo is really complicated, but I believe I have a pragmatic approach that will work. I don't expect users to resolve conflicts; instead I will make the effort of editing small and leave it to users to manually correct automatic conflict resolution if there is a problem. No "diff"s, no coding knowledge necessary.
Do feel free to email me if you want to chat about this problem :)
I'm curious how you're thinking of solving latency & disconnection issues between participants. It looks like you're representing things as a sequential list of transactions, and immutable transactions are definitely the starting point for everything I've considered! The question is: what happens if multiple people send each other conflicting transactions at the same time? Google Wave solved this by enforcing a single server-side ordering of all events, and making sure that all transactions would be accepted using Operational Transformation even if they occurred out of order. Without OT, you may have cases where Alice makes a change, only to have it invalidated and essentially erased by Bob's change that may have "won" on the server side. And while OT may be largely "solved" for text content, it doesn't seem well-studied for music or other timeline-based content.
As an alternative, source control manages to get along fine without automated conflict resolution/OT, since we're willing to dive into merge conflicts and resolve things ourselves. So theoretically, you could create "Git for Music" and drive that from your app. But what's the UI equivalent of version control in a DAW? What, exactly, does a "diff" look like in musical notation? And how do you make it unobtrusive to non-coder musicians?
All very interesting problems, and it's always great to have multiple innovators in this space! Would be happy to connect offline if you'd like.