Are your LayerModel, PlayerRecorder, collections etc. mutable or immutable?
Your patch is all red btw. So we don’t get the full picture here.
You are saying that the Model doesn’t hold all changes that you tried to apply?
Can you try to remove any functionality from your Records in order to not run into those niche situations?
If you’d just follow a simplistic approach that distinguishes data from functionality, you’d end up with your immutable data on one side and some patches operating on the data on the other side, which should allow you to fiddle the state (via accumulator and what not) and produce a new snapshot of the model that contains all the changes.
i think i may understand the philosophy, its not the first time i m encountering this problem with classes functionnalities from Gamma Core, and records. its possibile that i have plenty ones around…
Is there any “container” that could cheat a class to a record ? I mean there are many great tools in classes format in Gamma. No magic for it ?
except rewriting completly a sequencer in a dirty and surely less well working by s+h data in a spread, i dont see how to do this “defragmenting” thing between fonctionnalities and data.
Could you just provide a simple patch example of this that i understand ? thank you
I see terms like player and runtime. Those sound to me as if they should be modelled as part of a runtime, which typically is mutable and has longer lifespans, like those players should conceptually be there as long as you are editing.
On the other hand the models have short lifespans. They model the different snapshots of the model. It still feels like this could be refactored. So the players’ lifetime is managed by this big ForEach loop. And the players lead to new snapshots that you then push back to the main model channel.
I can’t do it over here, because most of the nodes are red. But do understand what I am trying to say?
thank you @gregsn
First of all, thank you for the quality of this exchange. I can get a sense of where all this could go, but I have no idea how it would be implemented in practice. I’m not a skilled C coder, and I admit that all this is very, very, very abstract, or more likely at a different, very, very different level than mine. We’re missing help files concerning models, philosophy, and project structuring.
I thought my problem was one of class versus record. Seems not.
In the architecture of this project, the Leap data is processed upstream and decoupled. Everything is split and recorded, perhaps with extra steps.
All the project is a model.
No, I don’t see the concrete application. But thank you!
Just had another look at the screenshots and wondered if PlayersManager and DoubleRecordPlayer are just both outside of your Model and both should be classes.
Macro probably as well?
Maybe this is the first thing to get right:
deciding what is part of the model and what is part of the runtime.
So runtime types have properties, like “currently recording”, “play mode” or similar. Those are not the most crucial things that you’d want to persist and serialize. It’s more like the current mode of your editor that edits the model.
Model types have all the crucial bits in there.
Model types should be records in order to get all the snapshot-, easy-to-detect-changes- and undo/redo-functionality…
Runtime-types & Editor/Controller-patches are all just mutating (Classes) for ease-of-use. Non need to fumble new snapshots of those. They just mutate in-place.
