-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
design contract for buffers of AudioNode #38
Comments
In general, yes, Also, correct that returning a short buffer in a I agree the way the input is handled in the render tree is not obvious, but you can think about it in a functional context, where you're calling the Maybe I'm being dense but I'm not sure what issue you're describing. Do you have a more complete example that shows the issue? |
My specific confusion regarding that point is that It just seems like nodes that take in audio and produce audio should be able to be composed together, and so there should be some specification, maybe, for what a node needs to be in order to be composed together. For example, maybe I test an FM modulator, say Similarly, something else that confused me initially, but I think I've come around, is that (Along the lines of "contract" it might be worthwhile to state that if nodes need long-term access to values in I think the package is really great! I've had a lot of fun. |
ArrayRenderer may return a buffer that is smaller than
info.buf_size
, since the array might not be a multiple ofinfo.buf_size
. But InputRenderer currently asserts that the size of the input buffer must beinfo.buf_size
.I think the idea is that a node can signal that it is done by returning an incomplete buffer. This is the default behavior of the
render
function forAudioNode
It took me a while to get the idea, but
play
really means "hook output of node to input of mixer and input of node to output of mixer" andInputRenderer
is really just a pass-through. But In general, you would want to compose nodes so that the output of one node goes to the input of another node. In fact, SinOsc{AudioNode} could have maybe been written like this, so that it took its frequency from itsdevice_input
instead of from another node.The text was updated successfully, but these errors were encountered: