Jump to content


Photo

Collaboration/syncronisation


  • Please log in to reply
33 replies to this topic

#26 mindplay

mindplay

    Advanced Member

  • Normal Members
  • PipPipPip
  • 85 posts

Posted 16 December 2011 - 22:42

It looks like the best algorithm around for doing this kind of thing, is Operational Transformation:

http://en.wikipedia...._transformation

This algorithm eliminates favoritism - everyone is editing the shared data on equal terms.

Here's an implementation with a server written in CoffeeScript and running under Node on a webserver, with a client-library (also written in CS) running under JavaScript engines in conventional web browsers:

http://sharejs.org/

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.

The JS client library is only 4KB of JavaScript, so it must be relatively simple. Or in other words, it's not unthinkable that you could write a client in Lua and actually run it against a ShareJS server. This is all open source - so you could package Node and ShareJS and create a self-contained server distribution.

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 :-)

#27 mindplay

mindplay

    Advanced Member

  • Normal Members
  • PipPipPip
  • 85 posts

Posted 16 December 2011 - 23:24

By the way, I still think my original idea would work, and probably much simpler to implement - but I should highlight one weakness of that approach: it interferes with undo/redo. That is, if you undo an operation, you're not undoing an operation done by you, necessarily, just the last operation performed by any of the participants, which is probably not the desired effect.

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:

http://opencoweb.org...ntro/openg.html

#28 mindplay

mindplay

    Advanced Member

  • Normal Members
  • PipPipPip
  • 85 posts

Posted 04 April 2014 - 02:51

Just a quick follow-up with a couple of observations I've gathered from learning some new things since posting in this thread.

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.

#29 Raegae

Raegae

    Super Advanced Member

  • Normal Members
  • PipPipPipPip
  • 164 posts
  • Gender:Male
  • Location:Turku Finland

Posted 04 April 2014 - 07:55

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?

#30 Djeroek

Djeroek

    Probably More God or Borg Than Human Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 6605 posts
  • Gender:Male
  • Location:Borneo

Posted 04 April 2014 - 16:04

Maybe out of the box thinking is needed, have a camera pointed at the screen or some kind of screen capturing going on and have optical recognition algorithms translate what's happening realtime, send converted OSC instructions to a arduino controlled robot on the other side, auto-mirroring, tracking the results.

Posted Image


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.

#31 mindplay

mindplay

    Advanced Member

  • Normal Members
  • PipPipPip
  • 85 posts

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.

#32 mindplay

mindplay

    Advanced Member

  • Normal Members
  • PipPipPip
  • 85 posts

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.

 

It was extremely easy to implement in JavaScript, since they have a JS client library ready to use.

 

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...



#33 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 6000 posts
  • Gender:Male
  • Interests:wildlife + urban trekking

Posted 28 December 2016 - 19:48

A lot of work, but totally possible as xrns is an open format :-)

 

Also, neurogami has made a proof of concept of sorts, check out this thread: 

http://forum.renoise...songs-with-git/


Tracking with Stuff. API wishlist | Soundcloud


#34 mindplay

mindplay

    Advanced Member

  • Normal Members
  • PipPipPip
  • 85 posts

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.