Version 1.8 versus 1.7

[mat123]

Hi folks,

Is there a "what's new in version 1.8" list? I couldn't find one. I think I will participate in the Rev C upgrade program once hard drives are available. However, to make an informed choice I would like to inform myself about the benefits from 1.8 - not from a technical point of view (I'm sure there is a never ending list of architectural changes) - rather with focus on functionality.

-mat123

[SurfacePatterns]

Is there a "what's new in version 1.8" list?

Muse Research's site has release notes for two 1.8 versions:

http://www.museresearch.com/downloads/r ... _Notes.pdf

http://www.museresearch.com/downloads/r ... _Notes.pdf

[mat123]

Thanks SurfacePattern! I was aware of the release notes. So from a user perspective, the motivation for version 1.8 is compatibility for more plugs, right?

I thought there might be enhanced functionality of the receptor itself, e.g.
- MIDI-handling (some programming like if I press key xyz, activate channel abc)
- performance (after patch switching, keep unused plugs if possible, the user may want to switch back)...

The release notes don't say anything about these type of changes... Probably I'll have to wait for 1.9

-mat123

[SurfacePatterns]

Thanks SurfacePattern! I was aware of the release notes. So from a user perspective, the motivation for version 1.8 is compatibility for more plugs, right?

I believe that the main motivation for the 1.8 update is both technical and practical. If you don't mind me getting a bit technical for a few paragraphs, I'll try to explain.

There are two main software components that make Linux a viable choice for the core of the Muse operating system:

1.) 'wine'

'wine' is a Windows compatibility layer. 'wine', among other things, has the capability of loading and running code in most Windows DLL files, which allows you to run your VST plugins under Linux.

2.) real-time kernel

Because the Linux kernel is open-source, it can be modified (patched) to work differently. One of the more popular patches allows the kernel to be run in real-time mode; that is, a process that has a higher realtime priority than another process can preemptively take the CPU from the lower-priority process. This is essential for realtime audio applications.

Older Receptor operating systems (up to and including 1.7) contained a very old version of 'wine' (the most current version on Muse Research's FTP site was released in 2005), and a 2.4 Linux kernel. The realtime support in the 2.4 kernel was experimental and volatile.

Newer Receptor operating systems (1.8 +), IIRC, are based on Fedora Core 7 (a distribution of Linux), which means they contain a shiny new 2.6 Linux kernel, and a newer version of 'wine'. The 2.6 kernel series is much more realtime friendly, and the realtime patches are much more mature than those in the 2.4 kernel series. It also supports more hardware, and is more stable. My DAW runs Fedora Core 10 with a 2.6 realtime kernel, and I can run several realtime audio applications with a 2.8 ms latency comfortably (Intel Core Duo, 2 Ghz).

On a technical level, this means that your Receptor should run more reliably. Of course, I'm assuming that Muse Research's applications will continue to function well ...

On a practical level, the newer kernel means that the 1.8 OSs are "potentially" much more efficient than earlier OSs, and that the hardware problems in the 1.7 OSs (i.e. buggy USB MIDI interface support) will probably go away. The new version of 'wine' means that more VSTs will work correctly with the OS.

When I post bugs on Plugorama, I often compare the performance of VSTs on my Linux-based DAW with performance on my Receptor. While the VST host I use on my DAW is different than the host included with the Muse OS, I do know that both hosts rely on 'wine' to load the DLLs associated with each VST. There are several VSTs that run reliably on my DAW that will not run on the 1.7 OS (most notably for me, Audjoo Helix).

I'm confident that many of the VSTs that work on my DAW will work correctly under the 1.8 OS.

I hope my explanation is more helpful than confusing.

[gregh1]

I thought there might be enhanced functionality of the receptor itself, e.g.
- MIDI-handling (some programming like if I press key xyz, activate channel abc)
- performance (after patch switching, keep unused plugs if possible, the user may want to switch back)...

Not sure if this helps, but here's what is available already:

You can use the number keys on your (typing) keyboard to switch Receptor channels. e.g. "1" goes to channel one, "2" goes to channel two, etc., and use "CTRL+num" for channels 11 and up. This is useful while setting things up.

But if you meant "enable/disable" when you wrote "activate": everything in the Receptor mixer is controllable by MIDI NRPN or CC. So you can mute, bypass, etc. by pressing a button on your controller.

About performance: the Vload option (a kind of caching, available on the Setup page) will keep plugs in memory, so they can be reloaded into the mixer more quickly.

[batgab]

SurfacePattern, that was very informative and interesting explanation (for me, anyway...). Thanks!

[mat123]

@SurfacePatterns: that was very informative and by no means confusing, thanks!

@gregh1: thanks for your suggestions. However, when I said "key" I meant "keyboard-key". I have no extra controller on stage (probably I should buy one...), just my 88 keys. but I have the lower octave of my keyboard, which I never use... as for Vload - I havn't heard about it. Is this a receptor 1.8 feature?

[gregh1]

mat123, I think the key to using Receptor live is having lots of good hardware knobs and sliders and such to control it, and also to pre-planning what you will need for a gig.

But if you want to use a keyboard key to control the Receptor, you will need to map the key event to a MIDI CC or NRPN. You could perhaps use one of the MIDI Solutions boxes for that.

Vload has been in Receptor since version 1.5, and probably earlier (several years, at least). It speeds up the re-loading of plugins (DLLs), although it probably does not speed up loading of sample sets or complex presets within those plugins.

But maybe you don't need to dynamically load plugins at all? Maybe you could use Snap Shots instead (which can be used to activate and deactivate plugins without loading and unloading them). These can be triggered by program changes from your controller. You could then pretend that the Receptor setups are actually patches within your controller (as if it were a multi-timbral synth with splits and layers).

[SurfacePatterns]

@batgab, @mat123: You're welcome.

[nathankingcole]

Vload has been in Receptor since version 1.5, and probably earlier (several years, at least). It speeds up the re-loading of plugins (DLLs), although it probably does not speed up loading of sample sets or complex presets within those plugins.

I think that Gregh1 is referring t Zload. I am just to make sure there is no confusion Thanks for your information, insights, and perspectives gregh1.

[gregh1]

Yes, it is "Zload", not "Vload"... I'm not sure why I remembered it the wrong way! Sorry for the confusion, and thanks for the correction, nathankingcole.

And it looks like Zload (got it right that time!) has been available since version 1.2 of the OS.