NullMember / godot-rtmidi

The Unlicense
15 stars 1 forks source link

MidiIn signal midi_message() isn't working #1

Open CsRic opened 4 months ago

CsRic commented 4 months ago

image I connected midi_message() to my callee function _on_midi_message():

extends MidiIn

func _ready():
    var num_ports = MidiIn.get_port_count()
    print(num_ports)
    for i in range(num_ports):
        var port_name = MidiIn.get_port_name(i)
        print(port_name)
    open_port(3)

func _on_midi_message(deltatime, message):
    print(deltatime)
    print(message)

For any port index I chose for open_port(), no midi message would print whenever I hit a midi key. Instead, the Debugger showed an error per hit (note_ons and note_offs):

image

E 0:00:03:0429   emit_signalp: Caller thread can't call this function in this node (/root/Node2D/MidiIn). Use call_deferred() or call_thread_group() instead.
  <C++ Error>    Condition "!is_accessible_from_caller_thread()" is true. Returning: (ERR_INVALID_PARAMETER)
  <C++ Source>   scene/main/node.cpp:3630 @ emit_signalp()

I am using windows 11. The extension is Release Version 0.0.2

CsRic commented 4 months ago

Thank you so much for this extension. I am also trying to build it and see how to fix this problem. Would it be possible to build from the SCons?

NullMember commented 4 months ago

Hi, I'm glad you found a solution that works for you. I'm currently searching the right way of resolving this issue. If I can't find anything better than yours I will merge your PR.

NullMember commented 4 months ago

I've investigated and found that the issue only occurs when the MidiIn node is added directly to the scene tree. Instantiating it from another node avoids the problem. Connecting the signal using deferred doesn't resolve it either. This suggests a potential bug in Godot, possibly related to threading or we need measures to ensure thread safety. I've decided to wait for a few Godot version updates before revisiting this issue.