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

David Olofson david at olofson.net
Fri Dec 13 17:53:01 UTC 2002


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 ---



More information about the Linux-audio-dev mailing list