|Deletions are marked like this.||Additions are marked like this.|
|Line 51:||Line 51:|
|For a full preemption kernel see:
|Line 57:||Line 60:|
|* It would be interesting to compile sample/soundfont packs as packages that would manage themselves properly and integrate into supported applications properly. TJVanslyke|
Please keep these things in mind when choosing a task:
- Do not pick something you cannot follow through on.
- Use only packages in official Ubuntu repositories.
- Ubuntu Studio is Gnome based.
This page will be for people who want to get involved. It will contain a list of items "To Do".
- Create solid package lists for ubuntustudio-settings, ubuntustudio-audio, ubuntustudio-audio-plugins, ubuntustudio-video and ubuntustudio-graphics.
- Create ubuntustudio-desktop package.
- Create website with own forums. (Almost done)
- Create "Alt" install DVD.
Currently Assigned Tasks
- C.Kontros - Organize/Update WIKI, Create list of packages for base of Mubuntu.
- joejaxx - Assist in creation of base packages and test.
HuwWilkins - Create the look and feel of Ubuntu Studio
- NEEDED - Create package lists for: ubuntustudio-audio, ubuntustudio-video and ubuntustudio-graphics. ubuntustudio-desktop-settings and ubuntustudio-artwork will also need work but these are in a state of flux. (I am working on - see the update on the wiki page - I need a bit more time, but I must work on the accounts of my own compagny this week - ttoine)
A Solid Foundation
Biggest contribution we can make to Linux desktop multimedia creation is with integration. Press upstream developers for lash support; that's a big piece of the integration issue.
Do we want to start jackd automatically? This is probably not useful to anyone not doing audio work all the time.
- No. I don't see why we would want that. LASH handles JACK, doesn't it? The only possible reason I could see would be if we can use it as the sound server over everything else (no ESD, no aRtsd, etc), but I don't think that is possible.BR - I think the most important thing is that JACK "Just Works" for users with as little hassel and setup as possible, in true Ubuntu fashion. -Derick_eisenhardt(2006-09-17@23:47CDT)BR - I agree, but I don't know how this will be possible. Everyone has a different soundcard, and JACK itself does no kind of detection of settings. Plus, tons of users in the forums are using on-board crap audio controllers, and they don't generally work well... One set of settings won't work, and we can't possibly guess what will and won't work for every single card. If someone is running an amazing card on an old Pentium 2 system, the settings would have to be different than the same card on a Xeon, for example. Or a dual AMD64 system with on-board sound card is going to be crap too. I think this is part of the reason why JACK itself doesn't auto-config itself. Too many possibilities. We could try with a setting of about 10ms latency, as it should work for most people... But then what sampling rate do you use? People are going to want 48KHz, but some cards only support 44.1KHz... See the problem here?BR - Also, many people will use external soundcards (USB/Firewire). Would these have to be taken over by JACK as soon as they are plugged in? For example, I normally use JACK on my external soundcard, only reverting to the on-board one if I'm on the road. Can such a scheme be accommodated if JACK starts automatically? - RogierVanDalenBR - I suggest that a jack control gui could be launched at startup, but the user has to start jack by himself - ttoineBR - Jack makes quite a demand on the system, so it will be a hindrance on lower powered systems at times when the machine is not being used for realtime music making. So I would be in favour of only starting it when it is needed. -RobertPersson2BR - Well in my experience, the systemload of jackd, if it is not actively working has not too big an impact on the normal work on the box. Still I agree, that the user should absolutely have the possibility to controll the servers behaviour. (I let qjackctl start jackd as it starts with xfce - this works very well. If something is wrong - I'll be informed and if I want to view a DVD with VLC, I can easily switch it off...)-zettberlinBR - As for the jack gui, qjackctl is not bad at all, but it would be really good to have a gtk2-based one. The jack gui for OSX handles netjack, which qjackctl does not. I think that would be an important feature. -RobertPersson2BR - I do not think so at all! There is no way to have a Linux-Sound-Computer without applications from both Worlds: GTK AND QT so wasting effort to alter something as perferct as qjackctl is pointless. -zettberlinBR - jackdmp (multi-processor jack) looks like it will have several advantages over the current jackd, even on single processor systems. http://www.grame.fr/~letz/jackdmp.html
- we must take a decision to go ahead... so what about ? Is it possible to provide different configuration with the different metapackages ? (ttoine)
- If I am not mistaken, Feisty will utilise PulseAudio as its default sound server (http://en.wikipedia.org/wiki/PulseAudio), thus retiring esd and providing low-latency server, possibly without the need for jackd. Has anyone considered it as an option? (petar)
- PA is not as good as JACK ATM. PA is for the desktop and JACK is for pro work. -C.Kontros
- All relevant applications for the musician in Linux work with jackd and some of the most important like Ardour or Muse are exclusively made for jackd - so there is no point in discussing another soundserver... -zettberlin
- This package probably needs to go into Debian, if we want the extra line added to /etc/services (that file is maintained by Debian). I (Forest) currently have the packaging part done. I just need to get it accepted by Debian, and have not been through that process in the past. I also need to chat with netbase maintainers to get /etc/services modified (one additional port for lash -- lashd crashes without it). netbase maintainer: Anthony Towns <ajt AT SPAMFREE debian DOT org>BR - Debian has lashd, as does Edgy. Is this your doing? It still does not work correctly. What do we need to do to fix it?BR - Must we wait for LASH ? can we now provide a working solution with what is available, or for will be for Edgy ? -ttoineBR - LASH is definitely a MUST. I have reached out to the debian maintainer for seq24 and ZynAddSubFX I think to build with LASH support. This won't make it to Edgy I am afraid. And I have had no response yet. -DanaOlson
Kernel with realtime preemption
We have a kernel in Feisty now with PREEMPT enables and 1000mhz timing.
"linux-lowlatency" is the meta to grab to try it out.
For a full preemption kernel see: https://wiki.ubuntu.com/RealTime
Samples / Patches
Mark originally expressed his desire to include a bunch of good free sound files, like samples, SoundFonts, and patches, etc. If we reach out to people who have created soundpacks for the main apps, like Hydrogen, ZynAddSubFX, etc, and any SoundFonts, we might be able to get some together. This can be a longer-term goal.
I would be willing to try to put together a good set of soundfonts for Ubuntu Studio. None of the "free" soundfonts out their seem to be any good. EdwardAmsden
If anyone can find any free instrument samples or wants to make some instrument samples, it would be greatly appreciated. Samples are extremely hard to find. EdwardAmsden
- A good instrument/sample format would be awesome. FLAC compression in the samples, with all the necessary features like envelope and one-to-many sample-to-key mappings. This plus a conversion tool to switch the full-featured instrument to an .ITI or .XMI or such would be very nice.
- It would be interesting to compile sample/soundfont packs as packages that would manage themselves properly and integrate into supported applications properly. TJVanslyke
* I have the ability to create samples/drumkits/etc that are royality free. (I have 5+ years experince in electronic music production)
Contact me: email@example.com if this sounds interesting...
I think that the key to having this a usable system will be to organize the menus properly - music apps, video apps, graphics apps should not be all in one big jumbled mess. I am not familiar enough with the menu system to know the best way to approach it, but a change to every package I think is not required. We can just add additional menu entries or some such.
It is possible to let people organize by themselves with the menu editor of their DE, when provided... Or to make a script that can redifine automatically the .desktop files.BR
Since we are going to use Gnome is the current structure of "Sound & Video" adequate? I dont know if actually splitting the menus into "Sound" and "Video" would help. See [http://img145.imageshack.us/img145/2954/menuaw3.jpg screenshot]. -C.KontrosBR
- Could there not be even further division of menus? For instance, under Sound, there could be even more categories, such as Audio Editors, Mixers, Synthesizers, etc.
Nested menus are evil. I can think of a [http://img102.imageshack.us/img102/8664/gnomenestedmenus3hq.png possible alternate]; but given the above screenshot, this would still look ugly. Perhaps if the categories could be collapsed? --JohnMoser
Sure. If you can do the work to implement it. -C. Kontros
More than 6 items per menu is evil too. Maybe splitting the root menu into more categories? Something like "Recording & Editing", "Synthesis", and "Sequencing." --dPolymeris
- What about desktop folders for each media program category(audio editors, mixers, video programs, etc)? Simply having them there by default could be more accessible and less overwhelming than menus. Also, what about shortcuts/scripts/something that opens multiple programs at once that are likely to be used in conjunction(i.e. some softsynth and a midi sequencer)?Are different preconfigured desktop configurations for different uses (video editing vs. audio recording) possible? --adamC
- Since we folloe the Ubuntu policy of a clean desktop this wont happen. We will be looking into a better menu structure for v2. -C.Kontros.
Dana and I have decided that we are going with Gnome. Demudi did it, so it is possible for us to do it also. With the intensity of the applications that we will be running, fairly current hardware should be used. The specs should be the same as Ubuntu. Therefore Gnome should be a fine choice. Further decisions should be made with using Gnome in mind. The challenge will be retaining the admin functions of Ubuntu's Gnome desktop while trimming down the size of the install disk. Demudi was fairly stripped down in this aspect. Its .iso is 558 megs. -C.Kontros