linuxaudio.org

--20cf303b39bdf4f58c04cbb852e3

Content-Type: text/plain; charset=ISO-8859-1
"I'm surprised you didn't mention Luppp, libmapper, or the resurgence of

ZynAddSubFX developement.
Don't be - it is impossible to mention everything :)

But this is why I want to hear what other people say - crowd source

approach ;)
On Wed, Oct 10, 2012 at 10:04 PM, J. Liles  wrote:
>

quoted text
>

> On Wed, Oct 10, 2012 at 1:24 AM, Louigi Verona wrote:

>

>> Hey fellas!

>>

>> Would like to present an article I've written. Mostly wrote it to start a

>> conversation and hear what others have to say on the subject.

>>

>>

>> http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=linux_pro...

>>

>> You can comment here or on my textboard (which does not require

>> registration).

>>

>>

> Seems like a pretty negative outlook overall. Progress has definitely been

> slower than many of us would like, but that's understandable considering

> that most Linux Audio programs are maintained by single developers (with

> lots of other projects) or small groups. I'm surprised you didn't mention

> Luppp, libmapper, or the resurgence of ZynAddSubFX developement. I think

> the KXStudio project represents a *huge* amount of progress as far as

> integration and user experience goes.

>

> My personal frustration with Linux Audio is mainly focused on the

> seemlingly iron-clad (but flawed) JACK API. We've needed the ability to

> rename clients and have ports with arbitrary event payloads (to allow MIDI,

> OSC, or whatever other streams to be managed via the JACK connection graph

> and frame clock) for years. And, even though many proposals have been made

> and patches submitted, it doesn't look like the JACK API is ever going to

> be improved--which doesn't speak well at all for the future of modular

> audio on Linux (such improvements are unnecessary for monolithic

> applications such as Ardour since they duplicate all this functionality

> internally) . If an API is going to be fixed and rigid, it must also be

> extensible (like LV2).

>

> Still, I remain committed to improving Linux Audio and generally

> optimistic about the future.

>

>

--

Louigi Verona

http://www.louigiverona.ru/
--20cf303b39bdf4f58c04cbb852e3

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
"I'm surprised you didn't mention Luppp, libmapper, or the res=

urgence of ZynAddSubFX developement.Don't be - it is impossible=

 to mention everything :)But this is why I want to hear what other peop=

le say - crowd source approach ;)

On Wed, Oct 10, 2012 at 10:04 PM, J. Liles <=

span dir=3D"ltr"><malnourite@gmail.com> wrote:

On Wed, Oct 10, 2012 a=

t 1:24 AM, Louigi Verona <louigi.verona@gmail.com> wro=

te:
Hey fellas!Would like to present an article I've written. Mostl=

y wrote it to start a conversation and hear what others have to say on the =

subject.http:/=

/www.louigiverona.ru/?page=3Dprojects&s=3Dwritings&t=3Dlinux&a=

=3Dlinux_progress
You can comment here or on my textboard (which does not require registr=

ation).Seems like a pretty negative outlook overall. Progress has defi=

nitely been slower than many of us would like, but that's understandabl=

e considering that most Linux Audio programs are maintained by single devel=

opers (with lots of other projects) or small groups. I'm surprised you =

didn't mention Luppp, libmapper, or the resurgence of ZynAddSubFX devel=

opement. I think the KXStudio project represents a *huge* amount of progres=

s as far as integration and user experience goes. 
My personal frustration with Linux Audio is mainly focused on the seeml=

ingly iron-clad (but flawed) JACK API. We've needed the ability to rena=

me clients and have ports with arbitrary event payloads (to allow MIDI, OSC=

, or whatever other streams to be managed via the JACK connection graph and=

 frame clock) for years. And, even though many proposals have been made and=

 patches submitted, it doesn't look like the JACK API is ever going to =

be improved--which doesn't speak well at all for the future of modular =

audio on Linux (such improvements are unnecessary for monolithic applicatio=

ns such as Ardour since they duplicate all this functionality internally) .=

 If an API is going to be fixed and rigid, it must also be extensible (like=

 LV2).
Still, I remain committed to improving Linux Audio and generally optimi=

stic about the future.

-- Louigi Veronahttp://www.louigiverona.ru/
--20cf303b39bdf4f58c04cbb852e3--