Subject: Re: [linux-audio-dev] Musical language / OO design questions...
From: David Olofson (audiality_AT_swipnet.se)
Date: ti tammi 25 2000 - 22:33:25 EST
On Mon, 24 Jan 2000, Paul Winkler wrote:
> David Olofson wrote:
> > Anyway, what's *really* annoying with CW is just that it ignore edits
> > after the start time of an event has been passed. When tweaking
> > string harmonies with some notes that are several bars long, that
> > becomes quite frustrating. As it can't play notes that should be
> > playing, but whose start times are before where you are when you
> > press start, you simply have to rewind and wait for several seconds
> > to hear the full result.
>
> That seems lazy. I've been thinking that eventually pysco should,
> whether outputting realtime or rendering to a file, look at all
> notes which start *or end* after the desired start time. Anything
> which starts before your selection but ends during or after it will
> be treated as if it actually started at the selection start. This
> has its own weird consequence -- you get a bunch of spurious attacks
> when you start playback -- but I think that's preferable to silence.
> Usually. It would be good if you could turn it off. :)
Well, if you want to hear the exact final version, you either have to
use a far more powerful protocol than MIDI to tell the synths that
you're starting in the middle of notes, or you simply have to rewind
a bit. :-) Nothing new, really, even analog tape has a similar
problem: non-zero acceleration time...
And a HDR has on even worse problem in that it needs to buffer up
before it can start playback. With a slow HD under heavy load, that
means seconds of delay...
> > > 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.
> >
> > Not too hard in theory, but hacking it into something not planned
> > that way could end up as a speghetti nightmare I guess...
>
> Well, pysco is pretty small, and my OO re-design will basically
> starting from scratch since a lot of the old code is useless in the
> new nested event paradigm.
>
> > Perhaps
> > having very similar APIs for the event database and the sequencer
> > engine could help? Or, going the OOP way, where events are objects
> > with methods used to gather data during playback; make sure the
> > datbase->sequencer interface is connected to the edit methods.
>
> That's the idea, I think.
> Basically the sequencer would be designed in such a way that editing
> any event causes an immediate update of any relevant previously
> scheduled events.
Yes, kind of like directly touching the database, from which the
playback thread grabs it's data in real time. That's how it worked
back in the good ol' tracker days. :-)
//David
.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST