Brainstrorming for Ubuntu Studio 13.04 (Blueprints)

[Kaj Ailomaa]

On Sun, 21 Oct 2012 01:42:15 +0200, ttoine <ttoine at ttoine.net> wrote:

> 2012/10/20 Len Ovens <len at ovenwerks.net>:
> Documentation:
>  - I think I can find some time to work on documentation, for audio
> recording, and publishing (I know very skilled people), and basic
> documentation for the other workflows (I don't know well video and
> graphic production). As a beginning of each workflow, we can make a
> resume of every applications used, what are they used for, and what
> is/are their equivalent in Windows or Mac worlds (of course when
> possible).

That's great. I took the role as documentation lead since last cycle, so  
please contact me about adding work to any "official" documentation. Just  
so that we can keep track of who is doing what, etc.
Here's a barebone for user docs in the community wiki (very sketchy)  
https://help.ubuntu.com/community/UbuntuStudio/UserGuide. We might add  
this to the home page, when done (it has been under discussion on IRC).
Here's an intro to Ubuntu Studio audio I did before 12.04 release  
https://help.ubuntu.com/community/UbuntuStudio/ProAudioIntro/1204. Needs  
to be improved a lot, and added to the user docs.

>  - We should have a place about "hardware choice" depending on the
> workflow: where to check that a hardware will work with Ubuntu Studio,
> and Linux in general. And second point, we should make some advice
> section about hardware. I don't mean about performance and what to
> buy, but about what we know that works well. Example: Texas Intruments
> firewire chipsets works well when Via ones are not very stable with
> Linux, etc... it will avoid users spending too much time on forums,
> Google, etc...

On this point, I believe the best strategy is to point to other, already  
existing sources (to save time). As I did here:
https://help.ubuntu.com/community/UbuntuStudio/SupportedHardware (the  
intro to audio guide also points here with links)
Of course, nothing stops us from creating our own HW matrix. I guess, in  
pro audio world, there aren't that many devices to keep track of anyway,  
so if anyone has the energy to do this, it might actually not take forever.
But there are other types of HW to for other workflows, like scanners. And  
I know there are good lists for them out there.


>  -  I don't think we should re-invent the wheel and develop a jack
> setup in -controls. Qjackctk is a good GUI, and perhaps we should just
> write a good howto, with general information, some tweaks, and, of
> course, screen captures!
>

This is something that I've proposed to add to ubuntustudio-controls, but  
not to replace any existing jack control applications.
I've been meaning to develop -controls, and if I do, I will make two  
versions. One for Debian, and another for Ubuntu Studio(different names).  
The Ubuntu Studio version would adress Ubuntu Studio specific issues,  
while the Debian version could be more progressive and have more features.

Also, hopefully falktx will be pushing his own applications into Debian  
soon. We should try those out and see how we can use them with Ubuntu  
Studio during next cycle.

> Improving performance:
>  - It is a good thing, but is it really needed for other workflow than
> audio ? The same question for -controls ? So for me this is the same
> point. Some interesting documentations about that are here :
>   + http://wiki.linuxmusicians.com/doku.php?id=system_configuration
>   + http://subversion.ffado.org/wiki/IrqPriorities

We have been using those as reference when doing testing, all though,  
there's more testing needed to get good data.
Since the current devs are mostly into audio, we tend to focus on audio  
first. But we never want to sacrifice other workflows.


>  - Maybe it would be possible to use
> https://code.google.com/p/realtimeconfigquickscan/ and to create a
> script that would apply recommendations ? Maybe could we use it in
> -controls ?

One idea for -controls is to have a startup script to check the system  
status, and tell the user if something is not optimal. This could be  
developed by anyone, and wouldn't need to be combined with -controls.

>
> Ubuntu Studio Artwork
>  - Do we really need to spend too much development time on artwork ?
> Maybe we can first focus on making it working well. And then, if their
> is some time left, on themes, etc... Imho, starting from a vanilla
> Ubuntu or a Vanilla Xubuntu is the better way to save time, and we
> should only change the background, the logo and the minimum stuff: "If
> it works don't fix it".
>  - I am pretty sure that most of users don"t care about theme if it
> works well. And users who want to have a "cool" theme will find a lot
> of stuff on gnome-look.org or xfce-look.org. Maybe we should just use
> a beautiful theme, already available, instead of re-inventig the
> wheel. It would save a lot of time to the dev team.

I think this is the case atm. We don't develop the desktop theme at all.  
We only provide the wallpaper, and a few other things.
We need to make sure any Xubuntu icon is replaced with Ubuntu icons, etc.
But, I think this is up to anyone who would like to work on art. If we  
would have active artists, there would be room for more art. Right now, we  
tend to focus mostly on what there is time for.

>  - For desktop background, maybe we should use the ubuntustudio.org
> website to aks for contributions, and then choose the best one.
>

Good idea. Maybe we should think about highlighting things like that on  
the front of the web page too, so people don't miss it.

> Audio applications
>  - Including LMMS would be interesting. Is there really so many
> problems (licence, etc...) ?
>  - We need to check that ladspa and lv2 plugins are stable before
> including them in the meta packages.

 From what I can tell, there's no problem with licensing. We might just  
need to have a special install procedure, when installing directly from  
ISO. Since the app is so small, I personally don't see why we can't add  
it, as long as someone is prepared to do the work.
IMO, we should adress the VST issue in docs.

>
> That is all I see at the moment.
>
> Toine