Krzysztof Foltman <[EMAIL PROTECTED]> 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>
pgpTX7KYPAlfI.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev