Re: [LAD] More proposed LV2 addition/extension stuff

Krzysztof Foltman <wdev@email-addr-hidden> 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>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev