Request: Naim UPNP server software
Posted by: 0rangutan on 19 November 2010
A simple request - please can Naim make their UPNP server implementation available to download/purchase?
There are likely to be a good number of customers who will not purchase the Serve, but would love a stable UPNP server with end to end compatibility with their HDX/NDX/Uniti/Qute.
Giving this away would make a big improvement to the Naim streaming ecosystem and resolve the majority of the (increasing number of) frustrated UPNP support postings. It will make the most difference for the non-techncial customers who don't know (or want to know) what UPNP is.
Charging to cover costs is potentially okay, just keep the price low enough to be considered a no-brainer.
Mac and Windows support essential. Linux and embedded NAS OS's much less so given the target audience and challenges associated.
Please.
There are likely to be a good number of customers who will not purchase the Serve, but would love a stable UPNP server with end to end compatibility with their HDX/NDX/Uniti/Qute.
Giving this away would make a big improvement to the Naim streaming ecosystem and resolve the majority of the (increasing number of) frustrated UPNP support postings. It will make the most difference for the non-techncial customers who don't know (or want to know) what UPNP is.
Charging to cover costs is potentially okay, just keep the price low enough to be considered a no-brainer.
Mac and Windows support essential. Linux and embedded NAS OS's much less so given the target audience and challenges associated.
Please.
Posted on: 01 December 2010 by Phil Harris
To try to clear up any confusion...
"Desktop Client" is a Windows Application which talks dierectly to any of our music server products - NS0x, HDX or UnitiServe - and allows direct control of what is being played through the audio outputs on the back of those units. This is not any sort of UPnP (proprietry or otherwise).
The Uniti, UnitiQute and NDX all have UPnP renderers (clients) included in them and require a UPnP server to supply them with data. The UPnP client built into the Uniti, UnitiQute and NDX is a "standard" UPnP client and as far as we are aware complies with the UPnP spec however we are very aware that there are many different interpretations of that spec (some UPnP servers don't work well with some UPnP clients) and so the UPnP client built into the Uniti / UnitiQute / NDX has been written to the same interpretation of the UPnP spec as the UPnP server built into the NS0x / HDX and UnitiServe. This way we know that these two units will operate correctly together.
If the end user wishes to use a 3rd party UPnP server then that is perfectly OK however then you get into the area of the UPnP standard not being very standard and may have issues - we do try to work with as many authors of third party UPnP servers as we can (and try to ensure our UPnP client works with as many UPnP servers as possible).
It is not practical for us to release the Naim UPnP server as a separate software product as the UPnP server application is very tightly tied in with the core software on the music server products.
The nServe and nStream applications for the iPhone / iPod Touch do not communicate with the Uniti / UnitiQute / NDX via any sort of UPnP protocol - those applications use our own Naim API which is completely separate to the UPnP interface.
Hopefully that clears up any confusion.
Cheers
Phil
"Desktop Client" is a Windows Application which talks dierectly to any of our music server products - NS0x, HDX or UnitiServe - and allows direct control of what is being played through the audio outputs on the back of those units. This is not any sort of UPnP (proprietry or otherwise).
The Uniti, UnitiQute and NDX all have UPnP renderers (clients) included in them and require a UPnP server to supply them with data. The UPnP client built into the Uniti, UnitiQute and NDX is a "standard" UPnP client and as far as we are aware complies with the UPnP spec however we are very aware that there are many different interpretations of that spec (some UPnP servers don't work well with some UPnP clients) and so the UPnP client built into the Uniti / UnitiQute / NDX has been written to the same interpretation of the UPnP spec as the UPnP server built into the NS0x / HDX and UnitiServe. This way we know that these two units will operate correctly together.
If the end user wishes to use a 3rd party UPnP server then that is perfectly OK however then you get into the area of the UPnP standard not being very standard and may have issues - we do try to work with as many authors of third party UPnP servers as we can (and try to ensure our UPnP client works with as many UPnP servers as possible).
It is not practical for us to release the Naim UPnP server as a separate software product as the UPnP server application is very tightly tied in with the core software on the music server products.
The nServe and nStream applications for the iPhone / iPod Touch do not communicate with the Uniti / UnitiQute / NDX via any sort of UPnP protocol - those applications use our own Naim API which is completely separate to the UPnP interface.
Hopefully that clears up any confusion.
Cheers
Phil
Posted on: 01 December 2010 by Phil Harris
quote:Originally posted by JLD:
I've see in the back of the unitiserve (manual page 6 http://www.naimaudio.com/userf...e_english_issue1.pdf) a mouse socket, a keyboard socket, a VGA display interface and even a serial (RS232).
3.2.1 Mouse Socket
Optionally connect a PS2 format mouse here to control
UnitiServe in combination with an external display.
3.2.10 Keyboard Socket
Optionally connect a PS2 format keyboard here to control
UnitiServe in combination with an external display.
3.2.9 VGA Interface
Optionally connect a VGA format screen here to display
the UnitiServe External Display Interface.
Is there someone here who have try to use these features?
We have used them here (of course) - what would you like to know?
Phil
Posted on: 01 December 2010 by JLD
Phil,
Thank you very much for this clarification:
I understand better a lot of things now.
And so I've several questions:
1- Is it possible for the developer to solve the volume problem of the foobar plugin?
In the specific case of the Foobar plugin (as already said thanks to the cooperation between naim and the developer the uniti's client works properly with this server/control point except for the volume setting)
Is there a way to provide a volume control if the command used by the client is adapted in the plugin?
2- nStream available for Mac and PC?
Well, my actual goal is to see what could be a correct solution for me to use my uniti with a Nas or an UnitiServe (or both).
Actually, my music is stored on PC hard drive.
I was thinking (before this very useful clarification) the logical solution should be to control the uniti directly from my PC with an Upnp control point. In this perceptive I've tried several UPnp server/ control point. (As the upnp naim's software is and will not available)
Now I understand that the best solution could be to use the nStream application (which is not an UPNP based software).
Providing these software for Ipod and Iphone products were laudable but this limit hugely...(especialy for me without any of these gadgets but Christmas is near) If these products should be available for classic Mac products and of course PC we would have numerous possibilities to remote controlling including touch screen laptops... This way we could use the uniti in several environments even with the same "extended remote control"
That why I've already asked to know if naim have planned to distribute nStream for Mac and windows platforms.
https://forums.naimaudio.com/ev...2903417/m/1812907637
Now, I think my question is very clever, isn't it?
Please let us know what is the naim position... I suppose these application could be delivered not free of charge, so this could be correct for all.
3- Comparison between server control vs player control
Thanks to Stevens Hopkins, I've found the Desktop Client Manual on the website.
So I've learned how to use the unitiserve with screen plugged on it.
In this perspective I think to use the Unity serve in my house (not at office) with a touch screen display for all family.
I haven't already compared this solution (control at server level) with the way described before (control at renderer level).
I suppose the main advantage of the first is to send different musics in several places...
Is it possible to give us a simple comparison?
4- Unitiserve and Nas
Last question:
I don't know if I can use the uniti serve as a Nas. Is it possible to store on it music file already ripped to avoid to have to re-rip again these disk?
If not how the uniti serve will work with a Nas on the network?
I was thinking to plug the uniti serve to my actual uniti with the best link (digital optical ?)
In the case where some file will be out of the serve box I suppose the stream of this nas will be made by network as Upnp stream, do you confirm?
I suppose this is not the best way to play and control. This returns to my previous point.
What is the your advise?
Cheers
Jean-Luc
Thank you very much for this clarification:
quote:The nServe and nStream applications for the iPhone / iPod Touch do not communicate with the Uniti / UnitiQute / NDX via any sort of UPnP protocol - those applications use our own Naim API which is completely separate to the UPnP interface.
I understand better a lot of things now.
And so I've several questions:
1- Is it possible for the developer to solve the volume problem of the foobar plugin?
In the specific case of the Foobar plugin (as already said thanks to the cooperation between naim and the developer the uniti's client works properly with this server/control point except for the volume setting)
Is there a way to provide a volume control if the command used by the client is adapted in the plugin?
2- nStream available for Mac and PC?
Well, my actual goal is to see what could be a correct solution for me to use my uniti with a Nas or an UnitiServe (or both).
Actually, my music is stored on PC hard drive.
I was thinking (before this very useful clarification) the logical solution should be to control the uniti directly from my PC with an Upnp control point. In this perceptive I've tried several UPnp server/ control point. (As the upnp naim's software is and will not available)
Now I understand that the best solution could be to use the nStream application (which is not an UPNP based software).
Providing these software for Ipod and Iphone products were laudable but this limit hugely...(especialy for me without any of these gadgets but Christmas is near) If these products should be available for classic Mac products and of course PC we would have numerous possibilities to remote controlling including touch screen laptops... This way we could use the uniti in several environments even with the same "extended remote control"
That why I've already asked to know if naim have planned to distribute nStream for Mac and windows platforms.
https://forums.naimaudio.com/ev...2903417/m/1812907637
Now, I think my question is very clever, isn't it?
Please let us know what is the naim position... I suppose these application could be delivered not free of charge, so this could be correct for all.
3- Comparison between server control vs player control
Thanks to Stevens Hopkins, I've found the Desktop Client Manual on the website.
So I've learned how to use the unitiserve with screen plugged on it.
In this perspective I think to use the Unity serve in my house (not at office) with a touch screen display for all family.
I haven't already compared this solution (control at server level) with the way described before (control at renderer level).
I suppose the main advantage of the first is to send different musics in several places...
Is it possible to give us a simple comparison?
4- Unitiserve and Nas
Last question:
I don't know if I can use the uniti serve as a Nas. Is it possible to store on it music file already ripped to avoid to have to re-rip again these disk?
If not how the uniti serve will work with a Nas on the network?
I was thinking to plug the uniti serve to my actual uniti with the best link (digital optical ?)
In the case where some file will be out of the serve box I suppose the stream of this nas will be made by network as Upnp stream, do you confirm?
I suppose this is not the best way to play and control. This returns to my previous point.
What is the your advise?
Cheers
Jean-Luc
Posted on: 01 December 2010 by okli
the discussions here start to look similar to the "Groundhog Day" film (watched it again a week ago) - we all request the same features and there is no reply. Hopefully the day we wake up and there is nobody outside, as in the film, will come soon...
Posted on: 01 December 2010 by Phil Harris
quote:
1- Is it possible for the developer to solve the volume problem of the foobar plugin?
In the specific case of the Foobar plugin (as already said thanks to the cooperation between naim and the developer the uniti's client works properly with this server/control point except for the volume setting)
Is there a way to provide a volume control if the command used by the client is adapted in the plugin?
It is not possible to use the UPnP volume commands to control the Uniti / UnitiQute volume as the volume of the unit is not controlled within the UPnP domain.
quote:
2- nStream available for Mac and PC?
Well, my actual goal is to see what could be a correct solution for me to use my uniti with a Nas or an UnitiServe (or both).
Actually, my music is stored on PC hard drive.
I was thinking (before this very useful clarification) the logical solution should be to control the uniti directly from my PC with an Upnp control point. In this perceptive I've tried several UPnp server/ control point. (As the upnp naim's software is and will not available)
Now I understand that the best solution could be to use the nStream application (which is not an UPNP based software).
Providing these software for Ipod and Iphone products were laudable but this limit hugely...(especialy for me without any of these gadgets but Christmas is near) If these products should be available for classic Mac products and of course PC we would have numerous possibilities to remote controlling including touch screen laptops... This way we could use the uniti in several environments even with the same "extended remote control"
That why I've already asked to know if naim have planned to distribute nStream for Mac and windows platforms.
https://forums.naimaudio.com/ev...2903417/m/1812907637
Now, I think my question is very clever, isn't it?
Please let us know what is the naim position... I suppose these application could be delivered not free of charge, so this could be correct for all.
It is highly unlikely that nStream (or nServe) will ever be ported to any other platforms other than the iPhone / iPod Touch / iPad (and any additional platforms that Apple deem to make compatible.
There is the Desktop Client application which runs under Windows to allow control of the local output(s) of an NS0x, HDX or UnitiServe and allows editing of music data, there is also the web interface to any of those units available by pointing a web browser at http:\\<server_ip_address> *AND* if you plug a display into the VGA / s-video or composite outputs of an of the music servers they also generate their own GUI for control via a remote (not supplied with UnitiServe).
quote:
3- Comparison between server control vs player control
Thanks to Stevens Hopkins, I've found the Desktop Client Manual on the website.
So I've learned how to use the unitiserve with screen plugged on it.
In this perspective I think to use the Unity serve in my house (not at office) with a touch screen display for all family.
I haven't already compared this solution (control at server level) with the way described before (control at renderer level).
I suppose the main advantage of the first is to send different musics in several places...
Is it possible to give us a simple comparison?
Desktop Client and the VGA "Local GUI" output are very different.
I'm not sure what you want by a "simple comparison" of server control vs player control ... the servers have a local audio output that is *NOT* under UPnP control and the Uniti range have built-in UPnP clients that draw data from a UPnP server such as the one built into the NS0x / HDX / UnitiServe.
quote:
4- Unitiserve and Nas
Last question:
I don't know if I can use the uniti serve as a Nas. Is it possible to store on it music file already ripped to avoid to have to re-rip again these disk?
If not how the uniti serve will work with a Nas on the network?
I was thinking to plug the uniti serve to my actual uniti with the best link (digital optical ?)
In the case where some file will be out of the serve box I suppose the stream of this nas will be made by network as Upnp stream, do you confirm?
I suppose this is not the best way to play and control. This returns to my previous point.
What is the your advise?
The UnitiServe will only store music that has been ripped on itself - you cannot copy downloaded music (or music ripped on other devices) to the UnitiServe and you should not attempt to "fudge" music onto the server as you can end up causing problems with the units own internal music databases.
If you have music from other sources then if they are available as a SAMBA Network Share then the Uniti will be able to access that share and read the music from it - it will then include that music within its own library but will not copy the music to its own storage. (Subject to the file formats being supported and appropriate login details specified wherever necessary.)
We would always try to dissuade the use of users PCs or Macs for storage of music files for the system as they tend to be turned on and off and go in and out of range if on WiFi.
The best "connection" between your Uniti and UnitiServe would surely be via Ethernet so that you can browse the music on your UnitiServe from your UnitiQute using just the nStream app?
I hope this helps...
Phil
Posted on: 01 December 2010 by Phil Harris
quote:Originally posted by okli:
the discussions here start to look similar to the "Groundhog Day" film (watched it again a week ago) - we all request the same features and there is no reply. Hopefully the day we wake up and there is nobody outside, as in the film, will come soon...
Hi Okli,
It's very easy to request features but if they aren't appropriate for inclusion in the device then that's a different matter.
Is there anything specific that you are referring to?
Phil
Posted on: 01 December 2010 by JLD
I thanks you very much Phil for this kind response.
I will only precise/comment shortly some of your informations.
nStream
Surely I were not very clear.
I distinguish two strategy:
A-focus on the player (uniti as upnp client can stream all music available on the network, in this case all we want is to be able to control the Upnp stream with a much better interface than the embedded one displayed on the monochromatic screen)
B-focus on the server (In this case there is a lot of additional feature required (ripping, organization, tagging etc than sending music on several players in the home.)
In the first situation the nStream question take all his sense:
I'm not sure to understand why the nStream app is reserved to apple mobile devices (IpadPodPhone).
If I understand correctly what you've said this application is the only way to control an uniti (/Qute) without a naim server. (Except of course, from classic remote)
(The Desktop client (or nServe) control only naim servers.)
Except if there is an arrangement betweenn Naim and apple which is absolutely understandable (at less for me) I do not see why other similar devices (android based) or little laptop. (mac or Pc)?
May I missed something here or can you be a little bit more clear?
Unitiserve AND Nas
I thank you very much for the explanation. I understand how unitiserve and Nas complement each other.
I not sure to understand what you mean in this sentence:
"then the Uniti will be able to access that share..." Do you mean the unitiServe? I suppose yes.
So when you said:
Why not using nServe (or desktop) and not nStream? If this as you said (sorry) this returns why we need nStream not only on apple devices (CQFD?)
Thanks again Phil, (I've seen this film, Okli, I suppose the day you were hoping is arrived but I can suppose our questions and request seems easy but difficult or simply impossible to address from a technical and commercial point of view )
Jean-Luc
I will only precise/comment shortly some of your informations.
nStream
quote:I'm not sure what you want by a "simple comparison" of server control vs player control ... the servers have a local audio output that is *NOT* under UPnP control and the Uniti range have built-in UPnP clients that draw data from a UPnP server such as the one built into the NS0x / HDX / UnitiServe.
Surely I were not very clear.
I distinguish two strategy:
A-focus on the player (uniti as upnp client can stream all music available on the network, in this case all we want is to be able to control the Upnp stream with a much better interface than the embedded one displayed on the monochromatic screen)
B-focus on the server (In this case there is a lot of additional feature required (ripping, organization, tagging etc than sending music on several players in the home.)
In the first situation the nStream question take all his sense:
quote:It is highly unlikely that nStream (or nServe) will ever be ported to any other platforms other than the iPhone / iPod Touch / iPad (and any additional platforms that Apple deem to make compatible.
There is the Desktop Client application which runs under Windows to allow control of the local output(s) of an NS0x, HDX or UnitiServe and allows editing of music data, there is also the web interface to any of those units available by pointing a web browser at http:\\<server_ip_address> *AND* if you plug a display into the VGA / s-video or composite outputs of an of the music servers they also generate their own GUI for control via a remote (not supplied with UnitiServe).
I'm not sure to understand why the nStream app is reserved to apple mobile devices (IpadPodPhone).
If I understand correctly what you've said this application is the only way to control an uniti (/Qute) without a naim server. (Except of course, from classic remote)
(The Desktop client (or nServe) control only naim servers.)
Except if there is an arrangement betweenn Naim and apple which is absolutely understandable (at less for me) I do not see why other similar devices (android based) or little laptop. (mac or Pc)?
May I missed something here or can you be a little bit more clear?
Unitiserve AND Nas
I thank you very much for the explanation. I understand how unitiserve and Nas complement each other.
I not sure to understand what you mean in this sentence:
quote:If you have music from other sources then if they are available as a SAMBA Network Share then the Uniti will be able to access that share and read the music from it - it will then include that music within its own library but will not copy the music to its own storage. (Subject to the file formats being supported and appropriate login details specified wherever necessary.)
"then the Uniti will be able to access that share..." Do you mean the unitiServe? I suppose yes.
So when you said:
quote:The best "connection" between your Uniti and UnitiServe would surely be via Ethernet so that you can browse the music on your UnitiServe from your UnitiQute using just the nStream app?
Why not using nServe (or desktop) and not nStream? If this as you said (sorry) this returns why we need nStream not only on apple devices (CQFD?)
Thanks again Phil, (I've seen this film, Okli, I suppose the day you were hoping is arrived but I can suppose our questions and request seems easy but difficult or simply impossible to address from a technical and commercial point of view )
Jean-Luc
Posted on: 01 December 2010 by Tog
Thanks Phil - this is why this forum is so useful. Now I understand what is going on and the separation between Naim apps and UPnP.
Cheers
Tog
Cheers
Tog
Posted on: 01 December 2010 by Alamanka
quote:
I'm not sure to understand why the nStream app is reserved to apple mobile devices (IpadPodPhone).
Most likely this nStream application is written using language, libraries, protocols that are specific to the Apple mobile platform.
In order to run Apple mobile application on a PC, it would require some sort of emulation program.
This is an idea for Microsoft or Apple, not for Naim.
In the meantime, if customers want a Windows application to control the NaimUniti, then probably Naim engineers would have to write a new application for Windows.
Then they would have to do the same for Android...
Those are good ideas and I fully support them.
But probably it simply boils down to a resource limitation on the Naim side. They probably do not have enough engineers to develop multiple applications. Therefore they had to make a choice and they went with Apple.
Personally I would have made a different decision, but I understand their rationale.
As someone said earlier, this is software business and Naim is learning how to play this new game.
Posted on: 01 December 2010 by okli
quote:Originally posted by Phil Harris:quote:Originally posted by okli:
the discussions here start to look similar to the "Groundhog Day" film (watched it again a week ago) - we all request the same features and there is no reply. Hopefully the day we wake up and there is nobody outside, as in the film, will come soon...
Hi Okli,
It's very easy to request features but if they aren't appropriate for inclusion in the device then that's a different matter.
Is there anything specific that you are referring to?
Phil
as already stated - nstream desktop / web client or some other way to be able to control naim media renderer's (qute / uniti) - excluding the remote, which nowadays seems "primitive way" and not bound to apples' iOS devices. On another thread - dedicated full naim API software package (server-control point-renderer), which benefits from support by naim and advanced features beyond the UPnP limitations. Actually, you can't bind this to a specific device - it's "simply" a matter of software package compatible with Naim's distributed audio product line and beyond this, because I'll highly appreciate, if I can control my Nait XS through the same client as well.
Posted on: 01 December 2010 by okli
quote:Originally posted by Alamanka:quote:
I'm not sure to understand why the nStream app is reserved to apple mobile devices (IpadPodPhone).
Most likely this nStream application is written using language, libraries, protocols that are specific to the Apple mobile platform.
In order to run Apple mobile application on a PC, it would require some sort of emulation program.
This is an idea for Microsoft or Apple, not for Naim.
In the meantime, if customers want a Windows application to control the NaimUniti, then probably Naim engineers would have to write a new application for Windows.
Then they would have to do the same for Android...
Those are good ideas and I fully support them.
But probably it simply boils down to a resource limitation on the Naim side. They probably do not have enough engineers to develop multiple applications. Therefore they had to make a choice and they went with Apple.
Personally I would have made a different decision, but I understand their rationale.
As someone said earlier, this is software business and Naim is learning how to play this new game.
Sorry Alamanka, but if you bind a strategical software to a specific OS, it is not a technical decision - it is commercial decision. You can be very flexible at the software side today and if you make so bad mistake as a software designer this will cost your job :-). And if I have to buy an Apple "i" device because this is the only way to control my qute I'd like to know it very clearly stated, because of the additional price I've to pay - these devices make app. 30% of the price of my Qute. Somehow I'm feeling cheated, reading Phil's statement above.
Posted on: 01 December 2010 by David Dever
What ever happened to practical constraints?
iOS devices are robust, inexpensive and sensible–building an entire control or automation system around Android would be a very dicey exercise, compared to Apple's controlled strategy which makes it very easy for developers to write once.
It is also (largely) PC/Mac desktop independent, which keeps p*ss-ant low-powered netbooks at bay, providing consistent performance rather than endless frustration.
The app is not required to operate the machine, nor is it exclusively required to queue streamed music to the digital media player board (for example, there are already some rudimentary UPnP™ Control Point apps for Android).
iOS devices are robust, inexpensive and sensible–building an entire control or automation system around Android would be a very dicey exercise, compared to Apple's controlled strategy which makes it very easy for developers to write once.
It is also (largely) PC/Mac desktop independent, which keeps p*ss-ant low-powered netbooks at bay, providing consistent performance rather than endless frustration.
The app is not required to operate the machine, nor is it exclusively required to queue streamed music to the digital media player board (for example, there are already some rudimentary UPnP™ Control Point apps for Android).
Posted on: 01 December 2010 by Tog
quote:Originally posted by David Dever:
What ever happened to practical constraints?
iOS devices are robust, inexpensive and sensible–building an entire control or automation system around Android would be a very dicey exercise, compared to Apple's controlled strategy which makes it very easy for developers to write once.
It is also (largely) PC/Mac desktop independent, which keeps p*ss-ant low-powered netbooks at bay, providing consistent performance.
The app is not required to operate the machine, nor is it exclusively required to queue streamed
music to the digital media player board.
On the subject of iOS and net books we can certainly agree.
Tog
Posted on: 01 December 2010 by JLD
I wouldn't comment anymore. Naim are very clever people and I think their decisions and choice are made carefully.
Thanks to them for this open forum.
David
Sorry, but if I understand, please do no reverse the way of thinking.
I(we?) never said a naim app is exclusively required to stream music. I've said the only one Naim application fully compatible requires an "i" apple device, and excuse me this is a limitation. (even if we can understand this...)
Regards
Jean-Luc
Thanks to them for this open forum.
David
quote:The app is not required to operate the machine, nor is it exclusively required to queue streamed
music to the digital media player board.
Sorry, but if I understand, please do no reverse the way of thinking.
I(we?) never said a naim app is exclusively required to stream music. I've said the only one Naim application fully compatible requires an "i" apple device, and excuse me this is a limitation. (even if we can understand this...)
Regards
Jean-Luc
Posted on: 02 December 2010 by Alamanka
quote:Originally posted by okli:
[...] if you make so bad mistake as a software designer this will cost your job
Now I understand why so many Austrian engineers are living abroad as expatriates.
quote:
And if I have to buy an Apple "i" device because this is the only way to control my qute I'd like to know it very clearly stated, because of the additional price I've to pay - these devices make app. 30% of the price of my Qute.
I think this statement is excessive for two reasons.
a) the nStram app is not the only way to control the Qute
b) the iTouch cost $220. Then you have to buy the nStream. Even with tax and shipping, the total cost should be around $300.
The Qute is now sold in the US for $2,500, which is equivalent to about $2,750 with tax.
So the cost ratio for the controller is closer to 10%
quote:
Somehow I'm feeling cheated, reading Phil's statement above.
Again, this is a bit too strong..
My view on this is different: although I am not currently using the nStream option, I like the fact that it is available if I choose to.
By the way, I wonder why are we having this discussion about control app...Was the initial topic not about server side?
Separately, do you know the name of those famous Austrian chocolates? I think they chose to use a music composer
Posted on: 02 December 2010 by okli
quote:Originally posted by JLD:
I wouldn't comment anymore. Naim are very clever people and I think their decisions and choice are made carefully.
Thanks to them for this open forum.
Davidquote:The app is not required to operate the machine, nor is it exclusively required to queue streamed
music to the digital media player board.
Sorry, but if I understand, please do no reverse the way of thinking.
I(we?) never said a naim app is exclusively required to stream music. I've said the only one Naim application fully compatible requires an "i" apple device, and excuse me this is a limitation. (even if we can understand this...)
Regards
Jean-Luc
exactly and I don't mind buying a software, but now I'm forced to buy HARDWARE, even there are several notebooks with Windows / Mac OSX and even a desktop computer at home already. Moreover, I'm limited to the small display, resolution, CPU and RAM of these devices compared to a normal notebook / desktop. And this limitations reflect the performance and the usability of the application, as already complained here in the forum.
I'm not complaining about iOS and am not saying that cheap netbooks are better than iPads, I'm saying that I already have good enough computer hardware and I want to be able to use it with my Naim system, as perhaps this is the case with 95% of the users here.
So, I hope Naim will re-think its options on this topic or should we wait for an iPad with Naim logo on its back right to the apple... "NaimPad"?
Posted on: 02 December 2010 by okli
quote:Originally posted by Alamanka:
[QUOTE]Originally posted by okli:
[...] if you make so bad mistake as a software designer this will cost your job
Now I understand why so many Austrian engineers are living abroad as expatriates.
quote:
And if I have to buy an Apple "i" device because this is the only way to control my qute I'd like to know it very clearly stated, because of the additional price I've to pay - these devices make app. 30% of the price of my Qute.
I think this statement is excessive for two reasons.
a) the nStram app is not the only way to control the Qute
b) the iTouch cost $220. Then you have to buy the nStream. Even with tax and shipping, the total cost should be around $300.
The Qute is now sold in the US for $2,500, which is equivalent to about $2,750 with tax.
So the cost ratio for the controller is closer to 10%
quote:
Separately, do you know the name of those famous Austrian chocolates? I think they chose to use a music composer
You mean
http://en.wikipedia.org/wiki/Mozartkugel ?
Posted on: 02 December 2010 by okli
quote:
a) the nStram app is not the only way to control the Qute
If you are aware of some other app could you please share it here?
Posted on: 02 December 2010 by okli
quote:
b) the iTouch cost $220. Then you have to buy the nStream. Even with tax and shipping, the total cost should be around $300.
The Qute is now sold in the US for $2,500, which is equivalent to about $2,750 with tax.
So the cost ratio for the controller is closer to 10%
And why should I spend 220 EUR for something I don't really need and which will stay on the sofa side by side with my wife's macbook, which she likes and uses all the time - try to convince her to fiddle with this small things, just to be able to play her favorite music, in the case my 2years kid doesn't throw it already away. So, my calculations are based on 1790 EUR for my Qute vs 599 EUR for iPad, thus the 30%...
Posted on: 02 December 2010 by okli
quote:
Now I understand why so many Austrian engineers are living abroad as expatriates.
No, this is because of the taxes, we have to pay here :-(
Posted on: 02 December 2010 by Phil Harris
quote:Originally posted by okli:quote:
b) the iTouch cost $220. Then you have to buy the nStream. Even with tax and shipping, the total cost should be around $300.
The Qute is now sold in the US for $2,500, which is equivalent to about $2,750 with tax.
So the cost ratio for the controller is closer to 10%
And why should I spend 220 EUR for something I don't really need and which will stay on the sofa side by side with my wife's macbook, which she likes and uses all the time - try to convince her to fiddle with this small things, just to be able to play her favorite music, in the case my 2years kid doesn't throw it already away. So, my calculations are based on 1790 EUR for my Qute vs 599 EUR for iPad, thus the 30%...
Just to be sure about this - you are aware that you don't *NEED* to buy an i-device to control the Uniti or UnitiQute aren't you? It is an *ALTERATIVE* interface, the UnitiQute and UNiti are both fully functional without iPad / iPod Touch / iPhone control.
If you like the additional flexibility that the i-device control gives you then it is completely up to you whether that flexibility is worth the expense (and if you have an i-device as many people already do then it becomes a much simpler decision).
Remember that control is not just limited to i-devices too - there are Crestron and AMX control interfaces too (curently in development).
Phil
Posted on: 02 December 2010 by okli
Yes Phil, I know that I can control Qute with the remote control, but you would agree that it is not very convenient way to browse your entire library on the Qute's display with the remote control. Therefore I purchased the n-stream application and installed it on my iPhone - it is limited due to the display and the performance is not very good, but anyway it is still better than the RC. But, when I'm not at home MY iPhone is always away as well - thus, I'd like the option to have normal desktop client for my family + the a.m. benefits of a desktop system. And IMO there are still much more people with desktop systems than with i-devices even here on this forum. The same with the Creston or AMX - why make the life more complex as it is already and make such installments, if the only part we need is a peace of software, installed in a couple of seconds on a normal computer?
Posted on: 02 December 2010 by Phil Harris
The general feedback that we have though is that *MOST* people don't want to use their computers to control their HiFi - they don't want to wait for machines to boot or be loading and switching tasks so this is why we wrote the i-app as that seemed to fulfill *MOST* peoples needs.
Crestron and AMX may not seem important to you of course but once again they are a very important player in the custom installation and integration market.
Phil
Crestron and AMX may not seem important to you of course but once again they are a very important player in the custom installation and integration market.
Phil
Posted on: 02 December 2010 by okli
Hi Phil,
reading the posts here since I've registered to the forum, I'm under the impression that providing n-stream on the desktop OR other platform is the MOST requested feature (and it wasn't me asking for this feature on this thread). But, if I'm the only one requesting this feature it could be ignored, of course, and I have to live without it, enjoying my Naim kit as it is at the moment and hope something to change in the future.
reading the posts here since I've registered to the forum, I'm under the impression that providing n-stream on the desktop OR other platform is the MOST requested feature (and it wasn't me asking for this feature on this thread). But, if I'm the only one requesting this feature it could be ignored, of course, and I have to live without it, enjoying my Naim kit as it is at the moment and hope something to change in the future.
Posted on: 02 December 2010 by Phil Harris
This thread itself was requesting that we release the UPnP *SERVER* software that we run on the UnitiServe / NS0x and HDX as a PC application - this isn't either nServe or nStream.
Maybe I've missed all the requests that you're referring to - we obviously get a huge number of "If only it did ..." - and believe it or not we do try to listen to requests but there has to be a significant case for implementing new facilities or porting aplications to new platforms as it's a hefty chunk of work.
Phil
Maybe I've missed all the requests that you're referring to - we obviously get a huge number of "If only it did ..." - and believe it or not we do try to listen to requests but there has to be a significant case for implementing new facilities or porting aplications to new platforms as it's a hefty chunk of work.
Phil