Has anyone heard from Muse lately?

RELATED
PRODUCTS

Post

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.
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.

Post

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.

Post

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.

Post

skipscada wrote:
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.
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.
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.

Windows XP embedded :

http://www.microsoft.com/windowsembedde ... fault.mspx

Post

UltraJv wrote:
skipscada wrote:
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.
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.
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.

Windows XP embedded :

http://www.microsoft.com/windowsembedde ... fault.mspx
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).

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.

Post

ZenPunkHippy wrote:
UltraJv wrote:
skipscada wrote:
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.
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.
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.

Windows XP embedded :

http://www.microsoft.com/windowsembedde ... fault.mspx
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).

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.
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

Post

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
Ta for the heads up, interesting concept.

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.

Post

Fair comment - Ill withdraw from further posts otherwise it will turn into an OS wars thread :hihi:

Post

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! :D

projektio

Post

UltraJv wrote:Fair comment - Ill withdraw from further posts otherwise it will turn into an OS wars thread :hihi:
A wise move, as everyone knows that "my" operating system is better than "yours" ;)

*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.

Post

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.
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.

projektio

Post

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

Post

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
Hi Kevin,

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.

Post

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.

Post

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.

Locked

Return to “Muse Research and Development”