From 45cae6bed42c597b323ca16a1eb62709514d30de Mon Sep 17 00:00:00 2001 From: Spencer Russell Date: Mon, 23 Jun 2014 14:33:06 -0400 Subject: [PATCH] adds some design notes --- notes/node_finishing.md | 22 ++++++++++++++++++++++ notes/subtyping.md | 3 +++ 2 files changed, 25 insertions(+) create mode 100644 notes/node_finishing.md create mode 100644 notes/subtyping.md diff --git a/notes/node_finishing.md b/notes/node_finishing.md new file mode 100644 index 0000000..bf9cb72 --- /dev/null +++ b/notes/node_finishing.md @@ -0,0 +1,22 @@ +One design challenge is how to handle nodes with a finite length, e.g. +ArrayPlayers. Also this comes up with how do we stop a node. + +Considerations: +1. typically the end of the signal will happen in the middle of a block. +2. we want to avoid the AudioNodes allocating a new block every render cycle +3. force-stopping nodes will typicaly happen on a block boundary +4. A node should be able to send its signal to multiple receivers, but it doesn't + know what they are (it doesn't store a reference to them), so if a node is finished + it needs to communicate that in the value returned from render() + +Options: + +1. We could take the block size as a maximum, and if there aren't that many + frames of audio left then a short (or empty) block is returned. +2. We could return a (Array, Bool) tuple with the full block-size, padded with + zeros (or extending the last value out), and the bool indicating whether + there is more data +3. We could raturn a (Array, Int) tuple that indicates how many frames were + written +4. We could ignore it and just have them keep playing. This makes the simple + play(node) usage dangerous because they never get cleaned up diff --git a/notes/subtyping.md b/notes/subtyping.md new file mode 100644 index 0000000..3aa600d --- /dev/null +++ b/notes/subtyping.md @@ -0,0 +1,3 @@ +There are a few issues regarding the types in AudioIO: + +1. There are some fields that need to be shared between all nodes