Re: [LAD] Experience driven design and Linux Audio

2014-10-03 Thread Patrick Shirkey

On Fri, October 3, 2014 7:22 am, Len Ovens wrote:

snip

 SHould Linux target those who only see a comodity? WHo are only looking to
 have what their idol uses? Or who want the cheapest one that works? The
 stuff already out there will be what gets bought. Developing HW with Linux
 is like developing with any other OS, it requires innovation and lots of
 support. The linux HW has to have what nothing else does and the something
 has to be seen as needed. Lets see how the mod duo does.


I have asked people who already have similar gear about the mod boxes and
while they are interested in the platform they are put off by the price. 
Until they reach the economies of scale to be price competitive there will
be a small market. Especially if trying to sell to the existing Linux
peeps who are generally pretty cheap when it comes to actually parting
with their own personal cash. Several people have tried to tap the market
with expensive hardware and had pretty dismal results. However if we look
at the success of the low end DIY market ex arduino, rasp pi, rockchip,
allwinner that is a pretty good success story.







--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-03 Thread Ralf Mardorf
On Fri, 2014-10-03 at 17:09 +1000, Patrick Shirkey wrote:
 On Fri, October 3, 2014 7:22 am, Len Ovens wrote:
 
 snip
 
  SHould Linux target those who only see a comodity? WHo are only looking to
  have what their idol uses? Or who want the cheapest one that works? The
  stuff already out there will be what gets bought. Developing HW with Linux
  is like developing with any other OS, it requires innovation and lots of
  support. The linux HW has to have what nothing else does and the something
  has to be seen as needed. Lets see how the mod duo does.
 
 
 I have asked people who already have similar gear about the mod boxes and
 while they are interested in the platform they are put off by the price. 
 Until they reach the economies of scale to be price competitive there will
 be a small market. Especially if trying to sell to the existing Linux
 peeps who are generally pretty cheap when it comes to actually parting
 with their own personal cash. Several people have tried to tap the market
 with expensive hardware and had pretty dismal results. However if we look
 at the success of the low end DIY market ex arduino, rasp pi, rockchip,
 allwinner that is a pretty good success story.

Whats wrong with the price? Assumed the hardware should be ok and there
would be a sane selection of high quality effects needed by musicians
(instead of hundreds of music pedals [1]), it isn't expensive.

[1] An irritating slogan, I suspect it would be hard just to name 50
effect pedals, let alone hundreds.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-03 Thread Len Ovens

On Fri, 3 Oct 2014, Patrick Shirkey wrote:


I have asked people who already have similar gear about the mod boxes and
while they are interested in the platform they are put off by the price.


compare to this for example:
http://www.zoom.co.jp/products/ms-100bt
$160, but you have to buy new effects... after the first 100 already 
there.



Until they reach the economies of scale to be price competitive there will
be a small market. Especially if trying to sell to the existing Linux
peeps who are generally pretty cheap when it comes to actually parting
with their own personal cash. Several people have tried to tap the market


I did notice they do not seem to be looking at the Linux users market, the 
promo shows the user with an apple product for browsing. The form is 
enough different than the norm that players will recognize it on the stage 
if they see someone else using it. It is very hard for me think like the 
group of people this is/should be aimed at, because I am one of those 
cheap Linux guys. Though of all the kickstarter categories I am most 
attracted to the gift a developer one... even for a gift size bigger 
than the next two categories.


Free and open seem to have almost no meaning/value to those who do not 
already know what that means and value it. Cheap and effective or over 
priced and branded are what seems to be attractive to people. I guess what 
I am trying to say, is that spreading Linux and it's tools is not going to 
be simply adding a nicer/easy UI. Those things will not hurt and besides 
will help those already using the SW.



--
Len Ovens
www.ovenwerks.net

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-03 Thread Ralf Mardorf
On Fri, 2014-10-03 at 17:59 -0700, Len Ovens wrote:
 http://www.zoom.co.jp/products/ms-100bt

Wow! Perhaps shopping new effects isn't that important for many
musicians: http://www.thomann.de/gb/zoom_multi_stomp_ms50g.htm

An advantage of the MOD Duo clearly is, that it's possible to connect
Expression Pedals and a footswitch extensor. OTOH for the low price of
the Zoom effects it's possible to buy several of those devices, this
would have the advantage, that if one device should fail on stage, the
musician wouldn't be completely lost.

The Advantage of the Zooms likely is the compact design, simply replace
one of your Boss boxes in the case with one of the Zoom effects.
Zoom is an established known company, if weak points, such as the
display should fail within the period of warranty, you can assume that
the company still will exists. You can't assume this for new companies.

I suspect that neither all available Linux effects, nor all the Zoom
effects will satisfy musicians, compared to some classic stomp box
effects, but both, a Linux and a Zoom likely could replace some effects.

Btw. I guess I'll order a MS-50G, resp. take a look if there are other
similar products available in this price range. Assumed I should dislike
it at a time when it isn't possible to send it back to the dealer, it
likely would be possible to sell it for half of the price, such a drop
is passable.

Resume: For us it's nice to get a device that is available to use open
source. Is this from interest for a majority of musicians? If not, than
the MOD duo never would become able to compete for the cost. However, if
the MOD duo should really provide something special, that isn't provided
by other products, the price still would be ok.

[snip] Open-source seems like a somewhat dubious format for pedals,
since many cheap digital multi-effects processors already exist and are
generally shunned by people who prefer analog circuitry. -
http://blog.pedalfinder.com/2014/09/443/

There are simply analog devices enjoying cult status for good reasons,
but some of the new digital devices are accepted too, they are not
shunned per se.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Patrick Shirkey

On Thu, October 2, 2014 7:00 pm, Will Godfrey wrote:
 On Wed, 1 Oct 2014 21:40:10 -0700 (PDT)
 Len Ovens l...@ovenwerks.net wrote:

 On Wed, 1 Oct 2014, Paul Davis wrote:

  Here's an interesting counterpoint or follow up point or whatever.
 I've queued it to
  start at the right time, listen till about 31:00 (or longer if you
 want). The key point
  I wanted to highlight was Gerhard's point about saying No to user
 requests. But, being
  Gerhard, he has other interesting points to make as well.
 
  src=//www.dailymotion.com/embed/video/x26axz5?start=1530
 allowfullscreen/iframebr

 An interesting chat. In his case the reasons for saying no to user
 requests might be different, though not by much.

 I also realize maybe I am taking the original question off of what it
 was
 asking. The original talk was about something that is perhaps not
 understandable in the context of creation rather consuming. Many of the
 newer DEs are frustrating for developers (not just SW development), but
 developers even though there are many, are a very small percentage of
 computer users. Most are consumers, games and browsing are almost all
 that
 happens. From that POV win8, unity, gnome3, OSx, Android, etc. all make
 sense. From a developers POV (POV meaning personal use), they don't.
 Someone who is creating music, video or graphics is a developer and
 their
 needs are not the same as the consumer. Once that difference is pushed
 out of the way and one looks at the user experience from a developer's
 POV
 the experience that is expected is different but it is still there.

 snip

 I found myself nodding all the way through this!

 Also, it seems that as time goes by a lot of people are using steadily
 more
 powerful equipment to actually do less! Whether this is what they want to
 do or
 whether it's what the interface *allows* them to do is a moot point.

 As someone who tries to get the most out of anything I use, I find most
 commercial software extremely frustrating in the way it strait-jackets
 users. I
 think this also blocks curiosity and maybe stops more youngsters joining
 the
 creative communities.

 I think this relates back to the topic as in who's experience should lead
 the
 design?


If youngsters are people under the age of, say 25 then, most of them
will be blocked from LAD by not having access to a Linux PC. The ones who
do will mostly be doing academic study, scientific research or working for
governments who have chosen Linux instead of the other options. It's
increasingly unlikely they will have Linux Desktop PC's at home.

Very few new people are taking the time to install Linux OS's on desktop
PC's and the desktop market is in decline for the consumer portion across
the board. The majority of the shift to Unix has been for Android,
ChromeOS, OSX with firefoxOS and Tizen coming closer to fruition each day.
The remaining professional portion of the market which I assume Harry is
targeting for a sustainable income is well and truly in the OSX camp. It's
going to be hard to pull them away from OSX to this OS. Even with really
slick interfaces they generally have a different mindset that defines
their reasoning.

As I was told once. it's not about how much money they can save, but how
much money they can make...

Linux has seen wide adoption in the embedded audio hardware market but
many of the companies that make audio hardware running on Linux systems do
not participate directly here.

So in terms of usability and this discussion the majority of LAD
professionally focused developers are targeting the scientific/academic
markets and embedded hardware markets. In that case usability takes second
place to raw power and functionality.

There is also the web market but I am in a clear minority on the
importance of that round here.



--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Neil C Smith
On 2 October 2014 10:28, Patrick Shirkey pshir...@boosthardware.com wrote:
 the desktop market is in decline for the consumer portion across
 the board.

Assuming by desktop you mean traditional PC market, various news
stories I've read over the last few months would suggest that's not
declining for the first time in years, and potentially even seeing
some growth.

Best wishes,

Neil




-- 
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net

Praxis LIVE - open-source intermedia development - www.praxislive.org
Digital Prisoners - interactive spaces and projections -
www.digitalprisoners.co.uk
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Patrick Shirkey

On Thu, October 2, 2014 7:44 pm, Neil C Smith wrote:
 On 2 October 2014 10:28, Patrick Shirkey pshir...@boosthardware.com
 wrote:
 the desktop market is in decline for the consumer portion across
 the board.

 Assuming by desktop you mean traditional PC market, various news
 stories I've read over the last few months would suggest that's not
 declining for the first time in years, and potentially even seeing
 some growth.


I've seen those reports too. They are optimistic but potential growth is
not the same thing as actually growing. It's more likely to be corporate
buyers replacing existing stock.

The current situation is the consumer desktop PC market when it comes to
audio/multimedia has been decimated by mobile. The Linux Audio Market is
currently doing best in embedded hardware.

If we want to consider Android as a Linux OS then Linux Audio is doing the
best that it has been for years with many companies that have nothing to
do with LAD making a business out of their Android applications.

The corporate market is still there as a potential battle ground and will
probably never go away but getting Linux Audio into the corporate market
is a very tough slog.  Even at companies where they have massive
investments in Linux infrastructure and embedded hardware they are still
using OSX for multimedia production and M$ for general purpose
administration.

It's almost impossible to convince an established Digital Media department
that Linux is an appropriate platform for their team members. Firstly
there is a massive lack of expertise and training. For example, It is very
rare to see a job ad for a multimedia position that uses open source
technology.  The Blender community is making some headway in the training
aspect of the problem but it is slow going. Nearly every professional
multimedia person working in corporate space uses those other tools and
platforms without question.

To change that will require getting into the heads of corporate managers
so they make decisions based on a different set of goals. It's a tough
sell. It will also require students to choose Open Source over proprietary
and that is also a hard nut to crack because the proprietary companies
offer incentives to the HoD's that open source can't match.

Will Linux Desktop professional or consumer multimedia ever become a
growth market? I am not convinced that putting additional effort into
usability is the key to cracking it. IMO there are other issues that need
to be resolved first.

Getting a couple more big names in on the game will be useful too.  I
recall Native-Instruments were on the fence a couple of years back. They
needed more convincing at the time. Maybe they have an update about their
assessment of the current market?

Has anyone here actually tried selling *any* kind of app on the Ubuntu App
Store?

Does anyone have actual data about the amount of people out there who use
LAD tools?

From my perspective the ad hits on LAU Guide are pretty much static after
the past 4 years I am not seeing significant growth or decline month on
month.  One could spin it that we have seen overall growth because it is
unlikely that a lot of the same people would return to the LAU-Guide on a
regular basis. That suggests that there is a reasonable sized potentially
untapped market out there of at least 100k. Who are these mysterious
people and will they spend any money? If I had tracking tags on the site I
might be able to provide more details but I don't.

Until someone nails a mega successful app/model with Linux the other
companies waiting in the wings will continue to dip their toes.


--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Neil C Smith
On 2 October 2014 11:48, Patrick Shirkey pshir...@boosthardware.com wrote:
 I've seen those reports too. They are optimistic but potential growth is
 not the same thing as actually growing. It's more likely to be corporate
 buyers replacing existing stock.

eg. 
http://www.warc.com/LatestNews/News/PC_sales_rebound_in_Western_Europe.news?ID=32866

Would suggest you're correct in being *mostly* about corporate buyers,
but not entirely - still +2% in consumer sales, which isn't declining!

Is that potential growth or actual though?

Still, 88.2% of statistics are made up on the spot :-)

 Will Linux Desktop professional or consumer multimedia ever become a
 growth market?

I'm intrigued to see what effect developments in the gaming arena may
have on consumer Linux usage over the next couple of years, or on
general commercial attitudes in other sectors.

Neil

-- 
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net

Praxis LIVE - open-source intermedia development - www.praxislive.org
Digital Prisoners - interactive spaces and projections -
www.digitalprisoners.co.uk
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Patrick Shirkey

On Thu, October 2, 2014 9:14 pm, Neil C Smith wrote:
 On 2 October 2014 11:48, Patrick Shirkey pshir...@boosthardware.com
 wrote:
 I've seen those reports too. They are optimistic but potential growth is
 not the same thing as actually growing. It's more likely to be corporate
 buyers replacing existing stock.

 eg.
 http://www.warc.com/LatestNews/News/PC_sales_rebound_in_Western_Europe.news?ID=32866

 Would suggest you're correct in being *mostly* about corporate buyers,
 but not entirely - still +2% in consumer sales, which isn't declining!

 Is that potential growth or actual though?

 Still, 88.2% of statistics are made up on the spot :-)

 Will Linux Desktop professional or consumer multimedia ever become a
 growth market?

 I'm intrigued to see what effect developments in the gaming arena may
 have on consumer Linux usage over the next couple of years, or on
 general commercial attitudes in other sectors.


If SteamOS becomes a fully fledged distribution on the scale of
Ubuntu/Fedora then it might have an affect on adoption rates for LAD
software with the young crowd. NVidia is putting a lot of effort into
expanding the use of GPU's with CUDA/OpenCL API's so that might also have
a positive affect on adoption but only if we build the tools to take
advantage of the hardware.

FFMPEG developers are doing a great job of keeping things progressing on
that front. But LAD'ers could do more to build out tools that leverage
GPU's.

We could get some more wind in our sails if some well known
companies/artists/producers actively promoted their support for Linux OS
and encouraged adoption. That has to be a two way street though. For
example famous artists usually give endorsements for something in return.






--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Ralf Mardorf
On Thu, 2014-10-02 at 10:24 +0100, gordon...@gjcp.net wrote:
 Ever wonder why your DX21 has only got eight algorithms by which the
 operators may be combined?  *That's* why.

That's a reasoning just from your point of view, but not the real
reasoning.

Btw. the DX21 provides 4 operators.
But the flagship is the DX7, with 6 operators and 32 algorithms, usually
feedback is given to 1 operator only, but 2 algorithms provide a grouped
feedback and there are various ways how operators modulate other
operators. The reason why it's different for the DX21 are cost concerns.
Programming the DX7 for most users was to complicated, because there
isn't a usable user interface, just a very small display and a few
switches, quasi the Unity of synthesizer user interfaces. A modular DX7
or better DX2014 with cables and potentiometers and programming it would
become enjoyable, but the synth would become much too expensive.

Analogies or comparisons don't work. There are reasons why completely
contrary designs could be as good as the other. There isn't a theory of
everything for functionality of design.

There are no knobs on a piano, but using a piano for me would be much
more complicated, because a normal piano can't be connected to a
sequencer, so playing it for a guitarist like me is hard to do. Why
doesn't a piano provide a neck as a guitar does? I now could make some
reasoning from a guitarist's point of view and ignore the fact that a
piano and a guitar are just different tools for musicians.

Regards,
Ralf

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Len Ovens

On Thu, 2 Oct 2014, gordon...@gjcp.net wrote:


I found Unity to be far, far quicker and easier to get around than anything 
that has gone before.  It took a bit of adjustment after using Gnome 2, but I 
can't see me ever going back.


Good, I have tried it a number of times (every release I install and try 
it) and for me it always ends up being more keystrokes to do anything more 
than use the browser. I know someone who uses the new gnome shell as well 
for music and loves it.


However, I have heard more complaints about both of them than praise. Both 
require an up to date reasonably powerful machine to run. (My P4 box will 
not even start gnome screen and unity barely moves, my 3 year old netbook 
doesn't like either of them either) As such, even something that runs 
these ok may not be able to do the same lowlatency audio that other DEs 
can do on the same machine. In trying to help people do so I have seen 
more people switch than not. Now obviously I won't have tried to help 
those for whom unity has just worked so my POV is bound to be one sided.



As someone who tries to get the most out of anything I use, I find most
commercial software extremely frustrating in the way it strait-jackets users. I
think this also blocks curiosity and maybe stops more youngsters joining the
creative communities.


But that starts to sound like the user arguments that put me off 
developing Linux audio software in the first place.  There seems to be a 
mindset of software shouldn't waste cycles looking nice and being easy 
to use which suggests that things ought to look shite and be difficult 
to use with every conceivable option exposed to the user, because it 
gives them more flexibility.


There does need to be a balance. However, part of the problem is user 
mindset, and here I am talking linux hobby mindset. Many people who use 
linux expect to get away with a lesser machine. The same person will spend 
twice what their computer is worth for an audio IF. Really, if someone is 
serious about music, they need to have reasonable gear. But they shouldn't 
have to have a server class box just so the display can look pretty 
either. If we were truely worried about cpu cycles we would all be using 
NAMA as our DAW with no X running. One of the things I heard from one of 
the videos mentioned was that the UI can influence the music that comes 
out of it. Limitations in the UI can shape the way the music is made. So 
here is another place there needs to be balance.


I don't know how this relates, but It may be interesting to note that I 
have tried LMMS and Bitwig both of which are supposed to be very easy to 
use, but I found them hard to get noise out of at all. Yet I was able to 
use Ardour and have it act as expected from my first use. So obviously my 
head does not work the same as the average musician... and as such maybe I 
should stay as far away from developing anything as I can.


I learned the same lesson myself after coming at it the hard way when I 
wrote an eight-operator FM softsynth where any operator could be routed 
to any other operator (even itself) in a giant matrix of 64 controls.


I think even the 32 setups on the DX7 were more than needed, yet there are 
people who have played with them for years who comment they are still 
learning new things on them. I do not know if two more operators who have 
helped, but having 6 still seems to be better than 4... though 4 with more 
than just sine wave in may be a different story.


Yes, it was extremely powerful and versatile, but actually it turned out 
that this didn't make it useful.  It needed to be *less* powerful and 
versatile to filter out all the useless combinations.  Ever wonder why 
your DX21 has only got eight algorithms by which the operators may be 
combined?  *That's* why.


The dx21 only has 8 because it only has 4 operators. This is math related 
rather than usablity related. I suspect it had something to do with 
production cost as well. I have a 4 operator synth (even cheaper version 
than the 21) and I do not like the sound as much as the DX7 (I have one of 
those too). However the usability angle really shows well here. The DX7 
was not at all easy to program and it showed, it was easy to recognize the 
DX7 in popular music becasue everyone just used the factory defaults... 
good thing they were reasonable defaults for the DX7 would have been dead 
as soon as it came out. Having more operator controls may have helped, but 
the cost would have been a lot more too (the DX1 for example).


The manufacturers have learned from this all and most new synths just have 
presets that eveyone uses. No one creates new sounds on them but rather 
buys them for the sounds that they come with. In the end it has led to 
less experimental music, but there are a lot of other factors that pointed 
that way anyway. The big labels are not interested in music at all, just 
profit. They hire the same producers who use the same sounds that have 
worked 

Re: [LAD] Experience driven design and Linux Audio

2014-10-02 Thread Harry van Haaren
Fons wrote:
 The many times I've had to set a delay time the most convenient unit could 
 have been samples, millisecs or meters (at the speed of sound), depending on 
 the context
Sure, there are uses (particularly your fields of WFS, Ambisonics, and
related) where such uses are prevailent. Aka, context. Musicians are
very rarely in a context when ms, meters or samples is of any
relevance to what they are trying to achieve.

I'm not trying to belittle either use case here: but highlighting that
there are different use cases, and that using tools designed with
units like speed-of-sound-in-air and meters-of-delay are not
usable for musicians. Similarly, I think you'll agree that trying do
correctly compensate for the non-ideal location of a specific speaker
using BPM and 1/4 notes delay time isn't a workflow you'd care for.

Patrick Shirley wrote:
 A way to enhance usability across the board might be to have an app of the 
 week where everyone in the Linux Audio community is encouraged to run it and 
 provide any feedback
I think this is a brilliant idea, and should be done: @Patrick, if you
wish to take the initiative to make this happen, I leave it to you. If
you're not interested in doing it yourself, I would like to pick up
such an incentive.

I'd could only start in a few weeks, and would take a slightly more
relaxed approach app of the month perhaps, and use the projects
bug-tracker for feedback: sending lots of feedback-traffic trough LAU
wouldn't seem appropriate to me.

Paul Davis wrote:
 Link to video
Interesting to see that larger companies and musicians also battle
the same issue, that there isn't any clear consensus on obviously it
should be done this way. Thanks for linking, I hope to watch the whole
clip another time.

Will Godfrey wrote:
 I think this relates back to the topic as in who's experience should lead the 
 design?
Very good point: and something I'd like to address: If I (as OpenAV)
recieved more feedback, I'd have a better idea of what people wanted.
Voicing concerns is hugely important here: hit me with emails /
github-issues if there are specific things you'd like to see change!


General commentary:
I guess that makes it clearer to me, design with experience in mind,
not features.

This is something I think I (as OpenAV) may not have been doing enough
while developing Luppp, and hence am currently re-organizing the
priorities of a live-performance / looping workflow.

Cheers, -Harry
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Florian Paul Schmidt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.09.2014 15:58, Harry van Haaren wrote:

 https://www.youtube.com/watch?feature=player_detailpagev=ldhHkVjLe7A#t=1625

 
 
 To bring this discussion to a productive start, I'd like to
 concider the tools we have available as the linux-audio community:
 they certainly have features, and empower the user to own thier
 tools, and the data used with those tools.
 
 Should we improve experience for users? Should we design
 experience driven open software? Should we forward the UX of
 Linux Audio to the age of experiences?
 
 What do users know, that developers might not? What is it that
 needs to change? Are there even issues here? If so, how do we (the
 community as a whole) try to solve this?
 
 
 I hope this is a productive and inclusive discussion, and politely 
 request remaining on topic ;) To a fruitful discussion, -Harry
 

I was disagreeing with everything he said from the get go (or rather
from the time you linked to). I'm an enthusiast and I don't need shiny
tools and integration. I need well designed (software design,
separation of concern, multiple ways of interfacing, language
bindings, etc.) building blocks to tinker and experiment with.

The one thing that struck a chord though were his last remarks and he
surely wasn't the first to mention those points :) If the open, libre,
software environment doesn't appeal to the non-enthusiast masses, they
are led to the altar of getting their liberties butchered, as is
apparent with modern OSs like OS X and windows, iOS and android and
the popular applications on those platforms.

I'll watch the rest of the talk later, when I'm not busy with getting
food on my table creating non open software on the linux platform ;) I
wonder how he wants to solve problem of funding. Polish and
Integration is a monumental task eating tons of resources. Ain't no
enthusiast got time for that (unless they find a way of financing)..

Regards,
Flo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJUK8UsAAoJEA5f4Coltk8ZlFYH/0KJONGEho+84ZHu7PUrxwJF
R6nK09AlyRlR2Hd/Dq7UP6Mqdr9+sFX6bbZCiQ6QfNtqti+qqdMmrQkfzmOGsgJ/
jBO4M3BU2nS23rQgjSnN/V2O+xejSXZSPTdqf9gepMIqnuEfqxmsqQsg/zvnBzOj
UuSBT+m8zvnrWuUoI3fH2rYFzJBEie70ap4/fzkk+8up4EJ3jjn8Yur087QrTDK+
cq6Jkmzd8waXKXP/g93tWoAW9CDK5f1xx8WIfumpSQdZ6qbj9uaDnAHfW6pMIdJJ
Ma+jLrmObx7y+V0nEyEGCNl041Ekhogrrzn0nfBjlr4rmMOhSvccIvrcauK/BtA=
=VYjt
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Harry van Haaren
Hi all,

There's a lot of interesting points brought up: I've only just had the
time to read them, and reply to the points that most speak to me (the
individual) and me (as OpenAV).

Charles Henry wrote:
 There does not currently exist a company that is credibly making a complete, 
 whole-system design approach to problems such as audio recording and live 
 sound processing.
There are various companies working on this type of integration
though: there are various HW/SW combo that works with a computer, and
integrates very well: sure they're not selling the PC yet: but it
won't be long I think. Actually they're probably working on developing
that right now :D
(example that I worked with http://www.presonus.com/products/StudioLive-16.0.2 )

Charles Henry also wrote:
 To change: incentive structure.  There must be some kind of initiative 
 (non-profit or other organization) that appeals to developers and meets the 
 economic constraints of the world we live in, to be feasible.
Agreed: with my OpenAV hat on, that's something that I'm thinking
about and concidering how I can earn a living somehow by developing
open music software.

Fons wrote:
 there's one significant difference between the users who expect everything 
 (including thinking) to be done for them, and those who are prepared to 
 learn: the latter will say 'thank you'.
Agreed, I also feel that doing the thinking for a user of a piece of
software is not the right thing: I have no issue with a user having to
spend time to learn to use a domain and tool. What I do want to note
here, is that said user should not have to learn an unrelated-domain,
in order to use the software in the target domain.

In my opinion, the learning curve is too steep (or perhaps more
accurately too board) for musicians starting to use linux-audio.

Louigi Verona wrote:
 I will probably record a podcast lil later
Cool, looking forward to your opinion as a user.

Tom wrote:
 Looking at one of the slides.. i find it a strange idea that a CEO would do 
 the (software, UX) design
Indeed: and I don't agree with everything in the talk; this is a good example.

Tom also wrote:
 Hiding behind the term professional to describe software, that is in fact 
 just a cumbersome pile of crap (and thus professional) is another strategy 
 i can observe
It is easy to have bad/overly-complicated workflow in a piece of
software, and call it professional to make up for it. That's pretty
much exactly why I started this thread: thanks for making it obvious
to me :)

Paul Davis wrote:
 it isn't about being a professional or not
In my opinion its about creating software that caters for a workflow,
or use case if that's a term you prefer. This is about designing
software for a particular use-case, and *then* focussing on the
experience while using it.

The talk mentions the age of experience, perhaps I interchange the
word workflow and experience sometimes. A smooth workflow provides
a good experience.

And certain use-cases are catered for very well by certain programs
*features*, but the *experience* or *workflow* of using it is not
something that I feel is somewhat lacking.

Flo wrote:
 I'm an enthusiast and I don't need shiny tools and integration. I need well 
 designed (software design, separation of concern, multiple ways of 
 interfacing, language bindings, etc.) building blocks to tinker and 
 experiment with.
And I understand that there is a need for software to cater for your
use case, or preferred workflow too. That's the lower-left quadrant in
the talk: Open Features-driven tools. Very powerful when in very
capable hands.

Its users who would prefer a smooth experience that do not have
software available to them on linux audio right now. And its designing
and building software in that domain that I'm interested in (both as
me, and OpenAV).

Cheers, -Harry

--

http://openavproductions.com
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Gene Heskett
On Wednesday 01 October 2014 01:04:52 hermann meyer did opine
And Gene did reply:
 Am 30.09.2014 23:51, schrieb Paul Davis:
  it isn't about being a professional or not. You can be a professional
  woodworker or a weekend amateur and use (functionally speaking) the
  same tools. The pro might also have a CNC system too, but that
  doesn't change things in any particular way.
 
 professional tools for woodworkers are extreme expensive ( I know it,
 because I'm), it's unlikely that a weekend amateur is willing to spend
 the money for them.
 (as well a parable)

I'm one of the weekenders I guess, although my weekends can be anytime 
since I retired a decade  change back up the log of life.

But to facilitate some precision in my woodworking for mortise  tenon 
joinery, I long ago made up an alu bar that I can bolt to the front of the 
head casting of my cnc'd (using LinuxCNC of course) micromill to mount a 
cheap die grinder far enough forward and offset to the left, and some jigs 
to mount the frame sticks in a vice-like setup, wrote a bit of gcode and 
carved both the tenon on the end of the stick, and its matching mortise.

My last such project, for the next door neighbor, was a set of benches 
with seat backs that double as storage for toys etc for all ages, only had 
172 such joints in it.  And no, not a pro, but just making the best use of 
the tools I have.  My interests are best described as eclectic I guess.  
Keeps me out of the bars, is I believe the usual excuse. :)

Point being, use the tool you are familiar with.

Cheers, Gene Heskett
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Joël Krähemann
On tal, 2014-09-30 at 10:56 -0400, Paul Davis wrote:
 
 
 On Tue, Sep 30, 2014 at 9:58 AM, Harry van Haaren
 harryhaa...@gmail.com wrote:
 Hi Linux Audio Developers,
 
 
 TL;DR; Discussing experience driven design for linux audio.
 
 
 I'd like to discuss the age of experiences. Allow me 10
 minutes of
 your time, to watch a video by Aral Balkan talk about
 development of
 technology, FLOSS, design, and the future.
 
 las HarryHaaren: interesting talk
 las HarryHaaren: i want to agree with him except for one major issue
 (for me)
 las HarryHaaren: i'm not interested in making consumer tools
 HarryHaaren las, I came across Aral's work recently, and its been
 very interesting for me anyway.
 las HarryHaaren: and if i'm not making consumer tools, then my model
 is not apple but tools for cabinetry
 HarryHaaren sure, valid point: I agree.
 las HarryHaaren: and everything he says would be total bullshit and
 totally inappropriate there
 HarryHaaren but I don't feel that's the case for the whole
 Linux-Audio eco-system
 las HarryHaaren: indeed
 las HarryHaaren: but basically, the bit that is missing is easily
 summarized: Live and plugins
 las HarryHaaren: these are where his experience driven stuff
 matters
 las HarryHaaren: and yes, i agree that it does matter
 HarryHaaren agreed: that happens to be just what i'm particularly
 interested in :D
 las HarryHaaren: he even uses the term tools
 las HarryHaaren: i think this is a serious abuse of the word, but
 he's not the one who started this
 las HarryHaaren: when my wife uses a computer, she really doesn't
 want tools, she wants his experience thing
 las HarryHaaren: tools are things people use to gain leverage over
 the world, so in some sense, it seems appropriate
 HarryHaaren I'd quite like some more of the experience thing - in
 the right places. And the power of under-the-hood available when/if
 required, agreed again
 las HarryHaaren: but they are also things that for centuries, people
 have expected to have to learn, to master
 las HarryHaaren: when i look at the design of iOS what i see is a
 huge effort to remove learning from the whole user experience
 las HarryHaaren: to make everything absolutely obvious (once you've
 learned a few basic ideas about the UI)
 HarryHaaren sure: not something i'm fond of for all situations: too
 much generic is bad in the arts / creative sectors IMO
 las HarryHaaren: when the *task* is simple, this seems appropriate
 las HarryHaaren: but when the *task* is not simple, i think its
 inappropriate
 las HarryHaaren: if you look at a table saw or a crosscut saw or a
 router, they fail almost every possible test of user experience
 las HarryHaaren: they are dangerous, loud and more or less
 completely opaque as far as how to use them to get a particular result
 las HarryHaaren: and yet 
 HarryHaaren sure: but learn to use it and its no problem. I
 appreciate that, and i see how it applies to certain software too
 las HarryHaaren: yes, and the learning about the tool leads to
 learning about the task also
 las HarryHaaren: do you know how easy it would be to make a plugin
 called MakeItSoundBetter that just had 3 buttons?
 las HarryHaaren: change it, that was better, that was worse
 las HarryHaaren: people would love this tool. and by using it,
 they would learn absolutely *nothing* about what they were doing
 las HarryHaaren: i don't want to help create that sort of world
 las HarryHaaren: on the other hand, i don't do much auto
 maintainance, so ... what does that say? :)
 HarryHaaren fair enough. I probably would. But let people click the
 advanced button, see the algorithms, and learn about the tool  the
 task
  
 
 ___
 Linux-audio-dev mailing list
 Linux-audio-dev@lists.linuxaudio.org
 http://lists.linuxaudio.org/listinfo/linux-audio-dev

Why doesn't Harry learn howto do a dial. I just take a look at his code
and it just sucks. Why don't you take a look how it should have been
done. For sure you will get it for once.

https://sourceforge.net/p/ags/code/HEAD/tree/src/ags/widget/ags_dial.c

kind regards
Joël



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Harry van Haaren
On Wed, Oct 1, 2014 at 12:26 PM, Joël Krähemann weedli...@gmail.com wrote:
 Why doesn't Harry learn howto do a dial. I just take a look at his code
 and it just sucks.

Hi Joel,

The topic isn't the quality of my code: I'm sorry to hear you feel it
just sucks. If you wish to discuss the quality of code, please
contact me directly by email, or start a new thread with an
appropriate topic.

But please, lets not stray away from the topic at hand: which is
desining user-interfaces with the objective to improve the experience
of using a piece of software, and not directly focussing on the
features that the software provides.

I welcome your input in this mailing-list thread on how we can make
FLOSS / Linux Audio programs have a better user experience.
Cheers, -Harry

-- 

http://www.openavproductions.com
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Paul Davis
On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt mista.ta...@gmx.net
wrote:


 The important point was though that left to their own devices the
 non-enthusiasts will be slaughtered by the software they use and maybe
 we have a responsibility to protect them from themselves.


slaughter is perhaps a strong term.

perhaps a more nuanced description might run something like this (taking a
little inspiration from the video):

creating and maintaining **consumer** software with a very good user
experience is expensive (relative to other tasks that people do) and takes
a significant amount of time. therefore the creation and maintainance of
this sort of software requires resources that are not clearly available to
most open source efforts. the proprietary software that manages to do this
is influenced at some level by where its creators and maintainers get their
income from, and the development of the free model used in particular by
google points in a direction where the software must allow/empower/enable
behaviour by the software developers that are not in the users' best
interest (e.g. selling data about the users).
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Louigi Verona
Discussion often focuses on thinking for the user or about users that
don't want to learn.

I don't think that this is what the guy in the video was talking about. And
this is certainly not what I mean when talking about usability of Linux
software.

Experience-driven design, as I understood him, is about convenience and
being able to make a tool that is easy to use. But easy to use does not
mean dumb usage. It rather means pleasant to use.

There is a huge difference between having options in a text file that you
have to edit or having them in a GUI. And the difference is not in having
to learn - most users know how to edit a text file. The difference is in
convenience. There is an inherent difference between going to a folder,
locating a config text file and editing it and just seeing all options laid
out in a GUI, right within the program.

GUI does not have to dumb you down. It economizes your time and effort by
showing you all the options and letting you tweak them more quickly and get
the information from your options in a more pleasant way. Having a GUI does
not mean reducing your options.

*---*

As an example, when I need to write using a text field the amount of delay
in milliseconds, this is not advanced. This just takes up my time,
because I need to figure out the amount of ms required for my bpm and then
input numbers into the field with a keyboard.

One can, of course, argue, that you can learn the formula, but this is
arbitrary. As Harry very correctly pointed out, this has little to do with
composing.

If instead of inputting numbers I get a knob - this is better. But if I get
a knob that will tweak delay time in actual bpm-multiple values - this will
be much more pleasant. Not because I am not able to learn, but because
this helps me get my task done faster.

One can, of course, argue that having ms allows you more functionality
and this is where the argument often lies - that Linux software allows you
more options. But in my view the price of implementing those options (and
not implementing easy to use GUI) far outweighs the actual need of those
options. How many times in your life have you needed to set delay time to
like 123.7863218 ms or other weird time?

---

So I think a developer should ask himself - would he want his software to
look better and to have a GUI that would help users get things done faster
and in a more pleasant manner? If yes, but he has no time - sure, it is
clear. If no - then this is a different position altogether. And this then
has nothing to do with learning or dumb users.



Louigi.




On Wed, Oct 1, 2014 at 5:20 PM, Paul Davis p...@linuxaudiosystems.com
wrote:



 On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt mista.ta...@gmx.net
 wrote:


 The important point was though that left to their own devices the
 non-enthusiasts will be slaughtered by the software they use and maybe
 we have a responsibility to protect them from themselves.


 slaughter is perhaps a strong term.

 perhaps a more nuanced description might run something like this (taking a
 little inspiration from the video):

 creating and maintaining **consumer** software with a very good user
 experience is expensive (relative to other tasks that people do) and takes
 a significant amount of time. therefore the creation and maintainance of
 this sort of software requires resources that are not clearly available to
 most open source efforts. the proprietary software that manages to do this
 is influenced at some level by where its creators and maintainers get their
 income from, and the development of the free model used in particular by
 google points in a direction where the software must allow/empower/enable
 behaviour by the software developers that are not in the users' best
 interest (e.g. selling data about the users).


 ___
 Linux-audio-dev mailing list
 Linux-audio-dev@lists.linuxaudio.org
 http://lists.linuxaudio.org/listinfo/linux-audio-dev




-- 
Louigi Verona
http://www.louigiverona.ru/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Paul Davis
On Wed, Oct 1, 2014 at 11:01 AM, Louigi Verona louigi.ver...@gmail.com
wrote:


 There is a huge difference between having options in a text file that you
 have to edit or having them in a GUI. And the difference is not in having
 to learn - most users know how to edit a text file. The difference is in
 convenience. There is an inherent difference between going to a folder,
 locating a config text file and editing it and just seeing all options laid
 out in a GUI, right within the program.


this isn't universally true. there is a class of user for whom editing the
text file is actually the faster, more efficient way to change options,
especially if there are a lot of them. whether this group of users is
large, and whether it should dominate design models is a separate question.



 GUI does not have to dumb you down. It economizes your time and effort by
 showing you all the options and letting you tweak them more quickly and get
 the information from your options in a more pleasant way. Having a GUI does
 not mean reducing your options.


it doesn't have to mean that, but it often does, especially if the program
has a lot of options - people get scared of presenting them all and so they
hide most of them.

consider the case of all the things you can do with sysctl(1) on OS X that
are not represented anywhere in the GUI. they *could* be, but they are not,
because doing so conflicts with the experience that apple designers wanted
people to have. anyone who needs to do that stuff is fine with the
command line, they apparently reasoned.

in general, textual presentations of options and parameters *tend* toward
showing the user everything; GUI presentations *tend* towared a more
structured display of selected options believed to be the most important.
these are not hard rules, just tendencies, but important ones,
nevertheless.


 As an example, when I need to write using a text field the amount of delay
 in milliseconds, this is not advanced. This just takes up my time,
 because I need to figure out the amount of ms required for my bpm and then
 input numbers into the field with a keyboard.


until you need to use a delay to compensate for a block size delay that you
known in samples :)




 So I think a developer should ask himself - would he want his software to
 look better and to have a GUI that would help users get things done faster
 and in a more pleasant manner?


this is a secondary question. until you define what the things that are
going to get done, you can't begin to ask if or how to help users with
those tasks.



 If yes, but he has no time - sure, it is clear. If no - then this is a
 different position altogether. And this then has nothing to do with
 learning or dumb users.


i think it has a *lot* to do with it. there are a whole bunch of things you
can do in a DAW-like tool to reduce the initial confusion and number of
things the user has to do and comprehend before they manage their first
recording pass or audio import. garageband is a perfect example of how to
do this. the cost is that (a) the user learns very little about the
underlying concepts of the application (b) you must hide a set of options
that would just confuse first time usage but that may be critical one month
in (I've watched my son face this curve with garageband, which is partly
why he no longer uses it and is on Live instead).

This leads naturally to one of two approaches: more workflow specific tools
(e.g. Live/Bitwig, Trackers, audio file editors, traditional DAWs,
SuperCollider ...) or gradual reveal in which the user gets to control
how much of the full set of possibilities are accessible/visible at any
point in their use of the tool.

When you give people an app that does one thing (i'm thinking of
android/iOS apps here), these considerations don't apply because the
things to be done are so easily defined and so limited that it really
just a presentation/design issue that doesn't have to sacrifice power for
experience.

But when you give people an app with the power of (even) audacity (let
alone Live or ProTools), there is naturally a learning curve, and it is a
critical question how and if the application will try to assist the journey
along this curve. First time DAW users are always dumb, no matter which
DAW they sit down in front of. How they get to be less dumb is about
learning, and the learning is very very dependent on the design and
structure and goals of the application.





 Louigi.




 On Wed, Oct 1, 2014 at 5:20 PM, Paul Davis p...@linuxaudiosystems.com
 wrote:



 On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt mista.ta...@gmx.net
  wrote:


 The important point was though that left to their own devices the
 non-enthusiasts will be slaughtered by the software they use and maybe
 we have a responsibility to protect them from themselves.


 slaughter is perhaps a strong term.

 perhaps a more nuanced description might run something like this (taking
 a little inspiration from the video):

 

Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Patrick Shirkey

On Thu, October 2, 2014 1:01 am, Louigi Verona wrote:
 Discussion often focuses on thinking for the user or about users that
 don't want to learn.

 I don't think that this is what the guy in the video was talking about.
 And
 this is certainly not what I mean when talking about usability of Linux
 software.


Usability usually requires a designers eye. Most good UX designers spend
almost all their time on design/usability issues. In fact most UX
designers are paid to only deign the UX and they look to developers to
advise on functional viability of their creations. In most cases in a
professional context UX designers will win over developers if there is a
decision to be made between form over function. Developers are usually
left to fill in all the gaps that UX designers have left in the
functionality of their design and In my experience developers are often
considered to be skilled labour while a designer is considered to be a
working artiste or in some way superior.

In open source development most developers are not designers or
particularly visually motivated. The exception being graphics/games
developers and a few very talented people who cover both disciplines with
expert delivery. In Linux Audio Development there is a clear majority of
audio focused developers who prioritise function over form. Considering
that even software like Blender has a major learning curve for the
uninitiated and those guys are expert visually oriented developers it's no
surprise that Audio focused developers are less successful at achieving
visually beautiful and highly polished usability.

IMO, in nearly all LAD applications the developers have tried to achieve
usability with the limited skills/expertise that they have in UX design
and GUI development.

The main problem in this regard is the lack of
interest/motivation/time/resources to make things more usable. The idea
behind open source is that anyone can pitch in but it seems in Linux Audio
Development there are less people pitching in these days than say 10 years
ago and there are more individually run projects

That's seems to be the main reason why many developers choose to use bog
standard gtk/kde to let the user define their own version of usability and
steer clear of visually challenging API's like Cairo/Clutter/OpenGL which
often require as much effort or more to achieve results than just writing
good clean efficient functional and bugfree code.

A way to enhance usability across the board might be to have an app of
the week where everyone in the Linux Audio community is encouraged to run
it and provide any feedback they can think of on mass to the LAU list.
That might give developers some incentive to forge ahead with the ideas
presented by the community.




 Experience-driven design, as I understood him, is about convenience and
 being able to make a tool that is easy to use. But easy to use does not
 mean dumb usage. It rather means pleasant to use.

 There is a huge difference between having options in a text file that you
 have to edit or having them in a GUI. And the difference is not in having
 to learn - most users know how to edit a text file. The difference is in
 convenience. There is an inherent difference between going to a folder,
 locating a config text file and editing it and just seeing all options
 laid
 out in a GUI, right within the program.

 GUI does not have to dumb you down. It economizes your time and effort by
 showing you all the options and letting you tweak them more quickly and
 get
 the information from your options in a more pleasant way. Having a GUI
 does
 not mean reducing your options.

 *---*

 As an example, when I need to write using a text field the amount of delay
 in milliseconds, this is not advanced. This just takes up my time,
 because I need to figure out the amount of ms required for my bpm and then
 input numbers into the field with a keyboard.

 One can, of course, argue, that you can learn the formula, but this is
 arbitrary. As Harry very correctly pointed out, this has little to do with
 composing.

 If instead of inputting numbers I get a knob - this is better. But if I
 get
 a knob that will tweak delay time in actual bpm-multiple values - this
 will
 be much more pleasant. Not because I am not able to learn, but because
 this helps me get my task done faster.

 One can, of course, argue that having ms allows you more functionality
 and this is where the argument often lies - that Linux software allows you
 more options. But in my view the price of implementing those options
 (and
 not implementing easy to use GUI) far outweighs the actual need of those
 options. How many times in your life have you needed to set delay time to
 like 123.7863218 ms or other weird time?

 ---

 So I think a developer should ask himself - would he want his software to
 look better and to have a GUI that would help users get things done faster
 and in a more pleasant manner? If yes, but he has no time - sure, it is
 clear. If 

Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread tom
On Wed, October 1, 2014 17:40, Patrick Shirkey wrote:

 Usability usually requires a designers eye. Most good UX designers spend
 almost all their time on design/usability issues.

That might be true but UX isn't restricted to visual aspects IMO.

Looking at a button to indicate two statuses, is it a pure (visual) design
question how large the button is, where it is placed, how it is labeled
and how it looks? I think there is a layer between the pure design aspects
and the pure functional aspects where the line is blurred. For the button
to indicate two statuses, it's inherent that the distinction of the two
statuses must work. This is clearly a functional aspect of the (visual)
representation, in terms of operating the widget. If the button is too
small or placed where it won't be found it's also a functional aspect. The
pure visual design aspects come into play *when the above functional
aspects of operation driven by visuals are met*. The visual aspects on top
of that can be to match a common style (we use rounded corners for our
buttons) *without breaking* the functional aspects (i.e. changing the
colors in a way that affects the distinction of statuses). This is also
where the individual preferences start whereas independently of that,
everyone needs to find, read, hit the button and distinguish its statuses.

  ___dev focus
 / __ux/design focus
/ /
| |---What is shown to the user, make use of the offered functionality
| |   --Wording, style/theme, hidden-factor of function
| |   --Documentation
| |
| |---The functionality embedded to the ecosystem of the program
| |   --Accessibility, grouping (..is in the same category as)
| |
| |---The abstract functionality
| |   --Fits/amends the core idea, plays well with existing
|  \
|
| ---The concrete implementation
|   --Algorithm 1 faster than 2
|   --Library x
|   --Already existing (just another parametric call)
|
: ---The distribution
:   --Needs special attention to build on y
:
: ---Other aspects
:   --Legal, license etc (can we use lib z?)
 \

(this is a free-form layering, change/comment it if you like)

Please note the the dev has/should have the full picture and shares the
top layers with a ux/design person.

I make an example using that layer stack.

Request: provide a way to add a new track in a multitrack app via keyboard
shortcut (no more actions/data entry needed)

Check legitimacy of request: is it something new or already existing, how
does it differ, does it fit to the core ideas, does it bring additional
value, does it break existing concepts etc.

Possible outcome: feature exists but it's not done in the most simple way
(clicking through menus and dialogues needed)
Possible arguments against: it can already be done. We can't know how many
channels the user wants in the track thus we can't make a shortcut without
data entry.
Possible facit: In 98% of cases, the users want's to either add a mono or
a stereo track. We provide the shortcut just for these two cases.

Layers bottom up:
--Other aspects: no change
--Distribution: no change
--Concrete implementation: already existing (just another parametric call)
--Abstract functionality: all conditions met
--Functionality embedded to the ecosystem of program: group with existing
track ops
--What is shown to the user: some minor work here (mainly: documentation)

In this case, the UX can be improved for users, without the UI changing
except for a menu entry showing the action and keyboard shortcut. All the
involved steps can be done just by developers.

Now one could do that again with the next request: add a button to add a
track immediately :) where UI/UX person will play a greater role.

Regards
Tom

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Louigi Verona
Hey Paul,

I agree with most of what you say, you are correct in pointing out that the
situation is more nuanced.

until you need to use a delay to compensate for a block size delay that
you known in samples :)

Wanted to comment on this. Right. You might want to do that. But, as I
said, the price of this one very rarely required feature, in my opinion, is
too high. Or else delay plugin was generally understood to be a very
different tool on Linux in general. In fact, most LADSPA delay plugins use
ms. There is an obvious cultural disconnect here :)

the cost is that (a) the user learns very little about the underlying
concepts of the application (b) you must hide a set of options that would
just confuse first time usage but that may be critical one month in (I've
watched my son face this curve with garageband, which is partly why he no
longer uses it and is on Live instead).

Point taken. However, I would like my point to be underlined as well - I am
saying that even in an application that has a steep learning curve there
are ways to do it even harder or more pleasant. I mean, Zyn has lots of
options. They could've been just a text file.



Also, I would like to say this - bottom line is that most apps on Linux are
not known for ease of use. And that has a systematic cause, no doubt about
it. In my view the cause is that this is mostly software done for oneself
rather than for the audience. Additionally, GUI takes a lot of time to
develop and Linux hobbyists are generally developers, not designers. That's
it, really.




Louigi.
http://www.louigiverona.ru/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Fons Adriaensen
On Wed, Oct 01, 2014 at 07:01:54PM +0400, Louigi Verona wrote:

 How many times in your life have you needed to set delay time to
 like 123.7863218 ms or other weird time?

The many times I've had to set a delay time the most convenient
unit could have been samples, millisecs or meters (at the speed
of sound), depending on the context. I've never had the need to
set it in beats. Which are not even a fixed unit but require the
delay processor to know the current bpm value. Could be done in
an app or plugin that mainly deals with beats, not in a general-
purpose plugin. 

Ciao,


-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Fons Adriaensen
On Wed, Oct 01, 2014 at 11:32:47AM -0400, Paul Davis wrote:

 it doesn't have to mean that, but it often does, especially if the program
 has a lot of options - people get scared of presenting them all and so they
 hide most of them.

Exactly. Good example is Chromium's settings page. It shows almost nothing.
Some more are available if you dare clicking 'advanced', but even those are
as basic as the default set.

The very term 'advanced' is often used to scare people away from touching 
certain options - don't touch these or you make break something.

Hiding options or settings in order to be 'convenient' *is* dumbing
down, no matter how you turn it. And the real reason for doing that
is often another one, for example to try and hide shortcomings or
defects. Or in the case of Chromium to scare the user setting any
options that would enhance his privacy or whatever remains of it.

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Paul Davis
On Wed, Oct 1, 2014 at 4:40 PM, Fons Adriaensen f...@linuxaudio.org wrote:

 On Wed, Oct 01, 2014 at 11:32:47AM -0400, Paul Davis wrote:

  it doesn't have to mean that, but it often does, especially if the
 program
  has a lot of options - people get scared of presenting them all and so
 they
  hide most of them.

 Exactly. Good example is Chromium's settings page. It shows almost nothing.
 Some more are available if you dare clicking 'advanced', but even those are
 as basic as the default set.


point your chrome at: about:config

:)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Joël Krähemann
On arb, 2014-10-01 at 12:39 +0100, Harry van Haaren wrote:
 On Wed, Oct 1, 2014 at 12:26 PM, Joël Krähemann weedli...@gmail.com wrote:
  Why doesn't Harry learn howto do a dial. I just take a look at his code
  and it just sucks.
 
 Hi Joel,
 
 The topic isn't the quality of my code: I'm sorry to hear you feel it
 just sucks. If you wish to discuss the quality of code, please
 contact me directly by email, or start a new thread with an
 appropriate topic.
 
 But please, lets not stray away from the topic at hand: which is
 desining user-interfaces with the objective to improve the experience
 of using a piece of software, and not directly focussing on the
 features that the software provides.
 
 I welcome your input in this mailing-list thread on how we can make
 FLOSS / Linux Audio programs have a better user experience.
 Cheers, -Harry
 

Excuse me being unpolite I just was thinking about all day. I can say it
sucks because me was at the same point.
Please take this as a chance to learn where the user benefits of
experience.

Scaling is done normally between -1.0 ... 0.0 ... 1.0
Your constants are false.

I can't say if it was cause of selfishness looking at the code but
telling you that you're wrong is cause wanting you to help.

have a nice evening and kind regards
Joël




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Len Ovens

On Wed, 1 Oct 2014, Louigi Verona wrote:


Also, I would like to say this - bottom line is that most apps on Linux are not 
known
for ease of use. And that has a systematic cause, no doubt about it. In my view 
the
cause is that this is mostly software done for oneself rather than for the 
audience.
Additionally, GUI takes a lot of time to develop and Linux hobbyists are 
generally
developers, not designers. That's it, really.


Yes, To add to the point, Just as the author of the talk is developing a 
phone, so is ubuntu. I was following the progress for a bit and what 
stands out to me is that almost all of the people who showed up and wanted 
to add code were interested in porting the the sw to another device (the 
one that person has) rather than improving the look, feel, experience or 
even the functionallity. It seems a part of it is that developing for 
other people can be pretty thankless. One hears about the problems and 
dislikes, but even when these grumbles have been addressed or fixed, there 
is rarely any thanks. This is even more noticable for those users who have 
switched over from proprietary sw who's attitude is more along the lines 
of why haven't you fixed this yet? to much more abusive language than 
that.


On a community developed project, how the developers feel about their 
work is much more important when they are paid for the same work (even the 
same people).


Just dabbling in development has made me much more understanding and 
appreciative of the work that others do. I am much more willing to make 
do, much more willing to hear no I am not going to add that. Much more 
willing to use two (or more) tools to do the same job that might be done 
with one if designed so.


The whole idea of we can make something beautiful with a wonderful 
experience and so users will use it and be free doesn't ring true. An 
open source project can put a product out like that yes, but as soon as they do 
it will be copied and even before that, it will not be chosen because it 
is free of malwere, but rather because it goes with my feeling this week 
and next week it is back to some closed device because my friend has one. 
In the end, open devices would have to be made by people just as 
cut-throat as a closed shop. so what is really gained?



--
Len Ovens
www.ovenwerks.net

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Paul Davis
Here's an interesting counterpoint or follow up point or whatever. I've
queued it to start at the right time, listen till about 31:00 (or longer if
you want). The key point I wanted to highlight was Gerhard's point about
saying No to user requests. But, being Gerhard, he has other interesting
points to make as well.

iframe frameborder=0 width=480 height=270 src=//
www.dailymotion.com/embed/video/x26axz5?start=1530
allowfullscreen/iframebr /a href=
http://www.dailymotion.com/video/x26axz5_music-in-the-age-of-democratization-gerhard-behles-ableton-and-matt-black-ninja-tune-coldcut-in-conv_tech;
target=_blankMusic in the Age of Democratization: Gerhard.../a iby
a href=http://www.dailymotion.com/SMWBerlin;
target=_blankSMWBerlin/a/i
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Paul Davis
bah. bad formatting. try this:

http://www.dailymotion.com/embed/video/x26axz5?start=1530
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-10-01 Thread Len Ovens

On Wed, 1 Oct 2014, Paul Davis wrote:


Here's an interesting counterpoint or follow up point or whatever. I've queued 
it to
start at the right time, listen till about 31:00 (or longer if you want). The 
key point
I wanted to highlight was Gerhard's point about saying No to user requests. 
But, being
Gerhard, he has other interesting points to make as well.

src=//www.dailymotion.com/embed/video/x26axz5?start=1530 
allowfullscreen/iframebr


An interesting chat. In his case the reasons for saying no to user 
requests might be different, though not by much.


I also realize maybe I am taking the original question off of what it was 
asking. The original talk was about something that is perhaps not 
understandable in the context of creation rather consuming. Many of the 
newer DEs are frustrating for developers (not just SW development), but 
developers even though there are many, are a very small percentage of 
computer users. Most are consumers, games and browsing are almost all that 
happens. From that POV win8, unity, gnome3, OSx, Android, etc. all make 
sense. From a developers POV (POV meaning personal use), they don't. 
Someone who is creating music, video or graphics is a developer and their 
needs are not the same as the consumer. Once that difference is pushed 
out of the way and one looks at the user experience from a developer's POV 
the experience that is expected is different but it is still there.


I remember having 4 or more terminals open for creating sw: One to edit 
(or more), one to try different configurations, one to compile and one to 
test. I hated the full screen way that a lot of consumer based people 
worked. Now we have a GUI with all of these things built in. Many audio 
programs have done the same thing. We have the DAW that takes a full 
screen and does everything. Linux audio has been different with separate 
tools connected together. As many of us started with tape... this makes 
sense to us. Even a home studio had many boxes wired together. If you 
wanted to add effects to one channel a separate box was used outside of 
the mixer. A sequencer was a separate box. Each synth was a separate box. 
Because of physical limitations, the wiring configuration was changed for 
each project or song... maybe more than once. Soon it was figured out that 
these routings might be changed not only to get around limitations, but 
also for artistic reasons. I think some of us miss that ability to be able 
to wire things as we wish in the monolythic SW blob. One who has worked 
with physical boxes for everything finds a simple interface difficult to 
use. They have to go looking for the bits they want. It is like having 
someone come into the studio and take any box that is not in use right now 
and put it in storage... across town, in different warehouses according to 
categories a herbalist would use.


For the newcomer who has started on a DAW based all in one box, all is 
fine, they only use the tools that are visible... Your clip says only for 
the first few months... but it does agree that the tools shape the music.


What I expect has changed, but it is still based on experience that covers 
a lot of technical advancement. I grew up in a house where all the 
electronics used tubes. I was given a transiter radio at 8 and I think 
this was the first solid state device we had. monochrome TV was pretty 
standard we actually got one in the house when I was 10 or so. The 
first personal computers had a row of switches on the front like a pdp8. 
An Apple computer had a 6502 in it and no mouse.


In all I am pretty happy that the consumer use of computers is as 
widespead as it is. This means that HW is relatively cheap. Really most people use 
computers in a way that could as easily (maybe better) be satisfied with 
and Xbox or Wii and a keyboard/mouse. I am glad people have not figured 
this out yet. Or may be that set top boxes havn't taken over.


Perhaps what I am saying is that I am quite happy to be using my computer 
in a niche market and I am glad there are enough people who think the same 
to be able to persue music the way I do.


Often people have a blurb here saying this was sent from a Brand mobile 
phone. perhaps I could say sent from Pine (or is it Alpine these days?) 
with a minimal text editor...


--
Len Ovens
www.ovenwerks.net

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Charles Z Henry
On Tue, Sep 30, 2014 at 8:58 AM, Harry van Haaren harryhaa...@gmail.com wrote:
 Hi Linux Audio Developers,


 TL;DR; Discussing experience driven design for linux audio.


 I'd like to discuss the age of experiences. Allow me 10 minutes of
 your time, to watch a video by Aral Balkan talk about development of
 technology, FLOSS, design, and the future.

 To start, please watch the following clip: I've skipped into the video
 to get the section I think is most interesting to discuss on this
 list:
 https://www.youtube.com/watch?feature=player_detailpagev=ldhHkVjLe7A#t=1625


 To bring this discussion to a productive start, I'd like to concider
 the tools we have available as the linux-audio community: they
 certainly have features, and empower the user to own thier tools, and
 the data used with those tools.

 Should we improve experience for users?
 Should we design experience driven open software?
 Should we forward the UX of Linux Audio to the age of experiences?

 What do users know, that developers might not?
 What is it that needs to change? Are there even issues here?
 If so, how do we (the community as a whole) try to solve this?


 I hope this is a productive and inclusive discussion, and politely
 request remaining on topic ;)
 To a fruitful discussion, -Harry

 --

 www.openavproductions.com
 ___
 Linux-audio-dev mailing list
 Linux-audio-dev@lists.linuxaudio.org
 http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Paul Davis
On Tue, Sep 30, 2014 at 9:58 AM, Harry van Haaren harryhaa...@gmail.com
wrote:

 Hi Linux Audio Developers,


 TL;DR; Discussing experience driven design for linux audio.


 I'd like to discuss the age of experiences. Allow me 10 minutes of
 your time, to watch a video by Aral Balkan talk about development of
 technology, FLOSS, design, and the future.


las HarryHaaren: interesting talk
las HarryHaaren: i want to agree with him except for one major issue (for
me)
las HarryHaaren: i'm not interested in making consumer tools
HarryHaaren las, I came across Aral's work recently, and its been very
interesting for me anyway.
las HarryHaaren: and if i'm not making consumer tools, then my model is
not apple but tools for cabinetry
HarryHaaren sure, valid point: I agree.
las HarryHaaren: and everything he says would be total bullshit and
totally inappropriate there
HarryHaaren but I don't feel that's the case for the whole Linux-Audio
eco-system
las HarryHaaren: indeed
las HarryHaaren: but basically, the bit that is missing is easily
summarized: Live and plugins
las HarryHaaren: these are where his experience driven stuff matters
las HarryHaaren: and yes, i agree that it does matter
HarryHaaren agreed: that happens to be just what i'm particularly
interested in :D
las HarryHaaren: he even uses the term tools
las HarryHaaren: i think this is a serious abuse of the word, but he's
not the one who started this
las HarryHaaren: when my wife uses a computer, she really doesn't want
tools, she wants his experience thing
las HarryHaaren: tools are things people use to gain leverage over the
world, so in some sense, it seems appropriate
HarryHaaren I'd quite like some more of the experience thing - in the
right places. And the power of under-the-hood available when/if required,
agreed again
las HarryHaaren: but they are also things that for centuries, people have
expected to have to learn, to master
las HarryHaaren: when i look at the design of iOS what i see is a huge
effort to remove learning from the whole user experience
las HarryHaaren: to make everything absolutely obvious (once you've
learned a few basic ideas about the UI)
HarryHaaren sure: not something i'm fond of for all situations: too much
generic is bad in the arts / creative sectors IMO
las HarryHaaren: when the *task* is simple, this seems appropriate
las HarryHaaren: but when the *task* is not simple, i think its
inappropriate
las HarryHaaren: if you look at a table saw or a crosscut saw or a
router, they fail almost every possible test of user experience
las HarryHaaren: they are dangerous, loud and more or less completely
opaque as far as how to use them to get a particular result
las HarryHaaren: and yet 
HarryHaaren sure: but learn to use it and its no problem. I appreciate
that, and i see how it applies to certain software too
las HarryHaaren: yes, and the learning about the tool leads to learning
about the task also
las HarryHaaren: do you know how easy it would be to make a plugin called
MakeItSoundBetter that just had 3 buttons?
las HarryHaaren: change it, that was better, that was worse
las HarryHaaren: people would love this tool. and by using it, they
would learn absolutely *nothing* about what they were doing
las HarryHaaren: i don't want to help create that sort of world
las HarryHaaren: on the other hand, i don't do much auto maintainance, so
... what does that say? :)
HarryHaaren fair enough. I probably would. But let people click the
advanced button, see the algorithms, and learn about the tool  the task
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Charles Z Henry
On Tue, Sep 30, 2014 at 8:58 AM, Harry van Haaren harryhaa...@gmail.com wrote:
 Hi Linux Audio Developers,


 TL;DR; Discussing experience driven design for linux audio.


 I'd like to discuss the age of experiences. Allow me 10 minutes of
 your time, to watch a video by Aral Balkan talk about development of
 technology, FLOSS, design, and the future.

 To start, please watch the following clip: I've skipped into the video
 to get the section I think is most interesting to discuss on this
 list:
 https://www.youtube.com/watch?feature=player_detailpagev=ldhHkVjLe7A#t=1625


 To bring this discussion to a productive start, I'd like to concider
 the tools we have available as the linux-audio community: they
 certainly have features, and empower the user to own thier tools, and
 the data used with those tools.

 Should we improve experience for users?
 Should we design experience driven open software?
 Should we forward the UX of Linux Audio to the age of experiences?

I don't think what he's talking about is comparable to audio yet.
There does not currently exist a company that is credibly making a
complete, whole-system design approach to problems such as audio
recording and live sound processing.

You *can* currently start a company with a offering of proprietary
hardware, open source software that you will support, tie it up with a
new interface (that you also release for free, a requirement of GPL),
offer software as a service (that you don't have to release), provide
centralized services, and sell support contracts.  It's a completely
reasonable thing, given other existing companies that do this
currently in other spheres.

 What do users know, that developers might not?

If you agree with the premise he's made, nothing.  Users apparently
want to be told what they want (until they find out they don't want it
any more... then they look for something else they're told they want).
This time, he's telling us we all want to get involved making products
in our own best interests while following a top-down organizational
structure(?)  I'm confused and my beautiful mouse only has one button
:(

 What is it that needs to change? Are there even issues here?
 If so, how do we (the community as a whole) try to solve this?

To change: incentive structure.  There must be some kind of initiative
(non-profit or other organization) that appeals to developers and
meets the economic constraints of the world we live in, to be
feasible.

The Indie Phone is likely to go the way of OpenMoko which is pretty
dead (no offense to the Moko users who still might be out there).
It's evident that Aral understands the problem faced by technology
consumers... but I can't quite circumscribe all the things he doesn't
get.

Chuck

 I hope this is a productive and inclusive discussion, and politely
 request remaining on topic ;)
 To a fruitful discussion, -Harry

 --

 www.openavproductions.com
 ___
 Linux-audio-dev mailing list
 Linux-audio-dev@lists.linuxaudio.org
 http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Fons Adriaensen
On Tue, Sep 30, 2014 at 02:58:23PM +0100, Harry van Haaren wrote:
 
 Should we improve experience for users?
 Should we design experience driven open software?
 Should we forward the UX of Linux Audio to the age of experiences?

Well, I watched the video until the end, and the only way to
avoid this having been a waste of my time seems to react to
it. Balkan's talk itself is an example of 'experience driven
design'. It goes down easily as it should according to his
own theories, but once you start thinking a bit about what
he says you discover it's only a thin layer of sugar around
nothing. Take the way he compares 'trickle down ecomony'
with 'trickle down technology'. A vague similarity that is
supposed to imply something. But does it ? If there is
really any meaning to this I must be too stupid to grok it.

There is actually a similarity, but not the one he intended,
between a trickle down economy and the type of world he seems
to dream about: one consisting of a majority of dumb 'users'
and an elite of CEO's having great 'design' ideas (remember,
design has to be driven from the top), and in between a third
layer, just above the unwashed masses of users, of 'developers
who need to be just smart enough to realise the bright ideas
of their CEO.

That division may even de facto exist, I'm not going to
dispute that. But I'm not going to help make it worse, and
I'll add why: there's one significant difference between
the users who expect everything (including thinking) to be
done for them, and those who are prepared to learn: the
latter will say 'thank you'.


-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Louigi Verona
I thought the 'trickle down technology' analogy was a little questionable,
but I find a lot in his talk that resonates with me as a user.

I would like to react, but I will probably record a podcast lil later.

On Tue, Sep 30, 2014 at 10:10 PM, Fons Adriaensen f...@linuxaudio.org
wrote:

 On Tue, Sep 30, 2014 at 02:58:23PM +0100, Harry van Haaren wrote:

  Should we improve experience for users?
  Should we design experience driven open software?
  Should we forward the UX of Linux Audio to the age of experiences?

 Well, I watched the video until the end, and the only way to
 avoid this having been a waste of my time seems to react to
 it. Balkan's talk itself is an example of 'experience driven
 design'. It goes down easily as it should according to his
 own theories, but once you start thinking a bit about what
 he says you discover it's only a thin layer of sugar around
 nothing. Take the way he compares 'trickle down ecomony'
 with 'trickle down technology'. A vague similarity that is
 supposed to imply something. But does it ? If there is
 really any meaning to this I must be too stupid to grok it.

 There is actually a similarity, but not the one he intended,
 between a trickle down economy and the type of world he seems
 to dream about: one consisting of a majority of dumb 'users'
 and an elite of CEO's having great 'design' ideas (remember,
 design has to be driven from the top), and in between a third
 layer, just above the unwashed masses of users, of 'developers
 who need to be just smart enough to realise the bright ideas
 of their CEO.

 That division may even de facto exist, I'm not going to
 dispute that. But I'm not going to help make it worse, and
 I'll add why: there's one significant difference between
 the users who expect everything (including thinking) to be
 done for them, and those who are prepared to learn: the
 latter will say 'thank you'.


 --
 FA

 A world of exhaustive, reliable metadata would be an utopia.
 It's also a pipe-dream, founded on self-delusion, nerd hubris
 and hysterically inflated market opportunities. (Cory Doctorow)

 ___
 Linux-audio-dev mailing list
 Linux-audio-dev@lists.linuxaudio.org
 http://lists.linuxaudio.org/listinfo/linux-audio-dev




-- 
Louigi Verona
http://www.louigiverona.ru/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Paul Davis
On Tue, Sep 30, 2014 at 2:10 PM, Fons Adriaensen f...@linuxaudio.org
wrote:

 On Tue, Sep 30, 2014 at 02:58:23PM +0100, Harry van Haaren wrote:

  Should we improve experience for users?
  Should we design experience driven open software?
  Should we forward the UX of Linux Audio to the age of experiences?

 Well, I watched the video until the end, and the only way to
 avoid this having been a waste of my time seems to react to
 it.


given that i don't really agree with his talk, i'm going to defend it
anyway.

what has happened with automobiles? when first introduced, they were the
domain of enthusiasts only. then they spread out to a wider audience, an
audience that was frequently irritated by the maintainance requirements,
breakdowns and poor behaviour of the machines. that gets us to the 1980s.

and now  cars are almost all of a near-uniformly high quality, and that
quality exceeds the levels attained even in 1970's era elite vehicles. you
need to know almost nothing about them to use them (other than knowing how
to drive). their reliability and longevity have improved dramatically, as
have their safety qualities. maintainance is generally simple - regular oil
and other fluid changes, less frequent tire replacements, occasional body
work due to damage. oh, and much better fuel mileage too. of course, every
single one of these improvements isn't the end of the road (no pun
intended), and new engine and propulsion systems still offer huge new areas
of potential improvement, along with self-driven cars for some situations.

if i give this presentation the benefit of the doubt, what he's arguing for
is that *consumer* software, having arrived at feature parity, should be
planning to evolve in the same general direction that automobiles have.
that is: away from an object only maintainable by an enthusiast who is
willing to take the time to learn about it, passing through the phase of an
unreliable, short-lived object that gets fixed by others, to reach a state
where fundamentally, the owner/user doesn't need to know anything and the
thing just works today, tomorrow and the next day.

i don't think i want to write software for people who think software should
be this way, but i will concede that if you accept the premise, it has its
own compelling internal logic.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread tom
On Tue, September 30, 2014 15:58, Harry van Haaren wrote:

 https://www.youtube.com/watch?feature=player_detailpagev=ldhHkVjLe7A#t=16
 25

 Should we improve experience for users?
 Should we design experience driven open software?
 Should we forward the UX of Linux Audio to the age of experiences?

Every other hip project development model X tries to address UX.

Looking at one of the slides.. i find it a strange idea that a CEO would
do the (software, UX) design. Of course in small units, multiple
functions can be incorporated in one person, but generally the CEO
represents, executes and does what the ones that provide finance want him
to do. (Just imagine the CEO designing a car for a moment.)
Good software (good in a way every POV is respected) is hard to do and a
good portion of well working symbiosis between developers, users, people
shouting the word are needed. Such an ecosystem can't be created on demand
easily. User experience is just one part, and it's a buzz part for some
years.
It should be easy though for developers to name the *core* functionality
and *critical dependencies* of their software. The best software won't 
unfold it's full potential i.e. if a dependency prevents it from starting
up at all (see the many problems some users have to start JACK).
Hiding behind the term professional to describe software, that is in
fact just a cumbersome pile of crap (and thus professional) is another
strategy i can observe. you know, if you're too stupid to dig our silly
model of operation you're just not professional. This has to do with
wrongly understood elitism.
I think without observing users closely it's hard to get a reasonable idea
of their experience with any software. Often users bring expertise in the
domain of interest while developers bring the handcraft and best practices
how that can be translated to a programming model. Ideally, these two
share at least some common ground.
The more convenient a software gets, the more it must precisely and
unmistakably know and provide commonly agreed workflows. One of the most
annoying things is software that tries to be smart but fails at being it..
And of course, what is a good UX for one user can be a bad one for
another. Decisions need to be taken. Who takes decisions is a question of
how the project is organized (if at all) and why it's taken is a
consequence of the latter and outcome of a rough common strategy (i.e. we
don't add a pink pony, because that's not the focus of the program).
The UX topic won't go away so quickly. Every other settop box (is it still
called that way?:) struggles to provide a good UI, it's getting better
though (observe: fonts and widgets get BIGGER). I haven't seen any single
case where an improvement of aspects of the user experience were reached
by making things smaller.
Cheers
Tom


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Fons Adriaensen
On Tue, Sep 30, 2014 at 02:53:02PM -0400, Paul Davis wrote:

 ... 
 and now  cars are almost all of a near-uniformly high quality, and that
 quality exceeds the levels attained even in 1970's era elite vehicles. you
 need to know almost nothing about them to use them (other than knowing how
 to drive). their reliability and longevity have improved dramatically, as
 have their safety qualities. maintainance is generally simple - regular oil
 and other fluid changes, less frequent tire replacements, occasional body
 work due to damage. oh, and much better fuel mileage too. of course, every
 single one of these improvements isn't the end of the road (no pun
 intended), and new engine and propulsion systems still offer huge new areas
 of potential improvement, along with self-driven cars for some situations.
 ...

I don't think that is a valid analogy. True, quality and ease of use
have gone up dramatically, but:

* that is mainly the result of fierce competition (and environmental
  regulations which have drive manufacturers towards high-tech solutions),
  while today's world of information technology and services revolves
  about a few de facto monopolies, lots of hype, and a complete absence
  of regulations.

* Cars have different features that fit various needs, and I guess
  most people select the car they will buy by considering the balance
  of features and cost. Which is an entirely different approach than
  buying the latest iphone because it is the latest iphone and even
  if you don't need it.

* Before cars became a commodity they were the toy and status symbol
  of the rich, not of 'car nerds' (although those exist as well).

* Nobody makes free (as in beer) cars.

* In most places, to be allowed to drive a car you don't need to
  RTFM but you need formal training and to pass an exam. More so
  if you drive something that's not your avarage family car or do
  it professionally. In other words, even if car drivers may not
  know much about the technology that makes their cars tick, they
  are not the typical 'dumb user'.

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Len Ovens


My take on this is much more practical. I make software to fill my needs 
and expected experience. I may be willing (if it's easy) to add features 
that are not for me. I may add some features like documentation/packaging 
that are not so easy because it makes it worth while to share the SW.


In the end I have a limited amount of time and resources. I am not a FOSS 
evangelist and am not willing to tythe money I typically don't have to 
shove FOSS down someone's throat or build beautiful toys for yuppies 
(or whatever they are called these days).


BTW, maybe add ubuntu touch to openmoco...

--
Len Ovens
www.ovenwerks.net

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Paul Davis
On Tue, Sep 30, 2014 at 5:32 PM, Len Ovens l...@ovenwerks.net wrote:


 My take on this is much more practical. I make software to fill my needs
 and expected experience.


Your expected experience is shaped by the software experiences you've
already had. This is why the first users of touch surfaces were so blown
away by it - an experience completely unpredicted and unanticipated by
previous experience.

Likewise, your needs are defined in part by the capabilities we currently
understand software to have. Before anyone understood how to do timestretch
in a way that preserved pitch, nobody saw that as a need in an audio
application. Now it is a very common feature, and among a very sizable
fraction of the people who use DAWs, it is a need. Once upon a time, text
editors had no undo feature. Once upon a time, editing video on a computer
was impossible. Once upon another time, realtime audio synthesis was
impossible. The Len of those times, I am certain, would have defined his
needs differently than the Len of today.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Paul Davis
On Tue, Sep 30, 2014 at 5:03 PM, Fons Adriaensen f...@linuxaudio.org
wrote:


 I don't think that is a valid analogy. True, quality and ease of use
 have gone up dramatically, but:

 * that is mainly the result of fierce competition (and environmental
   regulations which have drive manufacturers towards high-tech solutions),
   while today's world of information technology and services revolves
   about a few de facto monopolies, lots of hype, and a complete absence
   of regulations.


You're focusing on h/w and OS vendors. The competition among
app/application developers is insane! There's absolutely no monopoly except
for a couple of application niches, and even there we've seen some upstarts
break down barriers previously thought to be monopolistic.



 * Cars have different features that fit various needs, and I guess
   most people select the car they will buy by considering the balance
   of features and cost. Which is an entirely different approach than
   buying the latest iphone because it is the latest iphone and even
   if you don't need it.


Again, the items on one side of the analogy are software applications, not
hardware. And people will indeed shop around and do have considerable
choice, and a wide variety of prices (including zero cost).



 * Before cars became a commodity they were the toy and status symbol
   of the rich, not of 'car nerds' (although those exist as well).


Photoshop was (and to a limited extent still is) a very high end tool among
image editors (were it not cracked copies, it would still abolutely be a
status symbol, a sign of being a real professional). ProTools was this
way for a long time too. They marked you as a professional in a way
completely disconnected from anything to do with computers per se.


 * In most places, to be allowed to drive a car you don't need to
   RTFM but you need formal training and to pass an exam. More so
   if you drive something that's not your avarage family car or do
   it professionally. In other words, even if car drivers may not
   know much about the technology that makes their cars tick, they
   are not the typical 'dumb user'.


this is where i am not sure about the appropriateness of the metaphor
either. it works in my favor to a limited extent because i prefer to think
of software as tools that one must learn to use (and must learn the depths
of the task they are tools for), in the sense that driving is a task for
which we take a similar approach - car's require training and even
certification to use. but it works against my view because of the total
separation of understanding how the car *works* versus what you do when
using a car (more or less; a bit less for a manual gear shift).
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Paul Davis
On Tue, Sep 30, 2014 at 4:50 PM, t...@trellis.ch wrote:

 . you know, if you're too stupid to dig our silly
 model of operation you're just not professional. This has to do with
 wrongly understood elitism.


it isn't about being a professional or not. You can be a professional
woodworker or a weekend amateur and use (functionally speaking) the same
tools. The pro might also have a CNC system too, but that doesn't change
things in any particular way.

The difference is between expecting the user to dive toward a deeper
understanding of the task and how the tool makes the task easier (or even
trivial), versus expecting the tool to remove any need to really dive into
domain specific knowledge.

the stuff discussed in the video is all explicitly labelled consumer
software (he is trying to differentiate from the enthusiasts tools that
GNU and the rest of the open source world has done such an amazing job with
over the last 3 decades). my understanding of that this is that it refers
directly to software that avoids requiring the user to deepen their
understanding of the problem/task and simply aids them in doing what they
(think they) need to do.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread tom
On Tue, September 30, 2014 23:51, Paul Davis wrote:
 On Tue, Sep 30, 2014 at 4:50 PM, t...@trellis.ch wrote:


 . you know, if you're too stupid to dig our silly
 model of operation you're just not professional. This has to do with
 wrongly understood elitism.


 it isn't about being a professional or not. You can be a professional
 woodworker or a weekend amateur and use (functionally speaking) the same
 tools. The pro might also have a CNC system too, but that doesn't change
 things in any particular way.

that was not my point but i agree with that view


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread Len Ovens

On Tue, 30 Sep 2014, Paul Davis wrote:


On Tue, Sep 30, 2014 at 5:32 PM, Len Ovens l...@ovenwerks.net wrote:

  My take on this is much more practical. I make software to fill
  my needs and expected experience.

Your expected experience is shaped by the software experiences you've
already had. This is why the first users of touch surfaces were so blown
away by it - an experience completely unpredicted and unanticipated by
previous experience.


Yup, certainly. That was not my point though. Yes 1994 or 95 when I 
started using Linux, computer audio was midi. X was around, but was a toy, 
I did everything on terminals accessed with c-a-F* key combos. I don't do 
that any more because I don't have to. I do use a GUI based DAW and am 
grateful for those who developed it.


The point is that I don't get paid for playing with Linux (and when I did 
it was for a specific outcome), I can only spend so much time on it (and 
in the case of HW, only so much money... I have a family to feed). I do 
like open sw and so when I do create something I am willing to share it in 
the same spirit but I am not ready to start a world domination 
campaign. To put together something like this person was suggesting has 
been tried and failed because it has to happen quickly. Even closed house 
with lots of money doesn't always manage catch the wave in time.


This is part of the reason there is more open SW than HW. SW has a lot 
less to loose. The HW that is open is a lot more things that can not be 
bought or where customization is desired and competition is unlikely. 
Control surfaces, high end preamps, even microphones.


Any time hardware is mentioned one of the first responses is that you can 
buy one for less than making it. So it has to have some other value for 
the hobbist to make it. But it is still a value that is personal.


Besides, What do I need a smart phone for? The more I play with them the 
more I long for the old clamshell. Its the same with convergence... 
everything has a phone interface, but I can't do what I want to do on 
it... without more work. Sometimes the keyboard is the right input device 
and sometimes this simple text editor is faster and easier than a gui.


--
Len Ovens
www.ovenwerks.net

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Experience driven design and Linux Audio

2014-09-30 Thread hermann meyer

Am 30.09.2014 23:51, schrieb Paul Davis:
it isn't about being a professional or not. You can be a professional 
woodworker or a weekend amateur and use (functionally speaking) the 
same tools. The pro might also have a CNC system too, but that doesn't 
change things in any particular way.


professional tools for woodworkers are extreme expensive ( I know it, 
because I'm), it's unlikely that a weekend amateur is willing to spend 
the money for them.

(as well a parable)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev