by entering:
[root@receptor root]#rpm e
Q: I want to upgrade the motherboard, can I?
A: Well, this is kind of a tricky question. But the short answer is yes! But, to be able to use the current avalible kernel, you'd have to first have stick with an AMD based system, and, preferbly one with a VIA chipset. I'd also try to use a motherboard with a similar layout as the one that's currently in the Receptor. But, any mATX should work. Fitting wise at least.
Next up. Networking. They do use a modularized kernel, which is good. At least then you'd be able to use a different network interface.
I've spent a couple of minutes researching for a candidate. I've found that an Asus A8V-VM might be a good choice. It has support for 4Gb memory and an Athlon 64 CPU and a VIA K8M890 chipset. Now wouldn't this be nice to have a nice quiet cool AMD 64 CPU and 4 Gb RAM running your Receptor? My current box is quite loud actually, but then it doesn't run very hot either. Anywho. At the moment, I sure don't need more CPU power. But future wise, it feels good to know that it certanly is doable. As for destroying any warrantys, this is actually not a problem. Since any warranty is out the door after a year or so anyway.
On another fitting point. The LCD of the Receptor is driven by a ttyS interface. So, a serial COM port is needed. Muse have soldered away the sticking ot part of the COM port and put it inside the box so to speak. Either you could do this yourself or just the cable back in the box from the outside. This observation is just an educated guess so far. I didn't exactly got my magnifying glass while cloning the harddrive to investigate this. But most LCD's are driven by a serial interface.
Then there is the graphic card support. This should work with whatever you choose. Just make sure your motherboard of choice has an integrated VGA chip. They do use a generic VESA driver for the X server, so any chip would work just fine. Again, the Asus A8V-VM looks very promising. As it has all of the above things avalible. And it's dirt cheap to =D.
Note, there isn't any kernel module avalible for the Realtek chipset that's on the Asus A8V-VM board. At least not with the kernel my Receptor runs at the moment.
Contributed by Kermit Jagger:
Since the Pro version, Muse have been using a microATX motherboard made by MSI (Micro Star Intl), model number K8MM-V, also known as MS-7142. It is a socket 754 board that will take various AMD processors. However, Muse use the laptop CPU called the Turion. The "Pro" upgrade (from rev. A or B to rev. C) uses the ML-34, but up to the ML-44 is supported.
As oGG said re the original rev. A board, the COM port has been desoldered and resoldered facing the other way round.
On this mobo, the LAN chip is a VIAŽ VT6103L 10/100Mb/s PHY.
The maximum RAM is still 2Gb. Any version of DDR266/333/400 will do. Yes, it's probably better to go with PC3200 if you can, but the two PC2700 modules I recycled from the rev. A work fine, i.e. no crackling when using a sampler as a consequence of the RAM used.
There are SATA ports BUT DO NOT install a SATA drive, Receptor OS 1.6 does not support SATA. Carry on using an IDE drive, preferably the Seagate series as they are the less noisy, and carry a five year warranty. See "using a SATA drive" above.
Q: How do I use my small screen TFT with the Receptor?
A:I have bought a nice little 8" TFT that I'm going to use with my Receptor. The screen I bought (and as almost every small screen TFT) only have a native resolutioin of 800x600 pixels. If you use anything higher that this, the screen performs (good or bad) a downscaling of the image to make it fit. In my case, I actually can use the Receptor at 1024x768 quite well. If you want to use some plugins, which have tiny interfaces, you can run in to problems.
Since the Receptor runs Linux. And X, there's a nifty little feature that's called Virtual screens. I've configured my X server to run at 800x600 (which is my monitors native resolution) but the Virtual screen is 1024z768 (which the Receptors host application runs at). If you do this, you can "pan" the picture but you get no scaling whatsoever of the picture and it should be crystal clear.
Edit your /etc/X11/XF86Config and look for the Subsection "Display" and change it so it looks like below (the bold lines are the ones that differ from the original):
Subsection "Display"
Depth 16
Modes "800x600" "1024x768"
Virtual 1024 768
EndSubsection
Save the file and restart the Receptor.
What about the remote view you wonder? No worry, you won't have to "pan" when running the Receptor remote. This doesn't effect that at all!
Q: How do I enable regedit?
A:First off you need root access and be able to edit a file under Linux. After you've mastered that, add the following line into the file /etc/sysconfig/receptor.
export MUSE_PROVIDE_REGEDIT=1
Then restart the Receptor GUI either by running "restart-receptor" at the command prompt, pressing ALT-F4 in the Receptor Remote application or simply tripple-click the power button..
After this you should have a menu item that says "Run Regedit - ADVANCED" option under the Plugin Tools button on the Setup page.
Q: How do I install a plugin that the Receptor REJECTS?
I got this idea when reading about a failed installation attempt of EVE 2 on the Receptor forums. This is just an idea but it may actually work.
As far as I know, and have read, the Receptor keep a list with uniqe VST Id:s. So, whenever you try to install an unsupported plugin that shares the same ID as a supported one, you'll run into problems. The receptor will simply reject the install. You'd see something like this in your system log:
May 20 15:32:16 receptor rm-host: HostPluginList.cpp::AddDescription[1147]: REJECTED: NONAMEPLUGIN
This is actually pretty easy to circumvent. The solution is to make up an uniqe ID and tell the Receptor to use this ID instead of the original one. Here's how to do that.
Create a NONAMEPLUGIN-custom-info.xml similar to this one. (The reason I linked to this file instead of including it in the HTML is because I'm one of the "lazy" programmers I mention below =D).
The most important parameter is uniqueID. Change this to whatever (I figure the higher number the better but you'll have to try yourself).
The other paramters I have there is vst-plugin-name, this one can be useful to change also if you have a lazy programmer that haven't changed the name of the VST even if it's a new version. If you change this, you won't end up with a duplicate listing in the Plugin list on the Receptor.
vst-plugin-vendor can also be good to change. As far as I know, this is what the Receptor goes by when you create patches. So, if you have NONAMEPLUGIN Vendor there, the patches will end up in /c/Banks and Patches/NONAMEPLUGIN Vendor/NONAMEPLUGIN/. Nice and tidy. (I've seen some plugin vendors that have names like "ooo.i.make.plugins.and.have.a.homepage.com" sort of name in the vendor tag, which in the long run just is irritating.
Anywhoo. After you've created the custom xml file, refresh the plugin cache by holding down the Multi button and tripple-click the power button. Then remove any .NONAMEPLUGIN-sign.xml, .NONAMEPLUGIN-muse-lock.xml and NONAMEPLUGIN-info-cache.xml that were created when you failed to install the first time. After that, just hit the install button and hope it'll work.
Q: How to disable automatic file system checks?
A:
After system update 1.5 (correct me if I'm wrong, because I don't remember) the Receptor file system has the check disk field in fstab set to automatically check the filesystem after a number of mounts (boot ups). So, if you've switched drive to a big bad one this might put the Receptor in a "frozen" state when booting up and the mounting count has reached it's limit. It's actually checking the partitions but since it's lack of an IDE LED and a really quiet harddrive it's kind of hard to notice that it's actually working (Muse, fix please ;).
This is easily fixed thou. Just edit the file /etc/fstab and change the sixth field to a 0 for all partitions. This will ensure you're Receptor doesn't "hang" when you're about to gig. Believe me when I say it can take a veeeery long time to fsck a 400 gb partition which is almost full. So, this fix is a must for every gigging musician.
Thanks to AkNoT for reminding me to add this info. And for the following links regarding the subject (not Receptor and/or RedHat specific but worth reading anyway):
http://ubuntuforums.org/showthread.php?t=300477
http://ubuntuforums.org/showthread.php?t=498511
http://www.tuxfiles.org/linuxhelp/fstab.html
http://netadmintools.com/html/8e2fsck.man.html
Oh, and beware that this fix probably will be overwritten with the next system update. So, remember to do this again after the next upgrade.
Muse had released a RMP package that could be downloaded from their website to fix this. The package has now been integrated into O.S. v.1.7.
Q: Have you written this FAQ all by yourself?
A:
No, over time the following people have helped me:
Written by Olle Gustafsson in March 2006.
This page has been accessed 0
times by a total of 0
uniqe computers since The document last changed: July 29 2008 16:43:56.