Subject: Re: [linux-audio-dev] Musical language / OO design questions...
From: Paul Winkler (slinkp23_AT_yahoo.com)
Date: su tammi 23 2000 - 18:02:49 EST
Eli Brandt wrote:
>
> An old one -- I'm skimming backwards through my mail.
I'm still in thinking / testing / designing stage with this, so
comments are still welcome!
> Cribbing lazily from my working model of temporal structure... you
> have events bundling finitely many events; you might also think about
> infinitely many.
As in, "This event doesn't have any known ending time?"
Such as an event that keeps reading an input source or
algorithmically generating output, until it's somehow signalled to
stop?
Hmmm, interesting idea. I confess I hadn't thought of that.
> What's at the topmost level, for example? We can wrap the whole score
> in an event with start-time zero -- if it's finite. But maybe you
> want to being able to say
> input := score_from_MIDI_port(0)
> output := foo(input)
> MIDI_port_from_score(1) := output
>
> If not, fine, finite scores are a very useful domain and it simplifies
> your life. If so, then you might special-case the top level to allow
> an infinite stream.
OK, I think I see the problem. I was thinking that, for realtime
interaction, once we reach the "at" time for an event, subsequent
changes or additions to that event will not be heard, unless the
same event is called again later. So let's assume I'm using some
sort of threaded event-scheduling system which I haven't really
figured out yet. I think I could do something like:
while(1): annoying_loop.output()
Now suppose in another thread I'm running a GUI that edits the
annoying_loop event. The way I've been thinking of it, edits made to
the top level of an event during a pass through that event would not
be heard until the next time we got to the beginning of the
annoying_loop. I was thinking that was just an annoying limitation,
but I've just realized it's actually critical, because if I wrap a
whole piece in one big event, that would make it impossible to hear
ANY edits of the large structures of the piece.
But what if I follow David Slomin's suggestion to my question about
event scheduling? Where every possible way of changing the data in
an event caused an instantaneous and correct update to the data
being queued for output(). I wonder how hard that would be.
If I could figure that out, I think it would allow for infinite
streams, since you could simply keep appending new sub-events onto
the current event, and the event wouldn't terminate unless it ran
out of sub-events. Or actually, I have a better idea... see below...
> Don't do that, I say. If it can possibly fit into your execution
> model
My execution model is still largely hypothetical. I'm open to
suggestions for how to _make_ this fit into my execution model!
>... allow streams at arbitrary places in the structure. This lets
> you, for example, bundle a few of them together to get a multi-channel
> stream. Or generate some streams and then place them using event
> times. Programming imperatively, I can't imagine using infinite
> streams of infinite streams, so you might punt on that.
Ak, brain fried.
Originally I was thinking that there would be two basic sub-classes
of events: those with known duration (csound-style) and those with
unknown (potentially infinite) duration. But maybe that shouldn't
be done with sub-classes. Maybe there should be an optional
attribute, let's call it off_time. If it exists, the event is
scheduled to end at that time. If not the event is assumed to still
be active (that is, any sub-events appended to it that are at or
later than "now" will appear in the output) until... um... until we
turn it off by setting the off_time attribute for "now". How's that
sound?
Anyway, I can't test this yet, as I apparently need to upgrade my
kernel and my glibc before I can re-compile python with thread
support, which would be needed to do any of this stuff, I believe.
................ paul winkler ..................
slinkP arts: music, sound, illustration, design, etc.
A member of ARMS -----> http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.net/arms
personal page ----> http://www.ulster.net/~abigoo
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST