Burkhard Wölfel versuchsanstalt at gmx.de
Sat Nov 21 06:50:28 EST 2009

Am 20.11.2009 um 22:56 schrieb Frank Kober <goemusic at yahoo.fr>:

> Hi Nedko,
> The following tiny comments are to give some feedback even if most  
> of the details you mention are beyond my scope as a user and I would  
> be too scared to analyse that thoroughly. Take the already-said  
> thingies as +1s.
>> After recent discussion on IRC I'm
>> loosing faith in whether it is worth
>> to contribute to linux audio session handling/management.
> For me, session management is actually THE issue that a linux audio  
> setup for me is still lacking, so PLEASE don't ;).

Session managment is what still keeps us from world domination. It is  
the only spot where I as a user see Linux audio suck. There might be  
other quirks, but hey, thats life and I don't care very much about them.

If it would get solved in a way that the majority of client developers  
could follow, that would be heaven on earth, folks.

Sorry for religiously trolling,

- Burkhard

P.S.: Thanks for bringing it up, Nedko.

> I think it's the reason why people, sometimes including myself, are  
> sticking to plugin solutions be it any of the native open standards  
> or VST. But plugins are not an option for everything, and they press  
> your setup an some predefined shape which I don't like that much.  
> BTW is it true that none of the native standards can pass clock  
> information to a plugin?
> It's the reason of a couple of frustrations where in plain composing  
> environment you realize that you have to spend the next 10 minutes  
> on rebuilding your 'studio' loading various parameters, verify  
> connections, etc...if an app decided to tear down jack...well this  
> rarely happens with jack2 I have to say.
>> Two reasons
>> were given why it does not get testing from users. One is
>> that what I
>> did so far is not mature, has annoying bugs and I'm not
>> wanting to fix
>> them. The other one is that ladish is not giving more than
>> users already
>> have with qjackctl.
> It's the latter why I have to admit that I didn't test LADI yet. I  
> pretty well get along with qjackctl, but restoring the apps' states  
> is what makes the setup(s) long. It needs really good concentration  
> on things certain one-stop-shop host applications just take care of  
> on their own. If you use many independent apps, don't forget to save  
> each synth's or FX's parameters before you quit, know where you put  
> all the files, in which hierarchy, etc....I think such a modular  
> linux studio can only survive on the long term with a concept like  
> LADI or LASH. And I got to know the latter and the fact that many of  
> my apps didn't have support for it.
>> Also it was mentioned that D-Bus is not
>> what users
>> find acceptable for controlling jack server.
> I cannot comment on that, but my impression is, the problems arise  
> because this can only work in an environment in which all apps  
> follow that behaviour and for this they would have to adapt their  
> standards, is that what it is?
>> Given the almost missing feedback about LADI development
>> from community
>> members that could benefit from it, I'm not sure whether I
>> should
>> continue to contribute. Maybe I should give up on trying to
>> make linux
>> audio usable for my needs. I could also stop using
>> computers and make
>> music only by using my guitar.
> Even if I don't know your guitar playing I don't think we should  
> accept this :)
>> [resume on things that suck]
> I share many of the points that are in there, but how can a user  
> take position in that complex goods and bads environment? So we all  
> do what works best for what we're currently up to...
> Finally I do not know how LADI can talk to all of the apps around  
> and tell them to load their patches and restore their state, but I  
> really think it's worth TO GO ON WITH THAT.
> Frank.
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

More information about the Linux-audio-user mailing list