QUOTE(TBeck @ Mar 5 2008, 05:00)
QUOTE(skamp @ Feb 25 2008, 02:55)
QUOTE(Daniel Beaver @ Feb 23 2008, 21:48)
QUOTE(Bourne @ Feb 23 2008, 14:34)
I'm dying to get the Linux port...
Me too. What kind of effort would that take?
It would take Thomas letting go of his baby and one or two enthusiastic developers who could contribute *their* free time. I fully understand that Thomas has other priorities in life (family (?), work), but refusing help for now makes the point moot. He's been developing his codec for over 10 years, made his first announcement here almost two years ago, and us non-Windows users keep drooling over it, waiting for a port. One year ago we were told to be patient. How much longer? David Bryant found people to port WavPack to linux and write a plugin for XMMS... Now it's even supported by other players.
For the priorities: Well, i don't think someone who has also to work a bit for money could spend more time on a project as i on TAK... If you have got the impression, my dedication to TAK has decreased: That's wrong. Possibly one can get this impression, because now there is less discussion about TAK (because i am no longer releasing evaluation versions to test new optimizations).
For the 10 years: It did take so long, because i did so much (several thousand hours), not because of a little priority. TAK contains a couple of very new technologies.
QUOTE(skamp @ Feb 25 2008, 02:55)
I'm worried that Thomas may miss the train again because of his reluctance to release the code in its current state, all these feature requests that he's considering, his plans to switch to C++ and Object Oriented Programming, etc... Hashing can be done by piping raw PCM output to a hashing utility. Tagging can be implemented by encoding software, tagging software, or even a wrapper shell script. Cue sheets can be used externally. Artwork is taken care of by APEv2, hence relates to tagging support. More to the point, all of these features have little to do with major format changes, and could easily be developed on a multi-platform codebase. Delaying a souce code release by however much time it would take for a single, already busy person, to implement those features sures sounds like a bad idea to me.
I am preparing a port from an object oriented to a procedural approach (not the other way round) to make an implementation in standard C possible.
I would love to hear the opinion of other developers on whether moving to procedural is the best way to approach the Delphi-to-C conversion problem.
QUOTE
For the other features: Users are asking for them and the other lossless compressors have them. Without them TAK will always look bad in feature comparisons and some people will get the feeling, TAK isn't mature.
QUOTE(skamp @ Feb 25 2008, 02:55)
Now that I think of it, I wonder if FLAC didn't get such good support on Free operating systems and playback software in part thanks to Josh's extensive work in documentation and portability.
Absolutely right and -i fear- a very good argument to support my position...
It doesn't make much sense to release source code which isn't clean and lacking a good documentation. Not if you want widespread support. I think there is quite a lot of developers who would be excited when i release the source code. I don't want them to be disappointed because of bad code or documentation. A bad release could kill their motivation and i don't think i would get a second chance to attract developers.
Also very important: I am working as a self employeed developer and if i release bad source code, this will hurt my reputation!
If
that is your reason for not going open source, then I will not support you on this!
Messy and undocumented code means a high barrier of entry for developers. That does not mean it is not worth publishing it. Besides, if said developers can observe that the code is getting tidier and more annotated over time, that is a great boost for their confidence. They will know that it is worth getting used to the structure and style of coding, even maybe suggest some changes.
You can delegate tasks to them that do not require a high level of understanding of the code.
As for your public image, I do not see how being known as the developer of
the new lossless codec everyone talks about is going to damage it.
Do you have no better reason for keeping the code to yourself?
Do like everyone else, just ignore requests you can't/won't fulfill. And more importantly: don't apologize for it.