Multiple Ports not recognized

Cubase
,
1

Hi, I thought I should add this here as an issue with multiple midi ports in scripts, when we create a new (empty) project.

When we have a ports pair, no problem at all, Cubase immediately recognize it, and loads the script.

However, if we add another ports pair, it is not recognized automatically and gets us to the port setup window of the script.

Testing this is pretty straight forward:

var midiremote_api = require('midiremote_api_v1')


var deviceDriver = midiremote_api.makeDeviceDriver('test', 'test', 'multiple ports issue')

var midiInput = deviceDriver.mPorts.makeMidiInput()
var midiOutput = deviceDriver.mPorts.makeMidiOutput()

var midiInput2 = deviceDriver.mPorts.makeMidiInput()
var midiOutput2 = deviceDriver.mPorts.makeMidiOutput()

deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
    .expectInputNameEquals('loopMIDI Port')
    .expectOutputNameEquals('loopMIDI Port 1')
	
deviceDriver.makeDetectionUnit().detectPortPair(midiInput2, midiOutput2)
    .expectInputNameEquals('loopMIDI Port 2')
    .expectOutputNameEquals('loopMIDI Port 3')

If we remove the second pair (midiInput2 & midiOutput2), no problem at all! If we include it, the issue arises.

I’ve intentionally used virtual ports here, in order for it to be easily reproduced, however it obviously happens with “real” midi ports as well.

As a workaround, I have setup a project template containing the script, so this isn’t a big trouble in the end, but anyway, I think that this should be taken care of.

2 Likes
2

Hi,

Oh yes, please!

1 Like
3

Just out of curiosity:

What would be the implications of creating another separate deviceDriver object?

4

Hi Nico5, good question!

Generally, maybe none.

In my integrations, however, this cannot work. I’ll give you three examples of different nature:

  • My Arturia Keylab has two ports. The thing is, when I’m changing the mode of my control (from DAW to Analog Lab, if you happen to know how this controller works), the second port sends a message for that, and I need to know it, in order to suspend updating my lcd display which however listens to the first port. At the same time there are some additional functions performed on port 2, but I want to display feedback on port 1.

  • A second example and more generic, is when we want additional functionalities not already implemented by the API, to be received and send feedback to our “main” controller. We setup a virtual port to get the data and then inside the script we send whatever is needed to our “real” port. I use it all the time by creating a pseudo-Mackie and/or generic remote for this virtual port.

  • A final example is for when we want to translate messages. Say that we want that when user clicks on a control on our “real” controller, which sends a midiCC to transform it to another midiCC (or note, or whatever). We’re going to need a midi output for this and this cannot be our “real” port, in order to get the message to Cubase. A good use case for this, is when we split an encoder to left/right midiCCs which can then be midi-learnt by the users inside the assistant.

5

I guess my question was, if you could maybe create a new persistent object that contains multiple deviceDriver objects? Each of those objects would only contain one midi in and one midi out port. So the multiple deviceDriver objects would each just have one pair of midi inputs and outputs.

The idea would be to get around what seems to be a limitation of the deviceDriver class?

And then events in one of those deviceDriver objects could maybe trigger actions in the other deviceDriver object?

But since I’m painfully inexperienced with programming this way, there may be a big conceptual limitation I’m missing. If yes, I have to apologize for a possibly very silly idea.

(Right after the release of Cubase 12, I had successfully programmed one MIDI Remote script (with just one pair of input and output ports), but since then have only used the GUI configuration environment. )

1 Like
6

Ah, sorry, I now get your point!

Not, really, no, as far as I can see, and I hope I may be wrong on this.

Let me explain:

Say you create a deviceDriver

var deviceDriver = midiremote_api.makeDeviceDriver(arguments here)

Now, suppose you want to add a second one:

var deviceDriver2 = midiremote_api.makeDeviceDriver( the very same arguments here again)

What really happens is that both deviceDriver and deviceDriver2 refer to the very same object, simply because they actually have the very same arguments, to keep it simple.

“Why?”

Well , say, you change the arguments for your second driver. This won’t work, since Cubase is scanning scripts based on these arguments. Its approach (a correct one if you ask me) is to create a driver per device per script file at least so I understand :slight_smile:

EVERY idea in programming can’t be silly by definition. We always have to workaround things, no matter how clever or silly, cruel or elegant our approach may look :slight_smile: Thank you for your suggestion!

1 Like