Re: [LAD] Experience driven design and Linux Audio

[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

[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

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

[Patrick Shirkey]

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


> 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

[Ralf Mardorf]

On Thu, 2014-10-02 at 14:22 -0700, Len Ovens wrote:
> The dx21 only has 8 because it only has 4 operators. This is math
> related rather than usablity related.

Yesno, take a look at the 32 algorithms of the DX7, some perhaps sane
combinations are missing, not to mention that a second feedback could be
useful. Instead of giving the operator an envelope, giving the feedback
an envelop could be useful, at least when easy editing based on a preset
is wanted. For the DX7 there were several software updates available,
some from Yamaha, others from third party, but AFAIK no update advanced
the sound editing options, just the function options got bug fixes
and/or were advanced. Some limitations likely were done to make the DX
series not too complicated. I remember that when I first used a very
simple Moog, I had to learn what option does cause what sound. Starting
with a very complex modular synth would have been much to complicated to
start understanding those analog synth. Fazit: The right tool for the
right target group and use case. There is no right or wrong approach, no
final solution to get the best universal result. But I suspect that less
old school musicians like to use LMMS on Unity. Rosegarden on Xfce or
similar likely is closer to "our" needs, IOW sane ideas for different
target groups are jumping at us, there's not really the need to think
about ways how to improve approaches/results.

The MOD Duo seems to be a good idea, but the slogan likely will make
musician scratching their heads.
"It's a truly multipurpose effects pedal. It puts hundreds of music
pedals into just one powerful little box with unlimited connections."
In practise nobody ever used effect pedals in this way, while many
musicians already in the past had the possibilities to get such setups.
Musicians usually prefer a hand full of pedals and they much more care
about some models from some vendors or modern multi-effects that provide
something similar to this hand full of effects. Quality over quantity.
Musicians usually prefer a few effects from some vendors, just because
they provide what they need, it has nothing to do with knowledge or
costs.

___
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

[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

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

Re: [LAD] Experience driven design and Linux Audio

[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

[Paul Davis]

On Thu, Oct 2, 2014 at 5:24 AM,  wrote:

> his is fucking retarded.
>
> Modular synthesizers are dead.  No-one except a few propeller-hatted
> autistic loonies who you wouldn't want to sit next to you on the bus use
> them.  Why?  Because they're a pain in the arse.
>

euro-rack modular synthesis is a big growth area for small companies right
now. doesn't mean they are in widespread use, but to call them dead is
pushing it a bit.


>
> Bob Moog realised this very early on, and he (didn't really) invented the
> damned things.  What he realised was that everyone who uses a modular
> spends a day making silly farting noises and then gets on with having a
> couple of oscillators patched to a mixer, followed by a filter and finally
> followed by a VCA, with maybe an envelope for pitch, filter cutoff and
> amplitude.  So having realised this, Moog developed the Minimoog synth
> which was effectively pre-patched in a hardwired configuration that was
> what, as it turns out, most people actually used.
>

a process very similar to the contrast between mixbus and ardour. mixbus
represents harrison's accumulated experience about what people do when
mixing, ardour represents a totally open-to-whatever approach.

interesting that they both use substantively the same codebase, eh?


>
> I think the design should be led by someone with experience in observing
> what people actually do with the tools that are presented to them.  It's a
> sad fact that UX is a difficult and expensive thing to get right.  Car
> manufacturers learned this a long time ago - how many of you drive a car
> with a manual choke (me, okay) or manual ignition advance (no-one unless
> you're into *really* old ones).
>

it is all relative - in the US almost nobody drives a manual transmission
either.


>
> Did Bob Moog "dumb down" the Minimoog?  Well, you could say that yes he
> did.  But you'd be all kinds of wrong.
>

Moog's biggest contribution to analog synthesis, other than the filter, was
to add a keyboard. Buchla was ahead of Moog in actual synthesis, but was
opposed to the idea that such a capable instrument should be constrained by
the limitations of a keyboard. Moog thought that was stupid, and Moog won
that argument hands down, even though in some deeper sense, Buchla was
correct. UX ... all the way.
___
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

[Patrick Shirkey]

On Thu, October 2, 2014 9:14 pm, Neil C Smith wrote:
> On 2 October 2014 11:48, Patrick Shirkey 
> 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

[Neil C Smith]

On 2 October 2014 11:48, Patrick Shirkey  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

[Patrick Shirkey]

On Thu, October 2, 2014 7:44 pm, Neil C Smith wrote:
> On 2 October 2014 10:28, Patrick Shirkey 
> 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

[Neil C Smith]

On 2 October 2014 10:28, Patrick Shirkey  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

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

[gordonjcp]

On Thu, Oct 02, 2014 at 10:00:32AM +0100, Will Godfrey wrote:
> > 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 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.

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

This is fucking retarded.

Modular synthesizers are dead.  No-one except a few propeller-hatted autistic 
loonies who you wouldn't want to sit next to you on the bus use them.  Why?  
Because they're a pain in the arse.

Bob Moog realised this very early on, and he (didn't really) invented the 
damned things.  What he realised was that everyone who uses a modular spends a 
day making silly farting noises and then gets on with having a couple of 
oscillators patched to a mixer, followed by a filter and finally followed by a 
VCA, with maybe an envelope for pitch, filter cutoff and amplitude.  So having 
realised this, Moog developed the Minimoog synth which was effectively 
pre-patched in a hardwired configuration that was what, as it turns out, most 
people actually used.

Yes, you can do a lot of things with a modular, but it takes a long time to get 
there and how many of them are ultimately musically useful? 

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.

It was fucking retarded.

About all it did was make distorted hissing noises or collossal farting noises, 
or with *extreme* care and turning off most of the operators you could coax a 
fairly convincing DX rubber band bass out of it.  If you set all the operators 
to feed back to themselves and feed the output bus, you got a brutal supersaw, 
which I guess was a useful trick.

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.

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

I think the design should be led by someone with experience in observing what 
people actually do with the tools that are presented to them.  It's a sad fact 
that UX is a difficult and expensive thing to get right.  Car manufacturers 
learned this a long time ago - how many of you drive a car with a manual choke 
(me, okay) or manual ignition advance (no-one unless you're into *really* old 
ones).

Did Bob Moog "dumb down" the Minimoog?  Well, you could say that yes he did.  
But you'd be all kinds of wrong.

-- 
Gordonjcp MM0YEQ

___
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

[Will Godfrey]

On Wed, 1 Oct 2014 21:40:10 -0700 (PDT)
Len Ovens  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> 
> 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 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?

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
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

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

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

[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

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

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="_blank">Music in the Age of Democratization: Gerhard... by
http://www.dailymotion.com/SMWBerlin";
target="_blank">SMWBerlin
___
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

[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

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

[Paul Davis]

On Wed, Oct 1, 2014 at 4:40 PM, Fons Adriaensen  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

[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

[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

[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

[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

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

Re: [LAD] Experience driven design and Linux Audio

[Paul Davis]

On Wed, Oct 1, 2014 at 11:01 AM, Louigi Verona 
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 
> wrote:
>
>>
>>
>> On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt > > 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 inspirati

Re: [LAD] Experience driven design and Linux Audio

[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 
wrote:

>
>
> On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt 
> 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

[Paul Davis]

On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt 
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

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01.10.2014 12:03, Harry van Haaren wrote:

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

Thats's cool. I actually prematurely stopped my point there. I was
gonna say that my idealism doesn't extend to providing non-enthusiasts
tools that they can use. And I'm pretty sure many other enthusiasts
and tinkerers share that point.

I was also gonna say that if people like polished closed software on
closed systems better than open source stuff, that's fine, too.

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.

But then: Where's the resources for doing that work coming from?

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

iQEcBAEBAgAGBQJUK/s6AAoJEA5f4Coltk8ZAwcH/jB3kGFYBwqQwbUHg49eZuvD
j+31I5+oiozipL9umw0Gr/D0JyHDeAc998UAJlRUFKkcL95nsCBpnU4AQrllK4Rd
o+H3Hla+aCT8AX0px5rrA6CCao9X0YgljpxvFhYdNMFL9C1rDulzJPOOW051rqPX
wIjay4uknn+v9+my7iiFJyZBVCrRz2McmMPQ8AalBsln7hNQ1ieHuzEehpqP8CPy
ERmInVhCrxmYRj26eGAzUYF5x1MgkgJUePdEuY7F8PHGLhQTH7Gbtl0xtNQqA0Wh
3XAa7fiE9zPL1NMAYj12NU9HvThOw+K0y9aCrxcbvyrDYKFkWWkzA+u/VZmuR1w=
=bsn5
-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

[Harry van Haaren]

On Wed, Oct 1, 2014 at 12:26 PM, Joël Krähemann  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

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

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

[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

[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_detailpage&v=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

[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

Re: [LAD] Experience driven design and Linux Audio

[Len Ovens]

On Tue, 30 Sep 2014, Paul Davis wrote:


On Tue, Sep 30, 2014 at 5:32 PM, Len Ovens  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

[tom]

On Tue, September 30, 2014 23:51, Paul Davis wrote:
> On Tue, Sep 30, 2014 at 4:50 PM,  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

[Paul Davis]

On Tue, Sep 30, 2014 at 4:50 PM,  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

[Paul Davis]

On Tue, Sep 30, 2014 at 5:03 PM, Fons Adriaensen 
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

[Paul Davis]

On Tue, Sep 30, 2014 at 5:32 PM, Len Ovens  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

[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

[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

[tom]

On Tue, September 30, 2014 15:58, Harry van Haaren wrote:

> https://www.youtube.com/watch?feature=player_detailpage&v=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

[Paul Davis]

On Tue, Sep 30, 2014 at 2:10 PM, Fons Adriaensen 
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

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

[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

[Charles Z Henry]

On Tue, Sep 30, 2014 at 8:58 AM, Harry van Haaren  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_detailpage&v=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

[Paul Davis]

On Tue, Sep 30, 2014 at 9:58 AM, Harry van Haaren 
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.
>

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

[Charles Z Henry]

On Tue, Sep 30, 2014 at 8:58 AM, Harry van Haaren  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_detailpage&v=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