Jump to content
IGNORED

watmm idea thing


Recommended Posts

As I'm actively trying to cut down my hands-on collaborations, which have been my previous dumping ground of stuff I never managed to finish myself, this could be very useful for me as I hate having unfinished stuff.

Link to comment
Share on other sites

 

another option would be to use some kind of sync software, this for example: https://www.resilio.com/individuals/

Interesting! Although that appears to be from device-to-device, not from a website...

 

 

exactly, that's the point, don't need to worry about hosting large amounts of data. the one issue with that is permissions, I think you need to get the pro version for things fine grained control over who can delete stuff etc.

Link to comment
Share on other sites

I like this idea as well, but here are my concerns:

 

Storage - without increasing server/hosting costs, our storage for something like this may get out of hand, and unlike the downloads, this could grow much faster as people would be adding any bits and bobs they thought useful.

 

Control - I would like to keep it on or connected to WATMM, so we can provide it as a resource and not have folks from the outside raiding our bandwidth/resources.

 

We could create a section in the Downloads module for this - let me see if I can set it up so it only shows for the EKT forums or as a sub-forum of some sort...

Not to be contrarian but the OAuth freesound solution could take care of both issues. But I acknowledge that's going to involve some development effort. 

Link to comment
Share on other sites

The repository would probably be huge though. And I doubt anyone wants to download the whole thing anyway.

 

could do individual repos for songs. post a link to a repo in the thread. hosting is done on bitbucket/github.

 

would be a cool way to collaborate, so there are branches and there's no need to agree on one direction.

 

the size of a single song repo would be negligible. pushes/pulls would just be the diff. if one starts getting large, making the initial clone large, could fork some branches off into their own repos.

 

plus a lot of projects could be kept as mostly project data rather than audio

Link to comment
Share on other sites

https://help.github.com/articles/working-with-large-files/

GitHub will warn you when pushing files larger than 50 MB. You will not be allowed to push files larger than 100 MB.

100MB is like, what, 13 minutes of 44.1/16 stereo audio? So that might be an option too.

 

Integrating with any of these APIs would involve token management but would address both the storage and control/user-verification issues.

Link to comment
Share on other sites

https://help.github.com/articles/working-with-large-files/

GitHub will warn you when pushing files larger than 50 MB. You will not be allowed to push files larger than 100 MB.

100MB is like, what, 13 minutes of 44.1/16 stereo audio? So that might be an option too.

 

Integrating with any of these APIs would involve token management but would address both the storage and control/user-verification issues.

 

 

git doesn't work very well with lots of binary data out of the box, subversion is better, but still not ideal. you can configure git to handle it better though: https://help.github.com/articles/versioning-large-files/

Link to comment
Share on other sites

 

https://help.github.com/articles/working-with-large-files/

GitHub will warn you when pushing files larger than 50 MB. You will not be allowed to push files larger than 100 MB.

100MB is like, what, 13 minutes of 44.1/16 stereo audio? So that might be an option too.

 

Integrating with any of these APIs would involve token management but would address both the storage and control/user-verification issues.

 

 

git doesn't work very well with lots of binary data out of the box, subversion is better, but still not ideal. you can configure git to handle it better though: https://help.github.com/articles/versioning-large-files/

 

Is there an equivalent to github for subversion?

 

I always thought SVN was kind of icky but I think you're right that it handles binary data better.

Link to comment
Share on other sites

one way to set it up actually would for one person to maintain the VCS locally, they'd be in charge of all the submissions and so on, then you could setup a read-only view on the repo via that bittorrent sync thing I linked earlier. on the other hand using a VCS at all might be overkill, there's not much point if you don't need to keep a record of changes to individual files, and mostly this would be a single set of stems added to the repo and not touched again. a versioning scheme might come in handy if you used the library for other purposes, remixing the stems say, but even then you could just add them back in as a new set of files.

Link to comment
Share on other sites

on the other hand using a VCS at all might be overkill, there's not much point if you don't need to keep a record of changes to individual files, and mostly this would be a single set of stems added to the repo and not touched again. a versioning scheme might come in handy if you used the library for other purposes, remixing the stems say, but even then you could just add them back in as a new set of files.

That was kinda my thought... I can't think of a great use case for having that historical data; it'll probably just sit there taking up more space and slowing things down.

 

As far as I can tell, all we really need is some way to manage (upload/download) WAV/AIFF files using WATMM credentials, preferably with the ability to search, categorize, and preview them. Freesound API is still looking like the most turnkey way to do that to me.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.