Thinking of abandoning Naim after 35 years

"An alternative would be to buy something that can't connect to ALL THESE momentarily  WONDERFUL THINGS and sit glowering at it", complaining that it doesn't connect to these momentary wonderful things. 

It's quite non-PC but I have enjoyed listening off my iPad - on Shuffle.

It then appears as if I've found a station that plays music I like - while encouraging me to listen to tracks (and whole CDs) I have ignored for some time.

I want to listen to new music but I if I don't get the urge to buy I didn't really have the urge to listen (repeatedly).

Tedious for you clearly - absolutely fascinating and rewarding for me as a design engineer who was worked to contribute to some of these technologies and prototype platforms since the mid 90s for making multiple media  more available and accessable to the consumer.

I wouldn't assume it will 'settle down' - I expect the rate of change and innovation will increase... it has been doing so for the last 2 decades why should it settle down now?

Yes but things made by design engineers do not find their major market among design engineers.

The people who buy this stuff do like it to keep up to date - at least until they are out of the shop.

Witness the demise of the 'occasional table'.

Most engineers are consumers like everyone else...

But for most people (and professions)  I thinks its fair to say that the media consumption markets I have seen grow and thrive the most are those that have embraced  technologies and platforms that enable  choice, flexibility and personalisation ...  I expect that trend to continue.

Sorted. That's what I like in a product; choice, flexibility and personalisation. 

Dave

the demise of the 'occasional table'.

 

What a great name for an album, but by whom?

The Kinks?

Genesis?

SJB

Just read the new NAC 272 thread and following the links came by the report of Andrew on a visit to NAIM HQ where I read this interesting post "What’s more, the company is still recruiting more staff, and both in production and R&D: Trevor Wilson, who heads up research and development at Naim, explained that out of a total of around 35 people in his department, there are now nine staff working on core product software R&D, four more purely working on apps, and ‘an army of contractors’.

link: http://andreweverard.com/2015/...ing-naims-super-amp/

Seems ms to me NAIM is doing the right thing: beef up the software team. Something good oughta come out of this!

Indeed, I spoke to TJ at the Naim Soho event last year and he told me they were using mostly contractors for their software and application development.

Simon

That would help explain the dysfunctional output....

BR

Hmm.. really ? I think the quality of IT and software development contractors in the UK can be very high in my expieirience. Of course the resource does usually need to be led by a strong engineering architect. (TDA)

Simon

Don't disagree in principle, and it is all about leadership...

However, Naim have made too many fundamental (software/app) 'faux pas'  of late....

Need to do much better....and can/should do...

BR

Do Naim write there own software ? I have heard not!

Do Linn write there own software ? Yes, it is all done in house

There are staggeringly few companies that write all their own software - certainly not Linn, who have just announced they're going open source.

Software development just isn't like that in 2015, where concepts such as 'agile' are completely changing how it's done.  In general, these mean developers work on short cycles and use pre-written code, code tools, web services, third parties and other means to deliver new features at high speed. The idea of 'in-house' development is essentially non-existent in that context. You need excellent technical leaders and product owners, but the actual code can be done anywhere, and usually is. My company uses a team in Chennai which is awesome.

I was told by a reputable Linn dealer they do?

The most practical approach to this type of software development is to use contractors.

I have direct experience of this.

They probably have a core team in-house - as does Naim - but these days developers use pre-written chunks of code, web services and standards wherever possible and assemble them together using tools that manage the process. 

Think of it like getting a new kitchen installed. The supplier may assemble all its own kitchens using its own team, but does it manufacture every unit? Does it manufacture the hinges, the plastics, the taps? In practice, the supplier is reliant on third parties who've pre-made most of the components, and is therefore also reliant on the standard sizes and shapes they employ, otherwise nothing will fit together. The critical thing is to get the kitchen design right and use that supply chain of materials, discrete components and standards effectively, irrespective of whether the actual installers are salaried employees or contractors. 

It's basically the same with software. You're helped by, and constrained by, the component parts, tools and standards you're using, almost all of which were created by someone else.

In addition, these days most companies utilise at least some out-of-house development for reasons of budget, time-to-market and also the breadth of skills required. I would be very surprised if Linn didn't do that, and it would certainly be no mark of quality.

In general, I would recommend companies the size of Linn and Naim focus on the design of their software/firmware (ie features and functionality) and left specialists to assemble the parts, ideally adopting open standards and third party products wherever possible. Basically, don't reinvent the wheel unless you're sure you can improve on it.

I think you misunderstood what Linn's open-source approach implies - not that they would be using (consuming) off-the-shelf libraries, but they would be contributing more of their vertically-integrated network and audio rendering stack through OpenHome, for consumption by others.

There are very few specialist audio manufacturers that are fully vertically-integrated*, as most use some third-party resource for modular software and/or hardware sourcing.

As for contractors, there is a vanishing point where one needs to consider the long-term retention of key expertise in-house vs. the tax benefits of writing off the development expenses - for manufacturers lacking an (agile) software team and looking to get into new market areas, it'd be commercial suicide IMHO to farm out all of the work without some sort of capable, internal software project manager (just my 2p) to guide the process.

* - in Linn's case, mirroring their hardware manufacturing.

I got the implications of Linn's approach - but once you make your stack available to third parties, those third parties will build stuff that will end up contributing to the overall customer experience. And they will start to influence the APIs and layers below as well. It's an interesting approach for Linn - if it works, I wonder whether they're prepared for the consequences.

I agree about out-sourcing, although it's often not to do with tax but overall costs, time to market and quality - in particular for smaller companies whose core business is not software.

I also agree that you need some resources in-house or you're out-sourcing your strategy and control, which I think would be a mistake. My employer has in-house resources for overall project management, technical strategy and product ownership, but the 'scrum master', developers, UX and so on are all third party. We run two-week sprints, use control software (Pivotal) and constant communication. It works very well even though they're mostly in Chennai.

Phew, just trawled through this whole thread again and the full spectrum of opinion is well represented.  Seems to me the views range from; life isn't perfect so just live with interface limitations and think about the music, at one end of the spectrum, to; there are other solutions out there that are simpler, better and at least as musically engaging.

My conclusion?  In retrospect, I think using blind loyalty to the Naim badge and selecting the SuperUniti has turned out to be a mistake for me.  I wanted a clean, minimalist music player with sound quality that would bear comparison with my main system.  The Naim literature assured me that was just what I would get...

"Crowding so much audio technology in one place brings numerous challenges of component selection, circuit and component layout, power supply noise and microphony. Meeting such challenges however is second nature at Naim Audio and the expertise that brings solutions has long been part of the audio engineering culture. SuperUniti is a masterpiece of audio technology packaging.

The SuperUniti amplifier is derived from our reference integrated the SUPERNAIT 2. Its digital hardware is drawn from the NDX network player and its 24bit/192kHz capable DAC uses the same data-buffering jitter removal process as the Naim DAC. Along with drawing from the best existing Naim technologies, SuperUniti introduces a new technology of its own. Behind the traditional looking volume dial lies an advanced new control technology providing noise-free digital volume adjustment that varies its operating characteristic depending on how quickly the volume knob is turned. All this innovation offers you the simplicity of a one box solution with the performance the Naim badge guarantees."

With the benefit hindsight and looking at their website again I see a strong and positive focus on the hardware and I note the absence of any corresponding pride and enthusiasm for the software that is required to bring the hardware to life.  I was equally negligent in the auditioning process.

I've decided to select two or three good hi fi shops and submit my updated brief to them;

- A clean uncluttered music system

- High audio quality

- Able to play stored lossless music files, internet radio, spotify and connect with my television

- Includes or able to interface with a system that enables easy management of stored music

- A flexible, stable, intuitive interface for selecting and playing music from different sources

- The operative words here are quality, simplicity and useability

I'm going to have an open mind and open ears.  The best answer for me might still turn out to be Naim but it may equally be something else.  If it's something else, the SuperUniti will be on ebay.  If the new solution is very appealing, I'll get two and my HDX etc etc will also be on ebay.  Whatever the new answer is, I'm hoping it will see me through the next 35 years!

Best wishes, Dunstan

Hi Dunstan,

I think that it would be interesting to send those requirements to 2 or 3 good shops and see what they recommend.  Then, spend a decent amount of time with each -- enough time to really get to know both the sound and the user interface.  I'm interested in hearing your impressions.

I suppose that my short list of systems to evaluate that way would come from Linn, Meridian and Devialet.  The Baetis Reference server looks interesting too.  

Of course most of your 'wants' are highly subjective.  (The "intuitive interface" phrase gets tossed about a lot, for example.  It's in the eye of the beholder I submit.) I guess that's what makes this fun!  Let us know what you see and hear.

Very interesting wrap-up Dunstan, thanks! Looking at your brief, two considerations (perhaps three) come to my mind:

1) A valuable guideline towards  "A clean uncluttered music system", "A flexible, stable, intuitive interface", "simplicity and useability" is, in my view, separation of concerns. By "separation of concerns" I do not necessarily mean separation of components. A very integrated software can still implement a very clearcut distinction between software configuration and software usage. And highly integrated replay hardware can still support a very modular approach. And, the other way round, dedicated components can lack modularity.

2) A viable approach for judging how good or how bad a given (software, replay, management) system implements separation of concern is to consider the propagation of small changes. If a small (real or hypothetical) component modification or failure tends to trigger a cascade of effects throughout the whole system, then separation of concerns is usually not well implemented. The system is brittle. In contrast, designs that take separation of concerns seriously tend to be resilient. To make a concrete example, consider management and replay of music collections. Importing, tagging, converting, backuping belong to management. Searching, browsing, selecting, starting, pausing, resuming, reading liner notes, etc. belong to replay. One might of course be tagging while replaying. But I would expect these two activities to involve different tools and interfaces or, in the same application, clearly distinguishable pages or layers.

3) Another aspect of separation of concerns is flexibility. Separation of concerns tends to promote flexibility. Consider, again, the problem of tagging musical contents from the viewpoint of storage solutions. There are a number of excellent tools that support tagging: from lightweight, command-line tools (lltag) to comprehensive, full-fledged graphical tools with integrated conversions and playback capabilities (JRiver). You do not want storage solutions that prevent you from using any of theese tools. You want to be able, if you fancy to do so, to spend a rainy afternoon during a long holiday in a remote place cleaning up your music library at home if you happen to have an half decent internet connection. For this a remote login and rsync or lltag should be enough.

A final remark on "usability". Connecting a TV, an iMac or a laptop to a music system (via optical SPDIF, for instance), increasing or decreasing the replay volume, muting replay, etc. are all controls for which I would do not want to have to rely on a computer program. A plain Naim remote control should suffice. This is, I believe, another incarnation of the idea of separation of concerns, and of another most eminent principle: "Everything should be made as simple as possible, but not simpler". How many replay system solutions take these principles halfway seriously ?

Rococo? 

Do you like what you hear from your objective piece of kit? If yes, then don't worry about all the under the cover stuff. The Muso does truly sound very good and I am bemused at the endless talk of software  development. In the beginning and in the end is the DAC. Much of the output colour and subtlety will be delivered by the DAC, hence the eulogies about the Chord Hugo. As long as Naim add good value to what comes out of the DAC they should continue to have a good market. Anyway, will get to assess some of this kit tomorrow at the Marriott Hotel Bristol, hope it's more successful than the restaurant I had booked for this evening which appears to have gone bust between booking and arriving.