[LAD] More proposed LV2 addition/extension stuff

[Nedko Arnaudov]

Krzysztof Foltman <wdev at foltman.com> writes:

> Steve Harris wrote:
>> You're right, we never defined the lv2:binary predicate.
>>   
> While you're adding stuff to lv2core, you might as well consider adding 
> some of those (+/- any discussions that arise and probably rewrite in 
> proper English), or perhaps I should move some of them into separate 
> extension(s):
>
> :trigger a :PortProperty ;
>     rdfs:label "Trigger" ;
>     rdfs:comment """
> Indicates that the data item should be considered a Boolean value 
> corresponding to the specific event that was detected (control output 
> ports) or is to be triggered (control input ports). For input ports, the 
> port needs to be reset to false by the host (any value less or equal 
> than 0) after run() function is called.
> """ .
>
> (Boolean? discrete? based on if :integer or :toggle is present? a 
> feature that says :trigger that is supported? use special labeled events 
> instead?)
>
> :supportsStrictBounds a :Feature
>     rdfs:label   "Supports strict bounds" ;
>     rdfs:comment """
> Indicates use of host support for :hasStrictBounds port property. A 
> plugin that specifies it as optional feature can omit value clamping for 
> :hasStrictBounds ports, if the feature is supported by the host. When 
> specified as required feature, it indicates that the plugin does not do 
> any clamping for input ports that have a :hasStrictBounds property.
> """ .
>
> :hasStrictBounds a :PortProperty ;
>     rdfs:label "Has strict bounds" ;
>     rdfs:comment """
> For hosts supporting the :supportsStrictBounds, it indicates that the 
> value of the port should never exceed port's minimum and maximum control 
> points. For input ports, it moves the responsibility for limiting the 
> range of values to host, if it supports :supportsStrictBounds. For 
> output ports, it indicates that values within specified range are to be 
> expected, and breaking that should be considered by the host as error in 
> plugin implementation.
> """ .
>
> These probably belong somewhere else, but I'll post them anyway:
>
> :expensive a :PortProperty ;
>     rdfs:label "Changes trigger expensive calculation" ;
>     rdfs:comment """
> Input ports only. Indicates that any changes to the port value may 
> trigger expensive background calculation (eg. regenerate some lookup 
> tables in background thread). Any value changes may have not have 
> immediate effect at all, or may cause silence or diminished-quality 
> version of the output data to be produced until background processing is 
> finished. Ports having that property are typically not well suited for 
> connection to outputs of other plugins, and should not be offered as 
> connection targets or for automation by default.
> """ .
>
> :causesArtifacts a :PortProperty ;
>     rdfs:label "May cause audio artifacts when changed" ;
>     rdfs:comment """
> Input ports only. Indicates that any changes to the port value may 
> produce slight artifacts to produced audio signals (zipper noise and 
> other results of signal discontinuities). Connecting ports of this type 
> to continuous signals is not recommended, and when presenting a list of 
> automation targets, those ports may be marked as artifact-producing.
> """ .
>
> :continuousCV a :PortProperty ;
>     rdfs:label "Carries a smooth modulation signal" ;
>     rdfs:comment """
> Indicates that the port carries a "smooth" modulation signal. Control 
> input ports of this type are well-suited for being connected to sources 
> of smooth signals (knobs with smoothing, modulation rate oscillators, 
> output ports with continuousCV type etc). Typically, a plugin with this 
> type of ports will implement appropriate smoothing to avoid audio artifacts.
> """ .
>
> :discreteCV a :PortProperty ;
>     rdfs:label "Carries a discrete modulation signal" ;
>     rdfs:comment """
> Indicates that the port carries a "discrete" modulation signal. Input 
> ports of this type are well-suited for being connected to sources of 
> discrete signals (switches, buttons, classifiers, event detectors etc.). 
> May be combined with :trigger property.
> """ .

Having these things defined (either as part of core or as extension(s))
would be very useful. Hosts rendering generic UIs like zynjacku will use
them for sure.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080610/4b8583e5/attachment.pgp>