OSCresponderNode

[Joe Mariglio]

Hi all,

I'm trying to trigger subsample accurate grains using OSCresponderNode, but I'm running into a rate limitation that ends up sounding like ring modulation, with the modulator frequency at a multiple of 44100/64, which also happens to be server's sample rate over blockSize.  Nevertheless, I've determined it's not scsynth but rather OSCresponderNode itself which limits the response rate to this frequency. 

I'm using the responder to trigger layers of synchronous grains whose trigger rate is the reciprocal of their frequency, ranging across the spectrum.  the grains' amplitudes are the result of analysis happening on the server which sends these '/tr' messages back to the client for evaluation into "/s_new" messages.  but alas!  OSCresponderNode limits the rate at which these "/s_new" messages can be sent!

i'm thinking of maybe using the '/tr' messages as signals for change of amplitude state for each band, rather than to trigger the grains themselves, thus easing the load being placed on OSCresponderNode.  in this hypothetical implementation, the '/tr' messages would trigger trains of particles using either patterns or routines, which are fast enough.  however, i want to implement this on remote servers across a network so I'm unsure how to use the pattern paradigm for that. 

I'm currently looking into using OSCresponderNode to toggle routines which will handle spawning the grains, but this is cumbersome.  if it were on one machine i'd be using patterns i guess, but still the process would be quite annoying. 

what's the deal with OSCresoponder's draconian rate limit and why will it not listen to reason?  even if i use <server>.sendBundle(latency, [msg]) directly inside an OSCresponderNode, the distortion appears, whereas using sendBundle within a Routine seems just fine.  le sigh.

JM

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Joe Mariglio]

Hi again,
Rereading through this, it occurs to me some examples would be helpful.

the server-side triggers for the grains are the result of bandpass filters, lots of them:

SynthDef("filter", {|freq = 128, in = 16, on = 1, thresh = 0.0125, rq = 0.025|
    var amp, rate, t0, t1, t2, bound;

//reads the amplitude of the result of a bandpass filter on incoming signal;

    amp = Amplitude.kr(BPF.ar(InFeedback.ar(in), freq, rq));

//a retrigger rate for persistent bands, NOT 1/freq as i said above, but rather just freq (note audio rate)

    rate = Impulse.ar(freq);

//define three scalable regions of amplitude.  scalable, hence the weird recursive "bound*1.5" action

    bound = thresh;
    t0 = bound*1.5 > amp > bound;
    bound = bound*1.5;
    t1 = bound*1.5 > amp > bound;
    bound = bound*1.5;
    t2 = bound*1.5 > amp;

// tN = change of state , tN && rate = presence in state.  (again note audio rate)

    SendTrig.ar(t0 && rate, 0, freq);
    SendTrig.ar(t1 && rate, 1, freq);
    SendTrig.ar(t2 && rate, 2, freq);

}).send(s);


/* a lot of these are spread across the spectrum and contained in an array. */

a = (12, 12.2..135).midicps; //geometric spacing

b = a.collect({|x|
    Synth.new("filter", [\freq, x]);
    });
   
/* the OSCresponderNode.  added only once.

c = OSCresponderNode(s.addr,'/tr',
    {|time, responder, msg|
        var frq, amp;
        frq = msg[3];
        amp = msg[2] + 1;

/* this part changes quite a lot, with new grain types and different destinations.*/
/* this paradigm made it really intuitive to substitute 's' for the result of iterating
through an array of available servers, for example. */
/* also note the scaling for translating amplitude state for 'real' amplitude*/

        s.sendMsg("/s_new", "sine_subsample", -1, 0, 0, \freq, frq, \amp, amp/3);

        }
    ).add;

/* and finally, the grain: */

SynthDef("sine_subsample",{ arg out=0, freq = 440, cyc = 8, amp = 3;
    var sig, osc, offset, length, env, sd;

    sd = SampleDur.ir;
    length = cyc/freq;
    env = EnvGen.kr(Env.sine(length), 1.0);
    offset = (1-SubsampleOffset.ir) * sd;
    Line.ar(1,0, length + offset, doneAction:2);

//amplitude is scaled way back because there's gonna be a lot of these

    osc = FSinOsc.ar(freq, 0, 0.025*amp);
    sig = DelayC.ar(env * osc, sd*4, offset);

//widest spread, done cheaply.

    OffsetOut.ar(IRand(out, out+1), sig)
}).send(s);

/* one cycle grains, should be subsample accurate (as far as I can hear) .  */

so this thing works for me in the sense that the filters trigger grains and with big enough grains, that underlying-subharmonic-amplitude-mod-thing goes away.  but still it bugs me that i'm losing out on all that information.  i've done so many modifications to and tests on this paradigm that i'm nearly positive it's OSCresponderNode's fault.  is there a really simple, obvious and more efficient way of doing this? 

-Joe

On Wed, May 7, 2008 at 6:36 AM, Joe Mariglio <joe.mariglio@...> wrote:

Hi all,

I'm trying to trigger subsample accurate grains using OSCresponderNode, but I'm running into a rate limitation that ends up sounding like ring modulation, with the modulator frequency at a multiple of 44100/64, which also happens to be server's sample rate over blockSize.  Nevertheless, I've determined it's not scsynth but rather OSCresponderNode itself which limits the response rate to this frequency. 

I'm using the responder to trigger layers of synchronous grains whose trigger rate is the reciprocal of their frequency, ranging across the spectrum.  the grains' amplitudes are the result of analysis happening on the server which sends these '/tr' messages back to the client for evaluation into "/s_new" messages.  but alas!  OSCresponderNode limits the rate at which these "/s_new" messages can be sent!

i'm thinking of maybe using the '/tr' messages as signals for change of amplitude state for each band, rather than to trigger the grains themselves, thus easing the load being placed on OSCresponderNode.  in this hypothetical implementation, the '/tr' messages would trigger trains of particles using either patterns or routines, which are fast enough.  however, i want to implement this on remote servers across a network so I'm unsure how to use the pattern paradigm for that. 

I'm currently looking into using OSCresponderNode to toggle routines which will handle spawning the grains, but this is cumbersome.  if it were on one machine i'd be using patterns i guess, but still the process would be quite annoying. 

what's the deal with OSCresoponder's draconian rate limit and why will it not listen to reason?  even if i use <server>.sendBundle(latency, [msg]) directly inside an OSCresponderNode, the distortion appears, whereas using sendBundle within a Routine seems just fine.  le sigh.

JM

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[James Harkins-2]

OSCresponder does not have subsample time resolution -- actually, it
CAN'T even under optimal conditions. It can respond only when the
message is received in the client, and this involves a small but
unknown network latency time. The latency can be expected to be within
a certain range, but it isn't a fixed value.

Using OSCresponder for absolute timing precision is, unfortunately,
likely to be a disappointing experience.

Routines/Tasks/Patterns allow better control over event timing for
reasons described in the ServerTiming help file -- however even this
seems not to be wholly sample accurate because of sample clock drift
in the server itself. (I recall a discussion on the list about this a
couple of months ago.)

In terms of timing, Patterns and Routines aren't fundamentally
different. The backend scheduling mechanism for both is the same.

Don't have time at the moment to read over your examples and
brainstorm... perhaps later.
hjh


On Wed, May 7, 2008 at 6:36 AM, Joe Mariglio <joe.mariglio@...> wrote:
> Hi all,
>
> I'm trying to trigger subsample accurate grains using OSCresponderNode, but
> I'm running into a rate limitation that ends up sounding like ring
> modulation, with the modulator frequency at a multiple of 44100/64, which
> also happens to be server's sample rate over blockSize.  Nevertheless, I've
> determined it's not scsynth but rather OSCresponderNode itself which limits
> the response rate to this frequency.


--
James Harkins /// dewdrop world
jamshark70@...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Josh Parmenter]

Maybe use the Grain UGens to make your grains, then send those through  
the subsample delay? Set up a synth that will create one grain when it  
gets a trigger, then send that through the subsample delay.

Instead of using SendTrig - route the trigger data out to an audio  
bus, and have your grain synthdef listen on those audio busses for  
when to start the grain. This removes the language altogether, and  
should work (I think).

Make sure the grain synths are executed after the filter synth (so  
they can catch the triggered values)

Hope that helps.

Josh

On May 7, 2008, at 8:01 AM, James Harkins wrote:

> OSCresponder does not have subsample time resolution -- actually, it
> CAN'T even under optimal conditions. It can respond only when the
> message is received in the client, and this involves a small but
> unknown network latency time. The latency can be expected to be within
> a certain range, but it isn't a fixed value.
>
> Using OSCresponder for absolute timing precision is, unfortunately,
> likely to be a disappointing experience.
>
> Routines/Tasks/Patterns allow better control over event timing for
> reasons described in the ServerTiming help file -- however even this
> seems not to be wholly sample accurate because of sample clock drift
> in the server itself. (I recall a discussion on the list about this a
> couple of months ago.)
>
> In terms of timing, Patterns and Routines aren't fundamentally
> different. The backend scheduling mechanism for both is the same.
>
> Don't have time at the moment to read over your examples and
> brainstorm... perhaps later.
> hjh
>
>
> On Wed, May 7, 2008 at 6:36 AM, Joe Mariglio  
> <joe.mariglio@...> wrote:
>> Hi all,
>>
>> I'm trying to trigger subsample accurate grains using  
>> OSCresponderNode, but
>> I'm running into a rate limitation that ends up sounding like ring
>> modulation, with the modulator frequency at a multiple of 44100/64,  
>> which
>> also happens to be server's sample rate over blockSize.  
>> Nevertheless, I've
>> determined it's not scsynth but rather OSCresponderNode itself  
>> which limits
>> the response rate to this frequency.
>
>
> --
> James Harkins /// dewdrop world
> jamshark70@...
> http://www.dewdrop-world.net
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal." -- Whitman
> _______________________________________________
> sc-users mailing list
> sc-users@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-users

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[nescivi]

On Wednesday 07 May 2008 06:36:44 Joe Mariglio wrote:
> what's the deal with OSCresoponder's draconian rate limit and why will it
> not listen to reason?  even if i use <server>.sendBundle(latency, [msg])
> directly inside an OSCresponderNode, the distortion appears, whereas using
> sendBundle within a Routine seems just fine.  le sigh.

I have a suspicion that SendTrig cannot send sample accurate triggers. The
triggers are FIFO to a non-realtime thread, which I am guessing are harvested
only every controlcycle, for actual sending out.

Use Josh'es suggestion to make a server side only implementation of what you
want to do.

sincerely,
Marije
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Joe Mariglio]

Marije:

I have a suspicion that SendTrig cannot send sample accurate triggers. The
triggers are FIFO to a non-realtime thread, which I am guessing are harvested
only every controlcycle, for actual sending out.

 

ouch that's lame, but not so much an issue now.  i came up with an implementation that defines regions of spectral activity and sends only changes of state to the client for evaluation.  this need not be sample accurate.  from there, the client activates routines that send synchronous or quasi-synchronous timestamped oscBundles.  i assume those to be subsample accurate. 

//so 'a' is the gamut, with a different routine dedicated to each layer in the gamut:

a = Array.geom(400, 16, 2**(1/40));
~layers = a.collect({|x, i|
                                    Task({
                                        loop({
                                            s.sendBundle(0.1, [9, "sine_subsample", -1, 0, 0, \freq, x]);
                                            (1/x).wait;
                                            })
                                        })
                                    });
//the filterbank uses the same gamut, and triggers the client only when a boundary is crossed:

SynthDef("filter", {|freq = 128, in = 16, cyc = 4, thresh = 0.0125, rq = 0.025|
    var amp, rate, t0, t1;
    amp = Amplitude.kr(BPF.ar(InFeedback.ar(in), freq, rq));
    t0 = amp < thresh;
    t1 = thresh < amp;
    SendTrig.kr(Latch.kr(t0, Impulse.kr(freq/cyc)), 0, freq);
    SendTrig.kr(Latch.kr(t1, Impulse.kr(freq/cyc)), 1, freq);
}).send(s);

//right now there is only one 'bit' of amplitude data (on/off), but this will change.
//the responder just has to toggle the appropriate routine based on control rate data sent by the filters

~responder = OSCresponderNode(s.addr, '/tr',
                                                    {|time, responder, msg|
                                                        var frq, amp, laya;
                                                        frq = msg[3];
                                                        amp = msg[2];
                                                        laya = ~layers[a.indexIn(frq)];
                                                        amp.switch(
                                                            0, {laya.stop},
                                                            1, {laya.play}
                                                            );
                                                            });

Use Josh'es suggestion to make a server side only implementation of what you
want to do.

 

the problem with keeping everything server-side is that i want to implement this across a cluster of remote scsynth instances in a network, with my laptop as the 'head node', doing analysis and task management.  any suggestions for how to accomplish this while keeping everything server-side? 

at this point, the information about the spectrum is abstracted into explicitly written oscBundles.  if i wanted to, i could point those to a selection from an array of remote scsynths or other software.  also having client-side knowledge of that data allows me to do things like fill an array and create a score for NRT manipulation and resynthesis.  as far as i comprehend, i could not do most of these things if i kept the process server-side.  am i wrong in believing this?

jm

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users