GP not compatible with Arturia controllers?

Hi, I´m just testing the demo of GP 3.
My live setup is based on a Windows 10 laptop, an Antelope Zen Tour audio interface and Arturia controllers.
Unfortunately the Spark 2 VST refuses to connect to the Spark CDM controller when hosted in GP, no matter what combination of MIDI I/O I try.
The Arturia Keylab MK II keyboard, which has a deep integration with AnalogLab 4 doesn´t get back the information from the VST.
I can control AnalogLab 4 from the KeyLab hardware and I see the changes on the GUI of the plugin, but I get no feedback or information on the display of the keyboard.
AnalogLab has no MIDI out, so there seem to be a different kind of internal communication.
This is working in all DAWs I have tested, but not in GP.

I don’t know much about you setup, but I guess your plugin communicates toward your hardware using a MIDI connection, so I suppose you connected a MIDI output of your plugin to a GP MIDI out block connected to your hardware ?
Could you please post a screenshot of your GP connections view ?

Hummm… really ?

I just checked an older spark manual (1.5), it seems that the VST has two MIDI ports, an “internal” for controlling the hardware (you are not supposed to use it for something else) and another one which can be used as a standard MIDI in/out port.

Private port:
On Windows Vista and Seven : “MIDIIN2(Spark Controller)”
On Windows XP : “Spark Controller [2]”
On Mac : “Spark Private IN” and “Spark Private OUT”

Public port:
On Windows XP, Vista and Seven : “Spark Controller”
On Mac : “Spark Public IN” and “Spark Public OUT”

Could it be that this private MIDI port is disconnected from you hardware ?

Did you install something like a Arturia Remote Controller Script which is used by a DAW like Ableton Live?

I have just tested it with Cantabile demo, the communication between the KeyLab and AnalogLab is working there.
When the KeyLab is in AnalogLab mode, all changes made on the controller are visible in the GUI and on the display.

Back to Gig Performer the same combination of MIDI connection doesn´t work in both directions.
Parameter changes show on the GUI, but no feedback on the display.

I made the same experience with some other programs I have tested, it seems the MIDI stream is filtered somehow, so that the bidirectional communication between the plugin and the controller breaks.

I tried it with both ports or each of them, in no test I could get a connection between the plugin and the controller.
Gig Performer is detecting both ports, but it seems to block the communication in a similar manner as with the KeyLab.

I have installed the Arturia MIDI control center.
I think this provides the drivers for their hardware.

The Remote Control script is only needed when you want to control Ableton Live with the Spark hardware.

Hmm, if this is on Windows, the problem might be that Gig Performer opens all MIDI ports but unlike on Mac, most Windows systems only allow one application to open MIDI ports (sigh). At some point, we should add the ability to GP to tell it which ports it should not open. In the meantime, I believe the workaround might be to use a virtual MIDI driver such as (https://nerds.de/en/loopbe1.html) or (https://www.tobias-erichsen.de/software/virtualmidi.html)

It is not connected by default, I would try to connect the private out of the VST to your hardware controller. Does GP provide MIDI blocks for them ?

What is your idea with the MIDI virtual ports ? I thought if you simply add the “private” MIDI out blocks related to the Arturia “internal” MIDI ports and set the MIDI channel to the one of its hardware controller it should be enough to activate the connection again. (no need to connect anything to the in port of these MIDI out block). Do you think It is not enough ?

Yes, the MIDI I/O blocks are there, but on the plugin box you only have one MIDI in and one MIDI out.
I tried it with Public In -> Spark VST -> Private Out but no success.
Even with Omni I/O which should grab all available MIDI connections it doesn´t work.

The problem (only in Windows) is that most MIDI drivers only allow one application to open them. So when GP starts, it opens all MIDI drivers that it finds. So then if you load a special VST that wants to communicate directly with some device over a MIDI port, the VST can’t open the MIDI port because it’s already opened by Gig Performer. I think there’s a Roland VST for which there’s the same problem. It’s really a poor MIDI driver implementation on Windows but applications have to deal with it. We’ll add a way to select MIDI ports that should NOT be opened by Gig Performer.

The idea of those virtual ports is that they open the physical port at one end but then they allow multiple applications to open the new virtual port and so both Gig Performer and the VST can communicate with the port that was otherwise blocked

But why does it work in DAWs then?
There you choose the recognized I/Os and the connection is ok.

I am not talking from the MIDI in/out of the Arturia plugin, but of the GP MIDI out blocks that you can add from the GP MIDI out plugin menu…

Some DAWs already have the ability to not open all ports – Cubase has that, for example –

NB I’m just speculating that this is the reason why it’s not working.

But it seems that changes from the controller to the VST (private MIDI in port I guess) works fine. So I supposed that the communication between the VST and the private MIDI out could work if you put the corresponding “private” GP MIDI out block in the connection view set to the appropriate MIDI channel :thinking:

Ok, now I have tried it with a virtual MIDI cable.
I connected Spark MIDI in to Virtual out, Virtual In to Spark VST In.
The same with AnalogLab and the KeyLab.
No success in any configuration.
Here are the available ports and the VST box

From the Spark 2 manual:

7.2.1 Device ports (Spark Creative only)
The Spark controller is displayed within a host application as consisting of two sets of MIDI ports.
The first set of MIDI ports will present these labels to your computer:

  • On Windows Vista and 7: “MIDIIN2(Spark Controller)”
  • On Windows XP: “Spark Controller [2]”
  • On Mac: “Spark Private IN” and “Spark Private OUT”
    Note: These MIDI ports SHOULD NEVER BE USED by any application; they are used for internal communication between SPARK and the Controller. Telling the host software to use these ports would impair the efficiency of the controller.
    The second set of MIDI ports will present these labels to your computer:
  • On Windows Vista, 7 and XP: “Spark Controller”
  • On Mac: “Spark Public IN” and “Spark Public OUT”
    These are the public ports that are available for your applications to use.
    All messages sent to these ports will also be sent to the Spark Creative controller’s physical MIDI Out port. All messages sent to the Spark Creative controller’s physical MIDI In port by an external device will be transmitted to the host software internally by the public port. When using Spark Creative as a MIDI controller, the data flow from the controller will be sent on the USB public port to the host, as well as to the MIDI OUT port, adding itself to any other existing MIDI information.

So the Private ports (Windows: MIDIIN2(Spark Controller)) are only used or necessary if you want to use the Spark hardware as controller for other applications?

I am not sure I understand the problem completely, but it seems that something is expected to be set via midi out connection back to the keyboard right?

GP opens all midi ports so you can easily connect anything anywhere. Is it possible to somehow create a midi out block for your keyboard and then connect the expected midi in to that midi out?