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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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.) >
