hrrm, yes - the sample synchronicty between host and repeated playback of a sniop of time. Ugg But not impossible. If a plugin supports SEEK, it will have a SEEK control. The sequencer should notice that you've jumped/looped into a long note. Re-issue that note and then a SEEK for that voice with the same timestamp. Plugs that support it will have no glitching. Plugs that don't won't get re-triggered. eww, the seeking needs to be instantaneous, and unless you suggest supporting infinite tempo (forward and backward)... Tim

On Friday 20 December 2002 16.47, Ben Loftis wrote: Make it every *sample* frame, or it just won't work. (Unless that's what you actually meant). That would work, but there are a bunch of values you need to calculate, and the cost might be significant. My guess would be that generating full time info for every sample burns about as much CPU as a bunch of basic filters. Thread safety is not an issue. If you have multiple threads, you have many other issues as well, so you just can't do it without gateways between the threads. (I've mentioned what you need to do for RT/non-RT event passing for GUIs, and this applies to multithreaded hosts to some extent as well.) Yeah, and it's even more annoying if you have drum loops and other rhythmic sounds. The pads can be handled in an acceptable way by just adjusting the note start - or rather; find the last event for each control before the starting point. (Remember that we don't have actual note on/off events, but rather think of it as a note being played whenever VELOCITY is non-zero.) SEEK is needed when you want to tell the synth/sampler to skip the first part of the note, so it's basically the other half of the solution. (Minus a few percent; it doesn't handle pitch bend and other things that may affect the time/position relation. Sequencers could approximate it by looking at PITCH, but that won't work for modulation and other stuff that depends entirely on the sound/patch.) It's optional, and not too hard to implement. Doesn't even have to be accurate. (It *can't* be with this interface anyway.) A synth can just look at SEEK when it's time to start a note, and if it's beyond the attack + decay sections of the envelope, start with the hold section or something. Do what works "ok" for the job it's supposed to do, or just don't do it at all. That won't work, unless you can tell plugins to just process events and not audio. It's not much use trying to do it faster than real time unless you're only using a fraction of the available CPU time when playing in real time. Besides, this prerolling would have to be done outside the RT net, or you would have glitches (or rather, long pauses) in the RT audio processing. If you need it sample accurate, you only need to go back to some point where no events that are playing at the actual start position have started. Note that this is basically only for hard disk recording and similar tasks. Synths should very rarely need this. No, but it *might* force the plugin to redo the prebuffering work. For this very reason, I don't think you should do any "parametric" processing before the data goes into the buffers. For example, a HDR wouldn't apply EQ and stuff in the butler thread, but rather on the RT side. (Or there isn't much point in having a low latency RT part at all, obviously.) Thus, control changes would have no effect on PCPs/cue points. PREDELAY might have an effect, but only if the change is big enough that the PCP buffers need to hold a different position in the file. Yes, but again, there isn't much point unless the system is furiously overpowered. It might be though, and this is certainly an interesting feature for sophisticated hosts - but it's not a general solution for the problems we're truing to solve with PCPs and SEEK. Nope, and doing it *completely* right with internal synths is very hairy, very expensive or both. I think SEEK events would be a realistic way of doing it quite a bit better with internal synths, but going beyond that doesn't make much sense to me. Very little is set in stone so far, and it's to be expected that the only documentation will be the headers, until we're close to finalization. Might be nice to have HTMLized versions of the existing headers on the site, though. Can someone suggest a nice and handy tool for that? //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 ---