> To offer an example and bring this thread back on topic:
Please. No more "my code is better than your code" discussions.
> - How long have we been waiting for the 650?
>
3 1/2 years. Part of it is waiting of software, part of it was the programmers
were waiting on ME to get them stable development platforms. Part of it was the
uP vendor(Atmel) had massive bugs in the first silicon (thich was actually
Temic/Philips silicon) and we had to wait 9 months for them to ship fixed parts.
> Paul clearly understands the product. There are, what, 2 maybe 3 people
> involved with it's development (I'm guessing from what I've read in Paul's
> posts).
Mostly accurate. I think the RC1 code is 98% "bug free", there are still things
that need to be resolved but the software is certainly ∗useable∗.
Now the burden is more on me to ship that the coders to fix.
>
> I get the sense that most of us are here because of the quality. If that's
> the case, then our loyalty agrees with Paul to the extent that he makes
> decisions that do not compromise quality. That's part of the price we pay
> to do business with him.
>
Well, that IS accurate :)
>
> Now I'd like to weigh-in on the new Audio Engine direction, since MOTM is
> taking a path straight into major software territory. Here's some questions
> for Paul which he may or may not choose to answer, but they are what's on my
> mind:
Aw heck, why not? :)
>
> - What happens to all of this if the Xilinx guru gets hit by a bus? And as
> we painfully know in MOTM-land, it's already happened to some extent.
>
And what happens when ∗I∗ get hit by the police car responding to the bus
accident?
Actually, there are literally 100s of good Xilinx programmers. The "software"
that we will be using will be mostly Verilog. There may be portions of code
written in another language called VHDL.
The ARM 7 part will be programmed in C.
All of this "source code" gets compiled into binary images that the part uses to
operate. The binary images will ALWAYS be available for FREE on the website.
Just like the MOTM-650 images are there now. So, you can ALWAYS get the code in
there. Now, in order to get the code "into" the AudioEngine, that will be a
2-part process, require 2 special cables (about $20 each) and code on your PC
(don't EVEN start with Mac on this one). But it is doable.
And I'm not a shabby Verilog programmer, either.
> - These modules are going to be software black boxes. With the circuit-based
> modules, I have a reasonable chance of fixing something if it wonks-out. The
> Audio Engines sound like they're going to be throw-aways if something goes
> wrong, especially in or around the chip. This is true for many of us
> regarding SMT, too. Maintainability in the field has been an unsung attribute
> of MOTM
> gear thus far.
>
I don't disagree, but on the other hand, that is NOT A REASON to just stop on
Dec. 31st and say "Well, it's been fun. See ya!"
The ∗reality∗ is: SMT parts are cheaper, easier to get, easier to store, are
RoHS compliant and not THAT BAD to work with. For many people, just saying 'SMT'
provokes the same reaction as saying 'Calculus'. It's not that bad once you
understand it. Soldering SOICs is easy. Soldering 1206 and 0805 passives are
easy. 0603s are tricky, but use fine 0.015 solder and still not bad. And trust
me, if you are worried about repair 15 years from now, you will WANT SMT!
> - What's going to happen when someone like Ken finds a niggle in the code,
> but 80-90% of the rest of us don't really need that or care? Is the firmware
> going to be updated anyway? Or will time and effort (cost) mean that Ken or
> whomever just has to live with the shortcoming?
This is true with ANY software system. But it didn't deter Yamaha from selling
320,000 DX-7s, either :)
> Remember - the end user will not be able to mod or patch these things
> themselves like many have done with
> the hardware-based modules.
>
I don't disagree, but your definition of 'many' and mine will probably differ :)
> - No design can do it all. All modules have their "sweet spot." At the end
> of the day, I'm curious about how the Audio Engine modules will sound. MOTM
> today means quality in construction and sound. Paul (and Jeurgen, and other
> collaborators) has been nothing short of brilliant in bringing MOTM to us.
> But this is new territory. I'm not thinking too much about this one because
> of Paul's track record, but you never know.
>
Well, let's cross that bridge when we come to it. In fact, I am waiting for the
flip-side: people will think the SMT modules sound better :)
Paul S.