Re: Help needed with a sync-problem

A quick idea I had on this.  If the Web Audio API could do the
following things, would it be possible to implement most (all?) custom
processing just using nodes?

- Working with varying block sizes within the graph, down to a single sample
- Having nodes corresponding to each of the functions in Marcus' DSP API
- Simple logical nodes, for doing if-statement style branching
- A way to read to and write from an arbitrary point in a buffer
(maybe possible already using DelayNode?)

I think this would allow me to do pretty much anything I've ever done
in audio.  Are there many (lots?) of applications which need more than
this?

Predicting some problems which I'm sure Chris Rogers will be able to
put more eloquently: than me:

- Working with variable block sizes makes everything more difficult
- Working with single samples will be slow
- The API can do lots of this already
- Lots of nodes to implement, test, maintain etc.

With those caveats however, I can see the upsides of something like this.

- No need to drop down to JavaScript, so no latency problems
- More complex processing can still be done in C++, giving performance
gains over big collections of elementary nodes for common tasks
- Allows almost as much flexibility as JavaScript (albeit in a less
"nice" way imo)

I guess this would kind of be a half-way house between the two ways
people seem to be thinking about this, and as such probably has all of
the downsides of both approaches. Also in these emails I always tend
to miss a really obvious problem with my idea, so apologies in advance
for that.

Joe

On Sat, Aug 4, 2012 at 3:05 PM, 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.
>
> 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.
>
>
>>>
>> ABSOLUTELY _NOT_ what I said.  I expressed concern that there seems to be
>> a lot of focus on using custom JS nodes, when quite frankly it's much easier
>> and more efficient (in CPU) to do the same tasks in native nodes in many
>> cases.  I have said before that I'd like to ensure that we make
>> script-implemented nodes work as well as possible; that doesn't mean that
>> because I think we should offer a good hammer there every problem is a nail.
>
>
> Then i misinterpreted that one. Still, *my* main focus would be to create my
> own nodes, so yes, there's a focus on that when i post my problems regarding
> a major issue with that.
>
> 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)
>
>
> Peter

Received on Saturday, 4 August 2012 15:43:58 UTC