> Once you are used to reading and writing code like this it isn't a big > deal, but it's somewhat offensive to third parties trying to figure > out what the heck is going on.
Yes - you lose the clarity of expression of the algorithm, it becomes centred on expressing fixed point rather than expressing the algorithms. It's a bit like coding in assembler rather than C. Sure, you can do it once you are in the zone. Also it doesn't document why certain fixed point design decisions were taken, e,g, why we need a certain shift to get to a certain Q output format. To maintain or even read the code you need some one who (i) understands the algorithm (which is obscured by the macros) (ii) has fixed point DSP skills (iii) and can work out the fixed point design of this particular algorithm. There are very few people who have all of these skills. I can't help feeling that (ii) and (iii) can be automated to some extent, leaving the source code free to express just (i) - which is hard enough! So yes those sorts of macros are certainly one way to go. Probably the best way at the moment, and Speex and Opus are good examples that they work well in the right hands. Can't help feeling their might be a better way though ....... - David ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
