I have been exploring the rig manager and I would like to know if there is any support for the following scenario.
Question 1: In 1 situation I have multiple keyboards and I can play different parts on all of them. In situation 2 I have only 1 keyboard which I need to divide into zones to play the same parts. Is this possible to model in the rig manager?
Question 2: I have multiple keyboards with no USB, only MIDI. These are merged using different MIDI channels and connected to the computer via MIDI interface. Is it possible to identify a device in rig manager using its MIDI channel?
Unless I’m seriously misunderstanding something, you use multiple MIDI blocks to define the “zones” (by which I assume you mean splits) and you tie the MIDI blocks to a MIDI device via the rig manager
Thanks all for your replies. I think what I want can be achieved with a combination of the rig manager and the global rackspace:
in rig manager I define 2 virtual midi devices, one for merged midi input and one for single. I have 2 rigs in which I map my midi input to one of these virtual devices.
in the global rackspace I add both virtual inputs. The merged input is split into individual keyboards using midi filters. The single input could get controllable split zones using midi filters combined with widgets in the global rackspace and a button to switch to layered mode.
in the normal rackspace I connect an instrument both to one of the unmerged keyboards and one of the split zones.
Ideally I would have wanted to create a virtual device for each midi channel / un-merged keyboard. If I wanted to get a layered sound I could connect this virtual device to multiple instruments, and do the same for any additional keyboards if I wanted the same layered sound on those.
You could certainly achieve this quite easily by defining a rig manager alias for each physical keyboard (below I’m using Upper and Lower) using multiple MIDI In blocks, each one set to allow only a single channel and then save them so that they become trivially available either through the popup menu:
That said, this seems like a case of trying to impose a very old paradigm to a modern system.
For example, I do all those kinds of splits and layers, often on the fly, yet my keyboards (I use up to four of them) use only MIDI channel 1. I can still have different areas of different physical keyboards going to the same “sound” — e.g, I’ll often have an octave or two of hammond organ or strings on different keyboards simultaneously.
But doesn’t this mean it needs to be repeated in every rackspace? I am looking for a global definition that can be reused.
I attempted to realise the solution I described earlier but the global rackspace is for audio only. I don’t really understand the reason behind this design decision.
The regions would not necessarily need to be exactly the same. It would be no problem if I would need to redefine or override the key range for a specific rackspace.
The intent of the global rackspace is to keep a collection of common effects that would be used by all rackspaces, e.g, compression, equalizer, limiter and so forth - if you’re a guitarist then you might have some input preprocessing in the global rackspace (input compression, say) after which you would send the audio to individual rackspaces.
Quite possibly - again, it depends on what you’re trying to do — but I still have a sneaky suspicion that you’re trying to impose an old paradigm on top of Gig Performer. This is something we see from time to time when users come to us from systems like Forte.
So why don’t you describe what you’re trying to accomplish? (Not the approach you’re taking, but the results you want)
As you didn’t mention it, I suppose situation 1 and 2 are not considered together. I am not in a situation where I can test the two following proposals and I would have to check that what I am proposing is working. But well, those are the direction I would folllow:
If you have different keyboard controllers, define a MIDI Device alias for each of them Keyb_1 to Keyb_n. In your Rackspace then use the corresponding MIDI in blocks with the appropriate split (even if you don’t need it when you play on separate keyboard controllers). This will be your first Rig Manager configuration.
For the second Rig Manager configuration, simply assign each Keyb_1 to Keyb_n to the same MIDI device, i.e. your unique keyboard controller. Everything should work flawlessly if your splits are suited for using with a single keyboard.
If you have different keyboard controllers, define a MIDI Device alias for each of them Keyb_1 to Keyb_n and an additional one, say, merged_keyb, for the merged keyboard with separate MIDI channels.
Then you can use the so-called Rig Script to do the following; use a MIDI Event callback from the merged_keyb and on the basis of each MIDI channel reinject the incoming MIDI message on the individual Keyb_1 to Keyb_n MIDI Device aliases (and optionally convert the original MIDI channel into channel 1). With this solution you won’t have to change the Rig Manager configuration. Any message coming from the merged_keyb will be seamlessly redirected to the Keyb_1 to Keyb_n devices such that you won”t need to change anything in your Rackspace.
I checked out this link, but it looks like this can send only one midi data stream. I would like to send multiple from the global rackspace into a regular rackspace.
But the problem remains that I would need to repeat all splitting by midi channel or keyrange in all regular rackspaces.
That is very convenient for a guitar player but why leave out midi support for keyboard players?
I suppose you are right and I will probably replace my keyboards in the long run with usb-enabled equivalents but I thought that GP was all about the enabling use of any keyboard. And what I want is already possible in a regular rackspace but I would like benefit from a more structured approach for which the rig manager concept seems an excellent idea.
What I want is being able to switch between a situation where I have multiple keyboards available (which should be un-merged / split out according to midi channel into separate midi devices), and the situation where I have only 1 keyboard and I want the parts I would normally play on a separate keyboard as a split on this single keyboard. The same midi interface is used in both situations.
The point are the midi filters required to do this. These cannot exist in the rig manager nor in the global rackspace (well, they can but there is no midi communication possible between the global and regular rackspace).
I think this cannot work in practice, rig manager is only for organizing physical devices.
In my opinion it would not make sense to define splits in rig manager.
What do you mean, only one midi data stream? You can send anything you want over OSC
This comes under the umbrella of,“if we waited until we had every feature that every user could ever possibly want, we would never actually be able to release a product”
MIDI will probably get there at some point and as noted, there are several ways to work around it (OSC, virtual MIDI ports, etc)
GP is about enabling all musicians, not just keyboards
I mean: my intention was to split midi data in the global rackspace and send these separate streams into any regular rackspace. The script indicates how to do it in the other direction but I suppose that should be no problem. However if there are multiple midi osc blocks sending there is no way to determine which block will receive what on the receiving end. It’s possible the script can be modified but I don’t have enough experience with gpscript yet.
I was only disappointed that the solution I thought I had found could not work because of this limitation. I am in no way busting the product so I don’t really understand this reaction. If it’s not possible then fine, I can live with that. I only ask in this forum to make sure I’m not overlooking anything.
I don’t understand — what script? You can define MIDI Out OSC blocks in the global rackspace that can send messages to MIDI In blocks in a regular rackspace,
For example, here is a MIDI Out block in the Global Rackspace that is sending MIDI messages to a regular MIDI In block that has the OSC handle “Foo” in the currently active local rackspace.
