From nando at ccrma.Stanford.EDU Wed Jun 7 19:39:01 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 07 Jun 2006 12:39:01 -0700 Subject: [Fedora-music-list] qjackctl approval/sponsorship? Message-ID: <1149709141.13022.44.camel@cmn3.stanford.edu> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191239 Final comment says: > Looks good. I can't give final approval, but this is approve-able in > my opinion. Someone please sponsor Fernando, we need him. :) So.... where do I go from here? I have other packages I'd like to submit as well (and qsynth[*] is waiting and has had no comments so far - I doubt it is a perfect package! :-) Qjackctl is really needed if you want to actually use the recently released jack package in Extras. -- Fernando [*] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191538 From naptastic at comcast.net Wed Jun 7 21:03:55 2006 From: naptastic at comcast.net (David Nielson) Date: Wed, 07 Jun 2006 15:03:55 -0600 Subject: [Fedora-music-list] Is the Core 5 x86_64 repository broken? Message-ID: <44873F3B.8030607@comcast.net> 1. Fresh install of Fedora Core 5 x86_64 on a fancy new AMD X2 3800+. 2. su - (and enter the password to obtain the mythical root superpowers) 3. rpm --import http://ccrma.stanford.edu/planetccrma/RPM-GPG-KEY.planetccrma.txt 4. rpm -Uvh http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/5/i386/planetccrma-repo-1.0-2.rhfc5.ccrma.noarch.rpm No errors so far. Everybody's happy. But this serenity will not last for long... 5. yum check-update Yum bails with a 404, followed by [errno 256 - no more mirrors to try] or something similar. The GUI package manager (pirut?) fails to load now as well. Grr. -David From nando at ccrma.Stanford.EDU Wed Jun 7 23:56:18 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 07 Jun 2006 16:56:18 -0700 Subject: [Fedora-music-list] Is the Core 5 x86_64 repository broken? In-Reply-To: <44873F3B.8030607@comcast.net> References: <44873F3B.8030607@comcast.net> Message-ID: <1149724578.13022.57.camel@cmn3.stanford.edu> On Wed, 2006-06-07 at 15:03 -0600, David Nielson wrote: > 1. Fresh install of Fedora Core 5 x86_64 on a fancy new AMD X2 3800+. > 2. su - (and enter the password to obtain the mythical root superpowers) > 3. rpm --import > http://ccrma.stanford.edu/planetccrma/RPM-GPG-KEY.planetccrma.txt > 4. rpm -Uvh > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/5/i386/planetccrma-repo-1.0-2.rhfc5.ccrma.noarch.rpm > > > No errors so far. Everybody's happy. But this serenity will not last for > long... > > 5. yum check-update > Yum bails with a 404, followed by [errno 256 - no more mirrors to try] > or something similar. The GUI package manager (pirut?) fails to load now > as well. > > Grr. Sorry, the repo is not broken, it is just not there yet :-( I have not had a chance yet to work on the x86_64 version of the realtime patched kernel so the rest does not make much sense. -- Fernando From seg at haxxed.com Thu Jun 8 00:32:11 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Jun 2006 19:32:11 -0500 Subject: [Fedora-music-list] qjackctl approval/sponsorship? In-Reply-To: <1149709141.13022.44.camel@cmn3.stanford.edu> References: <1149709141.13022.44.camel@cmn3.stanford.edu> Message-ID: <1149726732.6780.8.camel@localhost> On Wed, 2006-06-07 at 12:39 -0700, Fernando Lopez-Lezcano wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191239 > > Final comment says: > > > Looks good. I can't give final approval, but this is approve-able in > > my opinion. Someone please sponsor Fernando, we need him. :) > > So.... where do I go from here? I have other packages I'd like to submit > as well (and qsynth[*] is waiting and has had no comments so far - I > doubt it is a perfect package! :-) Err, someone has to step up and sponsor. I wonder if I should seek sponsor status for myself so I can sponsor you. Or maybe I should just bribe John Mahowald to sponsor you. Heh. Hmmm, qsynth slipped by me. Not that I'm able to keep up with fedora-package-review at all anymore. I try and CC myself to any audio software that pops up. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From naptastic at comcast.net Thu Jun 8 01:01:25 2006 From: naptastic at comcast.net (David Nielson) Date: Wed, 07 Jun 2006 19:01:25 -0600 Subject: [Fedora-music-list] Is the Core 5 x86_64 repository broken? In-Reply-To: <1149724578.13022.57.camel@cmn3.stanford.edu> References: <44873F3B.8030607@comcast.net> <1149724578.13022.57.camel@cmn3.stanford.edu> Message-ID: <448776E5.2000606@comcast.net> Fernando Lopez-Lezcano wrote: > On Wed, 2006-06-07 at 15:03 -0600, David Nielson wrote: > >> 1. Fresh install of Fedora Core 5 x86_64 on a fancy new AMD X2 3800+. >> 2. su - (and enter the password to obtain the mythical root superpowers) >> 3. rpm --import >> http://ccrma.stanford.edu/planetccrma/RPM-GPG-KEY.planetccrma.txt >> 4. rpm -Uvh >> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/5/i386/planetccrma-repo-1.0-2.rhfc5.ccrma.noarch.rpm >> >> >> No errors so far. Everybody's happy. But this serenity will not last for >> long... >> >> 5. yum check-update >> Yum bails with a 404, followed by [errno 256 - no more mirrors to try] >> or something similar. The GUI package manager (pirut?) fails to load now >> as well. >> >> Grr. >> > > Sorry, the repo is not broken, it is just not there yet :-( > > I have not had a chance yet to work on the x86_64 version of the > realtime patched kernel so the rest does not make much sense. > > -- Fernando Makes perfect sense. Apologies in advance for my noobishness, but how, then, do I go about installing the i386 versions of the software? A lesser platform version is better than what I've got now, which is nothing. And not being able to listen to music really sucks! Thanks for everything you do. Planet CCRMA is a huge service to the community and you deserve a medal. -David From endy at digitalgrotto.net Thu Jun 8 02:51:55 2006 From: endy at digitalgrotto.net (Endymion) Date: Wed, 07 Jun 2006 19:51:55 -0700 Subject: [Fedora-music-list] *****SPAM***** Fernando Lopez-Lezcano In-Reply-To: <1149724578.13022.57.camel@cmn3.stanford.edu> References: <44873F3B.8030607@comcast.net> <1149724578.13022.57.camel@cmn3.stanford.edu> Message-ID: <448790CB.6080607@digitalgrotto.net> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- An embedded message was scrubbed... From: Endymion Subject: Fernando Lopez-Lezcano Date: Wed, 07 Jun 2006 19:51:55 -0700 Size: 2032 URL: From mircobeaker at gawab.com Thu Jun 8 13:25:59 2006 From: mircobeaker at gawab.com (Mirco Scara) Date: Thu, 08 Jun 2006 14:25:59 +0100 Subject: [Fedora-music-list] Fedora 5 planetccrma kernel nightmare; In-Reply-To: <1149726732.6780.8.camel@localhost> References: <1149709141.13022.44.camel@cmn3.stanford.edu> <1149726732.6780.8.camel@localhost> Message-ID: <44882567.1070600@gawab.com> I am desperately trying to force yum/yumex to accept the installation of planetccrma-kernel-edge but to no avail. Yum keeps on saying that the planetccrma kernel is oledr than the one installed and won't proceed. How can I solve this situation? Thanks Mirco From green at redhat.com Thu Jun 8 17:04:27 2006 From: green at redhat.com (Anthony Green) Date: Thu, 08 Jun 2006 10:04:27 -0700 Subject: [Fedora-music-list] qjackctl approval/sponsorship? In-Reply-To: <1149709141.13022.44.camel@cmn3.stanford.edu> References: <1149709141.13022.44.camel@cmn3.stanford.edu> Message-ID: <1149786267.3073.44.camel@localhost.localdomain> On Wed, 2006-06-07 at 12:39 -0700, Fernando Lopez-Lezcano wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191239 > > Final comment says: > > > Looks good. I can't give final approval, but this is approve-able in > > my opinion. Someone please sponsor Fernando, we need him. :) > > So.... where do I go from here? I have other packages I'd like to submit > as well (and qsynth[*] is waiting and has had no comments so far - I > doubt it is a perfect package! :-) I am not a sponsor unfortunately. The NEEDSPONSOR bugzilla says: "People should not sit in NEED-SPONSOR status and just expect sponsorship. The best way to get sponsorship is to continue doing other work, like reviewing other packages, giving helpful advice, or submitting more packages for review. Having approved packages is *NOT* the requirement for gaining cvsextras sponsorship. Instead demonstrating that you understand the packaging guidelines and Fedora process to sponsor members is what is necessary to gain sponsorship." So my suggestions are: 1. Continue to submit RPMs 2. Post to this list when you do submit RPMs for review (I'll do the same) 3. All of us interested in audio apps should comment in bugzilla Eventually one of the sponsors will wake up and realize that we need you. I also think that lots of bugzilla traffic will help get packages reviewed and approved faster as well. I didn't see your qsynth submission. I'll make whatever comments I can today. AG From gdk at redhat.com Thu Jun 8 17:09:31 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Thu, 8 Jun 2006 13:09:31 -0400 (EDT) Subject: [Fedora-music-list] qjackctl approval/sponsorship? In-Reply-To: <1149786267.3073.44.camel@localhost.localdomain> References: <1149709141.13022.44.camel@cmn3.stanford.edu> <1149786267.3073.44.camel@localhost.localdomain> Message-ID: On Thu, 8 Jun 2006, Anthony Green wrote: > On Wed, 2006-06-07 at 12:39 -0700, Fernando Lopez-Lezcano wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191239 > > > > Final comment says: > > > > > Looks good. I can't give final approval, but this is approve-able in > > > my opinion. Someone please sponsor Fernando, we need him. :) > > > > So.... where do I go from here? I have other packages I'd like to submit > > as well (and qsynth[*] is waiting and has had no comments so far - I > > doubt it is a perfect package! :-) > > I am not a sponsor unfortunately. > > The NEEDSPONSOR bugzilla says: "People should not sit in NEED-SPONSOR > status and just expect sponsorship. The best way to get sponsorship is > to continue doing other work, like reviewing other packages, giving > helpful advice, or submitting more packages for review. Having approved > packages is *NOT* the requirement for gaining cvsextras sponsorship. > Instead demonstrating that you understand the packaging guidelines and > Fedora process to sponsor members is what is necessary to gain > sponsorship." > > So my suggestions are: > > 1. Continue to submit RPMs > 2. Post to this list when you do submit RPMs for review (I'll do the same) > 3. All of us interested in audio apps should comment in bugzilla > > Eventually one of the sponsors will wake up and realize that we need > you. I also think that lots of bugzilla traffic will help get packages > reviewed and approved faster as well. FWIW, I'm also actively lobbying for your sponsorship. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From nando at ccrma.Stanford.EDU Fri Jun 9 01:31:39 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Thu, 08 Jun 2006 18:31:39 -0700 Subject: [Fedora-music-list] Fedora 5 planetccrma kernel nightmare; In-Reply-To: <44882567.1070600@gawab.com> References: <1149709141.13022.44.camel@cmn3.stanford.edu> <1149726732.6780.8.camel@localhost> <44882567.1070600@gawab.com> Message-ID: <1149816699.19977.57.camel@cmn3.stanford.edu> On Thu, 2006-06-08 at 14:25 +0100, Mirco Scara wrote: > I am desperately trying to force yum/yumex to accept the installation of > planetccrma-kernel-edge but to no avail. > Yum keeps on saying that the planetccrma kernel is oledr than the one > installed and won't proceed. > How can I solve this situation? Maybe this will help: http://ccrma.stanford.edu/planetccrma/software/installtwosix.html Check the "Installing the low latency kernel" section, in particular the tweak to /etc/yum.conf (which should let you install older stuff) and disabling /etc/yum/pluginconf.d/installonlyn.conf so that all kernels are kept (the default is to just keep the last two, not enough if you are trying out kernels). -- Fernando From nando at ccrma.Stanford.EDU Fri Jun 9 01:33:04 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Thu, 08 Jun 2006 18:33:04 -0700 Subject: [Fedora-music-list] qjackctl approval/sponsorship? In-Reply-To: <1149786267.3073.44.camel@localhost.localdomain> References: <1149709141.13022.44.camel@cmn3.stanford.edu> <1149786267.3073.44.camel@localhost.localdomain> Message-ID: <1149816784.19977.59.camel@cmn3.stanford.edu> On Thu, 2006-06-08 at 10:04 -0700, Anthony Green wrote: > On Wed, 2006-06-07 at 12:39 -0700, Fernando Lopez-Lezcano wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191239 > > > > Final comment says: > > > > > Looks good. I can't give final approval, but this is approve-able in > > > my opinion. Someone please sponsor Fernando, we need him. :) > > > > So.... where do I go from here? I have other packages I'd like to submit > > as well (and qsynth[*] is waiting and has had no comments so far - I > > doubt it is a perfect package! :-) > > I am not a sponsor unfortunately. > > The NEEDSPONSOR bugzilla says: > "People should not sit in NEED-SPONSOR status and just expect > sponsorship. The > best way to get sponsorship is to continue doing other work, like reviewing > other packages, giving helpful advice, or submitting more packages for review. > Having approved packages is *NOT* the requirement for gaining cvsextras > sponsorship. Instead demonstrating that you understand the packaging guidelines > and Fedora process to sponsor members is what is necessary to gain sponsorship." > > So my suggestions are: > > 1. Continue to submit RPMs > 2. Post to this list when you do submit RPMs for review (I'll do the same) > 3. All of us interested in audio apps should comment in bugzilla Ok, I'll do... Thanks! -- Fernando From nando at ccrma.Stanford.EDU Fri Jun 9 01:41:43 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Thu, 08 Jun 2006 18:41:43 -0700 Subject: [Fedora-music-list] Is the Core 5 x86_64 repository broken? In-Reply-To: <448776E5.2000606@comcast.net> References: <44873F3B.8030607@comcast.net> <1149724578.13022.57.camel@cmn3.stanford.edu> <448776E5.2000606@comcast.net> Message-ID: <1149817303.19977.61.camel@cmn3.stanford.edu> On Wed, 2006-06-07 at 19:01 -0600, David Nielson wrote: > Fernando Lopez-Lezcano wrote: > > On Wed, 2006-06-07 at 15:03 -0600, David Nielson wrote: > > > >> 1. Fresh install of Fedora Core 5 x86_64 on a fancy new AMD X2 3800+. > >> 2. su - (and enter the password to obtain the mythical root superpowers) > >> 3. rpm --import > >> http://ccrma.stanford.edu/planetccrma/RPM-GPG-KEY.planetccrma.txt > >> 4. rpm -Uvh > >> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/5/i386/planetccrma-repo-1.0-2.rhfc5.ccrma.noarch.rpm > >> > >> > >> No errors so far. Everybody's happy. But this serenity will not last for > >> long... > >> > >> 5. yum check-update > >> Yum bails with a 404, followed by [errno 256 - no more mirrors to try] > >> or something similar. The GUI package manager (pirut?) fails to load now > >> as well. > >> > >> Grr. > >> > > > > Sorry, the repo is not broken, it is just not there yet :-( > > > > I have not had a chance yet to work on the x86_64 version of the > > realtime patched kernel so the rest does not make much sense. > > Makes perfect sense. Apologies in advance for my noobishness, but how, > then, do I go about installing the i386 versions of the software? A > lesser platform version is better than what I've got now, which is > nothing. And not being able to listen to music really sucks! Hmm, I guess you need to install the i386 version of fc. I have never tried to install i386 binaries on top of x86_64, I imagine it would not be easy. > Thanks for everything you do. Planet CCRMA is a huge service to the > community and you deserve a medal. So much to do, so little time.... -- Fernando From gdk at redhat.com Tue Jun 27 21:22:40 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 27 Jun 2006 17:22:40 -0400 (EDT) Subject: [Fedora-music-list] Some notes from a cool meeting at RH today Message-ID: Had a good chat with Adrian Likins, Steven Salevan and Luke Macken today about what a "music collaboration server" might look like. Here's a whole firehose full of notes. To Adrian/Steven/Luke, this'll probably mean more -- but any questions, feel free to ask. :) We're getting together again here in Red Hat HQ to brainstorm more about possible clients on Thursday. For those of you on the list who aren't from around here, apologies, and we'll start filling in gaps soon. --g ======================================================================= The Four Steps -------------- 1. EXPORT TOOLS AND RULES. Figure out how to get output from every major music production tool into a simple, common format. If it's tools that plug in to GarageBand/Steinberg/Logic, great. If it's a 20-step HOWTO for each of those tools, great. The end result: wav/midi files, per track, that can be easily shared. 2. DEFINE COMMON METADATA FORMAT. Rough database schema follows. 3. REPOSITORY FOR METADATA. Ditto. 4. UPLOAD TOOLS. We need some simple way of getting "sharable" data into the system initially. The WAG at Schema ----------------- user email varchar password varchar asset (a superclass, subclassed per asset type) id varchar (md5sum) creator_id fk (user.email) license_id fk (license table) uri varchar creation_date date music_asset (a subclass of asset, we thus leave the possibility of video/clipart/etc.) asset_id fk (asset.id) lyric_id fk (lyric.id) (nullable) type? (midi/wav/loop/etc?) key? varchar? tempo? varchar? bpm? int? others? lyric id varchar (md5sum) author fk (user.email) authored_date date song id varchar (md5sum) producer_id fk (user.email) uri varchar production_date date song_tracks song_id fk (song.id) track_id fk (music_asset.asset_id) track_parent track_id fk (music_asset.asset_id) parent_id fk (music_asset.asset_id) Other stuff: tagging schema for songs and tracks --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From green at redhat.com Wed Jun 28 01:57:40 2006 From: green at redhat.com (Anthony Green) Date: Tue, 27 Jun 2006 18:57:40 -0700 Subject: [Fedora-music-list] Some notes from a cool meeting at RH today In-Reply-To: References: Message-ID: <1151459860.2598.123.camel@localhost.localdomain> On Tue, 2006-06-27 at 17:22 -0400, Greg DeKoenigsberg wrote: > Had a good chat with Adrian Likins, Steven Salevan and Luke Macken today > about what a "music collaboration server" might look like. Here's a whole > firehose full of notes. To Adrian/Steven/Luke, this'll probably mean more > -- but any questions, feel free to ask. :) I'm not exactly sure what you're up to, but... The fundamental problem with real collaboration in the area is that you're limited to working with the lowest common denomination of tools. I, for instance, have Sonar and Reason, plus a number of plugins. The kind of collaboration I'm able to do is extremely limited unless the people I'm collaborating with have exactly the same set of tools and plugins. People who are willing to spend money on commercial tools are also more likely to spend money on commercial collaboration services. In the FOSS world, however, access to tools is a non-issue. We should just be able to yum/apt-get them. I think a "music collaboration server" for FOSS-based music production makes perfect sense, but I didn't see you mention Rosegarden/Ardour/Hydrogen. Perhaps LASH could be extended to work using a client server model. Now that would be pretty spiffy... AG From seg at haxxed.com Wed Jun 28 03:08:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 27 Jun 2006 22:08:02 -0500 Subject: [Fedora-music-list] Some notes from a cool meeting at RH today In-Reply-To: References: Message-ID: <1151464082.4684.9.camel@localhost> Yeah, this is a bit lacking in context. What are we going for here? Music already has a solid standard, MIDI. Though what is sadly lacking is a MIDI over IP implementation. The IETF is working on MWPP but I haven't been able to dig up any implementations. I'm surprised its taking so long. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alikins at redhat.com Wed Jun 28 04:28:10 2006 From: alikins at redhat.com (Adrian Likins) Date: Wed, 28 Jun 2006 00:28:10 -0400 Subject: [Fedora-music-list] Some notes from a cool meeting at RH today In-Reply-To: <1151464082.4684.9.camel@localhost> References: <1151464082.4684.9.camel@localhost> Message-ID: <44A2055A.2040009@redhat.com> Callum Lerwick wrote: > Yeah, this is a bit lacking in context. What are we going for here? > > Music already has a solid standard, MIDI. Though what is sadly lacking > is a MIDI over IP implementation. The IETF is working on MWPP but I > haven't been able to dig up any implementations. I'm surprised its > taking so long. > > The current thinking is geared more towards non realtime collaboration, > so something > > like MIDI-over-IP isn't really related. At least not yet. > > The current thinking is geared more towards non realtime collaboration, so something like MIDI-over-IP isn't really related. At least not yet. The idea is more to share content and music related resources. samples, loops, tracks, etc. A content server really. Think garageband or similar tools with the loop browser hooked into a remote db with 10,000 loops. Ideally, the FOSS tools would get hooked into it. Ideally there would be some way to at least import data from other apps as well. Adrian From joakim at verona.se Wed Jun 28 11:45:28 2006 From: joakim at verona.se (joakim at verona.se) Date: Wed, 28 Jun 2006 13:45:28 +0200 Subject: [Fedora-music-list] Re: Some notes from a cool meeting at RH today References: <1151464082.4684.9.camel@localhost> <44A2055A.2040009@redhat.com> Message-ID: Adrian Likins writes: I dont know if this is related, but I do something similar in my band. We have an instance of "Trac" setup, which is a version control/bugtracker/wiki system. We upload tracks, samples , lyrics etc to the server and work together in the wiki and source repos. We use free tools on the client. The good is that its really easy to set up and get going, the bad is that trac is geared towards traditional source code management, so we haent quite got it working like we would like yet. For instance, Rosegarden uses compressed xml files, that we would like to have decompressed automatically on the server so we can track diffs. Just some input... > Callum Lerwick wrote: >> Yeah, this is a bit lacking in context. What are we going for here? >> >> Music already has a solid standard, MIDI. Though what is sadly lacking >> is a MIDI over IP implementation. The IETF is working on MWPP but I >> haven't been able to dig up any implementations. I'm surprised its >> taking so long. The current thinking is geared more towards non >> realtime collaboration, so something >> >> like MIDI-over-IP isn't really related. At least not yet. >> >> > The current thinking is geared more towards non realtime > collaboration, so something > like MIDI-over-IP isn't really related. At least not yet. > > The idea is more to share content and music related > resources. samples, loops, tracks, etc. > A content server really. Think garageband or similar tools with the > loop browser hooked > into a remote db with 10,000 loops. > > Ideally, the FOSS tools would get hooked into it. Ideally there would > be some way to > at least import data from other apps as well. > > Adrian > -- Joakim Verona http://www.verona.se From gdk at redhat.com Wed Jun 28 14:49:00 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 28 Jun 2006 10:49:00 -0400 (EDT) Subject: [Fedora-music-list] Some notes from a cool meeting at RH today In-Reply-To: <1151459860.2598.123.camel@localhost.localdomain> References: <1151459860.2598.123.camel@localhost.localdomain> Message-ID: On Tue, 27 Jun 2006, Anthony Green wrote: > On Tue, 2006-06-27 at 17:22 -0400, Greg DeKoenigsberg wrote: > > Had a good chat with Adrian Likins, Steven Salevan and Luke Macken today > > about what a "music collaboration server" might look like. Here's a whole > > firehose full of notes. To Adrian/Steven/Luke, this'll probably mean more > > -- but any questions, feel free to ask. :) > > I'm not exactly sure what you're up to, but... > > The fundamental problem with real collaboration in the area is that > you're limited to working with the lowest common denomination of tools. > I, for instance, have Sonar and Reason, plus a number of plugins. The > kind of collaboration I'm able to do is extremely limited unless the > people I'm collaborating with have exactly the same set of tools and > plugins. Or are willing to come down to the aforementioned lowest common denominator -- like wav files. "This is my song. I did it in Garage Band, but you may not use Garage Band. Therefore, I offer up my project as a set of 14 wav files, one per track." The goal, from my perspective, is to build a mechanism to share the basic building blocks of music collaboration -- which, from my (perhaps simplistic) perspective is the track. > People who are willing to spend money on commercial tools are also more > likely to spend money on commercial collaboration services. I don't think the money is in charging for tools. I think the money is in building a non-commercial commons and charging commercial users for access to that commons. > In the FOSS world, however, access to tools is a non-issue. We should > just be able to yum/apt-get them. I think a "music collaboration > server" for FOSS-based music production makes perfect sense, but I > didn't see you mention Rosegarden/Ardour/Hydrogen. Not yet, but nothing here precludes their use, obviously. The first goal is to figure out the basic "song/track/license" model -- the "basic unit" of sharability. Once we figure that out, we then figure out how to get tools to produce those "basic units"... and it's obvious that the first tools we'll be able to influence in this way will be Rosegarden/Ardour/Hydrogen. > Perhaps LASH could be extended to work using a client server model. > Now that would be pretty spiffy... Yep. :) --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From lmacken at redhat.com Wed Jun 28 15:08:11 2006 From: lmacken at redhat.com (Luke Macken) Date: Wed, 28 Jun 2006 11:08:11 -0400 Subject: [Fedora-music-list] Re: Some notes from a cool meeting at RH today In-Reply-To: References: <1151464082.4684.9.camel@localhost> <44A2055A.2040009@redhat.com> Message-ID: <20060628150811.GA2910@crow.rdu.redhat.com> On Wed, Jun 28, 2006 at 01:45:28PM +0200, joakim at verona.se wrote: > Adrian Likins > writes: > > I dont know if this is related, but I do something similar in my > band. > > We have an instance of "Trac" setup, which is a version > control/bugtracker/wiki system. > > We upload tracks, samples , lyrics etc to the server and work together > in the wiki and source repos. We use free tools on the client. > > The good is that its really easy to set up and get going, the bad is > that trac is geared towards traditional source code management, so we > haent quite got it working like we would like yet. For instance, > Rosegarden uses compressed xml files, that we would like to have > decompressed automatically on the server so we can track diffs. > > Just some input... I think it's great that there are actually bands out there using source code management tools for their music! (being able to file a bug against your guitar players solo would be pretty amusing ;), but I don't that this is exactly what we are trying to gear towards. Instead of providing a central colloboration server to manage song/track revisions, I think it should be designed around handling derivations (while keeping a solid audit trail of creators and licenses, of course). There was much brainstorming yesterday, and there is definitely going to be more tomorrow, so hopefully we'll be able to add some more context to this initiative in the near future. luke From ssalevan at redhat.com Wed Jun 28 18:38:03 2006 From: ssalevan at redhat.com (Steven Salevan) Date: Wed, 28 Jun 2006 14:38:03 -0400 Subject: [Fedora-music-list] Re: Some notes from a cool meeting at RH today In-Reply-To: <20060628150811.GA2910@crow.rdu.redhat.com> References: <1151464082.4684.9.camel@localhost> <44A2055A.2040009@redhat.com> <20060628150811.GA2910@crow.rdu.redhat.com> Message-ID: <44A2CC8B.5080301@redhat.com> I think that this derivation handling might be one of the big keys to the whole system here. Sometimes, slight variations in a track can make all the difference, and it's one of the areas where collaboration and community criticism can come into play. Listen to some of Brian Wilson's Pet Sounds sessions to get an idea of how many different takes were made of each particular musical line and how many of these pools of takes had to be chosen from and mixed into the final project. Music isn't nearly as clean as software is in terms of black and white improvements, and most of the musicians around here that I've talked to consider the concept of a 'revision' of a track or an 'update' to be pretty ludicrous. From experience, it's as hard as anything to choose exactly which take of a musical line should go into the final mix, and with a system like this, you could ask other people's opinions and get the kind of assistance that you'd pay a producer and a recording engineer large sums of money to do. This would be one of the things that'd draw small artists into the fray, as most small acts can't afford the kind of advice and expertise that a community could provide. "With many ears, all out-of-tune guitars stay on the pitch", perhaps. As Luke, Greg, and Adrian said, there will be more interesting stuff to ruminate on tomorrow. -Steve Salevan ssalevan at redhat.com Luke Macken wrote: > Instead of providing a central colloboration server to manage song/track > revisions, I think it should be designed around handling derivations > (while > keeping a solid audit trail of creators and licenses, of course). > > There was much brainstorming yesterday, and there is definitely going > to be > more tomorrow, so hopefully we'll be able to add some more context to > this initiative in the near future. > > luke > > > From kwade at redhat.com Wed Jun 28 21:12:56 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 28 Jun 2006 14:12:56 -0700 Subject: [Fedora-music-list] Re: Some notes from a cool meeting at RH today In-Reply-To: References: <1151464082.4684.9.camel@localhost> <44A2055A.2040009@redhat.com> Message-ID: <1151529180.2489.620.camel@erato.phig.org> On Wed, 2006-06-28 at 13:45 +0200, joakim at verona.se wrote: > The good is that its really easy to set up and get going, the bad is > that trac is geared towards traditional source code management, so we > haent quite got it working like we would like yet. For instance, > Rosegarden uses compressed xml files, that we would like to have > decompressed automatically on the server so we can track diffs. That should be doable on the server side. Subversion can run a script that decompresses before committing. If you can't get compression through Subversion, you could use a local svn wrapper script that updates, compresses, then writes to the local file system. What is really interesting to me here is how media collaboration (code, music, content, etc.) all benefit from a common underpinning of tool capabilities. I'd like to see all of these media needs addressed within a single Fedora platform, which could be a stitching together of existing FLOSS platforms. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nando at ccrma.Stanford.EDU Fri Jun 30 20:03:56 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Fri, 30 Jun 2006 13:03:56 -0700 Subject: [Fedora-music-list] Some notes from a cool meeting at RH today In-Reply-To: <1151464082.4684.9.camel@localhost> References: <1151464082.4684.9.camel@localhost> Message-ID: <1151697836.12140.38.camel@cmn3.stanford.edu> On Tue, 2006-06-27 at 22:08 -0500, Callum Lerwick wrote: > Yeah, this is a bit lacking in context. What are we going for here? > > Music already has a solid standard, MIDI. Though what is sadly lacking > is a MIDI over IP implementation. The IETF is working on MWPP but I > haven't been able to dig up any implementations. I'm surprised its > taking so long. [late on this thread, but still...] MIDI is a standard and solid and has been around for a long time. But it would be (from my point of view) a very limited standard for collaboration. It does not define the sound, it is just a protocol that controls note based instruments - of course you can say, "piano", but that is a one word description of a very complex instrument, and it gets worse when you have to deal with non-note based instrument (say, wind instruments). -- Fernando