Added GNU/Linux support to play() function #2

Merged
merged 5 commits into from Mar 18, 2013

Projects

None yet

2 participants

@calebsmith
Contributor

Firstly, thank you for this project and a great talk at Pycon. I've been working on Sator, a project for analyzing atonal music that you might find interesting: http://sator.readthedocs.org/

I'd like to help work on adding support for GNU/Linux for midi output. The approach I've taken here is just to call Timidity directly, because use of subprocess.call(['open', f.name]) fails with "Couldn't get a file descriptor referring to the console" on GNU/Linux.

I think some other approaches are possible, but I'm not sure what would be the most preferable. Also, Timidity seems to be the usual program for MIDI support on GNU/Linux but of course there are likely others. Would it be worthwhile to add an optional kwarg to the function for this argument? (such as passing program_name='timidity')

Let me know any thoughts and I'm happy to amend these changes

@jtauber
Owner
jtauber commented Mar 18, 2013

Yeah, I think passing in program_name would be great (+1 on idea and +0 on that particular param name) as I've hit the case where I want to just play in Quicktime Player but OS X opens up Logic Pro.

We could just use sys.platform for reasonable defaults.

I'm wondering if, for common cases, we should define constants (e.g. TIMIDITY = "timidity") so you'd say

play(tracks, program_name=player.TIMIDITY)

Actually, even just typing that makes me think program_name could just be program.

@jtauber
Owner
jtauber commented Mar 18, 2013

The advantage of program with a constant is there may be things like options triggered by choice of program. In other words, from an API point of view, it's more powerful to think of the parameter as just indicating the program to use rather than the specific shell command.

However this disadvantage is that then new programs would need to be set up in advance whereas what you're proposing is simply a case of "if you have some new program you want to use, just specify the shell command".

I'm open to discussion either way on that issue.

@jtauber
Owner
jtauber commented Mar 18, 2013

Oh, and add yourself to AUTHORS as part of the pull request.

@calebsmith
Contributor

Thanks for the feedback thus far. LMK thoughts on my latest changes. I'm not sure if you wanted to keep 'open' as the OSX default. I'm +1 on using the program kwarg. My earlier suggestion wasn't really named with any care, just wanted to present the idea of passing in a program. I like the idea of using constants for this as well, because it seems more future proof/powerful.

@jtauber
Owner
jtauber commented Mar 18, 2013

my only nit is to use double quotes for consistency

@calebsmith
Contributor

Seems reasonable. I made that change above.

@jtauber jtauber merged commit fbb0236 into jtauber:master Mar 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment