Re: Web Audio API Proposal

Small observation on this conversation - I would think the functionality those kinds of graphs (multiple sources with w/reverb & chorus) give might be simpler to achieve and control with a mixer-and-effects-send model, as opposed to a free-form-graph model.  Especially if you also go with the implied-mixer model you guys have been discussing today. Then source objects could have N effect send settings, in addition to the gain setting you settled on; and you'd select the particular effect associated with each send (i.e. chorus, reverb, etc.) on whatever object presents for the implied mixer -- probably the output, or the audio context.  Not that there isn't a good argument for also providing insert FX -- there certainly is, both in-line with a source and in-line with a mix output (for compression, EQ, etc.).

General comment - I guess while I've found fitting real-world music/sound applications into DirectShow-like filter graph models to be flexible and doable, it's also perhaps a bit more fiddly than strictly necessary for the developer/customer.  The flexibility might be considered overkill in many of the most common use cases.  We can explore that in detail later if anyone wants.

	-- Chris G.


On 2010Jun 21, at 4:47 p, Jer Noble wrote:
> 
> On Jun 21, 2010, at 3:27 PM, Chris Marrin wrote:
> 
>> On Jun 21, 2010, at 2:34 PM, Chris Rogers wrote:
>> 
>>> Hi Chris,
>>> 
>>> I'm not sure we can also get rid of the AudioGainNode and integrate the concept of gain directly into all AudioNodes.  This is because with the new model Jer is proposing we're connecting multiple outputs all to the same input, so we still need a way to access the individual gain amounts for each of the separate outputs.
>> 
>> Right, but if every node can control its output gain, then you just control it there, right? So if you route 3 AudioSourceNodes into one AudioNode (that you're using as a mixer) then you control the gain of each channel in the AudioSourceNodes, plus the master gain in the AudioNode. For such a common function as gain, it seems like this would simplify things. The default gain would be 0db which would short circuit the gain stage to avoid any overhead.
> 
> 
> Actually, I don't agree that modifying the output gain is so common an operation that it deserves being promoted into AudioNode.  Sure, it's going to be common, but setting a specific gain on every node in a graph doesn't seem very likely.   How many nodes will likely have a gain set on them?  1/2?  1/4?  I'd be willing to bet that a given graph will usually have as many gain operations as it has sources, and no more.  
> 
> I can also imagine a simple scenario where it makes things more complicated instead of less:
> 
> <PastedGraphic-1.tiff>
> 
> In this scenario, there's no way to change the gain of the Source 1 -> Reverb connection, independently of Source 2-> Reverb.  To do it, you would have to do the following:
> 
> <PastedGraphic-3.pdf>
> 
> And it seems very strange to have to create a generic AudioNode in order to modify a gain.  Alternatively, you could create multiple AudioReverbNodes, but again, it seems weird to have to create multiple reverb nodes just so you can change the gain going to only one of them.
> 
> Right now, every AudioNode subtype has a discreet operation which it performs on its input, and passes to its output.  To add in gain to every AudioNode subtype would make things more confusing, not less.
> 
> -Jer

Received on Tuesday, 22 June 2010 01:31:02 UTC