[Csnd] Interesting results rendering wgpluck2 at sr 96000 vs 44100

The Csound Mailinglist
1

First off, apologies if this is well known (I'm a newbie... ) but I stumbled on to this and thought others might find it interesting or useful.

For irrelevant reasons I tried using the wgpluck2 opcode at a sr of 96000. With many of my other csd files that use traditional synthesis as opposed to physical modelling opcodes I found a higher sampling rate to have little to no effect, but with wgpluck, and possibly with the other pluck opcodes, haven't tested them yet, the difference was significant. Perhaps a predictable result from the Karpus-Strong algorithm (my math abilities are pretty limited)?

Where at 44100, & 48000 there is a significant rolloff after 1kHz, at 96000 it's far less dramatic. The timbre contains many high freq overtones. When rendered at 96000 and downsampled in an editor afterwards the result is still quite noticeable.

While I wouldn't define the result as better or worse, it's obviously subjective and contextual, it does seem to offer a different dimension for expression when using the opcode(s).

I haven't personally noticed any undesirable artifacts as a result of rendering at 96000 but I'd be curious to know if others find/hear issues.

Some (crappy looking) screenshots from a spectrum analyzer:

44100 -
https://drive.google.com/file/d/1nVfxIga7l10AOh1g75qEAfSf8etkGaxR/view?usp=drivesdk

96000 -
https://drive.google.com/file/d/1nePV7BLnVcNyZPxKgG43xrzZTj-5s7mu/view?usp=drivesdk

There's an audio example here:
https://soundcloud.com/st-csound/table-arps

The first half rendered at 44100, the second at 96000 and then downsampled to 44100.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

2

It may have something to do with the way noise would behave if there was no lpf between the noise impulse and the comb filter/delay line, but this is just a wild guess.

3

That is because wgpluck uses a filter whose cutoff frequency is fixed at a 1/4 sampling rate (this is based on the Karplus-Strong model) and so it will change
with the sampling rate.

I am saying this without looking at the code, but I would expect it to be the case.

4

Yeah victor this makes perfect sense