Re: [linux-audio-dev] XAP status : incomplete draft

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

Subject: Re: [linux-audio-dev] XAP status : incomplete draft
From: David Olofson (david_AT_olofson.net)
Date: Sat Dec 14 2002 - 00:47:13 EET


On Friday 13 December 2002 20.41, Nathaniel Virgo wrote:
> On Friday 13 December 2002 7:05 pm, David Olofson wrote:
> > On Friday 13 December 2002 19.01, Steve Harris wrote:
> > > But it duplicates pitch. If you dont allow note_pitch then you
> > > dont miss out on anything, all the plugins that would be
> > > possible still are, it just makes a small number of specialised
> > > actions *slightly* harder.
> >
> > Well, if it's ok to just *guess* which plugins expect you to
> > interpret their pitch inputs and/or outputs as (1/12)/note rather
> > than 1.0/octave, then fine - that factor 12.0 is all the
> > complexity there is to it.
>
> ...but what's been said recently about note_pitch and scales means
> that you have to just "guess" what scale you're in anyway.

Yeah, but at least you won't be guessing what plugin goes where to
make things work *at all*... Considering how hard it is for *us* to
straighten this out, how would your average user have the slightest
chance of undestanding why nothing sounds right, and what to do about
it?

And note that this problem occurs even in a pure 12tET net! You
*cannot* mix plugins that thin in notes/scales with linear pitch
based plugins in just any order, and there is no way whatsoever the
host or users can be informed about that, unless there is a way for
plugins to say what they expect, and what they output.

> Solution: have a hint on the input that says it's expecting
> (1/12)/note. That way it does make sense to cast between them.
> Simple.

Yes. That's NOTEPITCH. Now, we're back at square 1: (1/12)/note is
*not* a much more sensible unit for NOTEPITCH than 12.0/octave is for
PITCH. :-)

Would work, though - and it is in fact what I suggested somewhere in
the beginning of this thread, in order to be able to use casting
(implicit, or marked by fake converters - host choice) instead of
actual conversion for this rather popular 12tET system.

> > Is it obvious that you must put any "traditional theory based"
> > plugins *before* the scale converter, if you're not doing 12tET?
>
> It is to me. I think you have to understand that anyway in the
> other system.

To some extent, maybe - but at least both you and the host can *see*
what the plugin expects and generates, so the user doesn't have to
rely on documentation to know whether a plugin thinks in notes or
linear pitch. The host could even refuse to make the wrong
connections, unless you're in "advanced mode".

> At least in this case only the people who actually
> want to use scale converters have to understand them.

Well, to some extent, but I'm pretty sure the majority of users that
use other scales than 12tET are aware of only a fraction of the
technical details discussed here. They just plug some box in on the
MIDI cable, or tweak some values in the synth, and then it just
sounds right to them.

Having an application that allows them to mix any plugins in any
order, without as much as a suggestion that "this plugin may not work
correctly with that kind of input" isn't going to be very helpful
with this background...

> > > I haven't seen any convincing argument that it isn't redundant
> > > and likly to cause problems.
> >
> > If the ability for the host to perform basic sanity checking on
> > connections is completely irrelevant, then this feature is indeed
> > redundant.
>
> The note_pitch thing isn't just about sanity checks, though, it's a
> completely different representation of the same thing.

Well, yes - it's a representation that is relative to an arbitrary
mapping, as opposed to absolute and linear.

Whether you think of linear pitch as 1.0/octave or (1/12)/note, it's
still not explicitly related to a scale, and thus, you're casting one
type of data into another, just to be able to squeeze it through the
API. That looks like a dirty hack to me.

> > I haven't seen any proof that it will cause problems, though.
>
> You can't prove a negative. I think that it's possible for it to
> cause quite big problems, which is why I'm still harping on about
> it.

I still think *not* having it can cause a great deal of trouble.
We're not really getting anywhere...

//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 -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---


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

This archive was generated by hypermail 2b28 : Sat Dec 14 2002 - 00:51:17 EET