Bug with StreamDeck + : controllers are linked

Whenever a CC is assigned to a dial all other dials that are programmed to the same CC on the same midi channel are linked. That behaviour persists even when the dials are programmed to output on a different midi ports.  For example, if dial #1 is set to B0 07 on a given port, any other dial set to B0 07 on a different port will move accordignly (without sending the value to their port).

Hi,

I assume the dials have the same Midi in port, in which case they will behave like that even though they gave different Midi out ports.

This behavior is "by design"; I can explain why if you are interested.

I didn't use any MIDI in ports. When I set a dummy (and different) input it works as expected.
I work with many small modules that don't have any MIDI output so assigning an input in StremDeck was not that obvious...

Would it be possible to implement a function to unlink controllers that use "no midi input" ? I have a pretty large midi port count (39 ports at the moment) and that would be very convenient not to care about a dummy input (in 2 years, I might use that dummy port and will ask myself why StreamDeck behaves erraticaly )


Keep the good job! This plugin is nothing but marvelous!


n.b. Yes, while I understand how feedback is important, I'd like to hear the "by design" choice in this specific "no input"  situation.

That was an interesting use case.  

Tech talk:

The plugin has a background service that monitors all configured midi (in) ports and saves the data in an in-memory database when a command is received. This is done regardless of whether any buttons are linked to the incoming command. The plugin does this to have as complete a picture as possible of the state(s) of the other party and to be able to give buttons and dials the current state when you switch pages and profiles.

In this "job", the plugin is input-centric, i.e., the task is to build a mirror view of the states of the other party, not a view of what you are sending. That being said, the plugin does save the command state when you send a command, but it does so for the configured INPUT port. It is still input-centric and presumes that sending a command to the other party will set the state accordingly, even if you don't get a command response back, and hence, it saves the state for the input port.

Changing all buttons, dials, background services, and Midi drivers to save the state for the output port if no input port is used, is probably a massive undertaking. What makes things "worse" is that buttons and dials don't have any opinion of their own of the current state/value for a control; every time they need the current value, they ask the in-memory database.

Maybe the plugin-internal midi ports in the upcoming plugin version can make things a little bit easier for you?  
You will have unlimited internal ports available without the need to create them in loopMidi/Midi Studio.


Addendum: In this context, "No Midi Input" is just another internal Midi port from the plugin's point of view.  All buttons and dials "connected" to "No Midi Input" will share the state in the in-memory database.

Thanks for the tech talk. Interesting backgroud.

As you suggest, the internal port will probably be a good eniugh work around for my usage.

Would it be possible to add  something like a ''self'' as a midi input wich would be fed by an invisible parallel internal midi out port...if that make any sense!

kx3 wrote:Would it be possible to add  something like a ''self'' as a midi input wich would be fed by an invisible parallel internal midi out port...if that make any sense!

Have you tried setting midi in to the same port as midi out? That is basically what you suggest...

Yes that will work in most cases. But at some point I will have to use a port that will be used by another controller.
 It's just to avoid confusion because my ports are not all i/o, some devices have no output and some no input that's why I'd like to use a set and forget input dummy port. I understand that my case is not that common and I don't plan to sue you if you don't fulfill my wishes! The implementation you did for the SD+ is amazing and it has replaced many hardware midi controller that I relied on.