By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,873 Members | 1,040 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,873 IT Pros & Developers. It's quick & easy.

Python suitable for Midi ?

P: n/a
Hello all

Is Python suitable for building a multi-track midi sequencer (with a
gui), that would run on windows / mac ? I fail to find sufficient
information on this, being a newbie and all. Furthermore, i found
references on Python not being really able of multi-threading, that
further adds to the confusion.

Please assist.

Panos

Oct 28 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Protocol wrote:
Is Python suitable for building a multi-track midi sequencer (with a
gui), that would run on windows / mac ? I fail to find sufficient
information on this, being a newbie and all.
We had a Google Summer of Code student working on this sort of thing this
year (This clearly puts a bounds on experience btw). He got a fair way along
with this, but didn't get his code to a mergeable state (mainly in the
application files rather than in the components which are largely
mergeable).

Essentially it generated a bunch of components which he was using in his
application, which are naturally reusable.

I've pinged him since the end of GSOC, and had a response that essentially
says "sorry, too busy, maybe next semester". We'll see on that (he was
having fun, so I suspect he really does want to come back to it, but hasn't
had time). In the meantime, the answer is, yes, you can do this in Python.
His code is here, if it's useful to you:

* http://code.google.com/p/kamaelia/so...nk/Sketches/JT
* ( svn co http://kamaelia.googlecode.com/svn/trunk/Sketches/JT )
- requires Kamaelia 0.6.0 btw

Top level file/application file is this:

http://kamaelia.googlecode.com/svn/t...tion/trunk/jam

(The reason I don't feel it's mergeable as is, is because it could with a
code clean up IMO, but it's pretty good - to say the least - considering
the GSOC timeframe - also it shows it is doable, and if you're reusing his
components, then it should be very doable)

It is likely though that his component library:
http://kamaelia.googlecode.com/svn/t.../Jam/Protocol/

will get merged before christmas though, since that code is a lot cleaner.

In case you're wondering, he was aiming to build something a bit like this,
but using Pygame as the interface, and it allows multiple users to run
their local version, connect to each other and do shared "jamming" - hence
the interesting subdirectory is "Jam"

As well as Midi it also supports OSC.

Underneath it all, he was using the python "rtmidi" bindings, and pyosc
bindings to talk Midi and Osc. (Most of his quagmire in the last bit of
GSOC was caused by audio under linux, which doesn't sound relevant to you)
Furthermore, i found references on Python not being really able of
multi-threading, that further adds to the confusion.
Kamaelia's component model effectively gives you concurrency for free,
since you build systems out of components that talk to each other. I
haven't attached the introspector to Jam, but I suspect it's embarrassingly
parallel. He didn't have to worry about that though :-)

If you're curious about the model, this tutorial is specifically targetted
at new developers:
http://www.kamaelia.org/MiniAxon/

It was originally written for someone (specific) who had learnt python the
previous week, had little programming experience, and we needed to get them
up to speed quickly and gently. It's been slightly generalised since, but
is a nice introduction to the ideas. (Under the hood Kamaelia is
significantly more optimised than that example, but the components you
create for that tutorial system work with the full/real world system)

Regards,
Michael
--
http://www.kamaelia.org/Home

Oct 28 '08 #2

P: n/a
I'm writing a sequencer in Python, although it's microtonal and not
MIDI. I'm using the Python bindings for the Csound API, all the
timing, MIDI, OSC, etc. stuff, essentially all but the GUI
capabilities, having been done by the Csound developers already.
Documentation is here and there, and Csound is another language to
learn, but it's one way to go about it.
I'm about to try to recode my app to calculate tempo and note timing
internally and send real-time notes to Csound, instead of having
Csound do it all.
The problem I've run into is that I can't set the audio to a higher
priority than the GUI (Tkinter). If I move the mouse over the app, no
matter what, I get audio dropouts. AFAICT this is the same for all
Python, regardless of what modules one uses: you can't assign system
priorities to different threads. If you're planning to pipe MIDI to
another app for playback, maybe it won't be an issue for you.
Good luck!

-Chuckk

On Tue, Oct 28, 2008 at 11:26 AM, Protocol <ey*********@gmail.comwrote:
Hello all

Is Python suitable for building a multi-track midi sequencer (with a
gui), that would run on windows / mac ? I fail to find sufficient
information on this, being a newbie and all. Furthermore, i found
references on Python not being really able of multi-threading, that
further adds to the confusion.

Please assist.

Panos

--
http://mail.python.org/mailman/listinfo/python-list


--
http://www.badmuthahubbard.com
Oct 28 '08 #3

P: n/a
On Tue, Oct 28, 2008 at 06:54:57PM +0200, Chuckk Hubbard wrote:
The problem I've run into is that I can't set the audio to a higher
priority than the GUI (Tkinter). If I move the mouse over the app, no
matter what, I get audio dropouts. AFAICT this is the same for all
Python, regardless of what modules one uses: you can't assign system
priorities to different threads. If you're planning to pipe MIDI to
another app for playback, maybe it won't be an issue for you.
FWIW... You could take your own advice, and devide your application
in two: one process manages the GUI, and the second is a back-end
process that plays the MIDI. Your GUI can even launch the back end,
which will inherit the priority of the GUI, after which the GUI can
reduce its own priority (the priority of the back end will not be
affected by the change)...
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFJB0gudjdlQoHP510RAvKGAJ4lWErDALJSACes5O4OqA SoSlYuFgCgvTNx
Li051e8NyguC8YpbDHvqhBA=
=nKYZ
-----END PGP SIGNATURE-----

Oct 28 '08 #4

P: n/a
Derek Martin <co**@pizzashack.orgwrites:
On Tue, Oct 28, 2008 at 06:54:57PM +0200, Chuckk Hubbard wrote:
>The problem I've run into is that I can't set the audio to a higher
priority than the GUI (Tkinter). If I move the mouse over the app, no
matter what, I get audio dropouts. AFAICT this is the same for all
Python, regardless of what modules one uses: you can't assign system
priorities to different threads. If you're planning to pipe MIDI to
another app for playback, maybe it won't be an issue for you.

FWIW... You could take your own advice, and devide your application
in two: one process manages the GUI, and the second is a back-end
process that plays the MIDI. Your GUI can even launch the back end,
which will inherit the priority of the GUI, after which the GUI can
reduce its own priority (the priority of the back end will not be
affected by the change)...
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
One also has access to nice-levels on unix systems.
Oct 29 '08 #5

P: n/a
On Wed, Oct 29, 2008 at 10:32 PM, J Kenneth King <ja***@agentultra.comwrote:
>
One also has access to nice-levels on unix systems.
True enough, but it's not so much a problem for me, as I'm pretty okay
at tuning my own system, but I believe most of the people who'd be
interested in my app (if any) are not *nix users. At any rate, it's
one option for those who are, and thanks for reminding me.

-Chuckk

--
http://www.badmuthahubbard.com
Oct 30 '08 #6

P: n/a
En Thu, 30 Oct 2008 16:50:22 -0200, Chuckk Hubbard
<ba*************@gmail.comescribió:
On Wed, Oct 29, 2008 at 10:32 PM, J Kenneth King <ja***@agentultra.com>
wrote:
>>
One also has access to nice-levels on unix systems.

True enough, but it's not so much a problem for me, as I'm pretty okay
at tuning my own system, but I believe most of the people who'd be
interested in my app (if any) are not *nix users. At any rate, it's
one option for those who are, and thanks for reminding me.
On Windows you can set the application global priority (SetPriorityClass)
and each thread's priority related to other threads (SetThreadPriority) -
either using pywin32 or the ctypes module.

--
Gabriel Genellina

Oct 30 '08 #7

P: n/a
On Tue, Oct 28, 2008 at 7:13 PM, Derek Martin <co**@pizzashack.orgwrote:
On Tue, Oct 28, 2008 at 06:54:57PM +0200, Chuckk Hubbard wrote:
>The problem I've run into is that I can't set the audio to a higher
priority than the GUI (Tkinter). If I move the mouse over the app, no
matter what, I get audio dropouts. AFAICT this is the same for all
Python, regardless of what modules one uses: you can't assign system
priorities to different threads. If you're planning to pipe MIDI to
another app for playback, maybe it won't be an issue for you.

FWIW... You could take your own advice, and devide your application
in two: one process manages the GUI, and the second is a back-end
process that plays the MIDI. Your GUI can even launch the back end,
which will inherit the priority of the GUI, after which the GUI can
reduce its own priority (the priority of the back end will not be
affected by the change)...
Thanks, Derek! It took me some looking and experimenting, but this is
a great idea. I see now that os.nice() works for Mac too, and Gabriel
has some suggestions for Windows. So simple- I was thinking I needed
superuser access to set priority to real-time, but I don't need it to
raise the priority of a running process. I never would have thought
of that on my own.

-Chuckk
--
http://www.badmuthahubbard.com
Oct 31 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.