W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Help needed with a sync-problem

From: Peter van der Noord <peterdunord@gmail.com>
Date: Sat, 4 Aug 2012 16:05:55 +0200
Message-ID: <CAL9tNz9HJKn4TX+sU3KLruKVop7U0uLfpmeCwY0HfCJK4JMDbQ@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: public-audio@w3.org
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

>> 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)

Received on Saturday, 4 August 2012 14:06:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:01 UTC