28 Nov
2011
28 Nov
'11
7:45 p.m.
Le Mon, 28 Nov 2011 00:31:50 +0000,
Harry van Haaren <harryhaaren(a)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."