22 Jul
2005
22 Jul
'05
11:22 p.m.
Atte, Iain, Tim, and everyone else who's interested in Python and ALSA:
As promised, I've put together some documentation of my Python bindings
for the ALSA sequencer API. You can find the new version at
http://www.math.tu-berlin.de/~brinkman/software/midikinesis/
The module pyseq.py is the heart and soul of the package. I've added
a simple MIDI file player, midiplayer.py, as a tutorial that shows most
aspects of the bindings in action.
The package also contains a number of other applications built with
the bindings. Most of them are pretty straightforward, except possibly
MidiKinesis, which I presented at LAC 2005, and the new module
leierkasten.py: That one receives control change messages from, say,
a MIDI controller keyboard and converts their rate of change into
MIDI tempo messages. The MIDI file player, midiplayer.py, pays attention
to incoming tempo messages, so that you can plug leierkasten.py into
midiplayer.py in order to create a virtual hand organ.
Any feedback would be appreciated; questions are always welcome.
All the best,
Peter
23 Jul
23 Jul
5:32 a.m.
Peter Brinkmann wrote:
Atte, Iain, Tim, and everyone else who's
interested in Python and ALSA:
As promised, I've put together some documentation of my Python bindings
Thanks, I'll be away for a week. Hope to find time to look at it when I
get back...
--
.''`. Peace, love & harmony
: :' : Atte
`. `'
`- http://www.atte.dk
5:56 a.m.
Atte, Iain,
Tim, and everyone else who's interested in Python and ALSA:
As promised, I've put together some documentation of my Python bindings
Thanks, I'll be away for a week. Hope to find time to look at it when I
get back... 
9:41 a.m.
i recently evaluated your package while searching for a standard looking alsa
midi wrapper, but the package seems to be focused on your application.
any chance you could break off the alsa midi part and make it a separate
package?
On Saturday 23 July 2005 03:22, Peter Brinkmann wrote:
Atte, Iain, Tim, and everyone else who's
interested in Python and ALSA:
As promised, I've put together some documentation of my Python bindings
for the ALSA sequencer API. You can find the new version at
http://www.math.tu-berlin.de/~brinkman/software/midikinesis/
The module pyseq.py is the heart and soul of the package. I've added
a simple MIDI file player, midiplayer.py, as a tutorial that shows most
aspects of the bindings in action.
The package also contains a number of other applications built with
the bindings. Most of them are pretty straightforward, except possibly
MidiKinesis, which I presented at LAC 2005, and the new module
leierkasten.py: That one receives control change messages from, say,
a MIDI controller keyboard and converts their rate of change into
MIDI tempo messages. The MIDI file player, midiplayer.py, pays attention
to incoming tempo messages, so that you can plug leierkasten.py into
midiplayer.py in order to create a virtual hand organ.
Any feedback would be appreciated; questions are always welcome.
All the best,
Peter
--
-- leonard "paniq" ritter
-- http://www.paniq.org
-- http://www.mjoo.org
11:24 a.m.
New subject: [linux-audio-user] Where we are at
At the moment I am writing an article about oss audio. It is intended to
be a kind of snap shot and introduction to the open source audio scene.
Kinda daunting topic! Also its not easy to write it as the mag obviously
do not want to offend many of their advertisers.
So far, I have done a brief intro to Open Source, a focus on Hollywood
using linux, and a bit about live distros, JACK, ALSA and LADSPA. I plan
on focusing on three key apps, touch on hardware compatability, and then
I ramble for a bit about where things might lead in future. Am happy to
email what I have so far to anyone for comments.
I am amazed that at my newsagent there are five mags for OSS and five
mags for music on a computer, and not one that comprises the two. As far
as I am aware this'll be the first major focus on OSS in a music mag so
am shitting myself !! I really dont want to screw this up !!
If anyone is interested in the article please do get in touch, am happy
to mail over a work in progress document for comments and suggestions.
Hope you are all having a good day,
John
11:48 a.m.
New subject: [linux-audio-user] Where we are at
At the moment I am writing an article about oss audio.
It
is intended to be a kind of snap shot and introduction to
the open source audio scene. Kinda daunting topic! Also its
not easy to write it as the mag obviously do not want to
offend many of their advertisers.
feel free to use parts of my document I prepared for a talk at
this years Linuxtag (www.linuxtag.org). You'll find the paper
at sysexxer.sf.net.
Best regards
ce
12:05 p.m.
New subject: [linux-audio-user] Where we are at
Ce, I could kiss you. Thank you very much.
Christoph Eckert wrote:
At the moment I
am writing an article about oss audio. It
is intended to be a kind of snap shot and introduction to
the open source audio scene. Kinda daunting topic! Also its
not easy to write it as the mag obviously do not want to
offend many of their advertisers.
feel free to use parts of my document I prepared for a talk at
this years Linuxtag (www.linuxtag.org). You'll find the paper
at sysexxer.sf.net.
Best regards
ce
12:09 p.m.
New subject: [linux-audio-user] Where we are at
On Sat, 2005-07-23 at 09:24, John Mulholland wrote:
At the moment I am writing an article about oss audio.
It is intended to
be a kind of snap shot and introduction to the open source audio scene.
Kinda daunting topic! Also its not easy to write it as the mag obviously
do not want to offend many of their advertisers.
So far, I have done a brief intro to Open Source, a focus on Hollywood
using linux, and a bit about live distros, JACK, ALSA and LADSPA. I plan
on focusing on three key apps, touch on hardware compatability, and then
I ramble for a bit about where things might lead in future. Am happy to
email what I have so far to anyone for comments.
I'd like to take a look. BTW, can you tell us which magazine?
--
Jan "Evil Twin" Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and this
we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
12:26 p.m.
New subject: [linux-audio-user] Where we are at
ok I have emailed you off list with what I have down so far. Anyone else
interested, the more the merrier. The magazine is called 'Music Tech
Magazine'......here is a url: www.musictechmag.co.uk
Jan Depner wrote:
On Sat, 2005-07-23 at 09:24, John Mulholland wrote:
At the moment I am writing an article about oss
audio. It is intended to
be a kind of snap shot and introduction to the open source audio scene.
Kinda daunting topic! Also its not easy to write it as the mag obviously
do not want to offend many of their advertisers.
So far, I have done a brief intro to Open Source, a focus on Hollywood
using linux, and a bit about live distros, JACK, ALSA and LADSPA. I plan
on focusing on three key apps, touch on hardware compatability, and then
I ramble for a bit about where things might lead in future. Am happy to
email what I have so far to anyone for comments.
I'd like to take a look. BTW, can you tell us which magazine?
11:46 a.m.
i recently evaluated your package while searching for
a standard looking alsa
midi wrapper, but the package seems to be focused on your application.
When exactly
did you look at the package? If it was more than three weeks
ago, then you've seen the original version, which was indeed focused on
MidiKinesis.
I have since studied most of the ALSA sequencer API, and I have added
support for everything I can see myself using, most importantly support
for scheduling events via ALSA queues, as well as a fair number of
convenience methods for quickly generating and evaluating common events.
I'm actually hard at work on a new project that's quite different from
MidiKinesis and extensively uses the new features.
any chance you could break off the alsa midi part and
make it a separate
package?
This is something that's been in the back of my mind, and now that
you're
asking, I'll go ahead and do it. For the time being, however, you can just
download the entire package and ignore everything except pyseq.py and
midiplayer.py.
Peter
1:13 p.m.
On Saturday 23 July 2005 15:46, Peter Brinkmann wrote:
rocking!
--
-- leonard "paniq" ritter
-- http://www.paniq.org
-- http://www.mjoo.org
any chance you
could break off the alsa midi part and make it a separate
package?
This is something that's been in the back of my mind, and now that you're
asking, I'll go ahead and do it. For the time being, however, you can just
download the entire package and ignore everything except pyseq.py and
midiplayer.py.
25 Jul
25 Jul
7:55 p.m.
On Sat, Jul 23, 2005 at 01:49:04PM +0200, Leonard paniq Ritter wrote:
any chance you could break off the alsa midi part and
make it a separate
package?
Done. You can find it at
http://www.math.tu-berlin.de/~brinkman/software/pyseq/
I've taken the opportunity to enhance the bindings ever so slightly and
add a proper installation script, which should make it a little easier to
get started.
Peter
3 Aug
3 Aug
5:09 p.m.
Peter Brinkmann wrote:
On Sat, Jul 23, 2005 at 01:49:04PM +0200, Leonard
paniq Ritter wrote:
Hi Peter
First - thanks: this is just what I needed to get me back to scratching
my itches!
I may be showing my Python naivety here, but I'm struggling to see how
to integrate the MIDI thread with other threads in a safe way. I see
that the low-level bindings incorporate a time-out on the poll(), but
there's no callback that'd allow for polling Python Queues, and you
don't appear to release the GIL during the poll().
Am I going at this from the wrong direction, or would this be a useful
feature?
Thanks
Rob
any chance you could break off the alsa midi part
and make it a separate
package?
Done. You can find it at
http://www.math.tu-berlin.de/~brinkman/software/pyseq/
I've taken the opportunity to enhance the bindings ever so slightly and
add a proper installation script, which should make it a little easier to
get started.
8:24 p.m.
Rob,
On Wed, Aug 03, 2005 at 08:09:18PM +0100, Rob Fell wrote:
I may be showing my Python naivety here, but I'm
struggling to see how
to integrate the MIDI thread with other threads in a safe way. I see
that the low-level bindings incorporate a time-out on the poll(), but
there's no callback that'd allow for polling Python Queues, and you
don't appear to release the GIL during the poll().
I always found it sufficient
to do any thread synchronization on the
Python side, using the synchronization primitives provided by Python's
threading module. Do you have an application in mind that would require
synchronization at a lower level?
Also, what sort of functionality would you like to implement by polling
Python Queues in the MIDI thread?
Best,
Peter
5 Aug
5 Aug
7:08 a.m.
Peter Brinkmann wrote:
I always found it sufficient to do any thread
synchronization on the
Python side, using the synchronization primitives provided by Python's
threading module. Do you have an application in mind that would require
synchronization at a lower level?
I'm considering using conventional thread-programming techniques, but
that always gets a little messy (although I may be in need of further
practice). I'd hoped to make the threads explicitly synchronous via
queues thus forcing all of the locking out of the class objects and into
the queues joining them. Then I'd hoped to wrap the queues to make
debugging the deadlocks a little easier :)
You probably shouldn't consider this a feature request yet.
Also, what sort of functionality would you like to
implement by polling
Python Queues in the MIDI thread?
I planned to consume events from the GUI thread periodically - this
would allow the MIDI thread to operate unhindered by the GUI if there's
a lot of work to do.
Background: I'm creating a guitar rack - my app. would live between a
control surface and JackRack, and be controlled (aka patch selection)
via either footswitch or GUI. I intend to add facilities for grouping
of patches into 'songs', and even arranging songs into 'gigs' for
mouse-free live use. That's why I'm trying to avoid potentially
stalling the MIDI thread....
The problem may be that I don't know the right idioms for doing this in
Python yet, but I haven't found anything worthy of study yet.
Thanks
Rob
8:06 a.m.
On Fri, 5 Aug 2005, Rob Fell wrote:
Background: I'm creating a guitar rack - my app.
would live between a
control surface and JackRack, and be controlled (aka patch selection) via
either footswitch or GUI. I intend to add facilities for grouping of patches
into 'songs', and even arranging songs into 'gigs' for mouse-free live
use.
That's why I'm trying to avoid potentially stalling the MIDI thread....
Just a quick ad, Ecasound provides a Python API for setting up processing
chains, including support for LADSPA and JACK, plus controlling parameters
with MIDI-CCs. Ecamegapedal, which is a jack-rack style app, is built
using this API (although in C++, but still using the same functionality).
You can find some Python examples at:
http://eca.cx/eci
http://eca.cx/ecasound/Documentation/programmers_guide/html_ecidoc/eci_doc.…
http://eca.cx/ecasound
http://eca.cx/ecamegapedal
--
http://www.eca.cx
Audio software for Linux!
9:49 a.m.
Kai Vehmanen wrote:
On Fri, 5 Aug 2005, Rob Fell wrote:
Thanks Kai. I'd already considered the ecasound route (having started
my multitrack linux experience with it) - ultimately it would allow me
to reconfigure the ladspa fx chains in addition to just controlling
parameters. But that's the start of a much longer project...
R
Background: I'm creating a guitar rack - my
app. would live between a
control surface and JackRack, and be controlled (aka patch selection)
via either footswitch or GUI. I intend to add facilities for grouping
of patches into 'songs', and even arranging songs into 'gigs' for
mouse-free live use. That's why I'm trying to avoid potentially
stalling the MIDI thread....
Just a quick ad, Ecasound provides a Python API for setting up
processing chains, including support for LADSPA and JACK, plus
controlling parameters with MIDI-CCs. Ecamegapedal, which is a jack-rack
style app, is built using this API (although in C++, but still using the
same functionality).
You can find some Python examples at:
http://eca.cx/eci
http://eca.cx/ecasound/Documentation/programmers_guide/html_ecidoc/eci_doc.…
http://eca.cx/ecasound
http://eca.cx/ecamegapedal 
11 Aug
11 Aug
6:17 p.m.
On Fri, Aug 05, 2005 at 01:06:20PM +0300, Kai Vehmanen wrote:
On Fri, 5 Aug 2005, Rob Fell wrote:
some of my own humble and naive python eci scripts are available here:
http://zhevny.com/bin/
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
Background: I'm creating a guitar rack - my
app. would live between a
control surface and JackRack, and be controlled (aka patch selection) via
either footswitch or GUI. I intend to add facilities for grouping of
patches into 'songs', and even arranging songs into 'gigs' for mouse-free
live use. That's why I'm trying to avoid potentially stalling the MIDI
thread....
Just a quick ad, Ecasound provides a Python API for setting up
processing
chains, including support for LADSPA and JACK, plus controlling parameters
with MIDI-CCs. Ecamegapedal, which is a jack-rack style app, is built
using this API (although in C++, but still using the same functionality).
You can find some Python examples at:
http://eca.cx/eci
http://eca.cx/ecasound/Documentation/programmers_guide/html_ecidoc/eci_doc.…
http://eca.cx/ecasound
http://eca.cx/ecamegapedal
5 Aug
5 Aug
8:28 a.m.
Peter
Brinkmann wrote:
Also, what sort of functionality would you like to implement by polling
Python Queues in the MIDI thread?
I planned to consume events from the GUI thread periodically - this
would allow the MIDI thread to operate unhindered by the GUI if there's
a lot of work to do. The problem may be that I don't know the right
idioms for doing this in
Python yet, but I haven't found anything worthy of study yet.
Here's how I would solve this problem, using an ALSA idiom of sorts.
ALSA sequencer events are more general than MIDI events, and you can
use them to communicate with your MIDI thread. In particular, when
new data is available in your queue, you can alert the MIDI thread to
the new data by sending it an echo event. The file midiplayer.py in
the PySeq distribution uses echo events in this fashion, so that you
can glean the basic idea from it.
There are a few ways to extend this basic idea. For instance, if you
have several queues, then you can tag your echo events according to
which queue currently has data. You could also add an intermediate
thread that just waits for new data in a queue and fires off an echo
message to the MIDI thread when needed. Like this, your top-level
GUI code wouldn't have to be ALSA-aware.
Would this work for you?
9:45 a.m.
Peter Brinkmann wrote:
> Here's how I would solve this problem, using
an ALSA idiom of sorts.
> ALSA sequencer events are more general than MIDI events, and you can
> use them to communicate with your MIDI thread. In particular, when
> new data is available in your queue, you can alert the MIDI thread to
> the new data by sending it an echo event. The file midiplayer.py in
> the PySeq distribution uses echo events in this fashion, so that you
> can glean the basic idea from it.
I had already considered that as an option - but not
being
knowledgeable about the ALSA seq API, I didn't know of the existence
of message types which could never originate from real equipment (it
would be a pity to hijack an event type which might later prove
useful).
I'll investigate these echo events.
> There are a few ways to extend this basic idea.
For instance, if you
> have several queues, then you can tag your echo events according to
> which queue currently has data. You could also add an intermediate
> thread that just waits for new data in a queue and fires off an echo
> message to the MIDI thread when needed. Like this, your top-level
> GUI code wouldn't have to be ALSA-aware.
>
> Would this work for you?
Almost. I see no need (in my application) to ensure
that the GUI
events are serialised at the correct time in the event stream.
I favour a periodic callback since a timeout on poll() indicates that
there are no events pending - hence it would be a reasonable time to
handle GUI events.
That's essentially what midiplayer.py does. Since most MIDI files
contain a lot more events than can be scheduled at once, midiplayer.py
just schedules a batch of a few hundred events at a time, followed by
an echo event addressed to itself. Then it just sits around waiting
for this echo event to arrive, at which time it schedules the next
batch as well as another echo event, etc.
In your situation, you may just want to set things up in such a way that
the MIDI thread keeps sending itself echo events at regular intervals.
6 Aug
6 Aug
12:12 p.m.
Rob Fell wrote:
Peter Brinkmann wrote:
IIUC in the case of midiplayer.py, all the events are generated by
software: in my case I'm trying to merge a live stream from a physical
device with events generated either by other physical devices or via the
GUI. GUI interaction should stall whilst there are real events to
process - and the easiest way I see to handle this is to use the poll()
timeout.
I can try other means of thread synchronisation, but I fear that will
massively complicate the locking :(
R
> Would this work for you?
Almost. I see no need (in my application) to
ensure that the GUI
events are serialised at the correct time in the event stream.
I favour a periodic callback since a timeout on poll() indicates that
there are no events pending - hence it would be a reasonable time to
handle GUI events.
That's essentially what midiplayer.py does. Since most MIDI files
contain a lot more events than can be scheduled at once, midiplayer.py
just schedules a batch of a few hundred events at a time, followed by
an echo event addressed to itself. Then it just sits around waiting
for this echo event to arrive, at which time it schedules the next
batch as well as another echo event, etc.
In your situation, you may just want to set things up in such a way that
the MIDI thread keeps sending itself echo events at regular intervals.
2:16 p.m.
Rob,
IIUC in the case of midiplayer.py, all the events are
generated by
software: in my case I'm trying to merge a live stream from a physical
device with events generated either by other physical devices or via the
GUI. GUI interaction should stall whilst there are real events to
process - and the easiest way I see to handle this is to use the poll()
timeout.
Let's see whether I got this right: You have two producers of events,
your MIDI hardware and your GUI. You want to have one consumer of events
that favors hardware events and only processes GUI events when no hardware
events are available.
If this interpretation is correct, then my first idea is to set up
your threads to reflect this structure: Take two queues, q1 and q2,
(in the sense of thread-safe FIFO from the Python package Queue, not
ALSA queues). The MIDI thread of pyseq writes to q1 (and doesn't do
anything else), and the GUI thread writes to q2.
Now you take a third thread that consumes events from q1 as long as
q1 isn't empty, and consumes events from q2 only after exhausting q1.
Is this closer to what you have in mind?
You say you want to stall GUI interaction while real events are available,
but I don't see how this would work in practice. Since the computer can
process events at a much higher rate than the MIDI hardware protocol can
deliver them, there should always be time for the GUI to squeeze in an
event or two.
Peter
3:12 p.m.
Peter Brinkmann wrote:
Let's see whether I got this right: You have two
producers of events,
your MIDI hardware and your GUI. You want to have one consumer of events
that favors hardware events and only processes GUI events when no hardware
events are available.
Correct.
If this interpretation is correct, then my first idea
is to set up
your threads to reflect this structure: Take two queues, q1 and q2,
(in the sense of thread-safe FIFO from the Python package Queue, not
ALSA queues). The MIDI thread of pyseq writes to q1 (and doesn't do
anything else), and the GUI thread writes to q2.
Now you take a third thread that consumes events from q1 as long as
q1 isn't empty, and consumes events from q2 only after exhausting q1.
Is this closer to what you have in mind?
Functionally that would produce the desired result.
Perhaps I've misunderstood the ALSA implementation, but a sequencer
client can't rely on the persistence of the event (snd_seq_free is
deprecated) - so it would have to be deep copied for queuing. The
embedded s/w eng. in me shies away from copying data unnecessarily.
You say you want to stall GUI interaction while real
events are available,
but I don't see how this would work in practice. Since the computer can
process events at a much higher rate than the MIDI hardware protocol can
deliver them, there should always be time for the GUI to squeeze in an
event or two.
Enumerating large dictionaries containing patch data and song groups for
the GUI seems to be the most troublesome case, but probably as a
side-effect of my data structure design.
I think my app. needs a redesign.
cheers
Rob
9 Aug
9 Aug
1:51 p.m.
Rob,
Functionally that would produce the desired result.
Perhaps I've misunderstood the ALSA implementation, but a sequencer
client can't rely on the persistence of the event (snd_seq_free is
deprecated) - so it would have to be deep copied for queuing. The
embedded s/w eng. in me shies away from copying data unnecessarily.
Let's call
it defensive copying;) This wouldn't be an expensive operation.
The event data structure is rather large, but for each event, only a small
part of it really matters. If you just copy the pertinent entries, then
you only have to copy a few bytes per event.
Peter
23 Jul
23 Jul
10:03 a.m.
Last Saturday 23 July 2005 02:22, Peter Brinkmann was like:
As promised, I've put together some documentation
of my Python bindings
for the ALSA sequencer API. You can find the new version at
http://www.math.tu-berlin.de/~brinkman/software/midikinesis/
Thanks. I'm looking forward to learning how to make use of these bindings.
Happy to give feedback once I've digested. Great work!
cheers,
tim hall
http://glastonburymusic.org.uk
6832
days inactive
6852
days old
linux-audio-user@lists.linuxaudio.org
25 comments
12 participants
participants (12)
-
Atte André Jensen -
Christoph Eckert -
Eric Dantan Rzewnicki -
Iain Duncan -
Jan Depner -
John Mulholland -
Kai Vehmanen -
Leonard "paniq" Ritter -
Peter Brinkmann -
Rob Fell -
Rob Fell -
tim hall