Posted 16 December 2011 - 22:42
This algorithm eliminates favoritism - everyone is editing the shared data on equal terms.
Pull up two browser windows side by side and edit the text in either window - ask a friend to pull it up and do the same. Pretty amazing. Scroll down that page for more links to far more impressive examples.
It supports text and JSON, so both one-dimensional and two-dimensional data - one dimensional operations would be required for samples, while two dimensional operations could be used for patterns.
So the hard part here would be implementing the actual operations, or more accurately, the operational transformations on those - I guess in some sense the operations are already implemented by Renoise.
I'm not going to say this would be easy, but it's feasible :-)
Posted 16 December 2011 - 23:24
For that matter, if an OT approach was used, undo/redo would be considered operations in their own right - that is, you would have to implement operational transformations for the undo and redo operations. I could be wrong, but I'm not sure the scripting API is up to the job - this may require tighter, more low-level integration with the Renoise editor than is possible with the scripting API. Or not - I don't know it that well, and definitely have not been keeping up with new developments in the past 6 months ;-)
If anybody has the time (and gusto!) to attempt something like this, here's a very good explanation of OT:
Posted 04 April 2014 - 02:51
1. If we're talking real-time collaboration, Operational Transformation, in it's simplest form, would only work if every possible operation in Renoise can be expressed as a "flat" operation - which may be possible, because almost every collection (instruments, samples, patterns, tracks) in Renoise (as far as I understand) is "addressable" using a flat index. Operational Transformation on anything with structure (such as nodes in an HTML, XML or JSON document) are not simple - they are extremely complicated, and most open source OT libraries do not support it.
2. If we're talking on-demand synchronization/merge, a straight diff (such as provided by common diff tools and version control systems) will not work, again, because an XML file, while stored as a flat text-file, does contain structured data, which is much (MUCH) harder to synchronize - which is why you will often experience merge failures in e.g. HTML, XML or JSON files with version control tools. There are specialized diff/merge tools out there designed specifically for XML (such as this one for PHP) but even these can't always successfully/correctly merge changes to structured data.
To give an example of the "unsolvable" problem, consider an operation where an item is renamed or changes position, versus an operation where an item is deleted and another item is added - without knowledge of the operation that happened, with the end result of both operations looking the same, one can only guess at which operation occurred. Operational Transformation addresses this by working with operations rather than the result of those operations - an XML file is only going to reflect the result, not the actual operation, so an approach using the XML file is always going to be brittle or limited in some way.
The possible exception in the case of Renoise, is a custom XML diff/merge tool specifically designed for Renoise XML files - since all collections (AFAIK) in Renoise are "addressable" (as discussed above) it should be possible to treat the data in the XML structures as flat data rather than as structures, and thereby implement working diff/merge operations, though still with the limitations covered above, as far as being unable to know which operations occurred, and having to make assumptions or guesses, which could be difficult.
In my opinion, real-time synchronization may actually be more feasible to implement than on-demand diff/merge.
But as I see, the Renoise scripting API, as it is, is currently not suitable for implementing this... in order to implement real-time synchronization, the command pattern (which Renoise uses internally to implement e.g. undo/redo) needs to be fully exposed via the scripting API. You need to be able to construct, serialize/unserialize, and execute commands - and command events need to be cancelable. Until the scripting API exposes these features, you can't implement real-time synchronization.
Posted 04 April 2014 - 16:04
but on the real to reals, some kind of collaboration option would be nice, take turns on creating a beat without having to be in the same room.
Posted 05 April 2014 - 22:00
WoW ,,, I didn't have time to read through all the topic, but does this mean that then you could have collaboration-gig with your fellow Renoisers (almost)realtime in different countries?
That's the dream - and with modern internet connections, it would be very nearly real-time.
Posted 28 December 2016 - 19:18
Reading through this post a couple years later - it popped into my head again after tinkering with deepstream a couple of weeks ago.
This thing is basically the back-end we need for real-time collaboration - no need to develop a custom Renoise server or anything like that.
It uses a "last in wins" strategy, which should be fine with today's internet speeds and the likelihood of actually making conflicting changes.
It's open-source so anyone could host their own.
Under Lua, hmm, not so much? Lue is a pretty exotic language - it's not likely we'll have a client for that anytime soon. It's too bad they selected Lua as the scripting back-end. JS would have been much more accessible to a larger audience, and would have made something like this readily available to implement.
Well, either way, I poked through the API reference, and it looks like there would still be some work to do before a script could provide this integration.
On the other hand, maybe with this as a back-end, the Renoise team itself might be interested in making this happen? Not that there's a client-library for C yet either, so I guess, either way, even though the back-end is there and ready to use, implementing a client-library might be a pretty substantial first hurdle...
Posted 28 December 2016 - 21:09
Well, the file-format is documented, sure - for a diff/patch-facility and git-support, that's nice, but doesn't really help with real-time collaboration. For that, we need the ability to basically subscribe and block all events, then apply them in the order the server echoes them back.
Depending on how central the event-bus in the Renoise architecture is, internally, that could be either really easy, or really difficult - if basically every command/change goes through a unified event-bus, it should actually be quite easy.