Hi Len,
I don't really have much spare time contribute comments here, but for
sure I will try out the ppa sometime soon.
But I just wanted to chip in with some encouragement. I like where this
is going :-)
Regards,
Ross
On 07/12/16 13:53, eylul wrote:
Len,
Lets assume I am an user. :)
I want to create a new boot setup (with system tweaks). I have to set up
the system tweaks, twice on each tab. (or change the boot setup, then be
mystified why settings aren't affected as I change them).
Similarly presets doesn't help me at all, if I want to switch back and
forth between 2 setups.(unless I want a preset change that also affects
audio setup AND tablet setup AND boot setup). I have to change things
manually to use the in session tweaks (and potentially look up every
time what correct setting is).
This is why it is important that the system tweaks are its own profile,
where there can be a default one to use in boot.
Similarly the current preset solution requires me to recreate the audio
setup (and graphics setup) each time I create a preset for any reason.
It makes much more sense for these to have their own profiles, and
having a default one on boot. (then underlying structure can deal with
issues like: does this mean jack is started on boot or not).
Also each of these have different change rates:
* Boot decision is something that will likely rarely change.
* For audio: there might be a couple of profiles that switches back and
forth (for 2 recording setups with different sample rates, or a graphics
or gaming profile that turns off zita to avoid extra processing power
waste. :D)
* Graphic tablet setup on the other hand, ideally changes every time one
switches software! (one of the primary aspects of more professional
tablets is that they have shortcuts buttons on the side and most
artists/designers like to adjust them to various shortcuts by program
basis. Some open source programs do allow their own overrides but not all)
Ralf is right in that too many choices will cause more user problems in
the end, and that the GUI needs to be arranged based on how users
perceive what they are doing, rather than how we know things actually
work under the hood. Some extra options (in this case, under the ability
to create a profile) for advance user will be there but even then it
needs to not assume user knows what happens under the hood.
E.g.: checkbox to change CPU profile to performance: What is my CPU
profile when it is unchecked? (ergo, why I had a drop down menu for
selecting CPU profile in my wireframe).
I hope these are helpful, rather than discouraging. By the way 2
relevant concepts to this design discussions.
https://en.wikipedia.org/wiki/Decision_fatigue
https://en.wikipedia.org/wiki/Pareto_principle (80/20 rule)
I'll try to finish a layout draft based on what you sent, later today. :)
Best
Eylul
On 12/07/2016 08:13 AM, Ralf Mardorf wrote:
Don't try to solve user problems that don't exist!
Consider to join the Ubuntu users and some Ubuntu flavour users mailing
lists.
On Tue, 6 Dec 2016 16:09:39 -0800 (PST), Len Ovens wrote:
Audio setup:
Master audio interface
Second choice master (disable unless master is USB)
sample rate (default to 48000)
On USB Audio plugin set USB AI to jack master enable
Choose if other audio IFs should autorun zita-ajbridge
Jack runs at boot enable (this should be default for Studio)
Apart from the fact, that it might conflict with Linux howtos, a
beginner would be overwhelmed. What is a master interface, what is zita?
What files will be overwritten?
.config/rncbc.org/QjackCtl.conf? /etc/modprobe.d/alsa-base.conf?
/etc/default/rtirq? ...?
Less is more. An advantage of Linux are human readable and
writeable configurations and a good documentation. Another advantage is
that Linux requires some amount of self-responsibility, such as reading
the fine manual.
Constructs like "Second choice master (disable unless master is USB)"
are an indication for a bad GUI running wild.
GUIs not necessarily make things easier for the inexperienced user,
they could make things more complicated.
/etc/init.d/ubuntustudio-controls would be the actual file
that set system things during boot
Ubuntu now only supports systemd and no other init system,
so /etc/init.d is an approach against the Ubuntu policy. Ubuntu
flavours must follow the Ubuntu policy. It is planned to replace all
init scripts by systemd units, not to add additional init scripts. The
latest release even doesn't give the choice between upstart and
systemd anymore, only systemd is available. There still is init script
compatibility, but systemd is not only the default, in addition upstart
can't be chosen anymore, it doesn't exist anymore.
Regards,
Ralf
--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
