Le Mon, 28 Nov 2011 00:31:50 +0000, Harry van Haaren <[email protected]> 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." _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
