Ctrlr vsti sends midi messages twice

[Possemo]

Does someone know a workaround for the vsti bug sending midi messages twice? Or is this not an issue on modern synths? When you send a midimessage via Lua script it will send the message just once, but all modulators no matter if sysex or CC’s will send all values twice.

I am thinking about making a special vsti version for my panel that will send values via Lua script but I would be glad if there would be an easier way…

[dasfaker]

With Ctrlr plugin, if you set to on “Enable output to plugin host”, messages are sent to the midi output port and to the host, and the midi monitor shows the same message duplicated. But there’s only one sent to the synth’s port.
You can see the name of the ports where messages are sent on the midi monitor, menu View -> Show device name

[Possemo]

Thanky you for your answer dasfaker. Well this makes me thinking that the bug could be related to my vst-host (Reaper). Ctrlr MidiMonitor shows this:

[17:50:32:000842]: Dev:[VST OUTPUT] Ch:[ 1] RAW:[b0 63 00]
[17:50:32:000842]: Dev:[VST OUTPUT] Ch:[ 1] RAW:[b0 63 00]
[17:50:32:000842]: Dev:[VST OUTPUT] Ch:[ 1] RAW:[b0 62 05]
[17:50:32:000842]: Dev:[VST OUTPUT] Ch:[ 1] RAW:[b0 62 05]
[17:50:32:000842]: Dev:[VST OUTPUT] Ch:[ 1] RAW:[b0 06 01]
[17:50:32:000842]: Dev:[VST OUTPUT] Ch:[ 1] RAW:[b0 06 01]

This should be 3 messages not 6. I will test this on Cubase maybe it reacts differently. Most people here seem to use Ableton Live, maybe this works best…

[Possemo]

Btw. same prob with sysex:

[19:22:57:000301]: Dev:[VST OUTPUT] Ch:[–] RAW:[f0 41 39 00 24 30 01 19 69 f7]
[19:22:57:000301]: Dev:[VST OUTPUT] Ch:[–] RAW:[f0 41 39 00 24 30 01 19 69 f7]

But it works as expected with Lua generated sysex:

[19:26:23:000288]: Dev:[VST OUTPUT] Ch:[–] RAW:[f0 41 38 00 24 20 01 20 46 41 54 20 46 49 46 54 48 20 38 00 00 60 4e 05 00 40 00 00 40 00 00 73 7f 7f 35 00 00 00 62 55 6d 68 63 00 00 00 00 00 00 00 00 00 00 00 00 7f 00 7f 00 7f 00 23 63 00 29 16 41 71 36 00 00 00 60 00 60 00 60 60 00 20 20 00 00 00 00 20 00 00 00 00 50 50 20 50 50 40 60 40 20 00 10 00 00 00 00 10 00 00 f7]

[Carl Licroy]

Hi Possemo!

I’ve experienced the same behaviour with CTRLR, that’s why when I load a panel, I only setup midi “Input” and “Output” and let “Controller” set to “none”.

[Possemo]

Hi Carl. First I want to thank you for your great Prophet08 panel. I used a lot of lua code for my own panels.

The issue I described only happens in the vst plugin. I just select “output to plugin host”. Input, Output and Controller are set to –None. But it still sends Midi messages twice.

Disabling “output to plugin host” and selecting an “Output” is not an ideal workaround as the vst-host already uses the Midi-port where the synth is connected to. There may be a way with virtual Midiports, re-feeding into the vst-host.

[Grimulkan]

This issue still exists when using host MIDI I/O, i.e., every message is sent twice. Likely a bug.
2 workarounds:
1. As Possemo mentioned, using virtual MIDI ports and turning off host MIDI I/O. Sadly, this won’t work correctly if using Expert Sleepers’ MIDI outputs, which require the the MIDI data to be routed inside the DAW to be sample accurate.

2. Custom plugin that removes duplicate consecutive MIDI messages after CTRLR output. Seems like a waste of resources to process everything, but it does work. I have one written in Reaper JSFX if anyone is interested. The doubling of messages always occurs consecutively as far as I can tell, but it might not work if using several different multi message output modulators.

Any other workarounds possible with Lua scripting in CTRLR?

[Possemo]

Hi Grimulkan,

nice that finally someone bothers this too :-). It is true that many synths don’t care if they receive the same messages twice. But nevertheless I think it is Ctrlr’s most serious bug. Bandwith of MIDI is very limited, so it could provoke lots of weird things like e.g. timing probs.

As mentioned before: when you send messages by Lua scripts it does not happen. Here a simple example:

sendUselessMessage = function()
panel:sendMidiMessageNow(CtrlrMidiMessage({0xF0, 0x10, 0x06, 0x0a, 0x01, 0xF7}))
end

So the bug seems to lie on the MIDI-send component of Ctrlr. In theory you could make a complete panel without using the MIDI component and instead doing it all by Lua scripts. But this is a lot of (useless) work.

One day I will to get into the Ctrlr code and will try to localize this big fat bug…

[Grimulkan]

That makes sense, thanks for the code.

I’m thinking that for the bug, the host output is getting MIDI from the input port along with the MIDI that would otherwise be forwarded to the output port. So effectively twice. But that is just a guess.

[goodweather]

Hi guys,
I experienced the same on Ctrlr Standalone and on MidiMessageReceived.
Searching on the forum I found the workaround that consists in resetting the Midi devices on panel load. The proposal was to reset the Controller devices.
BUT this was then removing the bidirectional behaviour of my panel.

The solution I found was to reset the Input devices at panel load and this is working fine:

-- Reset Midi INPUT devices to avoid having MidiMessageReceived method called twice
-- If resetting Controller devices then the bidirectional behaviour is loss (most probably a bug)
sMidiDevices = panel:getProperty("panelMidiInputDevice")
panel:setPropertyString("panelMidiInputDevice", "-- None")
panel:setPropertyString("panelMidiInputDevice", sMidiDevices)

So, maybe that you try resetting the Output devices instead to solve your send issue?

[CleverMonkey]

Hi, this is an old post so maybe this is old news (and I am a Ctrl noob) but I seem to have solved the problem, at least for my needs (Ctrlr as VST in Reaper) by checking the “No MIDI output from panel” option. Hope this is helpful 🙂

[goodweather]

Well, removing the Midi Output completely should prevent you to enjoy the benefits of bidirectional behavior, no?

[CleverMonkey]

One would assume so.. But seems to work fine here with that option checked in the panel properties. . Midi settings are “Input from host to comparitor” and “Output to plugin host”.

[Possemo]

Hi CleverMonkey, this is a nice find – though there is still a problem.

I first want to say that this discussion in solely related to the Reaper DAW. The other DAW’s I know (Ableton and Cubase) are not working anyway. On these DAW’s you have to dedicate the midi ports to Ctrlr. You have to disable the ports on the DAW – in the case of Cubase: it does not assign ports as long as you don’t use them on a track. This configuration is working fine – no doubly messages, just set the ports in Ctrlr as you would in standalone Ctrlr. Meanwhile I prefer this config to the one with “input/output to plugin host”. First, there is no doubly-message-bug and second you have no problems with midi feedbacks because you don’t have to set midi thru-options in Ctrlr. Only drawback: you cannot use the keyboard of the synth as a masterkeyboard for entering notes into the DAW – the input-port is dedicated to Ctrlr.

The other prob with CleverMonkeys find: when you disable midi out with this checkbox it won’t send data twice via modulators – but it won’t send data at all via Lua scripts.

[daimondamps]

This is the only workaround for me:

function resetMIDIdevice()
	-- Trick to avoid doubled MIDI messages
	local sMIDIDeviceName=panel:getProperty("panelMidiOutputDevice")
	panel:setPropertyString("panelMidiOutputDevice","-- None")
	panel:setPropertyString("panelMidiOutputDevice",sMIDIDeviceName)

	local sMIDIDeviceName=panel:getProperty("panelMidiControllerDevice")
	panel:setPropertyString("panelMidiControllerDevice","-- None")
	panel:setPropertyString("panelMidiControllerDevice",sMIDIDeviceName)

	local sMIDIDeviceName=panel:getProperty("panelMidiInputDevice")
	panel:setPropertyString("panelMidiInputDevice","-- None")
	panel:setPropertyString("panelMidiInputDevice",sMIDIDeviceName)
		

end

• This reply was modified 4 years, 9 months ago by daimondamps.
• This reply was modified 4 years, 9 months ago by daimondamps.

[goodweather]

Yep and this is what I have been using except that I only do it on the Input Devices and that it seems to be enough.
Now, doing it on Output and Controller do not hurt either 😉

[shooking]

I dont want to be “that guy” but it does hurt on my setup at least.
I can write the Input and Output to None most of the time.
But Controller channel will crash panel – which is nasty but of course I am trying to reset the Midi because of some overflow I guess.

I would love a “drain input, controller, output” method instead.

I am relatively careful to keep in and out disconnected (dont want midi tail chasing) – but especially on my K1r I get hangs. Sometimes if I am patient the midi recovers.
More often than not I have to stop Ctrlr and start again. Sometimes I have to reboot the whole PC>

I thought about putting MidiYoke on it to try to debug but not sure that plays nicely with Windows 10.
If _could_ be my Midex8 since that is “best efforts” driver from Steinberg. I will make time to trial this with other interfaces (no not the cheap Far Eastern ones ..dont be silly – they dont even have optocouplers in them most of the time!!).

I have to replace the battery in my K1r anyhow so I will use that time to repipe and retest.

In the meantime time the best I can do is use above to reconnect input and output – controller kills Ctrlr when I am in a hang.

[goodweather]

Can you describe your setup? Why do yo need Controller?
Usually you can achieve everything with just Input and Output devices then using Midi Thru : Input to Output which is redirecting the input of your master keyboard to your module through the panel.

[shooking]

Yes. I asked related question on https://ctrlr.org/forums/topic/any-documentation-on-midi-input-controller-output/#post-117905

See I need to send Sysex to and from a K1r. But I also want to be able to control it from a keyboard (it’s a sound module).

What I am finding is Ctrl hangs a lot. Hence I tried the reset trick. And if I set the Controller to the none well it crashes instantly.

Would be good to find definitive definition with some pictures on how to view Ctrlr. Linking in to out isn’t what a real thru does. I would prefer if Ctrlr behaved more like a standard Midi device.

In that case I would have to put k1r out to Ctrlr in and vice versa to allow sysex transfer both ways. And I would need a midi merge if I also.wanted to trigger internal k1r sounds

It seems from my experients that this is what the Controller channel is doing …it merges midi in with the controller input except I would have to write logic to forward on certain midi events.

If I connect so called thru and send a sysex it doesn’t take much for the panel to crash. Without thru it is more stable – not perfect but for sure better.

[goodweather]

Thx for the precision.

Which version of Ctrlr are you using?
5.3.201 is the recommended stable one.
There is no issue to keep Controller to None.

To achieve what you want: bidirectional sysex and usage of keyboard to play the sound module, the way of working is exactly as I described and used by many users of my panels.
Example with the Neutron:
– Connect the Neutron to the computer by USB
– Connect your master keyboard / controller to the computer by USB (connecting the master keyboard by USB to the computer gives you the possibility to use it for the Neutron but also for VST plugins or other soft synths)
– Power the Neutron On
– Start the Neutron panel
– In the Midi menu, select Input – Device your_master_keyboard
– In the Midi menu, select Input – Channel 1 (set this to the Midi channel of your Neutron). This is done to receive notes from the master keyboard.
– In the Midi menu, select Output – Device Neutron
– In the Midi menu, select Output – Channel 1 (set this to the Midi channel of your Neutron). This is done to send Global Settings and Notes to the Neutron
– In the Midi menu, select Midi Thru – Input Device -> Output Device. This is done to send the received notes to the synth

Attachments:

You must be logged in to view attached files.

[Author]

Posts