To my own surprise I have to object to the suggestion: /* AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled by a high time res. slider or control data, but shouldn't be connected to the next audio signal by default. I can't think of any simple examples off hand, but combined with MOMENTARY it could be used for sample accurate tempo tapping. */ As is see it, this declares that an audio port should be used for control data. I oppose because it is ugly to declare a port one thing in its PortDescriptor only to reverse this in the PortRangeHint. Furthermore, this ugliness is likely to cause problems in hosts that do not parse this hint value*. I believe that the true intention here was to undo the requirement that data ports can only have one value per run() block, but the author realized that undoing that requirement has significant implications. The primary problem occurs when the plugin assumes a particular control is continuous but the host abides by ladspa.h v1.1 which does not allow more than one control value per block. The plugin will treat that control port's data pointer as if it pointed to an array of the blocksize passed to run(), but the host will have only allocated a single value so there is a memory error. (*)I argue that turning audio ports into data ports will cause enough host incompatibility problems that you might as well do it correctly IF you really feel it's worth it to add this feature. Here are some incompatibilities which arise from using audio ports as continuous control ports: -the host doesn't parse the hint and sends audio to the control resulting in caucophonous output. -the host does realize it shouldn't send audio to the "audio" port but doesn't have a facility for sending control data arrays to audio ports, so the user is unable to manipulate some of the controls on the plugin. Plugin writers are more likely to use continuous controls for important plugin features which warrant the extra detail, so unmodified hosts will be unable to accomodate very useful plugins that do who-knows-what. Basically, introducing arrays of control data will force ALL reasonable hosts to adapt to handle that ability. So I believe we are better off keeping ladspa.h straightforward and self consistent by eliminating the strict single control value requirement and dealing with the issues involved, as opposed to maintaining a false veneer of backwards compatibility by allowing use of audio ports for control data. What are the issues involved with eliminating one control value per block? I think that all you need to do is remove it and add a data port hint CONTINUOUS which means the host _must_ attach that control port to a whole block's worth of data for each run. As i said before, this kills backwards compatibility of hosts, but you are going to do that for the majority of hosts anyway if you reappropriate audio ports for control data and reappropriating audio ports is ugly. As to whether I support adding CONTINUOUS data ports and breaking host compatibility; i haven't written my host yet so yes i support it because it will be easy enough to implement (or so i think :) --jacob robbins................. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail