watmm idea thing

here is thing i don't need

http://picosong.com/UuWV

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.

  On 12/6/2016 at 9:15 PM, Joyrex said:

 

  On 12/6/2016 at 8:44 PM, caze said:

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.

  On 12/6/2016 at 6:27 PM, Joyrex said:

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. 

  On 12/6/2016 at 2:59 PM, sweepstakes said:

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

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

  Quote

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

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

@very honest: Storing in project data rather than audio data is a bad idea I think as not everybody uses the same DAW

Gesendet von meinem SM-G900F mit Tapatalk

  On 12/7/2016 at 6:06 AM, sweepstakes said:

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

  Quote

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/

  On 12/7/2016 at 7:24 PM, caze said:

 

  On 12/7/2016 at 6:06 AM, sweepstakes said:

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

  Quote

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.

  On 12/9/2016 at 2:58 AM, sweepstakes said:

Is there an equivalent to github for subversion?

Not that I know of, I know there's a bunch of paid services, but I've never used them.

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.

  On 12/9/2016 at 4:29 AM, caze said:

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.