Quantcast

Ringz, Formlet, sample rate

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ringz, Formlet, sample rate

ddw_music
I've got some code from a year and a half ago.

When I ran it back then, it was reliable.

When I run it now (at 44.1kHz, as I did originally), it's mostly reliable but one element occasionally exceeds the MixerChannel clipping threshold.

When I run it now at 48kHz, it exceeds that threshold more often: i.e. the average level for that element must be a little louder.

When I run it at 96kHz, it *always* exceeds the threshold. The average level must be a LOT louder.

The synth is using several Formlets, driven by a short burst of pink noise. That's nondeterministic = hard to measure peak level changes reliably, so I tried Formlets driven by a single Impulse. I get a deterministic result, but only very slight differences in peak level -- nothing that would add 6 or more dB at higher sample rates. But in the pink noise case, I'm getting huge differences between 44.1kHz and 96kHz.

I've been asked to produce a higher sample rate version of the audio, but I have no idea how much to reduce the mixer level to compensate. Other elements' levels will not change -- so this weird behavior is throwing off the mix, and I'm not even comfortable shipping the 48kHz version because I can't measure accurately how much louder the problem synth is.

Any ideas?

Or I just tell them that I can't do it because the synth technique is sensitive to sample rate. Not a good advertisement for SuperCollider, though.

hjh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Glen Fraser
What happens if you LPF the PinkNoise at 22kHz?


On Wed, Jan 11, 2017 at 9:40 AM, ddw_music <[hidden email]> wrote:
I've got some code from a year and a half ago.

When I ran it back then, it was reliable.

When I run it now (at 44.1kHz, as I did originally), it's mostly reliable
but one element occasionally exceeds the MixerChannel clipping threshold.

When I run it now at 48kHz, it exceeds that threshold more often: i.e. the
average level for that element must be a little louder.

When I run it at 96kHz, it *always* exceeds the threshold. The average level
must be a LOT louder.

The synth is using several Formlets, driven by a short burst of pink noise.
That's nondeterministic = hard to measure peak level changes reliably, so I
tried Formlets driven by a single Impulse. I get a deterministic result, but
only very slight differences in peak level -- nothing that would add 6 or
more dB at higher sample rates. But in the pink noise case, I'm getting huge
differences between 44.1kHz and 96kHz.

I've been asked to produce a higher sample rate version of the audio, but I
have no idea how much to reduce the mixer level to compensate. Other
elements' levels will not change -- so this weird behavior is throwing off
the mix, and I'm not even comfortable shipping the 48kHz version because I
can't measure accurately how much louder the problem synth is.

Any ideas?

Or I just tell them that I can't do it because the synth technique is
sensitive to sample rate. Not a good advertisement for SuperCollider,
though.

hjh



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Ringz-Formlet-sample-rate-tp7630065.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Glen Fraser
It does seem to be the case here, too:

s.options.sampleRate = 44100; // try one...
s.options.sampleRate = 88200; // ...or the other
s.reboot;

{ var sig = Formlet.ar(Decay.ar(Impulse.ar(2), 0.1, mul: LPF.ar(PinkNoise.ar, 22050)), 440, 0.05, 0.4, 0.1); RunningMax.ar(sig).ampdb.poll(1); sig }.scope 

On 44100, after running about 30 seconds, I had a max of about -8 dB in one run.  With 88200, I got quite quickly (less than 10 seconds) to -1.8 dB!  I know it's random, but if you run each of them for a long time, it's quite clear (as you found) that the higher sample rate gives much higher "energy".  You can also hear it, and see it in the scope.

On second thought, maybe it's not PinkNoise that's the culprit, but rather Formlet:

s.options.sampleRate = 44100; // try one...
s.options.sampleRate = 88200; // ...or the other
s.reboot;

{ var sig = Formlet.ar(Decay.ar(Impulse.ar(4), 0.1, mul: 0.5), 440, 0.05, 0.4, 0.1); RunningMax.ar(sig).ampdb.poll(1); sig }.scope 

I get a running max of -11.6 dB at 44.1 kHz, and -5.6 dB at 88.2 kHz.

Not sure if that helps... not much...  (-;

Glen.


On Wed, Jan 11, 2017 at 2:23 PM, Glen F <[hidden email]> wrote:
What happens if you LPF the PinkNoise at 22kHz?


On Wed, Jan 11, 2017 at 9:40 AM, ddw_music <[hidden email]> wrote:
I've got some code from a year and a half ago.

When I ran it back then, it was reliable.

When I run it now (at 44.1kHz, as I did originally), it's mostly reliable
but one element occasionally exceeds the MixerChannel clipping threshold.

When I run it now at 48kHz, it exceeds that threshold more often: i.e. the
average level for that element must be a little louder.

When I run it at 96kHz, it *always* exceeds the threshold. The average level
must be a LOT louder.

The synth is using several Formlets, driven by a short burst of pink noise.
That's nondeterministic = hard to measure peak level changes reliably, so I
tried Formlets driven by a single Impulse. I get a deterministic result, but
only very slight differences in peak level -- nothing that would add 6 or
more dB at higher sample rates. But in the pink noise case, I'm getting huge
differences between 44.1kHz and 96kHz.

I've been asked to produce a higher sample rate version of the audio, but I
have no idea how much to reduce the mixer level to compensate. Other
elements' levels will not change -- so this weird behavior is throwing off
the mix, and I'm not even comfortable shipping the 48kHz version because I
can't measure accurately how much louder the problem synth is.

Any ideas?

Or I just tell them that I can't do it because the synth technique is
sensitive to sample rate. Not a good advertisement for SuperCollider,
though.

hjh



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Ringz-Formlet-sample-rate-tp7630065.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

ddw_music
In reply to this post by Glen Fraser
Glen Fraser wrote
What happens if you LPF the PinkNoise at 22kHz?
I was kind of heading that direction, but wanted to avoid it because the whole point of re-rendering at a higher sample rate was to allow higher partials to be produced...

Anyway, hard data proving my informal observation:

44.1kHz:
|          |       110 |      220 |      440 |      880 |
|----------+-----------+----------+----------+----------|
| max peak | 14.963339 | 6.547451 | 3.619412 | 2.367508 |
| avg peak |  5.621218 | 2.570018 | 1.836453 | 1.061382 |
| max rms  |  2.960487 | 1.325935 | 0.742221 | 0.470258 |
| avg rms  |  1.105638 | 0.487678 | 0.366603 | 0.206446 |

48kHz:
|          |       110 |      220 |      440 |      880 |
|----------+-----------+----------+----------+----------|
| max peak | 18.710405 | 8.059298 | 4.356654 | 2.961581 |
| avg peak |  6.053147 | 3.067358 |  1.81074 | 1.143205 |
| max rms  |  3.713527 | 1.616256 | 0.867722 | 0.593216 |
| avg rms  |  1.167052 | 0.600419 | 0.356967 | 0.225793 |

96kHz:
|          |       110 |       220 |      440 |      880 |
|----------+-----------+-----------+----------+----------|
| max peak | 34.569359 | 13.135559 | 5.984353 | 4.238211 |
| avg peak | 12.143966 |  6.557746 |  3.11234 | 2.387967 |
| max rms  |  6.880011 |  2.582498 | 1.238221 | 0.859845 |
| avg rms  |  2.370245 |  1.294991 | 0.600425 | 0.470544 |

Max peak @ 110 Hz = 34.569359 / 14.963339 = 7.27 dB difference between 96kHz and 44.1kHz :-O

But again, I couldn't reproduce anything like this when the Formlet input was a Dirac impulse -- so clearly it's the combination of noise --> Formlet.

Always a surprise in DSP-land...

hjh

Test code (which I think is kind of cool):

(
var printDataRow = { |array, w = 8, stream(Post)|
        array.do { |item|
                var str = item.asFloat.round(0.000001).asString;
                stream << "| ";
                if(str.size < w) { stream << String.fill(w - str.size, $ ) };
                stream << str << " ";
        };
        stream << "|\n";
};

s.waitForBoot {
        var cond = Condition.new,
        freqs = 55 * (2 ** (1..8)),
        w = 8, stream = Post, hr,
        a, resp, dataResp,
        stats;
        SynthDef(\test, { |n = 50|
                var trig = Impulse.ar(2),
                exc = PinkNoise.ar * EnvGen.ar(Env.perc(0.003, 0.01), trig),
                sig = Formlet.ar(exc, freqs, 0.01, 0.5),
                // problem: I need to trigger the Phasor integrator *after* sending data
                phasorTrig = Impulse.ar(0) + Delay1.ar(trig),
                // RMS instead of arithmetic mean
                stats = [Peak.ar(sig, trig),
                        sqrt(Phasor.ar(phasorTrig, sig.squared, 0, 1e30, 0) / (SampleRate.ir * 0.5))
                ],
                count = PulseCount.ar(trig);
                SendReply.ar(trig * (count > 1), '/stats', stats.flat);
                FreeSelf.kr(A2K.kr(count) > n);
        }).add;
        s.sync;
        d = List.new;
        a = Synth(\test, [n: 50]);
        dataResp = OSCFunc({ |msg|
                var data = msg[3..].clump(freqs.size);
                "\nmax: %\navg: %\n".postf(*data);
                d.add(data);
        }, '/stats', s.addr);
        resp = OSCFunc({ cond.unhang }, '/n_end', s.addr, argTemplate: [a.nodeID]).oneShot;
        cond.hang;
        dataResp.free;
        // print as org-style table
        hr = String.fill(w+2, $-);
        ["max", "rms"].do { |label, i|
                stream << "\n\n%\n".format(label);
                printDataRow.(freqs, w, stream);
                freqs.size.do { |i|
                        if(i == 0) {
                                stream << "|" << hr
                        } {
                                stream << "+" << hr
                        }
                }; stream << "|\n";
                d.do { |row| printDataRow.(row[i], w, stream) };
        };
        // print overall stats
        stream << "\n\nOverall\n";
        printDataRow.(freqs, w, stream);
        freqs.size.do { |i|
                if(i == 0) {
                        stream << "|" << hr
                } {
                        stream << "+" << hr
                }
        }; stream << "|\n";
        stats = d.flop.collect(_.flop);
        stats.do { |row|
                printDataRow.(row.collect(_.maxItem), w, stream);
                printDataRow.(row.collect(_.mean), w, stream);
        };
};
)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Glen Fraser
Actually, try a HPF too, of say 20 or 40 Hz, as the wandering "brownness" generation might add some occasional very low DC-ish offsets. Though don't know why they would be so different at different sample rates.

But as I said, even just Formlet alone was showing quite a big difference for me, repeatable, with deterministic input like decayed pulses...

G.

On Jan 11, 2017 17:23, "ddw_music" <[hidden email]> wrote:
Glen Fraser wrote
> What happens if you LPF the PinkNoise at 22kHz?

I was kind of heading that direction, but wanted to avoid it because the
whole point of re-rendering at a higher sample rate was to allow higher
partials to be produced...

Anyway, hard data proving my informal observation:

44.1kHz:
|          |       110 |      220 |      440 |      880 |
|----------+-----------+----------+----------+----------|
| max peak | 14.963339 | 6.547451 | 3.619412 | 2.367508 |
| avg peak |  5.621218 | 2.570018 | 1.836453 | 1.061382 |
| max rms  |  2.960487 | 1.325935 | 0.742221 | 0.470258 |
| avg rms  |  1.105638 | 0.487678 | 0.366603 | 0.206446 |

48kHz:
|          |       110 |      220 |      440 |      880 |
|----------+-----------+----------+----------+----------|
| max peak | 18.710405 | 8.059298 | 4.356654 | 2.961581 |
| avg peak |  6.053147 | 3.067358 |  1.81074 | 1.143205 |
| max rms  |  3.713527 | 1.616256 | 0.867722 | 0.593216 |
| avg rms  |  1.167052 | 0.600419 | 0.356967 | 0.225793 |

96kHz:
|          |       110 |       220 |      440 |      880 |
|----------+-----------+-----------+----------+----------|
| max peak | 34.569359 | 13.135559 | 5.984353 | 4.238211 |
| avg peak | 12.143966 |  6.557746 |  3.11234 | 2.387967 |
| max rms  |  6.880011 |  2.582498 | 1.238221 | 0.859845 |
| avg rms  |  2.370245 |  1.294991 | 0.600425 | 0.470544 |

Max peak @ 110 Hz = 34.569359 / 14.963339 = 7.27 dB difference between 96kHz
and 44.1kHz :-O

But again, I couldn't reproduce anything like this when the Formlet input
was a Dirac impulse -- so clearly it's the combination of noise --> Formlet.

Always a surprise in DSP-land...

hjh

Test code (which I think is kind of cool):

(
var printDataRow = { |array, w = 8, stream(Post)|
        array.do { |item|
                var str = item.asFloat.round(0.000001).asString;
                stream << "| ";
                if(str.size < w) { stream << String.fill(w - str.size, $ ) };
                stream << str << " ";
        };
        stream << "|\n";
};

s.waitForBoot {
        var cond = Condition.new,
        freqs = 55 * (2 ** (1..8)),
        w = 8, stream = Post, hr,
        a, resp, dataResp,
        stats;
        SynthDef(\test, { |n = 50|
                var trig = Impulse.ar(2),
                exc = PinkNoise.ar * EnvGen.ar(Env.perc(0.003, 0.01), trig),
                sig = Formlet.ar(exc, freqs, 0.01, 0.5),
                // problem: I need to trigger the Phasor integrator *after* sending data
                phasorTrig = Impulse.ar(0) + Delay1.ar(trig),
                // RMS instead of arithmetic mean
                stats = [Peak.ar(sig, trig),
                        sqrt(Phasor.ar(phasorTrig, sig.squared, 0, 1e30, 0) / (SampleRate.ir *
0.5))
                ],
                count = PulseCount.ar(trig);
                SendReply.ar(trig * (count > 1), '/stats', stats.flat);
                FreeSelf.kr(A2K.kr(count) > n);
        }).add;
        s.sync;
        d = List.new;
        a = Synth(\test, [n: 50]);
        dataResp = OSCFunc({ |msg|
                var data = msg[3..].clump(freqs.size);
                "\nmax: %\navg: %\n".postf(*data);
                d.add(data);
        }, '/stats', s.addr);
        resp = OSCFunc({ cond.unhang }, '/n_end', s.addr, argTemplate:
[a.nodeID]).oneShot;
        cond.hang;
        dataResp.free;
        // print as org-style table
        hr = String.fill(w+2, $-);
        ["max", "rms"].do { |label, i|
                stream << "\n\n%\n".format(label);
                printDataRow.(freqs, w, stream);
                freqs.size.do { |i|
                        if(i == 0) {
                                stream << "|" << hr
                        } {
                                stream << "+" << hr
                        }
                }; stream << "|\n";
                d.do { |row| printDataRow.(row[i], w, stream) };
        };
        // print overall stats
        stream << "\n\nOverall\n";
        printDataRow.(freqs, w, stream);
        freqs.size.do { |i|
                if(i == 0) {
                        stream << "|" << hr
                } {
                        stream << "+" << hr
                }
        }; stream << "|\n";
        stats = d.flop.collect(_.flop);
        stats.do { |row|
                printDataRow.(row.collect(_.maxItem), w, stream);
                printDataRow.(row.collect(_.mean), w, stream);
        };
};
)



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Ringz-Formlet-sample-rate-tp7630065p7630070.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Nathan Ho
In reply to this post by ddw_music
On 2017-01-11 00:40, ddw_music wrote:

> The synth is using several Formlets, driven by a short burst of pink
> noise.
> That's nondeterministic = hard to measure peak level changes reliably,
> so I
> tried Formlets driven by a single Impulse. I get a deterministic
> result, but
> only very slight differences in peak level -- nothing that would add 6
> or
> more dB at higher sample rates. But in the pink noise case, I'm getting
> huge
> differences between 44.1kHz and 96kHz.

Using a rectangular pulse as input, I can reproduce this
deterministically:

(
{
     Formlet.ar(Env.linen(0, 0.005, 0).ar, 440, 0.001, 0.01);
}.loadToFloatArray(0.01, s, action: { |array| array.abs.maxItem.postln
});
)


Here are the peaks:

44.1kHz: 5.575448513031
48kHz: 6.0593361854553
96kHz: 12.031888008118


Nathan

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Nathan Ho
On 2017-01-11 10:31, Nathan Ho wrote:
> Here are the peaks:
>
> 44.1kHz: 5.575448513031
> 48kHz: 6.0593361854553
> 96kHz: 12.031888008118

Ringz is similar:

44.1kHz: 2.3534990847111
48kHz: 2.5408102199435
96kHz: 4.7334305942059

In both cases (although the ratios aren't identical) there's a roughly
6dB difference between 48 and 96 and an 0.7dB difference between 44.1
and 48.


Nathan

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Nathan Ho
On 2017-01-11 12:05, Nathan Ho wrote:
> In both cases (although the ratios aren't identical) there's a roughly
> 6dB difference between 48 and 96 and an 0.7dB difference between 44.1
> and 48.

Obviously, this is proportional to the sample rates themselves. I
believe I've figured out why. There are two competing definitions of
sample-rate independence (hereafter SRI).

1. F is an SRI digital filter if, for every analog signal X, the chain
"X => ideal ADC => F at SR => ideal DAC" produces the same analog signal
for every sample rate SR that exceeds the Nyquist rate of X (that is, Fs
 > 2B if X is bandlimited at B).

2. F is an "impulse-SRI" digital filter if, for every sample rate SR,
the chain "digital impulse of amplitude 1 => F at SR => ideal DAC"
produces the same analog signal.

Here's the important part: a digital impulse of amplitude 1 corresponds
to a different analog signal depending on the sample rate. Think of what
happens when you interpolate it with a sinc function: it gets squeezed
inwards as you increase the SR. So the two definitions are quite
different.

Most digital filter implementations are SRI. Try evaluating the maximum
value of LPF.ar(Impulse.ar(0)) at different sample rates.

Ringz and Formlet are impulse-SRI. Why? Because most people using them
are going to be feeding digital impulses, and they expect
Ringz.ar(Impulse.ar(0)) to have the same amplitude regardless of SR.


Nathan

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Glen Fraser
Wow, thanks, this is good information to have! I usually feed Decay-filtered impulses to Ringz or Formlet, so they become a time-dependent signal again (decaying in N seconds), not a "narrower" (single-frame) impulse.  And I was indeed seeing a +6dB difference with double the SR...

We should document somewhere which UGens are SRI (at least the ones we're aware of), and explain the way to compensate for it if necessary (e.g. multiply amplitude by (old / new) sample rate if you aren't feeding them single-frame impulses).

Thanks for looking into this, 
Glen.

On Jan 12, 2017 01:49, "Nathan Ho" <[hidden email]> wrote:
On 2017-01-11 12:05, Nathan Ho wrote:
In both cases (although the ratios aren't identical) there's a roughly
6dB difference between 48 and 96 and an 0.7dB difference between 44.1
and 48.

Obviously, this is proportional to the sample rates themselves. I believe I've figured out why. There are two competing definitions of sample-rate independence (hereafter SRI).

1. F is an SRI digital filter if, for every analog signal X, the chain "X => ideal ADC => F at SR => ideal DAC" produces the same analog signal for every sample rate SR that exceeds the Nyquist rate of X (that is, Fs > 2B if X is bandlimited at B).

2. F is an "impulse-SRI" digital filter if, for every sample rate SR, the chain "digital impulse of amplitude 1 => F at SR => ideal DAC" produces the same analog signal.

Here's the important part: a digital impulse of amplitude 1 corresponds to a different analog signal depending on the sample rate. Think of what happens when you interpolate it with a sinc function: it gets squeezed inwards as you increase the SR. So the two definitions are quite different.

Most digital filter implementations are SRI. Try evaluating the maximum value of LPF.ar(Impulse.ar(0)) at different sample rates.

Ringz and Formlet are impulse-SRI. Why? Because most people using them are going to be feeding digital impulses, and they expect Ringz.ar(Impulse.ar(0)) to have the same amplitude regardless of SR.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Nathan Ho
> On 2017-01-12 01:49, Nathan Ho wrote:
> 2. F is an "impulse-SRI" digital filter if, for every sample rate
> SR, the chain "digital impulse of amplitude 1 => F at SR => ideal
> DAC" produces the same analog signal.

Correction: the same analog signal, provided that the SR exceeds the
Nyquist rate of that signal. This means that the analog signal must be
bandlimited, which is not the case for either Ringz or Formlet. So in
theory, they aren't actually impulse-SRI.


On 2017-01-12 00:08, Glen F wrote:
> We should document somewhere which UGens are SRI (at least the ones
> we're aware of), and explain the way to compensate for it if necessary
> (e.g. multiply amplitude by (old / new) sample rate if you aren't
> feeding them single-frame impulses).

If backward compatibility wasn't a concern, I'd propose altering them to
be true SRI. If you feed Impulse.ar into an SRI UGen, it's your fault --
as we've shown, it's really the Impulse that's SR-dependent.


Nathan

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Julian Rohrhuber-3

> On 12.01.2017, at 10:58, Nathan Ho <[hidden email]> wrote:
>
> On 2017-01-12 00:08, Glen F wrote:
>> We should document somewhere which UGens are SRI (at least the ones
>> we're aware of), and explain the way to compensate for it if necessary
>> (e.g. multiply amplitude by (old / new) sample rate if you aren't
>> feeding them single-frame impulses).
>
> If backward compatibility wasn't a concern, I'd propose altering them to be true SRI. If you feed Impulse.ar into an SRI UGen, it's your fault -- as we've shown, it's really the Impulse that's SR-dependent.

So how would you proceed if you want a sample rate independent sound from a SRI UGen? It is a very common technique to combine  e.g. Impulse and Ringz.

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Nathan Ho
On 2017-01-12 11:18, Julian Rohrhuber wrote:
> So how would you proceed if you want a sample rate independent sound
> from a SRI UGen? It is a very common technique to combine  e.g.
> Impulse and Ringz.

In some hypothetical rewrite of SC there could be an SRIImpulse UGen
that is scaled according to sample rate. But then that UGen wouldn't
truly be SRI -- they still represent different analog signals even if
their integrals over the real line are the same.

So now that I think about it, the supposed advantage of mathematical
purity of SRI isn't so clear-cut. I guess SRI vs. impulse-SRI doesn't
necessarily have an obvious answer in the design of audio programming
environments.


Nathan

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

ddw_music
In reply to this post by Glen Fraser
Glen Fraser wrote
We should document somewhere which UGens are SRI (at least the ones we're
aware of), and explain the way to compensate for it if necessary (e.g.
multiply amplitude by (old / new) sample rate if you aren't feeding them
single-frame impulses).
A start:

https://github.com/supercollider/supercollider/pull/2634

hjh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ringz, Formlet, sample rate

Glen Fraser
Looks good, thanks!

On Jan 13, 2017 10:36, "ddw_music" <[hidden email]> wrote:
Glen Fraser wrote
> We should document somewhere which UGens are SRI (at least the ones we're
> aware of), and explain the way to compensate for it if necessary (e.g.
> multiply amplitude by (old / new) sample rate if you aren't feeding them
> single-frame impulses).

A start:

https://github.com/supercollider/supercollider/pull/2634

hjh



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Ringz-Formlet-sample-rate-tp7630065p7630098.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

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