May 19, 2018 at 5:40 am #83996
-- -- Called when a panel receives a midi message (does not need to match any modulator mask) -- @midi CtrlrMidiMessage object -- myMethod = function(--[[ CtrlrMidiMessage --]] midi)
When I plug in “myMethod” as the method “called when a panel receives a MIDI message” – I can use midi:getLuaData() in order to see the MIDI traffic on the MIDI device configured in the panel for MIDI IN and MIDI OUT.
The question is: how do I filter on MIDI direction (the input port vs. the output port)? Currently, “midi:getLuaData()” returns both what is coming from a remote device and also what Ctrlr sends when, in this same function, I use “sendMidiMessageNow”.
The configuration I have set does not echo output to input or input to output and there is no loop elsewhere which would echo back these messages. My assumption is, therefore, that this method captures both input and output. Is there a way to ignore output so the lua script can focus on only incoming data? Some of the output data will be incorrectly parsed (should not be parsed) if there is no filter I can apply in the code.May 19, 2018 at 10:03 am #83998
- Topics: 12
- Replies: 416
- Total: 428
This is not normal behaivor of “called when a panel receives a MIDI message”. As it says it is called when the panel RECEIVES a message. What version of Ctrlr are you using? At the front page of this site you can get the recommended version. Don’t use the bugged latest versions. Another thing: you should use getData() instead of the deprecated getLuaData() but this probably isn’t the big problem here.
May 19, 2018 at 10:59 am #84001
- This reply was modified 1 month ago by Possemo.
Version = 5.4.52, Build date = Thu, Mar 30, 2017 6:26:23 PM, Branch = Stable, Juce = 4.3.1, libusb = 1.0.19, liblo = 0.28, lua = Lua 5.1.4, luabind = 0.9.0, boost = 1.57.0May 19, 2018 at 1:48 pm #84009
May 19, 2018 at 7:39 pm #84015May 19, 2018 at 9:59 pm #84022
- Topics: 12
- Replies: 416
- Total: 428
Forum says duplicate message – but I do not see the other one.
I’ll take a look a look at the recommended build. Thus far, this build has not been extremely buggy. It does crash when I feed it garbage as I learn – always seems to be something I implemented incorrectly.
To answer the “where did you get that”:
Listed first as “Ctrlr-5.5.2.exe 17.6 MiB 2017-May-08 15:45”
I’m referencing this post to determine that “5.5.2” == “5.4.52”:
Looking a little deeper into my setup, I’m wondering if the problem I’m seeing is due to use of “loopMIDI” which is a virtual MIDI driver. I use it in order to present Ctrlr as a specific device as loopMIDI allows hand editing the friendly name. The reason for this is for WebMIDI compatibility with an existing WebMIDI script which expects a certain “name” field to operate. The general concept works – but I’ve seen others need to setup two instances of loopMIDI (two ports) – one for incoming and one for outgoing MIDI traffic. The WebMIDI script doesn’t work if MIDI shows up on two different pipes. It’s expecting an “input” and “output” with the same friendly name.May 22, 2018 at 11:54 pm #84072
Suggested version didn’t help either with general stability or this specific action. I have already isolated the issue down to using loopMIDI for bidirectional use when using the same port name as the IN and OUT port. This works fine with a “true” MIDI device/driver – but not with loopMIDI.
I tested this by using the loopMIDI port in MIDI-OX with the Input and Outputs pointing to the same MIDI device. Should be two different directions although same device. Also, MIDI-OX had the Input->Output forwarding turned off. I would see the same echo of commands sent back to the IN port from the OUT port – even with no device connected to create the loop and no other settings to create the loop.
Unfortunately, there does not appear to be a virtual MIDI cable that supports bidirectional use of a single port name.
This would be required in order to emulate hardware connected to the PC which itself uses a driver and the IN and OUT of hardware using a driver has the same port name for both the IN and OUT — and does not suffer from this kind of artifact (output ending up on the input).
You must be logged in to reply to this topic.