Just been taking a metaphorical chainsaw to my inbox and got through to the Fedora Music list at long last.
I've packaged up some bits and bobs and assisted with Fedora myself, for better or for worse. Anyway, this thread makes me think a couple of things that I'd like to throw in for the masses (nor not, as the case may be) to chew over.
- Couldn't this lot be done as a yum 'Group' or several? With that then incorporated into the standard installer environment?
- Then I think, ah, wrong kernel, and pulseaudio? But that could be grouped too, no? Have, say, Jack and have it conflict with pulseaudio somehow?
- Then it all sounds a bit complicated, and I can't help think that maybe a respin is a valid and sane way forward.
- But still, it might be nice to give the non-pro users a leg-up to that sort of stuff with package groups in Yum anyway? Surely you don't need an RT kernel unless you're really hammering at the audio?
- Having better documentation would be really good, and I've noted the "Musicians Guide" on my travels, which I fully intend to real real soon now(tm).
- Every person who's into pro audio that I mention about Linux audio says "ah, but will it accomodate my XYZ plugins/filters from a.n.other windows app"? As far as I know the answer is usually "yes", but I hope that's documented in wherever the docs are.
I'll gladly put in such time as I can find to make this happen, and if necessary to get it documented as well, because I want to start using all my kit properly through Linux, with the minimum of fuss (there was a lot of fuss the last time I had a go, in spite of PlanetCCRMA and other's best efforts...), help other people at the same time, but perhaps mainly, get some distractions from my day job which involves Linux too.
Another thing it would be nice to have is a way to use my laptop running Linux for dj-ing if I'm feeling extremely lazy on a given night (I'm not a laptop DJ when I do so, but others are, and, hell, CD's are heavy, physically as well as at times musically), but I could not find a suitable app for that. Rhythmbox has a cross-fade feature, but it's a bit "brute force" and not very nuanced.
If this helps, or provokes discussion in any way, then that's great, and if someone can help me with any of the above questions, that's perhaps even better.
Yours,
Kev "Kyrian" Green.
On 02/21/2012 09:07 PM, Kyrian wrote:
Just been taking a metaphorical chainsaw to my inbox and got through to the Fedora Music list at long last.
I've packaged up some bits and bobs and assisted with Fedora myself, for better or for worse. Anyway, this thread makes me think a couple of things that I'd like to throw in for the masses (nor not, as the case may be) to chew over.
- Couldn't this lot be done as a yum 'Group' or several? With that then
incorporated into the standard installer environment?
Absolutely, that's been something I proposed a little earlier. I'm not sure exactly what this entails, but I envision that once the default set of audio packages have been decided we will submit something to be included in the comps file [1]
- Then I think, ah, wrong kernel, and pulseaudio? But that could be
grouped too, no? Have, say, Jack and have it conflict with pulseaudio somehow?
Pulseaudio is proving to be a pain. Its now an implicit dependency of the default desktop (GNOME) which is unfortunate. Having said all that, I think its a great piece of software, but creates unnecessary complications when all you want to do is create/produce and edit music. There are some applications which refuse to play with anything else now (skype anyone?) that mean people like me have no choice but to coexist with it. I'm still not happy with my setup - other users on this list have also posted their solutions [2]. I think we should aim to ship a pulseaudio-less solution. This means we need to decide on a desktop that's not Gnome - of course that won't make everyone happy, but if we have the comps group like you suggest, those gnome users can still pull in the audio packages with ease.
- Then it all sounds a bit complicated, and I can't help think that
maybe a respin is a valid and sane way forward.
I think most pro/semi-pro audio users in Fedora probably can get a Fedora installation from scratch to a fully workable installation with little effort. The main focus of the spin should be to cement the community around Fedora audio by attracting new users and give us a stronger sounding voice moving forward.
- But still, it might be nice to give the non-pro users a leg-up to that
sort of stuff with package groups in Yum anyway? Surely you don't need an RT kernel unless you're really hammering at the audio?
- Having better documentation would be really good, and I've noted the
"Musicians Guide" on my travels, which I fully intend to real real soon now(tm).
I'm extremely impressed with this documentation thus far - its a real strength that we need to capitalize on.
- Every person who's into pro audio that I mention about Linux audio
says "ah, but will it accomodate my XYZ plugins/filters from a.n.other windows app"? As far as I know the answer is usually "yes", but I hope that's documented in wherever the docs are.
Look there's some really exciting plugins, opensource and commercial alike which run really well on Linux. I'd like to get the TAL audio NATIVE linux VST plugins packaged at some stage for example. Hopefully Ardour3 will be realized in the next cycle which will give us another viable host.
I'll gladly put in such time as I can find to make this happen, and if necessary to get it documented as well, because I want to start using all my kit properly through Linux, with the minimum of fuss (there was a lot of fuss the last time I had a go, in spite of PlanetCCRMA and other's best efforts...), help other people at the same time, but perhaps mainly, get some distractions from my day job which involves Linux too.
For those packagers out there I need help getting my stuff reviewed. Any packager can review - if you're not a packager and are keen, there's plenty of packages in CCRMA that can be moved over. Fernando's done all the hard work, just need minor adjustments to Fedora's latest (ever-changing) package policies. My stuff awaiting review here [3]
Another thing it would be nice to have is a way to use my laptop running Linux for dj-ing if I'm feeling extremely lazy on a given night (I'm not a laptop DJ when I do so, but others are, and, hell, CD's are heavy, physically as well as at times musically), but I could not find a suitable app for that. Rhythmbox has a cross-fade feature, but it's a bit "brute force" and not very nuanced.
Mixxx is available on rpmfusion only at this stage - another libmame (MP3) dependancy. I'm not sure how big an audience it would have without MP3 support though. Perhaps someone else can comment here [4]
If this helps, or provokes discussion in any way, then that's great, and if someone can help me with any of the above questions, that's perhaps even better.
Thanks for the interest!
Yours,
Kev "Kyrian" Green.
[1] http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_grou... [2] http://lists.fedoraproject.org/pipermail/music/2011-December/000890.html [3] https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&classifica... [4] http://www.mixxx.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/21/2012 03:51 PM, Brendan Jones wrote:
On 02/21/2012 09:07 PM, Kyrian wrote:
...
- Then I think, ah, wrong kernel, and pulseaudio? But that could
be grouped too, no? Have, say, Jack and have it conflict with pulseaudio somehow?
Pulseaudio is proving to be a pain. Its now an implicit dependency of the default desktop (GNOME) which is unfortunate. Having said all that, I think its a great piece of software, but creates unnecessary complications when all you want to do is create/produce and edit music. There are some applications which refuse to play with anything else now (skype anyone?) that mean people like me have no choice but to coexist with it. I'm still not happy with my setup - other users on this list have also posted their solutions [2]. I think we should aim to ship a pulseaudio-less solution. This means we need to decide on a desktop that's not Gnome - of course that won't make everyone happy, but if we have the comps group like you suggest, those gnome users can still pull in the audio packages with ease.
Something about this seems off.
I remember when it used to be the case that audio cards generally wouldn't work by default in Linux. Slowly, eventually, PulseAudio solved that. If we remove PulseAudio, we're forcing our users to "go it alone." Now, I understand that PulseAudio isn't ideal for audio creation software--that's why it uses JACK--but we don't want to throw away everything that PulseAudio gained. And surely we want to allow people to use GNOME if they want. And Skype. Otherwise we risk running into a situation where people enjoy using the Fedora Audio Spin for audio-creation tasks, but can't stand it for anything else.
Recent versions of JACK cooperate better with PulseAudio. Maybe what we need is the PulseAudio-->JACK output sink enabled by default. As you noted, Simon Lewis recently posted a possible procedure to this list.
Christopher.
On 02/21/2012 10:00 PM, Christopher R. Antila wrote:
On 02/21/2012 03:51 PM, Brendan Jones wrote:
On 02/21/2012 09:07 PM, Kyrian wrote:
...
- Then I think, ah, wrong kernel, and pulseaudio? But that could
be grouped too, no? Have, say, Jack and have it conflict with pulseaudio somehow?
Pulseaudio is proving to be a pain. Its now an implicit dependency of the default desktop (GNOME) which is unfortunate. Having said all that, I think its a great piece of software, but creates unnecessary complications when all you want to do is create/produce and edit music. There are some applications which refuse to play with anything else now (skype anyone?) that mean people like me have no choice but to coexist with it. I'm still not happy with my setup - other users on this list have also posted their solutions [2]. I think we should aim to ship a pulseaudio-less solution. This means we need to decide on a desktop that's not Gnome - of course that won't make everyone happy, but if we have the comps group like you suggest, those gnome users can still pull in the audio packages with ease.
Something about this seems off.
I remember when it used to be the case that audio cards generally wouldn't work by default in Linux. Slowly, eventually, PulseAudio solved that. If we remove PulseAudio, we're forcing our users to "go it alone." Now, I understand that PulseAudio isn't ideal for audio creation software--that's why it uses JACK--but we don't want to throw away everything that PulseAudio gained. And surely we want to allow people to use GNOME if they want. And Skype. Otherwise we risk running into a situation where people enjoy using the Fedora Audio Spin for audio-creation tasks, but can't stand it for anything else.
I tend to agree with this if for slightly different reasons. It would be an opportunity to squash any bugs that still make PulsAudio less than usable.
And add the right configuration files for high channel count soundcards (Envy24, RME, etc) so they can be used with PA. And add them to either to PA or to ALSA, I don't care, they both keep pointing fingers at each other and nobody solves the problem (maybe we could add this to the wish list?).
But of course that requires a lot of testing and manpower.
Recent versions of JACK cooperate better with PulseAudio. Maybe what we need is the PulseAudio-->JACK output sink enabled by default. As you noted, Simon Lewis recently posted a possible procedure to this list.
There should be a way to turn this on and off easily and at will but I personally don't think it should be on by default.
My normal usage of Linux for audio work pretty much requires that the connection between PA and Jack not exist by default. I would not want random system beeps or web page sounds to intrude into a recording session or concert performance. At other times that might be desired or required. But the default should be off.
At some point the early history of PA+Jack integration, when it still did not quite work (Fedora 10?), I had a perl script that wrapped Jack and could optionally start the Jack sinks and sources automatically after the Jack startup process, but I never made that the default action.
-- Fernando
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/22/2012 02:00 AM, Fernando Lopez-Lezcano wrote:
...
Recent versions of JACK cooperate better with PulseAudio. Maybe what we need is the PulseAudio-->JACK output sink enabled by default. As you noted, Simon Lewis recently posted a possible procedure to this list.
There should be a way to turn this on and off easily and at will but I personally don't think it should be on by default.
My normal usage of Linux for audio work pretty much requires that the connection between PA and Jack not exist by default. I would not want random system beeps or web page sounds to intrude into a recording session or concert performance. At other times that might be desired or required. But the default should be off.
...
-- Fernando
You're right. I didn't think of this situation because I tend to engage with PulseAudio apps.
CRA
On Wed, Feb 22, 2012 at 12:00 AM, Christopher R. Antila crantila@fedoraproject.org wrote:
Recent versions of JACK cooperate better with PulseAudio. Maybe what we need is the PulseAudio-->JACK output sink enabled by default. As you noted, Simon Lewis recently posted a possible procedure to this list.
There's two scenarios here:
1) A single sound device, namely onboard audio. Jack and PA need to get along somehow.
2) A dedicated pro audio device (RME, Focusrite, M-Audio, etc) along side the motherboard/laptop audio. PulseAudio works the onboard audio for system beeps and boops and keeps its dirty mitts off the pro device, leaving it dedicated to Jack.
These are the two main scenarios that must Just Work somehow.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Responses in-line.
On 02/21/2012 03:07 PM, Kyrian wrote:
Just been taking a metaphorical chainsaw to my inbox and got through to the Fedora Music list at long last.
Metaphorical chainsaws are generally much safer than real ones.
...
- Couldn't this lot be done as a yum 'Group' or several? With that
then incorporated into the standard installer environment?
Good idea! And, without much knowledge of how packaging works, I don't think your other thoughts below pose a problem. Most importantly, I don't think a yum Group would make a Spin irrelevant. When you come right down to it, the Spin is a marketing tool to say "we're Fedora and we're ready for action!"
...
- Every person who's into pro audio that I mention about Linux
audio says "ah, but will it accomodate my XYZ plugins/filters from a.n.other windows app"? As far as I know the answer is usually "yes", but I hope that's documented in wherever the docs are.
Nope.
I'll gladly put in such time as I can find to make this happen, and if necessary to get it documented as well, because I want to start using all my kit properly through Linux, with the minimum of fuss (there was a lot of fuss the last time I had a go, in spite of PlanetCCRMA and other's best efforts...), help other people at the same time, but perhaps mainly, get some distractions from my day job which involves Linux too.
It seems like two things help avoid fuss: 1.) Bug-testing 2.) Documentation
As Brendan said, most of the work is probably not directly involved with packaging/compiling/composing the Spin. For small communities like ours, responsible testers are very important.
It's kind of strange when you think about it, but one of the most helpful things is to just use the available software, and to report bugs when you find them. With a particular emphasis on testing packages new to the updates-testing repository. And when something either doesn't work or doesn't work easily, then say so: file a bug against the software or the documentation. Maybe it's an upstream problem, but the Fedora policy is to start in the Red Hat Bugzilla.
Contributing to documentation is easier than you might think. If you're serious about it, go ahead and join the Docs Project--everybody's very helpful. But if you just want to write about something (like audio plug-ins!) without committing to learning all the tools, do this: 1.) Write about it. 2.) File a new bug in Bugzilla against the Musicians' Guide. 3.) Attach the new section you wrote. 4.) Receive comments and revise if necessary. 5.) Watch it get published in the next release.
Also, you could try testing the documentation. I wrote most of the procedures with Fedora 13, about Fedora 14. Do they still work? I don't know. But I discovered lots of *software* bugs along the way, too.
Welcome to the team!
Christopher.
-
Brendan Jones -
Callum Lerwick -
Christopher Antila -
Fernando Lopez-Lezcano -
Kyrian