Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Wed Dec 18 2002 - 18:13:11 EET
On Wednesday 18 December 2002 16.06, Tim Goetze wrote:
[...]
> >If it's not fixed, it's another parameter you have to get from the
> >timeline, before you can do anything useful with a musical time
> >value. That's all, basically.
>
> for the timeline, not from.
>
> it is constant throughout in a sane system.
Yes, of course. I didn't mean so suggest that it can change while
playing or anything.
> >> >> please, please, please, ask your favourite musician friends.
> >> >> read good books about it. listen to indian, jazz, techno,
> >> >> blues, classical western, classical indian, japanese, rap,
> >> >> whatever music: rhythmn is integral.
> >> >
> >> >Well, which ones qualify?
> >>
> >> all of them.
> >
> >Well, you've already disqualified at least one on this list, I
> > think. (And I don't count myself, of course.)
>
> which?
Well, that would be David Gerard Matthews, IIRC.
> i'll remind you that 9.5 = 19 / 2 -- that doesn't prove
> me wrong.
Well, that doesn't make x == x / 2. (Unless x == 0, but that's
irrelevant, of course.)
> >> rhythmn is always based on one integral periodic 'pulse'. if
> >> time is not divisible by this atom, there is no musical time.
> >>
> >>From a theoretical POV, I would agree, but that doesn't seem to
> >> be
> >
> >the best way to think of it at all times.
>
> it is not theoretical. it is the practical foundation of
> musical time.
You keep saying that. It may be practical most of the time, but what
makes it the only correct representation?
> >> >If you really *want* a bar that's shortened by a fractional
> >> > beat (which is not all that unusual, even in pop music), what
> >> > do you do...? How do you ensure that plugins that beat sync
> >> > don't freak out when you multiply the meter to get integers?
> >>
> >> if you shorten, for example, 4/4 by 1/16, it's 15/16.
> >
> >Yeah - but then your beat sync'ed effect suddently switches from
> > 4ths to 16ths...
>
> why should it? it knows what time unit it is synced to, doesn't
> it? at least that usually is one of its prime parameters.
Yes, but if you specify it as "1 beat", it will look at the meter,
and then *boom* - incorrect results...!
> >> if you want to shorten 4/4 by, say, 1/16 + 0.00212266328763,
> >> you're violating the very principle of the organization of
> >> musical time.
> >
> >Well, I can't say for sure. All I know is that I do that kind of
> >things by "abusing" the tempo map instead, since that's the only
> > way you can do it in most sequencers.
>
> this method works better:
> >> you're better off simply inserting a new meter
> >> where the shortened measure ends.
> >
> >How would you do that? The meter just defines the subdivision of
> >musical time. You can't just make a "skip" in musical time -
> > unless you're seriously suggesting that this should be
> > implemented as a transport "jump" to skip the last part of the
> > shortened measure.
>
> not at all. but you don't have to complete the current
> measure to put in a new meter, do you? it's just a way
> to count the passage of time, it's not time itself.
So, meters are basically timstamped, short fragments of defined time
placed arbitrarily along the timeline? Sounds a *lot* messier than
just assuming that the next one starts where the current one ends,
and allowing any lengths.
> >> and what seems to be the problem with beat sync? the relation
> >> of the meter to TIMEBASE is part of the tempo information, so
> >> all info you need, you have.
> >
> >No. Where did the *real* beat value go?
>
> there is no *real* beat value. if your arpeggiator starts
> emitting 8th notes when switching to 4/4 from 7/8, i'd say
> there's something wrong with it.
Not if you *specifically* tell it to interpret the parameter as
related to the beat value, rather than a specific note value.
Obviously, that's a feature you *could* live without, but it still
serves to demonstrate that the whole meter has a *musical meaning* -
it's not just a messy way of defining the length of one bar.
> anytime you introduce a
> new meter, you introduce a new "one" beat. your plugin
> absolutely needs to sync to that, right?
Yes - just like it locks to musical time, whatever the meter may be.
The point is just that the plugin should be able to *understand* the
meter as it was indended by the composer - or, plugins should not
have access to the full meter information in the first place, since
it becomes essentially musically irrelevant.
> and there's no *real* beat value because in the case you
> mention, you explicitly destroy musical time periodicity.
Ever heard a "break" (as they call it in pop music) in a shortened
bar?
The "breaking" of the periodicity is sometimes *intentional*, and
often so subtle that you can't reasonably "count" to deal with it.
63/64ths...?
You've probably also failed to notice a rather popular "trick" used
back in the disco era was to lag behind over the measure, for that
"push" feel of the one beat. (Yeah, it has a name too, but I can't
seem to remember it, being totally illiterate when it comes to music,
and all...)
Well, maybe tempo modulation would be more correct - I can't say for
sure. This belongs in that gray zone "slip" between traditional
notation and actual music, that sequencer folks seem to assume you
should simply ignore, unless you're dealing with "real" instruments
and real musicians.
> >> please excuse the harsh word: your assumptions about these
> >> fields lack in realism.
> >
> >*heh* Well, you seem to have all the right answers - so why do you
> >tend to ignore the questions that cannot simply be disregarded as
> > "in conflict with traditional theory"...?
>
> please put them here; i honestly don't know which questions
> you are referring to.
Well, sorry if I just missed it, but I'm still waiting for an
explanation as to why non-integer meters automatically result in
sequencer/plugin sync issues.
In general, it seems that we're not getting anywhere here, since, for
some reason, at some point, you end up countering with more or less
irrelevant arguments, instead of explaining the real issues.
You have repeatedly attacked my lack of experience, lack of musical
training and whatnot, instead of my technical arguments. As a result,
my impression is that you're sometimes more interested in defending
your traditional theory based standpoint, than in discussing
technical matters of the XAP API.
I'm here to participate in the creation of a plugin API. I'm much
more interested in serious arguments than in being personally
attacked for having the wrong view, or whatever this is about.
> i would love to have more musicians actively participate in
> this list but there seem to be few.
>
> >I think fp arithmetics have more effect or accuracy than
> > traditional ways of thinking about meters - but I must be wrong,
> > then.
>
> they are simply not adequate in this context.
Why? Counting in ticks, you can handle these subdivisions without
rounding errors. Then it doesn't really matter if they represent
integer *beats* and *note values*, since they're still integer
numbers.
So, to eliminate the only non-political difference between the two:
beats/measure: 1920/beat
beat value: 1920ths
That is, fixed point. (Bigger and "better" values could be used.)
This prevents you from accidentaly generating a meter that contains
rounding errors.
Please, counter this with *technical* arguments, or don't bother.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Wed Dec 18 2002 - 18:17:33 EET