Good morning,
I'm trying to derive correct conclusions from everything that I've read on here and in the Receptor manual, and one thing that I'm still trying to sort out is this - is it really the case that if you route CCs to source plug-ins, you lose control of the mixer - e.g., volume control of each mixer channel? So, you can either control the source plug-in, or the channel volume, but not both? Just trying to think through what would happen live if master receptor volume or channel volumes needed to be adjusted if the Receptor was passing CC to source plug ins?
Again, I might be totally wrong - just working towards envisioning this as a live solution. Thanks!
Volume Control vs Source Plugin Control
-
- KVRist
- 82 posts since 15 Apr, 2007
Unfortunately, you are correct. It is an either-or proposition.
Sadly, it seems that Muse is spending almost all of their time chasing their tales trying to get more plug ins compatible, rather than spending time on upgrading the overall usability and integration of the Receptor. Given that Linux is not Windows, I'm guessing that Receptor will never be a universal VST player. So, I'd wish that they would spend more time making the existing plug ins more usable in a live situation, mostly through better midi-mapping and control features, as well as the ability to send a single program change to the Receptor to change some plug ins while leaving others untouched. (ie those with large samples to load) However, for now we can only look longingly at the feature set of the Open Labs stuff. Check out what Keyboard said they are doing
"Open Labs MiKo/NeKo. The new Riff environment brings assignable control to the highest level. Not only is assigning the keyboard's many hardware controls straightforward and visual, but Riff fully exploits the touchscreen with its new "Live Controls" feature (see Figure 4 above). You can add various types of virtual knobs, buttons, sliders, and even an X-Y touchpad to the display, for realtime touch control of any plug-in setting. Imagine having a Kaoss-like pad, along with a dozen or so virtual knobs, at your beck and call. Riff makes it a reality, and your controller setup can change from song to song."
Of course, Open Labs is running Windows, so they don't have to worry about compatability. Instead, they spend their days working on cool environments, like Riff. I, for one, would far prefer to see something like this in Receptor before more compatible VSTs. Others may disagree.
K.
Sadly, it seems that Muse is spending almost all of their time chasing their tales trying to get more plug ins compatible, rather than spending time on upgrading the overall usability and integration of the Receptor. Given that Linux is not Windows, I'm guessing that Receptor will never be a universal VST player. So, I'd wish that they would spend more time making the existing plug ins more usable in a live situation, mostly through better midi-mapping and control features, as well as the ability to send a single program change to the Receptor to change some plug ins while leaving others untouched. (ie those with large samples to load) However, for now we can only look longingly at the feature set of the Open Labs stuff. Check out what Keyboard said they are doing
"Open Labs MiKo/NeKo. The new Riff environment brings assignable control to the highest level. Not only is assigning the keyboard's many hardware controls straightforward and visual, but Riff fully exploits the touchscreen with its new "Live Controls" feature (see Figure 4 above). You can add various types of virtual knobs, buttons, sliders, and even an X-Y touchpad to the display, for realtime touch control of any plug-in setting. Imagine having a Kaoss-like pad, along with a dozen or so virtual knobs, at your beck and call. Riff makes it a reality, and your controller setup can change from song to song."
Of course, Open Labs is running Windows, so they don't have to worry about compatability. Instead, they spend their days working on cool environments, like Riff. I, for one, would far prefer to see something like this in Receptor before more compatible VSTs. Others may disagree.
K.
-
- KVRist
- Topic Starter
- 93 posts since 10 Feb, 2009
So, I know this "isn't your sale to make", but, hmmmmm, why not just go with Open Labs stuff? (I'm a prospective buyer)....I'll have to check that out, just to be sure of my decision. Thanks for the info!
Just looked at it - EXPENSIVO!
Just looked at it - EXPENSIVO!
-
- KVRist
- 82 posts since 15 Apr, 2007
Open Labs stuff is not just expensive, it is also heavy and bulky. The form factor doesn't appeal to me at all. I haven't used it, but knowing that it runs Windows, why not just take a laptop?
The Linux system used by Receptor has much better latency and stability than any Windows machine I have used. But, the tradeoff is that it isn't Windows, so VST compatability is an issue. I don't know anything about software, but my guess is that compatability will always be an issue.
This means that Muse has to choose how to allocate their limited development resources. It seems to me as an outsider that they have chosen to spend most of their time making more VSTs compatible, which is probably an intelligent choice given the comments I see on this board. My own vote would be to spend more time on improving the functionality in regards to program changes and midi mapping, even at the expense of slowing down on making VSts compatible. However, I think I am in a minority.
However, these comments are certainly not meant to turn you away from the Receptor. I love my Receptor, but with two caveats: First, the functionality of your controller is crucial, gven the limitations of the Receptor's own midi mapping. I am much happier with my Receptor since I stopped trying to run it from my Yamaha S90ES and switched to a Kurzweil PC3. I can control the mix of different VSTs by putting them on different midi channels and send cc 7 or 11 directly to the VST, so long as they respond to to these messages (choose your VST's wisely!) Also, the limitations of the Receptor implementation means I still need a general purpose Rompler for most gigs, which I can augment with combinations of up to 16 sounds like Akoustik Piano, Kontakt samples, B4 organs and Atmosphere pads. However, people who don't need more than 16 different sounds for a given gig can and do use the Receptor as their only sound source.
K.
The Linux system used by Receptor has much better latency and stability than any Windows machine I have used. But, the tradeoff is that it isn't Windows, so VST compatability is an issue. I don't know anything about software, but my guess is that compatability will always be an issue.
This means that Muse has to choose how to allocate their limited development resources. It seems to me as an outsider that they have chosen to spend most of their time making more VSTs compatible, which is probably an intelligent choice given the comments I see on this board. My own vote would be to spend more time on improving the functionality in regards to program changes and midi mapping, even at the expense of slowing down on making VSts compatible. However, I think I am in a minority.
However, these comments are certainly not meant to turn you away from the Receptor. I love my Receptor, but with two caveats: First, the functionality of your controller is crucial, gven the limitations of the Receptor's own midi mapping. I am much happier with my Receptor since I stopped trying to run it from my Yamaha S90ES and switched to a Kurzweil PC3. I can control the mix of different VSTs by putting them on different midi channels and send cc 7 or 11 directly to the VST, so long as they respond to to these messages (choose your VST's wisely!) Also, the limitations of the Receptor implementation means I still need a general purpose Rompler for most gigs, which I can augment with combinations of up to 16 sounds like Akoustik Piano, Kontakt samples, B4 organs and Atmosphere pads. However, people who don't need more than 16 different sounds for a given gig can and do use the Receptor as their only sound source.
K.
-
- KVRer
- 5 posts since 19 Jan, 2007
[is it really the case that if you route CCs to source plug-ins, you lose control of the mixer - e.g., volume control of each mixer channel? ][/quote]
This is NOT an either-or proposition. With my live setup, I regularly control the Receptor channel volumes and mutes, as well as a number of plugin parameters. You get 16 (not a lot) CC's to use for each plugin (#16 thru 31), 4 CC's per FX plugin, and unlimited NRPN's. This stuff is explained pretty clearly in the manual. Check CH 15 "MIDI control of Receptor's Mixer" and CH 17 "MIDI control of Plugin Parameters".
To use the CC's, you do need to be able to assign the available #s to the plugin parameters you want to control. B4 is easy to set up for drawbar control, for example.
I use a Fatar VMK88 for sending the CC messages, and a Novation ReMote SL that allows for setting up anything, including the NRPN's.
This is NOT an either-or proposition. With my live setup, I regularly control the Receptor channel volumes and mutes, as well as a number of plugin parameters. You get 16 (not a lot) CC's to use for each plugin (#16 thru 31), 4 CC's per FX plugin, and unlimited NRPN's. This stuff is explained pretty clearly in the manual. Check CH 15 "MIDI control of Receptor's Mixer" and CH 17 "MIDI control of Plugin Parameters".
To use the CC's, you do need to be able to assign the available #s to the plugin parameters you want to control. B4 is easy to set up for drawbar control, for example.
I use a Fatar VMK88 for sending the CC messages, and a Novation ReMote SL that allows for setting up anything, including the NRPN's.
-
- KVRist
- Topic Starter
- 93 posts since 10 Feb, 2009
Thanks for the clarification. I was looking more closely at the manual last night, as you said, and noticed that the mixer control certainly doesn't consume all possible CC values, and it seemed odd to not let the others do what we'd like them to!