[LAD] Experience driven design and Linux Audio

Harry van Haaren harryhaaren at gmail.com
Thu Oct 2 21:51:00 UTC 2014

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

More information about the Linux-audio-dev mailing list