Navigation
API > API/Plugins > API/Plugins/MetasoundFrontend
References
| Module | MetasoundFrontend |
| Header | /Engine/Plugins/Runtime/Metasound/Source/MetasoundFrontend/Public/MetasoundArrayRandomNode.h |
| Include | #include "MetasoundArrayRandomNode.h" |
Syntax
namespace Metasound
{
enum ESharedStateBehaviorType
{
SameNode,
SameNodeInComposition,
SameData,
}
}
Values
| Name | Description |
|---|---|
| SameNode | |
| SameNodeInComposition | |
| SameData |
Remarks
Check that the static_cast<>s above are using the correct type.
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 };
Declare its wrapper types using the DECLARE_METASOUND_ENUM macro. DECLARE_METASOUND_ENUM(EMyOtherTestEnum, EMyOtherTestEnum::Gamma, METASOUNDSTANDARDNODES_API, FMyOtherTestEnumTypeInfo, FMyOtherTestEnumReadRef, FMyOtherTestEnumWriteRef)
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()
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
FClassAccessPtr ClassAccessPtr = DocumentAccessPtr.GetRootGraph().GetNodeWithNodeID(NodeID).GetInputWithVertexID(VertexID);
Forward Declare
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->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.