May 2006 - music - Fedora Mailing-Lists

by Florin Andrei

I always thought that merging PlanetCCRMA and Extras makes a lot of sense, and I also made some noises on the Planet mailing list. I'm glad to see that something has been started. -- Florin Andrei http://florin.myip.org/

18 years

3
3
0 / 0

Alsa tools and firmware

by Tim Mayberry

Hello all, It seems the alsa-tools package in fedora extras is crippled as I found out a little while ago https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186858 and there is no alsa-firmware package in FE. This is a bit of a problem for people like myself who use audio devices that need firmware to be loaded into the device before it can be used. In the past I used the planet CCRMA alsa packages and more recently I built and installed the alsa-tools and alsa-firmware packages from source tarballs because at the time planet CCRMA didn't support FC5. Although I greatly appreciate the work of Fernando and others at CCRMA, I don't really like the idea of replacing the whole alsa stack when as far as I'm aware it isn't really necessary. I believe the alsa-firmware package is not available in FE because of policy, assuming that is still the case it would mean that the alsa-firmware package would need to be hosted in an external repository. I'm not aware of a precedent of a package in the Fedora Extras repository depending on a package in an external repository but it doesn't sound like a good idea if it can be avoided. In this case it can by removing the crippled alsa-tools package from Fedora Extras and keeping it an external repository along with the alsa-firmware package. I'm not sure if this would be the best solution or if there are issues that meant it wouldn't be possible but I would like to help in making it easier for Fedora to support these devices as getting them to work at the moment is frustrating(at least to me) and beyond the capability of what I would expect from the "average user". Thoughts and ideas welcome... Tim.

18 years

3
2
0 / 0

package naming question: muse -vs - MusE

by Anthony Green

There are some discussions about merging parts of PlanetCCRMA into Fedora Extras. One of the problems has to do with package namespace conflicts. For instance, PlanetCCRMA has had a "muse" package for many years (http://www.muse-sequencer.org). But now FE has an emacs extension package called "muse". So, assuming the emacs extension package can't be renamed, we need a new name for the musical muse package. One of the suggestions was to use the official project spelling of "MusE" for the package name. Do the Extras packaging guidelines allow this (having both MusE and muse package)? AG

18 years, 1 month

5
9
0 / 0

Re: [Fedora-music-list] Re: package naming question: muse -vs - MusE

by Christian Iseli

notting(a)redhat.com said: > Anthony Green (green(a)redhat.com) said: > > One of the suggestions was to use the official project spelling of > > "MusE" for the package name. Do the Extras packaging guidelines allow > > this (having both MusE and muse package)? Let's please not go that route... even though I can't find anything in the guidelines that mention this case (yet...) > Some combination of CVS, bugzilla, and/or the buildsystem I suspect would > break. Yes, and for the end user it might get quite confusing... > Frankly, I'd rename the emacs thing emacs-muse, but that's just me. :) Not just you. If RPM can handle this, maybe an emacs-muse package that Provides muse for a short while... I think spot wanted to explicitly mention emacs/xemacs in the addon packages section. Cheers, Christian

18 years, 1 month

1
0
0 / 0

Re: [PlanetCCRMA] Fedora Extras

by Fernando Lopez-Lezcano

On Sat, 2006-05-06 at 15:49 -0700, Anthony Green wrote: > On Sat, 2006-05-06 at 15:20 -0700, Fernando Lopez-Lezcano wrote: > > Which spec files have you worked on? > > They're all listed here: http://people.redhat.com/green/FE/FC5 Hey great!! Too bad you did not sync with me, I've been working this two last weeks on pretty much the same stuff. But there are things that I don't have which is great! What has delayed me this past week is work on the menu system (I'm pretty much done and I was going to release a bunch of packages later today). If I may suggest a couple of things after a quick look, ladcca is not longer needed - I imagine it is there only as a result of previous builds? I would drop qjackconnect in favor of qjackctl, the later is the canonical jack server control app (and also sports a midi patchbay). I added a patch for lash so that it does not need an entry in /etc/services for the lash service (it will use the default instead). You will be able to pick this later today from the srpm. DSSI is now up to 0.9.1 and fluidsynth-dssi is a separate package (finally!). Are you planning on packaging the Hydrogen kits separately? I used to have a separate package but I merged them into the main package a while back... the example drumkits and demo songs are very useful for demos, with them (or at least some of them) it is easy to just fire up hydrogen and get sound out of it. Another question... have you tried caps with ardour? I'm having problems with that combination, selinux complains about something and the caps collection does not get loaded at all. > > > A few months ago there was a discussion on this list about moving some > > > packages from PlanetCCRMA to Extras. I took the JACK submission as a > > > cue and started submitting. > > > > Sigh, I was not aware that Jack had already been submitted. > > Yes, two months ago: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183912 > > I only noticed last month. I didn't... I could have answered a lot of those questions really fast... What should be packaged today, at least till that patch makes it into cvs (that was going to happen a couple of days ago) is the clock_fix branch of Jack cvs. Otherwise Jack will have problems in Athlon X2 machines... > > As I said, no problem. But I would appreciate if people don't reinvent > > the wheel and create specs from scratch given that they are available > > from Planet CCRMA (and I have worked on them for so long). > > Yes, of course. You've done great work. All of the packages I've > submitted are based on your spec files, with the changelog history > preserved. See the ardour spec file, for example: > http://people.redhat.com/green/FE/FC5/ardour.spec Thanks, most probably most of it will be "trimmed", right? There was a discussion long ago about keeping only a certain ammount of history in the changelog. I don't know what became of that - I think they were scavenging for space to avoid including one more disk in the base distro. -- Fernando

18 years, 1 month

2
3
0 / 0

Intro & packages submitted

by Anthony Green

Thanks again, Fernando, for pointing out the existence of this list. I missed the intros from last month, so here's mine... My name is Anthony Green. I live in Portland, OR and have worked at Red Hat (and Cygnus prior to that) for over 10 years, although in a non-Engineering capacity for most of that time. I package a small handful of apps for Fedora Extras (mostly java-related). For the curious, here's a summary of packages I've submitted to FE for review... ardour https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189315 caps LADSPA plugins https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190045 dssi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189892 fluidsynth https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189886 hexter-dssi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190027 hydrogen https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190040 lash https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189884 liblo https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189891 liblrdf https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189313 raptor (This one has been ACCEPTED) swh-plugins (This one has been ACCEPTED) vkeybd https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189889 whysynth-dssi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190029 Many of these depend on Andy's jack-audio-connection-kit submission. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183912 I think the biggest problem right now is the FE sponsor/reviewer bottleneck. jack-audio-connection-kit has been in the works for two months now. AG

18 years, 1 month

1
0
0 / 0

Re: [PlanetCCRMA] Fedora Extras

by Fernando Lopez-Lezcano

On Sat, 2006-05-06 at 12:25 -0700, Anthony Green wrote: > [MUNCH] > PlanetCCRMA? The Extras contributor infrastructure is stable and easy > to use. There's also been discussion of creating an Audio SIG for > Extras (with our own list, wiki site, etc). What do you think? At least the list is already there: Fedora-music-list mailing list Fedora-music-list(a)redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-list -- Fernando

18 years, 1 month

1
0
0 / 0

Re: [PlanetCCRMA] Fedora Extras

by Fernando Lopez-Lezcano

On Sat, 2006-05-06 at 12:25 -0700, Anthony Green wrote: > Hi Fernando, > > Andy Shevchenko submitted jack-audio-connection-kit to Fedora Extras > for review a few weeks ago. I didn't see much happening on the > PlanetCCRMA FC5 front, so I subsequently submitted a collection of audio > apps: http://people.redhat.com/green/FE/FC5/ . These are virtually all > updates of your PlanetCCRMA packages (updated upstream sources, spec > files changes for FE compatibility, etc). Oh well, he/you could have copied me, I guess. I _am_ actively working on packages, same thing (new versions, etc, etc). Which spec files have you worked on? Furthermore, I've been emailing with Greg DeKoenigsberg (he's part of the Fedora Extras steering committee) and he set up a mailing list of people interested in getting Planet CCRMA to be a part of Extras... you could also take a look there. > A few months ago there was a discussion on this list about moving some > packages from PlanetCCRMA to Extras. I took the JACK submission as a > cue and started submitting. Sigh, I was not aware that Jack had already been submitted. I have been terribly busy ('till last weekend) and just now I'm having some time to restart work on this. > I believe there's a group of people interested in helping maintain > audio apps in Extras. What is your position on this now? No problem at all. The more people that participate the better. It'd be nice to be aware of what's happening. > I just read your recent post about starting to work on the FC5 > PlanetCCRMA. If I may be so bold, why not use this opportunity to push > apps/libraries into FE, while maintaining the custom kernel in > PlanetCCRMA? The Extras contributor infrastructure is stable and easy > to use. There's also been discussion of creating an Audio SIG for > Extras (with our own list, wiki site, etc). What do you think? As I said, no problem. But I would appreciate if people don't reinvent the wheel and create specs from scratch given that they are available from Planet CCRMA (and I have worked on them for so long). I have to become a member myself of Extras contributors and was hoping to do that "real soon now". -- Fernando

18 years, 1 month

1
0
0 / 0

[Fwd: [PlanetCCRMA] Planet CCRMA menu tree for fcx] (fwd)

by Greg DeKoenigsberg

Check this. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- ---------- Forwarded message ---------- Date: Tue, 02 May 2006 23:08:19 -0700 From: Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> To: Greg DeKoenigsberg <gdk(a)redhat.com> Cc: nando(a)ccrma.Stanford.EDU Subject: [Fwd: [PlanetCCRMA] Planet CCRMA menu tree for fcx] Just to keep you up to date on relevant stuff... (let me know the moment I send too much stuff to your account :-) -------- Forwarded Message -------- From: Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> To: planetccrma(a)ccrma.Stanford.EDU Subject: [PlanetCCRMA] Planet CCRMA menu tree for fcx Date: Tue, 02 May 2006 22:50:15 -0700 Hi all... I'm starting work on the Planet CCRMA menu tree for fc5[*] - which will later percolate to previous fc versions (I think I know now what I need to do, at least on fc5, some tests today were successful). It used to be (in fc3) that the menu tree _and_ the desktop entries were all part of the Planet CCRMA menu packages. There were several reasons for this, but all (I think) are historical at this point (mainly because I started working on the menus long after I released the packages and I did not want to rerelease everything just to fix them). It makes sense now to fix this before starting to release more stuff (the "menuable" packages I released are not that many so far), and incorporate the categories into the .desktop files included in the packages themselves. The way this would work is that the most important or unique packages (good luck defining what that is!) would show up automatically in the "Sound and Video" menu, and those, and the rest, would be (more or less) neatly organized in the Planet CCRMA submenu tree. If the "planetccrma-menus" package is not installed you would just get the "Sound and Video" menu with the crucial packages there. There are two aspects to this, one is how to split apps into categories, and the second is what visible names to give the categories. Things can be fixed later but the internal category names in the .desktop files will stay for a while, I imagine. Anyway, a good start is better than nothing. So it would be good to take a look at the old tree to see how it looks today, so, this is what I used to do (comments through the list, "_" would be transformed into " " for the menu text): ALSA_Mixers (probably should be changed to just "Mixers"?, hmm, or "Soundcard control"?, this includes general purpose mixers like gamix and card specific programs like echomixer, hdspmixer, envy24control, etc) Digital_Processing Drumming DSSI_Plugins Graphics Jack_Apps (maybe a better name would be just "Jack"? or "Jack_and_friends"?) LADSPA_Plugins MIDI (sequencers _and_ midi utilities) Miscellanea Multitrack Notation Patch_Bays Players Programming Recorders Sequencers (maybe "Sequencers" is redundant given that we have midi already?, not to my eyes at least for now) Sound_Editors Synthesis (should this be part of "Digital Processing"?) System (this should probably go, it contained only "Synaptic" - which really does not belong there - and I can't think of anything else that belongs here) Trackers Video ("Video" could be split, I guess, but that could be done later) [maybe another category for "measuring instruments"? Like jaaa, japa, kmidimon, etc?, can't think of a proper name for that] Each one of the submenus has entries for starting up the app, and then two additional submenus, one for documentation (with links to the online web pages for each program and local documentation when available), and another one for "extra" applications that could be bumped from the main submenu into the subsubmenu. The submenus don't appear if there's nothing in them. In some occasions there could be documentation links and _no_ entry for the program itself, a perfect example is ecasound. It is a command line utility but very very useful. Having it in the menu somewhere is good because it raises awareness of the program for users that don't venture to the command line. I used to have also another submenu for popping up man pages, probably overkill (and something that could be added later). Applications can map into more than one category of course, I'm attaching a file that has a dump of what my old script created so that you can see what I mean. Some examples: ardour:Jack_Apps ardour:Multitrack ardour:Recorders or should we have an "Audio Workstations" category, whatever that means? rosegarden4:MIDI rosegarden4:Notation rosegarden4:Sequencers zynaddsubfx:Jack_Apps zynaddsubfx:MIDI zynaddsubfx:Synthesis freqtweak:Digital_Processing freqtweak:Jack_Apps libfishsound:Programming libgig:Programming liblo:Programming liblrdf:Programming liblscp:Programming liboggz:Programming ... and more ... Anyway, you get the idea. Obviously any categorization will leave someone unhappy but it is better to have something rather than nothing (as is proven by the humongous "Audio and Video" menu in fc4). I'll move fast on this as it has to be somehow solved before I start releasing more packages for fc5 (each package will have the category names hardwired into its .desktop file). One more problem is the contents of the .desktop entries themselves. Usability is not always a priority for linux audio software developers :-) Some packages, if not started with the proper command line incantation just die without warning and that's not good. For example, Jack clients. Some pop up a window and say something if Jack is not already running, others just die and print something to stderr, which will mean that if you start them from a menu you don't see anything. When I generated the Planet CCRMA specific .desktop entries separately from the packages this was less of a problem as I could, for example, make the command line "qjackctl /usr/bin/ardour" in the .desktop file and then qjackctl would first start jack and then spawn ardour and everyone would be happy. A second invocation of a different program from the menu, for example "qjackctl aeolus -J" would find the first instance of qjackctl and then just start aeolus, etc, etc. But this all predicates on qjackctl being there already, which you could mandate through explicit "Requires:" in the packages, but that's certainly overkill (there's no real need for qjackctl to be there, you could be starting Jack in a terminal and all Jack clients would be perfectly happy!). So I feel inclined to just assume that Jack is actually running (for programs that are Jack clients, of course) and just add the command line switches that some programs need to tell them they should use Jack. That can/will break using those programs from the menu with just ALSA, for example. But well, you can't have everything. Otherwise those programs will break when trying to use Jack. Tricks can be done with scripts so that they capture stderr and pop up a window with its contents when the program exits with an error code but then you have to either include the script everywhere or test for it or whatever and again everything is more complicated which is bad. Anyway, that would be a band-aid and not a cure (which would be to fix the program so that it does reasonable things when run from a menu). Enough for now. Wow, this was long... anyone still reading? :-) Any thoughts? -- Fernando

18 years, 1 month

1
0
0 / 0

[Fwd: [PlanetCCRMA] fedora core 5 support: a start]

by Fernando Lopez-Lezcano

FYI: Just sent to the Planet CCRMA lists... -------- Forwarded Message -------- From: Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> To: planetccrmanews(a)ccrma.Stanford.EDU, planetccrma(a)ccrma.Stanford.EDU Subject: [PlanetCCRMA] fedora core 5 support: a start Date: Tue, 02 May 2006 11:43:39 -0700 Hi all and thanks for the patience :-) Here's a start, a few Planet CCRMA packages for FC5. This of course does not mean you should install FC5 right now, but if you can't wait and want to try some things out (I know many of you have _already_ installed FC5 :-) then this is a beginning... but only for good sports, as Bill Schottstaedt would say... [BTW, FC4 users, don't despair, all these shiny new versions of packages should percolate to previous FC versions soon] So... Planet CCRMA on FC5 is yum based. First thing to do after installing fc5 is: rpm -Uvh http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/5/i... (wow, that's a long url...) This will install a yum configuration file that points to the Planet CCRMA repositories (two of them right now), plus a mirror of Fedora Extras. At this point Planet CCRMA depends on Extras, so that has to be there. There are also pointers to updates and the core os but those are disabled by default. You can edit this file and enable them if you want: /etc/yum.repos.d/planetccrma.repo Plus you can look at the existing packages here, courtesy of repoview: http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/5/i... http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/5/i3... You probably should edit another yum preference. By default (out of the box) yum keeps just the last two kernels installed. If experience is any guide you will want to keep more of them. Edit this file and disable this plugin: /etc/yum/pluginconf.d/installonlyn.conf After that you will manage kernels and decide which to keep and which to erase. To install the latest and greatest kernel: yum install planetccrma-core-edge or yum install planetccrma-core-edge-smp (for a multiprocessor kernel) This will get you (today) 2.6.16.9 plus Ingo Molnar's realtime preemption patch 2.6.16-rt17 configured as PREEMPT_RT (the best option but the most "bleeding edge"). This was all done on top of Fedora's 1.2080 kernel - a pain because I had to tweak Ingo's patch a bit, and hopefully that was done correctly. It should have the good side effect of being closer to the configuration that Fedora chooses, that is, should be a little bit more compatible with FC than plain vanilla 2.6.16.x (as I used to do before). Remains to be seen how long I'll be able to do this. One more difference (for gurus), I have built these kernels with 4KSTACKS=n - there were a couple of stack overflows with that on and the realtime preempt patch. A notch down in performance is: yum install planetccrma-core or yum install planetccrma-core-smp That will get you the same thing as the previous one but with Ingo's patch configured as PREEMPT_DESKTOP. It may help when PREEMPT_RT does not work on your hardware. Both selections will bring in some additional goodies as usual. Those include 1.0.11 final ALSA kernel modules, ALSA firmware, tools and oss packages, the rtirq script that optimizes IRQ priorities for best realtime sound performance and a patched PAM that will give you complete access to SCHED_FIFO for best performance, and the ability to hang the machine as well :-) Current kernels are named: kernel-2.6.16-1.2080.13.rrt.rhfc5.ccrma.i686.rpm for the PREEMPT_RT one, and kernel-2.6.16-1.2080.13.rdt.rhfc5.ccrma.i686.rpm for the PREEMPT_DESKTOP kernel (and the smp and i586 variations as well) There are some music packages, after all the kernel should be invisible and does not make music (unless you try to old trick of cat'ting the kernel image to a sound device... turn down the volume first! :-) Currently: jack 0.101.0-0.2.cvs qjackctl 0.2.20-1 liblrdf 0.4.0 (and raptor 1.4.9) lash 0.5.1 fluidsynth 1.0.7a-1 qsynth 0.2.5-1 ardour 0.99.3-1 I build the CAPS LADSPA plugin collection but it has a problem with selinux - for some reason Ardour is not allowed to load them, sigh, I still have to do research on this so I'll wait a bit before releasing them. I'll see if that also happens with other plugin collections... If you like to excersice the mouse you can try installing yumex for something similar to good 'ol synaptic. More packages will be forthcoming... Enjoy! -- Fernando _______________________________________________ PlanetCCRMA mailing list PlanetCCRMA(a)ccrma.stanford.edu http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma

18 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

music May 2006