Panorama Keyboard support...

[Taron]

Hey Jo, I was just asked about MuLab's prospects to possibly support Nektar's panorama keyboard:
http://www.nektartech.com/panorama-p4-p6.html

They do seem rather pricey, if you asked me, but it looks like all the "hip" DAWs jumped on that train. Might be an interesting thing to take a look at?!

I hope, this doesn't come as an annoyance right now, but before I forget about it again, it felt like a good idea to mention it at least...

[sbj]

There is also the more friendly priced Impact series.
http://www.nektartech.com/impact-lx49-61-plus.html
And it seems it at least, is something worth considering even though, it might be a long term priority.

[Taron]

Thing is, I really think that it's totally overkill, but then I'm kind of a hardcore user, highly comfortable with my computer setup. Any masterkeyboard is a wonderful plus and I absolutely love using the sliders and knobs on those, which I always happily assign per song. If it wasn't brought up to me, I really wouldn't have ever cared about panorama, but seeing the list of DAWs associated with it, it feels like it's a royal collection, desirable to be part of as a competitive, commercial host. This is to say: I'd love to see MuLab mentioned in the same breath as any of those hosts!

[MuTools]

Thx for the tip Taron. Can't immediately work on that atm, will continue the M8 works first.
But i wonder: Does anyone of you have such panorama keyboard?

[Frostline]

Thx for the tip Taron. Can't immediately work on that atm, will continue the M8 works first.
But i wonder: Does anyone of you have such panorama keyboard?

Hi
I think I am the person that brought this issue up with Taron.
I didn't realize that the official forum for MULab was here on KVR.
Anyway, when I tried the MuLab demo it was very frustrating because I have grown accustomed to having the features of the Panorama integrate with my current DAW Reaper. It quickly became clear to me that any alternative to Reaper that I consider must support the hardware I have because it provides too great of a benefit to my workflow.
But I have no idea how the parameter communication works between the DAW and the Panorama. So I do not know if it a Nektar issue or a MTools issue that the two don't easily work together. I just wish they did. There are many features in MULab that I thought were very impressive when I tried the demo.
Thanks

[Michael L]

Out of curiosity I looked at the Panorama manual. They have a Preset system that contains Maps for the different controller types.
http://www.nektartech.com/s.nl/ctype.KB ... KB.1129/.f

It is similar to the Automap system for Novation controllers that I use:
viewtopic.php?f=79&t=487386

To make a Preset or a Map, we need to first choose the synth parameters we want to map to controllers, which is a personal decision. However, mapping a parameter to a controller in MuLab is very fast:
https://www.mutools.com/info/docs/mux/u ... llers.html

The Panorama also has Function keys, and MuLab has a zillion ways to map Functions:
https://www.mutools.com/info/docs/commo ... tcuts.html

I tend to map my controller on a per-project basis. However, it may be useful for those who save their maps as global Presets in their controller software to share the MuLab parameters they chose to map, and the type of controller they mapped it to, and those of use with controllers can enter it in our respective controller software. Perhaps this can only be done globally in MuLab for racks 'n tracks?

If a lot of users own the same controller, you can collaborate on making a Preset for that controller. I think if there are only a few people who need a feature, it is best if we program those ourselves. Users of other DAWs do this a lot.

Also, iPad midi controllers like Lemur and MidiDesigner are far more flexible than hardware so could be awesome for controlling a Mux. (I have Lemur but haven't gone down its Mux rabbit-hole yet). IMO the Midi-in-Mux workflow has vast possibilities and can become the 'secret sauce'

[Taron]

I hope, I won't derail this, but I'm wondering about control connections, which would ignore focus on any vst. Like having a constant access to the transport system, even as a vst is in focus.
Does that mean such controllers have an additional way of communicating with the DAW outside of Midi?
(That would make me twice as angry about my cat, who destroyed the USB socket on my Akai MK88)

[Michael L]

Keyboard shortcuts are non-midi data. I believe Panorama Function keys send commands that can be used as keyboard shortcuts; other controllers may do the same.
I have a lot of transport-related shortcuts mapped to my computer keyboard: Play/Stop; Rewind; Start Stop Recording; Sequence Make and Delete; Track Add, Solo, Mute, delete; etc. (Someday I'll stick labels on an old keyboard.)
All midi controllers send Midi one-way to the computer: you choose the knob for each CC.
Automap and other mapping programs are two-way: they get the pre-assigned CC numbers from the non-modular plugin and map them to knobs.
According to quantum theory, it is possible for MuLab users to agree on the best way to map keyboard shortcuts and Midi, to create and share standardised templates for our controllers .

[Frostline]

I hope, I won't derail this, but I'm wondering about control connections, which would ignore focus on any vst. Like having a constant access to the transport system, even as a vst is in focus.
Does that mean such controllers have an additional way of communicating with the DAW outside of Midi?
(That would make me twice as angry about my cat, who destroyed the USB socket on my Akai MK88)

I think (though I do not know) that there almost has to be more going on than just midi.
For example,
I start Reaper
I add a new virtual instrument, say LotS
Since I didn't make a custom mapping for it (various reasons) it goes to default. That maps the first 48 parameters that LotS exposes to the host in the order it exposes them to my Panorama.
The panorama display not only labels the rotary knobs and faders it also displays the current parameter values for each control via a 4 page display. The rotary encoders are endless so they always are in the right spot. The faders display indicates the fader position based on the parameter value and it simultaneously displays the physical position of the fader so the user knows exactly how much to move the fader to get it to match the actual parameter value for soft take-over.
So when firing up LotS for example the 1st page of the right 8 encoders are Hit Power (which is Rise on LotS GUI), volume, 4x BOW temp, sA balance and decay. All also display the current values for the parameters.
That all happens automatically.
I can of course change the default mapping to whatever I like. Usually for example I like ADSR amp and filter envelopes (if the synth has them) on the 1st page so I make a custom mapping in the Panorama).
But with seeing the data of parameter names actually coming from the host into the Panorama as well as values (without touching anything on either the LotS GUI or the panorama) makes me think there is more communication going on beyond simple midi.

As far a transport and focus...I can have the LotS GUI floating and moving it around the screen with my mouse (so it must be the focus yes?) the transport controls still work on the panorama. I can play/stop/pause/move to markers etc all while holding the LotS window with my mouse.

The panorama has 4 mode buttons, mixer, instrument, transport and internal.
When in mixer mode I can switch tracks, solo/mute/arm/disarm tracks adjust track volume etc all from the panorama.
Instrument mode lets me control the parameters as described above. Plus other neat things like drop in an EQ on the track with a button press and the EQ controls are mapped and ready to adjust right from the panorama.
Transport mode assigns additional encoders to things such as position and zoom in addition to the many transport buttons that play/stop/rec prev marker etc that are in the specific transport section.
Internal mode basically makes the panorama function like a "dumb" midi controller. Probably does other things too, but I never use it.

Internal mode is the only selectable mode in MuLab.
I can use the keybed, and the 12 pads.
I can manually assign for example an encoder to a parameter(tested with the default synth when MuLab starts) and it will adjust the parameter. But there is no indication in the panorama display as what the encoder is assigned to or what is the value of the parameter. I also cannot change "pages" to assign the encoder to an additional parameter based on which page is active because "pages" are inactive in internal mode. This cuts my available encoders on the right side from 32 to 8. Which, since they are not labeled is just as well since I would not remember what the knob does a few moments after assigning it anyway without the display reminder.

Anyway, I understand if panorama integration is not a huge priority. It is not a popular controller, so limited potential benefit in supporting it. But as a user of one I would not not switch to a DAW that does not have good support for it.

[Michael L]

^^^ MuLab is different. It gives you hundreds of keyboard shortcuts, and an almost infinite number of ways to construct an effect or other module. So you choose the best way to map them. Mapping is very fast- one mouseclick and one knobtwist- and then save your mapping at different levels. The time you spend to midi-map a template, etc is a small price to pay for modular flexibility. OTOH, I can automap third-party plugins I use in MuLab because they have a fixed architecture.

[justin3am]

I can't go into detail about the way that Panorama interfaces with DAW applications but there are some concepts that are common among control surfaces.

Parameter feedback - Many control surfaces get name and value strings from the host application, to show on their own display. Parameter values can be as simple as sending the same control message back to the controller, but if you want formatted values and text strings for parameter names, it's better to do so with sysex messages.

Dynamic mapping - When you have a common set of control types which reoccur, you want to be able to define a group of them and call that a bank. Then you just need a method to select which bank is currently active, so you don't need to manually re-map controls when you want to control parameters in a different group. You find this commonly in mixer style control surfaces, where you can select a specific track or banks of 8,16,24, etc tracks. Panorama takes this idea to another level.

Host automation vs. Standard MIDI communication - Almost all control surfaces communicate via standard MIDI messages. Most DAW applications have a page of settings which allow you to route MIDI ports directly to track inputs for recording and playback. Some applications allow you to configure MIDI ports for use with control surface features. This is a means for a MIDI device to request information from the host and send information back. For the second method, the application's developers sometimes provide documentation for third-parties, to develop their own interface between the controller and the hosts control surface features. Some applications blur the lines between these two methods, giving users a graphical interface to create custom mapping which can follow track changes and even provide parameter feedback.

When a MIDI device is acting as a control surface, generally, it is not sending MIDI data directly to a track/plug-in input. In most cases, the host application provides information about a plug-in via it's automation system. There are a lot of benefits to using this method, as the host can get parameter names from the plug-in then pass them on to the controller and you can let the plug-in or host determine the resolution for a parameter. This method also allows us to parse thousands of parameters and present them in a way that is organized and intuitive.

Combination keyboard/control surface devices like Panorama can act as standard MIDI controllers and control surfaces simultaneously. They present multiple ports (USB end points) via a single USB instance. This way they can send note and unformatted controller data directly to track/plug-in inputs but also communicate with the hosts control surface features. The separate ports are necessary to prevent the two methods of communication from interfering with each other.

I can't comment on how any of this relates to Mulab. The MIDI mapping functions seem to make it pretty easy to map parameters to physical controls, and since it's a modular environment, I figure the capability to do more advanced stuff with MIDI is likely there. Currently, it requires a lot of work to implement Panorama's integration for a DAW. From our end and from the side of the DAW developer. Even implementing support for MCU or HUI is non-trivial. Ultimately we are looking for ways to make it easier to get control of a DAW application and the plug-ins it hosts, without asking so much of the DAW developers. It's an interesting challenge.