How to determine MIDI message direction?

Home Forums General Programming How to determine MIDI message direction?

This topic contains 6 replies, has 2 voices, and was last updated by  jyamaha 4 months, 3 weeks ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #83996

    jyamaha
    Participant
    • Topics: 1
    • Replies: 4
    • Total: 5
    --
    -- 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.

    #83998
    Possemo
    Possemo
    Participant
    • Topics: 13
    • Replies: 473
    • Total: 486
    • ★★

    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.

    • This reply was modified 4 months, 4 weeks ago by Possemo Possemo.
    #84001

    jyamaha
    Participant
    • Topics: 1
    • Replies: 4
    • Total: 5

    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.0

    #84009
    Possemo
    Possemo
    Participant
    • Topics: 13
    • Replies: 473
    • Total: 486
    • ★★

    I never heard of this version. Where did you get that? The build above 5.4.29 is completely bugged. As said – get the recommended build:

    http://ctrlr.org/nightly/Ctrlr-5.3.201.exe

    • This reply was modified 4 months, 4 weeks ago by Possemo Possemo.
    #84015

    jyamaha
    Participant
    • Topics: 1
    • Replies: 4
    • Total: 5

    … deleted duplicate msg.

    • This reply was modified 4 months, 4 weeks ago by  jyamaha.
    • This reply was modified 4 months, 4 weeks ago by  jyamaha.
    • This reply was modified 4 months, 4 weeks ago by  jyamaha.
    • This reply was modified 4 months, 4 weeks ago by  jyamaha. Reason: Update formatting
    • This reply was modified 4 months, 3 weeks ago by  jyamaha.
    #84022

    jyamaha
    Participant
    • Topics: 1
    • Replies: 4
    • Total: 5

    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”:

    http://ctrlr.org/nightly/?C=M;O=D

    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”:

    Forum topic: recommended-ctrlr-version

    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.

    #84072

    jyamaha
    Participant
    • Topics: 1
    • Replies: 4
    • Total: 5

    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).

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

There is currently 0 users and 24 guests online
No users are currently active
Forum Statistics
Threads: 2,157, Posts: 15,206, Members: 16,075
Most users ever online was 9 on October 14, 2018 10:42 am
Do NOT follow this link or you will be banned from the site!