Re: [sc-users] Re: 64 bit signal processing in the server? pros & cons?

[James Harkins <jamshark70@xxxxxx>]

At Fri, 27 Nov 2015 21:40:43 -0700 (MST),
time_mechanic wrote:
> 
> ddw_music wrote
> > I guess my first, gut response to this is that the way of working you're
> > describing seems like a modular, analog-synth approach. Digital can do a
> > lot of things, but it will never *be* analog.
> 
> Yes that is precisely what I am trying to do and more. However, I do
> wholeheartedly admire the flexibility of the pattern system. I just wish it
> was faster. 

The pattern system is actually plenty /fast/. For fun, I benchmarked how long it takes to generate 1000 events of the pattern you're trying to play and send the messages out to the server. (Since I was doing this all at once, I kept the server turned off, though -- which doesn't affect language timing.) Runtime was about 50-60 ms, or 0.06 ms per event. If the pattern system genuinely could not keep up with 1 ms, it would have to be > 1 ms per event or > 1 sec for the whole benchmark.

s.quit;

// Assuming you've 'add'ed your original percSynth
p = Pbind(\instrument, \percSynth, \dur, 1/50).asStream;

bench {
	1000.do { p.next(Event.new).play };
};

time to run: 0.056427999999869 seconds.

So the audio jitter has nothing to do with the pattern system's speed.

> I have become accustomed to using linear ramps to drive all of my time
> dependent configurations because it guarantees precise synchronisation at a
> high resolution. In Max/PD, the message rate can be extremely fast.
> Getting bangs to trigger at sub millisecond intervals is easy using a metro
> object. In Max, the stock metro can do this.

Likewise, in SC, it's easy to run a Task with wait time < 0.001 sec. For it to run *successfully*, however, all of the processing within one iteration of the loop must take less than the wait time. I'm quite sure this would be the same in Max. If it takes 2 ms, in a large and complex patch, for a bang at the top to finish all its work through the rest of the patch, then generating bangs every 1 ms or less will accomplish nothing except overwhelm the system.

> In PD, there is a work around
> but it works and is solid. The idea is simple. The metro outputs a stream of
> triggers which is fed to a counter.

OK, you started by talking about linear ramps -- and questioning their value based on a SinOsc test -- but now you're talking about triggers. Those aren't the same thing.

Triggers are relatively easy. You can run an Impulse.ar onto an audio bus. Then, other synths can read from that bus and do whatever PulseCount, PulseDivider etc. operations they want.

The problem with this is that the server's sample rate is, in reality, very slightly imprecise. SC has no control over this -- it comes from the audio interface's clock. The error is very small -- I estimate on my system that I will "lose" one second of audio output every 14-15 hours or so.

// error, per second, in seconds: (s - a) is in samples, divide by sr for secs
(s.sampleRate - s.actualSampleRate) / s.sampleRate
-> 1.9291496275417e-05  // 0.000001929% !!!

// how long for this error to total 1 sec?
// 1 / ((error) / sampleRate) = sampleRate / error
s.sampleRate / (s.sampleRate - s.actualSampleRate)
-> 51836.310969528  // seconds

51836.310969528 / 3600  // hours
-> 14.398975269313

When playing patterns even at drill'n'bass tempi, the error is undetectable to the ear. If you require absolute precision in triggering down to sub-ms resolution, then it may become a factor when you try to synchronize with language-side patterns. (But if you're doing all the sequencing on the server-side, maybe that's not an issue.)

If you're on Linux (and maybe on OSX -- I'm not sure of it's status), you could try supernova. It cues message timestamps off of the audio clock, not the system clock.

Your SinOsc phase-input test is interesting, but I'm not sure it's relevant to the accuracy of *triggers*. I just glanced at the source code for SinOsc, and I have my doubts that audio-rate phase modulation is absolutely 100% reliable when freq == 0.0. Good enough for PM synthesis, but probably not good enough for a pure sine tone. 

hjh

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/