I’m not sure if you could do it ‘live’ with SOAP. But I do have an idea to create a usable ‘collaboration environment’. Which is technically quite acheivable.
This is the workflow I have in mind: (forgive me if I refer to myself in the 2nd person, I’m not going crazy, I swear twitch twitch )
Via a web interface, MickRip initiates a “collaboration tune”. It’s stored remotely as a clean slate - the only significant data (thus far) is the “Song Name”, “ID”, and certain security parameters. MickRip is now the primary author, and he can now assign a collaboration team. He selects Conner_Bw. For now, it’s just a 2 person co-op.
MickRip makes a start on his tune. Just like normal. He tracks the first 5 patterns. He saves as “backspace.xrns”. It’s 8mb in size.
I’ve been figuring out how to get 8mb+ of data from my machine to a web server. Obviously the xrns file needs to be stored in a remote location. That in itself is easy, but looking ahead, we have syncronisation issues to consider.
[indent] .oO( … Thinking about how XRNS will be stored on a DB …)
- All Flac files are stored separately in binary, on the database.
- All Patterns are stored seperately. (DSP/Automation same umbrella?)
- Instrument data (looping, envelopes)
- Global data
- VST info and parameters
- What else? [/indent]
Sending 8mb over HTTP is a pain in the arse. Using FTP, although a bit better, but presents security issues. The best option I see, is create a local (client-side) peice of software which has the ability to …
[indent] - Break apart your tune into its significant/tangable components (flacs, patterns, instruments, dsp info, etc)
- Probe the server, looking for differences between the server copy, and the local copy.
- Upload only what is needed. Extra patterns, modifications, etc.
- Become available for other authorisised participants to Sync with their local copies.[/indent]
The same peice of software should be able to work in reverse, and modify your local copy with any changes that are made on the server. Local software can be written and compiled in PHP. (Not sure about a mac)…
It seems to me, the most difficult aspect of this is turning the whole XRNS file into data, and then building an XRNS file from whatever it finds from the database. It’s not rocket science, but to me to represents the most time.
(Back to reality) Once MickRip has uploaded his tune using the client side software, the tune should be on the server in a format which can be rebuilt into an XRNS file again. Conner_Bw’s client side software will make SOAP requests, first requesting the flac data, the patterns, the instruments and so on. The software will then build an XRNS file, ready for him to edit.
Conner_Bw adds another 6 patterns. He’s also changed a snare sample, more suited to his tastes. He’s also lengthened my intro by a pattern, and changed some notes here and there. He’s also added a vocal sample. He then saves his work, (the tune is now 11mb) … he goes to our client side interface and presses the upload button.
Now, this is where it gets tricky and my brain hurts a bit. Obviously there’s not 11mb to upload, as most of the flac files are intact. So the sync software looks at the instrument data, compares local and remote “Horn Sample”, and will only upload if it there has been a modification. What if you swap instrument 1 and 2? Should I identify the instrument by name rather than the slot? What if I change the name? These issues need to be delt with.
It seems to me, the only solution is to append a change rather than overwrite. Conner_Bw’s drum sample that he replaced, should be simply appended, and the old drum sample should remain on the remote server. We should ID everything by checksum, and not by the internal ID inside the XML. This means that the syncronisation process SHOULD cope with people swapping things around, without the syncronisation engine deciding things are different. If you upload a completely different tune, technically it should append the tune to the end of the existing remote copy. If a pattern has been changed by ONE note, then a new copy of that pattern will be created.
This method facilitates an ultimated amount of authors. It’s a bit “messy” though, but I can’t see any other solution to cope with drastic changes.
These are only initial thoughts. I haven’t worked out if DSP info should be ammeded, or replaced.
Some thoughts would be helpful.