Skip to content

Latest commit

 

History

History
33 lines (19 loc) · 1.66 KB

meeting_notes.md

File metadata and controls

33 lines (19 loc) · 1.66 KB

post-nuit blanche: focus on playing with history

up to November: focus on multiuser (if you can perform with your history without the system falling apart, multiuser should be easier)

what does playign with history's interface look like?

where do you draw the boundaries of what counts as history?

certain edits shouldn't become part of the history, which ones.

write down in detail how this would actually work. pseudocode is fine.

Drop in tape machines into the world to handle looping of history

  • they will always only act on knobs

if you start a loop, it should occur in other people's editors too. those automerge changes

automating the editor, you're recording your edits and looping them to the scene.

for now, could limit history playback to

machine-generated activity should not be part of the history (the history tape recorder/player)

it emphasizes the distinction between structural edits and parametric edits. another ontological separation between performance and documentation histories -- one is being able to pull from your history and turn into signals, the other is the ability to revert and branch. they are two completely different things. one creates a new signal inside of your world, the other creates whole new worlds.

will be useful to discuss Adobe's history brush: https://www.youtube.com/watch?v=adExe4IPTsU -

distinction between the edits you're making, and the resulting artifacts. what we're doing is goign back to the earlier versions of the virtual and making them actual.

important things to test in automerge:

  • can we get the history of a single object (under one key)
  • how does automerge perform once we stick arrays of lots numbers