Yes.  Please support different sample rates in all sampling opcodes.

Sent from my iPhone

> On May 11, 2018, at 8:04 PM, luis jure  wrote:
> 
> 
> i guess this is not related the the problem reported recently, but it
> seems to me that there is a bug or at least an inconvenient (and
> undocumented) "feature" in flooper2: it only works properly with sound
> files having the same sample rate as the csound orchestra.
> 
> please see the attached csd, it's designed to loop the word "dog" in the
> fox.wav file from the manual. but it only works with sr=44100, if you
> set sr to 48000 it produces strange results, and with sr=96000 it
> segfaults (i just pulled the git repository).
> 
> it would seem to me that perhaps the problem is that the opcode takes
> arguments in seconds and does the conversion using the orchestra sr
> instead of the sample rate of the sound file in the table.
> 
> BTW, you can also find a problem in mincer, as you can see changing the sr
> in the attached csd. (i haven't tried them all, but i think other opcodes
> in pvlock.c and sndloop.c might misbehave when the sampling rates are
> different).
> 
> i don't know if this is the intended behaviour, but i think it should be
> possible to use sound files with different sampling rates with these
> opcodes. or else there should be a warning in the manual page.
> 
> best,
> 
> lj
> 
> 
> 
> --
> 
> 
> 
> 
> 
> 
> 
> 

Also, while we are at it... did you notice and hopefully fix the bug in  the loscil opcode that (lately) requires one to put in a base frequency,  whereas in the past it did not require this.  As it used to put in a default of middle c.  Sadly this new requirement of an optional parameter broke all the tutorials from chapter 1 of The Csound Book



Sent from my iPhone

> On May 11, 2018, at 8:23 PM, Dr. Richard Boulanger  wrote:
> 
> Yes.  Please support different sample rates in all sampling opcodes.
> 
> Sent from my iPhone
> 
>> On May 11, 2018, at 8:04 PM, luis jure  wrote:
>> 
>> 
>> i guess this is not related the the problem reported recently, but it
>> seems to me that there is a bug or at least an inconvenient (and
>> undocumented) "feature" in flooper2: it only works properly with sound
>> files having the same sample rate as the csound orchestra.
>> 
>> please see the attached csd, it's designed to loop the word "dog" in the
>> fox.wav file from the manual. but it only works with sr=44100, if you
>> set sr to 48000 it produces strange results, and with sr=96000 it
>> segfaults (i just pulled the git repository).
>> 
>> it would seem to me that perhaps the problem is that the opcode takes
>> arguments in seconds and does the conversion using the orchestra sr
>> instead of the sample rate of the sound file in the table.
>> 
>> BTW, you can also find a problem in mincer, as you can see changing the sr
>> in the attached csd. (i haven't tried them all, but i think other opcodes
>> in pvlock.c and sndloop.c might misbehave when the sampling rates are
>> different).
>> 
>> i don't know if this is the intended behaviour, but i think it should be
>> possible to use sound files with different sampling rates with these
>> opcodes. or else there should be a warning in the manual page.
>> 
>> best,
>> 
>> lj
>> 
>> 
>> 
>> --
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 

yes, there is no resampling built into it. It reads whatever data that is loaded in the table at the SR that is set by the orchestra.

It shouldn’t segfault though.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 12 May 2018, at 01:04, luis jure  wrote:
> 
> 
> i guess this is not related the the problem reported recently, but it
> seems to me that there is a bug or at least an inconvenient (and
> undocumented) "feature" in flooper2: it only works properly with sound
> files having the same sample rate as the csound orchestra.
> 
> please see the attached csd, it's designed to loop the word "dog" in the
> fox.wav file from the manual. but it only works with sr=44100, if you
> set sr to 48000 it produces strange results, and with sr=96000 it
> segfaults (i just pulled the git repository).
> 
> it would seem to me that perhaps the problem is that the opcode takes
> arguments in seconds and does the conversion using the orchestra sr
> instead of the sample rate of the sound file in the table.
> 
> BTW, you can also find a problem in mincer, as you can see changing the sr
> in the attached csd. (i haven't tried them all, but i think other opcodes
> in pvlock.c and sndloop.c might misbehave when the sampling rates are
> different).
> 
> i don't know if this is the intended behaviour, but i think it should be
> possible to use sound files with different sampling rates with these
> opcodes. or else there should be a warning in the manual page.
> 
> best,
> 
> lj
> 
> 
> 
> --
> 
> 
> 
> 
> 
> 
> 
> 

but it is a simple fix, just have to take in account the table sr, in GIT now.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 12 May 2018, at 01:04, luis jure  wrote:
> 
> 
> i guess this is not related the the problem reported recently, but it
> seems to me that there is a bug or at least an inconvenient (and
> undocumented) "feature" in flooper2: it only works properly with sound
> files having the same sample rate as the csound orchestra.
> 
> please see the attached csd, it's designed to loop the word "dog" in the
> fox.wav file from the manual. but it only works with sr=44100, if you
> set sr to 48000 it produces strange results, and with sr=96000 it
> segfaults (i just pulled the git repository).
> 
> it would seem to me that perhaps the problem is that the opcode takes
> arguments in seconds and does the conversion using the orchestra sr
> instead of the sample rate of the sound file in the table.
> 
> BTW, you can also find a problem in mincer, as you can see changing the sr
> in the attached csd. (i haven't tried them all, but i think other opcodes
> in pvlock.c and sndloop.c might misbehave when the sampling rates are
> different).
> 
> i don't know if this is the intended behaviour, but i think it should be
> possible to use sound files with different sampling rates with these
> opcodes. or else there should be a warning in the manual page.
> 
> best,
> 
> lj
> 
> 
> 
> --
> 
> 
> 
> 
> 
> 
> 

also applied to flooper, syncgrain, syncloop, diskgrain, mincer, temposcal, pvstanal.
The filescal opcode already had that builtin.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 12 May 2018, at 09:33, Victor Lazzarini  wrote:
> 
> but it is a simple fix, just have to take in account the table sr, in GIT now.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 12 May 2018, at 01:04, luis jure  wrote:
>> 
>> 
>> i guess this is not related the the problem reported recently, but it
>> seems to me that there is a bug or at least an inconvenient (and
>> undocumented) "feature" in flooper2: it only works properly with sound
>> files having the same sample rate as the csound orchestra.
>> 
>> please see the attached csd, it's designed to loop the word "dog" in the
>> fox.wav file from the manual. but it only works with sr=44100, if you
>> set sr to 48000 it produces strange results, and with sr=96000 it
>> segfaults (i just pulled the git repository).
>> 
>> it would seem to me that perhaps the problem is that the opcode takes
>> arguments in seconds and does the conversion using the orchestra sr
>> instead of the sample rate of the sound file in the table.
>> 
>> BTW, you can also find a problem in mincer, as you can see changing the sr
>> in the attached csd. (i haven't tried them all, but i think other opcodes
>> in pvlock.c and sndloop.c might misbehave when the sampling rates are
>> different).
>> 
>> i don't know if this is the intended behaviour, but i think it should be
>> possible to use sound files with different sampling rates with these
>> opcodes. or else there should be a warning in the manual page.
>> 
>> best,
>> 
>> lj
>> 
>> 
>> 
>> --
>> 
>> 
>> 
>> 
>> 
>> 
>> 

More detail please.  i cannot see anytin wrong in the code and it seems 
unchanged.  ?Can you provide a csd file and possibly the input file or the 
gen?

==John


On Fri, 11 May 2018, Dr. Richard Boulanger wrote:

> Also, while we are at it... did you notice and hopefully fix the bug in  the loscil opcode that (lately) requires one to put in a base frequency,  whereas in the past it did not require this.  As it used to put in a default of middle c.  Sadly this new requirement of an optional parameter broke all the tutorials from chapter 1 of The Csound Book
>
>
>
> Sent from my iPhone
>
>> On May 11, 2018, at 8:23 PM, Dr. Richard Boulanger  wrote:
>>
>> Yes.  Please support different sample rates in all sampling opcodes.
>>
>> Sent from my iPhone
>>
>>> On May 11, 2018, at 8:04 PM, luis jure  wrote:
>>>
>>>
>>> i guess this is not related the the problem reported recently, but it
>>> seems to me that there is a bug or at least an inconvenient (and
>>> undocumented) "feature" in flooper2: it only works properly with sound
>>> files having the same sample rate as the csound orchestra.
>>>
>>> please see the attached csd, it's designed to loop the word "dog" in the
>>> fox.wav file from the manual. but it only works with sr=44100, if you
>>> set sr to 48000 it produces strange results, and with sr=96000 it
>>> segfaults (i just pulled the git repository).
>>>
>>> it would seem to me that perhaps the problem is that the opcode takes
>>> arguments in seconds and does the conversion using the orchestra sr
>>> instead of the sample rate of the sound file in the table.
>>>
>>> BTW, you can also find a problem in mincer, as you can see changing the sr
>>> in the attached csd. (i haven't tried them all, but i think other opcodes
>>> in pvlock.c and sndloop.c might misbehave when the sampling rates are
>>> different).
>>>
>>> i don't know if this is the intended behaviour, but i think it should be
>>> possible to use sound files with different sampling rates with these
>>> opcodes. or else there should be a warning in the manual page.
>>>
>>> best,
>>>
>>> lj
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>> 

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 12 May 2018, at 16:21, luis jure  wrote:
> 
> 
>> el 2018-05-12 a las 09:11 Victor Lazzarini escribió:
>> 
>> also applied to flooper, syncgrain, syncloop, diskgrain, mincer,
>> temposcal, pvstanal. The filescal opcode already had that builtin.
> 
> hi, victor, thanks for taking a look at this and for your prompt response. 
> 
> mincer seems to be working OK now.
> 
> however, the problem i reported with flooper2 persists, as you can see
> compiling the attached csd and then changing the sr. i guess the problem
> is that the time pointer is still calculated from the orchestra sr, not
> the ta

It says flooper3?
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 12 May 2018, at 16:20, luis jure  wrote:
> 
> 
> el 2018-05-12 a las 09:11 Victor Lazzarini escribió:
> 
>> also applied to flooper, syncgrain, syncloop, diskgrain, mincer,
>> temposcal, pvstanal. The filescal opcode already had that builtin.
> 
> hi, victor, thanks for taking a look at this and for your prompt response. 
> 
> mincer seems to be working OK now.
> 
> however, the problem i reported with flooper2 persists, as you can see
> compiling the attached csd and then changing the sr. i guess the problem
> is that the time pointer is still calculated from the orchestra sr, not
> the table sample rate.
> 
> 
> 
> 
> 

Indeed. Fixed in GIT
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 12 May 2018, at 16:20, luis jure  wrote:
> 
> 
> el 2018-05-12 a las 09:11 Victor Lazzarini escribió:
> 
>> also applied to flooper, syncgrain, syncloop, diskgrain, mincer,
>> temposcal, pvstanal. The filescal opcode already had that builtin.
> 
> hi, victor, thanks for taking a look at this and for your prompt response. 
> 
> mincer seems to be working OK now.
> 
> however, the problem i reported with flooper2 persists, as you can see
> compiling the attached csd and then changing the sr. i guess the problem
> is that the time pointer is still calculated from the orchestra sr, not
> the table sample rate.
> 
> 
> 
> 
> 

el 2018-05-12 a las 15:40 Victor Lazzarini escribió:

> Indeed. Fixed in GIT

yes! works OK now.

thanks, victor!