-
Notifications
You must be signed in to change notification settings - Fork 118
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
not require audiolet instance passed to all new objects #39
Comments
Yeah, this is a bit ugly - I go back and forth over how the right way to do this is. I don't really want to have to pass sampleRate around all the time. Possibly what should happen is that the Audiolet object is should be a singleton, which the nodes can grab if they need the sample rate, scheduler, graph etc. That does seem a little bit close to just having a massive global though. I think that any changes to this will wait until a good sized rewrite of the code takes place (I have vague plans for Audiolet 2), as IMO the API win from this is negated by losing compatibility with existing code. Will leave the issue open for now though and have a think about it. |
Wouldn't it be easiest to have all object creation occur through the instantiated Audiolet object? In other words, instead of:
do this:
or even this:
This seems like the most obvious strategy to me, though perhaps I'm missing something. |
i considered that route as well, but ultimately, it doesn't solve the inconvenience. this would still require anything creating nodes to have reference to that while on one hand i realize in a scenario with multiple graphs, this might be totally unavoidable... it might not be bad for audiolet to only assume 1 graph in any application. i realize this is also not ideal, but given the sink.js limitations, it does make some sense. (ie. if you can only have 1 master output, assuming 1 graph might not be inherently bad). |
@catshirt wouldn't creating nodes via Edit: I suppose your point is that you would still need the root I don't think keeping around the root |
you're right- but there are many parts of my application which create nodes outside of the context of an audiolet object. what it really boils down to here is that |
@catshirt see my edit above... and yeah, in that case you would need to maintain some sort of singleton Audiolet graph object. Edit: I also think it's better to force the user to rely on a single library object, rather than pollute the global scope with a whole bunch of new object constructors. Just my opinion though. I would also note that this is how the Web Audio API does it... you create a single audio context, and then use that to generate all of your nodes via object methods. |
a single graph would be the easiest solution. but i don't think it's the only one. audiolet objects don't actually need the reference to the graph, as much as they need references to properties of that graph (ie. sampleRate), which could be obtained through other methods. for instance, audiolet could pass these parameters to the generate function during the recursive tick. a bit of work is involved here, and the generate() api would grow substantially, but it is a solution. |
How about using some sort of global namespace object, and getting rid of the Audiolet class all together? So something like: var audiolet = {};
audiolet.Output= function() {
audiolet.sampleRate = 44100;
};
audiolet.Sine = function(frequency) {
print(frequency);
print(audiolet.sampleRate);
};
output = new audiolet.Output();
sine = new audiolet.Sine(300); If, like Nic, you just wanted each object as a global then we could maintain an optionally imported file which says: var Output = audiolet.Output;
var Sine = audiolet.Sine; I'm don't like the createWhateverNode style very much, because in Audiolet you can create custom nodes using the same syntax as it uses internally. So if you wanted to make a custom node you would also have to write a createWhateverNode function to keep a consistent API, which seems like an unnecessary step. The obvious issue with the style I've suggested is that it doesn't allow multiple outputs running at different sample rates. That said, I don't see that happening in the Web Audio API any time soon, as I can see that it would present significant architectural challenges for not too much gain. |
don't worry- last one for now. i realize this one is a bit more difficult, but i wouldn't think it's impossible to remove the necessity to pass an Audiolet instance to everything you create.
since i think you can only safely make one instance of sink.js, one way to achieve this would just have scheduler, device, etc set as globals, and pass sampleRate through generate(). i haven't thought about it too much and surely this isn't a good solution... but just to get the ball rolling...
your thoughts?
The text was updated successfully, but these errors were encountered: