Re: Help needed with a sync-problem

On Sat, Aug 4, 2012 at 7:05 AM, Peter van der Noord
<peterdunord@gmail.com>wrote:

> 2012/8/3 Chris Wilson <cwilso@google.com>
>
>> On Fri, Aug 3, 2012 at 10:40 AM, Peter van der Noord <
>> peterdunord@gmail.com> wrote:
>>
>>> I agree fully that it won't be what most developers want or need to do,
>>> the api will be used for games and site music/effects mostly, but creating
>>> custom nodes would be my primary focus. To be honest, the list of native
>>> nodes that i wanted to use has thinned out, due to some behaviours and
>>> implementations that were not appropriate for what i wanted. That's all
>>> fine by itself, but if i can't recreate them myself...
>>
>>
>> Have you filed issues on those behaviors and implementations?
>>
>
> I have posted quite a lot of messages to this list as i went along,
> commenting on things that i found when i was working with the api. Some
> suggestions made sense, some didn't, but to be honest this isn't really the
> point. Apart from the fact that i don't want the workgroup to decide
> whether my ideas are valid, and if they are, wait for a year for it to be
> implemented in a browser (and probably not exactly as i'd want it so i'd
> have to work around it), the main point is: i want to create my own nodes.
>
> You mention somewhere in this thread that nearly everything can be done
> with the native nodes, but just this isnt true. Really, it isn't. For
> example: there are literally hundreds of modules on sale for the Eurorack
> system (the most popular type of modular synthesizer, i did a really quick
> count on a popular store and saw about 500-600), with new ones being added
> every year. With your argument, you'd only need 8 types or so and would be
> able to do everything with those. Obviously, that is not the case.
>

There are a limited number of electric components those modules are made of
(resistors, capacitors, etc), so I have to disagree.  AudioNodes are not a
1:1 comparison to modular synth modules - most modular synth modules would
combine a number of different AudioNode components, in my expectation.  I
still believe that scripted nodes are important to get right as well, but I
believe most scenarios actually CAN be satisfied with a combination of
native modules.

You mentioned the only thing you'd want would be an noise gate (iirc), a
> nice one indeed, but what's the use if it adds a delay to the signal?
> Correct me if i'm wrong, but in my opinion (or more exact: in my case) it's
> useless.
>

Given that noise gate would be a trivial node to implement, I'd be able to
get away with implementing it with a very small bufferSize, which would put
its delay on the order of 5-10ms.  That's still unfortunate, and I'd much
rather have it as a native module, yes. I'd also rather have an AudioNode
output of the "reduction" parameter in the DynamicsCompressor to do
side-chaining and ducking; but I see these as evolutionary things that
we're working toward, not a reason to start over and expect that everyone
wants to be calling matrix methods directly.

I know custom nodes are way slower than the native ones and i accept that.
>> For comparison, there's nothing native going on in the modular synth i
>> created in flash, although i do admit there is some trickery involved. But
>> still, it's the single-threaded flash player, with each module writing
>> buffers in plain old as3 for-loops. I have no idea how as3 compares to js
>> (if anyone knows, i'd be interested to hear), but if i can recreate that
>> same performance with js and custom-nodes, i'm quite happy. (The
>> openingpatch on patchwork-synth.com runs 20-30 modules or so, and most
>> of them are not very optimized at all; my sine-osc still does Math.sin to
>> create its signal and there's the same biquad filter in there coded by hand
>> in as3, and still the ui reacts fine)
>>
>
And if that's how you want to implement, simply use a single JS node
connected for output, and continue to do everything else yourself.  A
single delay of 5-10ms shouldn't be a critical issue.  It seems to me that
you've already DONE the work to implement a lot of audio processing
yourself; one major goal behind Web Audio was to make that kind of
processing accessible to those who don't already have that code written,
and/or would benefit from the performance boost from having
natively-implemented optimized audio code running in a
separate-from-the-UI-thread high-priority thread.  I don't want to
understate the important of optimizing and insulating the audio path from
glitching (for example, resizing the window while your opening patch was
playing badly glitches on my
Xeon MacPro).

I guess what I'm trying to get at is there's a huge difference between "I
want to create my own programmatic modules" and "I want to create my own
nodes."  The vocoder, for example, is essentially a bunch of programmatic
modules plugged together; however, it doesn't use JSNodes at all.


>
>
> Peter
>