[flocking-users] combining with processingjs? and timing accuracy

Colin Clark colin at colinclark.org
Tue Apr 22 09:33:22 EDT 2014


I’m really glad to hear it! I’ll write up some documentation about this issue as soon as I can. Thanks for your help in pointing it out!

Colin

On Apr 22, 2014, at 8:52 AM, enrike <altern2 at gmail.com> wrote:

> flock.init({
>    bufferSize: 512
> });
> 
> this above was crucial! both the latency on the clicks and the slow graphics are fixed now
> 
> thanks!
> 
> enrike
> 
> 
> al., 2014.eko apiren 21a 05:29(e)an, Colin Clark(e)k idatzi zuen:
>> Hi again Enrike,
>> 
>> Thanks for all the great questions. Responses inline…
>> 
>> On Apr 20, 2014, at 5:15 AM, enrike <altern2 at gmail.com> wrote:
>> 
>>> is there a way to make a synth to run but not to play its sound output? I am trying to get a rect() in processingjs to change its width controlled by a sinOsc from flockingjs. The sinOsc is running at a frequency of 0.3. I would like to use that sinOsc only to produce contol data, not sound. Maybe I need to set its rate to "control"? but how do I do that? I see a reference in the docs but I dont find any example.
>> 
>> Yes, you should be able to use a valueOut ugen to do this. If you don’t specify an output unit generator in a Flocking synthDef, one will be added automatically for you. By default, it will output to the speakers.
>> 
>> In your case, you want the synth to be evaluated but not to output to the speakers. The flock.ugen.valueOut unit generator does exactly this. Here’s an example:
>> 
>> var synth = flock.synth({
>>     synthDef: {
>>         ugen: "flock.ugen.valueOut",
>>         sources: {
>>             ugen: "flock.ugen.triggerCallback",
>>             source: {
>>                 id: "carrier",
>>                 ugen: "flock.ugen.sinOsc",
>>                 freq: 0.3, //LFO
>>                 mul: 1
>>             },
>>             trigger: {
>>                 ugen: "flock.ugen.impulse",
>>                 freq: 30, //FPS
>>             },
>>             options: {
>>                 callback: {
>>                     func: doit
>>                 }
>>             }
>>         }
>>     }
>> });
>> 
>>> Also, the impulse I am using to trigger the callback is running at a frequency of 30 but I am getting pretty random updates on the processing side. probably ~2 fps. The processing graphics update is around 30fps so any changes in the graphics from the processing code are quickly updated. Any ideas if I am doing something or if there is some bottleneck in the communication between Processingjs and flockingjs? this is part of the flockingjs code that deals with this issue
>> 
>> Hmm, this sounds strange to me. I can’t think of any reason why there should be a bottleneck, unless the Processing code is particularly CPU intensive, which it doesn’t appear to be.
>> 
>> Can you send along the HTML page you use to run these two pieces of code together so I can try it out myself and take a look?
>> 
>>> Finally I am also calling a function in flocking from Processing but there is like 0.5 sec latency. In Processingjs I do
>>> void mousePressed()
>>> {
>>>  playSine(mouseX);
>>> }
>>> 
>>> and in Flockingjs I do
>>> function playSine(freq)
>>> {
>>> 	sine.play();
>>> 	sine.input("sine.freq", freq);
>>> 	setTimeout(	sine.pause, 1000 );
>>> }
>>> where the sine var contains a synth with a simple sinOsc
>> 
>> Which browser are you using to test with? By default, I’ve set the latency to be fairly high on Firefox, because I’ve noticed some unpredictable glitching in recent versions of the browser. I’m on the beta channel and these seem to have improved, but I haven’t done any formal tests recently. Firefox also appears to be doing double-buffering, which might account for the degree of latency you’re seeing. Much as it pains me to say, Chrome has the better Web Audio implementation at the moment.
>> 
>> You can control the buffer size (and hence the latency) in Flocking by explicitly calling flock.init() at the beginning of your code. The Web Audio API supports buffer sizes down to 256 samples (about six milliseconds--twice that on Firefox, I think), but the complexity of your code will determine what kind of latency you can get away with. I usually use buffer sizes of between 256 and 1024 samples depending on how complex my music is.
>> 
>> Here’s an example:
>> 
>> flock.init({
>>     bufferSize: 512
>> });
>> 
>> Let me know if that improves the latency of your button clicks.
>> 
>> Colin
>> 
>> 
> 




More information about the flocking mailing list