diff --git a/src/proc/asset/category.hpp b/src/proc/asset/category.hpp index ce6028921..aca63b08f 100644 --- a/src/proc/asset/category.hpp +++ b/src/proc/asset/category.hpp @@ -57,7 +57,7 @@ namespace asset { , VIDEO , EFFECT , CODEC - , STRUCT + , STRUCT //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META? , META }; diff --git a/src/proc/asset/meta.hpp b/src/proc/asset/meta.hpp index 4a736cf47..245d13da9 100644 --- a/src/proc/asset/meta.hpp +++ b/src/proc/asset/meta.hpp @@ -61,6 +61,7 @@ #define ASSET_META_H #include "proc/asset.hpp" +#include "proc/asset/struct-scheme.hpp" #include "lib/idi/entry-id.hpp" #include "lib/nocopy.hpp" @@ -112,6 +113,7 @@ namespace asset { /** * key abstraction: metadata, parametrisation, customisation and similar organisational traits. * @todo just a stub, still have to figure out the distinctive properties of asset::Meta + * //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META? */ class Meta : public Asset @@ -127,7 +129,14 @@ namespace asset { } protected: - Meta (Asset::Ident const& idi) : Asset(idi) {} //////////////TODO + Meta (Asset::Ident const& idi) + : Asset{idi} + { } + + template + Meta (lib::idi::EntryID const& nameID) + : Meta{idi::getAssetIdent (nameID, META)} + { } // friend class MetaFactory; ///////////////////////////////////TODO still necessary? }; diff --git a/src/proc/asset/meta/time-grid.cpp b/src/proc/asset/meta/time-grid.cpp index 4c374e573..6d173db2d 100644 --- a/src/proc/asset/meta/time-grid.cpp +++ b/src/proc/asset/meta/time-grid.cpp @@ -51,9 +51,12 @@ namespace meta { - /** */ + /** + * @internal to be invoked indirectly by means of the Builder. + * @todo drafted in 2010 -- usage of the builder feels unsatisfactory as of 2018 + */ TimeGrid::TimeGrid (GridID const& nameID) - : Meta (idi::getAssetIdent (nameID)) + : Meta{nameID} { } @@ -76,7 +79,7 @@ namespace meta { /** @internal helper to retrieve the smart-ptr * from the AssetManager, then attach a further * smart-ptr-to-Quantiser to that, which then can be - * published via the \link advice.hpp "advice system"\endlink + * published via the [advice system](\ref advice.hpp) * @note this allows to use a time grid just "by name", * without explicit dependence to the Session / Assets */ diff --git a/src/proc/asset/meta/time-grid.hpp b/src/proc/asset/meta/time-grid.hpp index 2cf593edb..6b00a69de 100644 --- a/src/proc/asset/meta/time-grid.hpp +++ b/src/proc/asset/meta/time-grid.hpp @@ -22,7 +22,7 @@ /** @file time-grid.hpp - ** Establishing a reference scale for quantised time values. + ** To establish a reference scale for quantised time values. ** Contrary to the continuous Time values (Lumiera internal time scale), ** quantised time can only take on some discrete values corresponding ** to blocks or frames, according to the respective \em timecode format. @@ -34,7 +34,8 @@ ** Time grid specifications are integrated into Lumiera's framework ** for meta assets, automation, configuration and similar metadata. ** - ** \par using time grids + ** ## using time grids + ** ** TimeGrid is an interface (ABC), but provides some actual factory ** functions, which can be used as a convenience shortcut to fabricate ** the kind of simple time grid used most often. diff --git a/src/proc/asset/struct-scheme.hpp b/src/proc/asset/struct-scheme.hpp index 15db48dbf..fd1f05860 100644 --- a/src/proc/asset/struct-scheme.hpp +++ b/src/proc/asset/struct-scheme.hpp @@ -155,9 +155,9 @@ namespace asset{ */ template inline Asset::Ident - getAssetIdent (lib::idi::EntryID const& entryID) - { - Category cat (STRUCT, idi::StructTraits::catFolder()); + getAssetIdent (lib::idi::EntryID const& entryID, asset::Kind assetKind =STRUCT) + { //////////////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META? + Category cat (assetKind, idi::StructTraits::catFolder()); return Asset::Ident (entryID.getSym(), cat); } diff --git a/src/proc/asset/struct.hpp b/src/proc/asset/struct.hpp index 4ed21312e..bf5e58a2f 100644 --- a/src/proc/asset/struct.hpp +++ b/src/proc/asset/struct.hpp @@ -108,6 +108,7 @@ namespace asset { * The idea is to have a generic mechanism for attaching properties and relations. * This will become relevant once we build the real query subsystem. * Right now (as of 1/2015), asset::Struct is just an ID provider. + * //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META? */ class Struct : public Asset { diff --git a/tests/41asset.tests b/tests/41asset.tests index 3bfa9db35..b88b05b67 100644 --- a/tests/41asset.tests +++ b/tests/41asset.tests @@ -58,6 +58,6 @@ END TEST "Simple TimeGrid" TimeGridBasics_test < -
+
Asset management is a subsystem on its own. Assets are "things" that can be loaded into a session, like Media, Clips, Effects, Transitions. It is the "bookkeeping view", while the Objects in the Session relate to the "manipulation and process view". Some Assets can be //loaded// and a collection of Assets is saved with each Session. Besides, there is a collection of basic Assets always available by default.
 
 The Assets are important reference points holding the information needed to access external resources. For example, an Clip asset can reference a Media asset, which in turn holds the external filename from which to get the media stream. For Effects, the situation is similar. Assets thus serve two quite distinct purposes. One is to load, list, group search and browse them, and to provide an entry point to create new or get at existing MObject in the Session, while the other purpose is to provide attribute and property information to the inner parts of the engine, while at the same time isolating and decoupling them from environmental details. 
@@ -900,6 +900,8 @@ is how to implement the relationship between [[MObject]]s and Assets. Do we use
 
   //9/07: currently implementing it as follows: use a refcounting-ptr from Clip-~MObject to asset::Media while maintaining a dependency network between Asset objects. We'll see if this approach is viable//
 
+{{red{NOTE 8/2018}}} there seems to be a fuzziness surrounding the distinction between StructAsset and MetaAsset.
+I am suspicious this is a distinction //merely derived from first principles...// &rarr; {{red{Ticket #1156}}}
@@ -4210,10 +4212,11 @@ For the case here in question this seems to be the __R__esource __A__llocation _ And, last but not least, doing large scale allocations is the job of the backend. Exceptions being long-lived objects, like the session or the sequences, which are created once and don't bear the danger of causing memory pressure. Generally speaking, client code shouldn't issue "new" and "delete" when it comes in handy. Questions of setup and lifecycle should allways be delegated, typically through the usage of some [[factory|Factories]], which might return the product conveniently wrapped into a RAII style handle. Memory allocation is crucial for performance, and needs to be adapted to the actual platform -- which is impossible unless abstracted and treated as a separate concern.
-
-
This category encompasses the various aspects of the way the application controls and manages its own behaviour. They are more related to the way the application behaves, as opposed to the way the edited data is structured and organised (which is the realm of [[structural assets|StructAsset]])
+

+
This category encompasses the various aspects of the way the application controls and manages its own behaviour. They are more related to the way the application behaves, as opposed to the way the edited data is structured and organised (which is the realm of [[structural assets|StructAsset]]) &rarr; {{red{Ticket #1156}}}
 * StreamType &rarr; a type system for describing and relating media data streams
 * ScaleGrid &rarr; to manage time scales and frame alignment
+* {{{ErrorLog}}} &rarr; collect incident records
 
 !accessing meta assets
 It turns out that all meta assets follow a distinct usage pattern: //they aren't built as individual entities.// Either, they are introduced into the system as part of a larger scale configuration activity, or they are //derived from category.// The latter fits in with a prototype-like approach; initially, the individual entry just serves to keep track of a categorisation, while at some point, such a link into a describing category may evolve into a local differentiation of some settings.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index b4a62fd18..cbb1e9430 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -32085,6 +32085,57 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      ...obwohl die betreffenden Assets in die Kategorie "Medien" fallen,
+    

+    

+      und wir einen eigenen StreamType definieren wollen, also explizit die Art der Medien offen lassen.
+    

+    

+      Ganz prominent fehlt hier also z.B: MIDI
+    

+  
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      ...nämlich genau nicht für alle Assets,
+    

+    

+      die Aufgrund von Klassifikationen automatisch bereits existieren
+    

+  
+
+
+
+
+
 
 
 
@@ -32183,7 +32234,11 @@
 
 
 
-
+
+
+
+
+