Re: Help needed with a sync-problem

Yes, i have thought about that but i dont think i will be heading in that
direction. With custom graphs being adjusted by the user all the time,
that's not something i want to handle (and it will still add a lot of lag,
although it will be synced at least). I've also thought about implementing
my own engine inside one single custom-node connected to the output, but
that's also not very inviting ;)

Peter

2012/8/3 Jussi Kalliokoski <jussi.kalliokoski@gmail.com>

> On Fri, Aug 3, 2012 at 8:27 PM, Peter van der Noord <peterdunord@gmail.com
> > wrote:
>
>> Well, that's pretty sad news. If this is the case, i'm afraid my
>> involvement with the API ends here, since i can't work around this (unless
>> someone has some good suggestions). I'm not into the lowerlevel mechanics
>> of the implementation, but i don't understand why the rest of the graph
>> can't (or shouldn't) wait for the custom-nodes to finish, what use is there
>> to supply the use of custom nodes if they add incremental lag.
>
>
> One tedious workaround is to "compensate" the lag by (I assume you already
> have your own wrapper of the API which makes this a bit easier) adding
> pass-through JavaScriptNodes to the points where the two connections need
> to be in sync.
>
> For example: http://i.imgur.com/wwRtl.png
>
>
>>
>> 2012/8/3 Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
>>
>>> It's a known and major issue all right, but it's not a bug. There's not
>>> much that can be done about it though, afaict. The processing thread has to
>>> buffer enough data (the buffer size) from the inputs of the JSNode before
>>> its callback can be invoked, and next it just sends an event to the JS
>>> thread to process the buffer. The audio thread, however, can't wait for the
>>> JS thread to process the buffer but instead plays back the previously
>>> processed buffer.
>>>
>>> This is one of the reasons why I think we should focus on empowering the
>>> JS node / DSP API. If you want to add any custom processing to the graph,
>>> you're going to have to adjust the rest of the graph accordingly and you'll
>>> end up with more latency. This means that if you want to do extensive
>>> custom processing you'll probably need to work around the graph or just go
>>> with just the JS and have your own routing which means you're in a much
>>> more flexible place already anyway. I think the graph serves best as an IO
>>> abstraction, and that's the part we should focus on.
>>>
>>> Cheers,
>>> Jussi
>>>
>>>
>>> On Fri, Aug 3, 2012 at 4:16 PM, Peter van der Noord <
>>> peterdunord@gmail.com> wrote:
>>>
>>>> Well, it seems indeed that custom-nodes add a delay-time to the signal.
>>>> I've connected a few bypass modules (they write their input to the output)
>>>> and i'm magically creating an echo...
>>>>
>>>> http://www.petervandernoord.nl/patchwork_js/?patch=2&buffer_size=8192
>>>>
>>>> (to hear sound, you have to select the loaded buffer from the pulldown
>>>> in the buffersource-module)
>>>>
>>>> I'm getting somewhat confused and concerned about this, why does this
>>>> happen and isn't this a major bug/issue?
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>> 2012/8/2 Adam Goode <agoode@google.com>
>>>>
>>>>> I think you can use playbackTime to determine the absolute a-rate time
>>>>> of the beginning of the javascript buffer. But last I checked it wasn't
>>>>> present in webkit.
>>>>>
>>>>> You might be able to count samples, assuming you know the node's
>>>>> noteOn time, to keep track of the a-rate time. But with a short buffer
>>>>> size, sometimes you can have problems as you've noticed.
>>>>>
>>>>>
>>>>> On Thu, Aug 2, 2012 at 4:47 PM, Peter van der Noord <
>>>>> peterdunord@gmail.com> wrote:
>>>>>
>>>>>> Ermmm.....wait, what? And that is intened behavior?
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> 2012/8/2 Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
>>>>>>
>>>>>>> Hey Peter!
>>>>>>>
>>>>>>> I think this is because the JSNode has a delay equivalent to the
>>>>>>> buffer size, hence if you have parallel graphs that contain a different
>>>>>>> number of JSNodes, they will arrive to the common destination at a
>>>>>>> different delay.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jussi
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 2, 2012 at 11:35 PM, Peter van der Noord <
>>>>>>> peterdunord@gmail.com> wrote:
>>>>>>>
>>>>>>>> I'm having a strange problem with some signals at the moment and
>>>>>>>> i've been staring at it for way too long now, so i thought: why not put it
>>>>>>>> up here, maybe someone sees what's going on. It's a lenghty story, so if
>>>>>>>> you want to hang on...i'll try to explain :)
>>>>>>>>
>>>>>>>> As you may know, i'm writing a modular synthesizer:
>>>>>>>>
>>>>>>>> http://petervandernoord.nl/patchwork_js (maybe clear your cache if
>>>>>>>> you've been there before)
>>>>>>>>
>>>>>>>> If you click the 'json to patch' button, a testpatch will be set.
>>>>>>>> (Important to know: all custom nodes will be created with the buffer-size
>>>>>>>> that's selected in the pulldown on the right). The patch contains 3 modules
>>>>>>>> (in patchwork, a module can contain one or more audionodes, with the
>>>>>>>> module's in/outputs mapped to certain in/outputs of the containing nodes):
>>>>>>>>
>>>>>>>> - The destination, which contains a normal destinationNode
>>>>>>>> http://localhost/patchworkjs/js/modules/DestinationModule.js
>>>>>>>>
>>>>>>>> - a clockmodule. one custom js node
>>>>>>>> http://localhost/patchworkjs/js/modules/DestinationModule.js
>>>>>>>>
>>>>>>>> - a triggersequencer, also one custom node.
>>>>>>>> http://localhost/patchworkjs/js/modules/TriggerSequencerModule.js(the audioprocess callback is at the bottom)
>>>>>>>>
>>>>>>>> What is happening in the patch: the clock sends out single values
>>>>>>>> of 1s (all other values are 0) on a given interval (set in BPM). The
>>>>>>>> sequencer checks on every incoming value if that value is >0 AND the
>>>>>>>> previous one was <=0 (i'll call that a clock-pulse). If that is the case,
>>>>>>>> its SequencerParameter will proceed to the next step. A sequencer-parameter
>>>>>>>> (actually it is a LogicSequencerParameter, but that's almost the same - it
>>>>>>>> has one extra method) can be found here:
>>>>>>>>
>>>>>>>> http://localhost/patchworkjs/js/params/SequenceParameter.js
>>>>>>>>
>>>>>>>> It's basically just an array filled ith 0s and 1s (you can set a 1
>>>>>>>> by clicking somewhere on the sequencer), and increases the current position
>>>>>>>> when it gets a next() command. So, back to the the sequencer module: If it
>>>>>>>> received a clock-pulse, it proceeds the sequencer. Then, if the (new) value
>>>>>>>> of the sequencer-parameter is 1, the sequencer will write a 1 in its
>>>>>>>> outputbuffer as well.
>>>>>>>>
>>>>>>>> My issues:
>>>>>>>> - in the testpatch, both the clockmodule and the seq-module are
>>>>>>>> connected to the output. if you activate some steps in the sequencer, you
>>>>>>>> will hear that the clicks do not run in sync. I have no idea why that is,
>>>>>>>> the stepsequencer writes a 1 in exact the same iteration as it reads the
>>>>>>>> incoming 1s from the clock. In my opinion, they should run exactly in sync.
>>>>>>>> - When you change the buffersize (which is for the customnodes) you
>>>>>>>> will hear that the timedifference between the ticks changes (since there's
>>>>>>>> no clear, you have to refresh the page, set another buffersize and click
>>>>>>>> 'json to patch')
>>>>>>>> - Something else i noticed: when i run just a clock module
>>>>>>>> connected to the output, with a very low buffersize (256, 512), the clock
>>>>>>>> seems to run very, very irregular.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, my main question: Does anyone have any idea why those two
>>>>>>>> modules do not run in sync when both connected to the output?
>>>>>>>>
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>