Hi,

Maybe Oeyvind can help me with this one! I'm comparing syncgrain and
partikkel.  I'm wondering why the attached example doesn't work with
partikkel (instr 3). Given the sr and ksmps constants, the size of the
table and the frequency and duration of the grains used, why aren't
partikkel's grain fitting in perfectly instead of causing an overlap? It
seems to be working fine with syncgrain (instr 2).

Thanks in advance. Cheers.



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

Hi Oeyvind,

Thanks for the quick reply. I wasn't trying to achieve anything in
particular. I started reading Chapter 15 on the 2016 Csound book and I
thought I could set up an example with both opcodes in order to compare
how their respective clocks worked. I knew I was going to mess the
comparison if I tried to match each one of the 44100 samples and that's
why I lowered the sr to something my head could handle (more than 4
seemed like a stretch, lol). But all things being equal, wouldn't I see
the same inconsistency in both opcodes' clocks also at 44100?

I think I'm still not getting what's going on because raising the max #
of overlaps to 2 doesn't produce the values I think it should. I thought
4 grains of 250ms would fit in a 1 second note, but previous grains seem
to be getting their duration extended a little bit more than they should.

 i   3 time     2.00000:     0.00000
 i   3 time     2.25000:     0.50000
 i   3 time     2.50000:     1.00000
 i   3 time     2.75000:     1.50000

I didn't know about the ability to have subsample grain clock precision!
It might be that then, because I think opcodes that do interpolation and
those that don't should work the same in this context (?).

Anyway, so you're confirming this is expected behavior then. Right?

Thanks again for your time. Cheers.


On 8/6/19 19:58, Oeyvind Brandtsegg wrote:
> Hi Guillermo,
>
> I was a bit unaccustomed to looking at it at such low sample rates, but, I
> think partikkel's interpolation between sample locations plays tricks with
> your results here.
> Also, due to the ability to start a grain between audio samples (subsample
> grain clock precision), it seems we need to set maxgrains to at least 2.
> Actually, I have never run it at such a low sample rate, so there might be
> unknown artifacts that appear in this specific context.
> It was a nice challenge to compare these different generators at this rate.
> What is it you want to do, or investigate specifically?
>
> Oeyvind
>
> lør. 8. jun. 2019 kl. 23:51 skrev Guillermo Senna :
>
>> Hi,
>>
>> Maybe Oeyvind can help me with this one! I'm comparing syncgrain and
>> partikkel.  I'm wondering why the attached example doesn't work with
>> partikkel (instr 3). Given the sr and ksmps constants, the size of the
>> table and the frequency and duration of the grains used, why aren't
>> partikkel's grain fitting in perfectly instead of causing an overlap? It
>> seems to be working fine with syncgrain (instr 2).
>>
>> Thanks in advance. Cheers.
>>
>>
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>

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

On 8/6/19 21:12, Oeyvind Brandtsegg wrote:
> Hm,
> I think maybe the confusion might stem from two different things being
> tested.
> Instrument 1 reads the values of the table once through,
> but instr 2 and 3 starts new grains at each table index.
Yes, instrument 1 was there just to have a reference of what each value
in the table was. But the way I see it is: we know instr 1 is not
reading the 4 samples at once because of ksmps=1; then I think setting
the four grains to 250ms in instr 2 makes syncgrain act the same as
indexing with the tab opcode. So instr 1 and 2 are really doing the same
here and instr 3 is the one that isn't purely diving by the table size
and indexing according to the specified grain duration.
>
> Example pasted below, where I think I ask them to do the same thing, and
> they print the same.
>
> I do understand the need to try to slow down, or downsample the process
> until we can look at the separate numbers.
> Still, partikkel was not designed to work as an uninterpolated table reader
> with a single table index providing the source material for a full grain.
> Maybe your results indicates that I should investigate again how it
> performs close to the Nyquist frequency, which is effectively what you do
> here.

Yes, sorry. I know I'm pushing it into conditions no one is probably
going to use, or who is going to care about the content of individual
grains/samples really? But I think it is still interesting that, while
using the same table, 4 grains of 250ms don't output the same four
values as 1 grain of 1000ms.

> Another way of comparing the different generators (at higher rates too) is
> to write audio to the left and right channel of a stereo file, and look at
> them in and audio editor. Then you can also zoom in and see any minuscule
> differences. You can also subtract one from the other, and if the result is
> zero they are equal in all samples, otherwise you will see a residue.
Those are good ones. I'll try to see if I can think of other experiments
while I keep reading the chapter!
>
> best
> Oeyvind
>
> **
> 
> 
>
> sr    = 4
> ksmps = 1
> 0dbfs = 1
>
>
> giRamp ftgen 0,0,       4,-2, 0, .25,  0.5, 0.75
>
> instr 1
>  asamplepos1 linseg 0, p3, 1
>  a1 tab asamplepos1, giRamp, 1
>  printk 0,vaget(0, a1)
> endin
>
>
>
>
> giConstant ftgen 0,0, 2, 2,     1,   1
>
> instr 2
>  igrsize = 1
>  ifreq   = 1
>  a1 syncgrain 1, ifreq, 1, igrsize, 1, giRamp, giConstant, 1
>  printk 0,vaget(0,a1)
> endin
>
>
>
> giCosine   ftgen  0,0, 8193, 9,    1,    1,  90
> giConstant ftgen  0,0,    2, 2,    1,    1
> giAmp      ftgen  0,0,    8, 2,    0,    0,   1,  0,  0,  0,  0
>
> instr 3
>  async = 0.0 ; (disable external sync)
>  awavfm = 0 ; (FM disabled)
>
>  asamplepos1 linseg 0, p3, 1
>  kGrainRate = 1
>  kgdur = 1000
>
>  kwavfreq = 1
>  kwavekey1 = 1
>
>  a1 partikkel kGrainRate,0,-1,async,0,-1,
>  giConstant,-1,0,1,kgdur,
>  ampdbfs(0),-1,kwavfreq,0.5,-1,-1,awavfm,
>  -1,-1,giCosine,1,1,1,-1,0,
>  giRamp,giRamp,giRamp,giRamp,giAmp,
>  asamplepos1,asamplepos1,asamplepos1,asamplepos1,
>  kwavekey1,kwavekey1,kwavekey1,kwavekey1,2
>
>  printk 0, vaget(0, a1)
>
> endin
>
> 
>
> 
> i 1 0 1
> i 2 1 1
> i 3 2 1
> 
>
> 
>
>
> søn. 9. jun. 2019 kl. 01:30 skrev Guillermo Senna :
>
>> Hi Oeyvind,
>>
>> Thanks for the quick reply. I wasn't trying to achieve anything in
>> particular. I started reading Chapter 15 on the 2016 Csound book and I
>> thought I could set up an example with both opcodes in order to compare
>> how their respective clocks worked. I knew I was going to mess the
>> comparison if I tried to match each one of the 44100 samples and that's
>> why I lowered the sr to something my head could handle (more than 4
>> seemed like a stretch, lol). But all things being equal, wouldn't I see
>> the same inconsistency in both opcodes' clocks also at 44100?
>>
>> I think I'm still not getting what's going on because raising the max #
>> of overlaps to 2 doesn't produce the values I think it should. I thought
>> 4 grains of 250ms would fit in a 1 second note, but previous grains seem
>> to be getting their duration extended a little bit more than they should.
>>
>>  i   3 time     2.00000:     0.00000
>>  i   3 time     2.25000:     0.50000
>>  i   3 time     2.50000:     1.00000
>>  i   3 time     2.75000:     1.50000
>>
>> I didn't know about the ability to have subsample grain clock precision!
>> It might be that then, because I think opcodes that do interpolation and
>> those that don't should work the same in this context (?).
>>
>> Anyway, so you're confirming this is expected behavior then. Right?
>>
>> Thanks again for your time. Cheers.
>>
>>
>> On 8/6/19 19:58, Oeyvind Brandtsegg wrote:
>>> Hi Guillermo,
>>>
>>> I was a bit unaccustomed to looking at it at such low sample rates, but,
>> I
>>> think partikkel's interpolation between sample locations plays tricks
>> with
>>> your results here.
>>> Also, due to the ability to start a grain between audio samples
>> (subsample
>>> grain clock precision), it seems we need to set maxgrains to at least 2.
>>> Actually, I have never run it at such a low sample rate, so there might
>> be
>>> unknown artifacts that appear in this specific context.
>>> It was a nice challenge to compare these different generators at this
>> rate.
>>> What is it you want to do, or investigate specifically?
>>>
>>> Oeyvind
>>>
>>> lør. 8. jun. 2019 kl. 23:51 skrev Guillermo Senna :
>>>
>>>> Hi,
>>>>
>>>> Maybe Oeyvind can help me with this one! I'm comparing syncgrain and
>>>> partikkel.  I'm wondering why the attached example doesn't work with
>>>> partikkel (instr 3). Given the sr and ksmps constants, the size of the
>>>> table and the frequency and duration of the grains used, why aren't
>>>> partikkel's grain fitting in perfectly instead of causing an overlap? It
>>>> seems to be working fine with syncgrain (instr 2).
>>>>
>>>> Thanks in advance. Cheers.
>>>>
>>>>
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>

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

Hi,

Yes, thank you. This definitely clarifies things for me.

I just tried with sr/2 and that still causes an overlap. So, just for
the archives of this mailing list, the safe range seems to be using "up
to, but not including" the Nyquist frequency for the triggering rate of
the grains. Otherwise an overlap occurs and the content of the (n-1)
grain gets added to the (n) grain.

Cheers.

P.S. I apologize if I made you spend time over this on a Sunday!


On 9/6/19 18:23, Oeyvind Brandtsegg wrote:
> Hi,
> Could not leave this unresolved, so I looked a bit more.
> So, partikkel actually makes the grain 1 sample longer, to allow for the
> interpolation required for subsample grain placement.
> Then when you ask for a 1-sample long grain, we get artifacts due to
> overlapping grains where you did not expect them to happen.
> I recall (admittedly vaguely) that we discussed this, me and Thom Johansen,
> when we implemented it, we thought it natural that artifacts could be
> allowed to occur when asking for a grain rate above the Nyquist frequency.
> We thought this made sense, since it is an audio generator, and the Nyquist
> frequency applies to granular just as it does to other generators. IIRC we
> also discussed implementing a failsafe, but it would make the opcode
> slightly less efficient.
> Since you ask for a grain rate = sr and grain duration = 1/sr, this puts us
> in the area where problems can occur.
> Hope this did clarify things.
> All best
> Oeyvind
>
> søn. 9. jun. 2019 kl. 02:55 skrev Guillermo Senna :
>
>> On 8/6/19 21:12, Oeyvind Brandtsegg wrote:
>>> Hm,
>>> I think maybe the confusion might stem from two different things being
>>> tested.
>>> Instrument 1 reads the values of the table once through,
>>> but instr 2 and 3 starts new grains at each table index.
>> Yes, instrument 1 was there just to have a reference of what each value
>> in the table was. But the way I see it is: we know instr 1 is not
>> reading the 4 samples at once because of ksmps=1; then I think setting
>> the four grains to 250ms in instr 2 makes syncgrain act the same as
>> indexing with the tab opcode. So instr 1 and 2 are really doing the same
>> here and instr 3 is the one that isn't purely diving by the table size
>> and indexing according to the specified grain duration.
>>> Example pasted below, where I think I ask them to do the same thing, and
>>> they print the same.
>>>
>>> I do understand the need to try to slow down, or downsample the process
>>> until we can look at the separate numbers.
>>> Still, partikkel was not designed to work as an uninterpolated table
>> reader
>>> with a single table index providing the source material for a full grain.
>>> Maybe your results indicates that I should investigate again how it
>>> performs close to the Nyquist frequency, which is effectively what you do
>>> here.
>> Yes, sorry. I know I'm pushing it into conditions no one is probably
>> going to use, or who is going to care about the content of individual
>> grains/samples really? But I think it is still interesting that, while
>> using the same table, 4 grains of 250ms don't output the same four
>> values as 1 grain of 1000ms.
>>
>>> Another way of comparing the different generators (at higher rates too)
>> is
>>> to write audio to the left and right channel of a stereo file, and look
>> at
>>> them in and audio editor. Then you can also zoom in and see any minuscule
>>> differences. You can also subtract one from the other, and if the result
>> is
>>> zero they are equal in all samples, otherwise you will see a residue.
>> Those are good ones. I'll try to see if I can think of other experiments
>> while I keep reading the chapter!
>>> best
>>> Oeyvind
>>>
>>> **
>>> 
>>> 
>>>
>>> sr    = 4
>>> ksmps = 1
>>> 0dbfs = 1
>>>
>>>
>>> giRamp ftgen 0,0,       4,-2, 0, .25,  0.5, 0.75
>>>
>>> instr 1
>>>  asamplepos1 linseg 0, p3, 1
>>>  a1 tab asamplepos1, giRamp, 1
>>>  printk 0,vaget(0, a1)
>>> endin
>>>
>>>
>>>
>>>
>>> giConstant ftgen 0,0, 2, 2,     1,   1
>>>
>>> instr 2
>>>  igrsize = 1
>>>  ifreq   = 1
>>>  a1 syncgrain 1, ifreq, 1, igrsize, 1, giRamp, giConstant, 1
>>>  printk 0,vaget(0,a1)
>>> endin
>>>
>>>
>>>
>>> giCosine   ftgen  0,0, 8193, 9,    1,    1,  90
>>> giConstant ftgen  0,0,    2, 2,    1,    1
>>> giAmp      ftgen  0,0,    8, 2,    0,    0,   1,  0,  0,  0,  0
>>>
>>> instr 3
>>>  async = 0.0 ; (disable external sync)
>>>  awavfm = 0 ; (FM disabled)
>>>
>>>  asamplepos1 linseg 0, p3, 1
>>>  kGrainRate = 1
>>>  kgdur = 1000
>>>
>>>  kwavfreq = 1
>>>  kwavekey1 = 1
>>>
>>>  a1 partikkel kGrainRate,0,-1,async,0,-1,
>>>  giConstant,-1,0,1,kgdur,
>>>  ampdbfs(0),-1,kwavfreq,0.5,-1,-1,awavfm,
>>>  -1,-1,giCosine,1,1,1,-1,0,
>>>  giRamp,giRamp,giRamp,giRamp,giAmp,
>>>  asamplepos1,asamplepos1,asamplepos1,asamplepos1,
>>>  kwavekey1,kwavekey1,kwavekey1,kwavekey1,2
>>>
>>>  printk 0, vaget(0, a1)
>>>
>>> endin
>>>
>>> 
>>>
>>> 
>>> i 1 0 1
>>> i 2 1 1
>>> i 3 2 1
>>> 
>>>
>>> 
>>>
>>>
>>> søn. 9. jun. 2019 kl. 01:30 skrev Guillermo Senna :
>>>
>>>> Hi Oeyvind,
>>>>
>>>> Thanks for the quick reply. I wasn't trying to achieve anything in
>>>> particular. I started reading Chapter 15 on the 2016 Csound book and I
>>>> thought I could set up an example with both opcodes in order to compare
>>>> how their respective clocks worked. I knew I was going to mess the
>>>> comparison if I tried to match each one of the 44100 samples and that's
>>>> why I lowered the sr to something my head could handle (more than 4
>>>> seemed like a stretch, lol). But all things being equal, wouldn't I see
>>>> the same inconsistency in both opcodes' clocks also at 44100?
>>>>
>>>> I think I'm still not getting what's going on because raising the max #
>>>> of overlaps to 2 doesn't produce the values I think it should. I thought
>>>> 4 grains of 250ms would fit in a 1 second note, but previous grains seem
>>>> to be getting their duration extended a little bit more than they
>> should.
>>>>  i   3 time     2.00000:     0.00000
>>>>  i   3 time     2.25000:     0.50000
>>>>  i   3 time     2.50000:     1.00000
>>>>  i   3 time     2.75000:     1.50000
>>>>
>>>> I didn't know about the ability to have subsample grain clock precision!
>>>> It might be that then, because I think opcodes that do interpolation and
>>>> those that don't should work the same in this context (?).
>>>>
>>>> Anyway, so you're confirming this is expected behavior then. Right?
>>>>
>>>> Thanks again for your time. Cheers.
>>>>
>>>>
>>>> On 8/6/19 19:58, Oeyvind Brandtsegg wrote:
>>>>> Hi Guillermo,
>>>>>
>>>>> I was a bit unaccustomed to looking at it at such low sample rates,
>> but,
>>>> I
>>>>> think partikkel's interpolation between sample locations plays tricks
>>>> with
>>>>> your results here.
>>>>> Also, due to the ability to start a grain between audio samples
>>>> (subsample
>>>>> grain clock precision), it seems we need to set maxgrains to at least
>> 2.
>>>>> Actually, I have never run it at such a low sample rate, so there might
>>>> be
>>>>> unknown artifacts that appear in this specific context.
>>>>> It was a nice challenge to compare these different generators at this
>>>> rate.
>>>>> What is it you want to do, or investigate specifically?
>>>>>
>>>>> Oeyvind
>>>>>
>>>>> lør. 8. jun. 2019 kl. 23:51 skrev Guillermo Senna :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Maybe Oeyvind can help me with this one! I'm comparing syncgrain and
>>>>>> partikkel.  I'm wondering why the attached example doesn't work with
>>>>>> partikkel (instr 3). Given the sr and ksmps constants, the size of the
>>>>>> table and the frequency and duration of the grains used, why aren't
>>>>>> partikkel's grain fitting in perfectly instead of causing an overlap?
>> It
>>>>>> seems to be working fine with syncgrain (instr 2).
>>>>>>
>>>>>> Thanks in advance. Cheers.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>         https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>

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