Re: [linux-audio-dev] Re: Timed Event Editor Framework

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
From: Eli Brandt (eli_AT_v.gp.cs.cmu.edu)
Date: ma elo    30 1999 - 18:21:29 EDT


David Slomin wrote:
> > > I take issue with this. In CSound you specify all parameters for a note a
> > > the time that it is fired. In MIDI, you add or modify parameters over
> > > time after the note has been fired.
> >
> > That's a conceptual bug in Csound that IMO should be patched over --
>
> Actually, I see advantages in both methods. The MIDI way is certainly
> more appropriate for realtime, but Csound's approach makes many things in
> synthesis much easier (or even possible). For instance, try designing a
> MIDI-controlled sound that crescendos linearly from zero volume at note-on
> to maximum volume at note-off.

Orthogonal issues, I think:
1) is note length known at the time of note-on?
2) can notes be modulated while they are playing?

Even in Csound you _can_ do (2); you just have to bypass the pfield
mechanism.

> > Seems to me it's easier to ignore
> > structure than it is to add it in after the fact. Say something like
> >
> > function delay_each_track(merged_tracks) =
> > for each_track in merged_tracks,
> > for each event e in each_track,
> > old_e.time = e.time; output old_e
> > old_e = e
> >
> > vs.
> >
> > function delay_each_track(merged_tracks) =
> > for each event e in merged_tracks,
> > old_e[e.track].time = e.time; output old_e[e.track]
> > old_e[e.track] = e
> >
> > Okay, the difference is not dramatic here, but as I start wanting more
> > and more temporal structure, it can either go in the data typing, or
> > I the programmer have to write code that parallels and maintains it by
> > hand.
>
> I understand what you're saying, but I can't think of an example where the
> difference _would_ be dramatic.

How about escalating the structure's tree-depth? The first version
gets more for-each levels but the inner loop stays clean:

        for each_group in merged_groups
                for each_track in each_group
                        old_e.time = e.time; output old_e
                        old_e = e

 vs.

        for each event e in flattened_all_groups_in_tracks
                this_old_e = (old_e[e.track])[e.group]
                this_old_e.time = e.time; output this_old_e
                (old_e[e.track])[e.group] = e

And with a more-involved structure the second loop involves things like
(((old_e[e.level1index])[e.level2index])[e.level3index])[e.level4index]
(and that isn't a one-piece multidimensional array).

Other sorts of scenarios: apply a function to some part of a musical
structure -- call it on that part of the data structure, or grovel
through all the data elements determining whether they're in the part?
(Is speed a concern?) Rearrange a musical structure -- twiddle
pointers at the top level, or grovel again munging all the data
elements' tags?

If you've got structure in the language you can always forgo it and
work with tagged flattened data. Just seems to me you'll only want to
do that at the very end, for shipping to the output device.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST