There are 4 USB slots, right?
Has anyone actually plugged 4 controllers into it? How complicated is it to assign midi controls etc for a live show with all those keyboards?
How far has anyone pushed it and flaws are you able to expose?
Most ambitious Receptor configuration?
-
- KVRian
- 524 posts since 25 Aug, 2005
Only ONE USB keyboard may be attached at this time. USB QWERTY keys, mouse, dongle port and midi controller=4 slots. We're all hoping they let us use the second controller, but so far it's one MIDI port, one USB port - (but you COULD daisy chain up to 16 MIDI keyboards! (Hint: Don't...)
I'm sure that someone has blown this one off with the faster processors and more RAM, but check my setup out...
http://www.kvraudio.com/forum/viewtopic ... t=#2043844
and the picture here: http://www.thesoundsmith.com/private/cokeyrig.htm
I'm sure that someone has blown this one off with the faster processors and more RAM, but check my setup out...
http://www.kvraudio.com/forum/viewtopic ... t=#2043844
and the picture here: http://www.thesoundsmith.com/private/cokeyrig.htm
-
- KVRist
- 82 posts since 15 Apr, 2007
Very nice setup. You have clearly spent some time thinking through the issue of making quick patch changes live. Definitely worth some study.
I think this is the biggest challenge in using the Receptor: Since we don't want to wait for large samples to load, we stick with the Snapshots. But then, we can't change patches on VSTs that don't use samples unless the individual VST accepts patch change messages. Many don't. And on those that do, we have to figure out how they store their preset banks and remember to store new patches in those internal preset banks. Even different VSTs by the same manufacturer differ in the way they do this (ie Pro53, B4 and FM7) And, oh yeah, gotta be careful not to send patch change messages to the wrong VSTs.
Do you ever wish for a sort of "super snapshot" bank in which we could set the sample based VSTs to act like they do now in snapshots, but the synthesis based VSTs could have a different sound for each snapshot in the snapshot bank? With this, using a Receptor would feel much more integrated, more like using a workstation with way better sounds or something like the Oasys without the ridiculous weight. (wouldn't want to move an Oasys even if I had it).
Sorry don't mean to hijack the thread. This should probably be under the wishlist. But your ideas on changing patches, and the way you've worked around these limitations so well, got me thinking.
K.
PS: Love the music on your website. Great playing.
I think this is the biggest challenge in using the Receptor: Since we don't want to wait for large samples to load, we stick with the Snapshots. But then, we can't change patches on VSTs that don't use samples unless the individual VST accepts patch change messages. Many don't. And on those that do, we have to figure out how they store their preset banks and remember to store new patches in those internal preset banks. Even different VSTs by the same manufacturer differ in the way they do this (ie Pro53, B4 and FM7) And, oh yeah, gotta be careful not to send patch change messages to the wrong VSTs.
Do you ever wish for a sort of "super snapshot" bank in which we could set the sample based VSTs to act like they do now in snapshots, but the synthesis based VSTs could have a different sound for each snapshot in the snapshot bank? With this, using a Receptor would feel much more integrated, more like using a workstation with way better sounds or something like the Oasys without the ridiculous weight. (wouldn't want to move an Oasys even if I had it).
Sorry don't mean to hijack the thread. This should probably be under the wishlist. But your ideas on changing patches, and the way you've worked around these limitations so well, got me thinking.
K.
PS: Love the music on your website. Great playing.
-
- KVRian
- 524 posts since 25 Aug, 2005
I don't use snapshots, these are all conventional old-style multi patches. Everything is in RAM. I tried snapshots, but a lot of my VSTis work better (IMHO) with straight preset banks. Takes no time to change, and I get more bang for the RAM buck. There may well be a way to do what I do in snapshots, but I had this working and if it ain't broke...
-
- KVRist
- 82 posts since 15 Apr, 2007
So how do you keep from re-loading the Colossus and EWQL samples every time you choose a new multi? Are you using Z-Load? Do you have the Colossus and EWQL banks loaded into every multi, even when they are disabled and not playing? I'm interested in understanding your technique better, since its clearly working for you.
K.
K.
-
- KVRian
- 691 posts since 13 May, 2004 from Silicon Valley
Okli,
I'm with you on the "super snapshot" thing. I think it would be cool to somehow have a checkbox for given channels in a multi that means "Don't load/reload this channel". Or even a Lighter channel assignment, where only the instrument preset/receptor-bank/receptor-preset changes, but the VSTi on that channel remains the same (ie doesn't get re-loaded).
Right now, I use up to 10 midi channels from 3 midi controllers. Switching an instrument on a controller means making a different Midi zone active, so I really don't switch presets. I would like to be able to switch presets on a given MIDI zone in an easy manner, without disturbing other channels/zones.
Regards,
Kevin L
I'm with you on the "super snapshot" thing. I think it would be cool to somehow have a checkbox for given channels in a multi that means "Don't load/reload this channel". Or even a Lighter channel assignment, where only the instrument preset/receptor-bank/receptor-preset changes, but the VSTi on that channel remains the same (ie doesn't get re-loaded).
Right now, I use up to 10 midi channels from 3 midi controllers. Switching an instrument on a controller means making a different Midi zone active, so I really don't switch presets. I would like to be able to switch presets on a given MIDI zone in an easy manner, without disturbing other channels/zones.
Regards,
Kevin L
-
- KVRian
- 524 posts since 25 Aug, 2005
The secret is this - if you install a VST to SLOT n on the mixer and set to channel n, patch changes on channel n change patch, and the system reloads the patches every time. But if it is loaded into a DIFFERENT mixer slot (I have Colossus in slot 11, set to use midi channel 2, 5 and 12. That slot is set to accept all midi channels, but the VST is set to respond only on 2, 5 and 12. Because it is in slot 11, a midi patch change is ignored. So I can choose to have the VST respond to patch changes by selecting the appropriate slot/channel combination. I have Colossus configured with 2 instances of Steinway piano, one set an octave higher than the other, and a string section patch. As long as none of these is on a channel that receives patch change, they all sit patiently in memory...
HTH
(BTW, oki, thanks for the kind comments on the music.)
HTH
(BTW, oki, thanks for the kind comments on the music.)
-
- KVRist
- 82 posts since 15 Apr, 2007
Thanks for the explanation, Soundsmith. Staying in the same multi and sending patch changes to the individual VST's is one workable solution. Its sort of like what I've been trying to work out with snapshots, which are really very much like using a single multi, since only things like mutes, key ranges and channel assignments change.
However, I'd really like to see Muse put some thought and effort into making the Receptor act in a more integrated way. By that I mean acting something like a workstation, or a super-Oasys. I'm as anxious as anybody to see more plug-ins made Receptor compatible. However, even though I'd bet that there will always be more incompatible than compatible plugs, the Receptor as it stands right now has way more different tyoes of synthesis available than does the Oasys (or almost anything else, for that matter). Where the Oasys kills it is in integration.
One good place to start would be in the ability to change the patch in a single VST in a multi using the native Receptor patch banks, rather than relying on the VSTs own ability to respond to patch change messages. While sending patch changes to the individual VST can work, not all VSTs respond to patch change messages. Those that do will choose the patch from their internal sound banks, not the Receptor sound banks, and will have many differing ways of saving customized patch banks.
For instance, Pro-53 saves its default soundbanks in a file called "def.p5a" Every time the Receptor is re-started, Pro53 loads the patches in this file. So, if I creat a Pro53 patch, and I want to be able to select this patch by means of a patch change message directly to Pro53 (so that I don;t also have to reload the samples in Akoustik Piano), then I must do the following: first save the patch in the Pro-53s internal memory, then save the entire soundbank as "def.p5a." Other VSTs will have completely different ways of saving default patch banks, and I have to learn all of them and remember to go through this process every time I create a custom patch.
Oh yeah, and when I update to the Receptor 2 (which I know I will) I'll have to remember where all of these default soundbank files are located and what they are called in order to back them up and reload them on the new hard drive. I'm getting a headache just thinking about this.
In the 1.2 manual, Muse says that a future revision will allow Z-load to be turned on and off for each channel. This would be helpful, but still wouldn't achieve a full workstation style integration. One possible solution would be a mode where each individual channel in a multi could be set to act like a regular mult or like a snapshot. Then, VSTs which don't use sample, or which use small samples, could be set to change.
Another way would be to do something like what the Oasys does: a certain number of samples could automatically load into RAM when any multi in a given bank is selected. Those samples would stay in RAM when changing multis within that bank. Choose a multi form a different bank, and a new set of samples will be loaded.
I'm sure others could come up with different and probably better ideas. I hope Muse can spend some time brainstorming on this issue once they have gotten Direct Install working.
Apologies to WeaponEx for posting such a long-winded post in a thread he created for an entirely different purpose.
K.
However, I'd really like to see Muse put some thought and effort into making the Receptor act in a more integrated way. By that I mean acting something like a workstation, or a super-Oasys. I'm as anxious as anybody to see more plug-ins made Receptor compatible. However, even though I'd bet that there will always be more incompatible than compatible plugs, the Receptor as it stands right now has way more different tyoes of synthesis available than does the Oasys (or almost anything else, for that matter). Where the Oasys kills it is in integration.
One good place to start would be in the ability to change the patch in a single VST in a multi using the native Receptor patch banks, rather than relying on the VSTs own ability to respond to patch change messages. While sending patch changes to the individual VST can work, not all VSTs respond to patch change messages. Those that do will choose the patch from their internal sound banks, not the Receptor sound banks, and will have many differing ways of saving customized patch banks.
For instance, Pro-53 saves its default soundbanks in a file called "def.p5a" Every time the Receptor is re-started, Pro53 loads the patches in this file. So, if I creat a Pro53 patch, and I want to be able to select this patch by means of a patch change message directly to Pro53 (so that I don;t also have to reload the samples in Akoustik Piano), then I must do the following: first save the patch in the Pro-53s internal memory, then save the entire soundbank as "def.p5a." Other VSTs will have completely different ways of saving default patch banks, and I have to learn all of them and remember to go through this process every time I create a custom patch.
Oh yeah, and when I update to the Receptor 2 (which I know I will) I'll have to remember where all of these default soundbank files are located and what they are called in order to back them up and reload them on the new hard drive. I'm getting a headache just thinking about this.
In the 1.2 manual, Muse says that a future revision will allow Z-load to be turned on and off for each channel. This would be helpful, but still wouldn't achieve a full workstation style integration. One possible solution would be a mode where each individual channel in a multi could be set to act like a regular mult or like a snapshot. Then, VSTs which don't use sample, or which use small samples, could be set to change.
Another way would be to do something like what the Oasys does: a certain number of samples could automatically load into RAM when any multi in a given bank is selected. Those samples would stay in RAM when changing multis within that bank. Choose a multi form a different bank, and a new set of samples will be loaded.
I'm sure others could come up with different and probably better ideas. I hope Muse can spend some time brainstorming on this issue once they have gotten Direct Install working.
Apologies to WeaponEx for posting such a long-winded post in a thread he created for an entirely different purpose.
K.
-
- KVRian
- 524 posts since 25 Aug, 2005
In effect, this is already set up. The multis I use switch Receptor patches, NOT the original VST patch lib. I hated it at first, because I had to completely, one at a time, set the patches into Receptor banks. But once done, it works just as I need (for now...)One good place to start would be in the ability to change the patch in a single VST in a multi using the native Receptor patch banks, rather than relying on the VSTs own ability to respond to patch change messages.