On Saturday 14 December 2002 23.20, David Gerard Matthews wrote: [...] Do you have experience with processing events meant for non-ET scales? I'm looking for a definitive answer to this question, but it seems that this kind of stuff is used so rarely that one might argue that 12tET and scaleless are the only two significant alternatives. (And in that case, the answer is very simple: Use 1.0/octave, and assume 12tET whenever you want to think in terms of notes.) Well, you do have to be able to lock to tempo and/or musical time in some cases - but (IMHO) that is an entirely different matter, which has little to do with whatever format the event timestamps have. This confirms my suspicions. (And I even have some experience of just being annoyed with those non-optional grids... :-/ In some cases, you just want to make the *music* the timeline; not the other way around.) Let's put it like this; two altornatives (or both, maybe): 1. Plugins receive timestamped events, telling them what to do during each block. Effectively the same thing as audio rate control streams; only structured data instead of "raw" samples. 2. Plugins get direct access to the musical events, as stored within the sequencer. (These will obviously not have audio timestamps!) Now, plugins can just look at the part of the timeline corresponding to each block, and do whatever they like. Some event processors may well play the whole track backwards! This solution would also make it possible for plugins to *modify* events in the sequencer database, which means you can implement practically anything as a plugin. Obviously, these are two very different ways of dealing with events. I would say they are solutions for completely different problem spaces, with only slight overlap. One cannot replace the other; if you want to deal with the combined problem space, you need both. Why can't 2 deal with everything? Well, consider the simple case where you want to chain plugins. One plugin reads events from the sequencer, and is supposed to make a synth play the events. However, now the *synth* will expect to have access to an event database as well! So what does that first plugin do...? Plug in as a "wrapper" around the whole sequencer database? Well, I could think of ways to make that work, but none that make any sense for a real time oriented API. Suggestions? Is there a third kind of "event system" that I've missed? Well, I see what you mean - but see above; The timestamps are not much of an issue, since sync'ed and locked effects would get their musical time info by other means. Though, obviously - if timestamps are in musical time and you can have only one timeline, you have a problem... Or not. (My question is basically whether you need to be able to sync or lock to multiple timelines or not.) For timestamps, yes - but if you want your plugin to "spontaneously" (ie without explicit "note" events) to sync with the tempo or the beat...? Or in the sequencer *plugin* - if you like to implement it that way. Since MuCoS/MAIA, I've been convinced that the host should be as simple as possible. Basically just like the room in which you build your studio. There's light so you can see what you're doing (UI<->plugin connection support), power outlets for you machines (memory management, event system,...), and various sorts of cables hanging on the walls (routing/connection system). You'd bring in controllers, synths, mixers, effects, powered speakers etc. (Plugins!) Yes. (See above, though.) Well, that's what everyone used to tell *me* - and now the situation is pretty much the opposite. :-) Well, at least I *tried* to squeeze it all into MAIA. I have indeed given all of these issues a lot of thought, over and over again - and finally realized that even if it *could* be made to work, it would take ages to get right, and it would be way too complex to use for anything serious. I've learned my lesson. Maybe others should too... Well, yes - but I was rather thinking about CoolEdit and SoundForge style things, and their off-line plugins. You could say the term "audio editor" is rather unspecific! :-) MIDI!? Aaargh! :-) Well, if there was a way to sync + lock nicely with the ALSA sequencer...? Yes, I agree totally on that. JACK replaces crude and/or high latency hacks and allows applications to play nicely together. LADSPA and eventually (or so we hope) XAP turns monoliths into modular applications, that can exchange and combine units in any way the user wants. Very good point! It's a much more recent design, and even if the motives for creating it were perhaps not only technical, one would assume that these guys know what they're doing. Yes. Well, I don't exactly know Objective C, but I've read up on the basics, for reasons I can't remember... (Probably to see if it was the "C++ done right" I was looking for. In that case, it was not, because the contructs are *higher* level; not lower.) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Sunday 15 December 2002 01.10, Steve Harris wrote: OTOH, have you looked at how the VST host/plugin interface is actually implemented? Pretty "interesting". :-) (And here we worry about function call overhead...) Well, there's always struct-in-struct + typecasts... ;-) Seriously though, I think a plugin API of this kind *needing* C++ would suggest that there's something wrong with the design. It shouldn't be that complex. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Sunday 15 December 2002 01.49, Steve Harris wrote: Yeah, that's probably a good idea. (Not that we'd be very likely to copy that part anyway... :-) Well, as long as the compiler generates a clean C interface, any language is fine for plugin implementations. Speaking of which, does anyone hack LADSPA plugins in C++, or other languages? //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Sun, Dec 15, 2002 at 01:59:24 +0100, David Olofson wrote: The CMT set are all C++. That's the reason I didn't start by contributing to it. - Steve

On Sat, Dec 14, 2002 at 07:47:55 -0500, David Gerard Matthews wrote: It doesn't really require any c++ familarity, its more like Smalltalk (a "real" OO language). Apple do have a history of Objective C, and they use gnu compiler IIRC, so in theory porting OSX apps or writing linux.osc apps shouldn't be hard. - Steve

On Sunday 15 December 2002 00.32, Paul Davis wrote: Exactly. Unless I'm missing something, all you need for this is a way for plugins to keep track of the tempo (sync) and musical time (lock). The TEMPO + POSITION_* event set I proposed should be sufficient for for sample accurate lock to musical time, even accross tempo changes and transport skips. It is not just "very nice"; it's a required feature, IMNSHO. And it should preferably be sample accurate, and capable of tracking even the most furious tempo maps. Someone will complain sooner or later if they aren't. I would like to clarify something here: musical time as used in an API is not by definition "periodic". (That's just an interpretation of it, normally based of the time signature.) The APIs that don't use audio frames for timestamps and song position generally use "ticks". 1.0 per quarter note is a fine unit, for example, if we (like practically everyone else) decide to use the quarter note as the base. It's rather handy, because a quarter note is always a quarter note, but a bar might be anything... The important point is that musical time represents the movement of a *timeline*. Unlike audio time, it is not free running time in any way, but a representation of the sequencer's idea of time. That is, locking to musical time is essentially the same thing as locking to the sequencer. And if you do that, your plugin and the sequencer will have a common reference for time, that the sequencer can play around with as it wishes, while you can just modulate some audio with (sin(musical_time * M_PI * 2.0) + 1.0) or whatever. ;-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Sunday 15 December 2002 03.25, David Gerard Matthews wrote: [...] Well, I never said it was the unit of a *beat*. ;-) Well, yes - I've actually used that sometimes. Yes. And either way, even if you never *use* a quarter note, or the corresponding distance, in your music, quarters, dotted quarters, 16ths or whatever still have a fixed relation. Just tell the plugin to do 16ths, and it'll get the idea. Or maybe not... out = in * (1.0 - fmod(musical_time * 4.0, 1.0)); would be more fun, although you'd need some filtering on the modulator to kill that awfull clicking. Or just use it to index an interpolated "envelope waveform" of some 16 points or so. (*Now* it starts to get interesting. :-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Sunday 15 December 2002 03.53, Tim Goetze wrote: Well, yes - but is there any sequencer out there that deals with the basic timeline + sequencer stuff? Sounds interesting. Will check. Just started browsing MusE source, actually. Discovered that the synth API indeed uses *audio* timestamps (as expected), so I'll have to look at the sequencer core for whatever we might be missing here. That's not really what it's about. IMHO, we should have 1/octave for basically "everything", but also something that's officially hinted as "virtual pitch", which is related to an unspecified scale, rater than directly to pitch. Example: 1. You have integer MIDI notes in. 2. You have a scale converter. The scale is not 12tET, but a "pure" 12t scale, that results in better sounding intervals in a certain key. 3. Output is linear pitch (1.0/octave). In this example, the scale converter would take what I call note pitch, and generate linear pitch. Note pitch - whether it's expressed as integer notes + pitch bend, or as continous pitch - is virtual; it is not what you want to use to control your synth. Linear pitch is the *actual* pitch, that will drive the pitch inputs on synths. So far, there is no big deal what you call the two; you could just say that you have 12tET before the converter, and 12t pure temperament after it. Now, if you wanted to insert an effect that looks at the input and generates a suitable chord, where would you put it, and how would you implement it? Hint: There are two answers; one relatively trivial, and one that's both complicated and requires that two plugins are completely aware of the details of the pure 12t scale. If this does not demonstrate why I think NOTEPITCH is useful, I frankly have no idea how to explain it, short of implementing both alternatives in code. Of course - but I don't see how that relates to audio timestamps. Musical time is something that is locked to the sequencer's timeline, whereas audio time is simply running sample count. Whenever the sequencer is running (and actually when it's stopped as well!), there is a well defined relation between the two. If there wasn't you would not be able to control a softsynth from the sequencer with better than totally random latency! Within the context of a plugin's process()/run() call, the sequencer will already have defined the musical/audio relation very strictly, so it doesn't matter which one you get - you can always translate. You can *always* translate? Well, not quite! Read on. OTOH, musical time is really rather opaque to DSP programmers, and either way, has to be translated into audio time, sooner or later, one way or another. I find it illogical to use a foreign unit in a place where everything else is bound to "real" time and samples. And that's not all there is to it. Surprize: Musical time *stops* when you stop the sequencer, which means that plugins can no longer exchange timestamped events! You may send and receive events all you like, but they will all have the same timestamp, and since time is not moving, you're not *allowed* to handle the events you receive. (If you did, sample accurate timing would be out the window.) So, for example, you can't change controls on your mixer, unless you have the sequencer running. How logical is that in a virtual studio? How logical is it not to be able to play a synth *at all*, unless "something" fakes a musical timeline for it? Should plugins have a special case event handler for when time stands still? If so, what would it do? How could it allow the automation's nice declick ramping on PFL buttons and the like to work, if there is no running time to relate the ramp durations to? I'm afraid this simply won't work in any system that doesn't assume that the whole world stops when you stop the sequencer. Right. Anything like b.b.t assumes that you actually *have* bars and beats, which may not be relevant at all, depending on what you're doing. IMHO, it should not be hardcoded into sequencers, and definitely not into APIs. That's what I'm thinking - and that's where the event system I'm talking about comes in. It's nothing but an alternative to audio rate controls, basically. Yes, I realize now that you have a good point here; if you know how far into the future an event is to be executed, you don't have to reevaluate it once per block. This could be considered a performance hack, *provided* it actually costs less to evaluate a correct time for a future event, than to check once per block. I *think* it would. That said, there is one very important thing to remember when using this feature: No one knows anything about the future! You *may* know about the future along the sequencer's timeline, but you do *not* know what the relation between audio time and musical time will be after the end of the current buffer. After you return from process(), event scheduled (be it with sample count or musical time as a timestamp), someone might commit an edit to the timeline, there could be a transport stop, or there could be a transport jump. In either of those cases, you're in trouble. If you have an audio rate timestamp, it simply becomes invalid, and must be recalculated. If it's a musical timestamp, you may end up leaking events. For example, in a loop, you would end up sceduling some events after the loop, over and over again. The events would never be delivered, and thus, never removed. Of course, in the first case, you can just invalidate all scheduled events. (But make sure you have the original musical timestamps somewhere! :-) In the latter case, you can deal with transport events, and remove anything (what?) you won't be needing. No matter how you turn this stuff about, some things get a bit hairy. The most important thing to keep in mind though, is that some designs make some things virtually *impossible*. I disagree. It's also a technical decision. Many synths and effects will sync with the tempo, and/or lock to the timeline. If you can have only one timeline, you'll have trouble controlling these plugins properly, since they tread the timeline pretty much like a "rhythm" that's hardcoded into the timeline. It's not just about moving notes around. Well, if you have two tempo maps, how would you apply the "meter map"? I guess the meter map would just be a shared object, and that meter changes are related to musical time of the respective map, but there *are* (at least theoretically) other ways. Either way, IMHO, these belong together. (And SMPTE, MIDI clock and stuff belongs there as well; all that makes "one timeline".) It doesn't seem too complicated if you think of it as separate sequencers, each with a timeline of it's own... They're just sending events to various units anyway, so what's the difference if they send events describing different tempo maps as well? Well, I can understand that... :-) Though, it seems to me that it might be rather handy when dealing with soundscapes and similar stuff. Most of the time, you'll basically have no explicit tempo at all, but if you want to throw in some little tunes and stuff... Imagine a large 3D soundscape that you can walk around in; pretty much like a game environment. Some radio playing music somewhere. Someone whistling... How about having a sequencer understand Q3A maps with special speaker entities, so you can create complete 3D soundscapes for maps right in the sequencer? ;-) Maybe it will be in most cases, but I can't see any real reasons why you couldn't implement it as a reasonably normal plugin. Indeed, it would need a "private" interface for interaction with it's GUI, but that's to be expected. Yes, but you still have to deal with tranport events. No big deal, though; you just have to tell everyone that cares about them, so they can adjust their internal "song position counters" at the right time. For most plugins, there won't be a difference. It only matters to driver plugins (and you don't use audio and MIDI drivers for off-line processing), plugins with background worker threads, and plugins with latency compensated interfaces for their GUIs. Even for many of these, it's no big deal; they'll work anyway, although you'll obviously get silly results in some cases. Well, I *think* so... ;-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

Replying to myself with two other ideas: 1) the host->tick_me(plugin, 100, cookie) // call me back in 100 ticks - This could be a simple host-based time-management API - This depends on a 1-1 map between host and timeline, which I think is ok 2) rather than having per-channel TEMPO etc controls, have a small set of host-global (timeline global, if you prefer to say) event queues. If a channel is concerned with TEMPO, they will have already gotten the hosts TEMPO queue. They can then check it. This saves delivering the same event struct to potentially many plugins, and still is sample accurate. Again, just blathering. Trying to find something elegant.. Tim

Paul Davis wrote: Callbacks do make sense here, I agree. You never know about the ticks, though. In film scoring, it's not uncommon to nudge things around a tick or two here or there to enable audio events to sync up with the picture. I can see wanting to chase audio on every tick in some very high resolution contexts like that. -dgm

i was assuming that the callback would be executed so that it was passed the audio frame at which the change occurs. my definition of callback: register_callback (function_to_be_called_when, when_to_call_it); the name "callback" is based on a style of telephone interaction: no callbacks: Paul: hi David, is audiality is available? David: its not. with callbacks: Paul: hi David, please call me back at +1 610-667-4807 when audiality is available. [ ... time passes ... ] [ ... david calls ... ] David: its available. or alternatively: David: it will be available in 5 minutes. --p

On Sunday 15 December 2002 07.24, Tim Hockin wrote: [...] Yes... It's just that it's not very useful if you get a tempo change before that tick. How is the host supposed to know what to do? It doesn't know what you're doing, so there's no single correct answer. This won't work, since you can't check an event queue that you do not own, without a whole set of special macros. The normal event handling is based on the idea that events you read are meant for *you*, and that you're supposed to reuse or dispose of the structs once you've handled the events. Besides, if you somehow read these events from some global queue, you'll have to copy and sort/merge them into your real event queue anyway, or you wouldn't be able to handle timeline events with sample accurate timing. I strongly believe that plugins should never be *forced* to do this sort of stuff. (The sort/merge function might be a nice thing to make public, though, since plugins can make use of it internally for other reasons. It's just a tool.) Well, I think the most elegant solution is to base this on the standard event + control layer, as far as possible. Anything else will just result in more special cases and more restrictions (or more complexity), for no advantage. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 18 December 2002 01.25, Tim Hockin wrote: Yeah, you're right. Doesn't work for *position* changes, though, which is what I was really thinking about. If it turns out that you just missed the event, should it be thrown away, kept indefinitely, adjusted to the start of the current block, or quantized to the first beat (or whatever) in the current block, or later blocks, or what? I guess you could set up callbacks that let you decide... No way! :-) It's 1920 (or an even bigger "magic" number), and there's no need to ever change it. Sounds like great fun in conjunction with sorted, linked lists of events. :-) Sure, it's possible to do this with or without refcounts. (Refcounts would be overkill in this case.) Still doesn't reduce overhead in any way for most plugins. Nope, only the ones with rather weird internals. Most plugins will just have one event queue for each Channel - and that means you get timeline events right into each Queue. However, if you don't want to support independent timelines for Channels, you can just make your timeline controls master controls, and do whatever you like internally. Hmm... Yes. What *are* they, actually? Do we need type hints as well as other hints? Multiple hints per control? Either way, *datatype* is hard, and simply must be there. The few timeline events that don't fit in will have their own types. These events aren't really usable as normal controls anyway, so it doesn't really matter. All the host has to do is check type compatibility (input->type == output->type) and then connect as usual. Only Audio ports are special, and that's just because their buffers are managed directly by the host. Some catching up to do...? ;-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

Tim Hockin wrote: ticks/sec (float) is much more convenient. for one thing, you don't have to send both tempo and meter when only one the meter changes. ticks/sec also happens to play the central role in time/tick conversion. no way. this is an arbitrary value, and there's absolutely no need for it. some sequencer authors may already have their own preference here. why make things difficult for them? please read some more sequencer source code before you make any assumptions here. this stance is exactly what made me make a fool of myself with the initial polemic. let the user/sequencer combination control this value. oh and btw: 1920 is not divisible by 9, which is more common than a division by 10 in music. rhythmn *is* integral by nature. floats complicate this a lot for absolutely no good reason. please, please, please, ask your favourite musician friends. read good books about it. listen to indian, jazz, techno, blues, classical western, classical indian, japanese, rap, whatever music: rhythmn is integral. if you think you really need this, please remember that this is how plugins, ie. algorithms implemented on a machine with a finite computing precision see the meter. it does not say anything about how musical time is presented to the user. the meter information has to convey: the relation of the denominator to what you call TIMEBASE above, and the nominator. for tempo, bpm (quarter notes/minute) seems the convention in user interaction. as has been said, ticks/second seems to be the most practical value to communicate. tim

David Olofson wrote: [TIMEBASE, aka ppq] the only thing i object to is that you want to assign a fixed value. it is a severe limitation, but it gains us absolutely nothing. at least you don't give a reason why it needs to be fixed. all of them. rhythmn is always based on one integral periodic 'pulse'. if time is not divisible by this atom, there is no musical time. the float meter proposal is like using floats to count your fingers. if you shorten, for example, 4/4 by 1/16, it's 15/16. if you shorten it by 1/32, it's 31/32 etc. if you want to shorten 4/4 by, say, 1/16 + 0.00212266328763, you're violating the very principle of the organization of musical time. you're better off simply inserting a new meter where the shortened measure ends. and what seems to be the problem with beat sync? the relation of the meter to TIMEBASE is part of the tempo information, so all info you need, you have. * again, i strongly recommend you do some research on music and its theory and then round off your studies with some sequencer implementation reading, or even better, writing. please excuse the harsh word: your assumptions about these fields lack in realism. tim

David Olofson wrote: for the timeline, not from. it is constant throughout in a sane system. which? i'll remind you that 9.5 = 19 / 2 -- that doesn't prove me wrong. it is not theoretical. it is the practical foundation of musical time. why should it? it knows what time unit it is synced to, doesn't it? at least that usually is one of its prime parameters. this method works better: not at all. but you don't have to complete the current measure to put in a new meter, do you? it's just a way to count the passage of time, it's not time itself. there is no *real* beat value. if your arpeggiator starts emitting 8th notes when switching to 4/4 from 7/8, i'd say there's something wrong with it. anytime you introduce a new meter, you introduce a new "one" beat. your plugin absolutely needs to sync to that, right? and there's no *real* beat value because in the case you mention, you explicitly destroy musical time periodicity. please put them here; i honestly don't know which questions you are referring to. i would love to have more musicians actively participate in this list but there seem to be few. they are simply not adequate in this context. tim

Steve Harris wrote: indeed. it seems there are few who have built a solid theoretical foundation though, and that doesn't mean western music theory only. not expressive enough for fractions, for one thing. for technical reasons, you should prefer int i think. for artistic reasons, well you can't argue with that. if you get a chance to, do some experiments with non-integral organization of musical time. i'm dead certain you'll never want to go there a second time. tim

Steve Harris wrote: allow me to come to the gist without replying specifically: since almost everybody here is for float meters, let's do it this way. there doesn't seem to be much point in discussing this any further. tim

On Wednesday 18 December 2002 16.06, Tim Goetze wrote: [...] Yes, of course. I didn't mean so suggest that it can change while playing or anything. Well, that would be David Gerard Matthews, IIRC. Well, that doesn't make x == x / 2. (Unless x == 0, but that's irrelevant, of course.) You keep saying that. It may be practical most of the time, but what makes it the only correct representation? Yes, but if you specify it as "1 beat", it will look at the meter, and then *boom* - incorrect results...! So, meters are basically timstamped, short fragments of defined time placed arbitrarily along the timeline? Sounds a *lot* messier than just assuming that the next one starts where the current one ends, and allowing any lengths. Not if you *specifically* tell it to interpret the parameter as related to the beat value, rather than a specific note value. Obviously, that's a feature you *could* live without, but it still serves to demonstrate that the whole meter has a *musical meaning* - it's not just a messy way of defining the length of one bar. Yes - just like it locks to musical time, whatever the meter may be. The point is just that the plugin should be able to *understand* the meter as it was indended by the composer - or, plugins should not have access to the full meter information in the first place, since it becomes essentially musically irrelevant. Ever heard a "break" (as they call it in pop music) in a shortened bar? The "breaking" of the periodicity is sometimes *intentional*, and often so subtle that you can't reasonably "count" to deal with it. 63/64ths...? You've probably also failed to notice a rather popular "trick" used back in the disco era was to lag behind over the measure, for that "push" feel of the one beat. (Yeah, it has a name too, but I can't seem to remember it, being totally illiterate when it comes to music, and all...) Well, maybe tempo modulation would be more correct - I can't say for sure. This belongs in that gray zone "slip" between traditional notation and actual music, that sequencer folks seem to assume you should simply ignore, unless you're dealing with "real" instruments and real musicians. Well, sorry if I just missed it, but I'm still waiting for an explanation as to why non-integer meters automatically result in sequencer/plugin sync issues. In general, it seems that we're not getting anywhere here, since, for some reason, at some point, you end up countering with more or less irrelevant arguments, instead of explaining the real issues. You have repeatedly attacked my lack of experience, lack of musical training and whatnot, instead of my technical arguments. As a result, my impression is that you're sometimes more interested in defending your traditional theory based standpoint, than in discussing technical matters of the XAP API. I'm here to participate in the creation of a plugin API. I'm much more interested in serious arguments than in being personally attacked for having the wrong view, or whatever this is about. Why? Counting in ticks, you can handle these subdivisions without rounding errors. Then it doesn't really matter if they represent integer *beats* and *note values*, since they're still integer numbers. So, to eliminate the only non-political difference between the two: beats/measure: 1920/beat beat value: 1920ths That is, fixed point. (Bigger and "better" values could be used.) This prevents you from accidentaly generating a meter that contains rounding errors. Please, counter this with *technical* arguments, or don't bother. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 18 December 2002 18.20, Tim Goetze wrote: [...] Well, that's a point - but I think we should leave that part to the user. The API isn't supposed to create the music! :-) There is a reason. My disco reference below would be one example. Two? That's not what I meant. Either way, the problem with this is that the plugin doesn't know where a measure ends before it gets the new one. That makes it pretty hard to do any useful beat sync processing, since you never know the length of a beat for sure. [...] I'm not talking about AI - just that if you want 4/4 shortened just slightly, you should still be able to have simple beat sync plugins understand that you still want 4 beats, not 15 or 31 or whatever. Yeah, great... It's been explained as playing straight 4/4 at a slightly lower tempo than the duration of one measure would indicate. I would interpret that as the last "4th" being slightly shorter than the first 3, since the next measure starts early. No, that's probably rather what I assumed your claims about precision issues would be related to, since I'm still not seeing where you could go "wrong enough that it matters", as long as you base your calculations on the tick where the meter starts. I'm basically looking for actual examples of when you end up doing the wrong thing, because you have an inexact meter, such as 4.3/4 expressed as 4.3/3.0 - especially if, as you suggest later, meters are placed at explicit points along the timeline. Could a meter realistically make the measure long enough that you land more than a very small fraction of a sample away from where the sequencer thinks the measure ends? Well, you have interesting ways of making a point at a time, but no serious offense taken. :-) And indeed, it can't hurt to consider all aspects and verify all claims before throwing stuff into an API. Especially with unusual solutions where we don't have a lot of existing implementations to learn from. It's not all that fun to correct mistakes after the API is finalized... Right, but consider these two: 1. (3+1/3)/4. Expressed in the units I suggested before (if I got it right, that is), it's 6400/7680. A beat is 1920/7680, and a measure is 6400/1920 beats. Indeed, values like 1/7 won't give nice exact results, but how close do you have to get? 274/1920 is rather close. 2. Musical time is expressed as 1920 ticks per *beat*, and tempo as beats/minute (or beats/second, maybe). This means that the beat value has only one real function: It defines the relation between beat values of meters. It's the value you multiply the typical QN/minute "BMP" with to get the XAP tempo. What you see outside the sequencer is simply a tick counter that counts to 1920 for each whole beat. In the (3+1/3)/4 example, a new measure will start every 6400 ticks. Tempo is <whatever>*1920/7680. So, how about just rounding the meter values so you always have an integer number of ticks per measure? (Not that I'm sure I see any point in it.) However, I'm also interested in finding out whether the sequencer's "new measure starts now" event would be sufficient for ensuring sync when *not* rounding. After all, you don't know what the next measure will look like, so you can't assume anything about it until you actually get the event - and then you know where the sequencer believes the measure starts. Since measures can be of different length, you can't just divide the song position with it, so you have to base your calculations on where the measure actually starts anyway. //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 -' --- http://olofson.net --- http://www.reologica.se ---

Well, actually, it is still plausible with integer values, we just ened to look at meter somewhat differently. a 4/4 measure has 4 steps, one beat is one step (we know bpm and timebase) a 3.5/4 measure has 7 steps, one beat is 2 steps a 3.95/4 measure has 395 steps, one beat is 40 steps This doesn't much relate to 'meter' in the traditional sense. It does allow you to use integral numbers and have your beat-sync still work. Is that worthwhile? I don't know. Do we want the user to enter '3.95 beats' or '395 ubeats'? It CAN work, is what Tim (the other) is saying. Does integral values buy us anything? 63 ubeats per bar, a beat is 16 ubeats But what does that buy us?

Steve Harris wrote: it is with african music for all i know, and with steve reich's music, it is simply many, but still integral, rhythmns at the same time. more examples? just as there's good reasons to represent things like 1/3 with fractions, right? tim

Steve Harris wrote: reich started, afaik, with tapes running out of sync. but it's a tempo thing with him, not meter -- his music is very much tied to integral meters. tim

On Wednesday 18 December 2002 10.18, Tim Hockin wrote: Or just one API that keeps some data you hand it, and lets you reevaluate prequeued events when needed? (See my previous reply on handling this.) Right. I think what has been discussed so far is best done in the SDK, though. Instead of the host, you'd talk to a private "object" that has a process() call you call first thing for every block. All info required is in your input event queues anyway. In fact, the host does *not* have access to this info in any obvious way (would have to eavesdrop to get it), so this really belongs in the plugin. Yeah... Yeah, but why not float? (Right, it's just a nominal sample rate, but anyway...) Why not ticks/second, to avoid scaling when applying to position? Yep. Yes. Or a third option: Two floats. Beats/measure expressed as ticks/measure (multiply with 1920, that is). Note value expressed as length in ticks. No, must be double. float isn't accurate enough for more than a few minutes. (Just 24 bits, and that corresponds to 5.8 minutes of counting samples at 48 kHz. Then you lose the first low bit...) I think thansport position and transport start/stop should be kept separate, to avoid the special case handling. Remember that extra event actions don't cost anything extra to decode. The switch() is just a single LUT anyway. It might be interesting to explicitly tell plugins whether a transport change is because of a jump, or if it's just a resync. OTOH, what matters is the delta, and that's plugin dependent. Just check the delta if you're interested. (Even a resync can result in a skip of several samples, if the sequencer is syncing with something external! It's better done with tempo adjustments, though, but that's a sequencer implementation decision.) We never know what beat or measure lengths people will use, so in's probably better to just send periodic resync approximately once per second or something like that. I would also recommend that resync is sent directly after tempo changes and tempo ramps. (Especially if we allow spline ramping of the tempo control...) Here are the time domains represented in VST's time info: Domain Our unit ------------------------------------------- Audio time (samples) System time (seconds?) Musical time (ticks; 1920/beat) SMPTE time (frames) MIDI clock (clocks at 24 ppq) Not sure what the point is with the last one, though. Provided your sequencer is driven my external MIDI clock, this should be equivalent to Musical Time anyway. Otherwise, if there's no MIDI clock input, this would be undefined. The "raw" MIDI clock that drives the sequencer? Would that apply to SMPTE time as well; ie do you want the SMPTE time as is, or as reconstructed by the sequencer after it's "sync filter"? No QNs, please... A beat can be anything, and then QNs are irrelevant. No rounding errors. :-) Yeah. I think we basically have the conversion API left to do. There are some details for which I don't see obvious solutions right now. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 18 December 2002 14.12, Paul Davis wrote: [...] I've been thinking about this particular issue. (HDR + loops.) Well, one loop is just fine for linear music editing, but what about interactive music? (The old, primitive approach, based on conditional jumps.) I was thinking one could generalize this by using N cue points (abstract objects) instead of hardcoded loop markers in the time info. Tell timeline aware plugins about them by sending events looking something like this: XAP_A_CUE_POINT int id; double position; The 'id' field is for referencing the point, so it can be changed in a reliable fashion. BTW, applications may use one cue point to track the play cursor when the sequencer is stopped, to reduce the start delay. (Prebuffering would be done while you're moving around, so some or all of it is already done when you hit "play".) This makes me think of another feature we need for anything that needs to prequeue data from some background thread or something: "Busy." A HDR just won't be able to start playback instantly, and it would be rather useful if the host could tell, and deal with it. (The alternative would be for such plugins to block or something. Very nasty...) Can't think of any nice way that doesn't require at least one block/cycle for the sequencer/timeline to find out whether plugins are ready or not. Maybe that's not an issue? As soon as you have that kind of plugins, you *will* have "random" start latency anyway... //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 19 December 2002 06.40, Tim Hockin wrote: The transport/sequencer does. Whether it's part of the host or not is another matter. :-) Any time a cue point is moved, basically. Obviously, though, there's not much point in continously tracking the playback position with a cue point when *playing*. You do that only when you're *not* playing, so plugins that need to have some extra time before you hit *play*. Then again, provided the transport position tracks the play position marker at all times (playing or not), there's no real need for a special cue point. Plugins get the information they need anyway. Yes. Nope, that could be too late. If you want to be totally certain that everyone is ready, you simply have to wait until all plugins have "1" on their READY outputs, after changing any cue points. If you don't there can be no guarantees. This is pretty much the same thing as in Linuxsampler: Before you've precached all starting points, there are no guarantees. Just because the starting points are ready, you can't start playing until the loop points have been cached as well, as there's no guarantee that the butler will have them ready in time for the first loop. Not only a nice optimization, but an absolute requirement to handle more than one "zero-latency" cue point together with HDR. I think the semanticts can be made very clear and simple without much trouble. Now I have a guestion for people with more hands-on experience with HDR and looping: Do you really need anything more than the loop start cue point? What is the loop end info for? (Paul?) I suspect that the idea is to avoid having to actually keep data for all cue points in memory at all times. (That can be a whole lot of data!) If you have both start and end info, you don't really have to precache, but can basically just move the disk read point to the start of the loop once it passes the end of the loop. (Obviously, you can't wait for the timeline to tell you "loop!", unless you keep the data for the loop start in memory at all times.) My conclusion: The two loop markers are not exactly the same thing as N "Zero Latency Cue Points". Looping is really *looping*, while "ZLCPs" are more similar to direct-from-disk sample playback. Both can be very useful, but they're not equivalent. Obviously, you *can* use a ZLCP instead of a loop start-end pair, but it's a waste of memory if you have only one, non-conditional loop. The advantage with ZLCPs is that you can jump to them at any time for instant playback, and you don't *really* need that for a single loop. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 19 December 2002 17.12, Frank van de Pol wrote: [...] Well, your question indicates that "cue point" is not the right term for this thing. The "objects" I'm talking about are "Zero Latency Start Points" or "Precache Points". The whole point with them is to let plugins know about jump target points that the sequencer wants to be able to jump to at any time, without disrupting playback. The most obvious example of this would be conditional looping. (Which is actually what any HDR or sequencer with a loop feature has!) If you have a loop active, a HDR would know about the loop end, and have the disk thread skip to the loop start when the end is passed. All is fine, and the looping will work great. However, if the user turns looping off just before the loop end, you're in deep sh*t! Your HDR has been reading from the start of the loop, maybe for *seconds* - while the sequencer is just about to pass the now disable loop end mark... All you can do is stall (and lose sync) or just let the HDR go silent until it catches up. If you instead put a Pre-Cache Point (PCP?) at the loop start, the HDR will keep that data in memory at all times, and thus, will be ready to instantly start playing from that position at any time. So, maybe the loop start + end approach isn't all that smart, after all...? Although PCPs do waste more memory, they make the applications a whole lot more interactive. Yes, and you can easilly have a sequencer do either. (That's what the READY control output is for.) But why not just have instant playback whenever possible? Yes, but that sort of jitter is just a result of using the wrong tool for the job, or using the right tool incorrectly. It is IMPOSSIBLE to have instant playback directly from disk. You MUST precache. That's what Gigaspampler, Linuxsampler/EVO and co does, and it's the only way to do it, short of simply loading all data into RAM before starting playback. I give you three alternatives: 1. Ignore READY and just play. As far as realistically possible, samplers and HDRs will start playing at the right position when they catch up. 2. Use READY and wait until the plugins are ready. 3. Tell your samplers to load the sounds you need, and give the HDR PCPs for any points in a sequence that you need to be able to jump to instantly. Wait until they all are ready. Now, you can play sounds and jump to any of the PCPs without drop-out, delays or other artifacts. Just pick what works best for each situation. All methods can be used at the same time in the same net. (Just disconnect the READY and/or PCP controls for the plugins you don't want to prepare or care about.) That's virtually impossible. The best you can have is a way for plugins to indicate approximately how long they need to precache for a PCP. Full RT plugins will just say 0, or just not have PCP inputs. Of course - but how do you do it for a HDR...? These are two related, but slightly different problems. Of course. Just disconnect the READY output from the sampler, or disable the "wait for ready" feature altogether in the sequencer. The READY feature is *optional*. [...] Yes. You can do that with PCPs. Either have plugins suggest a worst case latency, or just tell the sequencer to assume something reasonable. Or you can pass the PCPs at "load time" and wait until all plugins are ready before you start playing. Yes. You could add, move or remove PCPs at any time, although there is obviously no way of eliminating the underlying problem: the need for substantial buffering when reading from disk. It doesn't need to "register" explicitly; just say that it supports PCPs. It could have a READY output for situations where accurate playback is more important than start delay (when you're recording songs to disk, for example), and it could have some interface for "expected PCP setup latency". Yes. Just use PCPs. (I've realized that start + end markers are only half a solution.) If you're not all that worried about the user moving the loop markers at the wrong time, you could still use loop start + end, and just watch out for "time info changed!" notification events. (Since that's where the loop points would be found.) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 19 December 2002 18.37, Frank van de Pol wrote: Looping with a hard disk recorder would be a nice example. As I explained, though, loop start + end depends on the user not changing his/her mind too late, or too often. If you start toggling the looping on and off before the loop ends, you'll most likely not get proper playback whether looping is on or off when the end is passed! With a PCP at the loop start, the HDR will just ignore your fooling around with the looping switch, and just play all the way to the loop end. Then, if looping is enabled when the end marker is hit, it just starts playing from the PCP cache. If looping is disabled, it just keeps playing. Yeah, that's the idea with having most controls using the same protocol and datatypes, basically. What I'm envisionning is a system where the Control hints allows the host to let users work on two levels: Cables and Wires. If you connect a Cable from an output Channel of one plugin to an input Channel of another, the host looks at the hints, and tries to hook up everything that fits together. PITCH->PITCH, VELOCITY->VELOCITY etc. This is for your average user, thinking in terms of MIDI and monolith synths. Now, if you want to do something unusual, just open up a Cable and you can cut and reroute Wires in any way you like. This is probably where modular synth folks will spend most of their time with connections. (If they bother to use a host with the Cable abstraction at all, that is. *This* is basically the real nature of 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 -' --- http://olofson.net --- http://www.reologica.se ---

On Friday 20 December 2002 02.58, Tim Hockin wrote: Yes. Yes, that's what they are. A synth would not care about PCPs at all, unless it's actually a "vocaliser" that's generating backing harmonies from a HDR vocal track or something like that. (And then, the data would probably come from the HDR anyway. The "vocalizer" is just an audio effect, and doesn't even need basic beat sync.) Yes, but that's a different problem entirely. Synths can't do this anyway, unless they have integrated sequencers. Right. A synth should (probably) never have PCP support, since it can't do anything useful with it anyway. The purpose with the PCP interface is simply to have a standard protocol for the timeline/prebuffering stuff. The alternative would be to enforce that timeline and transport are part of the HDR, and that sequencers always slave to HDRs. That way, a HDR can implement this stuff internally - but obvisously, you can't make this work with more than one "unit" of this kind in the system. Also, it might be a bit weird to have to load part of your song (the timeline) into the HDR, and the rest into the sequencer... No, PCPs and the proposed SEEK control solve two different problems. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wed, Dec 18, 2002 at 01:18:24AM -0800, Tim Hockin wrote: ... Do I understand correctly that the engine state (Stopped, Running, Pause etc.) is send to the plugings ising the TRANSPORT control? In fact a Pause state is not needed if a control is available to indicate shuttle speed/direction (eg. a float; 0.0 if in pause; 1.0 if normally running; >1.0 for fast forward; negative for reverse scrubbing etc. This makes the plugins aware of varispeed and shuttling from the host. just a thought. Frank. -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol(a)home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?

On Wed, Dec 18, 2002 at 11:35:08PM +0100, David Olofson wrote: I was thinking of Pause like on my tape deck; Of course this could also be called freeze, or like midi stop/continue yes, that is the idea. In fact some plugins would indeed play the sound backward (eg. scrubbing over a sample...), depends on the plugin :-) this SPEED control allows the plugins to anticipate to the POSITION change events or discontinious position passed for the block to be processed. Fast forwarding without SPEED hint would result in fast skipping (like seeking on a mini disk deck); a slowdown would be euh, also result in repositioning, but nudging a bit back every block. Frank -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol(a)home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?

Sounds sane - and that implies negative tempo? It's scary, but I guess correct... Do we really want to deal with playing during shuttles? The sequencer needs to send reversed ON/OFF events, but that's no big deal..

float. for all integer tempo/meter setups, we'll fit things with no rounding into the 24 bits of a float, yet we'll still allow for other things as well. nice! i'll change ardour to use this value immediately. i think that ticks/measure is a nice idea. combined with ticks/sec for tempo, you can compute everything you need. however, i don't see how you can derive the actual western A/B form from just this information, and this might be necessary for some purposes. i think that having multiple methods to ask about "current" time is a mistake. i think that VST's approach is better: have a single function that retrieves all the information (actually, in VST, you set a bitfield to specify which information you want). the host doesn't compute anything till the first call to the function (by a plugin), thereafter, it uses the precomputed value of the struct that holds the data. thus: typedef struct __xap_timeinfo { ... somewhat like VST ... } XAP_timeinfo; XAP_timeinfo* time; time = host->get_timeinfo(... possible bits ...); that seems entirely correct to me, but then i'm not a musician. when i've asked my musician friends, i get two responses. the rock/pop people are used to 1 beat = quarter note and tempo = quarters-per-minute. the classical folks are more experienced with tempo being denoted in beats-per-minute, and found the idea of it being forced to be quarters-per-minute rather odd. so you'd have two different responses to this. the classical people i know would find this sensible; the rock/pop people might find it odd that the tempo continues to be N of some unit, yet the apparent tempo has changed (because they aren't used to the idea that the unit of tempo is a beat, not a quarter note). i would agree with this. i think its a very sensible idea. --p

On Thursday 19 December 2002 23.51, Tim Hockin wrote: [...] Do you actually need the beat value for anything on this level? Remember that tempo and position are based on the *beat*, rather than on a fixed note value, so you don't need the beat value to know what one beat is in terms of musical time. One beat is N ticks. If the measure isn't an integer number of beats, that just means the last beat will be "cut off". If you're using 3.5/4 and 1920 ticks/beat, the first measure will start at 0, and the next measure will start at 3.5 * 1920 = 6720. That is, the last beat is only 960 ticks. The only case I can think of when you need to know the beat value is when dealing with changes from one beat value to another. The beat value is effectively the relation between "absolute musical speed" and our TEMPO, which is expressed as actual beats/<time unit>. [...] Just remember that the returned data is essentially invalid if you ask for a time beyond the end of the current block. It is little more than a hint about the future. Right. Either it's a value in the time info, or it's a timestamped event. I believe the latter is the right way to do it, as start/stop isn't strictyly bound to measures, musical time or block cycles. When you're sync'ing with an external device, there is nothing that prevents transport start/stop events (or jumps, for that matter) from occuring at any point - including in the middle of a block. I'm worried about sync/lock issues if start/stop is treated as something totally different from position and tempo. [...] Mid-block TRANSPORT_STOP simply means that the timeline stopped moving in relation to audio time exactly at the point where you got the event. That's all. Yes, probably. The only case where it really matters is when you have beat sync effects - and then you can probably live with using two instances of a synth instead of one. (Though, you'd have to get an extra drive for something like Linuxsampler, unless you can make all instances share the same disk butler thread.) I think it *does* make sense mid-block. For example, if you want to start playback at a particular point in musical time, while the sequencer is on external sync (that is, transport control is external as well), you'll need better than block accurate timing for TRANSPORT_START, or you simply can't track external sync properly. [...] The only real reason to change this value is to avoid inexact values in some places. Given that there won't be many exact values in real calculations anyway (as soon as the audio rate gets involved), this matters only to the sequencer and some musical time aware plugins. So, it seems logical that it's the sequencer that decides what TIMEBASE to use - and it would have to do that based on the project you load. Yeah. Beat sync effects will need to get that information one way or another anyway. Yeah. It's just that HDRs tracking the play cursor and that kind of stuff is so commonly used that I think it makes sense to have the timeline work the same way. Besides, what use is the old song position when it will never be used again? I don't see a point in plugins keeping an irrelevant value just to merge two different kinds of information in one event. (To me, start/stop seems to be more closely related to TEMPO than to POSITION - but I don't think abusing TEMPO == 0 for stop is a good idea either.) [...] What do you do if you want to run a beat sync effect in real time, without a sequencer? Well, the best way would be to set up a "timeline generator". That would allow multiple beat sync effects to stay in sync with each other, and you'd get a nice, central interface to set the tempo and meter. So, yes, they might as well be considered special enough not to need default values, presets or anything. Then it's probably a better idea to use special events for them as well, not to have them handled by the same code that handles normal controls. I think it might be useful, but as I said; only when you want to know the relation between beat values in different meters. This could matter to some plugins in songs with meter changes. Well, if TEMPO uses a "special" event, it *cannot* be a normal float (or whatever) control, and thus it *must* be hinted as a different type, or the host wouldn't be able to make correct connections. I've never suggested that these events should be hinted as normal controls unless they really are 100% compatible in all respects. One event set <==> one event data type. Yes. Where? You'll always get the *actual* time and tempo info, whether it's caused by the sequencer being on SPEED ;-) or something else. Both. That's how you can ignore SPEED if you don't feel like implementing timestretching and stuff. [...] In the contrary, it would play the note without the offset, as it would look like just any note. That sounds sensible to me, though. (I'd *really* like MIDI sequencers to do that with strings and similar sounds, but there just isn't such a feature in most of them. "Controller seachback" is as close as you get.) Sequencers could have an option that lets the user decide when/if notes should be sent in these situations even if there's not SEEK control. That way, you have support for all three variants; skip "missed" notes, play them from the start, or play them from the right position. I definitely like this idea. No, it's a different problem entirely. To use cue points/PCPs/whatever for anything that relies on events from the sequencer, we would need an entirely different kind of interface between plugins and sequencers. The SEEK control, OTOH, would provide the information needed to get it right most of the time, though. (It doesn't work if you pitch bend samples. You'd need the full story behind the note do get that right.) They *could* be, but not if you have multiple timelines. Assuming that plugins can belong to different sub nets in this regard seems acceptable to me, though. It would have to be a list of events, rather than global variables. Otherwise, tempo changes, position jumps and the like would be restricted to block boundaries, and you couldn't have more than one change per block. The net result would be forcing hosts to perform global buffer splitting, as there would be no way to implement a correct host without it. Well, that's one way of doing it. The only problem is figuring out what actually needs to be calculated. The time info struct will contain musical time, SMPTE, MIDI clock and whatnot. Are you supposed to send TIMEINFO events for every update (new SMPTE frame, new MIDI tick), or once per beat, or once per measure, all of those, or when? Also, if you can send these events for more than one reason, plugins would have to be able to tell the difference, or they'd have to check all data in the time info struct to know what's happened. Multiple events would be the most efficient way (no extra level of conditionals for decoding), but then we're almost back at square one, only with a less efficient interface. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 23 December 2002 09.00, Tim Hockin wrote: If you're sync'ing with beats or measures, you're fine. But if you're doing it the traditional way - sync'ing with a note value - you'll need to know what one beat actually is. Then you'll need the beat value as well. [...] Yes. It doesn't really change anything - and the selection of a suitable queue is still something that belongs in the plugin implementation. (Most simple plugins will want a single queue, since otherwise, they'll just have to merge the incoming queues anyway.) I think treating these "event sets" as event types of their own is the cleanest approach. It means there are no special cases; they're just another "control" type, and can be connected as normal Controls. You could consider them a different Port type as well, but they're not *that* different from controls. Control Ports have abstract ports and are accessed through events. Audio Ports have buffer pointers. Different connection APIs. Do we need a third kind that is physically identical to the Control API? Yes indeed. Yeah... I read the ALSA driver writing HOWTO, started working on the new XAP logo and fixed some stuff in Audiality. Though I still haven't figured out what that subtle clicking when looping in cubic interpolation mode is coming from. *Must* be the "first sample" special case in the mixer, but I can't seem to figure out what's wrong with it. :-( (BTW, does anyone know if h/w synths and samplers do this, or if they just let the interpolation delay the output?) Oh, and then I've been trying to build some MIDI sequencers, but Jazz requires some ancient version of wxWindows that's no longer available for download, and midimountain won't build with GTK 1.2.9, and GTK 2.0.x refuses to build with 1.2.9 installed. And MusE can't tell controls in MIDI files from notes. I just need a simple, basic MIDI file editor, but it seems like nothing will work without hacking... seq24 builds just fine BTW, but it doesn't seem to be the right kind of tool for what I need to do. Well, that's a weekend off for me! ;-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 23 December 2002 18.58, Tim Hockin wrote: Actually, the *beat* based approach is purely theoretical. These kinds of things (as implemented in h/w synths at leat) usually talk about note values; not "fractions of a beat". Yeah. It seems like beat based timing is generally more useful, so there might not be much point in using the traditional method at all... Yeah... Macros? (Like for your average float control...) The good part is that the host doesn't have to do anything special about it. Not much, really. If you have a "timeline generator" in the net, it's going to have a bunch of outputs of types corresponding to the timeline inputs of plugins that want timeline events. This is just like the "Cable/Wire" approach; the host will look for matching inputs and outputs and connect them. Doesn't matter what types they are, as long as they're the same. In the sender, you have something like this somewhere: if(me->outputs[OUTPUT_TEMPO].queue) { XAP_event *e = xap_event_alloc(me->host); if(!e) ...; e->target = me->outputs[OUTPUT_TEMPO].cookie; e->... = ...; ... xap_event_send(e, me->outputs[OUTPUT_TEMPO].queue); } And in the receiver: switch(e->action) { ... case XAP_A_TEMPO: ...handle tempo change... break; ... } Connection is still done with the usual "get cookie + queue and tell the sender to connect it's output to it" approach. The host never cares what events are used. Well, they *are* of different types, so why should they have defaults, ranges etc at all? Each control type has it's own struct for this anyway, right? Yes, that could be one way. These "things" have to be strictly standardized anyway, so there's no real need for dragging any metadata around. Only the type field is needed, basically. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 24 December 2002 00.28, Tim Hockin wrote: [...] Yes, if we assume that a plugin can only be aware of one timeline at a time. Probably not a major restriction. No, the latter two are *per-voice* - although that basically just means they take a VVID argument as well. (Speaking of which, I implemented a VVID manager for Audiality the other day. "Finished and tested", although I haven't integrated it yet.) How many fields can actually be eliminated? Can't be many bytes, and there aren't all that many of these controls. I can't see that it's worth any special casing to save a few fields per "magic control". Why? It should be enough to give them datatype codes of their own, so no one will get the idea that they're compatible with anything else. In what way? Indeed, the relation between TEMPO and POSITION is a bit "odd", but other than that, they're basically just controls used by the timeline to express musical time. There should be no special "MIDI compatible" controls at all, IMHO, but rather just a standard set of hints. The motivation for those is really just this "Cable" idea of hosts connecting ranges of controls automatically. PITCH->PITCH, VELOCITY->VELOCITY etc. MIDI drivers/converters would just map MIDI CCs to suitable Controls in the way suggested by the Control hint names. We could have an official MIDI CC -> Control mapping, if desired, but no actual references to MIDI in the API. Well, I still think the cleanest way would be to use the Control metadata stuff, giving the timeline controls datatype IDs of their own. No hints needed, I think, as ranges, semantics etc would be strictly specified in the API anyway. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 24 December 2002 03.57, Tim Hockin wrote: Well, I don't know when Audiality 0.1.1 will be ready for release, so I just put the files here for now: http://olofson.net/download/ (a_vvid.[ch]) Not very sophisticated, but it should work, I think. (Or I'll just have to fix it when I get around to actually use it, obviously. :-) The actual mapping/translation still has to be done somewhere, though, so I don't think there's much point in dictating much in the API. There will be some "official" MIDI->event converter, I guess, but I think it's more important to worry about what we want for the new API, than worrying about MIDI legacy. We have a slightly different way of controlling things, and thus, MIDI CC can't map 1:1 to our Controls. I don't think it's useful to impose MIDI related restrictions upon the API, since there's probably no single "correct" mapping that will work for everything anyway. In short, we should have our own set of "standard controls", with sensible units. Mapping MIDI to that is more of an implementational issue, IMHO. I'm not sure. We could *suggest* that they're similar to certain MIDI controllers, but I think we're going down the legacy route as soon as we start imposing "arbitrary" limitations upon ranges and units to make MIDI->control mapping closer to 1:1. I don't think the host should be aware of the existence of MIDI. It's a driver/translator thing. The MIDI driver/converter would have hinted outputs, and *those* are what the host should look at - if it cares to support "Cables" at all. What MIDI events the driver/converter maps to which Control outputs is an implementational issue, rather than something that should be strictly specified in the API. (And in fact, I don't think it should be all that strict either way. In my experience, fixed MIDI CC mappings are nothing but a PITA if you have controllers that aren't fully programmable.) [...macros...] Yes, something like that. Maybe they should just have the ranges and all - or perhaps it's better to make them more "opaque" to hosts that don't want to care about the details. What I'm thinking is that hosts should be able to figure out whether an input is compatible with an output without having to understand every aspect of the datatype. (That's the problem with hints + range; if range isn't implicit, the host will have to check...) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 19 December 2002 07.09, Tim Hockin wrote: Constant for the sequencer at least, I think. (As to GUI level sequencing, it's usually fixed per song, and you have to do a destructive conversion of the file to change it. This is because the timestamps are usually integers, just like in MIDI files.) Integer value, at least. Actual format doesn't matter much, since you won't see many of these events. (That is, int->float conversion cost can be ignored.) Yeah. Could use any "magic" value. "Bigger is better", as long as the number itself doesn't take too many bits in the mantissa. Yep. However, is it assumed that plugins should always count meter relative time from where the last METER event was received? I guess that would be the simplest and "safest" way, although it *does* reduce musical time accuracy to the sample accuracy level. "So what?", you say; "We have only sample accurate timing anyway." Yes - but the METER event is the *base* of your musical time calculations from the point you receive the event. That is, this rounding error adds up with the ones you get in your internal calculations. You could end up a sample off occasionally because of this. So, it might be nice if we could squeeze in a field specifying more exactly when the meter actually starts. Think of it as the fraction bits of the event timestamp. I think we need a special event, since otherwise you can't move the transport position when the transport is stopped. (See my post on cue points.) Provided the *host* knows anything about that. I think it's a rather serious restriction to assume that, since the rest is implicitly capable of handling timelines on a per-Channel basis. I'd suggest doing the "host forwards callbacks to timeline manager" thing I proposed. That's just an integer argument for the calls above. Or we use a single pointer to a XAP_timeline struct, which contains the callback pointers above. Maybe both. As mentioned before, they're not *exactly* the same thing. Yes... That would mean going back to assuming that QNs (or whatever) are special. If you're not using QNs as the beat value, why would you really want to specify the tempo as QNs/second or something? (Sequencers genarally do, but that's rather a UI + conventions issue. We're talking about the API now.) TEMPO is not special in any way, and nor is transport start/stop. Both *can* be normal controls. If they're not, they'll require special case handling in hosts for defaults and preset handling. I don't like the idea of making them plugin global, but that's basically just a matter of how different from normal controls you want to make them. Yes. (METER would be two controls.) Yeah. Cue points are really N abstract objects, more like voices. Guess you could actually treat them as Voice Controls, but that would be abuse of the dimension of indexing that is voices. (There isn't one cue point per voice, but rather a bunch of them per timeline. That could be per Channel or per Plugin.) No need. Just have "1" for rolling an "0" for stopped. No, it's probably no big deal, but I'm not sure it really changes anything. Timeline generators and hosts still have to do hairy stuff to get it right, if it has anything to do with the host. I simply don't like the idea of blindly assuming that the host *is* the sequencer. It doesn't eliminate any special cases anyway; the timeline stuff still needs some "nonstandard" interfaces to work. Well, I don't think we can do much about that. Some of them can be ordinary controls, but some special events are hard to avoid. Either way, I think it's important to keep in mind that control != event. Events are just a transport layer for control data, and other stuff. Different datatypes already require different events. This applies to the timeline stuff as well, for the things that just don't fit in the normal datatypes. Indeed, this means you get more datatypes to deal with - but how different is that from a bunch of extra calls in the host struct, really? I'll try to wrap my version up and release it, in case you want the event handling macros or something. They're adapted from Audiality, and should be fully functional. Still need a nice sort/merge implementation for N queues into 1, though. (I haven't used that in Audiality so far.) No point in doing *everything* twice. :-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thu, Dec 19, 2002 at 02:41:47PM +0100, David Olofson wrote: True, the effective tempo is negative, but think the SPEED control should be decoupled. - the SPEED control also affects the effective sample rate (not the rate in the processing graph, but the rate at which the audio material is played). Depending on the plugin it can decide how to implement it, eg. resampling, pitch shifting, adjustment of LFO/envelope etc. - tempo is indeed influenced, to keep the model consitent with the sample stream and parameter values (for which only the plugin know what to do with in case of a change of SPEED, eg. LFO) - for plugins or hosts that do not support the SPEED, the repositioning events are still usefull without the additional hinting from the SPEED control. The SPEED only allows the plugins to generate usefull noise in case the user starts fiddling with it. - essential is that the relation between media time and musical time is not changed! The whole perception of time is influenced. A nice real-life example of use for this SPEED control is the pitch control function as seen on CD decks and turntables. The DJ uses this control to manualy obtain and maintain beat sync between sources. Modern CD decks perform the SPEED changes without influencing the pitch of the song. When running a MIDI sequencer or drum machine in beat sync with a record, the dj (actually a gear jockey :-) simply fiddles with the tempo control to keep every thing grooving. The SPEED control I proposed would provide the additional abstraction layer to allow the plugins to be smart enough to keep the sample and event streams running smoothly together. I have no clue how this would be beneficial to classical or indian style of music ;-) a plugin _could_ be in sync (of course depends on the plugin). Think of Sonic Foundry ACID. That is a in fact a sequencer which plays samples (looped or not), and performs real-time timestreching/pitch adjustment. The XAP API should certainly support a plugin with similar capabilities as ACID's playback/resampling engine. -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol(a)home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?

On Sunday 15 December 2002 06.23, Tim Hockin wrote: Well, my "guess" (not really) is that most plugins will need the audio timestamps, *even* when they deal with musical time. Whenever you actually need to *do* something, you'll need the audio timestamp, because that's effectively real time to you. You can't even tell if an event is within the current block, unless you convert one way or the other. I've considered that, but remember that musical time is absolute and non-wrapping. A float has only 24 bits of accuracy, so it will drop below sample accuracy rather quickly. My events look something like this, so far: typedef struct XAP_event { struct XAP_event *next; XAP_timestamp when; /* When to process */ XAP_ui32 action; /* What to do */ XAP_ui32 target; /* Target Cookie */ XAP_f32 value; /* Value/Ramp Target */ XAP_f32 slope; /* Ramp Target Slope */ XAP_ui32 count; /* Ramp Duration */ XAP_ui32 id; /* VVID */ } XAP_event; You'll need all these fields at once when sending control ramp events to voices, so unions won't help. The struct is exactly 32 bytes, so we're going to end up with 64 byte events if we add anything. On big deal, maybe. (64 bit platforms will need an extra 4 bytes for 'next' anyway.) More importantly, it would mean that everyone that sends events have to calculate *both* timestamps for every event. And what do you do if there is no timeline at all? 0.0? (That would make the timestamp useless, as described before.) Well, you do expect a beat synced effect to track the *beat*, right? Now, if you have two timelines running at different tempi, which one do you track? I'm not sure it's a good idea to ignore this, just because *most* people never do this sort of stuff. I've mentioned that it can be handy when creating soundscapes, and I'd guess there are more applications for it. So, if it doesn't complicate the API significantly, why not just do it right? [...] But telling a beat synced LFO what note value the beat is is ok? (Well, it can't be avoided.) You're forgetting that it's not the *host* that handles this. The host is not necessarily the sequencer, and thus, it may not even know what a timeline is. If you have the timeline interface in the host struct, who tells the host about the timeline...? Why special case it like this? Why not just have Control inputs named TEMPO, TRANSPORT and METER? Then you could also have plugins with corresponding outputs - or just build those outputs into the host, if you don't want to make the sequencer a real plugin. You don't need to request anything from anywhere; just say that you have TEMPO, TRANSPORT and/or METER control - input and/or output. Just as if they were ordinary controls. They need different event types, but that applies to string and raw data controls as well. And this just makes them easier to handle. Yes, but each plugin would be able to know about only one timeline. One may argue that this restriction doesn't matter much, but then again, we could just assume that no one uses multiple timelines at al. Where to draw the line? Anyway, if you throw these things in as normal controls, they become per-Channel for free. They're just ordinary connections, from the internals all the way up to the UI. If your plugin does not work without timeline input, it is broken. Your internal tempo will be 0.0, and your sound position will stand still at 0.0. You won't hear anything about TRANSPORT_START or TRANSPORT_STOP. No meter changes either, obviously. So what? Same things as if the sequencer is stopped. Have a default value for tempo, or something. (Just an f64 control...) Do you expect a synth to play anything but some default frequency, without pitch input? :-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 18 December 2002 00.53, Tim Hockin wrote: Yeah, it's no big deal, really. I'm just trying to streamline the interfaces for other reasons as well - and keeping the argument count to a minimum coincides with that. So, how do you suggest a plugin should know when to start...? In all sequencers I've seen so far, it's perfectly possible to start playback at any point on the timeline - which may well be in the middle of a beat. *That's* what locking deals with. (As well as making sure that you don't drift out of sync due to rounding errors or other issues.) A beat sync'ed arpeggiator. (Or it wouldn't be beat sync'ed! Just tempo sync'ed.) However, many beat sync effects may not receive any note events or similar events at all, so they definitely need their "trig" information from elsewhere - and that is the timeline. That applies only to a few special kind of effects, which basically all belong in the "tempo sync'ed delay" category. Beat sync is not the same thing as tempo sync. Yep, did so. Can probably give you some more, if you like. Well, then we'll have to implement 64 bit double controls - including ramping. And the tempo control could end up receiving non-linear ramps... I'm not sure this is a good idea. Also note that many plugins that deal with musical time will *still* have to special-case the tempo and position controls - which means you get an extra check for every control you receive, just to see if it's timeline related stuff. Finally, the meter is two floats (tempo has it's own event), and nothing like a normal Control event. We could use two float controls with ramping disabled, though. TRANSPORT_START/STOP don't need events of their own either. Those would be a single control where any non-zero value means "rolling!" (No interpolation.) Hmm... Ok, so the only special cases I have so far are: XAP_A_POSITION, /* Set new song position */ XAP_A_TIME_INFO, /* Time Info changed! */ The first is 64 bit double, while the other is just a notification event that you get in case of an unexpected modification in the current time info. (Or something. I have to think some more about the details here. Would like to avoid having plugins polling hysterically all the time...) Well, yes - they would just use the default values. Same applies to beat and tempo sync plugins. Just have default values for tempo and transport on/off, and start with POSITION at 0, and the plugin will effectively have it's own, free running timeline. //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 -' --- http://olofson.net --- http://www.reologica.se ---

me wrote: allow me to correct myself: there are in fact applications that need this (rhythmn-based audio delays). it is a very special case though. the idea i wanted to get understood is that plugins don't need to keep track of time and tempo. tim

On Sunday 15 December 2002 16.43, Tim Goetze wrote: Why? I don't see why you can't interpret "1.5" as being in between 1 and 2. Scales do not imply that there is no pitch bend, or continous pitch control. It doesn't to 12tET, and at least, my 1080 doesn't disable pitch bend if I tweak the scale... So, let's not have event processors that deal with basic, traditional theory...? I disagree. People will not want to implement simple arpeggiators and harmonizers that break down as soon as you tweak the 12tET scale a little. Do we *have* to force this sort of stuff (that even VST can do!) into another API? What knowledge would need to be in the API? No way! (Ok, I'm going there anyway, but that's besides the point. :-) 1.0/octave. Whatever NOTEPITCH becomes, I don't really give a damn - as long as the distinction is possible to make for those that care. Call it PITCH, and have an even "softer" hint (NOTE) somewhere else. Whatever. NOTEPITCH is *only* the exact same thing as PITCH when you're dealing with ET scales, and when you don't care about scales at all. You may think of both as 1.0/octave. The only difference is that *when* you have a scale converter anywhere, NOTEPITCH is what you have *before* the scale converter, and PITCH is what you have after it. If the scale is not ET, some event processors will *definitely* care which side you put them on, so I suggest it would be kind of nice if there was any way at all to tell what the plugin author intends. Ok, no beer for me! ;-) (Oops, there goes sample accurate timing when you don't have a sequencer...) How would you go about implementing an event delay effect? I'd really rather let plugins decide how they want to do it. Depending on what you're doing, and whether you're syncing or locking, there are many different answers - and by cutting off the notion of time from all plugins makes half of them impossible to implement. You can cheat internally in a plugin, but what do you do in an event processor? Unless *you* are sending timeline events to it, you can't even lie to it, so that it will accept your faked timestamps. Well, there *is* a relation between bars:beats and ticks, so you can always convert... This won't help if you're locking to an external device. (I'm sure Paul can explain this a lot better - I only seem to confuse people most of the time...) How does that allow you to *take back* what you did in earlier blocks? Again, consider a simple event delay plugin. Either way, I understand perfectly well that a sequencer cannot take back what it has sent down a MIDI cable. This is exactly the same thing. When events are placed on the event queues of other plugins, they are *gone* - there is nothing more you can do for that block. I certainly wouldn't want the API to depend on such limitations. Applications may do what they like, but thinking of block/cycle boundaries as anything more than the limits for the non-zero length time span that is "now", is not helpful in any way, if you want fully sample accurate timing. Except that musical time may stand still in relation to real time, but not the other way around. (Well, since "real" time is actually audio time, that *could* happen - but then no plugins will run anyway.) Yes - and that's why I want plugins to "breathe" in the time space that is least likely to freeze while plugins are still alive. Plugins can always translate one into the other, but they can't operate properly if the very reference they use for communication goes away. The argument about multiple timelines has very little to do with the argument about the timestamp format. I'm *not* arguing for audio timestamps because it would make multiple timelines easier. I'm arguing for audio timestamps, because I do not want plugins to have two different time domains forced upon them, especially not when stopping one of them prevents plugins from communicating properly. Yes, I agree. There is no strong motivation behind multiple timelines at all. If they're a problem, let's just not have them. You're missing my point. Tempo and transport events are nothing but an interface to the timeline. You may ask for the information through host calls or whatever - these are just *interfaces*. You're not required to sequencer every event in the network. How about event processors? You want them to send events *back* to the host, or what? Yes - if you think of time in terms of musical time only. It could be anywhere, but then you'd have to make a call somewhere every time you want a sample accurate version of it. I don't see how pretending that "real time" (audio time or whatever) is irrelevant makes this any easier. //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 -' --- http://olofson.net --- http://www.reologica.se ---

umm, I know that a requirement for me is to be able to stop the sequencer, and still play MIDI and have delay lines etc still delay. Are you saying that this can't be done in your model? In my opinion just because transport has stopped does NOT mean time has stopped. On the contrary, ticks are still happening, the tempo is still in effect. Just because the SEQUENCER stopped sending events doesn't mean the rest of the studio did. Perhaps it's the loud music last night (anyone ever sen S.U.N. Project - WOW!), but I just can't wrap my head around what you're arguing. Standing proposal: Host processes blocks of 'n' samples. Events are delivered with a timestamp that says 'actuate this event at this time within this buffer'. This is exactly what user-supplied automation is, totally randomly timed events. Some plugins need to sync to tempo or music-milestones. They indicate this need and receive tempo, meter, ticks events. It is responsible for tracking changes. Alternative proposal: Host processes blocks of 1 tick. Events are delivered with a timestamp that says 'actuate this event at this fractional-ticks offset within this buffer'. This is what tempo-synced plugins want. All other plugins, which have user-supplied data must translate fractional ticks into sample count to process events, or events can ONLY occur at tick boundaries. Tempo/meter/etc are exclusively the host's problem. Converting to samples is the plugin's problem. Is that accurate? Tim

Ok. So how does a plugin know about musical milestones, then? Suppose it wants to lock onto a beat edge. I agree that TICKS events are not needed, since if you know the sample rate (you do) and you know the tempo (you can), then you can extrapolate a tick-width. The tick edge is the trick. Or do we not worry about it and assume that the user will start things at the proper edge, and plugins will just need numbers of tick-widths? Yeah, I didn't mean it to come across that way - we've already decided that timestamps are continuous. Sorry for the miscommunication. I don't get what you were saying about virtual time. Let me try: frame-count is a global rolling counter. It never stops, unless the host has a special 'off' mode. Ticks is a mucial counter starting at some point, 0, that represents the timeline (track/song/whatever). It can jump forward (12, 13, 165) or backward (165, 166, 1) or loop, or pause. If it is paused or stopped, the frame-counter is still going. Since plugins just track 'ticks' by that, they still work. Is that correct? Tim

good. good. Both of those are simple and elegant (once I get over the internal conflict of using controls :). Tim

On Monday 16 December 2002 03.18, Tim Goetze wrote: I think he meant "start of beat" and that kind of stuff, rather. ("isolde stirbt" would be a change of a string Control of some weird plugin. ;-) That's basically what I'm suggesting *plugins* could do, if they like. They would still be told about TRANSPORT_STOP, of course, in case they actually *want* to stop. That's what I don't quite like. I'd prefer if plugins that don't care could... well, just not care! :-) With audio timestamps, that would be very easy, and I'm still failing to see how there can be any complications in dealing with musical time, just because you stamp events with something else, that has a known relation to musical time for every sample of the current block. 1. There can never be a question about when an event is meant to be applied. (You will process for N sample frames, or there will be trash in the audio. Likewise with events - and they're based on audio time.) 2. 1 applies to the sequencer as well - so it will *have* to have decided how to map musical time to audio time, before it lets other plugins run. There is a known, fixed relation for every sample in the block. 3. Given 1 and 2, you can always translate an event that you're supposed to process, into musical time, with sample accurate timing. 4. If you want to manipulate timing of events in relation to musical time, you will have to consider the fact that no one knows the exact mapping of musical time to audio time in future blocks. 5. Given 1 and 4, you can wait until the musical time you're interested in is within the current block. Not until then can you make a final and correct decision. //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 -' --- http://olofson.net --- http://www.reologica.se ---

David Olofson wrote: they can, rest assured. during "virtual time", the tempo and beat measure at the point where the transport has stopped remain in effect. tick, time and frame counts continue to roll. plugins that are not locking to transport time, ie. those that seem to interest you the most, do not need to care at all about the distinction. those that do lock to transport time, ie. those who record and playback, are usually inactive while the transport is standing still, though they do not need to. in fact the kind of timestamp you choose is irrelevant in this context i think. tim

tim, you wrote: yet earlier, you wrote: so, there isn't just one time! this is the whole issue with positional versus rate synchronization. positional references provide one kind of time ("transport" or "virtual" time). its not monotonic, not invariant and not continous. rate synchronization controls a continuous, but not necessarily monotonic or invariant flow of time. different things want to lock to each of these. converters need the rate synchronization provided by sources like word clock. this is the same time that something like JACK and now the proposed XAP would be using as its basic timebase. but a sequencer or tape device would use a positional synchronization signal that is entirely independent of the sample rate. tim h. had written: sounds fine, except that there are some difficult cases to handle at a higher level. consider "actuate this event when get the following point in the music", delivered when we are looping, and have already passed that point in the music, yet its within the loop. the event needs to be delivered at a point which is now in the *past*, yet will soon be in the *future*! --p

On Monday 16 December 2002 02.21, Tim Hockin wrote: Or rather, related to audio time, since the timestamps are free running + wrapping, and not specifically related to the start of any audio block. Doesn't really matter, though, since the point is that you should not think in terms of audio time outside the current block. Right. That's not an alternative, but rather a way of ensuring that beatsync plugins don't drift because of rounding errors or whatever. They're just "unmotivated" POSITION_CHANGE events. No special handling needed. If plugins or the host maintains a sample accurate representation of musical time, all you need to do is look at that. If you get TEMPO + POSITION_* events, those will ensure that your internal representation is in sync with the timeline, for every single sample that you process. If you want to know about the future, you could make a call somewhere - but yet again: No one knows anything about the future, so the answers are just guesses. Ask for musical time, but don't expect to ever reach the point returned. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 16 December 2002 02.12, Paul Davis wrote: [...] Yep. Yes - and I believe this is where musical time belongs. Thus, there is no reason to involve musical time timestamps unless you actually care about musical time. It would be like plugins sending audio rate control data at 44.1 kHz and and audio at 48 kHz, where the two sample rates are not in a fixed relation to each other. That's exactly why I don't want to have plugins deal with musical time, unless they really want to. It's tricky to get right, and in the majority of plugins (including most beat sync'ed effects), there's no need for it whatsoever. Unless I'm totally misunderstanding what you have in mind, this can only happen if someone modifies the song while playing. It that case, there isn't much to do about it; the new event is behind the current play position, be it in a loop or not. So, you missed it, this time. I'd think it's too much to ask that every synth supports FFWDing waveforms, envelopes, LFOs and all to the position they would have been, had the event been delivered in time. It's theoretically possible indeed, but I strongly doubt there's a point in implementing it, only so dragging notes around in the piano roll works better with long and dynamic sounds. The stop/restart hack is quite sufficient, considering what it takes to do it *properly*. It doesn't matter whether or not the event exists both in the past and in the future; the future will still soon be within the current block. Unless someone hits stop, or moves the loop marker, or whatever. Again, plugins can't know anything about the future (who does?), so they shouldn't pretend they do. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Mon, Dec 16, 2002 at 01:43:03AM +0100, Tim Goetze wrote: I thought the assumption was to send only events scheduled for the block te be processed. If that is the case all tempo based, musical time references can be converted into sample relative time (eg. sample number within the block). If the block is to be rendered; it's too late make changes. Block sizes[1] determine your latency. If you are scheduling events ahead of the buffer, a few interesting things happen: - the plugin needs to have some events queued in musical time reference (tick) to be able to anticipate tempo changes no known at the time the event was scheduled (eg. for synching he position) - In case of real-time changes to the song, events would need to be adjusted/deleted/inserted. This is something better handled at the sequencer host - In case of repositioning, skipping, reversing and other things a user can do with her jog dial, the queue needs to be adjusted appopriate. Same as #2 My votes for normalising event timestamps to buffer relative sample position. Perhaps a callback to get the actual tempo etc info from the host for those plugins that require it (say: tempo delay) would be the best solution. Frank. [1] - in case of lots of blocks in series; the latency might end up being quite substantial, or am I overlooking something? If this is true, a setup (I compare it to my mixing desk with some outboard processors) with varying number of plugings for every channel would have different latency for differenct channels. -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol(a)home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?

Well, if this is really important, perhaps something to the effect of host->abs_scrow(plugin, tick_num, event_queue, value); The plugin requests that the host deliver an event to the particular queue when we hit a specific abolute tick time (host turns it into audio time for event delivery, of course). If the transport jumps (i.e. a loop) the escrow is discarded. Plugins can do this on their own and just observe TRANSPORT events, too. It just needs to be EASY (e.g. in the SDK). right.

no, this is wrong. if the transport stops, depending on how you define "the transport", then all *musical* time has stopped, at least all musical time using the musical timebase controlled by "the transport". --p

<My views> Tempo remains in effect. Transport time is only meaningful to the sequencer. Why should a plugin care what point in the song you are at? Why should a plugin care if the play-pointer moves? Audio time (sample-count) runs endlessly (host can actually stop it if it can know there is nothing going on at all, perhaps - blocked on user/MIDI - maybe). Because the sample-counter is tied to the tick counter directly via tempo, rate, meter, and ppqn (modulo tempo changes, which can come as events or whatnot) plugins don't need to actually track what tick number they are on, just the passing of ticks. Edge-dependent plugins, if there is such a thing, can see when (samples_per_tick*ppq) samples has elapsed and know a beat has happened. Absolutely essential, IMHO. Now, I've become very confused. What is it that we are arguing about? We seem to all be talking in circles, so I'm going to describe what I understand and I want to steer the discussion towards a solution :) * Host sends buffers of N samples to plugins, with a starting timestamp * Things send timestamped events to plugins * Timestamps are measured in whole audio samples * Host/timeline must export/deliver: - SAMPLE RATE (samples/sec - passed at instantiation) - TEMPO (sec/tick - event?) - PPQN (ticks/qn - host-global? event? fixed?) - METER (units? - event?) * Plugins can track ticks by adding 1/(rate*tempo) to a counter and observing an integral boundary crossing. So the questions that remain: * what am I missing? * how do external clocks tie in? (I know _nothing_ about them!) * units for meter (I don't know enough music theory to answer properly) * can we take any of this tracking work away from the plugins? This argument is getting tired - lets resolve it.. Tim

Paul Davis wrote: you absolutely need ppq for the tick system to properly map different measures (5/4 time, 6/8 time etc) as per previous post. you're better off specifying tempo as quarter beats/minute uniformly for the above reasons. add seconds-per-beat for plugins that are not limited to audio purposes. i wouldn't make either a float, it is by far too uncommon to be justified and makes some arithmetic cumbersome. from my experience, more conversion functions are needed, in effect you need to map from any of these domains to any other: * bar.beat.fractional (or .tick if you will), * tick * time in seconds * audio frame you may want to implement it using one call and a structure with flags denoting your interest, or offer any of these as a separate function. i have opted for the latter -- to keep things sane, b.b.f conversion is only done for ticks and vice versa though. tim

Paul Davis wrote: it is ticks for all i know, spell it tpq if you happen to like that better. have you ever parsed a MIDI file? the same value is called 'division' in the file specs. there's no point in limiting this to be a fixed value. you're right, it doesn't matter what reference length you choose. quarters simply happen to work well, and there's no need to break with convention here. it must be assumed the hosts knows seconds-per-beat better than the plugin. thus, forcing another calculation back from frame units is illogical. one of the basic properties of rhythmn is that human beings are able to count it, otherwise they cannot sync (groove) to it. no musical tradition i know of violates this principle; rhythmn is integral by its very nature. i'd be happy to hear a good example proving this wrong. but take note that i don't accept 1/2, 1/3 and relatives as qualifying because they can better be (and usually are) expressed using integer numbers. about arithmetic: float operations, as you know, introduce round-off error. integers can be used in accumulators with much less inconvenience. tim

Paul Davis wrote: [long reasonings elided] alright, have your way then if you need all the complication for so little to gain, and if your scheme gets the votes. prove it. tim

David Olofson wrote: thanks for asking. 1) it is simply not the way counting time as a musician works. if your measure said 3.5 / 2, you'd count 7 quarters. actually and mathematically proving this unfortunately is beyond me, you have to try it yourself. 2) the first time somebody uses 1/3 and 1/4 at the same time, accumulating beat algorithms don't give the same result reliably where they should. tim

On Tuesday 17 December 2002 03.40, Paul Davis wrote: [...] In fact, if you try just playing along with your sequencer, you'll quickly realize that just counting doesn't work. Try it! (Hint: Input it step-time first, and play it. Listen to the wandering *relation* between the beats. Start easy with 2:3, 3:4 etc.) I bet. Didn't take me much experimentation to realize it doesn't really have much to do with the counting at all. Isn't that just 3 notes + 4 notes in one bar? //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 17 December 2002 04.34, Tim Goetze wrote: Well, then you *should* know more than I do about these matters. What am I supposed to say? //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 17 December 2002 04.25, Tim Goetze wrote: Try that with 4:5, 5:6, etc, and you'll see why it doesn't work. At some point, you must start thinking in some other way. First of all, fp *is* equivalent to integers for all practical matters, as long as you don't do anything that results in values that don't fit in the mantissa. Adds and multiplications with integer values are perfectly safe, as long as the result fits. That said, precision *is* an objective - but having 32+ actual bits of accuracy per sample is not. Again, as long as you lock to the timeline, there's no real problem. //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 -' --- http://olofson.net --- http://www.reologica.se ---

David Olofson wrote: you don't really count to 19 as a musician, you'd make it from 2, 3 and 4 just as you do with all other odd rhythmns. because adding 1/3 six times doesn't give the same as 1/4 added eight times. tim

Good god! I come home and find not 10, not 20 but SIXTY emails arguing the virtues of time, precision of floating point values, and at least one exposition on Indian rhythm. It's going to take me a while to catch up - Anyone care to summarize?

David Olofson wrote: Well what a coincidence! :) I just got back from a rehearsal coaching a 60-piece wind ensemble on this sort of thing. Most people these days really do think of complex meters as non-integral values. (A lot of musicians would be hard-pressed to explain it that way, though, because at least in western pedagogy so much rhythmic terminology is still highly subjective - think about terms like "feel" or "groove".) A very comon case might be the following: an initial meter of 4/4, with a metronome makring of quarter=60. After 3 bars of 4/4, we come to a 3/8 bar, then resume 4/4. That 3/8 is functionally equivalent to 1.5, because the quarter note is *still* the counting unit, despite the temporary change to a meter with an eighth-note denominator. A more complex case, and one which is popping up with greater frequency in some kind of music, involves divisions other than 2. For example, imagine we had been going along in 4/4, but each beat had been subdivided into quintuplets. (5 divisions per quarter). Thus, in 4/4 we have 20 such units. Now imagine that we needed to have a bar consisting of 7 of these units. (This is occasionally notated 7/20). Then we want to go back to 4/4 after a bar of 7/20. I don't think you could use integers for this. (Traditional time signature notation, as you see, represents this very poorly.) The only way to accommodate this with a traditional sequencer is to clumsily insert a tempo change, which I find very awkward. -dgm

On Tuesday 17 December 2002 03.23, Paul Davis wrote: Right. This should apply to XAP as well. Just make sure the sequencer doesn't let plugins run on accumulated position + tempo for too long, and nothing will ever run out of sync. This is nothing normal beat sync'ing plugins will ever have to worry about. If they can take musical time position events, they get "drift elimination" for free. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tue, 17 Dec 2002, Pascal Haakmat wrote: But in this case, they're designing a system for designing instruments. Such a system should be able to accomodate every possible musical expression under the sun. I like this metaphor because in this case, they're trying to find the most generally useful peice of wood for as many instruments as possible. Taybin -- http://www.piratesvsninjas.com

16/12/02 20:04, Taybin Rutkin wrote: I don't believe it. If it is that comprehensive it won't be very useful. And if it's useful, it won't be that comprehensive. Exactly. It is totally backwards. Pascal.

On Tuesday 17 December 2002 01.50, Pascal Haakmat wrote: For the exact reason I've suggested once or twice: A musical time aware effects might want to know the length of one beat, or one bar. Why not just allow the user to select "beats" or "bars" instead of "note value" when configuring such a plugin? If you have integer-only meters, you make it impossible to do exactly that, in the cases where beat or bar sync is most interesting; in polyrythmic compositions. Users will have to resort to telling these plugins about the correct lengths in other, potentially non-obvious and/or inaccurate ways. No, but we should at least try to cover what we know about, are interested in, and can handle without too much trouble. (And I'm definitely interested in exploring stuff beyond 4/4 and 6/8.) So, you're not supposed to use cutting edge technology, unless you're interested only in traditional western european music? That is very discriminating, not only towards other cultures, but also towards those of us who want to experiment and explore things beyond 12tET and simple rhythms. So what? I sure still want to explore harmonies beyond the 12tET scale. We're not *excluding* anything here; just trying to find the smallest common denominators for *music*, rather than just for most kinds of western european music. Why is it a good idea to *prevent* interesting uses, just so you don't even have to think about the consequences of using a float where you could have used an int? What's wrong with a fretless guitar? Indeed, you'd have to learn how to play it, but that's a non-issue in our world. Sequencers and MIDI->event converters don't have a problem delivering the exact right values every time. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 17 December 2002 04.53, Pascal Haakmat wrote: So do I. ;-) I think it's acceptable that applications just display the signature as two fp values with some decimals. That's ok for *.5 and *.25 and the like, but not very sexy for N/3 and the like. More sophisticated applications might look for nicer ways of expressing such values, but that's entirely optional. Well, yes - I just meant that there is no need for the distinction, unless removing it results in real, technical issues. Yes. I just don't see a conflict here; that's my point. That's not at all what I'm suggesting. There is a very big difference between "understanding something" and "supporting something". A synth does not have to understand *any* musical scale to play 1.0/octave. Yet, it can reproduce any pitch in the audible spectrum, and then some. As a result, it *will* play whatever you feed it, no matter what theory, culture or tradition the pitch values are related to. Ok. Let's just hope I'm 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 -' --- http://olofson.net --- http://www.reologica.se ---

Sorry, forgot to add: Pascal Haakmat wrote: I know what you're saying, it's basically the argument against cultural appropriation, and that any aesthetic not grounded in some tradition is basically superficial. I'm not unsympathetic to that position in general. But this is not really the forum to debate aesthetics. Let's not forget that ideas from one domain tend to carry over to others. When Paul D. talks about non-integral rhythmic structures, he mentions Indian music. However, these sorts of rhythms have been popping up in western music over the last 100 years as well, sometimes, though not always under non-western influence. (I'm pretty sure Brian Ferneyhough doesn't care about Indian rhythms, but he certainly uses non-integral bar lengths, including things like 7/10 (1) [= 1.3 quarter note bar]). That's a little off-topic, but the point is that a well-written piece of code should be adaptable to as many different contexts as possible, and should support as many users as possible. I've searched for years for commercial apps that don't restrict my rhythmic and harmonic thinkning, and they basically don't exist. Hmm. Last time I checked, the guitar was used in just about every musical tradition from rock to western classical to Afro-pop to jazz to folk to Hawaiian to chansons to Flamenco to country..... -dgm

David Olofson wrote: [tempo] it does: 5/8 = 2.5 * 1/4 you *are* the sequencer because we agree there must be a central time authority, don't we? tim

On Monday 16 December 2002 21.59, Paul Davis wrote: [...] I suggest 1.0/beat for XAP. (64 bit double.) One may claim that that's not an exact representation, but who cares, as long as it's much more accurate than what you need for sample accurate timing? This only really matters to sequencers, and those should probably use integer b:b:t formats, to avoid rounding errors building up when manipulating events. Still, I don't think there's a strong motivation for that either. [...] Agreed. (I wasn't thinking straight before.) XAP tempo: beats/minute (what most people expect) beats/second (fits better with Hz for sample rate) The second does look better to me the more I think about it, but that "BPM" term is pretty deeply rooted! :-) [...] Ok, that settles it for me; XAP should express meter as two 32 bit floats. (Tempo would be a third, but that's redundant, since you'll need a separate Control for Tempo anyway, to handle "tempo ramping".) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 17 December 2002 02.41, Tim Goetze wrote: ...which get rounded to the nearest integer audio sample frame anyway, as far as events are concerned. I don't see why. (On the contrary, there are just more figures to read. ;-) Yes indeed - but I don't see a reason to force every plugin to keep track of it. Just make it 1.0, and the sequencer can use whatever it likes internally and/or in the UI. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 17 December 2002 03.50, Tim Goetze wrote: That's a good point - and we're only talking about a unit for a 64 bit double anyway. Well, if it *changes*, how do you know what "1 beat" is, unless you involve a factor that you must get from the timeline driver? I dont't see why it should be *variable*, given that 1920 fits most useful subdivisions, and that you still have quite a few fractional bits below that, should you ever need it. Just make it 1920, and don't worry about it. :-) Naah - there might be some beat sync ones as well, I think... ;-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 17 December 2002 03.45, Paul Davis wrote: Well, double has some 14 figures of accuracy (decimal), so it would be more like 0.33333333333333 or so. When you're at tick 1000.0 (1000 *beats*!), it would be 1000.3333333333. Given 120 BPM, that would be at a sample rate of 192 kHz, you'll have 12 fractional bits per sample. 1000 beats at 120 BPM is 83.3 days. Please check; I could be missing something. If not, I simply have to disagree. :-) Note that I'm *not* suggesting that sequencers must use this internally. How much finer? Why call it a "tick" at all? (That's not really my invention. I'd just call it "musical time".) Well, "exact" *is* nicer than "approximate", so... I'm beginning to like this. :-) Well, since I assume you've both done it, while I (IIRC) have only done it with integers; point taken. Still, if it's floating point, there is no such restriction, really. You *could* implement a sequencer with higher resolution, and make use of the fractions below 1920. Right. There's no absolute maximum resolution. So, considering the advantage of double with 1920 ticks/beat being truly useful inside sequencers (no rounding errors), and it still providing sub-tick accuracy, I move over to the 1920 side. XAP audio time unit: 1920.0 ticks/beat //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 -' --- http://olofson.net --- http://www.reologica.se ---

David Olofson wrote: right on. seconds_per_tick is what i actually use, and it's central to easily mapping ticks to seconds, and from there to frames. seconds-per-beat would be a little exotic actually, sorry for bringing it into play. non-integer is not proven to be needed i think. if you say you need 9.5 beats per measure, simple make that 19 half beats. it is a lot simpler to implement on a machine, and the denominator is just a matter of convention but not of precision. in a system where audio is the master clock, the time i mean is simply frames / sample_rate. i don't care how complicated you make it, it just has to be there. ;) besides it's ok by me to complicate life for host coders. it's the plugins that should get the better part of the deal. tim

On Monday 16 December 2002 14.35, Paul Davis wrote: [...] Yes, almost. I think it's useful to be know about the METER, in case someone tells you something about "N bars", or "every beat" or whatever. [...] It looks like Controls will take two or three forms of events: SET(..., value) RAMP(..., target, duration) SPLINE(..., target, target_slope, duration); Basically another form for the same thing. I find this representation slightly more logical, since it gives you an explicit duration, which lets you insert a "stop here" event into your own queue, or whatever. You can do that either way, but since timestamps are only sample accurate anyway, I see a risk of target + slope opening up for different interpretations of exactly when the slope ends. OTOH, that could actually be allowed for, and seen as a feature - but how useful is subsample accurate timing that only applies to the ends of ramps, but nothing else? Just one issue: Is float32 sufficient for tempo? (We'd need to switch to 64 byte events, or use double events to handle 64 bits + ramping...) Position could just be double, and no ramping, right? (No problem fitting that in a 32 byte event.) Provided that adding a float to a double should extend the float to double first, you'd actually have to *make* this go wrong explicitly, to break anything. Would two floats (32 bit) do? Ok, that would mean we're dealing with special events (rather than standard Control events), but in most cases, I think that just makes implementation easier anyway. It has no effect on the "Control export" and connection stuff anyway, since that's just about abstract objects anyway. Good idea. VST gives you a time info for the first sample in tho buffer, which seems like a good way of complicating things for the host, for no good reason. (Provided that plugins get accurate timeline date by other means, that is. That's not the case in VST.) I think you need events *as well* for that, since transport events can occur at any time; just not between bars. (Though, most people set loop markers in between bars, I'd think.) Yes, that could make it easier for some musical time dependent plugins to figure out what to do with events that don't "fit in" after a transport event. Yes. But I still like the idea of multipli timelines. :-) What I had in mind was for whoever maintains the timeline, to also send time info structs by reference, to those that want them. As events, that is, so you get the same Channel addressing capabilities as for normal Controls. Alternatively: host { /* For timeline "generators" */ int (*register_timeline)(...timeinfo callback&stuff...); /* For whoever wants to know what they're sync'ing to. */ XAP_time_info *get_time_info(int timeline_id); } Now, if you're a sequencer (plugin or not), just register your time info callback with the host. Mark timeline related events you send with the return value - which is your timeline's host global handle. (Or have a control for this, if it doesn't fit anywhere. It should fit in the POSITION_CHANGE event, though - and you'll *have* to get one of those first thing the sequencer is started.) A plugin that wants more than what it gets through the timeline controls, can just look at one of those events and ask the host about the current XAP_time_info for the timeline that event came from. Not *that* complicated, and now, hosts don't have to understand *anything* about timelines. The host just provides an indirect way for plugins and other "objects" in the system to ask each other directly about this stuff. The host would just look up the right timeline and forward the call. BTW, I think it might be a good idea to send a notification event to plugins that care about position whenever the meter is changed, or something, so they can ask for the new XAP_time_info, in case they don't always do that every block. You *shouldn't* need to do it more than once per bar, if each one is valid for one bar, but if someone edits the timeline, something must tell you that your data is no longer valid... How is that possible? (Provided "audio frame" referst to free running time as used for event timestamps and implicitly, audio.) Well, anyone can "export" a timeline through the callback forwarding system I proposed above. Will that do? As to only implementing once; how about a plugin that is *only* a timeline? You'd use one to drive a sequencer, or you could just hook it up directly to any musical time aware plugins, if you have no need for a sequencer. Like any controls. From the host/plugin registration and connection POV, they just need a type ID, so you can't mix them up with controls of incompatible types, but that's in place already. (For float and string controls. We might want to have double as well, although special-casing POSITION_CHANGE would do.) As to implementation, it's just a matter of using custom events, if desired. I can't see a real need to handle these as if they *really* were normal Controls (ie running PITCH into POSITION_CHANGE) - and if you *really* want to do that, you can hack a converter plugin anyway. I think it's more impontant to keep this as clean and simple as possible. Yep. And POSITION_* events, IMHO, to ensure that plugins don't drift out of sync, even if they don't care to ask for XAP_time_info all the time. I would think you only really need one of these, since you can calculate the other if you really need it. (Ask for time info, or track meter changes, or whatever there is.) Anyway, these would both have to be doubles (64 bit), since integers would introduce large rounding errors (can't have *both* timestamps and positional data as integers), and float (32 bit) have insufficient resolution. We *can* squeeze two doubles in an event, but that's it. The header (next, timestamp, action, target) is 16 bytes. (Well, we could go 64 byte/event, but not for a single special case like this.) That's the event timestamp - unless you're referring to audio time as used by hard disk audio tracks? Is that really needed, if musical time is subsample accurate? 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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 18 December 2002 03.08, Tim Hockin wrote: [...] Yeah, but that's not much point in itself. We have at least 12 bytes if we use a non-standard event, so this isn't a major problem. Using a special format inside an integer would be a non-standard control type anyway, since you cannot assume that the value is a valid float. Unless it's explicitly encoded that way... Don't want to go there! :-) Yes, that's a good point. As soon as you say N+1/3 for beats per measure, you get a rounding error... So, how about using the magical 1920 unit for both fields? Then you can express all sorts of weird values and still get exact integer values. And it fits nicely with the musical time unit as well. :-) Probably! ;-) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 18 December 2002 10.29, Tim Hockin wrote: Two standard float controls would work fine. Better, in fact, as you can handle defaults and presets without any special-casing at all. Do we have int controls? Well, I do in my version, and my motivation is that you have 9 extra bits, compared to float32. This might matter a great deal when you actuall want an int. BTW, how about making integer controls 64 bit? (*41* extra bits! :-) It's no big deal in any way, because they can't be ramped (no event size issues), and you can just throw the top 32 bits away if you don't want them in you internal control arrays. The point is that events are (at least) 32 bytes anyway, so why not make use of the otherwise dead space? *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 -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 18 December 2002 19.19, Tim Hockin wrote: Yes... Well, first of all, this is all totally optional. It's only needed by tempo and beat sync plugins. (Through that doesn't mean it needs a hairy API. ;-) [...] I can't think of any example. It's just more bits, basically. Frankly, that's the only strong motivation I see for ints at all, since if you just need an integer *value*, float should do. (Just disable rounding.) It might be nice to know that you'll never get 1.5 on a port hinted/typed as integer, but I'm not sure that's a good motivation. If you really need an integer, you'll round or truncate first thing anyway, so such illegal values never get into the machinery. Yes... Might be interesting if you want compact protocols for sending events over networks or something. Well, fp is signed, and AFAIK, there are a bunch of programming languages that don't have unsigned ints at all, so I would suggest assuming they're signed. (Unless they're strictly meant for flags or something, but that seems like a nasty thing to do...) Well, yeah... You'd have to implement ramping for integers in plugins, and that's not quite as trivial as ramping floats. (I do it all the time in Audiality - but that's 16:16 fixed point, so no one relies on much accuracy in the lowest bits.) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 19 December 2002 08.44, Steve Harris wrote: [...] Right. They actually make *more* sence as an audio format, since there, it can have a real effect on performance. That's only really relevant for old or low end hardware, though. (That's why Audiality does it - but only in the real time synth. I'm simply not motivated enough to implement the off-line oscillators in fixed point... *heh*) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 19 December 2002 21.17, Steve Harris wrote: Yeah - and I'm not even sure I'm going to do much integer stuff in Audiality from now on, *despite* scalability being a major priority. Performance isn't really a problem until you're on old Pentium processors - and then you can't really use Audiality anyway, because rendering a few sounds takes "ages". The only other audio format that could be of interest for XAP could be double, but I think that can wait until people actually start complaining about float being insufficient. :-) Double *controls* might actually be useful in some cases, though. Song position demonstrates the weakness of float, but the question is if that applies to many other things. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Thu, 19 Dec 2002 20:17:04 +0000 Steve Harris &lt;S.W.Harris(a)ecs.soton.ac.uk&gt; wrote: The only sound argument I have found for using integer fixed point over float can be summed up in two words: Denormal Number Although deft coding can alleviate it somewhat, I can only hope that with the Itanium, Opteron or whatever, this is no longer a problem! - Mike __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

do we really need spline? How many plugins are going to implement that? If the host wants to approximate a spline, send multiple short linear ramp events. Then you only need timestamp (start), duration, and value. The plugin just has to arrive at that value by the end of the duration. Slope is implied. beat events could be integral - the host sends the beat # timestamped to the very first sample at or beyond the beat edge. Tim