Global-Layer-Renaming: adapt lots of documentation

doc/design/application/Config.txt

@@ -6,7 +6,7 @@ Lumiera Design: Application and Session Configuration
 The Lumiera application uses two quite different sources for configuration
 
 - individual __settings values__ can be loaded from an application- and user configuration in the conventional way
-- various facilities, especially in the Proc-Layer, base the actual behavour on __queries__, which are
+- various facilities, especially in the Steam-Layer, base the actual behavour on __queries__, which are
   to be resolve employing a rules based system '(planned)'. Configuration rules will be provided by the
   application (defaults), a session template and rules stored in the actual session.
 

doc/design/architecture/TimeQuant.txt

@@ -188,7 +188,7 @@ context an object is encountered in. This solution might be too general and
 heavy weight at times though. Thus, for important special cases, the accessors
 should return tagged values, preferably even with differing static type. Time
 codes can be integrated this way, but most notably the *frame numbers* used
-for addressing throughout the backend, can be implemented as such specifically
+for addressing throughout the vault, can be implemented as such specifically
 typed tagged values; the tag here denotes the quantiser and thus the underlying
 grid -- it should be implemented as hash-ID for smooth integration with code
 written in plain C.

doc/design/architecture/playRender.txt

@@ -149,7 +149,7 @@ instance, several life switching and reconfiguration operations might happen at
 the _model port_ (the place where data is retrieved from calculation), the output characteristics
 (framerate, direction) and the delivery goals (playback position, loop playing, scrubbing)
 all may be changed during playback -- we need a way for the player to ``cancel'' and
-reconfigure the backend services.
+reconfigure the vault layer services.
 
 Frame quantisation
 ^^^^^^^^^^^^^^^^^^
@@ -165,9 +165,9 @@ Thus, there are three fundamental guidelines when it comes to rounding:
 These may guide the process of finding the right place for the Quantiser(s) to
 apply. We need some information flows to be joined in order to be able to do
 the quantisation, which leaves us with just a few possible junction points
-where to place quantisation: the backend, the GUI, the player and the session.
+where to place quantisation: the Vault, the GUI, the player and the session.
 
-- putting it into the backend seems to be the most reasonable at first sight:
+- putting it into the vault layer seems to be the most reasonable at first sight:
   we can ``do away'' with nasty things soon, especially if they are technicalities,
   ``get a clean state soon'' -- and hasn't frame quantisation something to do
   with media data, which is handled in the backend?
@@ -177,7 +177,7 @@ cleanliness, well, sigh! Doing rounding soon will leave us with a huge
 amount of degraded information flows throughout the whole system; as a
 consequence,  the general rule is to do it as late as possible. Uncrippled
 information is an enablement. And last but not least: the frame quantisation is connected
-to the _output_ format -- and the backend is likely within the whole
+to the _output_ format -- and the vault layer is likely within the whole
 application the subsystem most remote and unaware of output requirements.
 
 - rounding/quantising in the GUI is extremely common within media applications;

doc/design/backend/index.txt

@@ -1,5 +1,5 @@
-Design Documents: Backend
+Design Documents: Vault
-=========================
+=======================
 
 What follows is a summary of Lumiera's *Data Handling Backend*
 
@@ -11,17 +11,17 @@ data access. Within Lumiera, there are two main kinds of data handling:
   especially logging, replaying and ``Undo'' of all ongoing modifications..
 * Media data is handled _frame wise_ -- as described below.
 
-The backend uses *memory mapping* to make data available to the program.
+The vault layer (backend) uses *memory mapping* to make data available to the program.
 This is somewhat different to the more common open/read/write/close file access,
 while giving superior performance and much better memory utilization.
-The data backend must be able to handle more data than will fit into the memory
+The Vault-Layer must be able to handle more data than will fit into the memory
 or even address space on 32 bit architectures. Moreover, a project might access more files
-than the OS can keep open simultaneously, thus the for _Files used by the Backend,_ it needs a
+than the OS can keep open simultaneously, thus the for _Files used by the Vault,_ it needs a
 *FilehandleCache* to manage file handle dynamically.
 
 Which parts of a file are actually mapped to physical RAM is managed by the kernel;
 it keeps a *FileMapCache* to manage the *FileMaps* we've set up.
-In the End, the application itself only requests *Data Frames* from the Backend.
+In the End, the application itself only requests *Data Frames* from the Vault.
 
 To minimize latency and optimize CPU utilization we have a *Prefetch thread* which operates
 a *Scheduler* to render and cache frames which are _expected to be consumed soon_. The intention
@@ -62,7 +62,7 @@ low level File Descriptor and access
 
 Frames
 ~~~~~~
-+Frames+ are the smallest datablocks handled by the Backend. The application tells the Backend to make
++Frames+ are the smallest datablocks handled by the Vault. The application tells the Vault Layer to make
 Files available and from then on just requests Frames. Actually, those Frames are (references to) blocks
 of continuous memory. They can be anything depending on the usage of the File (Video frames, encoder frames,
 blocks of sound samples). Frames are referenced by a smart-pointer like object which manages the lifetime
@@ -81,7 +81,7 @@ weak::
   try to transform a weak reference into a readonly or readwrite reference
 
 
-Frames can be addressed uniquely whenever a frame is not available. The backend can't serve a cached
+Frames can be addressed uniquely whenever a frame is not available. The vault can't serve a cached
 version of the frame, a (probably recursive) rendering request will be issued.
 
 Prefetching
@@ -92,9 +92,9 @@ There are 2 important points when we want to access data with low latency:
   The data which is backed in files has to be paged in and available when needed.
   The +Prefetch+ Thread manages page hinting to the kernel (posix_madvise()..)
 . Intermediate Frames must eventually be rendered to the cache.
-  The Backend will send +Renderjobs+ to the +Scheduler+.
+  The Vault Layer will send +Renderjobs+ to the +Scheduler+.
 
-Whenever something queries a +Frame+ from the backend it provides hints about what it is doing.
+Whenever something queries a +Frame+ from the vault it provides hints about what it is doing.
 These hints contain:
 
 * Timing constraints
@@ -104,7 +104,7 @@ These hints contain:
 * action (Playing forward, playing backward, tweaking, playback speed, recursive rendering of dependent frames)
 
 .Notes
-* The Backend will try to render related frames in groups.
+* The Vault Layer will try to render related frames in groups.
 * This means that following frames are scheduled with lower priority.
 * Whenever the program really requests them the priority will be adjusted.
  

doc/design/engine/PlayModes.txt

@@ -39,7 +39,7 @@ triggering small atomic chunks of work in a ``just in time'' manner -- there is
 and built-in buffering beyond the low-level double buffering mechanisms utilised by most
 output facilities. Generally speaking, we prefer precise beforehand planning and discarding
 of untimely results over demand-driven and possibly blocking operations. Yet the buffer
-management and frame cache provided by the backend for storing and passing of intermediary
+management and frame cache provided by the vault for storing and passing of intermediary
 and final results allows for a certain amount of leeway.
 
 

doc/design/gui/GuiDiscussion/TimelineDiscussion.txt

@@ -250,8 +250,8 @@ type we get), or an custom condition or tag.
 
 Thus, generally the price to pay would be a more elaborate track head area,
 which actually is a collection of advice. Besides, of course it causes a lot
-more work in the Proc Layer (which obviously I am willing to take or already try
+more work in the ``Proc Layer'' (which obviously I am willing to take or already
-to implement). And, finally, one price to pay is a steeper learning curve for
+try to implement). And, finally, one price to pay is a steeper learning curve for
 anyone accustomed to the conventional approach.
 
 
@@ -364,7 +364,7 @@ produce a strip of images taken from the footage, or just a single image (pivot
 image), or a colouring derived from motion detection etc. This way, all clip
 displays could be made to fit the same space in the GUI.
 
-Regarding transitions, the Proc-Layer (with the use of the type information) has
+Regarding transitions, the Steam-Layer (with the use of the type information) has
 to find out if an transition is applicable to a given pair of clips. If it is
 not, it will be flagged as error. Besides, we need an editor for tweaking the
 transition curve. Now we could consider differentiating this transition curve
@@ -397,7 +397,7 @@ natively, without the need of a special "multicam-feature". Some thoughts:
 When a clip contains multiple media streams, we build an pipe for every stream
 actually sent to some output. Now the question is, what happens when attaching
 an effect (either attaching it directly to the clip, or placing the effect on a
-track/trackgroup in a timerange touching this clip). Basically, Proc-Layer will
+track/trackgroup in a timerange touching this clip). Basically, Steam-Layer will
 be able to determine if an effect is applicable at all. It won't try to wire in
 an sound effect into a video pipe. It won't wire an stereo reverb into a mono
 sound pipe. Thus, I would propose a pragmatic approach to this problem: Let the
@@ -416,5 +416,5 @@ This page sumarises the state of the GUI Discussion in early 2009 +
 Since end of 2009, Gui development is mostly stalled (Joel left the project
 due to other obligations). Meanwhile we had a bit of discussion here and there,
 and personally I got a somewhat clearer understanding of what the Model in
-Proc-Layer can / will provide. But basically that's along the lines of what
+Steam-Layer can / will provide. But basically that's along the lines of what
 I wrote in my last comment at the bottom of this page

doc/devel/rfc/ArchitectureOverview.txt

@@ -20,11 +20,12 @@ link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.
 
 Description
 ~~~~~~~~~~~
- * the Application has three Layers: Backend, Proc and GUI
+ * the Application has three Layers: Vault, Steam and Stage.footnote:[at the
+   time of this writing, those three layers were named ``Backend'', ``Proc'' and ``GUI'']
  * the Application shall be completely functional without GUI (script-driven)
  * all IO, media data fetching, processing and bookkeeping falls within the
-   realm of the Backend
+   realm of the Vault Layer
- * all media object manipulation, deciding and configuration is the Proc
+ * all media object manipulation, deciding and configuration is the Steam
    Layer's job
  * extensible by plugins on all levels, highly configurable, but not totally
    componentized (micro kernel) architecture

doc/devel/rfc/DesignRenderNodesInterface.txt

@@ -9,7 +9,7 @@
 Design the Render Nodes interface
 ---------------------------------
 In the current design, the low-level model is comprised of "Render Nodes";
-Proc-Layer and Backend carry out some colaboration based on this node network.
+Stean-Layer and Vault carry out some colaboration based on this node network.
  +
 Three different interfaces can be identified
  * the node wiring interface
@@ -19,8 +19,8 @@ Three different interfaces can be identified
 
 Description
 ~~~~~~~~~~~
-Render Nodes are created and wired by the Builder in the Proc-Layer. On the
+Render Nodes are created and wired by the Builder in the Steam-Layer. On the
-other hand, the rendering process is controlled by the backend, which also
+other hand, the rendering process is controlled by the vault layer, which also
 provides the implementation for the individual data processing tasks. To create
 a result, output nodes are ''pulled'' via the invocation interface, resulting
 in the affected nodes to recursively pull their predecessor(s). In the course
@@ -28,8 +28,8 @@ of this call sequence, the nodes activate their processing function to work on
 a given set of buffers. Moreover, we plan to use the render network also for
 gathering statistics.
 
-'''Note''': Render Node is an internal interface used by Proc-Layer and
+'''Note''': Render Node is an internal interface used by Steam-Layer and
-   activated by the Backend. Plugins are planned to be added via Adapter nodes.
+   activated by the Vault. Plugins are planned to be added via Adapter nodes.
    Thus the Render Node interface needs ''not'' to be exported.
 
 
@@ -73,8 +73,8 @@ the processing interface
 the individual nodes are configured to call a plain-C {{{process()}}} function
 and provide an array of buffer pointers to be used within this function. For
 the purpose of invoking actual data processing, it is irrelevant if this
-function is implemented somewhere in the backend or provided by a plugin. At
+function is implemented somewhere in the vault layer or provided by a plugin.
-this point, no type- and other meta-information is passed, rather the
+At this point, no type- and other meta-information is passed, rather the
 processing function is supposed to do The Right Thing ^TM^
 
 
@@ -84,7 +84,7 @@ Tasks
  * What services do we expect from Render Nodes. What do we plan to do with a
    render node?
  * What different kinds (if any) of Render Nodes can be foreseen?
- * order the required functionality by Proc / Backend. Find out specific
+ * order the required functionality by Steam / Vault. Find out specific
    implementation constraints.
  * work out a design based on this informations
 
@@ -102,10 +102,9 @@ The purpose of this Design Entry is to give a summary; the questions and the
 details of carrying out the operations are much more involved.
  +
 Please see the
-http://www.lumiera.org/wiki/renderengine.html#Rendering[Proc-Layer impl
+http://www.lumiera.org/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)]
-documentation (TiddlyWiki)] and the
+and the
-http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod
+http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code]
-.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code]
 for details
 (and/or contact Ichthyo for in-depth discussion of those technical details)
 

doc/devel/rfc/EDLsAreMetaClips.txt

@@ -105,7 +105,7 @@ Comments
   for sure. We always used the term '''meta-clip''' for this feature, thus I
   edited the headline (I hope you don't mind).
 * Regarding the implementation, I choose a slightly different approach for the
-  proc layer (actually, it's not yet there, but planned right from start, as I
+  ``proc layer'' (actually, it's not yet there, but planned right from start, as I
   consider this meta-clip feature to be of uttermost importance): I'd prefer to
   add it at the level of the media source which is used by a clip. The
   rationale is, that at the level of the clip, there is no (or almost no)
@@ -139,7 +139,7 @@ Comments
    This is a real threat (see Cinelerra), but not limited to meta-clips. It is
    especially important, as you can expect users to work for months or years
    with a single session. Thus the integrity of the session is a value to be
-   protected. That's the rationale why I put up the constraint in the proc
+   protected. That's the rationale why I put up the constraint in the steam
    layer that all important objects can only be created or re-created by some
    specialized factory, which in turn has the responsibility of never creating
    a corrupted object.

doc/devel/rfc/EngineInterfaceOverview.txt

@@ -41,7 +41,7 @@ Render Process
 ~~~~~~~~~~~~~~
 The render process brackets an ongoing calculation as a whole. It is not to be
 confused with a operating system process or thread; rather it is a point of
-reference for the relevant entities in the GUI and Proc-Layer in need to
+reference for the relevant entities in the GUI and Steam-Layer in need to
 connect to such a "rendering", and it holds the specific definitions for this
 calculation series. A render process
 _corresponds to a single data stream_ to be rendered. Thus, when the play

doc/devel/rfc/FeatureBundle_PluggableModules.txt

@@ -112,7 +112,7 @@ individual Extension point to define when a Feature Bundle is fully usable,
 partially usable or to be rejected. For example, an
 "Effect" Feature Bundle may be partially usable, even if we can't load any
  "ProcFunction" for
-the current platform, but it will be unusable (rejected) if the proc layer
+the current platform, but it will be unusable (rejected) if the steam layer
 can't access the properties describing the media stream type this effect is
 supposed to handle.
 

doc/devel/rfc/LumieraForwardIterator.txt

@@ -115,7 +115,7 @@ APIs should be written such as not tie them to the current implementation.
 Exposing iterators is known to create a strong incentive in this direction and
 thus furthers the creation of clean APIs.
 
-Especially in Proc-Layer we utilise already several iterator implementations,
+Especially in Steam-Layer we utilise already several iterator implementations,
 but without an uniform concept, these remain just slightly disguised
 implementation types of a specific container. Moreover, the STL defines various
 and very elaborate iterator concepts. Ichthyo considers most of these an

doc/devel/rfc/MarbleMode.txt

@@ -101,7 +101,7 @@ Tasks
  * make locked-together transports work
    * in the GUI (transport controls)
    * for coordinating the corresponding playback/render schedules (playback
-     controller, which is located in the backend according to our current
+     controller, which is located in the core according to our current
      planning)
 
 

doc/devel/rfc/ProcBuilder.txt

@@ -1,5 +1,5 @@
-Design Process: Builder within the Proc-Layer
+Design Process: Builder within the Steam-Layer
-=============================================
+==============================================
 
 [grid="all"]
 `------------`-----------------------
@@ -8,15 +8,15 @@ Design Process: Builder within the Proc-Layer
 *Proposed by*   link:Ichthyostega[]
 -------------------------------------
 
-Builder within the Proc-Layer
+Builder within the Steam-Layer
------------------------------
+------------------------------
-One of the core ideas of the Proc-Layer (as being implemented since summer '07
+One of the core ideas of the Steam-Layer (as being implemented since summer '07
 by Ichthyo) is the use of the Builder-pattern to achieve a separation between
 high-level view and low-level view.
 
 Description
 ~~~~~~~~~~~
-The Proc-Layer differentiates into a high-level view, which models the
+The Steam-Layer differentiates into a high-level view, which models the
 properties of the problem domain (manipulating media objects), and a low-level
 model, which is a network of render nodes and will be optimized for processing
 efficiency.

doc/devel/rfc/ProcHighLevelModel.txt

@@ -6,14 +6,14 @@
 -------------------------------------
 
 
-High-level model in the Proc-Layer
+High-level model in the Steam-Layer
-----------------------------------
+-----------------------------------
 
 The purpose of this link:DesignProcess[] entry is to collect together
 informations regarding the design and structure of the high-level model of
-Lumiera's Proc-Layer. Most of the information presented here is already written
+Lumiera's Steam-Layer. Most of the information presented here is already written
 down somewhere, in the
-http://www.lumiera.org/wiki/renderengine.html#SessionOverview[Proc-Layer
+http://www.lumiera.org/wiki/renderengine.html#SessionOverview[Development
 TiddlyWiki] and in source code comments. This summer, we had quite some
 discussions regarding meta-clips, a *container* concept and the arrangement of
 tracks, which further helped to shape the model as presented here.
@@ -195,7 +195,7 @@ Pros
 Cons
 ^^^^
 
- * very tightly coupled to the general design of the Proc-Layer. Doesn't make
+ * very tightly coupled to the general design of the Steam-Layer. Doesn't make
    much sense without a Builder and a Rules-based configuration
  * not all semantic constraints are enforced structurally. Rather, it is
    assumed that the builder will follow certain patterns and ignore non

doc/devel/rfc/ProcPlacementMetaphor.txt

@@ -6,16 +6,16 @@
 -------------------------------------
 
 
-Placement Metaphor used within the high-level view of Proc-Layer
+Placement Metaphor used within the high-level view of Steam-Layer
-----------------------------------------------------------------
+-----------------------------------------------------------------
 besides the [wiki:self:../ProcBuilder Builder], one of the core ideas of the
-Proc-Layer (as being currently implemented by Ichthyo) is to utilize
+``Proc-Layer'' (as being currently implemented by Ichthyo) is to utilize
 _Placement_ as a single central metaphor for object association, location and
 configuration within the high-level model. The intention is to prefer _rules_
 over fixed _values._ Instead of ``having'' a property for this and that, we
 query for information when it is needed.
 
-The proposed use of *Placement* within the proc layer spans several,
+The proposed use of *Placement* within the steam layer spans several,
 closely related ideas:
 
  * use the placement as a universal means to stick the "media objects" together

doc/devel/rfc/Roadmap-first.txt

@@ -32,8 +32,8 @@ designed, the most important interfaces between the parts of the application
 exist in a first usable version, and all the facilities on the rendering code
 path are provided at least in a dummy version and are '''capable of cooperating
 to create output'''. Based on Lumiera's design, this also means that the basic
-frame cache in the backend is working. And it means that a media asset and a
+frame cache in the vault layer is working. And it means that a media asset and
-clip can be added to the internal session representation, which is then handed
+a clip can be added to the internal session representation, which is then handed
 over to the builder. Probably it's a good idea to include basic
 playback/display of the rendered frames within the GUI while they are created.
 

doc/devel/rfc/SchedulerRequirements.txt

@@ -159,13 +159,13 @@ Rationale
 ---------
 //rationale: Give a concise summary why it should be done *this* way:
 We use a scheduler to gain flexibility in controlling various aspects of computation and I/O usage.
-Moreover, we turn the scheduler into an interface between Backend and Proc-Layer; while the exact
+Moreover, we turn the scheduler into an interface between the Vault and Steam-Layer; while the exact
 outfitting of the individual jobs highly depends on internals of the Session and Engine models,
 the properties of _actual job execution_, closely related to system programming are akin
-to the Backend. The actual requirements outlined in this RfC are derived from the internals
+to the Vault. The actual requirements outlined in this RfC are derived from the internals
 of the player implementation, while _the way_ these requirements are defined, and especially
 the aspects _omitted_ from specification are derived from knowledge regarding the possible
-scheduler and backend implementation.
+scheduler and vault layer implementation.
 
 
 //Conclusion

doc/devel/rfc/StreamTypeSystem.txt

@@ -14,7 +14,7 @@ Stream Type System
 
 ********************************************************************************
 .Abstract
-Especially in the Proc-Layer, within the Builder and at the interface to the
+Especially in the Steam-Layer, within the Builder and at the interface to the
 Engine we need sort of a framework to deal with different »kinds« of
 media streams. +
 This is the foundation to be able to define what can be connected and to
@@ -98,9 +98,9 @@ _library_ routines, which also yield a _type classification system_ suitable
 for their intended use. Most notably, for raw sound and video data we use the
 http://gmerlin.sourceforge.net/[GAVL] library, which defines a fairly complete
 classification system for buffers and streams. For the relevant operations in
-the Proc-Layer, we access each such library by means of a Façade; it may sound
+the Steam-Layer, we access each such library by means of a Façade; it may sound
 surprising, but actually we just need to access a very limited set of
-operations, like allocating a buffer. _Within_ the Proc-Layer, the actual
+operations, like allocating a buffer. _Within_ the Steam-Layer, the actual
 implementation type is mostly opaque; all we need to know is if we can connect
 two streams and get an conversion plugin.
 
@@ -220,7 +220,7 @@ Comments
 --------
 //comments: append below
 As usual, see the
-http://www.lumiera.org/wiki/renderengine.html#StreamType[Proc-Layer impl doku]
+http://www.lumiera.org/wiki/renderengine.html#StreamType[Development internal doc]
 for more information and implementation details.
 
 Practical implementation related note: I found I was blocked by this one in
@@ -249,7 +249,7 @@ number, plus adding the capabilitiy of per frame metadata. This indices get
 abstracted by "indexing engines" it will be possible to have different kinds of
 indices over one file (for example, one enumerating single frames, one
 enumerating keyframes or gops). Such a indexing engine would be also the place
-to attach per media metadata. From the proc layer it can then look like `struct
+to attach per media metadata. From the steam layer it can then look like `struct
 frameinfo* get_frame(unsigned num)` where `struct frameinfo` (not yet defined)
 is something like `{ void* data; size_t size; struct metadata* meta; ...}` +
  -- link:ct[] 2008-10-06

doc/devel/rfc/TimelineSequenceOutput.txt

@@ -79,7 +79,7 @@ PlayController:: coordinating playback, cueing and rewinding of a
  _PlayheadCursor_ (or multiple in case there are multiple views and or
  monitors), and at the same time directing a render process to deliver the
  media data needed for playback. Actually, the implementation of the
- PlayController(s) is assumed to live in the backend.
+ PlayController(s) is assumed to live in the application core.
 
 RenderTask:: basically a !PlayController, but collecting output
  directly, without moving a !PlayheadCursor (maybe a progress indicator) and
@@ -148,7 +148,7 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline,
 
 Tasks
 ^^^^^
- * Interfaces on the GUI and Proc level need to be fully specified.
+ * Interfaces on the Stage and Steam level need to be fully specified.
    Especially, "Timeline" is now promoted to be a new top-level entity within
    the Session
  * communication between the PlayController(s) and the GUI need to be worked

doc/technical/backend/index.txt

@@ -1,7 +1,7 @@
-Technical Documentation: Backend
+Technical Documentation: Vault
-================================
+==============================
 
-Here we collect bits of technical documentation for the Backend.
+Here we collect bits of technical documentation for the Vault-Layer.
 
 For now, we have:
 

doc/technical/code/linkingStructure.txt

@@ -245,12 +245,12 @@ to comply to that contract superficially. Dealing with the entities involved in
 effectively involves the internal functions of both sides. Which is in contradiction to a
 ``clean'' layer hierarchy.
 
-For a more tangible example, lets assume our backend has to do some work on behalf of the GUI;
+For a more tangible example, lets assume our vault layer has to do some work on behalf of the GUI;
-so the backend offers a contract to outline the properties of stuff it can work on. In compliance
+so the vault offers a contract to outline the properties of stuff it can work on. In compliance
-with this contract, the GUI hands over some data entities to the backend to work on -- but by their
+with this contract, the GUI hands over some data entities to the vault to work on -- but by their
-very nature, these data entities are and always remain GUI entities. When the backend invokes compliant
+very nature, these data entities are and always remain GUI entities. When the vault invokes compliant
 operations on these entities, it effectively invokes functionality implemented in the GUI. Which
-makes the backend _binary dependent on the GUI_.
+makes the vault layer _binary dependent on the GUI_.
 
 While this problem can not be resolved in principle, there are ways to work around it, to the degree
 necessary to get hierarchically ordered binary dependencies -- which is what we need to make a lower
@@ -519,19 +519,19 @@ Relative dependency location
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Locating binary dependencies relative to the executable (as described above) gets complicated when several
 of _our own dynamically linked modules_ depend on each other transitively. For example, a plug-in might
-depend on `liblumierabackend.so`, which in turn depends on `liblumierasupport.so`. Now, when we link
+depend on `liblumieravault.so`, which in turn depends on `liblumierasupport.so`. Now, when we link
 `--as-needed`, the linker will add the direct dependency, but omit the transitive dependency on the
 support library. Which means, at runtime, that we'd need to find the support library _when we are
-about to load the backend library_. With the typical, external libraries already installed to the
+about to load the vault layer library_. With the typical, external libraries already installed to the
 system this works, since the linker has built-in ``magic'' knowledge about the standard installation
 locations of system libraries. Not so for our own loadable components -- recall, the idea was to provide
 a self-contained directory tree, which can be relocated in the file system as appropriate, without the
 need to ``install'' the package officially. The GNU dynamic linker can handle this requirement, though,
 if we supply an additional, relative search information _with the library pulling in the transitive
-dependency_. In our example, `liblumierabackend.so` needs an additional search path to locate
+dependency_. In our example, `liblumieravault.so` needs an additional search path to locate
-`liblumierasupport.so` _relative_ to the backend lib (and not relative to the executable). For this
+`liblumierasupport.so` _relative_ to the vault layer lib (and not relative to the executable).
-reason, our build system by default supplies such a search hint with every Lumiera lib or dynamic
+For this reason, our build system by default supplies such a search hint with every Lumiera lib or
-module -- assuming that our own shared libraries are installed into a subdirectory `modules` below
+dynamic module -- assuming that our own shared libraries are installed into a subdirectory `modules` below
 the location of the executable; other dynamic modules (plug-ins) may be placed in sibling directories.
 So, to summarise, our build defines the following `RPATH` and `RUNPATH` specs:
 

doc/technical/gui/CodePolicy.txt

@@ -20,7 +20,7 @@ It is strictly prohibited to spawn other threads from within the event loop.
 We hold up a strict distinction between the _UI mechanics_ and the _core editing
 concerns_. The latter _must not be implemented within the UI-Layer._ Rather, you need
 to send an `act(CommandID)` message over the UI-Bus, which causes the corresponding
-Proc-Layer command script to be dispatched within the Session thread. It is good
+Steam-Layer command script to be dispatched within the Session thread. It is good
 practice to give an immediate visual clue regarding the fact of sending such
 a command (e.g. pressing a button). But be prepared that the actual feedback
 of invoking a command happens asynchronously.
@@ -32,7 +32,7 @@ into the widgets. However, some widgets or controllers are special, insofar they
 correspond to and reflect some entities within the _Session model._ These special
 entities must be implemented as subclasses of `gui::model::Tangible`. These are
 always connected to the UI-Bus, and they are populated and mutated by receiving
-diff messages pushed up from the Proc-Layer.
+diff messages pushed up from the Steam-Layer.
 
 There is an _inner circle_ of UI backbone services. These are all mutually dependent
 on each other and their start-up sequence is intricate. Implement global and cross-cutting

doc/technical/gui/GuiConnect.txt

@@ -33,7 +33,7 @@ interface to collaborate.
 
 We may escape from that dichotomy when we cease to _rely on data as the fundamental substrate of our system._
 To collaborate, both parts still need to share a structure, yet it suffices for this structure to be a _common
-understanding:_ both the UI-Layer and the Proc-Layer need to share a common understanding how the parts of a editing
+understanding:_ both the UI-Layer and the Steam-Layer need to share a common understanding how the parts of a editing
 session can be arranged. Yet they do not need to share a _common data representation_ of the session.
 
 The consequence is that both sides, ``the core'' and ``the UI'' remain autonomous within their realm. For some concerns, namely _the core concerns,_ that is editing, arranging, processing, the core is in charge and has absolute authority.
@@ -46,17 +46,17 @@ The UI reflects these changes into _its own understanding and representation,_ w
 widgets. When the user interacts with these structures of the presentation layer, *action command messages* are generated,
 using the element-IDs to designate the arguments of the intended operation. Acting on these messages again causes reaction and change in the core, which is reflected back in the form of further diff messages.
 
-Anatomy of the Proc/GUI interface
+Anatomy of the Steam/Stage interface
----------------------------------
+------------------------------------
 - the `GuiFacade` is used as a general lifecycle facade to start up the GUI and to set up the »Layer Separation
-  Interfaces«. The `GuiFacade` is implemented by a class _in Proc-Layer_ and loads the Lumiera GTK-UI as a plug-in.
+  Interfaces«. The `GuiFacade` is implemented by a class _in Steam-Layer_ and loads the Lumiera GTK-UI as a plug-in.
 - once the UI is running, it exposes the `GuiNotificationFacade`, to allow pushing state and structure updates up into
   the user interface.
 - in the opposite direction, for initiating actions from the UI, the Session Subsystem opens the `SessionCommandFacade`,
   which can be considered __ ``the'' public session interface.__
 
 Both these primary interfaces operate *message based.* As immediate consequence, these interfaces are comparatively
-narrow, and interactions can easily be serialised, enqueued and dispatched. On the Proc-Layer side, the `ProcDispatcher`
+narrow, and interactions can easily be serialised, enqueued and dispatched. On the Steam-Layer side, the `ProcDispatcher`
 coordinates command execution and the _Builder run_ to derive the consequences of those session command invocations.
 And within the UI, the GTK-Event loop runs likewise single threaded, and the Notification facade automatically
 dispatches any invocation into the UI thread.

doc/technical/infra/TestSupport.txt

@@ -48,7 +48,7 @@ difficulties with tainted state.
 Test classes are organised into a tree closely mirroring the main application source
 code tree. Large sections of this test tree are linked together into *test libraries*.
 Some of these are linked against a specific (sub)scope of the application, like e.g.
-only against the support library, the application framework or the backend. Since we
+only against the support library, the application framework or the vault. Since we
 use _strict dependencies_, this linking step will spot code not being placed at the
 correct scope within the whole system. As a final step, the build system creates a
 *test runner* application (`target/test-suite`), which links dynamically against _all_
@@ -188,7 +188,7 @@ Options for running the Test Script
 
   (cd target; TESTSUITES=41 VALGRINDFLAGS=DISABLE TESTMODE=FAST+FIRSTFAIL ../tests/test.sh)
   
-. invoking the buildsystem, rebuilding if necessary, then invoking just the proc-layer test collections::  
+. invoking the buildsystem, rebuilding if necessary, then invoking just the steam-layer test collections::  
 
   scons VALGRIND=false TESTSUITES=4 check
 
@@ -239,9 +239,9 @@ The currently employed numbering scheme is as follows
 |01 |Infrastructure, package consistency
 |10 |Basic support library functionality
 |20 |Higher level support library services
-|30 |Backend Unit tests
+|30 |Vault Layer Unit tests
-|40 |Proc Layer Unit tests
+|40 |Steam Layer Unit tests
-|50 |User interface Unit tests (Gui, Scripting)
+|50 |Stage Layer Unit tests (Gui, Scripting)
 |60 |Component integration tests
 |70 |Functionality tests on the complete application
 |80 |Reported bugs which can be expressed in a test case

doc/technical/library/index.txt

@@ -12,7 +12,7 @@ over time.
 Interface Library
 -----------------
 The Lumiera Application is designed deliberately in a way to be controllable by scripts. All of
-the Session, the models and the backend are fully operational without the GUI. Any significant
+the Session, the models and the vault are fully operational without the GUI. Any significant
 functionality can be addressed through the primary Façade Interfaces.
 
 But, in order to make such an open and extensible application a reality, we need to build up

doc/technical/overview.txt

@@ -214,7 +214,7 @@ integration::
  The player cares for the necessary integration with the other subsystems
 + 
 it consults the _Output Management,_ retrieves the necessary informations from the _Session_
-and coordinates the forwarding of Backend calls.
+and coordinates the forwarding of Vault-Layer calls.
  
 time quantisation::
  The player translates continuous time values into discrete frame counts.
@@ -244,7 +244,7 @@ and notifies any attached _change listeners_.
 
 .play process
 Ongoing effort to calculate a stream of frames for playback or rendering. +
-The play process is an conceptual entity linking together several activities in the backend
+The play process is an conceptual entity linking together several activities in the vault
 and the render engine. It maintains a registration entry for the process to keep track of
 associated entities, resources allocated and calls dispatched as a consequence. Besides
 each play process is wired to at leas one play-controller acting as frontend interface
@@ -255,7 +255,7 @@ necessary to make the stream of calculations actually happen. The play process c
 within the player subsystem is largely comprised of organisational concerns and not especially
 performance critical.
 
-- the backend is responsible for dispatching the calculation stream and scheduling calculation jobs
+- the vault is responsible for dispatching the calculation stream and scheduling calculation jobs
 - the render engine has the ability to carry out individual frame calculations
 - the OutputSlot exposed by the output manager is responsible for accepting timed frame delivery
 
@@ -300,8 +300,8 @@ dumb. Higher level management will be done by the Schedulers and Jobs.
 Engine Interface
 ~~~~~~~~~~~~~~~~
 While on itself just a thin interface and adaptation layer forwarding calls to
-the primary backend facilities, the Engine Interface is the primary point of service
+the primary vault facilities, the Engine Interface is the primary point of service
-accessed by Proc-Layer to use the backend services for rendering content.
+accessed by Steam-Layer to use the vault layer services for rendering content.
 
 .Calculation Streams
 The Engine Interface is cast in terms of an _calculation stream_ entity. This is
@@ -1008,7 +1008,7 @@ CLib wrappers
 
 Some wrapers for the C memory management functions malloc, calloc, realloc and
 free which never fail. In case of an error the resourcecollector in the
-backend is invoked to free resources or doing an emergency shutdown.
+vault is invoked to free resources or doing an emergency shutdown.
 
 Safe wrapers for some string functions from the C-library which also never
 fail. NULL strings are propagated to "" empty strings.

doc/technical/proc/index.txt

@@ -1,11 +1,11 @@
-Technical Documentation: Proc-Layer
+Technical Documentation: Steam-Layer
-===================================
+====================================
 
-Eventually, this section will hold technical documentation for the Proc-Layer.
+Eventually, this section will hold technical documentation for the Steam-Layer.
 
-Proc-Layer TiddlyWiki
+Development Scrapbook TiddlyWiki
----------------------
+--------------------------------
-Hermann Voßeler, core developer of the Proc-Layer uses an separate embedded wiki
+Hermann Voßeler, core developer of the Steam-Layer uses an separate embedded wiki
 for his day-to-day design sketches, notes and also for the more persistent planning.
 This *TiddlyWiki* is a nifty JavaScript wiki embedded in a single HTML page; as such
 it lives right within the source tree, where it can be worked on alongside with the

doc/user/intro/intro.txt

@@ -215,7 +215,7 @@ In this section, we discuss the user's perspective when working with the GUI.
 Although Lumiera will initially ship with a standard, default GUI, we do not presume that this GUI will be suitable for all uses.
 We expect there to be multiple, different GUIs, each designed for different
 kinds of tasks.  We expect that some of these will be written by users, and the
-proc-layer is designed to facilitate this easily.
+steam-layer is designed to facilitate this easily.
 
 Indeed, Lumiera can even work
 satisfactorily without a GUI, for example, for special purposes
@@ -360,8 +360,8 @@ The material in this section provides a cursory view of features not required by
 a typical user, but of more importance to people looking under the hood
 (advanced users, software developers)
 
-Most of the material in this section is to be found in the Proc-layer and in the
+Most of the material in this section is to be found in the Steam-Layer and in the
-Backend.
+Vault.
 
 
 
@@ -449,11 +449,11 @@ Input-Output Subsystem
 
 Lumiera will process large quantities of data and it is of critical importance
 to perform this efficiently.  The input and output subsystem are all processed
-in the backend, in fact, this is one very important function provided by the
+in the vault layer, in fact, this is one very important function provided by the
 back end.
 
 The typical Lumiera user will have many clips, in various configurations located
-at various places.  All this data will have to be stored by the backend,
+at various places.  All this data will have to be stored by the vault layer,
 moreover all this data will have to be rapidly retrieved from storage and
 provided to the user. The demands on memory are high: huge chunks of data,
 that can be quickly stored and equally quickly fetched, even if stored over
@@ -465,11 +465,11 @@ Lumiera will break down processes that need to be processed into smaller units
 called _frame job_. Typically, there will be many hundreds of jobs waiting for
 processing at any one time. These jobs are queued for processing and the order
 in which this is performed is managed by the _scheduler_.
-This is all done in the backend.
+This is all done in the vault layer.
 
-Apart from memory, the backend will be responsible for accessing and saving
+Apart from memory, the vault will be responsible for accessing and saving
 files. It is essential to do this efficiently. This will be carried out
-in the backend using low-level mechanisms.
+in the vault layer using low-level mechanisms.
 
 // file handling
 //  vault, work, cache

src/backend/backend.c

@@ -1,5 +1,5 @@
 /*
-  Backend  -  common lumiera backend facilities
+  Backend  -  common lumiera vault layer facilities
 
   Copyright (C)         Lumiera.org
     2008,               Christian Thaeter <ct@pipapo.org>
@@ -22,7 +22,7 @@
 
 
 /** @file backend.c
- ** Lumiera Backend: implementation of global initialisation and services.
+ ** Lumiera Vault-Layer: implementation of global initialisation and services.
  */
 
 

src/backend/backend.h

@@ -1,5 +1,5 @@
 /*
-  BACKEND.h  -  common lumiera backend definitions
+  BACKEND.h  -  common lumiera vault definitions
 
   Copyright (C)         Lumiera.org
     2008,               Christian Thaeter <ct@pipapo.org>
@@ -22,7 +22,7 @@
 
 
 /** @file backend.h
- ** Lumiera Backend: global initialisation and definitions.
+ ** Lumiera Vault-Layer: global initialisation and definitions.
  */
 
 

src/backend/engine/job.cpp

@@ -63,8 +63,8 @@ namespace engine {
   
   /**
    * emit the VTable for JobClosure within this compilation unit,
-   * which is still part of the backend. The actual job implementation
+   * which is still part of the Vault. The actual job implementation
-   * classes are defined in the Proc-Layer
+   * classes are defined in the Steam-Layer
    */
   JobClosure::~JobClosure() { }
   

src/backend/engine/job.h

@@ -23,7 +23,7 @@
 
 /** @file job.h
  ** Definition of a render job.
- ** Jobs are defined within Proc-Layer and passed to the scheduler in the Back-end
+ ** Jobs are defined within Steam-Layer and passed to the scheduler in the Back-end
  ** for time bound invocation. This header defines the data structures used to describe
  ** a job, and the basic data structures used by the scheduler to keep track of individual
  ** jobs. Moreover, within the C++ part of this header, some classes are layered on top
@@ -147,16 +147,16 @@ typedef lumiera_jobDefinition* LumieraJobDefinition;
 
 
 /**
- * Description of a job. Jobs are passed by the Proc-Layer to the Back-End. 
+ * Description of a job. Jobs are passed by the Steam-Layer to the Back-End. 
  * 
  * This descriptor record is used by the scheduler to organise job invocation.
  * The actual job's definition, i.e. the invocation parameter and the closure
  * necessary to invoke the job as a function is embedded (by value)
  * into this descriptor.
  * 
- * @remarks all fields of interest only to the backend,
+ * @remarks all fields of interest only to the vault layer,
  *       except #jobDefinition, which is provided by and of
- *       interest to the Proc-Layer
+ *       interest to the Steam-Layer
  * @note while this descriptor as such is self-contained,
  *       the referred LumieraJobClosure needs to be allocated
  *       and managed separately. Indeed, this closure happens
@@ -167,7 +167,7 @@ struct lumiera_jobDescriptor_struct
     gavl_time_t deadline;                ///< given in real wall clock time
     JobState jobState;
     
-    lumiera_jobDefinition jobDefinition; ///< of interest only to Proc-Layer
+    lumiera_jobDefinition jobDefinition; ///< of interest only to Steam-Layer
     
     /* == Job prerequisites == */
     LList waiting;

src/backend/engine/scheduler-frontend.hpp

@@ -45,8 +45,8 @@ namespace engine {
   
   /**
    * Access point to the scheduler service provided by the back-end.
-   * Proc-Layer uses this service as the primary means of instructing
+   * Steam-Layer uses this service as the primary means of instructing
-   * the backend; suitably prepared and wired frame render jobs are
+   * the vault; suitably prepared and wired frame render jobs are
    * handed over to the scheduler for time-bound or bandwidth-controlled
    * execution
    * 
@@ -55,7 +55,7 @@ namespace engine {
    * @todo this is planned to become the frontend
    * to the render node network, which can be considered
    * at the lower end of the middle layer; the actual 
-   * render operations are mostly implemented by the backend
+   * render operations are mostly implemented by the vault layer
    * @todo define the low-level scheduler interface and hook in
    *       the necessary calls to implement this frontend.
    * ////////TODO WIP as of 9/2013

src/backend/enginefacade.hpp

@@ -24,7 +24,7 @@
 /** @file enginefacade.hpp
  ** Global control interface for the render engine subsystem.
  ** The render engine, as implemented in an combined effort by the
- ** Lumiera backend and some parts of Proc-Layer, can be started and
+ ** Lumiera Vault-Layer and some parts of Steam-Layer, can be started and
  ** stopped as a [Subsystem](\ref subsys.hpp) of the whole application.
  */
 
@@ -41,15 +41,15 @@ namespace backend {
   
   
   /**************************************************************//**
-   * Interface to the backend layer (render engine subsystem):
+   * Interface to the vault layer (render engine subsystem):
    * Global access point for starting the render engine subsystem and
    * for defining the public interface(s) for talking with the engine.
    * 
-   * While the engine is partially implemented relying on Proc-Layer 
+   * While the engine is partially implemented relying on steam-Layer 
    * operations, the general access point and the playback/render
-   * controller is considered part of the backend. This results in
+   * controller is considered part of the vault. This results in
-   * a "W"-shaped control flow: from GUI to backend to proc to
+   * a "W"-shaped control flow: from stage to vault to steam to
-   * backend, feeding resulting data to output.
+   * vault, feeding resulting data to output.
    * 
    */
   struct EngineFacade

src/backend/media-access-facade.cpp

@@ -50,14 +50,14 @@ namespace backend {
     if (isnil (name))
       throw Invalid ("empty filename passed to MediaAccessFacade.");
     
-    UNIMPLEMENTED ("delegate to backend: query accessability of file");
+    UNIMPLEMENTED ("delegate to vault: query accessability of file");
   }
   
   
   ChanDesc 
   MediaAccessFacade::queryChannel (MediaDesc& mHandle, uint chanNo)  const
   {
-    UNIMPLEMENTED ("delegate to backend: query channel information");
+    UNIMPLEMENTED ("delegate to vault: query channel information");
     ChanDesc nix;
     return nix;
   }

src/backend/media-access-facade.hpp

@@ -54,10 +54,10 @@ namespace backend {
   
   
   /**************************************************************//**
-   * Interface to the backend layer:
+   * Interface to the vault layer:
    * provides functions for querying (opening) a media file,
    * detecting the channels or streams found within this file etc. 
-   * Implementation delegating to the actual backend functions.
+   * Implementation delegating to the actual vault layer functions.
    * 
    * convention: data passed by pointer is owned by the originator;
    * it should be copied if needed beyond the control flow 

src/backend/netnodefacade.hpp

@@ -41,7 +41,7 @@ namespace backend {
   
   
   /**************************************************************//**
-   * Interface to the backend layer (renderfarm node):
+   * Interface to the vault layer (renderfarm node):
    * Global access point for starting a server listening on a TCP port
    * and accepting render tasks. Possibly such a server could also
    * use the backend file/media access functions to provide a media

src/backend/real-clock.cpp

@@ -25,9 +25,9 @@
  ** Implementation of simplified access to the current wall clock time.
  ** 
  ** @todo just a rough draft as of 2012 / 2017
- ** @todo the idea was that the backend has elaborate knowledge about
+ ** @todo the idea was that the vault has elaborate knowledge about
  **       timings and time progression; upper layers should thus be able
- **       to fulfil their timing needs by querying the backend
+ **       to fulfil their timing needs by querying the vault layer
  */
 
 

src/backend/real-clock.hpp

@@ -22,7 +22,7 @@
 
 /** @file real-clock.hpp
  ** Front-end for simplified access to the current wall clock time.
- ** The implementation relies on Lumiera backend functions to access the
+ ** The implementation relies on Lumiera vault functions to access the
  ** system clock with a sufficient level of precision. The result is
  ** delivered in lumiera's internal \link lib::time::Time time format \endlink
  **   

src/backend/scriptrunnerfacade.hpp

@@ -41,7 +41,7 @@ namespace backend {
   
   
   /*******************************************************************//**
-   * Interface to the backend layer (script runner):
+   * Interface to the vault layer (TODO 2018 really?) (script runner):
    * Global access point for starting a script within Lumiera application
    * context. 
    * 

src/backend/thread-wrapper.hpp

@@ -24,7 +24,7 @@
 
 /** @file thread-wrapper.hpp
  ** Convenience front-end for basic thread handling needs.
- ** The Lumiera backend contains a dedicated low-level thread handling framework,
+ ** The Lumiera vault contains a dedicated low-level thread handling framework,
  ** which is relevant for scheduling render activities to make best use of parallelisation
  ** abilities of the given system. Typically, the upper layers should not have to deal much
  ** with thread handling, yet at some point there is the need to implement a self contained
@@ -68,7 +68,7 @@ namespace backend {
   
   /************************************************************************//**
    * A thin convenience wrapper for dealing with threads,
-   * as implemented by the threadpool in the backend (based on pthread).
+   * as implemented by the threadpool in the vault (based on pthread).
    * Using this wrapper...
    * - helps with passing data to the function executed in the new thread
    * - allows to bind to various kinds of functions including member functions

src/backend/threadpool-init.hpp

@@ -22,12 +22,12 @@
 */
 
 /** @file threadpool-init.hpp
- ** Automatically bring up the threading management and threadpool in the backend.
+ ** Automatically bring up the threading management and threadpool in the vault layer.
  ** This works by registering a lifecycle callback, which is activated at the start
  ** of main or when running the testsuite. Similarly, a shutdown hook is registered.
  ** 
  ** @todo as of 1/10 it is not clear if this will be the final solution.
- **       Alternatively, we may rely on a subsystem "backend" or "threadpool"
+ **       Alternatively, we may rely on a subsystem "vault" or "threadpool"
  ** 
  ** @see threads.h
  ** @see thread-wrapper.hpp

src/backend/threads.h

@@ -73,7 +73,7 @@ enum lumiera_thread_class
 
     // .. various thread flags follow
     /**
-     * flag to let the decision to run the function in a thread open to the backend.
+     * flag to let the decision to run the function in a thread open to the vault.
      * depending on load it might decide to run it sequentially.
      * This has some constraints:
      * The Thread must be very careful with locking, better don't.

src/common/advice.hpp

@@ -76,7 +76,7 @@
  ** 
  ** @note as of 6/2010 this is an experimental setup and implemented just enough to work out
  **       the interfaces and gain practical usage experiences. Ichthyo expects this collaboration
- **       service to play a central role at various places within proc-layer.
+ **       service to play a central role at various places within steam-layer.
  ** @todo allow variables in binding patterns
  ** @todo use the lumiera MPool instead of heap allocations
  ** @todo consider to provide variations of the basic behaviour by policy classes

src/common/advice/binding.hpp

@@ -59,7 +59,7 @@
  **       obviously this is the foundation of a more generic system to deal with predicate terms.
  ** @note as of 4/2010 this is an experimental setup and implemented just enough to work out
  **       the interfaces. Ichthyo expects this collaboration service to play a central role
- **       at various places within proc-layer.
+ **       at various places within steam-layer.
  ** @todo for now, \em only the case of a completely constant (ground) pattern is implemented.
  **       Later we may consider to extend the binding patterns to allow variables, which, on match
  **       could be fed as parameters to the bound advice. But this extension requires to extend

src/common/advice/index.hpp

@@ -65,7 +65,7 @@
  ** 
  ** @note as of 4/2010 this is an experimental setup and implemented just enough to work out
  **       the interfaces. Ichthyo expects this collaboration service to play a central role
- **       later at various places within proc-layer.
+ **       later at various places within steam-layer.
  ** @note for now, _only_ the case of a completely constant (ground) pattern is implemented.
  **       Later we may consider to extend the binding patterns to allow variables. The mechanics
  **       of the index are designed right from start to support this case (and indeed the index

src/common/config-rules.hpp

@@ -53,7 +53,7 @@
  ** @see lumiera::Query
  ** @see mobject::session::DefsManager
  ** @see asset::StructFactory 
- ** @see config-resolver.hpp specialised setup for the Proc-Layer
+ ** @see config-resolver.hpp specialised setup for the Steam-Layer
  ** @see fake-configrules.hpp currently used dummy-implementation
  **
  */
@@ -146,7 +146,7 @@ namespace lumiera {
       };
     
     /** 
-     * the "front side" interface: the Proc-Layer code can
+     * the "front side" interface: the Steam-Layer code can
      * use this QueryHandler to retrieve instances of the
      * type TY fulfilling the given Query. To start with,
      * we use a mock implementation. 

src/common/query.hpp

@@ -63,7 +63,7 @@
  ** @see lumiera::QueryResolver
  ** @see mobject::session::DefsManager
  ** @see asset::StructFactory 
- ** @see config-resolver.hpp specialised setup for the Proc-Layer
+ ** @see config-resolver.hpp specialised setup for the Steam-Layer
  ** @see fake-configrules.hpp currently used dummy-implementation
  ** @see SessionServiceExploreScope
  ** @see PlacementIndexQueryResolver 

src/common/query/defs-manager-impl.hpp

@@ -28,7 +28,7 @@
  ** include to create explicit template instantiations with the concrete types to be used
  ** for definition and retrieval of default-configured objects.
  ** 
- ** For the standard use-case within the session / Proc-Layer, this is performed for the
+ ** For the standard use-case within the session / Steam-Layer, this is performed for the
  ** core MObject types, alongside with the definition of the generic config-query-resolver.
  ** 
  ** @see config-resolver.cpp definition of the explicit specialisations for the session 

src/gui/ctrl/bus-term.hpp

@@ -25,7 +25,7 @@
  ** Attachment point to the UI-Bus.
  ** Every gui::model::Tangible holds a BusTerm, which is linked
  ** to the Tangible's identity, and serves to relay interface actions
- ** towards the Proc-Layer, to remember state changes and to broadcast
+ ** towards the Steam-Layer, to remember state changes and to broadcast
  ** notifications. Moreover, the BusTerm is the service point
  ** to receive structural change messages.
  ** 
@@ -98,7 +98,7 @@ namespace ctrl{
    * intended for routing, broadcasting or forwarding. Effectively,
    * routing is determined from the context and meaning of a message,
    * where the _act_ and _note_ messages have an implicit receiver
-   * (either the Proc-Layer or the UI state manager), while the
+   * (either the Steam-Layer or the UI state manager), while the
    * _mark_ messages are always directed _downstream_ towards
    * some element.
    */

src/gui/ctrl/core-service.hpp

@@ -71,7 +71,7 @@
  ** messages, which can not be handled in a generic way on the Nexus:
  ** - *act* handles command invocation within the Session core, and
  **   is treated by [forwarding](\ref command-handler.hpp) it over the
- **   SessionCommand facade to the [Proc-Dispatcher](\ref proc-dispatcher.hpp)
+ **   SessionCommand facade to the [Steam-Dispatcher](\ref proc-dispatcher.hpp)
  ** - *note* observes and captures presentation state note messages, which
  **   are to be handled by a central presentation state manager (TODO 1/17).
  ** 
@@ -106,7 +106,7 @@ namespace ctrl{
    * Attachment point to »central services« within the UI-Bus.
    * This special implementation of the [BusTerm] interface receives and
    * handles those messages to be processed by centralised services:
-   * - commands need to be sent down to Proc-Layer
+   * - commands need to be sent down to Steam-Layer
    * - presentation state messages need to be recorded and acted upon.
    * As an object, CoreService encases the heart of the UI-Bus, the
    * \ref Nexus, and acts as "PImpl" for the gui::UiBus front-end.

src/gui/dialog/test-control.hpp

@@ -165,8 +165,8 @@ namespace dialog {
       
       
       /**
-       * Ticket #1099 : perform a dummy round-trip to verify Proc-GUI integration.
+       * Ticket #1099 : perform a dummy round-trip to verify Steam-Stage integration.
-       * This routine invokes the command `test_meta_displayInfo` and friends down in Proc-Layer,
+       * This routine invokes the command `test_meta_displayInfo` and friends down in Steam-Layer,
        * passing the settings from the radio buttons to select the flavour of feedback, and the text
        * for feedback content. The expected behaviour is for the invoked command to send a feedback
        * via UI-Bus towards the ErrorLogDisplay within the InfoboxPanel.
@@ -212,8 +212,8 @@ namespace dialog {
               trig_1_.set_use_underline();
               trig_1_.set_label ("_display text");
               trig_1_.property_xalign() = 0;
-              trig_1_.set_tooltip_markup (_("Trigger Proc-GUI <b>roundtrip</b>\n"
+              trig_1_.set_tooltip_markup (_("Trigger Steam-Stage <b>roundtrip</b>\n"
-                                            "Proc invokes GuiNotification::displayInfo"));
+                                            "Steam invokes GuiNotification::displayInfo"));
               
               level_warn_.join_group(level_info_);
               level_erro_.join_group(level_info_);
@@ -222,19 +222,19 @@ namespace dialog {
               trig_2_.set_use_underline();
               trig_2_.property_xalign() = 0;
               trig_2_.set_label ("mark _error");
-              trig_2_.set_tooltip_markup (_("trigger Proc-command, which in turn\n"
+              trig_2_.set_tooltip_markup (_("trigger Steam-command, which in turn\n"
                                             "sends an error state mark via UI-Bus"));
               
               trig_3_.set_use_underline();
               trig_3_.property_xalign() = 0;
               trig_3_.set_label ("mark _info");
-              trig_3_.set_tooltip_markup (_("trigger Proc-command, which in turn\n"
+              trig_3_.set_tooltip_markup (_("trigger Steam-command, which in turn\n"
                                             "sends an info state mark via UI-Bus"));
               
               trig_4_.set_use_underline();
               trig_4_.set_label ("_mark");
               trig_4_.property_xalign() = 0;
-              trig_4_.set_tooltip_markup (_("trigger Proc-command, which in turn\n"
+              trig_4_.set_tooltip_markup (_("trigger Steam-command, which in turn\n"
                                             "sends an <b>state mark</b> message, using\n"
                                             "the message action-ID from the combobox"));
               actionID_.append (cuString{MARK_Flash});

src/gui/gtk-base.hpp

@@ -111,14 +111,14 @@ namespace gui {
   
   /** The Lumiera GTK-GUI uses a thin proxy layer data model
    *  on top of the actual "high-level-model", which lives in the
-   *  Proc-Layer below. GUI operations interact with these proxy model
+   *  Steam-Layer below. Stage operations interact with these proxy
-   *  entities, which in turn forward the calls to the actual objects
+   *  model entities, which in turn forward the calls to the actual objects
-   *  in the Proc-Layer, through the Command system (which enables UNDO).
+   *  in the Steam-Layer, through the Command system (which enables UNDO).
    *  
    *  @todo: as of 1/2011 this connection between the GUI proxy model and
-   *         the Proc-Layer model needs to be set up. Currently, the GUI model
+   *         the Steam-Layer model needs to be set up. Currently, the GUI model
    *         entities are just created standalone and thus dysfunctional.
-   *  @todo: as of 11/2015 this connection between UI and Proc-Layer is actually
+   *  @todo: as of 11/2015 this connection between UI and Steam-Layer is actually
    *         in the works, and it is clear by now that we won't use proxy objects,
    *         but rather a generic bus-like connection and symbolic IDs to designate
    *         the model elements

src/gui/model/clip.hpp

@@ -22,7 +22,7 @@
 
 /** @file gui/model/clip.hpp
  ** Preliminary UI-model: a Proxy Clip object to base the GUI implementation on.
- ** Later this Clip object will be connected to the underlying model in Proc-Layer.
+ ** Later this Clip object will be connected to the underlying model in Steam-Layer.
  ** @warning as of 2016 this UI model is known to be a temporary workaround
  **          and will be replaced in entirety by UI-Bus and diff framework.
  */

src/gui/model/parent-track.hpp

@@ -22,7 +22,7 @@
 /** @file parent-track.hpp
  ** Preliminary UI-model: Definition of ParentTrack, a class which
  ** represents a base functionality for tracks and sequences which
- ** are also track parents. This class was intended to wraps proc layer data.
+ ** are also track parents. This class was intended to wraps steam layer data.
  ** @warning as of 2016 this UI model is known to be a temporary workaround
  **          and will be replaced in entirety by UI-Bus and diff framework.
  ** @deprecated the existing timeline implementation will be completely rewritten

src/gui/model/project.cpp

@@ -23,7 +23,7 @@
 
 /** @file project.cpp
  ** Preliminary UI-model: Implementation of Project, a class which
- ** stores project data, and wraps proc layer data.
+ ** stores project data, and wraps steam layer data.
  ** @warning as of 2016 this UI model is known to be a temporary workaround
  **          and will be replaced in entirety by UI-Bus and diff framework.
  ** 

src/gui/model/project.hpp

@@ -22,12 +22,12 @@
 
 /** @file project.hpp
  ** Preliminary UI-model: Definition of Project, a class which
- ** stores project data, and wraps proc layer data.
+ ** stores project data, and wraps steam layer data.
  ** @warning as of 2016 this UI model is known to be a temporary workaround
  **          and will be replaced in entirety by UI-Bus and diff framework.
  ** 
  ** @todo this solution was used to build the first outline of the UI.
- **       It needs to be reshaped into a connector to Proc-Layer  ///////////////TICKET #959
+ **       It needs to be reshaped into a connector to Steam-Layer  ///////////////TICKET #959
  */
 
 #ifndef PROJECT_HPP

src/gui/model/session-facade.cpp

@@ -26,7 +26,7 @@
  ** This header defines the basics of...
  ** 
  ** @note as of X/2014 this is complete bs
- ** @todo THE NAME IS UNFORTUNATE!!!! "SessionFacade" should rather be a facade in Proc!
+ ** @todo THE NAME IS UNFORTUNATE!!!! "SessionFacade" should rather be a facade in Steam!
  ** @todo WIP  ///////////////////////TICKET #
  ** 
  ** @see ////TODO_test usage example

src/gui/model/track.hpp

@@ -21,7 +21,7 @@
 */
 /** @file track.hpp
  ** Preliminary UI-model: Definition of Track, a class which
- ** represents a track, and wraps proc layer data
+ ** represents a track, and wraps steam layer data
  ** @warning as of 2016 this UI model is known to be a temporary workaround
  **          and will be replaced in entirety by UI-Bus and diff framework.
  ** @deprecated the existing timeline implementation will be completely rewritten

src/gui/ui-bus.hpp

@@ -123,7 +123,7 @@ namespace gui {
   namespace controller { 
     
     /**
-     * @todo needs to be reshaped for communication with Proc-Layer /////////////////TICKET #959
+     * @todo needs to be reshaped for communication with Steam-Layer ////////////////TICKET #959
      */
     class Controller
       {

src/gui/widget/timeline/timeline-header-container.hpp

@@ -64,7 +64,7 @@ namespace gui {
        *
        * @note This must be called when the track list changes
        * to synchronise the headers with the timeline body and
-       * the backend.
+       * the core data.
        */
       void update_headers();
       

src/include/dummy-player-facade.h

@@ -54,7 +54,7 @@ namespace lumiera {
     
     
     /**************************************************************//**
-     * Experimental Interface Proc-Layer (or maybe the backend?): 
+     * Experimental Interface Steam-Layer (or maybe the vault?): 
      * Global access point for starting a dummy playback, generating
      * some test image data for the GUI to display in a viewer window.
      * 
@@ -108,9 +108,9 @@ namespace lumiera {
          * the Process implementation via the Process handle,
          * without having to map each implementation-level function
          * into the dummy player interface. We can't access the
-         * implementation in Proc-Layer without this indirection
+         * implementation in Steam-Layer without this indirection
          * through a VTable, since a direct call would require
-         * us to link against liblumieraproc.so
+         * us to link against liblumierasteam.so
          */
         class ProcessImplementationLink
           : public lumiera_playprocess

src/include/gui-notification-facade.h

@@ -23,7 +23,7 @@
 /** @file gui-notification-facade.h
  ** Major public Interface of the Lumiera GUI. While from a user's point of view,
  ** the GUI controls the application and thus acts on its own, in fact the UI sends
- ** command messages to the Session subsystem in Proc-Layer. These commands cause
+ ** command messages to the Session subsystem in Steam-Layer. These commands cause
  ** changes in the session, which result in notification and structure change messages
  ** being pushed up asynchronously back into the UI. The GuiNotification interface
  ** abstracts this ability of the UI to receive such update messages. It is implemented

src/include/logging.h

@@ -74,7 +74,7 @@ NOBUG_CPP_DEFINE_FLAG           (all);
 NOBUG_CPP_DEFINE_FLAG_PARENT    ( debugging,                    all);
 /** debug logging for the main application starter */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (  main_dbg,                    debugging);
-/** base of debug logging for the backend */
+/** base of debug logging for the vault layer */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (  backend_dbg,                 debugging);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   file_dbg,                   backend_dbg);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   filehandle_dbg,             backend_dbg);
@@ -88,13 +88,13 @@ NOBUG_CPP_DEFINE_FLAG_PARENT    (    threads_dbg,               thread_dbg);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    threadpool_dbg,            thread_dbg);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   fileheader_dbg,             backend_dbg);
 
-/** base of debug logging for the proc layer */
+/** base of debug logging for the steam layer */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (  proc_dbg,                    debugging);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   command_dbg,                proc_dbg);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   session_dbg,                proc_dbg);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   player_dbg,                 proc_dbg);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   engine_dbg,                 proc_dbg);
-/** base of debug logging for the gui */
+/** base of debug logging for the stage layer */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (  gui_dbg,                     debugging);
 /** base if debug logging for the support library */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (  library_dbg,                 debugging);
@@ -123,7 +123,7 @@ NOBUG_CPP_DEFINE_FLAG_PARENT    ( logging,                      all);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (  progress,                    logging);
 /** progress log for the main starter */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   main,                       progress);
-/** progress log for the backend */
+/** progress log for the vault layer */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   backend,                    progress);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    file,                      backend);       //opening/closing files etc
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    mmap,                      backend);       //mmap errors
@@ -131,9 +131,9 @@ NOBUG_CPP_DEFINE_FLAG_PARENT    (    thread,                    backend);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (     threads,                  thread);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (     threadpool,               thread);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    fileheader,                backend);
-/** progress log for the proc layer */
+/** progress log for the steam layer */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   proc,                       progress);
-/** progress log for proc-layer command dispatch */
+/** progress log for steam-layer command dispatch */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    command,                   proc);
 /** progress log for session datastructure */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    session,                   proc);
@@ -181,7 +181,7 @@ NOBUG_CPP_DEFINE_FLAG_PARENT    (   mutex_sync,                 sync);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   cond_sync,                  sync);          //waiting and signalling condition vars
 /** base flag for memory related logging */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (  memory,                      logging);
-/** proc layer memory handling */
+/** steam layer memory handling */
 NOBUG_CPP_DEFINE_FLAG_PARENT    (   proc_mem,                   memory);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    mobject_mem,               proc_mem);
 NOBUG_CPP_DEFINE_FLAG_PARENT    (    builder_mem,               proc_mem);

src/include/play-facade.hpp

@@ -66,7 +66,7 @@ namespace lumiera {
     
     
     /**************************************************************//**
-     * Interface to the Player subsystem of Lumiera (Proc-Layer).
+     * Interface to the Player subsystem of Lumiera (Steam-Layer).
      * Global access point for starting playback and render processes,
      * calculating media data by running the render engine.
      * 

src/include/session-command-facade.h

@@ -32,7 +32,7 @@
  ** the structure of binding and invocation messages. This goes so far as to
  ** accept the command arguments for binding packaged as `Record<GenNode>`.
  ** For each command, there needs to be a registration record within the
- ** Proc-Layer implementation. The service implementation backing this
+ ** Steam-Layer implementation. The service implementation backing this
  ** facade indeed retrieves the corresponding proc::control::Command
  ** handles to perform the binding operation and hands them over
  ** to the ProcDispatcher for invocation.

src/lib/frameid.hpp

@@ -71,7 +71,7 @@ namespace lumiera {
    * Identification tuple for addressing frames unambiguously.
    * 
    * @todo currently (7/08) this is a dummy implementation to find out
-   *       what interface the Proc layer needs. Probably the backend will
+   *       what interface the Steam layer needs. Probably the vault layer will
    *       later on define what is actually needed; this header should then
    *       be replaced by a combined C/C++ header
    */

src/lib/safeclib.h

@@ -37,7 +37,7 @@ LUMIERA_ERROR_DECLARE(NO_MEMORY);
  * initialised and removed from it before shut down. Without resourcecollector
  * failed allocations will abort().
  * @param hook pointer to the resourcecollector_run function, must be of type
- *        lumiera_resourcecollector_run_fn but we don't want a dependency on backend in this header
+ *        lumiera_resourcecollector_run_fn but we don't want a dependency on vault in this header
  */
 void
 lumiera_safeclib_set_resourcecollector (void* hook);

src/lib/symbol.hpp

@@ -36,7 +36,7 @@
  ** we close the circle by allowing Symbol instances to be created from strings at runtime.
  ** 
  ** @remark this started on occasion 11/2008, just with a typedef to mark assumption on interfaces
- **   for rules based configuration in the Proc-Layer. Over time, conversions, comparison and
+ **   for rules based configuration in the Steam-Layer. Over time, conversions, comparison and
  **   hashcode implementation were added. It turned out that the most smooth integration in
  **   coding practice is achieved when allowing transparent conversion for Literal, but not
  **   for Symbol or std::string.

src/lib/time.h

@@ -36,9 +36,9 @@
  ** so that multiple output or rendering operations can use differing time origins
  ** and frame rates simultaneously on the same model.
  ** 
- ** The Lumiera backend functions mostly operate on raw frame counts, which in this
+ ** The Lumiera Vault Layer functions mostly operate on raw frame counts, which in
- ** model are defined to be a special kind of timecode, and thus dependent on a
+ ** this model are defined to be a special kind of timecode, and thus dependent on
- ** preceding time quantisation.
+ ** a preceding time quantisation.
  ** 
  ** 
  ** @see lib::time::Time

src/lib/time/formats.hpp

@@ -74,8 +74,8 @@ namespace time {
      * Frame count as timecode format.
      * An integral number used to count frames
      * can be used as a simple from of time code.
-     * Indeed the Lumiera backend mostly relies on
+     * Indeed the Lumiera vault layer mostly relies
-     * these frame counts. As with any timecode, the
+     * on these frame counts. As with any timecode, the
      * underlying framerate/quantisation remains implicit.
      */
     struct Frames

src/lib/time/quantiser.hpp

@@ -136,7 +136,7 @@ namespace time {
    * Simple stand-alone Quantiser implementation based on a constant sized gird.
    * This is a self-contained quantiser implementation without any implicit referral
    * to the Lumiera session. As such it is suited for simplified unit testing.
-   * @warning real GUI and Proc-Layer code should always fetch a quantiser from the
+   * @warning real GUI and Steam-Layer code should always fetch a quantiser from the
    * Session, referring to a pre defined TimeGrid. Basically, the overall purpose of
    * the time-quantisation framework is to enforce such a link to a distinct time scale
    * and quantisation, so to prevent "wild and uncoordinated" rounding attempts.

src/lib/visitor.hpp

@@ -37,7 +37,7 @@ Credits for many further implementation ideas go to
 
 /** @file visitor.hpp
  ** A library implementation of the *Visitor Pattern* tailored specifically
- ** to Lumiera's needs within the Proc Layer. Visitor enables *double dispatch*
+ ** to Lumiera's needs within the Steam Layer. Visitor enables *double dispatch*
  ** calls, based both on the concrete type of some target object and the concrete type of
  ** a tool object being applied to this target. The code carrying out this tool application
  ** (and thus triggering the double dispatch) need not know any of these concrete types and is

src/proc/asset.hpp

@@ -22,7 +22,7 @@
 
 /** @file asset.hpp
  ** @ingroup asset
- ** Proc-Layer Interface: Assets.
+ ** Steam-Layer Interface: Assets.
  ** Declares the Asset top level Interface, the Asset::Ident identification tuple
  ** and the asset::ID primary key wrapper. Normally, Assets should be handled
  ** using asset::PAsset, a ref counting smart pointer.

src/proc/asset/typed-id.hpp

@@ -57,12 +57,12 @@
 //#include <boost/operators.hpp>
 #include <memory>
 
-namespace lumiera{  ///////TODO: shouldn't that be namespace lib? or proc?
+namespace lumiera{  ///////TODO: shouldn't that be namespace lib? or steam?
 namespace query  {
   
   /**
    * Adapter for using this type as a \em primary type
-   * within Lumiera's Proc-Layer. Any such type is expected
+   * within Lumiera's Steam-Layer. Any such type is expected
    * to provide a specialisation, filling in the actual details
    * necessary to deal with objects of this type.
    * 

src/proc/assetmanager.hpp

@@ -21,7 +21,7 @@
 */
 
 /** @file assetmanager.hpp
- ** Proc-Layer Interface: Asset Lookup and Organisation.
+ ** Steam-Layer Interface: Asset Lookup and Organisation.
  ** Declares the AssetManager interface used to access individual 
  ** Asset instances.
  ** 

src/proc/cmd.hpp

@@ -1,5 +1,5 @@
 /*
-  CMD.hpp  -  Proc Command definition keys
+  CMD.hpp  -  Steam Command definition keys
 
   Copyright (C)         Lumiera.org
     2017,               Hermann Vosseler <Ichthyostega@web.de>
@@ -22,9 +22,9 @@
 
 
 /** @file cmd.hpp
- ** Common ID definitions for Proc-Layer commands.
+ ** Common ID definitions for Steam-Layer commands.
  ** This header is included when defining the actual command scripts, but also
- ** from all those UI elements to use and invoke the defined Proc-Layer commands.
+ ** from all those UI elements to use and invoke the defined Steam-Layer commands.
  ** @todo WIP 3/2017 early draft
  ** 
  ** @see command.hpp

src/proc/cmd/meta-cmd.cpp

@@ -1,5 +1,5 @@
 /*
-  MetaCmd  -  actual proc command scripts for internal meta and control activities
+  MetaCmd  -  actual steam command scripts for internal meta and control activities
 
   Copyright (C)         Lumiera.org
     2018,               Hermann Vosseler <Ichthyostega@web.de>
@@ -22,7 +22,7 @@
 
 
 /** @file meta-cmd.cpp
- ** Actual definition of Proc-Layer command scripts for meta/ctrl actions.
+ ** Actual definition of Steam-Layer command scripts for meta/ctrl actions.
  ** Any actions issued by the UI-Layer to control internal application state
  ** @todo WIP 8/2018 early draft
  ** 
@@ -92,7 +92,7 @@ COMMAND_DEFINITION (test_meta_activateContentDiff)
                       {
                         TODO ("send a population diff starting from scratch");
                         TODO ("activate life-update service within the session");
-                        // Temporary hack to get any meaningful UI <-> Proc communication
+                        // Temporary hack to get any meaningful UI <-> Steam communication
                         GuiNotification::facade().displayInfo(NOTE_INFO, "Request: population-Diff from Session.");
                       })
        .captureUndo ([]() -> bool
@@ -146,7 +146,7 @@ COMMAND_DEFINITION (meta_deactivateContentDiff)
   /* ===== Demo and Development ===== */
   
   /** DemoGuiRoundtrip: push a notification info message back up into the UI.
-   * @todo this is a demo mock setup to further development of the Proc-UI integration     //////////////////TICKET #1140 : prototypical Proc-GUI communication
+   * @todo this is a demo mock setup to further development of the Steam-Stage integration     //////////////TICKET #1140 : prototypical Steam-Stage communication
    */
 COMMAND_DEFINITION (test_meta_displayInfo)
   {
@@ -166,7 +166,7 @@ COMMAND_DEFINITION (test_meta_displayInfo)
   
   
   /** DemoGuiRoundtrip: send a `markError` message back up into the UI.
-   * @todo this is a demo mock setup to further development of the Proc-UI integration     //////////////////TICKET #1140 : prototypical Proc-GUI communication
+   * @todo this is a demo mock setup to further development of the Steam-Stage integration     //////////////TICKET #1140 : prototypical Steam-Stage communication
    */
 COMMAND_DEFINITION (test_meta_markError)
   {
@@ -187,7 +187,7 @@ COMMAND_DEFINITION (test_meta_markError)
   
   
   /** DemoGuiRoundtrip: send a `markNote` message back up into the UI.
-   * @todo this is a demo mock setup to further development of the Proc-UI integration     //////////////////TICKET #1140 : prototypical Proc-GUI communication
+   * @todo this is a demo mock setup to further development of the Steam-Stage integration     //////////////TICKET #1140 : prototypical Steam-Stage communication
    */
 COMMAND_DEFINITION (test_meta_markNote)
   {
@@ -208,7 +208,7 @@ COMMAND_DEFINITION (test_meta_markNote)
   
   
   /** DemoGuiRoundtrip: send a generic `mark` message with given _action ID_ back up into the UI.
-   * @todo this is a demo mock setup to further development of the Proc-UI integration     //////////////////TICKET #1140 : prototypical Proc-GUI communication
+   * @todo this is a demo mock setup to further development of the Steam-Stage integration     //////////////TICKET #1140 : prototypical Steam-Stage communication
    */
 COMMAND_DEFINITION (test_meta_markAction)
   {

src/proc/cmd/scope-cmd.cpp

@@ -1,5 +1,5 @@
 /*
-  ScopeCmd  -  actual proc command scripts for actions within model scope
+  ScopeCmd  -  actual steam command scripts for actions within model scope
 
   Copyright (C)         Lumiera.org
     2017,               Hermann Vosseler <Ichthyostega@web.de>
@@ -22,7 +22,7 @@
 
 
 /** @file scope-cmd.cpp
- ** Actual definition of Proc-Layer command scripts for actions within scope.
+ ** Actual definition of Steam-Layer command scripts for actions within scope.
  ** Here "scope" means a scope within the high-level model, which could be
  ** - a track or media bin
  ** - a clip

src/proc/cmd/sequence-cmd.cpp

@@ -1,5 +1,5 @@
 /*
-  SequenceCmd  -  actual proc command scripts for actions operating within a sequence
+  SequenceCmd  -  actual steam command scripts for actions operating within a sequence
 
   Copyright (C)         Lumiera.org
     2017,               Hermann Vosseler <Ichthyostega@web.de>
@@ -22,7 +22,7 @@
 
 
 /** @file sequence-cmd.cpp
- ** Actual definition of Proc-Layer command scripts for actions within a sequence.
+ ** Actual definition of Steam-Layer command scripts for actions within a sequence.
  ** Especially all those actions working within the track tree go into this file
  ** @todo WIP 4/2017 early draft
  ** 

src/proc/cmd/session-cmd.cpp

@@ -1,5 +1,5 @@
 /*
-  SessionCmd  -  actual proc command scripts for session-global actions
+  SessionCmd  -  actual steam command scripts for session-global actions
 
   Copyright (C)         Lumiera.org
     2017,               Hermann Vosseler <Ichthyostega@web.de>
@@ -22,7 +22,7 @@
 
 
 /** @file session-cmd.cpp
- ** Actual definition of Proc-Layer command scripts for session-global actions.
+ ** Actual definition of Steam-Layer command scripts for session-global actions.
  ** @todo WIP 3/2017 early draft
  ** 
  ** @see cmd.hpp

src/proc/common.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMON.hpp  -  global definitions and common types for the Proc-Layer
+  COMMON.hpp  -  global definitions and common types for the Steam-Layer
  
 
   Copyright (C)         Lumiera.org
@@ -25,9 +25,9 @@
 /** @file proc/common.hpp
  ** Basic set of definitions and includes commonly used together.
  ** Including common.hpp gives you a common set of elementary declarations
- ** widely used within the C++ code of the Proc-Layer. Besides that, this
+ ** widely used within the C++ code of the Steam-Layer. Besides that, this
  ** header is used to attach the doxygen documentation comments for all
- ** the primary Proc-Layer namespaces
+ ** the primary Stean-Layer namespaces
  ** 
  ** @see main.cpp
  ** 
@@ -53,26 +53,26 @@
 
 
 /**
- * Proc-Layer implementation namespace root.
+ * Steam-Layer implementation namespace root.
  * Lumiera's middle layer contains the core models, both
  * high-level (session) and low-level (render nodes), together with
  * the Builder to translate between those two models, the command frontend,
  * session support system, the playback-and-render-control subsystem and
  * the API and backbone of the renderengine. Most render implementation
- * code resides in the backend or is loaded from plug-ins though.
+ * code resides in the vault layer or is loaded from plug-ins though.
  */
 namespace proc { 
   
   
   
   /**
-   * The asset subsystem of the Proc-Layer.
+   * The asset subsystem of the Steam-Layer.
    */
   namespace asset { }
   
   
   /**
-   * Proc-Layer dispatcher, controller and administrative facilities.
+   * Steam-Layer dispatcher, controller and administrative facilities.
    */
   namespace control { }
   
@@ -80,7 +80,7 @@ namespace proc {
   /**
    * Playback and rendering control subsystem.
    * The so called "player" combines and orchestrates services from
-   * the engine, session and backend to perform playback or rendering
+   * the engine, session and vault to perform playback or rendering
    */
   namespace play { 
     
@@ -88,10 +88,10 @@ namespace proc {
   
   
   /**
-   * Render engine code as part of the Proc-Layer.
+   * Render engine code as part of the Steam-Layer.
    * Backbone of the engine, render nodes base and cooperation.
    * A good deal of the active engine code is outside the scope of the
-   * Proc-Layer, e.g. code located in backend services and plugins.
+   * Steam-Layer, e.g. code located in vault services and plugins.
    */
   namespace engine {
     

src/proc/config-resolver.cpp

@@ -22,7 +22,7 @@
 
 
 /** @file config-resolver.cpp
- ** Implementation of bindings between Proc-Layer objects and rules-based configuration.
+ ** Implementation of bindings between Steam-Layer objects and rules-based configuration.
  ** @todo draft from the early design phase of the Lumiera application. As of 2016, nothing
  **       was done on behalf of rules-based configuration, other then preparing the whole architecture
  **       for this capability. So this remains one of the most relevant goals of the Project.

src/proc/control/argument-erasure.hpp

@@ -22,7 +22,7 @@
 
 
 /** @file argument-erasure.hpp
- ** Implementation helper to bind Proc-Layer commands with arbitrary argument tuples
+ ** Implementation helper to bind Steam-Layer commands with arbitrary argument tuples
  ** @internal details of the [command handling framework](\ref command.hpp).
  */
 

src/proc/control/argument-tuple-accept.hpp

@@ -27,7 +27,7 @@
  ** accept a specifically typed binding or function call, as specified by the
  ** template parameters, or alternatively it can inherit a complete set of
  ** templated argument binding functions, assuming that the matching signature
- ** can be detected at runtime. These templates are used for the Proc-Layer
+ ** can be detected at runtime. These templates are used for the Steam-Layer
  ** command frontend, to bind to the actual command arguments.
  **   
  ** The AcceptArgumentBinding template allows to mix in a `bind(...)` function.
@@ -531,7 +531,7 @@ namespace control {
     { };
   
   
-  /** Helper Template for Proc-Layer control::Command : mix in a \c bind(...) function
+  /** Helper Template for Steam-Layer control::Command : mix in a \c bind(...) function
    *  @param SIG  function signature to mimic (regarding the arguments and return type)
    *  @param TAR  the target class providing a function \c bindArg(Tuple<Types<T1...> >)
    *  @param BASE the base class for inheritance chaining

src/proc/control/command-closure.hpp

@@ -23,7 +23,7 @@
 
 /** @file command-closure.hpp
  ** A closure enabling self-contained execution of commands within the ProcDispatcher.
- ** After defining a proc-layer command, at some point the function arguments
+ ** After defining a steam-layer command, at some point the function arguments
  ** of the contained operation are "closed" by storing concrete argument values.
  ** These values will be fed later on to the operation when the command is invoked.
  ** 

src/proc/control/command-def.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMAND-DEF.hpp  -  defining and binding a Proc-Layer command
+  COMMAND-DEF.hpp  -  defining and binding a Steam-Layer command
 
   Copyright (C)         Lumiera.org
     2009,               Hermann Vosseler <Ichthyostega@web.de>

src/proc/control/command-impl.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMAND-IMPL.hpp  -  Proc-Layer command implementation (top level)
+  COMMAND-IMPL.hpp  -  Steam-Layer command implementation (top level)
 
   Copyright (C)         Lumiera.org
     2009,               Hermann Vosseler <Ichthyostega@web.de>
@@ -24,7 +24,7 @@
 /** @file command-impl.hpp
  ** Top level of the command implementation. CommandImpl holds together
  ** the various data and sub-objects involved into the inner workings of a
- ** Proc-Layer command. It serves to implement a "command definition" (prototype)
+ ** Steam-Layer command. It serves to implement a "command definition" (prototype)
  ** as well as a concrete command instance. It is a data holder with a well defined
  ** identity and usually located within the (pooled) storage managed by the
  ** CommandRegistry. Client code gets access to a specific CommandImpl through
@@ -62,7 +62,7 @@ namespace control {
   
   
   /**
-   * Proc-Layer Command implementation.
+   * Steam-Layer Command implementation.
    * Data record holding together the parts necessary for command execution
    * - command operation functor
    * - a functor to UNDO the command effect

src/proc/control/command-instance-manager.hpp

@@ -23,7 +23,7 @@
 
 /** @file command-instance-manager.hpp
  ** Service to support forming and invocation of command instances for use by the UI.
- ** A *Proc-Layer command* is a functor, which can be parametrised with concrete arguments.
+ ** A *Steam-Layer command* is a functor, which can be parametrised with concrete arguments.
  ** Typically, these arguments are to be picked up from the actual usage context in the GUI.
  ** This creates the specific twist that possible command instances for invocation can and will
  ** be formed during an extended time period, non-deterministically -- since the actual context
@@ -40,7 +40,7 @@
  ** \par lifecycle
  ** There CommandInstanceManager is maintained by the SessionCommandService, which in turn is
  ** installed and removed by the implementation within ProcDispatcher. Its lifecycle is thus tied
- ** to the opening / closing of the Proc-Layer interface, as dictated by the Session lifecycle.
+ ** to the opening / closing of the Steam-Layer interface, as dictated by the Session lifecycle.
  ** When the current session is closed, all command instances "underway" will thus be discarded.
  ** 
  ** @see command-setup.cpp service implementation

src/proc/control/command-invocation.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMAND-INVOCATION.hpp  -  shortcuts and helpers for calling Proc-Layer commands
+  COMMAND-INVOCATION.hpp  -  shortcuts and helpers for calling Steam-Layer commands
 
   Copyright (C)         Lumiera.org
     2009,               Hermann Vosseler <Ichthyostega@web.de>

src/proc/control/command-mutation.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMAND-MUTATION.hpp  -  functor encapsulating the actual operation of proc-Command
+  COMMAND-MUTATION.hpp  -  functor encapsulating the actual operation of steam-Command
 
   Copyright (C)         Lumiera.org
     2009,               Hermann Vosseler <Ichthyostega@web.de>
@@ -22,7 +22,7 @@
 
 
 /** @file command-mutation.hpp
- ** Core of a Proc-Layer command: functor containing the operation to be executed.
+ ** Core of a Steam-Layer command: functor containing the operation to be executed.
  ** Each command holds two of these functors: one representing the actual operation
  ** and one to undo the effect of this operation. The latter involves the capturing
  ** and storing of a "memento" value behind the scenes. But towards Command, the
@@ -57,7 +57,7 @@ namespace control {
   
   
   /**
-   * Unspecific command functor for implementing Proc-Layer Command.
+   * Unspecific command functor for implementing Steam-Layer Command.
    * To be created from an std::function object, which later on gets
    * any necessary arguments from a closure passed in on invocation.
    * The concrete type of the function  and the arguments is

src/proc/control/command-registry.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMAND-REGISTRY.hpp  -  proc-Command object registration and storage management
+  COMMAND-REGISTRY.hpp  -  steam-Command object registration and storage management
 
   Copyright (C)         Lumiera.org
     2009,               Hermann Vosseler <Ichthyostega@web.de>

src/proc/control/command-setup.cpp

@@ -85,7 +85,7 @@ namespace control {
   
   CommandSetup::~CommandSetup() { }
   
-  /** Start a command setup for defining a Proc-Layer command with the given cmdID
+  /** Start a command setup for defining a Steam-Layer command with the given cmdID
    * @param cmdID the ID under with the new command will be registered
    * @note after defining a static variable of type CommandSetup,
    *       a functor or lambda should be assigned, which then

src/proc/control/command-setup.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMAND-INSTANCE-SETUP.hpp  -  Key abstraction for proc/edit operations and UNDO management
+  COMMAND-INSTANCE-SETUP.hpp  -  Key abstraction for steam/edit operations and UNDO management
 
   Copyright (C)         Lumiera.org
     2017,               Hermann Vosseler <Ichthyostega@web.de>
@@ -23,7 +23,7 @@
 
 /** @file command-setup.hpp
  ** Provision for setup of concrete commands for use by the UI.
- ** A *Proc-Layer command* is a functor, which can be parametrised with actual arguments.
+ ** A *Steam-Layer command* is a functor, which can be parametrised with actual arguments.
  ** It needs to be [defined](\ref command-def.hpp) beforehand, which means to establish an unique
  ** name and to supply three functions, one for the actual command operation, one to capture
  ** state and one to _undo_ the effect of the command invocation. CommandSetup allows to create
@@ -76,7 +76,7 @@ namespace control {
   
   
   /**
-   * Marker and Helper for writing Proc-Layer Command definitions.
+   * Marker and Helper for writing Steam-Layer Command definitions.
    * Together with the Macro #COMMAND_DEFINITION, such definitions
    * may be written statically, in DSL-style:
    * - statically define a variable of type CommandSetup,

src/proc/control/command-storage-holder.hpp

@@ -68,11 +68,11 @@ namespace control {
    * This is "the" top level CmdClosure implementation.
    * It is a specifically typed CmdClosure, which serves for
    * actually allocating storage to hold the command arguments
-   * and the UNDO state (memento) for Proc-Layer commands.
+   * and the UNDO state (memento) for Steam-Layer commands.
    * Both the contained components within StorageHolder
    * can be in \em empty state; there are no distinct
    * lifecycle limitations. StorageHolder is part
-   * of Proc-Layer command's implementation
+   * of Steam-Layer command's implementation
    * and should not be used standalone.
    */
   template<typename SIG, typename MEM>

src/proc/control/command.cpp

@@ -1,5 +1,5 @@
 /*
-  Command  -  Key abstraction for proc/edit operations and UNDO management
+  Command  -  Key abstraction for steam/edit operations and UNDO management
 
   Copyright (C)         Lumiera.org
     2009,               Hermann Vosseler <Ichthyostega@web.de>

src/proc/control/command.hpp

@@ -1,5 +1,5 @@
 /*
-  COMMAND.hpp  -  Key abstraction for proc/edit operations and UNDO management
+  COMMAND.hpp  -  Key abstraction for steam/edit operations and UNDO management
 
   Copyright (C)         Lumiera.org
     2009,               Hermann Vosseler <Ichthyostega@web.de>
@@ -22,7 +22,7 @@
 
 
 /** @file command.hpp
- ** Proc-Layer command frontend.
+ ** Steam-Layer command frontend.
  ** A *command* is a functor, which can be invoked according to a pre-defined HandlingPattern.
  ** Most notably, command invocation can be scheduled and logged with the serialiser, and the effect
  ** of any command invocation can be _undone_ later on by invoking the "undo operation" defined

src/proc/control/handling-pattern.cpp

@@ -23,7 +23,7 @@
 
 /** @file handling-pattern.cpp
  ** Implementation of pre-defined command handling patterns
- ** @internal detail of the Proc-Layer command handling framework.
+ ** @internal detail of the Steam-Layer command handling framework.
  */
 
 

src/proc/control/handling-patterns.hpp

@@ -24,7 +24,7 @@
 /** @file handling-patterns.hpp
  ** A hard wired collection of predefined command handling patterns.
  ** There is a small number of different possibilities to handle execution
- ** and UNDO of proc-Layer commands. Each of these is defined as a subclass
+ ** and UNDO of Steam-Layer commands. Each of these is defined as a subclass
  ** in this header and then hard wired into a small table. Handling patterns
  ** are stateless singleton objects, thus we build using multiple Singleton
  ** factory objects and configure them hard wired with the respective