Open briansorahan opened 7 years ago
Can you try running the code with theGODEBUG=cgocheck=2
environment variable set?
@kisielk Tried that and got the same error.
Okay, but you didn't get any messages from the Go runtime? Also, which version of Go are you using?
go version go1.7.4 linux/amd64
Didn't notice any extra messages from the Go runtime.
Also here is pacman -Qi portmidi
Name : portmidi
Version : 217-5
Description : Platform independent library for real-time MIDI input/output
Architecture : x86_64
URL : http://portmedia.sourceforge.net/
Licenses : GPL
Groups : None
Provides : None
Depends On : alsa-lib
Optional Deps : java-runtime: for using pmdefaults
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 154.00 KiB
Packager : Eric Belanger <eric@archlinux.org>
Build Date : Sat 26 Oct 2013 12:14:09 PM CDT
Install Date : Sat 14 Jan 2017 04:26:42 PM CST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
Reviewing the cgo docs it says that the GODEBUG checks are sidestepped by code that uses package unsafe, and the code that is crashing in this case does use unsafe. I wonder if it's possible to not use unsafe?
Looks like we have to use unsafe.Pointer since PortMidiStream is void
FWIW I started playing with an alternative midi implementation https://github.com/scgolang/midi seems pretty stable on linux so far, haven't used it on mac much yet
@briansorahan cool, I will check it out. One thing I'm struggling with in PortMIDI is to have an efficient way to have channels for incoming MIDI events implemented in an efficient way, preferably without polling. Seems like using ALSA might solve that.
@kisielk Writing that package has been interesting so far. The linux part took me maybe two hours and resulted in a beautiful tiny interface which basically just had Open, Read, Write, and Close. Read would block until I sent data from the device, which seemed just perfect to me since consumers of the package can easily type go
to make it nonblocking.
Wrapping coremidi caused me to rewrite the linux code though because in order to get data from the device you register a callback.
So now I return a channel for reading in both the linux and darwin code.
i see this fairly regularly on linux (via the launchpad package) but haven't yet figured out how to reproduce