Closed sl1200mk2 closed 2 years ago
Hi Roger, you're right... but English is not my native langage so I would much prefer if you can adapt it... on my computer (Intel/macOS12.4) virtual devices was not working at all. With this PR I can make QLab to talk to my app using virtual device. Moreover, Clang was complaining about integer to pointer conversion...
++
I don't think there's a real bug here, but I see the integer to pointer conversion warning, and the integer should be coerced to make the compiler happy. I can add that.
I think something else is going on with your app and QLab because the PR doesn't seem to change any observable behavior. Can you try tests 19 and 20 (see pm_tests/README.txt)? If these fail, that would be a big surprise. If they pass, then virtual ports work, at least in these tests, which might shed some light on the real problem.
so I ran recvvirtual in a terminal: Midi Input opened. Reading 10 Midi messages...
I ran sendvirtual in another terminal: Midi Output Virtual Device "portmidi" created. Type ENTER to send messages: Note On pitch 60 Note Off pitch 60 Note On pitch 61 Note Off pitch 61 Note On pitch 62 Note Off pitch 62 Note On pitch 63 Note Off pitch 63 Note On pitch 64 Note Off pitch 64 ready to close...done closing. Now delete the virtual device...done deleting. finished sendvirtual test...type ENTER to quit...
nothing have been received in the first terminal
Moreover, when will come time to MIDIDestinationCreateWithProtocol() we'll need to pass pointer and not int. ++
That's correct: recvvirtual creates a virtual "portmidi" device. sendvirtual also tries to create a "portmidi" device. I'd have to read the code to see what happens next, but if the sender and receiver both create ports, they won't be connected.
Test procedures are documented in pm_test/README.txt. The tests I'm interested in are 19 (recvvirtual receives from testio) and 20 (sendvirtual sends to mm). The procedures are documented down to the keystrokes.
If I'm reading it right, MIDIDestinationCreateWithProtocol() doesn't even take a refCon; it takes a client reference, and the client is created with an arbitrary reference. I'm inclined to make a branch for eliminating MIDIDestinationCreate() since I think it will not be eliminated for a long time, and changing the guts of the interface always involves a lot of guesswork about how COREMidi works.
so, out of the box it works... nico@re605x ~ % /Users/nico/Downloads/portmidi-master\ 2/build/Debug/testio Usage: test [-h] [-l latency-in-ms] [-v] -h for this help message (only) -l for latency -v for verbose (enables more output) Apparently this is a 64-bit machine. Latency in ms: 0 begin portMidi test... enter your choice... 1: test input 2: test input (fail w/assert) 3: test input (fail w/NULL assign) 4: test output 5: test both 6: stream test (for WinMM)
and on the recvvirtual terminal: nico@re605x build % /Users/nico/Downloads/portmidi-master\ 2/build/Debug/recvvirtual Midi Input opened. Reading 10 Midi messages... Got message 0: time 135969, c0 0 0 Got message 1: time 139085, 90 3c 64 Got message 2: time 140984, 90 3c 0
let me try to add different CFLAGS at compile time. ++
regarding MIDIDestinationCreateWithProtocol()/MIDIDestinationCreate(), we can ifdef the usage only for macOS11 (when code will be written :))
/ Testing availability of new COREMidi API/
it works... I don't know what was going on with Qlab and my app... so I guess this PR can be closed
++
Thanks for input. It's on my list now to start a development branch to use MIDIDestinationCreateWithProtocol and begin testing before making it the recommended version.
cool, tell me if you need tester ...
++
MIDIDestinationCreate wants a pointer as fourth parameter