Re: Help needed with a sync-problem

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