2020-05-22 23:46:09 -04:00
{
2021-01-27 19:52:18 -04:00
"FileVersion": 3,
"Version": 1,
"VersionName": "1.0",
2021-04-02 20:19:06 -04:00
"FriendlyName": "MetaSound",
"Description": "A high-performance audio system that enables sound designers to have complete control over audio DSP graph generation of sound sources, via sample-accurate control and modulation of sound using audio parameters and audio events from game data and Blueprints",
2021-01-27 19:52:18 -04:00
"Category": "Audio",
"CreatedBy": "Epic Games, Inc.",
2022-10-21 11:04:07 -04:00
"CreatedByURL": "https://epicgames.com",
2021-01-27 19:52:18 -04:00
"DocsURL": "",
"MarketplaceURL": "",
"SupportURL": "",
2022-10-19 12:32:28 -04:00
"EnabledByDefault": true,
2021-01-27 19:52:18 -04:00
"CanContainContent": true,
2022-09-14 16:51:41 -04:00
"IsBetaVersion": true,
2021-01-27 19:52:18 -04:00
"Installed": false,
2021-04-02 20:19:06 -04:00
"Modules": [
2020-05-22 23:46:09 -04:00
{
2021-01-27 19:52:18 -04:00
"Name": "MetasoundGraphCore",
"Type": "Runtime",
"LoadingPhase": "PreDefault"
2020-05-22 23:46:09 -04:00
},
{
2021-01-27 19:52:18 -04:00
"Name": "MetasoundGenerator",
"Type": "Runtime",
2022-04-28 21:18:57 -04:00
"LoadingPhase": "PreDefault"
#jira UEAU-467
Initial implementation of Metasound::Frontend. Includes all classes and abstractions for dealing with the metasound document tree and graph editing.
Overall super happy with the way this turned out, since it lets us support exporting metasound graphs, creating local subgraphs in a metasound graph, and other really cool things.
High Level:
1) a Metasound with any sorts of inputs and outputs can be created using a UMetasoundNodeAsset, which contains a struct called the FMetasoundDocument.
2) since it would be very easy to create a malformed FMetasoundDocument by just editing the struct directly, all editing of the FMetasoundDocument is done through a set of APIs: FGraphHandle, FNodeHandle, FInputHandle, and FOutputHandle
2) You can access the main graph for a UMetasoundNodeAsset with UMetasoundNodeAsset::GetRootGraphHandle(), which returns a Metasound::Frontend::FGraphHandle.
3) The FGraphHandle lets you do all sorts of things, including:
i) Adding and removing nodes from the graph (AddNewNode/RemoveNode)
ii) adding and removing inputs/outputs from a graph (AddNewInput/RemoveInput, AddNewOutput/RemoveOutput)
iii) Get a handle to manipulate individual nodes in the graph (GetAllNodes/GetOutputNodes/GetInputNodes/GetOutputNodeWithName/GetInputNodeWithName)
iv) Get any metadata associated with that graph (GetGraphMetadata)
v) Create a subgraph that lives in the same document (CreateEmptySubgraphNode)
vi) Export a graph to a new Metasound asset or JSON
vii) compile that graph to an executable, playable, Metasound::IOperator (currently not all the way implemented in this CL but I'm getting to that tomorrow)
4) The FNodeHandle lets you manipulate any indivdual node on any given graph, primarily:
i) Getting input pins (GetAllInputs/GetAllOutputs/GetInputWithName/GetOutputWithName)
ii) get an FGraphHandle for the subgraph for this node if there is one (GetContainedGraph)
5) FInputHandle/FOutputHandle lets you manipulate individual input/output pins, primarily:
i) Seeing if two pins can be connected (CanConnectTo)
ii) Connecting two pins (Connect/ConnectWithConverterNode, the latter of which isn't implemented yet)
Mid Level (the metasound document model):
1) FMetasoundDocument is an aggregate and totally serializable to binary or text using the uproperty serializer.
2) A FMetasoundDocument owns a root class, which is it's primary graph, and a list of dependencies, which could be c++ implemented nodes, metasound graphs living in other assets, or subgraphs living in the current metasound document. the Dependencies list owns a list of any dependencies for the root class, as well as any nested dependencies (for example, if the root class has a subgraph that requires a C++ implemented sine osc, the subgraph and the sine osc will both be in the Dependencies array.
3) Each FMetasoundClassDescription contains that metasounds metadata, as well as a list of inputs and outputs for that metasound, and optionally a fully implemented graph.
4) If the metasound class description has a fully implemented graph, that graph is a list of FMetasoundNodeDescriptions, which themselves describe which nodes they are connected to.
5) Each FMetasoundClassDescription contains a list of uint32s corresponding to a dependency in the document's Dependency list.
Low level (how individual elements of the FMetasoundDocument are accessed and edited)
1) We can't hand out weak pointers to the FMetasoundDocument itself unfortunately, but We are able to enforce a strict visitor pattern using the class FMetasound::Frontend:: FDescriptionAccessPoint. Currently, uobjects like UMetasoundNodeAsset can hand out weak pointers to the FDescriptionAccessPoint, and the FDescriptionAccessPoint can return raw pointers to specific elements in the FMetasoundDocument using FDescriptionAccessPoint::GetElementAtPath. Since individual elements in the document can get moved around for a number of reasons (for example, we added or removed a dependency to the document, or a node to a specific subgraph), we enforce that specific elements get accessed via a path that doesn't cache specific indices or references to specific nested structs.
2) Paths to specific elements are saved as FDescPaths, which is basically an array of enums/uint32s/strings. I added some syntactical sugar using bracket overloads to more easily build out paths to specific elements. At first this looks whacky, but after a few uses it ends up being pretty easy to write paths using chained bracket operators. All paths start at a document type, and autocomplete does most of the hard work using a set of enums.
For example, to access a specific node on a specific subgraph (which is the most complicated use case):
FDescPath()[Path::EFromDocument::ToDepenencies][TEXT("MyCoolSubgraph")][Path::EFromClass::ToGraph][Path::EFromGraph::ToNodes][12 /* or whatever node id I want */];
3) Finally, Metasound::Frontend:::TDescriptionPtr wraps a weak ptr to a FDescriptionAccessPoint and a FDescPath and ends up getting used like a weak pointer. Under the hood though, it's enforcing a visitor pattern.
4) All of the big branching statements for following a FDescPath to a specific element in the metasound document is hidden in FDescriptionAccessPoint::GoToNext, which uses TVariants to cache the current step and go to the next step.
5) Most of the complicated parts of implementing FGraphHandle is dynamically adding and removing dependencies to documents and classes behind the scenes when we add/remove new nodes.
6) I also added support for basic undo/redo callbacks, but haven't explicitly added em yet to any specific handles.
#rb rob.gay
[CL 13829763 by Ethan Geller in ue5-main branch]
2020-07-02 23:05:41 -04:00
},
{
2021-01-27 19:52:18 -04:00
"Name": "MetasoundFrontend",
"Type": "Runtime",
2022-04-28 21:18:57 -04:00
"LoadingPhase": "PreDefault"
2020-07-14 17:58:13 -04:00
},
2020-07-28 13:58:29 -04:00
{
2021-01-27 19:52:18 -04:00
"Name": "MetasoundStandardNodes",
"Type": "Runtime",
2022-04-28 21:18:57 -04:00
"LoadingPhase": "PreDefault"
2020-07-28 13:58:29 -04:00
},
2020-07-14 17:58:13 -04:00
{
2021-01-27 19:52:18 -04:00
"Name": "MetasoundEngine",
"Type": "Runtime",
2022-04-28 21:18:57 -04:00
"LoadingPhase": "PreDefault"
2020-07-15 12:59:38 -04:00
},
2021-09-08 12:58:26 -04:00
{
"Name": "MetasoundEngineTest",
"Type": "Runtime",
2022-04-28 21:18:57 -04:00
"LoadingPhase": "PreDefault"
2021-09-08 12:58:26 -04:00
},
2020-07-15 12:59:38 -04:00
{
"Name": "MetasoundEditor",
2021-04-26 17:08:04 -04:00
"Type": "UncookedOnly",
2022-04-28 21:18:57 -04:00
"LoadingPhase": "PreDefault"
2021-01-27 19:52:18 -04:00
}
],
2021-04-02 20:19:06 -04:00
"Plugins": [
2021-01-27 19:52:18 -04:00
{
"Name": "AudioWidgets",
"Enabled": true
2020-07-15 12:59:38 -04:00
},
2021-01-27 19:52:18 -04:00
{
"Name": "AudioSynesthesia",
"Enabled": true
2022-06-27 12:00:38 -04:00
},
{
"Name": "WaveTable",
"Enabled": true
2021-01-27 19:52:18 -04:00
}
2020-05-22 23:46:09 -04:00
]
}
