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: Sebastien Metrot (meeloo_AT_noos.fr)
Date: Sun Dec 15 2002 - 23:46:00 EET


Sorry to step in this very interesting discution but I have one question
regarding this floating point note/pitch thing. Floating point is great for
DSP code as it makes our lives quite easy. On the other hand, floating point
is not a very stable way of storing fixed values such as notes. Many
applications rely a lot on the midi note number, for exemple mapping a drum
kit on each note of a keyboard is something that most of us do everyday. I
think most of you know that there are some numbers that have no
representation in floating point format, and you must also know that
comparing floating point numbers (as in a == b) may fail even for some
really stupid and simple cases. I wonder if programming a beat box (for
exemple) in such an environement could be be made really over complicated
and could create some very interesting bugs. I don't thing using octave/1 is
a good idea, I also fail to understand why you totaly refuse to build on the
existing fundations of midi that all musicians understand very well and is
well established in the comunity. I'd preffer an integer giving the original
midi note and a floating point value giving the deviation of this note
(1/octave or 1/note, i don't really care about this).

Also considering the time information passing in between the plug and the
host I agree with David that it is a must have, as well as transport
information. My experience with VST is that they got all the automation
stuff very wrong as they give the information with no time reference and
many hosts interpret this in very strange ways. On the other hand they
managed to give some timing information when they introduced VST2 and the
capacity to receive/send midi events. I think there is a need to unify all
these events: automation, notes, time change, tempo change, etc. What a
plugin/instrument writer really need is to be asked for a block of audio. In
order to process the said block of data the hosts pass him a struct
containing all the informations he need: all the events that happened during
the block. So we can have multiple even type (note on/off, tempo change,
transport event, automation, etc...) in a linked list (or even a list by
type of event if you prefer that). All the timing & transport event can be
processed only once for all the plugins and every event can be given in a
sample accurate fashion (even automation, unlike VST).
What if a plugin doesn't care about this info? Just ignore it!
What to do when the transport is stopped? Reference the even from the time
when the transport was stopped.

Of course I can be plain wrong, do not hesitate to put me on the right track
if this is the case...

Sebastien

----- Original Message -----
From: "David Olofson" <david_AT_olofson.net>
To: <linux-audio-dev_AT_music.columbia.edu>
Sent: Sunday, 15 December, 2002 21:12
Subject: Re: [linux-audio-dev] XAP status : incomplete draft

>
> You're still missing the point. Note pitch is <something>/note, which
> is a linear scale. With 12t, it's identical to 12tET. This is very
> easy to process.
>
> np[0] = np_in;
> np[1] = np_in + 3.0/12.0;
> np[2] = np_in + 7.0/12.0;
>
> gives you a chord. (I'm assuming we're using (1/12)/note, so the
> formats become equivalent is you assume ET scale or scaleless.)
>
> Now, you can apply a scale converter with a pure 12t scale, and you
> *still* get the "same" chord, only sounding slightly different. (If
> you're close to the indended key, it'll sound better, otherwise
> worse.)
>


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

This archive was generated by hypermail 2b28 : Sun Dec 15 2002 - 23:50:32 EET