[LAD] Linux Audio Documentaion Effort : (Was "Question 0")

[Dominique Michel]

Le Mon, 28 Nov 2011 00:31:50 +0000,
Harry van Haaren <harryhaaren at gmail.com> a écrit :

> I think some "beginner" coding documentation on Linux Audio would be a
> great asset to the community, and I'm willing to contribute to such an
> effort. As Robin Gareus mentioned in another thread, a "FLOSS" manual
> is probably the best way to go for a community effort on documenting.

It is a very good idea.

> 
> Personally I'd be even more enthusiastic about such an effort if some
> of the veteran Linux audio guys were to get on board and ensure the
> content is of a high quality. (As I'm a self though programmer, there
> are some big gaps in my knowledge, and I'd not like to provide bad
> sample code, or share bad concepts.)

I will be very interested because I have some basic skills (basic,
assembler, bash) but never get enough time to learn the C/C++ and the
other needed skills in order to become an audio programmer on a modern
system. I have  a working note recognition software (monophonic
realtime Audio to MIDI conversion) on a dsp56k, and would like to port
it to C/C++ on linux. It will need a GUI in order to be easily usable
with so many sound sources (musical instruments) than possible.

It is so many things to learn for me (C/C++, JACK, some toolkit,
threading, ...) than I never was able to see how to process to learn
all that in the little amount of free time I have. A good audio
tutorial will be definitely a great asset, not only for me, but
also for the whole community.

> 
> Of course some issues will arise in choosing how to document Linux
> Audio, and some typical "flame" topics like GUI toolkits, libraries
> etc will arise. I have no idea how we can best avoid that issue,
> except by following the "if you think it should be thought that way
> write the tutorial"...  the downside of this is that if one tutorial
> uses toolkit <X> and the next toolkit <Y>, the average beginning
> coder is going to get lost in implementation details and that defeats
> the purpose of documentation :D

A toolkit is about visual presentation and interaction with the core
of the software. Whichever toolkit you choose, you will have to learn
the same things, but in a different manner. So, I think that you need
first to focus on the core and only after look on its interactions with
the toolkit. Also, depending to the goal of a given program, the
interactions between the core and the toolkit will be more or less
deep, and they will interfere on the core more or less deeply. I think
that deeper those interactions are, more it will be important to have
good coding skills. But the problem to solve will always be the same:
a goal to reach, a core and its interactions with a toolkit.

Dominique

> 
> -Harry


-- 
"We have the heroes we deserve."