- Rename FNodeInfo to FNodeClassMetadata
- Add FGuid to Metasound node instances
- Metasound node class names are now Namespace.Name.Variant
- Add displayname for Metasound node classes.
#jira UE-107332
#jira UEAU-660
#rb Rob.Gay
[CL 15253779 by phil popp in ue5-main branch]
- Moving Frontend UObject registration logic to FMetasoundUObjectRegistry
- Allow FMetasoundAssetBase to support multiple FMetasoundArchetypes
- Adding graph synchronization between UEdGraph and FMetasoundDocument
- Added TAssetPtr<> for tracking validity of objects that cannot be wrapped in a smart pointer.
- Added support for mono and stereo to UMetasoundSource
- Added tools for comparing FMetasoundARchetypes.
- Added LogMetasound
#rb Max.Hayes
#jira UEAU-487
[CL 14919511 by phil popp in ue5-main branch]
Converter Nodes for Metasounds. Allows for use of the METASOUND_REGISTER_CONVERTER macros, as well as autogenerated converters.
#rb phil.popp
[CL 14192031 by Ethan Geller in ue5-main branch]
- Disallow removing required I/O from MetasoundSources
- Add functions to expose/iterate required I/O archetypes from Frontend
- Enable copy graph nodes using JSON MS Document Schema and pruning unused nodes
- Mock in paste code (Ethan to add validation or "fix-up" logic on MSDoc side to avoid duplication of node/I/O Ids, names, etc.)
#rb ethan.geller
#jira UEAU-547
[CL 14038324 by Rob Gay in ue5-main branch]
- Hide superfluous type info & non-preferred literal data
- Allow user to rename nodes with display name, which is independent from node string name (and supports localization)
- Add better membership checks to editor detail customizations to ensure document member renames/data org doesn't break editor
#rb ethan.geller
#rnx
#jira UEAU-546
[CL 13981474 by Rob Gay in ue5-main branch]
Implement UMetasoundSource, Archetype registry, and implement Archetype support in the metasound editor.
#rb rob.gay, phil.popp
#fyi rob.gay, phil.popp
[CL 13940440 by Ethan Geller in ue5-main branch]
- Expose I/O arrays to UI (TODO: fix rename. We currently have two places we're caching input/output names and no easy way to snatch I/O metadata from I/O node. Could we add function to reference name from description instead of caching on node?)
- Stub in json import exposition to UI
- Fix crash with removing inputs/outputs
- Various clean-up
#rb ethan.geller
#jira UEAU-527
[CL 13937505 by Rob Gay in ue5-main branch]
Fix for linker error on string literal on linux. Move implementation of the string literal from DECLARE_METASOUND_DATA_TYPE to REGISTER_METASOUND_DATATYPE.
#rb phil.popp, rob.gay
[CL 13902707 by Ethan Geller in ue5-main branch]
1) The node registry and METASOUND_REGISTER_NODE(FMyNodeType)
2) The datatype registry and REGISTER_METASOUND_DATATYPE(FMyDataType) (which I have to rename to METASOUND_REGISTER_DATATYPE)
3) Integration of literals, which are handled with FDataTypeLiteralParam and serialized out with FMetasoundLiteralDescription , and can be expanded to pass in a UObject*/TArray<UObject*> in the future
4) And finally, the full construction of an arbitrary graph to build operators out of in Metasound::Frontend::FGraphHandle::BuildOperator, which needs a sample rate/frame count per callback to work.
#rb rob.gay, phil.popp
[CL 13891250 by Ethan Geller in ue5-main branch]
- Move deserialize/serialize utilities off of module and into own FileConversion namespace. Stub in landing place for export in Intermediates.
#jira UEAU-527
#rb ethan.geller
[CL 13886786 by Rob Gay in ue5-main branch]
Clang compile fix: friend class UMetasound is in the global namespace, so FHandleInitParams needed to establish friendship with ::UMetasound rather than UMetasound.
#rb none
[CL 13832348 by Ethan Geller in ue5-main branch]
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]
