Can anyone look speak to audio out? Is there any evidence of 5.1 support for line out? I know that DVD Player currently doesn't support it, but I'm hoping and praying that I can use my G4 as a home theater pc instead of having to build a winblows box. *ick*.
It just means (to me anyway) that Apple realized that their old solution was a hack, and has continued to work on the root problems instead of figuring that the previous solution was good enough. Apple has not always looked at things this way. </strong><hr></blockquote>
I can see your point, but the process of optimisation is often a series of hacks that sacrifice programming elegance for performance.
You start off doing things the cleanest and most general way, and then attempt to remove all of the bottleneck processes by rewriting or masking them.
I can see your point, but the process of optimisation is often a series of hacks that sacrifice programming elegance for performance.
You start off doing things the cleanest and most general way, and then attempt to remove all of the bottleneck processes by rewriting or masking them.</strong><hr></blockquote>
Absolutely... but at some point those hacks are not only no longer necessary, but are a major contributor to code cruft, and loss of time and resources. It's best to yank them out as soon as possible, and keep to a clean design wherever you can.
In my own code, and those of my students, I have the original clean design intact in the code, and the optimization as well, each *CLEARLY* marked with conditional compilation structuring (#ifdefs), so they can be re-tested at a later date, and reverted to a clean approach when appropriate. Makes the long term development process *much* easier. When the reversion is deemed appropriate, the hack is not only not compiled in, but is completely removed from the codebase for clarity. (It's always available via CVS, so we don't lose anything but a mess.)
Comments
Anyone?
edit: spilling...er...spelling.
[ 07-25-2002: Message edited by: tsukurite ]</p>
<strong>
It just means (to me anyway) that Apple realized that their old solution was a hack, and has continued to work on the root problems instead of figuring that the previous solution was good enough. Apple has not always looked at things this way.
I can see your point, but the process of optimisation is often a series of hacks that sacrifice programming elegance for performance.
You start off doing things the cleanest and most general way, and then attempt to remove all of the bottleneck processes by rewriting or masking them.
<strong>
I can see your point, but the process of optimisation is often a series of hacks that sacrifice programming elegance for performance.
You start off doing things the cleanest and most general way, and then attempt to remove all of the bottleneck processes by rewriting or masking them.</strong><hr></blockquote>
Absolutely... but at some point those hacks are not only no longer necessary, but are a major contributor to code cruft, and loss of time and resources. It's best to yank them out as soon as possible, and keep to a clean design wherever you can.
In my own code, and those of my students, I have the original clean design intact in the code, and the optimization as well, each *CLEARLY* marked with conditional compilation structuring (#ifdefs), so they can be re-tested at a later date, and reverted to a clean approach when appropriate. Makes the long term development process *much* easier. When the reversion is deemed appropriate, the hack is not only not compiled in, but is completely removed from the codebase for clarity. (It's always available via CVS, so we don't lose anything but a mess.)