Subject: [linux-audio-dev] python audio development details, etc
From: est_AT_hyperreal.org
Date: ti syys 07 1999 - 13:10:55 EDT
Paul Winkler discourseth:
> est_AT_hyperreal.org wrote:
>
> > Re (2): www.hyperreal.org/~est/oolaboola (major new release in two
> > weeks) has a gui written in Python. It communicates with the dsp over
> > a pair of pipes using Scheme symbolic expressions (which are logged
> > with timestamps to a file).
>
> OK, I'm downloading oolaboola now! There are definitely some things I'm
> going to want to see how you handled...
Things are often handled abominably. :) The new release will have a
good amount of internal cleanup, but there's plenty more to come.
> What exactly are Scheme symbolic expressions (aside from having
> something to do with Scheme)? I've heard you guys talking about them and
> always just scratched my head at those messages...
Its a polymorphic datatype consisting of pairs (which are the building
blocks of lists), symbols, strings, numbers, booleans, etc. They have
a well-defined textual representation and procedures to read and write
them are basic to Scheme. What I like about it is that it lets me
forget about the lexical details of textually represented structured
data and just concentrate on the abstract syntax. A simple example
would be:
(note-on 5 60 90)
If you type that into guile preceeded by a single quote, you'll
get..well, the same thing back! It's a list of 4 elements: one symbol
and 3 integers.
As mentioned in other messages, symbolic expressions compare in
interesting ways with XML as a representation strategy.
BTW, I'm working on a real-time implementation of Scheme. It will
allow a lot of the easy extensibility Python provides along with the
speed of more of a `systems language'. Python will still have a place
for me though..it really has its own linguistic niche.
> > oola is written using pygtk. This may have some bearing on using
> > python/tkinter for a similar project. In particular, the following
> > points may be of interest:
> >
> > 1) I think pygtk is faster than Tkinter (because there's no tcl level
> > involved).
>
> This is almost certainly true. However, I'm brand-new to GUI programming
> of any sort, and looking at tutorials for both tk and gtk, I notice gtk
> takes a lot more work to get it to do anything (at least for C; I
> haven't looked at pygtk specifically, maybe I should). I think I can
> live with slow displays as long as the sequencer itself isn't too slow
> to be useful.
Fair enough. :) There's a nice Tkinter intro in the larger Lutz book
also.
> > 3) I'm experiencing (2) even though I've migrated a fair amount of
> > code to Python extensions in C.
>
> I'm curious: what specific speed problems motivated this? How much
> improvement did you get?
Oh, it was fairly random stuff..generally any place where too much
logic was executed too often. Remember that the basic execution speed
of python is about 100x slower than C! I profiled the python script
(Profiling is one of the great things about python. You can invoke
oola with script profiling via the --profile option :) and migrated
what I could that was taking a lot of time to C. I have no idea what
the overall speedup was, but I wouldn't be surprised if it were 2 to
10 times. One thing that still consumes a lot of time is the
play-position slider and read-outs. I think I may create a full-dress
gtk widget for that (I've already done so for the level-hold
meters..making them much prettier :)
> > 4) When the gui is saturated with midi controller events it takes up
> > to 40% of my processor time.
>
> Uh-oh. Do you mean midi continuous controllers?
Yes.
> I had hoped to make things update nicely in realtime, though I was only
> thinking of mouse control, not MIDI.
That might not be too hard..remember those midi cc events can arrive
at a ridiculous rate.
> > Worse, there's no hot-spot..nothing I
> > can migrate to C except the whole midi control architecture (the
> > parsing is already in C) which I wanted to keep in Python for easy
> > programmability. On the plus side, my midi parsing module does
> > event compression if it runs out of cpu.
>
> "event compression"? What's that?
That's where you disregard all but the most recent value of a stream
of cc events. My streaming midi input module does it when the client
hands it a chunk of input containing more than one event for a given
continuous controller. In that case, it calls the callback only for
the last event for each controller. If the client hands it one or two
bytes at a time, there's no compression.
> > I wish it worked for me. It freezes on the very pretty splash screen.
>
> Cecilia, you mean?
Yes, indeed.
> I haven't used it in quite some time.
> I think it requires some specific versions of tcl/tk stuff installed.
> The trouble with freeware closed-source projects is the authors never
> have time to fix stuff like that... haven't seen a cecilia update in a
> *long* time...
Yes..such things are often not worth the time of learning to use!
> > Hmm..what was your k-rate..and your overall system configuration.
>
> Don't remember k-rate.
> I haven't tweaked my system much at all. What specifically?
Oh, what kind of cpu and kernel for example.
> Aha, good point. I haven't looked at csound code lately either. I tried
> once. Brrrr. Too much for my newbie eyes.
The csound code is generally even more abominable than mine..doesn't
keep it from being a great program though. :)
> > I don't think there's a problem here except for the limitations of the
> > kernel you're using. I think us linux-audio people generally want a
> > >=1000HZ kernel anyhow.
>
> Hmmm, maybe I should try that kernel recompile with higher HZ...
It's good for tight timing. At the moment it tends to screw up
various utilities though. top(1) becomes fairly useless for example.
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:11 EST