Re: [ubuntu-studio-devel] -controls tweaks

[Ross Gammon]

Hi Len,

You are right. My test machine only has motherboard sound, and a USB
device (Alesis iO2) which is very portable (but only 2 inputs at a time).

Most of the time it "just works", and it is only when I fiddle that I
get myself into unusual states :-)

But I will test and report back.

Incidently, we should probably create a suite of manual tests we could
point testers at between now and 20.04 (LTS):
http://packages.qa.ubuntu.com/
We have not used it for a few releases, but it could be resurrected.

Ross

On 4/27/19 9:06 PM, Len Ovens wrote:
> Rather than mucking up the bug comments... Ross, I think that you were
> the one who has only a USB device. In any case, that should also be
> fixed as a part of correcting defaults. please check for this. Removing
> ~/.config/autojackrc should show if th9is is so. you should not have to
> set up USB as master expicitely it should do that on it's own. The jack
> master box should sho USB and the USB master box should show your device.
> 
> In a new install, jack is disabled at boot and in order to start jack
> the user has to open -controls and select start jack. Start jack will
> save the configuration and use it to start jack. This should default to
> using your USB device without you having to select it.
> 
> I can't test this without taking my machine apart and removing cards and
> later reinstalling them. Doing this repeatedly will cause problems
> sooner rather than later as the PCI slots are not high use plugs.
> 
> -- 
> Len Ovens
> www.ovenwerks.net
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
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

[ubuntu-studio-devel] -controls tweaks

[Len Ovens]

Rather than mucking up the bug comments... Ross, I think that you were the 
one who has only a USB device. In any case, that should also be fixed as a 
part of correcting defaults. please check for this. Removing 
~/.config/autojackrc should show if th9is is so. you should not have to 
set up USB as master expicitely it should do that on it's own. The jack 
master box should sho USB and the USB master box should show your device.


In a new install, jack is disabled at boot and in order to start jack the 
user has to open -controls and select start jack. Start jack will save the 
configuration and use it to start jack. This should default to using your 
USB device without you having to select it.


I can't test this without taking my machine apart and removing cards and 
later reinstalling them. Doing this repeatedly will cause problems sooner 
rather than later as the PCI slots are not high use plugs.


--
Len Ovens
www.ovenwerks.net


--
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

Re: [ubuntu-studio-devel] -controls

[Erich Eickmeyer]

If -controls is working in 16.04 and the new version works for 18.04, probably 
best to leave the version in 16.04 alone for manpower reasons.

Just my two cents.

Erich

> On Apr 9, 2018, at 8:57 AM, Len Ovens  wrote:
> 
> Systemd is somewhat of a headache. I have been testing -controls in 1804 and 
> ondemand has been moved to systemd. Not only that, some of the kernel modules 
> don't seem to be loaded before cpufreq runs. I can fix all this stuff but if 
> I do, -controls will be something that works for 1804 but not for 1604. 
> (where the exact cutoff would be I don't know)
> 
> Any opinions as to supporting older versions in -controls, or should we just 
> go forward?
> 
> My thoughts are to move forward as we don't seem to do back ports anyway, so 
> Ardour for 16.04 is still 4.* even though active development is on 6.0. I'm 
> sure other applications are similar.
> 
> --
> Len Ovens
> www.ovenwerks.net
> 
> 
> --
> 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



signature.asc
Description: Message signed with OpenPGP
-- 
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

[ubuntu-studio-devel] -controls

[Len Ovens]

Systemd is somewhat of a headache. I have been testing -controls in 1804 
and ondemand has been moved to systemd. Not only that, some of the kernel 
modules don't seem to be loaded before cpufreq runs. I can fix all this 
stuff but if I do, -controls will be something that works for 1804 but not 
for 1604. (where the exact cutoff would be I don't know)


Any opinions as to supporting older versions in -controls, or should we 
just go forward?


My thoughts are to move forward as we don't seem to do back ports anyway, 
so Ardour for 16.04 is still 4.* even though active development is on 6.0. 
I'm sure other applications are similar.


--
Len Ovens
www.ovenwerks.net


--
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

Re: [ubuntu-studio-devel] -controls

[Ralf Mardorf]

Oops,

iOS Firefox or my providers web interface are responsible for some strange 
sentences.

Corrections:

> On 08 Dec 2016, at 10:01, Ralf Mardorf  wrote:
> 
> Hi,
> 
> especiall user-friendly apps should keep things simple. Don't try to cover 
> all posssible usecases. If somebody wants to use an USB interface, then it 
> doesn't require some ominous secundary master interface. Assuming a user 
> unpluggs an USB audio interface, then the user needs to change the settings, 
> e.g. by using another preset/profile. Its easier to follow a good 
> documentation or to ask in a forum, how to do settings, than to use an app, 
> that conflicts with the common way to set up those things. If you think 
> available common used apps don't cover usecases, its better to report it 
> upstream, than to write an app that conflicts with common used apps. What if 
> a user does add a ferquency scaling tool to the panel? Keep Ubuntu Studio 
> compatible with distros that follow a classic unix alike approach. One app 
> for one task. No fancy GUI, if a scrit
script
> could do. Ubuntu Studio makes already a lot of things very unusual and it's 
> more a mess, than useful. Unusual menues, bizarre sound server defaults. 
> Actually you cover your personal prefferences, not what a majority of user 
> consider as beeing useful. Let alone that you even ignore the way Ubuntu 
> goes, in regards to systemd. Again, don't use init.d anymore, write a systemd 
> unit, this is the official way Ubuntu goes. 
> Even if you think, that the app should cover CPU frequency scaling, than make 
> it a user session setting, not a boot time setting. Assuming a school or 
> public studio provides one machine with several user accounts, they would run 
> in
into
> issues if everyboddy could change boot time settings. If accounds quire
require
> different settings when starting a session, provide
move the auto-start
> your auto-start settings from boot to session auto-start. This would even not 
> conflict with the Debian/Ubuntu CPU frequency scaling startup script. 
> Actially you are writing an app, without thinking about the the structure in 
> the first place. First plan the app, than write the app, don' t mix planning 
> with writing. 


-- 
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

Re: [ubuntu-studio-devel] -controls

[Ralf Mardorf]

Hi,

especiall user-friendly apps should keep things simple. Don't try to 
cover all posssible usecases. If somebody wants to use an USB 
interface, then it doesn't require some ominous secundary master 
interface. Assuming a user unpluggs an USB audio interface, then the 
user needs to change the settings, e.g. by using another 
preset/profile. Its easier to follow a good documentation or to ask in 
a forum, how to do settings, than to use an app, that conflicts with 
the common way to set up those things. If you think available common 
used apps don't cover usecases, its better to report it upstream, than 
to write an app that conflicts with common used apps. What if a user 
does add a ferquency scaling tool to the panel? Keep Ubuntu Studio 
compatible with distros that follow a classic unix alike approach. One 
app for one task. No fancy GUI, if a scrit could do. Ubuntu Studio 
makes already a lot of things very unusual and it's more a mess, than 
useful. Unusual menues, bizarre sound server defaults. Actually you 
cover your personal prefferences, not what a majority of user consider 
as beeing useful. Let alone that you even ignore the way Ubuntu goes, 
in regards to systemd. Again, don't use init.d anymore, write a systemd 
unit, this is the official way Ubuntu goes. 

Even if you think, that the app should cover CPU frequency scaling, 
than make it a user session setting, not a boot time setting. Assuming 
a school or public studio provides one machine with several user 
accounts, they would run in issues if everyboddy could change boot time 
settings. If accounds quire different settings when starting a session, 
provide your auto-start settings from boot to session auto-start. This 
would even not conflict with the Debian/Ubuntu CPU frequency scaling 
startup script. 

Actially you are writing an app, without thinking about the the 
structure in the first place. First plan the app, than write the app, 
don' t mix planning with writing. 


2 Cents,
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

Re: [ubuntu-studio-devel] -controls

[Set Hallström]

On December 7, 2016 5:13:12 PM GMT+01:00, Ross Gammon  
wrote:
>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 

Re: [ubuntu-studio-devel] -controls

[lukefromdc]

The CPU governor is easily controlled in any DE. Ubuntu offers 
indicator-cpufreq, which will also work as a tray applet when not
in Unity. I've used it in MATE, IceWM, Cinnamon, even gnome-shell
so it should have no trouble in XFCE either.  Many DE's offer their
own CPU governor controls (Cinnamon and MATE both do) but 
this one is cross-DE and can be used to set any available CPU
governor as needed. 

I normally turn it all the way up for video rendering due to Kdenlive
slowing on the OnDemand governor and use OnDemand for everything
else.


On 12/7/2016 at 7:16 PM, "Len Ovens"  wrote:
>
>On Wed, 7 Dec 2016, eylul wrote:
>
>> 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).
>
>The boot settings could change the now values as well, that would 
>be easy 
>enough. But the now values do not always want the boot values 
>changed. For 
>example a laptop user may wish to boot without performance to 
>extend 
>battery life only turning it on when needed. A desktop user who 
>does a lot 
>of sw building may like to have boost available for building (15 
>min is 
>better than 20)
>
>> 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).
>
>You want three sets of presets? It is doable I suppose. But if one 
>part 
>stays the same there is no need to change it every time, it will 
>still be 
>there from where the system is now. Maybe I don't understand. But 
>the 
>preset part right now is just a placeholder, it doesn't do 
>anything.
>
>> 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.
>
>I am confused. maybe use exact values/parameter names to explain.
>
>> Similarly the current preset solution requires me to recreate 
>the audio
>> setup (and graphics setup) each time I create a preset for any 
>reason.
>
>Why? Only if it changes.
>
>> 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).
>
>Own profiles? I am not sure what you mean by a profile. Do you 
>mean own 
>tab? Do you want to rearange what is on each tab? That is not hard 
>to do.
>
>> Also each of these have different change rates:
>> * Boot decision is something that will likely rarely change.
>
>So it has it's own tab. It might make more sense for it to be the 
>last tab 
>rather than the first. I am just working from where things were 
>and 
>expanding.
>
>> * 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)
>
>While I understand this is just an example, it is probably best 
>practice 
>to find the rate that works best with your audio interface and 
>record, 
>edit, mix etc. at that rate. At export is the time (not realtime 
>BTW) to 
>decide what SR is right for distribution. In general most audio 
>cards work 
>best at 48000. (the analog filters are set to have the sweet spot 
>there) 
>That aside changing master device for jack is quite common for 
>laptops 
>that use a USB IF at home and mix to internal on the road. 
>Different 
>buffer sizes are also common with a larger buffer for mixdown than 
>for 
>tracking and a smaller buffer than either for live effects or 
>softsynth.
>
>> * 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)
>
>If a tablet shows itself as a file in /dev/input/ it is possible 
>to catch 
>tablet key press events. They could be mapped to whatever. In any 
>case, I 
>would like to add a tablet or graphics tab, but honestly don't 
>know what 
>setting are available let alone which way is which. Someone will 
>have to 
>tell me what they are and I will add them. A bash script or 
>command line 
>examples would be great.
>
>> 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 

Re: [ubuntu-studio-devel] -controls

[Len Ovens]

On Wed, 7 Dec 2016, eylul wrote:


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).


The boot settings could change the now values as well, that would be easy 
enough. But the now values do not always want the boot values changed. For 
example a laptop user may wish to boot without performance to extend 
battery life only turning it on when needed. A desktop user who does a lot 
of sw building may like to have boost available for building (15 min is 
better than 20)



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).


You want three sets of presets? It is doable I suppose. But if one part 
stays the same there is no need to change it every time, it will still be 
there from where the system is now. Maybe I don't understand. But the 
preset part right now is just a placeholder, it doesn't do anything.



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.


I am confused. maybe use exact values/parameter names to explain.


Similarly the current preset solution requires me to recreate the audio
setup (and graphics setup) each time I create a preset for any reason.


Why? Only if it changes.


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).


Own profiles? I am not sure what you mean by a profile. Do you mean own 
tab? Do you want to rearange what is on each tab? That is not hard to do.



Also each of these have different change rates:
* Boot decision is something that will likely rarely change.


So it has it's own tab. It might make more sense for it to be the last tab 
rather than the first. I am just working from where things were and 
expanding.



* 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)


While I understand this is just an example, it is probably best practice 
to find the rate that works best with your audio interface and record, 
edit, mix etc. at that rate. At export is the time (not realtime BTW) to 
decide what SR is right for distribution. In general most audio cards work 
best at 48000. (the analog filters are set to have the sweet spot there) 
That aside changing master device for jack is quite common for laptops 
that use a USB IF at home and mix to internal on the road. Different 
buffer sizes are also common with a larger buffer for mixdown than for 
tracking and a smaller buffer than either for live effects or softsynth.



* 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)


If a tablet shows itself as a file in /dev/input/ it is possible to catch 
tablet key press events. They could be mapped to whatever. In any case, I 
would like to add a tablet or graphics tab, but honestly don't know what 
setting are available let alone which way is which. Someone will have to 
tell me what they are and I will add them. A bash script or command line 
examples would be great.



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


That is what presets are for. Naming the presets so the user can go "that 
looks like the one for me" and be correct most of the time is what I am 
looking for. If we want more than one set of presets for different places 
that is possible. As I have said that is a part I have not started and 
will not be starting till I have mostly done with adding settings.



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).


Len does not care what kind of widgets get used... index 0 or 1 is the 
same as true or false. I just used what was already being used.


My idea for audio is to come up with a default that just works for most 
people (doing audio) along with a preset that allows other user not to 

Re: [ubuntu-studio-devel] -controls

[Len Ovens]

On Wed, 7 Dec 2016, Ross Gammon wrote:

I don't really have much spare time contribute comments here, but for sure I 
will try out the ppa sometime soon.


Hopefully by then I will have more done :) The screenshots are where I 
would like to be :) I have not even started on the Audio tab yet, but the 
other two are just about done.


But I just wanted to chip in with some encouragement. I like where this is 
going :-)


Good. It is similar to Cadence in some ways, but less. I am hoping a 
little better for newbys and the desktop in general.


--
Len Ovens
www.ovenwerks.net


--
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

Re: [ubuntu-studio-devel] -controls

[Ross Gammon]

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

Re: [ubuntu-studio-devel] -controls

[eylul]

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

Re: [ubuntu-studio-devel] -controls

[Ralf Mardorf]

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

-- 
Marge Simpson: We used to call ourselves the Cool Moms.

Bart Simpson: There is nothing cooler than calling yourself cool.

-- 
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

[ubuntu-studio-devel] -controls

[Len Ovens]

Here are some screen shots:
http://i.imgur.com/KvxzXTI.png
(last running version on my system)
http://i.imgur.com/X2lLHujl.png
(latest that I am working on)
I don't know if attachments will make it through but will try:

Not sure why the second is named odd (.png.jpeg) I did screenshot direct
to imgur in both cases and then save image as in both cases. weird.


-- 
Len Ovens
www.OvenWerks.net-- 
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