Subject: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Mon Feb 03 2003 - 13:18:10 EET
Here's that PTAF document that Ohm Force brought to Anaheim:
http://freezope2.nipltd.net/ldesoras/files/ptaf-2003.01.23.pdf
I've read some parts of it, and browsed all of it, and here are some
initial reflections of mine:
* Three states; created, initialized and activated.
This may be useful if plugins have to be instantiated
for hosts to get info from them. Why not just provide
metadata through the factory API?
* Bypass mode seems to be a good idea for stereo->surround.
* Assuming that audio and sequencer stuff is in different
threads, and even have plugins deal with the sync sounds
like a *very* bad idea to me.
* GUI code in the same binaries is not even possible on
some platforms. (At least not with standard toolkits.)
* Using tokens for control arbitage sounds pointless. Why
not just pipe events through the host? That turns GUI/DSP
interaction into perfectly normal control routing.
* Why use C++ if you're actually writing C? If it won't
compile on a C compiler, it's *not* C.
* I think the VST style dispatcher idea is silly. A table
of function pointers, with a bunch of reserved NULLs
would be simpler, faster and just as extensible for all
practical matters.
* Is using exceptions internally in plugins safe and
portable?
* Specifying the maximum string length when asking for
strings seems nice in some ways...
* UTF-8, rather than ASCII or UNICODE.
* Hosts assume all plugins to be in-place broken. Why?
* No mix output mode; only replace. More overhead...
* Only mono buffers. (Good.)
* Buffers 16 byte aligned. Sufficient?
* Events are used for making connections. (But there's
also a function call for it...)
* Audio quality control. (Nice scalability feature.)
* Plugin input->output latency.
* Host process return->audible output latency.
* Tail size. (Can be unknown!)
* Process mode: Mixed/RT/Off-Line.
* Plugins send events specifically to the host...
* Events are delivered in arrays, just like in VST.
* "Clear buffers" call. Does not kill active notes...
* Timestamps are in audio frames.
* Events are always for the current block.
* Ramping API seems awkward...
* Ramping cannot run accross blocks.
* It is not specified whether ramping stops automatically
at the end value, although one would assume it should,
considering the design of the interface.
* Note IDs are just "random" values chosen by the sender,
which means synths must hash and/or search...
* Hz is not a good unit for pitch...
* Why both pitch and transpose?
* Why [0, 2] ranges for Velocity and Pressure?
* Note On/Off/End confuse note on/off with context
management.
* TimeChange: tempo, ts numerator, ts denominator.
* TransportJump: sample pos, beat, bar. (Why not just
ticks?)
* PlaybackChange: stopped/running
* Plugins (not hosts) maintain parameter sets/presets.
* Parameter sets for note default params? Performance
hack - is it really worth it?
* Why have normalized parameter values at all?
(Actual parameter values are [0, 1], like VST, but
then there are calls to convert back and forth.)
* The "save state chunk" call seems cool, but what's
the point, really?
* Just realized that plugin GUIs have to disconnect
or otherwise "detach" their outputs, so automation
knows when to override the recorded data and not.
Just grabbing a knob and hold it still counts as
automation override, even if the host can't see any
events coming... (PTAF uses tokens and assumes that
GUI and DSP parts have some connections "behind the
scenes", rather than implementing GUIs as out-of-
thread or out-of-process plugins.)
//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 ---
This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 13:32:10 EET