Metasound::ETriggerComparisonType

Navigation

API > API/Plugins > API/Plugins/MetasoundStandardNodes

References

Syntax

namespace Metasound  
{  
    enum ETriggerComparisonType  
    &123;  
        Equals,  
        NotEquals,  
        LessThan,  
        GreaterThan,  
        LessThanOrEquals,  
        GreaterThanOrEquals,  
    &125;  
}  
Copy full snippet

namespace Metasound {     enum ETriggerComparisonType     &123;         Equals,         NotEquals,         LessThan,         GreaterThan,         LessThanOrEquals,         GreaterThanOrEquals,     &125; }

Values

Remarks

This file is largely copied from JsonStructSerializerBackend / JsonStructDeserializerBackend. The primary difference is that it exposes template args for which character encoding to use, as well as our printing policy.

NOTE: Metasound Enum types are defined outside of Engine so can't use the UENUM type reflection here. Basic reflection is provides using template specialization and Macros defined below. Example usage:

Declare an Enum class. enum class EMyOtherTestEnum : int32 { Alpha = 500, Beta = -666, Gamma = 333 }; 2. Declare its wrapper types using the DECLARE_METASOUND_ENUM macro. DECLARE_METASOUND_ENUM(EMyOtherTestEnum, EMyOtherTestEnum::Gamma, METASOUNDSTANDARDNODES_API, FMyOtherTestEnumTypeInfo, FMyOtherTestEnumReadRef, FMyOtherTestEnumWriteRef) 3. Define it using the BEGIN/ENTRY/END macros DEFINE_METASOUND_ENUM_BEGIN(EMyOtherTestEnum) DEFINE_METASOUND_ENUM_ENTRY(EMyOtherTestEnum::Alpha, "AlphaDescription", "Alpha", "AlphaDescriptionTT", "Alpha tooltip"), DEFINE_METASOUND_ENUM_ENTRY(EMyOtherTestEnum::Beta, "BetaDescription", "Beta", "BetaDescriptioTT", "Beta tooltip"), DEFINE_METASOUND_ENUM_ENTRY(EMyOtherTestEnum::Gamma, "GammaDescription", "Gamma", "GammaDescriptionTT", "Gamma tooltip") DEFINE_METASOUND_ENUM_END()

Metasound Controllers and Handles provide a object oriented interface for manipulating Metasound Documents.

Each controller interface is associated with a single Metasound entity such as Document, Graph, Node, Input or Output. Access to these entities generally begins with the DocumentController which provides access to Graphs. Graphs provide access to Nodes and Nodes provide access to Inputs and Outputs.

A "Handle" is simply a TSharedRef<> of a controller.

In general, the workflow for editing a Metasound graph will be: 1) Load or create a metasound asset. 2) Call UMetaSoundPatch::GetDocumentHandle() to get a handle to the document for that asset.

Typically the workflow for creating a Metasound subgraph will be 1) Get a Metasound::Frontend::FGraphHandle (typically through the two steps described in the first paragraph) 2) Build a FMetasoundFrontendClassMetadata struct with whatever name/author/description you want to give the subgraph, 3) call Metasound::Frontend::FGraphHandle::CreateEmptySubgraphNode, which will return that subgraph as it as a FNodeHandle for that subgraph in the current graph. 4) class Metasound::Frontend::FNodeHandle::AsGraph which provides access to edit the subgraphs internal structure as well as externally facing inputs and outputs.

General note- these apis are NOT thread safe. Make sure that any FDocumentHandle, FGraphHandle, FNodeHandle, FInputHandle and FOutputHandle that access similar data are called on the same thread.

MetasoundFrontend Document Access Pointers provide convenience methods for getting access pointers of FMetasoundFrontendDocument sub-elements. For instance, to get an input vertex subobject on the root graph of the document, one can call:

FDocumentAccessPtr DocumentAccessPtr = MakeAccessPtr(AccessPoint, Document);

FClassAccessPtr ClassAccessPtr = DocumentAccessPtr.GetRootGraph().GetNodeWithNodeID(NodeID).GetInputWithVertexID(VertexID);

MetaSound Frontend Query

MetaSound Frontend Query provides a way to systematically organize and update streaming data associated with the MetaSound Frontend. It is a streaming MapReduce framework for querying streams of data (https://en.wikipedia.org/wiki/MapReduce)

While it does not support the computational parallelism commonly found in MapReduce frameworks, it does offer:

• An encapsulated and reusable set of methods for manipulating streamed data.

Support for incremental updates (a.k.a. streamed data).

• An indexed output for efficient lookup.

Data within MetaSound Frontend Query is organized similarly to a NoSQL database (https://en.wikipedia.org/wiki/NoSQL). Each object (FFrontendQueryEntry) is assigned a unique ID. Keys (FFrontendQueryKey) are associated with sets of entries (FFrontendQueryPartition) and allow partitions to be retrieved efficiently. Each partition holds a set of entries which is determined by the steps in the query (FFrontendQuery). A FFrontendQueryKey or FFrontendQueryValue represent one of multiple types by using a TVariant<>.

A query contains a sequence of steps that get executed on streaming data. The various types of steps reflect common operations performed in MapReduce and NoSQL database queries.

Step Types Stream: Produce a stream of FFrontendQueryValues. Map: Map a FFrontendQueryEntry to a partition associated with a FFrontendQueryKey. Reduce: Apply an incremental summarization of a FFrontendQueryPartition. Transform: Alter a FFrontendQueryValue. Filter: Remove FFrontendQueryValues with a test function. Score: Calculate a score for a FFrontendQueryValue. Sort: Sort a FFrontendQueryPartition. Limit: Limit the size of a FFrontendQueryPartition.

METASOUND TRANSMISSION SYSTEM This allows for transmission of arbitrary data types using transmission addresses.

Typical use case: TSenderPtr FloatSender FDataTransmissionCenter::Get().RegisterNewSender(ExampleAddress, InitSettings); TReceiverPtr FloatReceiver FDataTransmissionCenter::Get().RegisterNewReceiver(ExampleAddress, InitSettings);

//... FloatSender->Push(4.5f);

//... elsewhere on a different thread: float ReceivedFloat = FloatReceiver->Pop();

In general, some performance considerations for this system: 1) Senders and receivers are meant to have long lifecycles, and requesting them from the FDataTransmissionCenter may be expensive if done every tick. 2) Most non-audio data types cannot be mixed, so multiple senders to the same address will cause only one of the senders to be effective. 3) while the overall system is thread safe, individual TSender and TReceiver objects should only be used by a single thread.

Forward Declarations