On 04/04/2012 11:22 PM, David Robillard wrote:
On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola wrote: [...]
I think it's essential to the discussion to get the cards on the
table, so everybody can make up his own mind and decides which SM
is the best solution for the Linuxaudio session puzzle. It would be
nice if we could reach agreement on this, but it's a free world
indeed. :)
With apologies in advance, here are my cards:
Thanks, with my apologies in advance for my reply. :)
It would be nice if this list could stick to actual
developer/development problems.
Of course this is the LAD list, so I don't post often on this list,
except for this topic, started by me and of importance for me.
I think this topic is a special case on LAD, because it's by far more
interesting for users to have a good SM implementation then for
developers. For musicians/ user it is a real problem when something
doesn't work or when a session API is implemented badly (technically
and/ or socially). Developers care much less.
But if you make such a strict border between devs and users, also in
such a topic, as you seem to suggest, I'm afraid we'll have to deal with
the same 'great-technical-design' but
'sorry-not-yet-usable-if-you-really-want-to-make-music' software issues
in the coming years on Linux.
Or in the case of session management,'great-minimal-design' but
'useless-because-you-can-only-use-a-few-apps-and-we-dont-have-a-problem-with-that-because-we-dont-use-it-ourselves'.
I'll tell you why this topic is important to me. I did a talk about
Linuxaudio. I can't tell you how much of a pain it was to get my stuff
together. It did cost me more then a *fulltime week, 10h a day* to be
able to show a more or less workable Linuxaudio workflow. Truly
ridiculous and it made me realize that JackSession is utopian (and
probably making music on Linux too) in this state.
It's nice to talk about software design side of Linuxaudio, but actually
working with it is a whole different story, I tell you...especially the
combination 'making music' and 'the modular approach'... (NSM seems to
change this quite a bit though)
But if you're only interested in technical stuff and academic discussion
about APIs, this might be not very interesting to read for you, my
apologies.
up on this thread, and almost nothing at all of value (i.e.
something towards solving the/a problem) has been contributed since
last I checked. Mostly just a bunch of wannabe bureaucracy political
noise, which only obscures any actual technical points that might
need fleshing out (i.e. it's actively hurting, not helping). >
Take the politics to LAU or something.
Call it politics, or call it just an obvious part of the process of
implementing something like a session manager API, where a large part of
the community has to deal with. For me it's not politics in the sense
that I like to see API X supported, rather then API Y, don't get me
wrong. I just think it's important to get the real true (technical/ LAD
related) arguments on table, it helps already to get the picture clear
and to kill argumentation flaws, wrong suggestions and myths. That's in
the benefit for devs and users.
Regards,
\r
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
