LinuxMusicians

wolftune wrote:The only valid complete source would be entire session files. …

So when using for instance Non-Session-Manager, you could just dump your project directory, it contains the audio files, jackpatch setting and programs used.
That would be a cool thing.

Just bring in my 2 cents. In the "old days" you would listen to a record, find cool parts, subscribed them or sampled them when you wanted to use them.
In line with what Wolftune said, could it be a idea to add completed music on soundcloud or other websites, with a notice that on request files can be shared.
If you get a couple of request you can also dump the files somewhere. If not, no harm is done.

Hans

wolftune wrote:The only valid complete source would be entire session files. Anything less is just partial.

But like I said, what if there isn't a session file? What if I dump a GPL audio track to analog and record & mix old-school (I still keep my fostex R8 around, too many good memories there)? I could dump the analog tracks back to digital, but you wouldn't have my fader moves, eq settings, outboard FX settings, etc.

What if I bounce tracks or record with FX, and there's no way to retrieve the original takes discretely? Is it enough to release the individual tracks as they were at mixdown, or am I required to make a digital backup of each track before doing any destructive editing?

From GPL: "The "source code" for a work means the preferred form of the work for making modifications to it."

Well, if you're the person who recorded a song, your preferred form for modifying your recording is your precise session files with all the separate tracks and effect racks and everything. So, that's what full source would be when sharing the source with others.

Of course, sharing *some* source files is nicer than nothing…

Yes, it's nicer, but if we're talking about legally obligating ourselves, it's not enough; especially since the requirements would apply to anyone distributing the work (does this apply to radio stations? Music stores? Would Pandora or Jamendo be obligated to provide sources?).

If I'm obligated to provide the "preferred form of the work", who determines what's preferred? With code it's pretty straightforward, because code is basically created one way: You author a bunch of text files that are fed to a compiler / interpreter / build tool and it generates a binary.

Audio isn't so straightforward. There are a lot of ways to compile a piece of audio, and they aren't all non-destructive, automated, or easily repeatable.

My point isn't to be anti-GPL here, or to take you personally to task for wanting to release stuff GPL, but I guess I'm just thinking this through out-loud because it seems like copylefting audio (or using said audio) may ultimately be a self-defeating endeavor, if the requirements for users and distributors are too onerous or nebulous.

lykwydchykyn wrote:
But like I said, what if there isn't a session file? What if I dump a GPL audio track to analog and record & mix old-school (I still keep my fostex R8 around, too many good memories there)? I could dump the analog tracks back to digital, but you wouldn't have my fader moves, eq settings, outboard FX settings, etc.

Well, then you have no source, it's like you wrote a program in machine code. That's as good as we get, and there's no more-preferred source that exists.

lykwydchykyn wrote: What if I bounce tracks or record with FX, and there's no way to retrieve the original takes discretely? Is it enough to release the individual tracks as they were at mixdown, or am I required to make a digital backup of each track before doing any destructive editing?

Yeah, it's messy. But if *you* wanted to make a remix, the point is that you share with others whatever you would care to keep for yourself, don't give them second-class status.

lykwydchykyn wrote: if we're talking about legally obligating ourselves, it's not enough; especially since the requirements would apply to anyone distributing the work (does this apply to radio stations? Music stores? Would Pandora or Jamendo be obligated to provide sources?).

If I'm obligated to provide the "preferred form of the work", who determines what's preferred? With code it's pretty straightforward, because code is basically created one way: You author a bunch of text files that are fed to a compiler / interpreter / build tool and it generates a binary.

Like any other distribution under GPL, if it were GPL, then Jamendo or Pandora would have to provide some way to get the source, which can be as simple as a link on their websites and a mention that such links exist. GPL never requires the source to be included. The "preferred form" is, to some extent, a court judgment. And I think it basically means: "give others what you would use yourself if you were the one remixing".

lykwydchykyn wrote: My point isn't to be anti-GPL here, or to take you personally to task for wanting to release stuff GPL, but I guess I'm just thinking this through out-loud because it seems like copylefting audio (or using said audio) may ultimately be a self-defeating endeavor, if the requirements for users and distributors are too onerous or nebulous.

It's definitely confusing, and I'm not actively advocating for it. I think that copylefting music would be acceptable after we have a strong enough system in place to make it really easy and probably clarify a lot more about the terms etc. I think it's more about source as ideal but not as a requirement.

lykwydchykyn wrote:But like I said, what if there isn't a session file? What if I dump a GPL audio track to analog and record & mix old-school (I still keep my fostex R8 around, too many good memories there)? I could dump the analog tracks back to digital, but you wouldn't have my fader moves, eq settings, outboard FX settings, etc.

What if I bounce tracks or record with FX, and there's no way to retrieve the original takes discretely? Is it enough to release the individual tracks as they were at mixdown, or am I required to make a digital backup of each track before doing any destructive editing?

This is again the case of using non free stuff during production. It is mitigated by using only free software.

FaTony wrote:

lykwydchykyn wrote:But like I said, what if there isn't a session file? What if I dump a GPL audio track to analog and record & mix old-school (I still keep my fostex R8 around, too many good memories there)? I could dump the analog tracks back to digital, but you wouldn't have my fader moves, eq settings, outboard FX settings, etc.

What if I bounce tracks or record with FX, and there's no way to retrieve the original takes discretely? Is it enough to release the individual tracks as they were at mixdown, or am I required to make a digital backup of each track before doing any destructive editing?

This is again the case of using non free stuff during production. It is mitigated by using only free software.

FaTony, the question you are replying to was talking about mixing with *analog* recording tools, with magnetic tape and such and physical knobs that control physical circuits, stuff that is pure hardware. There's no software at all. And the hardware isn't non-free in any sense that counts here.

The question is: what if the GPL music is recorded to that analog tape and then messed with and remixed that way? There is an answer, my answer from above, which amounts to: You just have to provide the same source you have access to yourself, which is the original GPL music files. There's no source for your analog stuff, so you don't have to provide that. Having said that, I'm not denying this is complex and easy to get confused or be unenforceable.

This is an interesting thing. I think I could try to provide "source" when it does not take too many gigs. Also, I think there is another point that if I am not wrong has not been discussed yet: maintaining the source. If we think that the "source" is the session file, than the source is stuck with the program(s) that can handle that session file. Moreover, it might be stuck with the version it was used at the time. This reminds me of when a friend wanted to remix a song of mine. I was like "yeah, no problems! I will export the tracks to you". Nope. It was recorded with Ardour 2 and Ardour 4 couldn't open it at first. Later on it was found to be a bug, but in the meanwhile my attempts to recover the session corrupted it forever. Should the author work to provide endless compatibility?

This is an interesting problem. In my case my music is usually in the constant state of work in progress so I keep files updated. But in the long run I guess exporting .mid files and sheets may be better.

CrocoDuck wrote: Also, I think there is another point that if I am not wrong has not been discussed yet: maintaining the source. If we think that the "source" is the session file, than the source is stuck with the program(s) that can handle that session file.

I said this on the first page but was apparently ignored... But yeah midi files aren't ideal since they don't contain standard representations of automation (I think) nor is there a way to express complex project configurations, eg grouping, plugin chains and signal routing so a lot would have to be done manually. I think format compatibility is something to think about as LAU continues to evolve. The good thing about foss is that APIs are generally transparent enough that if needed it isnt impossible for a third party to develop some conversion utility between formats, like the ardour->non utility that male wrote a while back (not sure if it still works though)

CrocoDuck wrote:Should the author work to provide endless compatibility?

Well, in the software world, there is no obligation there. If I were to write driver code for a Linux 2.2 kernel, which only compiles with some ancient version of GCC, I would be under no obligation to make this work with kernel 4.3 or a newer GCC.

Likewise, if I release python code under the GPL, it's understood that it requires python and possibly third-party python libraries to be installed for the code to run. There's no obligation to port it to some kind of ready-to-run/platform-agnostic code.

Maintenance is only an obligation if you release a newer version of the "binary" based on updated sources. You have to provide sources for any binary you distribute, basically.

FaTony wrote: But in the long run I guess exporting .mid files and sheets may be better.

Actually, I think that'd be worse; it'd be like only releasing header files for c code, because the actual implementation details (which synths/patches were used, FX, mixdown settings, etc) would be missing.

Hmm well I have been thinking about this more. I was releasing under CC BY-NC-SA 4.0 but I decided to drop it down to CC BY-SA 4.0, since I'm not really that opposed to people making money with it if they're willing acknowledge that I wrote the original song. I also have been dumping a lot of my music source files to Blend. But I'm using a lot of proprietary plugins since they flow better with my creativity.

I wouldn't object to giving away stems by default if it was easy/convenient to do so, but my upload speed is only ~700 KB/s and saving all that data for each project really starts eating up a lot of disk space, which is still a concern when you're using SSD. So my compromise with that is if someone approaches me asking for stems I'll take the effort to release them, but otherwise I'm not going to go out of my way to do so.

You could release .mid files or sheets.

i'm planning to release supercollider part of my project when it's (more or less) ready.
but i go greedy when it comes to synth patches, because people in general don't want to educate and learn how things work, they just want to download more ready presets instead ))

Well, that's an interesting dilemma. I'm pretty sensitive about the problem of bulk and collecting. I've fallen into that trap myself. I'm not sure that keeping patches unreleased will help anyone avoid obsessive collecting though. But I agree with the idea that it's nice to encourage people to learn how to actually adapt synths on their own instead of just collecting thousands of patches…

Maybe we need some sort of diff system that shows the similarity of patches based on their diffs and then organizes them in meaningful ways "X is just Y with LFO faster" or something… instead of just huge lists with broad categories…

chaocrator wrote: i go greedy when it comes to synth patches, because people in general don't want to educate and learn how things work, they just want to download more ready presets instead ))

Not to be accusatory, but thats how I feel about my software too. People just want to use it, they don't study the source and learn. Many aren't interested if they have to compile it themselves. I release it though because many other devs have given me so much free licensed software that I learn from. It is more or less just giving away your skills, time, and effort, but hopefully it will inspire somebody else to share alike.

Anyhow maybe thats OT.

ssj71 wrote:Not to be accusatory, but thats how I feel about my software too. People just want to use it, they don't study the source and learn.

i would. but i have no time.
i often think about cool mods & features i would do with software if i could code, but that's a vicious circle.

btw, when it comes to plugins, (too) many people want just to collect more and more of them, like it happens with synth patches. and exactly this happens in the win/mac/proprietary world too. in general, people tend to prefer collecting instruments over learning them. that's some kind of cognitive bias, i think, because collecting guitars does not turn one into angus young, and it's quite obvious.

ssj71 wrote:Many aren't interested if they have to compile it themselves.

that's not just bad, but good too real men don't just compile software, but package it
or otherwise we get things too difficult to update and too easy to break.

my own dedicated live/rehearsal system is entirely built, packaged & maintained by me, according to my own conception of doing things properly. it not only has everything i need, but also stripped from anything i don't. i eventually will put it on github when it's considered ready.