search

scgolang / midi

Golang midi package
13 stars 0 forks source link

Device enumeration #1

Open kisielk opened 7 years ago

kisielk commented 7 years ago

Figured I would discuss this here instead of the portmidi repo :) But one important thing missing from the API right now is a way to enumerate devices. Have you thought about what the API would look like for that?

It would be nice if the enumeration returned a slice of devices that had the Open method directly on them, instead of say an ID that then needs to be passed to an Open function.

briansorahan commented 7 years ago

I've definitely been thinking about this recently but haven't had time to sit down and actually implement something. I hadn't considered what you're suggesting. I thought I would make a new func, maybe Find, that would try to be smarter about the device you want to open. It could get the name of each device in the system and do substring matching to find the device you're looking for ala rakyll's launchpad package. I feel like if Open returned a list of things that exposed a Name then I would prob end up implementing that ^ whenever I consume the midi package. Kind of a minor detail since it's a pretty simple piece of code to write.

I also think that an API for enumerating devices seems very reasonable, but would prefer a different name than Open. Maybe List() ?

Thus far I've just been using amidi -l or this to find the device I want to connect to.

kisielk commented 7 years ago

I was also digging more into this package and it seems like it's kind of limited when it comes to devices with multiple ports, that is, it always opens the first one. That should be more flexible as well. I also think it's a good idea to separate input and output ports in the API. Some devices will have only outputs, or some only inputs, and I think it doesn't really make sense to expose methods that they can't support. It also complicates matters for devices that have a more complicated collection of input and output ports, where they may not be paired in an obvious way.

I don't really think providing substring matching right in the package is necessarily a good idea, because naming of ports can be different depending on the system configuration or vendor implementation of MIDI-USB. I think it's better for users to be able to decide what the best way to choose the device is.

Maybe what you propose is as far as you'd like to go in this package, but I'd really like to develop a canonical MIDI package for Go that can support even the most complex use cases.

briansorahan commented 7 years ago

I agree this package is very limited right now. That is intentional. I made this package to satisfy my current use case, which is communicating with a launchpad from both linux and mac laptops. I'm happy to add support for whatever your use case is, but I prefer to start simple and add features whenever the need for those features presents itself.

If you have a need for more granular control over which ports are used for a given device that also seems like a separate issue, I created this https://github.com/scgolang/midi/issues/2

I think you're right that the device discovery probably doesn't belong in this package. Maybe that's why I've been slow to start coding it!

kisielk commented 7 years ago

I will have a play with the API at home and see what I can come up with. I have a pretty complex setup in my studio with 30+ MIDI endpoints that will make a pretty good test case.

briansorahan commented 7 years ago

I took a look at the portmidi code for populating the device list with Alsa Sequencer. Hopefully sometime in the next week or two I can find the time to take a stab at implementing something similar in this package.

briansorahan commented 7 years ago

@kisielk I've implemented a Devices() func in #3 that mimics what amidi does (on linux). What do you think about the API?