OSCresponderNode

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