I remember this theory being put to someone from Muse. They rejected it, arguing that the difference in price wouldn't have been a significant percentage of the price of a Receptor. They said it was about freedom to modify the OS. I think.UltraJv wrote:I can see why Muse used Linux, it made the unit cheaper. IMHO the way to go would have been Windows XP embedded. This is a custom install of XP with no extras. The problem with doing it the Windows way is that it would have been more costly. The tradeoff is price vs compatibility.
Has anyone heard from Muse lately?
- KVRAF
- 1665 posts since 22 Oct, 2004 from Schmocation
-
- KVRist
- 173 posts since 3 Sep, 2007 from CT
I'm guessing Ivory iLOK and Kontakt Player Libraries will be demoed at NAMM. Maybe EastWest Play and Omnisphere on the new hardware.
I'm not sure there's much to be said if they don't deliver on the newer iLOK libraries and Kontakt Player libraries.
I agree making the installler specs public and having an examples library would be a way to take advantage of developer good will Open Source style.
It's a competitive environment and I'm sure Muse knows they can't stand still or simply offer hardware upgrades.
It's a pretty impressive product as it it. The IK stuff, Komplete, existing East West Kontakt libraries, Ivory, the Soundfont.it stuff, and many others like Cameleon, Firebird, Linplug synths, Trilogy, etc make it more versatile than any hardware synth rack.
I'm not sure there's much to be said if they don't deliver on the newer iLOK libraries and Kontakt Player libraries.
I agree making the installler specs public and having an examples library would be a way to take advantage of developer good will Open Source style.
It's a competitive environment and I'm sure Muse knows they can't stand still or simply offer hardware upgrades.
It's a pretty impressive product as it it. The IK stuff, Komplete, existing East West Kontakt libraries, Ivory, the Soundfont.it stuff, and many others like Cameleon, Firebird, Linplug synths, Trilogy, etc make it more versatile than any hardware synth rack.
-
- KVRist
- 38 posts since 1 Feb, 2005
I fall on both sides of this debate. As a hardware synth, Receptor is exceptional as my goto piano, Rhodes, B3, Moog and guitar front end. It has excellent latency and stability running Komplete 5 and insulates my Pro Tools DAW from typical softsynth instability. In this regard I really like it.
On the other hand, I'm patiently waiting for Korg Legacy Digital Edition to run in Receptor, as this is a real resource hog in RTAS. I'm also waiting for VI.One, and too often I read about some new softsynth that gets rave reviews but does not run in Receptor. I would like a more open platform, but only if this does not create its own set of problems.
On the other hand, I'm patiently waiting for Korg Legacy Digital Edition to run in Receptor, as this is a real resource hog in RTAS. I'm also waiting for VI.One, and too often I read about some new softsynth that gets rave reviews but does not run in Receptor. I would like a more open platform, but only if this does not create its own set of problems.
-
- KVRAF
- 6323 posts since 30 Dec, 2004 from London uk
Interesting viewpoint. I mentioned Windows XP embedded , this is not standard XP and allows modification in every way possible. I would have to ask what thier freedom to modify Linux is doing for them and thier customers that this cannot? Using it would have got rid of all the compatibility issues in one go.skipscada wrote:I remember this theory being put to someone from Muse. They rejected it, arguing that the difference in price wouldn't have been a significant percentage of the price of a Receptor. They said it was about freedom to modify the OS. I think.UltraJv wrote:I can see why Muse used Linux, it made the unit cheaper. IMHO the way to go would have been Windows XP embedded. This is a custom install of XP with no extras. The problem with doing it the Windows way is that it would have been more costly. The tradeoff is price vs compatibility.
Windows XP embedded :
http://www.microsoft.com/windowsembedde ... fault.mspx
- KVRAF
- 5948 posts since 19 Jun, 2008 from Melbourne, Australia
From some work I did on an embedded system a couple of years back (industrial printers), I recall that the cost of licensing WindowsCE (the embedded version of Windows previous to XP) was something like $6 per seat, or machine sold. Not a very significant amount of money by any means for an end product that is priced in the thousands (both the printers and Receptor).UltraJv wrote:Interesting viewpoint. I mentioned Windows XP embedded , this is not standard XP and allows modification in every way possible. I would have to ask what thier freedom to modify Linux is doing for them and thier customers that this cannot? Using it would have got rid of all the compatibility issues in one go.skipscada wrote:I remember this theory being put to someone from Muse. They rejected it, arguing that the difference in price wouldn't have been a significant percentage of the price of a Receptor. They said it was about freedom to modify the OS. I think.UltraJv wrote:I can see why Muse used Linux, it made the unit cheaper. IMHO the way to go would have been Windows XP embedded. This is a custom install of XP with no extras. The problem with doing it the Windows way is that it would have been more costly. The tradeoff is price vs compatibility.
Windows XP embedded :
http://www.microsoft.com/windowsembedde ... fault.mspx
As for development requirements sure, Microsoft lets you "customise" Windows XP embedded, but it does not affect the basic operations and driver model used by Windows. What it mostly relates to is the individual components that get installed (e.g. don't install all the fonts, or the chat client as <x> product does not need them). This will affect the overall size of the OS installed, reducing the footprint on disk - an important money saving technique if the "disk" that you are booting and running from is static RAM (aka Solid State Disks), which is far more expensive that regular RAM. Obviously it also impacts the amount of regular RAM required at run time.
In the case of Receptor, where the OS is installed on the HD (cheap in comparison to SSD's) the static RAM is not the issue, but reducing the size of the OS in memory at run time is crucial because it determines the amount of RAM available for sample libraries, which clearly needs to be maximised.
Then we have to consider performance, and Windows XP does a lot of stuff that is definitely not related to audio.
The Muse developers absolutely are spot on with their choice of Linux. You have full control over every aspect of the source code and hence how OS works at the lowest levels i.e. exactly what it does with valuable clock cycles. If you know your stuff and you want to modify a kernel level routine because it will significantly improve audio performance for a bespoke device like the Receptor, Linux is the only realistic choice you have. They will most likely be able to control the way various drivers work too, which could improve performance dramatically. You will never get this level of control with Windows.
Linux in its various guises is the OS of choice for embedded systems with good reason, and I hope the above makes that clear!
Yes it's a shame that this might cause problems with <x> plug in, but I'm sure there is no conspiracy at play here, or that Muse are making these decisions for a laugh. It makes very real sense that they have chosen to run on Linux, and I'm impressed with what they have achieved. As Linux improves over time, the situation for various plugs will improve also. When you have a problem with MS products, mostly they aren't interested unless you are a major player like a bank or similar.
Note: I do not own a Receptor, but I am seriously considering one for studio use as my Laptop performance is degrading over time as I am now using much more powerful plugs than I have in the past.
The main question I have that I cannot find an answer to is "how many instances of <x> plugin can I run on Receptor before it starts to grind"? "<x>" plugins being Albino, Zebra, Blue plus a few FX. I know the question relates to patch complexity, and lengths of a piece of string etc., but if someone had general statement to make about this kind of detail I would appreciate it.
Peace,
Andy.
-
- KVRAF
- 6323 posts since 30 Dec, 2004 from London uk
Ah, perhaps youve heard of the Open Labs Neko/Miko series? They use XP with no issues so I have to balance the reasoning of using Linux once again.ZenPunkHippy wrote:From some work I did on an embedded system a couple of years back (industrial printers), I recall that the cost of licensing WindowsCE (the embedded version of Windows previous to XP) was something like $6 per seat, or machine sold. Not a very significant amount of money by any means for an end product that is priced in the thousands (both the printers and Receptor).UltraJv wrote:Interesting viewpoint. I mentioned Windows XP embedded , this is not standard XP and allows modification in every way possible. I would have to ask what thier freedom to modify Linux is doing for them and thier customers that this cannot? Using it would have got rid of all the compatibility issues in one go.skipscada wrote:I remember this theory being put to someone from Muse. They rejected it, arguing that the difference in price wouldn't have been a significant percentage of the price of a Receptor. They said it was about freedom to modify the OS. I think.UltraJv wrote:I can see why Muse used Linux, it made the unit cheaper. IMHO the way to go would have been Windows XP embedded. This is a custom install of XP with no extras. The problem with doing it the Windows way is that it would have been more costly. The tradeoff is price vs compatibility.
Windows XP embedded :
http://www.microsoft.com/windowsembedde ... fault.mspx
As for development requirements sure, Microsoft lets you "customise" Windows XP embedded, but it does not affect the basic operations and driver model used by Windows. What it mostly relates to is the individual components that get installed (e.g. don't install all the fonts, or the chat client as <x> product does not need them). This will affect the overall size of the OS installed, reducing the footprint on disk - an important money saving technique if the "disk" that you are booting and running from is static RAM (aka Solid State Disks), which is far more expensive that regular RAM. Obviously it also impacts the amount of regular RAM required at run time.
In the case of Receptor, where the OS is installed on the HD (cheap in comparison to SSD's) the static RAM is not the issue, but reducing the size of the OS in memory at run time is crucial because it determines the amount of RAM available for sample libraries, which clearly needs to be maximised.
Then we have to consider performance, and Windows XP does a lot of stuff that is definitely not related to audio.
The Muse developers absolutely are spot on with their choice of Linux. You have full control over every aspect of the source code and hence how OS works at the lowest levels i.e. exactly what it does with valuable clock cycles. If you know your stuff and you want to modify a kernel level routine because it will significantly improve audio performance for a bespoke device like the Receptor, Linux is the only realistic choice you have. They will most likely be able to control the way various drivers work too, which could improve performance dramatically. You will never get this level of control with Windows.
Linux in its various guises is the OS of choice for embedded systems with good reason, and I hope the above makes that clear!
Yes it's a shame that this might cause problems with <x> plug in, but I'm sure there is no conspiracy at play here, or that Muse are making these decisions for a laugh. It makes very real sense that they have chosen to run on Linux, and I'm impressed with what they have achieved. As Linux improves over time, the situation for various plugs will improve also. When you have a problem with MS products, mostly they aren't interested unless you are a major player like a bank or similar.
Note: I do not own a Receptor, but I am seriously considering one for studio use as my Laptop performance is degrading over time as I am now using much more powerful plugs than I have in the past.
The main question I have that I cannot find an answer to is "how many instances of <x> plugin can I run on Receptor before it starts to grind"? "<x>" plugins being Albino, Zebra, Blue plus a few FX. I know the question relates to patch complexity, and lengths of a piece of string etc., but if someone had general statement to make about this kind of detail I would appreciate it.
Peace,
Andy.
http://www.openlabs.com/products.html
- KVRAF
- 5948 posts since 19 Jun, 2008 from Melbourne, Australia
Ta for the heads up, interesting concept.UltraJv wrote:Ah, perhaps youve heard of the Open Labs Neko/Miko series? They use XP with no issues so I have to balance the reasoning of using Linux once again.
http://www.openlabs.com/products.html
My immediate reaction to the Open Labs Neko is that it's a completely different product. It's a full workstation running the DAW, like a highly customised laptop. It also costs 2 to 3 times as much as the equivalent Receptor putting it well outside the reach of most, except for the really pro pro's.
My second reaction to the Open Labs Neko is that ... it's a completely different product, it's not even designed to compete with Receptor, it's in a different league. Would you compare a Korg MS2000 to a Roland V-Station? Probably not ... (note, I'm not intending to compare a Receptor to the Korg!!!!!!).
The Neko box a full blown computer with a customised hard case integrating a musical keyboard, touch screen monitor and regular keyboard. No wonder it's expensive!! The question of running XP is valid because without the full OS you could not even consider running Cubase or any other fully functioned DAW "ITB", except Reaper.
Really it makes my argument above all the more valid. The Receptor is not running Windows to run Cubase. It is concerned with running plugins and sample libraries with minimum latency and highest throughput of audio / midi data.
You are comparing apples to oranges. Ok, pears to oranges as Apples are another kettle of fish entirely.
Peace,
Andy.
-
- KVRAF
- 6323 posts since 30 Dec, 2004 from London uk
Fair comment - Ill withdraw from further posts otherwise it will turn into an OS wars thread 
-
- KVRist
- 184 posts since 28 Apr, 2004
I agree with MWGilbert (et al) about the lack of updates on where things are at on supporting new VSTs. I had originally thought this thread was more or less a "are Muse going out of business" thread, but I guess my aim was a little off the mark.
I originally purchased a Rev.B unit a few years back, and last Christmas '07 I made the stupid mistake of upgrading it to Pro Jr. I have now in effect dumped $3,000 into what has become a machine used to house BFD and very little else.
All of the VSTs that I have particular interest in are currently not supported (big surprise) and I feel very much the same as the rest of you concerning last year's annoucement of Direct Install. It was absolutely announced and marketed as a "one size fits all" solution for installing practically ANY new/old commercial/non-commercial VST available, and it was supposed to have helped them simplify their own install process.
What the Receptor has become for me is something that promised a lot, and has ultimately delivered very little in the course of the past four years.
As for what I personally plan to do in the future? I will continue to use my Receptor for BFD, and will continue to hope that the future is brighter than the past has been. This irritation has not slowed down my own development as a musician/composer, but it has certainly made me kick my own arse for not having simply built a glorified rackmount WINXP box, that would ultimately be faster, easily upgradeable and something that does not crash either during gigs or in the studio.
Cheers!
projektio
I originally purchased a Rev.B unit a few years back, and last Christmas '07 I made the stupid mistake of upgrading it to Pro Jr. I have now in effect dumped $3,000 into what has become a machine used to house BFD and very little else.
All of the VSTs that I have particular interest in are currently not supported (big surprise) and I feel very much the same as the rest of you concerning last year's annoucement of Direct Install. It was absolutely announced and marketed as a "one size fits all" solution for installing practically ANY new/old commercial/non-commercial VST available, and it was supposed to have helped them simplify their own install process.
What the Receptor has become for me is something that promised a lot, and has ultimately delivered very little in the course of the past four years.
As for what I personally plan to do in the future? I will continue to use my Receptor for BFD, and will continue to hope that the future is brighter than the past has been. This irritation has not slowed down my own development as a musician/composer, but it has certainly made me kick my own arse for not having simply built a glorified rackmount WINXP box, that would ultimately be faster, easily upgradeable and something that does not crash either during gigs or in the studio.
Cheers!
projektio
- KVRAF
- 5948 posts since 19 Jun, 2008 from Melbourne, Australia
A wise move, as everyone knows that "my" operating system is better than "yours"UltraJv wrote:Fair comment - Ill withdraw from further posts otherwise it will turn into an OS wars thread
*ahem* besides all that, can anyone say what the general performance of Receptor is like? Is it like having one, two or three extra laptops under the desk? Or more like half a laptop?
Hmm, seems that reliability is a problem with Receptor?! I guess my original post was generally coming from a technical background, rather than a "live on stage in the heat of the battle" POV. Crashes are what these things are supposed to avoid!
Peace!
Andy.
-
- KVRist
- 184 posts since 28 Apr, 2004
I am no technical guru. but I have to believe that the crashes the Receptor experiences come more from the Linux programming side of things, and less from the hardware side. Although I did hear about a couple of issues with the PSU overheating, but not enough to raise my eyebrows.ZenPunkHippy wrote:Hmm, seems that reliability is a problem with Receptor?! I guess my original post was generally coming from a technical background, rather than a "live on stage in the heat of the battle" POV. Crashes are what these things are supposed to avoid!
Peace!
Andy.
projektio
-
- KVRian
- 691 posts since 13 May, 2004 from Silicon Valley
Hi Andy,
gregh1 did some benchmarking of Kontakt performance on Receptor Pro units in this thread.
In general, VSTi samplers using ram will give very good performance, and you will be able to put the most of these on Receptor channels. Streaming sampler VSTi's - less so, but still better than compute intensive plugins (like analog synth emulations). Emulative VSTi's can drag a Receptor to it's knees, and I have not been able to use much more than 4 of these simultaneously.
The good news is that you can mix and match VSTis on different channels, and typical playing activities never have you stacking much more than 4 Midi channels of notes at exactly the same time. I often have Receptor multis configured with 8-10 instruments, by which I am triggering from 3-4 midi keyboards. I often switch instruments by switching midi zones on the controllers.
Hope this helps,
Kevin L
gregh1 did some benchmarking of Kontakt performance on Receptor Pro units in this thread.
In general, VSTi samplers using ram will give very good performance, and you will be able to put the most of these on Receptor channels. Streaming sampler VSTi's - less so, but still better than compute intensive plugins (like analog synth emulations). Emulative VSTi's can drag a Receptor to it's knees, and I have not been able to use much more than 4 of these simultaneously.
The good news is that you can mix and match VSTis on different channels, and typical playing activities never have you stacking much more than 4 Midi channels of notes at exactly the same time. I often have Receptor multis configured with 8-10 instruments, by which I am triggering from 3-4 midi keyboards. I often switch instruments by switching midi zones on the controllers.
Hope this helps,
Kevin L
- KVRAF
- 5948 posts since 19 Jun, 2008 from Melbourne, Australia
Hi Kevin,looneytunes wrote:Hi Andy,
gregh1 did some benchmarking of Kontakt performance on Receptor Pro units in this thread.
In general, VSTi samplers using ram will give very good performance, and you will be able to put the most of these on Receptor channels. Streaming sampler VSTi's - less so, but still better than compute intensive plugins (like analog synth emulations). Emulative VSTi's can drag a Receptor to it's knees, and I have not been able to use much more than 4 of these simultaneously.
The good news is that you can mix and match VSTis on different channels, and typical playing activities never have you stacking much more than 4 Midi channels of notes at exactly the same time. I often have Receptor multis configured with 8-10 instruments, by which I am triggering from 3-4 midi keyboards. I often switch instruments by switching midi zones on the controllers.
Hope this helps,
Kevin L
Thanks for that info, it's extremely helpful. It will be interesting to see how v2 of Receptor performs. I hope for everyone's sake the software improvements also roll out to v1.x ...
Peace,
Andy.
-
- KVRer
- 8 posts since 19 May, 2008
Just adding my name to the list of Receptor owners who feel left out in the cold. While it bothers me that Receptor hasn't lived up to the advertising, it worries and aggravates me more that there is nearly zero communication from Muse on when we can expect updates. The fact that a thread like this was started (and is still without a reply from a Muse employee) is a sign of the company's weak customer service. I don't want to trash Muse. I just hope to see something better from them in the future.
-
- KVRist
- 269 posts since 23 May, 2008 from Lake Stevens, WA, USA
KKeys,
Well stated. I will add that there has got to be a logical reason behind all the silence. I can dream up good or bad scenarios, but I'm pulling for the good one! In that vein, the silence may be due to Muse not wanting to unzip their fly and reveal the solution to the world before they're ready. For competitive reasons, they may need to keep tight-lipped with any and all comments until the appropriate time. Unfortunately, this does leave us all out in the cold, of course, as you said. Now, if Muse would just say "hang in there", I'd feel better, even with those three little words...
We all hope the Receptor soon evolves to become everything we all thought it would be; we obviously see it as a good solution to our various music-making needs. I hope Muse realizes that our collective frustrations vented in this forum are for this very reason.
Well stated. I will add that there has got to be a logical reason behind all the silence. I can dream up good or bad scenarios, but I'm pulling for the good one! In that vein, the silence may be due to Muse not wanting to unzip their fly and reveal the solution to the world before they're ready. For competitive reasons, they may need to keep tight-lipped with any and all comments until the appropriate time. Unfortunately, this does leave us all out in the cold, of course, as you said. Now, if Muse would just say "hang in there", I'd feel better, even with those three little words...
We all hope the Receptor soon evolves to become everything we all thought it would be; we obviously see it as a good solution to our various music-making needs. I hope Muse realizes that our collective frustrations vented in this forum are for this very reason.
