diff options
Diffstat (limited to 'lv2/lv2plug.in/ns/ext/atom/atom.ttl')
| -rw-r--r-- | lv2/lv2plug.in/ns/ext/atom/atom.ttl | 17 |
1 files changed, 8 insertions, 9 deletions
diff --git a/lv2/lv2plug.in/ns/ext/atom/atom.ttl b/lv2/lv2plug.in/ns/ext/atom/atom.ttl index 2e82e32..c3249ec 100644 --- a/lv2/lv2plug.in/ns/ext/atom/atom.ttl +++ b/lv2/lv2plug.in/ns/ext/atom/atom.ttl @@ -42,24 +42,23 @@ lv2:documentation """ <p>This extension defines a generic container for data, called an <q>Atom</q>, and several basic Atom types which can be used to express structured data. -Atoms allow LV2 plugins and hosts to communicate, process, serialise, and store -values of any type via a generic mechanism (e.g. ports, files, networks, -ringbuffers, etc.). Atoms are, with one exception, Plain Old Data (POD) which -may safely be copied (e.g. with a simple call to <code>memcpy</code>).</p> +Atoms are (with one exception) Plain Old Data (POD), which means they can be +easily copied generically (e.g. using <code>memcpy</code>), and are suitable +for use in high-performance and real-time code.</p> <p>Since Atom communication can be implemented generically, plugins that understand some type can be used together in a host that does not understand -that type, and plugins (e.g. routers, delays) can process atoms of unknown -type.</p> +that type. Similarly, plugins (such as routers, delays, or data stores) can +meaningfully process atoms of a type unknown to them.</p> <p>Atoms can and should be used anywhere values of various types must be stored or transmitted. This extension defines port types, atom:ValuePort and -atom:MessagePort, which are connected to an Atom. The atom:Sequence type in -conjunction with atom:MessagePort is intended to replace the <a +atom:MessagePort, which contain Atoms. The atom:Sequence type in conjunction +with atom:MessagePort is intended to replace the <a href="http://lv2plug.in/ns/ext/event">LV2 event</a> extension.</p> <p>The types defined in this extension should be powerful enough to express -almost any structure. Implementers SHOULD build structures out of the types +almost any structure. Implementations SHOULD build structures out of the types provided here, rather than define new binary formats (e.g. use atom:Object rather than a new C <code>struct</code> type). New binary formats are an implementation burden which harms interoperabilty, and should only be defined |