Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csoundas a sampling engine
From: Paul Winkler (slinkp_AT_ulster.net)
Date: ti syys 07 1999 - 04:13:23 EDT
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...
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...
> 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.
> 2) Even so, I perceive a subliminal mushiness to a pygtk gui, really only
> noticable by the comparative feeling of `solidity' of a C/gtk app.
>
> 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?
> 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?
I had hoped to make things update nicely in realtime, though I was only
thinking of mouse control, not MIDI.
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?
> I wish it worked for me. It freezes on the very pretty splash screen.
Cecilia, you mean? 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...
> > of timing. Try it with both stdin and FIFOs -- does that make a
> > difference?
>
> It shouldn't..stdin *would* be an (unnamed) fifo if you're piping to
> it.
Thanks for the info.
> > Previous experiments with csound events from stdin are not especially
> > encouraging: more than about 10 simultaneous events were audibly not
> > simultaneous.
>
> 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?
> Something that could produce this problem would be quite useful.
OK, now I've been trying your csoundL stuff and still finding problems
between 10 and 15 simultaneous events. Not blurring of attack time, but
weird glitches in the timing of each whole bunch of events... See my
other message about that...
> > line. If I want to send 50 simultaneous events, maybe they should fill
> > the buffer and _then_ flush it before going to the next event? If so, my
> > engine would need to efficiently know when it's done with "current"
> > events.
>
> This shouldn't make too much difference. I haven't checked the csound
> code, but I'll bet it checks the -L input on every k-cycle and
> processes anything it finds there. It may need to be tweaked in some
> ways..we'll see! Also, if you really want to gather up your events
> before sending them, the wait-to-flush approach will be unreliable
> since stdio may autoflush anyhow.
Aha, good point. I haven't looked at csound code lately either. I tried
once. Brrrr. Too much for my newbie eyes.
> 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...
> > --Held notes: I want a way to optionally say "Do this until I
> > tell you to
> > stop" -- that is, follow the "noteoff" paradigm rather than the
> > "dur" paradigm. Sometimes this just makes more sense.
>
> I don't know enough about csound yet. Is there a way for an
> instrument to explicitly say "I'm done, deallocate me now!". If so
> then this could be handled via table entries.
Well, I see you've already figured out one solution.
> Thanks for posting these thoughts! :)
>
> Eric
------------------ paul winkler ------------------ slinkP arts: music, sound, illustration, design, etc.
zarmzarm_AT_hotmail.com --or-- slinkp AT ulster DOT net http://www.ulster.net/~abigoo/ ======================================================
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:11 EST