On Mon, Dec 09, 2002 at 02:48:10PM +0100, David Olofson wrote: OK, I think I must be missing something. I dont see how a plugin can usfully process and note information without any explicit knowledge of the scale (execpt for some trivial cases, eg. octave shift, 5ths), but those can be handled in linear pitch too. I guess you can do something if its an equal tepmered scale, and you dont know the note/octave division, but isn't that an unusual case? Granted if you have some way of expressing scale information then note data makes things easier, but we dont (AFAIK). It sounds like a hard problem. If you allow note data then you still have to provide some mechanism/information for oscialtors to convert this back to a frequency, and doesnt this nullify the point? - Steve

On Monday 09 December 2002 16.30, Steve Harris wrote: 1. There is no "current scale". You may have different scales for different instruments. (As a matter of fact, you *do* most of the time IRL - except when working exclusively with synths.) 2. I don't like one or more function for every other event! There's a reason why I designed a totally inlined event system. :-) 3. Who would use that, when you can just have control inputs for note_pitch only or linear_pitch only? Agreed. Hmmm... On second thought, why support plugins with *both* note and linear pitch inputs? It could just be a hint on the pitch control, saying whether it expects note numbers or linear pitch values. They're basically both contious pitch controls, but the note_pitch version may be non-linear (non-ET scales), and will usually have a different scale, such as 12.0 per octave. Anyway, still the same thing: *plugins* should be used for conversions between the two; not host callbacks. Oh, and here's a good reason to actually use 12.0/octave for linear pitch: You won't need any scale conversions at all, as long as you use 12tET. :-) (That's why I decided to use that in Audiality in the first place.) //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 ---

On Monday 09 December 2002 18.35, Steve Harris wrote: There is potentially a "current" scale for each *Channel* of an event generator/processor. (I'm not even sure it's that simple...) Well, this is Audiality's code for linear pitch -> "whatever" conversion with linear interpolation: /* * Interpolated linear frequency -> frequency factor lookup. * * 'pith' is a 16:16 fixed point linear frequency value. * * Returns engine pitch as 16:16 fixed point. */ static inline int ptab_convert(int pitch) { int bfrac; int btone = pitch >> 16; if(btone < 0) return __pitchtab[0]; else if(btone > 127) return __pitchtab[128]; bfrac = (pitch & 0xffff) >> 8; return (__pitchtab[btone+1] * bfrac + __pitchtab[btone] * (256-bfrac)) >> 8; } (Fixed point. XAP would deal with floats, of course.) You may have that as an inline or a host call, and in the latter case, you might throw the scale management in as well - but either way, there are a few remaining problems that can't be solved with a single pair of conversion calls/macros: * Getting what you actually *need* for the synth. Is this something that can be narrowed down to one or two formats (frequency and period?), or is it perhaps better left to plugins to perform the linear->"value" conversion? Is there a point in using a host callback to make sure you have linear pitch, if you *still* need to convert again, into something else? * How do you manage scales, if they're not handled by "normal" plugins? Should all hosts have built-in UIs for this? How sophisticated must this be to actually be usable? * If you have a host callback for converting note pitch into linear pitch (or something else), how would the plugin know what scale to ask for? Given that the majority of people actually use only 12hET, how many plugins would actually get this right? In fact, how many plugin coders would even bother to implement this, if you *usually* get away with just assuming that the input is 1.0/octave or 12.0/octave or whatever, and that all pitches are based on 12tET? They don't have to be implicit. If you assume that 12tET is the standard scale, you'll *only* need scale converters when you want something else. Again, that's why 12.0/octave makes sense. It doesn't make a difference technically, but it makes *this* stuff a whole lot easier, since it just "happens" to result in note_pitch and linear_pitch being identical as long as you stick with 12tET. If you want some synth to play something else, just throw in a scale converter and pick or tune your scale. That's what you do with hardware synths, unless they come with a built-in "foreign scale" features, or when those are insufficient. Why make this a special case, when it's actually just another event processor - on that most people will never need to use? Unless your LFO or whatever *understands* scales (ie has it's own built-in scale converter, or can actually "think" in non-linear scales), it would *always* see and generate 12.0/octave. If you don't like 12.0, scale and use whatever you like internally. It doesn't change anything. Nothing. You still se, and are expected to send, 12.0/octave. It's just a figure. Scale as you like. The reason to use 12.0/octave is, as I said, just that it makes note and linear pitch identical on the physical level, which means you don't need any conversion at all, as long as you're using 12tET. 1.0 Volt is a nice and handy figure. Easy to remember, and it goes well with SI units when you design analog cirquits. There's nothing magical about the figure as such. //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 ---

On Monday 09 December 2002 23.05, Steve Harris wrote: [...] If they can do more than give you the linear pitch. (Which IMHO, you should get right in your events in the first place.) Question is, how many version do we need to make that a useful resource to plugins, rather than just another required step along the way to the final value? And the way I want it, 12tET-only hosts would have nothing at all related to scales - not even two functions that multiply or divide by 12.0. Plugins don't really have to know anything about this; designers only need to answer *one* question: "Do you care about notes or actual pitch?" If "notes"; hint your pitch inputs as "note_pitch". That way, you will always get 1.0/tone, whatever the scale is. In 12tET, this "just happens" to be exactly the same thing as 12.0/octave. If "actual pitch"; hint your pitch inputs as "linear_pitch". Now, you get 12.0/octave, period. It could have been 1.0, but then someone would need to convert back and forth, even in pure 12tET nets. Now, you can effectively have your synth just "think" in 12tET, and still be capable of playing in any scale. Scale conversion just expresses the pitch of tones of the real scale as 12.0/octave - just as it would have done with 1.0/octave; just a factor 12.0. It doesn't matter if they seem illogical, since your synth (the kind of plugins that would normally want linear_pitch) can effectively think in 12tET regardless of which scale it's being used with. It it cared about the actual *values*, it would have asked for note_pitch instead, or as well. Well, I must agree - but does representing note_pitch a 1.0/octave make more sense? :-) You could do that as well, but it means most control processors, sequencers and stuff will have to multiply with 12.0 to get the actual note pitch (1.0/tone) - which is pretty illogical as well, considering that your output may well be interpretted as 16.0/octave! Question is basically, do we "deal" with this in synths (linear_pitch) or event processors (note_pitch)? So do I, but is it worth wasting cycles and add complexity, just to prevent synth programmers from even thinking about 12tET? In fact, I can already see the FAQ: "What's this 1.0/octave thing? Where are the *notes*!?" With 12.0/octave, it's almost the opposite. 12tET brainwashed synth coders will go "Huh? How can *my* synth play that weird scale? I didn't implement that!" (There's definitely no way ever that will happen with VSTis... :-) Sequencers, most event processors (basic appregiators and the like) etc will send note_pitch. Those plugins think in terms of notes, and don't care much about what exact pitch each note represents on whatever eventually makes the sound. (This is *exactly* the situation you're in when working with MIDI.) Most synths will want linear_pitch. They generally have no reason to know or care about the higher level meaning of a note. It's just like your voice; (hopefully) it just produces exact pitch you want - and whether that's a tone in the 12tET scale is irrelevant, as long as that tone is what you're supposed to sing. With 1.0/note for note_pitch, and 12.0/octave for linear_pitch, we have a nice and extremely simple "shortcut" available for all those that use only or mostly 12tET: linear_pitch = note_pitch; No converters needed for that - and linear_pitch --> actual frequency, peroid, filter coeffs or whatever, is better done by custom, optimized code in plugins. The plugin SDK may provide some handy macros, inlines or functions to make life easier for plugin authors. Maybe there could even be a few host calls for it - but I definitely don't think that the API should *force* you to use those by design. Now, say you have a scale converter plugin. It should take note_pitch for input, and output linear_pitch. When set to 12tET, it would effectively do *nothing*. (As described above.) If you pick a different scale, the plugin actually starts doing something. For example, for 16tET, it would do: linear_pitch = note_pitch * (12.0 / 16.0); That is, "stretch" the scale so you need 16.0 note_pitch units to span one octave. Now, all of a sudden, your synths - apparently written for 12tET - can play 16tET. They don't know it, or understand it, but they're playing the right notes. BTW, there is another thing I think is rather important to realize. If you consider that we're talking about *continous* pitch (note_pitch is float!), you don't *really* need to mess with scales at all. If for example, you have a pitch tracker that generates events from a vocal track, it doesn't matter what scale you use for mapping actual frequency to pitch values. As long as you use the same scale for playing those events on a synth, that synth will play *exactly* the same pitches. Now, you may sing 16tET if you like - the events will still be 12tET, and despite that, the synth will still play exactly the same tones that you sing. Indeed, it will look weird in the note_pitch based piano roll view, but it will *work*. Conclusion: With continous pitch, a scale is basically little more than a mapping that makes some forms of higher level "logic" easier to implement. You *can* play any pitches you like without it, but for harmonizers, appregiators, note editors and stuff to understand what you're doing, you should preferably use a scale that matches what you're actually using. And forcing plugins to request information about what's going on outside their input ports, and passing that to non-optional host callbacks does not? No, but event processor coders are going to think that multiplying with 12.0 to get actual note_pitch is rather strange when there could be any number of tones/octave... ;-) I simply don't think that using 1.0/octave and 12.0/octave is worth the cost of figuring out when to translate, figuring out *how* to translate and actually doing it. The actual translation is trivial for 12tET, but getting there is not. I agree. But how much is that allowed to cost? I would be happy to see a clean solution for this, but so far, these are the only alternatives we have managed come up with: 1. 1.0/note for note_pitch, 1.0/octave for linear_pitch. Converter plugins required everywhere, even for 12tET. Even 12tET-only hosts have to handle this. 2. 1.0/octave for linear_pitch, no note_pitch (?). Host calls required for conversions. Plugins have to find out what scales senders are using, or who is sending what. How does this work if multiple senders send to the same Channel? 3. 1.0/note for note_pitch, 12.0/octave for linear_pitch, No conversion needed for 12tET. Converter plugins can be used when other scales are desired. There cannot be 12tET-only hosts, since scales are not a host side matter. More ideas, anyone? //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 ---

On Tuesday 10 December 2002 01.31, Steve Harris wrote: [...] How and when would the host do this? It normally won't touch or even see events passed from one plugin to another, so there is no natural place to do this. Well, so do I... 1/12 is just as bad IMHO, but hopefully, we'll only see that in note editors, appregiators and that kind of places. (And we could actually wrap it in macros, to keep people from having bad ideas... *heh*) And given that "real" plugins think only in linear pitch, note/scale oriented plugins should pay? Well, I would like to have some actual statistics on this... On the VST list, it's exactly the other way around - but then, they have *MIDI* in thier events, so what can you expect? ;-) You can't do that. You can't implement useful scale conversion that easy anyway, so we're talking about a hardcoded pitch*12.0, just to convert the note_pitch we asked for from (1/12)/note to the much more sensible 1.0/note. It's a matter of "packing" the 1.0/note note_pitch into something that's physically equivalent to 1.0/octave when dealing with 12tET, just so you don't have to use scale converters at all for 12tET. When you actually *need* a scale converter, it would also get (1/12)/note (as anyone that asks for note_pitch) and scale it to 1.0/note for internal calculations. Then it would output 1.0/octave, linear_pitch, of course, since that is the only truly sensible unit. Right. Nor does 12.0 / octave. One looks nice in syths and various event processors, and the other looks nice in note/scale oriented things. Both result in note_pitch and linear_pitch being the same value for the same actual pitch in 12tET, so you *only* need to mess with scale converters when you actually want non-12tET. I suggest new terminology: Linear pitch becomes... * Actual Pitch 1.0/octave, period. and note pitch becomes... * Virtual Pitch (1/12)/note. Can be cast directly to Actual Pitch for 12tET. Scale converters needed for other scales. Editors and processors need not understand scales completely, as VP is *alway* (1/12)/note. Why? Well, both are linear pitch. The only difference is in the interpretation. Actual pitch is complete, self contained data, while Virtual Pitch is related to a scale that you may or may not need to understand to deal with the data. //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 ---

On Tuesday 10 December 2002 13.00, Steve Harris wrote: [...pseudocode and stuff...] Yes. I don't like the fact that you can't map 1.0/note to 1.0/octave without a scale converter (althoug a very trivial one), but the only alternative is to define (1/12)/note for note pitch, regardless of scale. Well, I can't deny that! :-) Of course. I never said anything else. What I'm trying to say is that (1/12)/note certainly doesn't look nice in note oriented code, considering that there's *not* nescessarilly 12 notes per octave: arpeggiator { offset = offsets[fmod(time() * speed, steps)]; out = in + offset * (1/12); } ...and to avoid both that *and* have 1.0/octave for linear pitch, we have to do actual conversions whenever connecting these two different kinds of controls. The only sensible way of doing that is by using some form of conerter plugins, IMHO. I definitely do not want to force host callbacks into this. //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 ---

On Wednesday 11 December 2002 00.29, Steve Harris wrote: You're missing that I'm not talking about 1.0/octave, linear pitch, but <something>/note, *note* pitch. That means <something>/note should *always* apply, and that <something> should be constant. Changing it is totally pointless, since you'd still have note pitch. Changing the "size" of one note is about as silly as changing the "size" of one octave; that's my whole point. (1/12)/note for note pitch *is* just as silly as 12.0/octave for linear pitch. Right. Some plugins think in 1.0/note, and others in 1.0/octave. If you want to connect them, you'll need "something" that expresses 1.0/note as 1.0/octave according to your scale of choice. Just as if you were going to connect a MIDI controller to a CV synth. Exactly! :-) //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 ---

On Wednesday 11 December 2002 12.06, Steve Harris wrote: I do, definitely. It's the *only* logical reference to anything in a scale, since you may not even have octaves. (BTW, this applies to the the tuning of most grands. Lower octaves are tweaked downwards, while higher octaves are tweaked upwards. Not 100% sure why, but I suspect it has to do with the overtone spectra for low notes. At least, that seems to be why some phatt synth/techno bass sounds don't sound right if you play them at the "correct" pitch.) There is nothing 12ey *at all* about notes if you're into 16t... So, 1.0/note makes sense, (1/12)/note does *not*. :-) I would have agreed with you a while ago, but I think the VST guys have a point. Why would you *force* harmonizers, autocomp "machines" and the like to think in terms of linear pitch? I personally think in semitones rather than musical scales when I compose and arrange (0-4-7, 0-3-7 etc; tracker arpeggio remember? :-), but I would think that classical tone/scale based theory is pretty deeply rooted in most musicians/coders. So, I'm afraid the general reaction to an API that doesn't understand that concept would be something like this: "Huh? Not aware of *notes*!? Useless for music!" Either way, I *do* see advantages in being able to say whether you're only interested in actual pitch, or "virtual tones in a scale of the user's choice." For example, that avoids having to re-record or edit everything just because you decide to change from 12tET to some other 12t tuning. And finally, you *can* tell the host that you want 1 note/octave, and use 1.0/octave throughout. No special support needed for that. (Well, expect that hosts that like to nag about control hint incompatibilities would have to be told that 1 note/octave and 1.0/octave are "compatible enough" for implicit casting.) //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 ---

On Wednesday 11 December 2002 17.17, Steve Harris wrote: It's always <whatever>/note, and it's always trivial. The non-trivial stuff goes on in the scale converter plugin. MIDI pitch is always MIDI pitch, which is 1/note. This is the same thing, only you can say note pitch 0.5 instead of pitch bend range +/-2; pitch bend 2048; note pitch 60 and do that independently for each note without going Universal SysEx or one note/channel. You don't change the value of "1" in the MIDI protocol when using a MIDI scale converter. You don't change the value of 1.0 when using a scale converter plugin. That *is* the scale converter, if you're dealing with a "primitive" sampler that cannot implement this properly. But indeed, you may do it directly in the sampler as well. (And IMHO, that's the way you *should* do it, since, as I suggested, the need for this tuning is directly related to the sound of the instrument.) A sequencer is just something that records and plays back events. A kind of event processor. You may integrate it with your host, or you may use some sequencer plugin that comes with the SDK, or whatever. The API shouldn't rule any of this out, or it will rule out a number of interesting plugins, such as phrase sequencers and virtual analog sequencers. The GUI is another issue - which indeed, is something we have to consider for all plugins, if we're going anywhere with this API. The way I see it, the Control interface should be a sufficient plugin/GUI interface, so that all we need is a standard way of connecting controls to the external, non-RT applications that GUIs will normally be. Whatever comes in should go throgh the host's "preset database", so that the host knows the current value of every control at all times. I'm thinking in terms of GUI == non-RT plugin, or rather client to the event system. That is, inside a XAP host, you would see GUI as an ordinary plugin in the net. Although it's not really physically in there; what you see is a gateway plugin that interfaces with the non-RT GUI plugin outside. //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 ---

On Tuesday 10 December 2002 14.48, Nathaniel Virgo wrote: How would that make anything easier? Wrong. Linear pitch, as used by synths, is <some value>/octave, and that's all there is to it. When dealing with scales, you take one form of pitch control - be it MIDI note numbers + pitch bend, or *Continuos* Pitch (1.0/note for example) - and express the note pitches as Linear Pitch, Hz Frequency, or whatever. Linear Pitch is just a mathematically handy way of expressing frequency. [...] Exactly. That's why I don't think Hz frequency belongs in the API at all. You'll do better with linear pitch most of the time, and when you finally reach an oscillator that wants period or frequency, it's easy enough to calculate it. Agreed. It's just that all other solutions seem to be just about as bad. :-( Where does the int cast get in...? Yes. So let's have 1.0/note for continous pitch (corresponds to MIDI pitch + pitch bend, sort of; this is *before* you apply scales), 1.0/octave for linear pitch (absolute relation to Hz), and then... we'll have to convert continuos to linear at some point. That's the disadvantage; you *have* to actually convert. (Well, unless you're thinking in terms of one tone/octave.) Pros with scale converter plugins: * They are just plugins, and can do *anything*. * Any host can host them - no need for explicit scale support. * New scale converters can be used directly with any host. Can someone suggest alternaties and advantages with those? //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 ---

On Wed, Dec 11, 2002 at 12:40:18 +0000, Nathaniel Virgo wrote: We could put it to a vote ;) - Steve

On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote: So do I, definitely. There has never been an argument about <something>/octave, and there no longer is an argument about 1.0/octave. The "argument" is about whether or not we should have a scale related pitch control type *as well*. It's really more of a hint than an actual data type, as you could just assume "1tET" and use both as 1.0/octave. The need for 1.0/note or similar arrise when you want to work with something like 12t without deciding on the exact tuning, and also when you want to write "simple" event processor plugins that think it terms of notes rather than actual pitch. //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 ---

David Olofson wrote: Not to sound rude or anything, but I've been following this thread and still have yet to be convinced of the necessity for an internal conept of "note". Disclaimers: 1) Although schooled intensively in classical music theory (I have even taught it at the university level), I consider the whole conept of "notes" a little outdated; and (more importantly) 2) my coding skills are still pretty rudimentary. I can see the need for conversion from, say midi note numbers, but I have to admit that I still don't really see the need for an API to know about "notes". -dgm

David Olofson wrote: Right, but would the *user* actually see any of this? I was under the impression that any details of pitch control would be handled by the plugins themselves, and any mapping of the user's preferred frequency-based frame of reference to note_pitch or linear_pitch would be handled transparently. The only people who might need to worry about this would be coders, and as I think someone pointed out, anyone who can write DSP code can do the conversion from whatever pitch system they wish to use (if any) to whatever pitch system XAP eventually ends up using internally. Fair enough. I'm pretty sure I don't understand enough about DSP coding to even think about this. :) I'll leave that one to Steve (who seems to have no shortage of projects at the moment anyway.) Right, but couldn't you just have a function that maps arbitrary pitch systems to whatever ends up being the internal unit? I'm pretty sure this was thrown around already anyway... Not very, I suppose. Right.... (Off to ponder.)

On Wed, Dec 11, 2002 at 12:40:18 +0000, Nathaniel Virgo wrote: Problem with letting the host worry about it is that the host would normally not understand anything of this whatsoever, since the normal case would be that a sequencer *plugin* controls the synths. It would be a hack. As to API, all there is to it is the existence of a note_pitch hint for pitch controls, that suggests that the value *could* be interpretted as something else than 1.0/octave. If you want 1.0/octave throughout, just ignore it and think of any pitch control you see as 1.0/octave. //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 ---

On Monday 09 December 2002 15.59, Steve Harris wrote: You can do a lot more than that even with just integer MIDI pitch, at least if you assume that the scale in use is *somewhat* similar to 12tET. Even if some notes in the scale deviate a bit from the pitch they have in the 12tET scale, basic 12 tone theory still applies - and that's what the vast majority of harmonizers, autocomp units and whatnot are based on. So, why force these plugins to look at the scale in use, convert linear pitch into note pitch, process that, and then look at the scale and convert note pitch back into linear pitch for proper playback? They *could*, but IMHO, it should be optional, since it should be easy enough to have separate converter plugins for this. Yes, probably. That would be 16 tone scales and that kind of stuff - but even then, the *actual* problem is still there: You cannot know for sure what linear pitch values mean in terms of tones in the current scale, unless you have a description of that scale at hand. If the linear pitch of a note is more than 50 cents off from the corresponding tone in the corresponding ET scale, you get the wrong note. That's why simple plugins should not be forced to worry about it. As to scale information, that's basically something that's built into sequencers, scale converters and that kind of plugins. The implementation may be the definition, or the implementation might convert according to a scale definition loaded from a file of some (non-)standard format. However, it doesn't matter. If you deal only with 12tET, all you need is that multiplication or division by (1.0/12.0), if even that. (Linear pitch is still just linear pitch, and most synths should probably just use that.) Synths could chose not to have note_pitch controls at all (host or user throws in a suitable converter), to have note_pitch and built-in 12tET conversion (or more advanced converters) or to have *only* note_pitch and some kind of note->pitch conversion. Anything will work, and should be easy enough to deal with. No, because a synth is not *required* to have note_pitch inputs. It's considered an integrated bonus feature, if found on a synth. *If* a synth has note_pitch input, the synth could be seen as having builtin scale converters - which is something you might just as well plug in in between the synth and the event source. (Which would allow you to have different senders playing the same channel of the same synth with different scales, BTW. :-) Same thing applies to sequencers. Normally, you'd probably want a sequencer to "think" in terms of note_pitch, so you can tweak scales without destructively (and potentially irreversibly) modifying the database. However, since you'll normally connect a sequencer directly to a synth (and synths usually want linear_pitch), it might make sense to throw in a scale converter on each output channel. (Or a single global one, or whatever.) But that'd also be a bonus feature, since you might as well output *only* note_pitch, and then just throw in your favourite scale converter/generator plugin whenever you want or need to give some synth linear_pitch rather than note_pith. //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 ---

On Monday 09 December 2002 17.05, Steve Harris wrote: Well, it can be done with one form only, that will only make life harder on those who don't want to truly understand non-12tET scales. It may be messy if done wrong, but I strongly doubt anyone on the VST list would agree that it is unnecsessary. They convinced me, at least. It's not cleaner in any way, since for this to be useful, the plugin has to figure out what scale it should ask about. Again, there is no such thing as a single, global scale. If you assume that, you may as well ignore anything about non-12tET altogether. Well, yeah - presets. Just like with any other plugins. A scale converter is an *effect*, and deserves to be treated as such by the API. //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 ---

On Monday 09 December 2002 18.44, Steve Harris wrote: You want "simple" event processors to pay the price? Well, maybe that's ok, bit I'd prefer if they could just say "I want note_pitch!" and then assume that 1.0 will always be one note, whatever scale is used. What I'm saying is simply that if *everything* in a standard, 12tET net uses 12.0/octave, it doesn't matter whether you say you're taking or sending note_pitch or linear_pitch - because they look exactly the same. That way, *no one* pays the price for non-12tET - until you actually want something to play using a different scale. When you want that, you just insert a scale converter, and from then on, everything is expressed as linear_pitch, based on the scale selected for that converter. Normally, you'd just place it on a Channel of a synth, but if you're into modular, you place it wherever you want to start dealing with linear_pitch rather than note_pitch. You're probably right. The main thing they wanted to convince me of was that you need *both* note pitch and linear pitch - but OTOH, that was thinking in the terms of the rather primitive MIDI based, effectively one-way event system of current VST. Our plugins will be able to *tell* the host and/or the user what they expect by hinting their controls, so it's much less of a problem. You *could* even get both, I guess... (Have a switch on the scale converter to enable passthrough of the original events to some other control index. You *can* have multiple controls with the same "type hint", so that's not a problem.) I don't think that's true. At least in "real" music, it's really rather common to mix slightly "alien" scales with 12tET. Many singers, violinists and other "continous pitch" people *deliberately* tweak notes to make them fit better - although one might perhaps think of that as something different from scales; not sure. Some people do all sorts of weird stuff. Considering that Steinberg and others seem to think this really matters, I don't think we should ignore it. Why implement something that is inferor to the *current* version of VST, when we already know that people are complaining, and that Steinberg most probably will improve these matters in VST 3.0? AFAIK, there are even musicians that don't have much use of current standard synths and applications, simply because they're too restrictive, and/or way too cumbersome to deal with, when it comes to scales and pitch control. Well, that's what I meant, actually. One graph would usually correspond to one song. We don't? Well, lets hope that all Multichannel synths will do the right thing when someone wants to play different scales on *the same instance*. The way I see it, this could all be rather trivial - but I seem to be missing something... I disagree. And I think lossy vs lossless is entirely besides the point. Effects *cannot* be lossless? If you're referring to loss of accuracy in the processing, well then conversions cannot be lossless either. (Besides, I actually meant plugins, event processors or whatever, rather than "effects". Dunno where I got that from...) Either way, scale conversions are lossless? When you're dealing with *continous* pitch, you'll need either an exact formula, or you'll have to use an approximation of some kind. We're not talking about plain LUTs. (Pitch bend needs more than that, and continous pitch is basically "pitch bend done right".) //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 ---

On Monday 09 December 2002 23.25, Steve Harris wrote: [...] Then you're missing the point. My 12.0/octave linear_pitch is *exactly* the same thing as your 1.0 - except that it's 12.0 instead of 1.0. (See previous post.) Well, you're right. That's why I'm now effectively trying to reduce note_pitch vs linear_pitch into a matter of interpretation, rather than two different formats. It's basically just all linear_pitch, although when messing with non-12tET scales, you (or the host - but that's not at all required) *may* have to care about the difference when using certain plugins. The default case would actually be MIDI pitch + pitch bend - but most of them seem to ignore that too, so I guess it's just totally impossible to use their plugins with guitar synthesizers and other pitch tracking devices... No, and in this case you would have to *change* that tuning to track the chords in the music, since you will have to "tweak" in different ways depending on that. This is basically about getting the resulting harmonies to sound better than they normally would in 12tET. No, I would like to think so too - but then, what is the answer? I can't see an alternative that doesn't bring complexity and overhead into hosts and/or plugins. No note numbering is enforced. It's just that there's this stupid 12.0 factor instead of 1.0... :-/ Yes, they will. Who said 1.0/tone implies that there is an integer number of tones/octave, or even that the tuning repeats for every octave? Either way, it doesn't matter to synths anyway, since they don't care about numbering anyway. I *am* suggesting to represent pitch; just that it is expressed as 12.0/octave instead of 1.0/octave, to eliminate all conversions in 12tET systems. 12tET is indeed a default that makes sense to a lot of people - and if you don't care for 12tET or scales *at all*, just think pitch and ignore the actual figures. If you like to have scales (for the few plugins that should care, and for piano roll editing or whatever), consider pitch 1.0/tone everywhere, except on the other side of your scale converters. It *does* hurt the 12tET case, at least unless you're suggesting that sequencers should always store 1.0/octave...? Well, that's exactly why I want to avoid it entirely, by working in 1.0/tone until I actually *need* pitch. If you do 1.0/octave everywhere, the tone/scale logic is lost. As long as you're doing 12tET, it might not matter, but when you start using other scales, it may quickly become both expensive and innacurate. //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 ---

On Tuesday 10 December 2002 13.15, Steve Harris wrote: [...] You're missing the point with the "cast is conversion" hack. A host writer *cannot* prevent other scales from being used, unless they specifically refuse to load plugins that happen to do scale conversion. Sequencers are going to store pitch in the form of floats. The argument is about whether these should be in 1.0/note or (1/12)/note format. (And this has nothing to do with scales or notes/octave; it's <something>/note, period.) Or forces a few (or so we seem to thing) to work around a factor of 1/12... Either way, this is the situation: We have to pick *two* out of three good things: 1. 1.0/octave 2. 1.0/note 3. No conversions for 12tET. I think I would pick 1 + 2, and accept that conversion is required whenever you want to drive 1.0/octave from 1.0/note, but you rejected that. I rejected the alternative of using special host callbacks to deal with these conversions. You also rejected 2 + 3, since that results in 12.0/octave. I rejected 1 + 3, since it results in (1/12)/octave. So, are there any more alternatives? //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 ---

On Wednesday 11 December 2002 00.33, Steve Harris wrote: Yeah. Well, you could just tell your editor (if any) that you want to use 1 note/octave, and use a standard sequencer without scale converters. :-) Considering that I hardly ever use any "MIDI plugins", I would think so too. (This might change when I find some that can actually do something useful.) I see. (Sorry about the confusion - this has been a rather long thread, and I was rather tired last night... :-) Anyway, given that a converter plugin instance can only ever be called once per buffer, and could potentially handle multiple channels, I'm sure it will be quite a bit faster than host callbacks when it actually matters: when you're flooded with events. //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 ---

On Wednesday 11 December 2002 12.10, Steve Harris wrote: They are not parallel. One actually *is* frequency, while the other expresses pitch in relation to a scale. It's like comparing inline code with calls through function pointers, basically. Yes, but that's not the point. And 12tET is essentially irrelevant to this discussion (now, even *I* say that! ;-) - it just happens to be what most people use most of the time. (Or is it? I'm thinking that there may be some rather significant cultures where this is not true... Unless they're all brainwashed by our 12tET music, we may eventually be outnumbered!) *hehe* //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 ---

On Wednesday 11 December 2002 18.26, Steve Harris wrote: No, not unless the string representation is supposed to translate in a number of different ways, depending on what character table you use. In code, for linear_pitch: actual_pitch = linear_pitch; whereas for note_pitch (simplified; no interpolation): actual_pitch = scale[note_pitch]; There is only one valid relation between actual pitch and linear pitch, while the relation between actual pitch and *note* pitch is user defined. //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 ---

[representing pitch] i'm a classically trained musician, and i even failed to learn csound properly, but even so it strikes me as highly arbitrary and somewhat anachronistic to stick to the 12 semitones/octave model. so i'd strongly second steve's suggestion to have 1.0f per octave and nothing else (you might say even the notion of an octave is anachronistic, but then it's a ratio of 2:1, which *is* some sort of natural constant in music). back to lurk mode... -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)