Tracking, sharing and collecting separate tracks for mix

[Gek21]

end result: a mixing engineer getting all the tracks separately to do the work.

Concept: A tree, at the core the combined work, evolving at each step, the bounces for reference.

At each step, branches with the various versions of the layer being added to the song (drums, base, vocals, harp, and so on). There will be back and forth until agreement and validation. (Can you try this? Can you try that? Creative soup)

Once that step is done the producer validates the preferred bounce and the contributor provides the separate stem (if not already done, depending on whether the collaboration involves an XML. If an XML is used only the stems need to be exchanged and validated and the producer generates a bounce to continue to grow the core of the tree.)

Ideally, once the creative stuff is done, you should be able to pull all stems that have been validated with one click (and any XML or similar that could be shared in the process) to send it to mix and master.

The « pull to mix » request would also validate the list of all the npubs having contributed (important when keeping in mind revenue split.)

[rockymedure]

@Gek21 starting to jam on this now. Calling it a "sounds family tree"

My goal is for this to begin to explore the answer to "what sounds make up this track"

Those can be bespoke (generated entirely by the producer outside of stemstr) or from previous stemstr downloads. For the latter, i'd like this design to address the linkage (history) of sounds and attribution through the chain.

[olheadinternet]

need to separate the two issues if the goal is: "a mixing engineer getting all the tracks separately to do the work".

If new parts are just layered onto... the tree does nothing for the engineer.

you need to encourage people to upload the additional part separately,

someone uploads a synth pad
I add drum and bass and it becomes a beat...
someone else raps over it

the engineer doesn't want a 2-track with all that, the engineer wants the acappella, the drums, the bass, and the pad all on separate tracks... but what the interface encourages now, and the output a tree would provide, the engineer still only has
2-track merged rap over beat
2-track merged dem&bss over pad
2-track pad
a single download xml of that isn't gonna do an engineer any good.the only thing isolated is the original pad.

so although I agree a tree that links to the samples used is important for attribution, it doesn't solve for the solution to "a mixing engineer getting all the tracks separately to do the work"... but being able to upload more than one file to a note, and encouraging people with design to upload their contribution separately, will allow for high quality output that audio engineers might actually want to contribute a mix too from stemstr.

[Gek21]

The tree is there to track the contributions to the track. I start from the core concept of GitHub of a track, with release of the track as the end goal. The validations serves the pull to mix request, only the notes validated would be pulled (with associated sub stem if they exist)

The trunk of the tree serves the créatives process if multiple people are involved, it’s just the stereo bounce of the whole song. It can be taken and something is layered on top before next step. But you’re right it’s useless to the engineer.

That’s where the branch comes in. The branch itself has a little trunk to guide the shared creative process note by note, but it has little branches, with little leafs , the stems of the collaborators.

A pull request essentially takes all the validated leafs and the trunks (big and little) become useless (a reference for the engineer)

then you have all the npubs of the contributors, and the debate about what is a fair way to split it (taking the entire chain into consideration) can start

[rockymedure]

Really simple, rough concept of a sounds history

[olheadinternet]

I think that's a great end goal. I would take that one step further in saying this shouldn't be a "destructive" process, in that it's not a new audio file, you simply upload your contribution with time stamps to the trunk. And the mixing would be expressed as a json file that just contains the location of the files and playback instructions instead of downloading and destructively merge them.

The pull request part might be antithetical to the core of stemstr. The tiny original bits just put into the ether are out there with the intention you don't have to ask, maybe behind a sat paywall, or none of this works. With out a non destructive process or a whole audio file format that supports keys, it's really hard to track these things if working in traditional destructive daws.

I think the next right steps towards this are:

1. multiple files per note (encouraged to upload your isolated contribution)
2. a field to input referenced notes (quote notes)
3. splits and releases should ideally be handled either on a different platform or with different note kinds, or a tag, maybe starts with

samples: small little bits
wip : work in progress (contains samples, encourages isolated contributions)
showcase: for showcasing finished work made entirely on stemstr

With showcase, I worry people will quickly try to just use this as a way to distribute music not made from stemstr, and the way music is currently created destructively there isn’t a way to validate this with signing. And the tiny little bits which is the core of stemstr don’t necessarily ever need to come back to stemstr.

Ive the use the term destructively, what that means is I download a beat file a, I add an acapella, I upload file b, I've destroyed file a in the process, if there are parts missing from a, they are gone now.

[olheadinternet]

sountree tm looks great... it's useless for anything other than attribution if the engineer has to reach out for the accapella file or the isolated contribution.

[rockymedure]

This part of it is only looking at the history of the sound - i've yet to explore the stems side of things. Yet to come.

[rockymedure]

Here's a pass at including the stems of a sound in the upload flow - does this start to get at the root of what you guys are talking about?

[olheadinternet]

beautiful

[olheadinternet]

details should also allow the pasting of a note link that is a isolated part that is from stemstr, should discourage uploading duplicates.

Here's a pass at including the stems of a sound in the upload flow - does this start to get at the root of what you guys are talking about?

[Gek21]

@rockymedure looking gooood! The notes on the soundtree should have a button to access the sound stems that were added by the contributor.

@olheadinternet just to explain where I come from for the need of 2 track bounces as the trunk if you wish. I worked as an Online Editor for TV. My task was to take the offline (low res) work from the creative editors and reassemble at master quality before managing pipeline all the way to the broadcast master. We always sent reference files, low res versions of the assembly. When hopping system to system using xmls and other edit lists one needs to verify the reassembly, that’s where the useless truk comes in. Plus, the creatives always want those “bounces”. I understand the concern of uploading too much media, could have a function that backs up all validated files and deletes the rest once song has been confirmed for release.

[Gek21]

Other side note, I agree with @olheadinternet that the platform shouldn’t be about releasing music, others people can do that. Packaging the release for Nostr friendly services however serves a double purpose:

• if the tool is well made and easy to use, it will encourage users to respect the human chain and reference all participants, since the system would do it automatically with the push of a button. (Splits will be built in in Nostr, so will the zap tag, when media distribution is ironed out at protocol level it will simply be the case of implementing it in stemstr, no need to invent anything)

• it will create a consistent new way of releasing music. Stemstr advocates for the creators camp, the distributors (relays, clients and what nots) will also have their interests to defend. By controlling the media packaging, that is how the media can be used by services downstream, the users will have the power to configure the conditions on how the music can be broadcasted with a few click before pressing release. Publishers have conned artists for too long, this bit is about fighting back.

Media distribution in Nostr is a whole lot of “coulds” for now but the idea is there, and it is coming.

[olheadinternet]

@Gek21 yeah my concern isn't sending too much... my concern is as it stands now we only sending the reference files.

We always sent reference files, low res versions of the assembly. When hopping system to system using xmls and other edit lists one needs to verify the reassembly, that’s where the useless truk comes in. Plus, the creatives always want those “bounces”. I understand the concern of uploading too much media

i share the desire for a git of music. i was just focusing directly at this goal

end result: a mixing engineer getting all the tracks separately to do the work.

which can be made easier with a reference, but with out the individual isolated contributions isn't possible. (san source separation, but that's beyond polishing a turd).

[Gek21]

Quick note after bout of passion regarding something that did not affect me directly… anyway…

Double validation of stems would be a good way of having that « creatives approval » I crave so much.

It could be implemented in a variety of ways, but potato quality audio could be forced on bounced reference track used for collaboration on upload, « high quality stems » would be released only after the conditions are met (pay wall, double human validation, free…) according to user setting.

Then, if people want to release potato quality files into the wild, their problem not mine.

[Gek21]

NIP 94 file sharing and marking seem to be addressed in there