Downloading tracks 2.0

responses to a few things that have been mentioned:

Bandcamp is a pretty good platform as far as platforms ever can be. It is one of the few platform services I can bring myself to use at all. The functions provided are pretty close to what i would want to see. If it were a artist/worker owned coop there would be no need for resonate IMO. So, while we shouldn’t imitate it’s features blindly - if Resonate ends up looking a lot like bandcamp in terms of function, I’ll be pretty happy.

In terms of selling - free music and price, I think a pay what you like option, with a minimum (which can be zero) solves the issue, from a technical perspective. Race to the bottom is another thing, a social problem rather than a technical one. It would also be nice to have the option to pay an artist more for a track/album after purchase. A sort of “this music has grown on me and I want to pay more now” option.

I don’t like the idea of artists opting out of downloads. At all. As a listener I couldn’t take a musician seriously who did that. However it seems to me that article 7 really dictates maximum artist choice. it points towards yes, not no.

Artists should retain all ownership and rights, be able to decide what, when and how they make their art available to the public, and the value of their art.

But if the community decides to make downloads mandatory I won’t be complaining.

I don’t actually care what format is implemented first, as long as a lossless format is available within a few weeks of downloads becoming available.

My preference for flac first is based on the following points:

  • flac can be converted to mp3, but the reverse is pointless and misleading.

  • a master definitive lossless version needs to exist as a source to create the mp3 in the first place, so exposing that should actually be less work than creating the mp3. Sure that master version might be currently archived, but we know it needs to be made available at some point so why not start at the logical beginning, with the definitive version of the track?

However that is really up to the devs how to approach the structure.

I would suggest that these just be flagged and then basically ignored in whatever way is convenient, until such time as an automated upload system for artists is in place, at which time all artists with lossy master files could be prompted to reupload. But this suggestion is predicated on the notion that only a small proportion of the current catalogue has a lossy master.

I’m also wondering, could some dev work be saved by requiring artists to upload flac files with correct tags already in place? The current manual system required me to enter all my tags into a spreadsheet - even though I’d already added them to my flac files.

My point is that requiring artists to stick to a standard format isn’t all that onerous, and artists can be helped with a how-to guide written by someone (like me) whose time is at less of a premium than the devs with detailed knowledge of the code. I can’t help the devs write code to cope with messy and incorrect uploaded files, but I can write a guide for artists to help them upload correct files that require less processing.

It also occurs to me that there might be rare special cases where no lossless master exists. Maybe odd ephemera such as field recordings made on a phone or something. Do we exclude these, or maybe allow them with a flag that basically says “lossy master”. If the slot that holds the (normally flac) master file were to be made format agnostic then it needn’t compromise the structure.


OK so this is OT, but I’ve had a look and I’m not sure if there is another discussion of these issues or even where to look for one. It is an important topic though.

At this point Resonate is primarily about software development - and those of us not equipped to do that are really spectators, hopefully helping, but likely also getting in the way or just wasting time in speculation.

It would be great if there was some sort of overview for non-devs of what resources are required to achieve any specific goal, as I feel that the rest of us can’t really help if we are speculating about the software issues.

I’d like to know, for example, things like how many person-hours per week/month are currently being spent on dev work, how many are paid and at what rate, how many hours might be expected to be needed to reach particular milestones and so on.

Also how many additional hours the current devs would be able to put in if payment were available?

If work were to be accelerated is the bottleneck primarily money or is it primarily available people with suitable expertise?

I know I personally would be prepared to donate/invest more money if I knew what it might achieve. (not that my personal financial contribution will ever amount to much)

I’ve donated to a few worthy FOSS projects that never reached version 1.0 - no doubt others have has similar experiences - so I’m looking for ways to avoid that here.


I feel we should fork this into its own topic, but I’ve had the same issue lately, where basically I largely feel more like I’m getting in the way and even to some degree, annoying the devs, rather than really participating or helping. I think in a way, despite all desires of being a coop, a democracy or whatever we aim for, Resonate is still very much done first and foremost by a little team of devs, and right now I think its mainly “their platform” rather than the platform of the community, because “the community” as a whole doesn’t have the financial bandwith to garantee fair payment of dev time, and since we don’t have that, we can not in all decency ask anything of them that they do not feel inclined to do.

I really feel like I’m stepping on people’s toes everytime I mention something to be done regarding dev at this point because I’m aware I should either have the knowledge to do it myself, or know for sure that everybody’s being paid fairly and that there’s a legitimate democratic process to make sure of what the majority of users on the platform wants so that funds are allocated according to collective decisions and so that the devs don’t feel like they’re forced into doing something they don’t want to by just a few people on the forum that they potentially disagree with.

Right now I don’t feel like we really have either. So it makes talking about anything look more like a thought exercice rather than an actual conversation.

I always post messages here with the assumption that whatever I say might be useful 6 months or 1 year or 2 year further down the line and has no real immediate purpose, but doing that feels a bit like making constant pointless criticisms since there doesn’t seem to be much we can do about it and the entire pressure to actually build things is on the shoulders of 2 or 3 people.


Insightful as always @LLK you very accurately described the raw reality we’re in.

The only bit I’d add to this is that often it’s not even about what the devs want, but rather what the code needs. With software development of this size and scope, they’re constantly running up against compatibility issues across a wide variety of codebases and technologies which have domino effects throughout the system. (And that’s a simplistic overview. Would have to write three or four more paragraphs to even begin to outline.)


Likewise, while I did a first round of testing and responding to some notes/ideas, I’m wary of putting too much onto volunteer devs; it risks getting out of control & too big to handle. IMO it’s better to have a focused set of high-priority must-haves + wishlist than everything in one bucket.

Sorry if this has already been said…

1 Like

I have very limited experience with making software - but still this is absolutely what i found when I have - at least 85% of the effort goes into understanding and connecting to the frameworks of pre-existing software that one is trying to use and build on. The more different such pre-existing modules or frameworks in use, the worse it gets.

It is easy to get trapped on local maxima where to add an unanticipated feature it would be best to entirely replace or reconfigure some piece of incorporated third-party software - but this would require major rewiring of the whole project.

Other than having a fixed feature set prescribed in advance, I’m not really sure how people avoid this.

It suggests to me that as a community we need a clear idea of what the core features should be, and we needed it from the start - but better now than later.

Resonate doesn’t have to be all things to everyone - a decision could be made, for example, not to have downloads at all. If that kept the scope of the project manageable it might even be worth it.

While I personally wouldn’t be much interested in such a platform, others obviously would be. The question is really whether the reduced complexity and reduced appeal result in a more viable ratio than making a more full featured platform.


the closest thing I have seen to a spec for what is being created is this:


FWIW my personal feeling on the download question is… that it’s not an urgent issue in the DSP development essentials. Offline listening would be great, but so long as the music you’ve paid for in full is there for you in resonate on demand, in 2022 the download/ownership question is just not that modern. Plenty of people never own or will own music, they will only ever stream it or access in the cloud.

So while I fully support Resonate having download capabilities, in the future, I think more important concerns are things like… handling metadata correctly, automating inputting of releases, automating payments and reports, giving artists control over their releases and information. All are bare minimums from an industry perspective.

A streaming platform can be just a streaming platform - a sale platform can be just a sales platform. In the future Resonate can and will be both, but from a dev/platform/catalogue perspective, downloads aren’t as essential to our future as many other things I’ve described above and in the DSP overview.


Hope it’s helpful. Happy to add in missing ideas and feed in essential thoughts and questions to that document as needed.


so, contrasting this with my attitude expressed in the first half of this post: Downloading tracks 2.0 - #19 by blackthorn

I think this is a central existential question for Resonate. (though I would regard streaming as a post-modern phenomenon, rather than a modern one)

Selfishly - I would like to know if being a download shop as well as a streaming platform is something the community thinks is important and something the devs actually wholeheartedly want to do. Because for me it’s central.

I’m not going to argue further about it one way or another - but in terms of where I put my energy I’d like to see it resolved. I’m sure the devs also need it resolved as it has major backend implications as we’ve discussed.


it’s important to the coop members & planned be done. but there are things ahead of it in the priority queue that are physical barriers to the downloads - like metadata handling, auto reporting payments, legal agreements etc. those have to be cleared before we can enable downloads.


As an artist I would welcome the option for fans to download tracks they had purchased (I feel like the custom of owning the music one buys has been erased by the ubiquity of streaming…a convo for another day) but I realize that this potentially adds a lot of work to a dev team that already has a mountain to climb. At its most basic level, if Resonate is to be the antidote to the existing streaming platforms, then maybe it’s best to first focus on building out a killer streaming platform that pays artists fairly.

My hope is that it can eventually be both a streaming platform and a place like Bandcamp where fans can get physical media/downloads, artist updates, goodies, subscriptions, merch, etc etc.

My 2 cents.