Nektar Panorama Integration

Hi all,
Just wanted to ask if anyone has a Nektar Panorama P6/P4 working well with Ardour? Nektar have it working very nice for the usual suspects like Logic and Bitwig with the midi mapping and ALPS motor fader etc, but dont publicly say anything about Ardour support.

Many thanks!

1 Like
For Bitwig Studio, Cubase, Nuendo, Logic Pro, Reaper and Reason users, Panorama is a dream come true. The dedicated communication protocol ties Panorama and your DAW tightly together so all you have to do is select the mode and menu you want to control. Panorama does the rest.
(emphasis added)

That doesn’t sound too promising. Other aspects of the device description suggest it just sends generic MIDI, which means that it should be pretty easy to put together a MIDI binding map for the device. But without one to test, there’s really no way to know.

Thanks Paul, yeah it has a generic midi mode and Im starting to use it with Carla Rack & assorted plugins. Looking into creating a new control surface mapping for Ardour now but this is new ground for me, I have to learn the process. Will get back to this thread when I have some more comprehensive results!

I also recently purchased a second hand P6 and have been asking Nektar to consider supporting Ardour and Mixbus since they are two of very few cross platform DAWs out there.
If we really try, we might get them to support “us” out of the box. Otherwise we might have to hack something up. (I have not even started my Nectar yet)

I am open for collaboration if we need to map stuff manually.

Got a reply from Nektar and a URL where a working Nektar Panorama map for both Ardour and Mixbus is located.
Have not yet tried my Nktar yet but will do soon…

I hope this is what we need

Nice! If this works (please test), it’d be great if we could include the file directly upstream with Ardour/Mixbus.

PS. The linked post suggests to copy it into the application folder, for testing or custom maps the user-prefs dir would be more appropriate.
PPS. are the .syx files needed to initialize the device every time, or is it just a one-time setup? Theoretically Ardour can play back sysex from a normal MIDI track, but perhaps some tigher integration is warranted.

1 Like

thanks for the response…

I will try this soon and report back.

On a side note
I would love to have sysex bulk dump support in ardour some time in the future since there are not that many other tools out there ready in distro repos for this kind of old school midi transfers… Especially if the sysex in this case needs to be sent every time the Nektar is supposed to work with Ardour/Mixbus

Nektar support had tried to contact Ardour via help@ in the past to get the mappings included but had not get any response but he was going to try again since it is in their interest to not have to manually provide information on the map file and how it is used.

Maybe a form on where vendors can upload map files or other information that the projects might need would be a nice gesture to them. I don’t expect them to line up but it would speak loud and clear that the project wants/needs/encourages that type of information. Just my 2c

Opensource project are usually very open and one can discuss and participate through IRC, forums, mailing lists and various other means but regular commercial companies probably will try to call or send an email which very likely might not get through… at least so it seems

I also happend to see a commit for LUA-sysex operations yesterday, Nice Robin !

@ahellquist: paul (help@) said he’s in contact with them. He may or may not chime in here. Anyway, these days I expect the easiest way for 3rd party party contributions, is a pull-request on github. For confidential discussions the ardour-bug tracker allows to mark bugs as tickets as “private”. I don’t think a dedicated form is needed, although announcing and documenting those two options might be helpful.

The Lua-script is handy for prototyping and testing. A first step to investigate. Since Ardour’s audio-engine is realtime, while most sysex dump/replay utils are not and send as fast as possible, as slow as needed.
Ideally it’ll be possible to embed the sysex data into the midi-map, and transmit it when the device is connected. The hard part there is to design the interface and options that works for many devices.
Can a single map have multiple sysex-config (dropdown select)? Allow a user to disable it or manually [re-]trigger it? Tightly integrate it with control surfaces or allow a more generic sysex manager or both? etc.

They sent one email, yesterday, and I received it, and I replied to it. Their map(s) will appear in the next release of both Ardour and Mixbus.

1 Like

Great Paul and X42

Btw, the sysex file will only be sent once (or after a factory reset)

You should only need to transmit the sysex file once. It just loads an internal Mode preset. The Bitwig integration will not interfere. The only time you would need to restore that sysex file, is if you restore the factory defaults.

I have considered buying one of these. With full Ardour/Mixbus support, I may have to now. I noticed it mentioned Mixbus 32C only. So no support for standard Mixbus?

Good Afternoon

I have just aquired a Nektar Panorama P1 control surface , I am looking for guidance getting it working with Ardour 5.12 . I see that a link was posted above however this is now returning a 404 error .

Any help greatly appreciated


It is very unfortunate that for some reason, I never followed up on this or something went wrong.

So, starting again from scratch:

No idea on whether you’ll get the Nektar working, or what it can actually do. There are 3 levels of control surface in Ardour;

  1. Dynamic MIDI learn - bind specific MIDI messages (note, CC) to a parameter
  2. MIDI Binding Maps - preconfigured bindings between MIDI messages and parameters
  3. Custom surface support - written in C++, dedicated code that understands a lot more about the device and its state

The first is intended for use with simple MIDI controllers. The second can be used with just about anything. The third is required if the device needs messages to turn on lights/change its display/manage its state.

Docs on binding maps can be found in the Ardour manual:

To do anything with the device, you will need to know what messages it sends. This can be accomplished by using a MIDI monitor application appropriate for whatever platform you are on.

Many thanks for your prompt reply Paul . I will look at that .

I have found the following Link :

Which on download unpacks what appears to be an xml file ( Out of my comfort zone here )

And Sys Ex file . The website instructions state that you have to send the sysex to the P1 and give instructions to place the XML file in .config/Ardour

So far Ardour can see The p1 as a midi device and learn faders and encoders but not transport

As ever any help greatly appreciated


Great that you found the link. I’ve added the binding map to our repository so it will be in the next release. Meanwhile, you can put the XML file in the right place. Their document gives these for Windows and macOS; on Linux it will be $HOME/.config/ardour5/midi_maps (you will likely need to make this folder before moving the XML file there).

The sysex is more of a problem. I can’t give you a good solution on how to load that.

When using Ardour 5, the transport controls are not “learnable”. This is fixed in Ardour 6 (soon to be released).

It may be sensible to document what the Panorama actually sends and hopefully there is a way to create a binding map that works without loading the sysex files.

Good Evening

Solved the Sysex send with this windows utility using WINE , couldnt find a native linux program that I could get to work :

Created the folder , put the XML file in it and I now have working transport controls . I now need to understand how Ardour deals with templates ( Time for the RTFM step :slight_smile:

Many thanks for your kind assistance


Good Evening

Having bought this off ebay for ÂŁ90 I am satisfied with it so far. The transport and faders work just fine . The rotary enocders however only return 1 0r 127 so they dont control plugins properly . The XML file is below , has anyone any ideas of this can be edited to fix this ?

<?xml version="1.0" encoding="UTF-8"?>

Regards as ever


<?xml version="1.0" encoding="UTF-8"?>

Well I cant seem to post the XML file . however with some plugins the encoder
work as you would expect.