Composition Security

Hello and thanks for reading my post. I’m new here and am “charged” by this software and it’s development.
Although I cannot talk too much about this, I will be uploading a new musically oriented business by year’s end which will implement Ardour and consequently bring much attention to it and it’s capabilities both technically, and as a collective source of it’s true potential. Okay, 'nuff said, here’s my issue and idea:

For the application that I intend to use Adour, I really need it to have a security lock. In other words, if a song file was uploaded into it by a second, third, or fourth party writer, producer, or programmer, I need Ardour be able to differentiate between ALL users, perhaps by locking the previous input and rendering it as “uneditable” as well as doing the same for any new input, or recordings. It’d be essential that each composer working on any given song had their IP “stamped” on their actual input. At least that’s my idea, perhaps there’s a better way of defining a composer and a composers input into any given track, but I just don’t know how to do that. That’s why you guys are the bomb!

Please consider the options and I thank you all in advance for considering them and for reading this post.

Peter

Well, some of what you appear to want to do is easy, some is hard.

Uploading ardour projects is a very high bandwidth activity. Recording at 96khz, for me, means my smallest projects seem to run at well over a gigabyte in size. It’s nice that I can download files at 2MByte/sec, but I can only upload them at 200k/sec on my cable service. Other countries than the US do have faster uploads.

Managing concurrent edits to ardour (or almost any digital system, be it audio or word processing or whatever) is hard. Serial edits, which is what you describe above, is much easier. One way to do it would be to use a version control system like svn, and try to encourage “passing the baton” in your community (many readers, only one writer). There used to be vcs’s that explicitly locked, but locking is a pain. It is nice in that “updating the project from svn” - only the xml describing the project and any new wave files would have to come down, all else could be cached by the collaborators in the project.

Tracking individual composer’s IP - which I take to be something of a pun - tcpIP and “Intellectual Property” - would need to take place on several levels. One - in the XML itself containing the project - and Two - in the wave files themselves - and Three - in the finished output.

I see the complications now and thank you for your detailed explanation. I’m not a developer or even a programmer of software so please excuse my “you’re dreaming if you want to try and do that” type of questions.

Might there be a way to isolate any new data that transpires once the program is initiated or edited by another user? Similar to the way in which a PC remembers recent items/applications etc. used, and then locked with in a log file that is uneditable?

Just some thoughts.

Peter

Hi Peter,

There is already a pretty good application for network collaboration of Ardour sessions. It’s called Session Exchange. It’s a python script in the Ardour SVN repository.

It would be fairly easy to modify Session Exchange to take on the features you need. It could “stamp” the wave files with the user’s name, and interact with an online web server in some way.

Generally speaking there is no way to change a wave file from within Ardour once it is recorded (destructive mode is the only exception). So that won’t be a problem.

Locking the wave files so that they can be read by the collaborator but disallowing all other uses is a bigger project involving encryption which I will leave as an exercise for the reader.

I’ve seen several online musician collaboration sites come and go. I’ve always felt Ardour would provide a method for this to finally work. Good luck with your project!

-Ben

Thanks for your comments Ben. Although much of it is Greek to me, I do think I get the overall idea of what you’re suggesting.

As I said, I am new to this site, but certainly not new to the software recording world. Open Source is a new ballgame for me though. Based on the levels of support I see here at this site, combined with what I think is a great product, I’m totally pumped about the possiblities which lay ahead.

What bandwidth transfer rate might one expect to use if relaying a large number of Ardour files around the planet?

Also, the site’s you have seen come and go; what were they exactly and do any still exist?

Thanks so much for your input. Greatly appreciated!

Here are some starting points:

esession.com - still a demo after 2 years

http://www.masternewmedia.org/music_collaboration/music_jamming/online_music_collaboration_software_20050715.htm

http://www.musicbizacademy.com/internet/tonos_exit.htm

There was another startup which had their own proprietary DAW which allowed you to collaborate with others, non-realtime, by trading tracks. But I can’t find them now.

Thanks Ben for your reply. I have checked out esession and although it does have real time DAW software it seems to me to be a glorified online management company. I watched a video created by one of the esession partners and she said that their members have to have a minimum of 15 released products under their belt in order to qualify. Also, if someone were in need of a musician/producers services there is a $25.00 charge just for esession to forward the request. I could on with foreseeable problems but that’s not what we’re here for, right?

With regard to Ardour: I’d asked what bandwidth rate a web hosting company would expect to see being chewed up each month. I’ve heard that an Ardour file can be a gig or more and consequently a very slow upload. If a site were to have heavy traffic and many members transferring these files back and forth, how much (estimation) dedicated bandwidth traffic do you think I’d be looking at on a monthly basis?

As well, is there, might there, be a way to reduce these file sizes until a final product (song file) is finished and then expand, decompress or restore it to it’s expected size? Sorry if that’s a stupid question. I’m really not familiar with these things.

Again, thanks for reading my post and thanks in advance for your time and consideration.
Peter.

BTW: gearslutz is a great site! Extremely entertaining and knowledgable resources. I see very clearly as to how gearslutz will become aan invaluable part of my business. Thanks!