i am having troubles with some of the ATS opcodes. I'm having trouble with
the offset setting and partial increment, which are both optional for some
ATS opcodes.

First i analyzed "fox.wav" with default settings. When checking out the
result with ATSinfo i got the same results as in the chapter on ATS of the
book "Csound - A Sound and Music Computing System" on page 329. For example,
the result was: Number of Partials = 209

Then i wanted to set some offset with ATSadd and ATSsinnoi, so some lower
sine frequencies would get  filtered out. 
Result was:
INIT ERROR in instr 1 line 77: ATSSINNOI: Partial(s) out of range, max
partial allowed is 209

To my surprise i found that the offset needed to be subtracted from the
total of partials before applying the offset.
So, when offset = 10 and total number of partials = 209, the number of
partials of ATSadd and ATSsinnoi should be set to 199 and offset = 10.
  
I now heard that the lower sines were gone and all seems to work as
intended.
I expected that this subtraction was done in the code of ATSadd etc. itself?

I still have not found out how to get the incremental option of ATSadd or
ATSsinnoi to work. Only the default setting of 1 seems to work.
What is the secret formula for the incremental setting to work?





--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

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

Hello Menno, yes, your guess is OK.
ATSadd computes the number of the higher partial to be synthesized as:
offset + npartials*incr
If the result is greater than the number of partials held in the ATS
file, an error will be issued.
Those three variables are mutually dependent as they are in the pvoc
and adsynt Opcodes.
So, if, you have 24 partials in an ATS File, you may have
npartials=24 offset=0 and incr=1
Or, as an example:
npartials=24 offset=12 and incr=1  will be rejected
so, you should set, instead:
npartials=12 offset=12 and incr=1  and will be fine
I've tried changing incr as well and works fine for me, but the same
constraints are to be taken in account
As an example:
npartials=24 offset=0 and incr=2  will be rejected
so, you should set, instead:
npartials=12 offset=0 and incr=2  and will be fine

However, I discovered now a Bug in ATSadd that I did not noticed before.
When more than one note is performed using ATSadd and either offset or
incr are set to something different than 0 or 1
respectively, there is a distorsion in the onset of the result.
The strange thing is that the bug only occurs when more than one note
is performed. Performing individual notes will
not produce it, indicating that the unit is working fine.
It looks like something "unclean" in memory allocation. I will take a
closer look to the code to see if I can figure out what is
wrong. And, eventually, I will consult to the developer list.
Hope this helps.
Pablo

El jue., 14 mar. 2019 a las 15:57, Menno Knevel
() escribió:
>
> i am having troubles with some of the ATS opcodes. I'm having trouble with
> the offset setting and partial increment, which are both optional for some
> ATS opcodes.
>
> First i analyzed "fox.wav" with default settings. When checking out the
> result with ATSinfo i got the same results as in the chapter on ATS of the
> book "Csound - A Sound and Music Computing System" on page 329. For example,
> the result was: Number of Partials = 209
>
> Then i wanted to set some offset with ATSadd and ATSsinnoi, so some lower
> sine frequencies would get  filtered out.
> Result was:
> INIT ERROR in instr 1 line 77: ATSSINNOI: Partial(s) out of range, max
> partial allowed is 209
>
> To my surprise i found that the offset needed to be subtracted from the
> total of partials before applying the offset.
> So, when offset = 10 and total number of partials = 209, the number of
> partials of ATSadd and ATSsinnoi should be set to 199 and offset = 10.
>
> I now heard that the lower sines were gone and all seems to work as
> intended.
> I expected that this subtraction was done in the code of ATSadd etc. itself?
>
> I still have not found out how to get the incremental option of ATSadd or
> ATSsinnoi to work. Only the default setting of 1 seems to work.
> What is the secret formula for the incremental setting to work?
>
>
>
>
>
> --
> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>
> 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



-- 
Dr. Oscar Pablo Di Liscia
Profesor Titular
Director Programa de Investigación "Sistemas Temporales y Síntesis
Espacial en el Arte Sonoro"
http://stseas.web.unq.edu.ar/
Director Colección Editorial "Música y Ciencia"
Escuela Universitaria de Artes
Universidad Nacional de Quilmes
Argentina

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

I think i have discovered another bug as well:
ATSadd works well with incr > 1 but ATSsinnoi with inc > 1 crashes all the
time.
so
aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 1
but this crashes:
aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 2

Can you verify this?
I'm working with Linux Mint. Using the same fox ats with standard analyzing
options.

(I have not yet tried the other ATS opcodes that has the same "offset +
npartials*incr " system, like ATSadd, bufread, cross.)




--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

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

I think i have discovered another bug as well:
ATSadd works well with incr > 1 but ATSsinnoi with inc > 1 crashes all the
time.
so
aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 1
but this crashes:
aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 2

Can you verify this?
I'm working with Linux Mint. Using the same fox ats with standard analyzing
options.

(I have not yet tried the other ATS opcodes that has the same "offset +
npartials*incr " system, like ATSadd, bufread, cross.)




--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

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

Yes, you´re right.
Any value for increment > 1 will cause that the output of ATSsinnoi is 0.
It does not crash, but it outputs 0.
I did not find this bug before. I will see the code, thanks for your report.
Best
Pablo

El lun., 18 mar. 2019 a las 7:25, Menno Knevel () escribió:
>
> I think i have discovered another bug as well:
> ATSadd works well with incr > 1 but ATSsinnoi with inc > 1 crashes all the
> time.
> so
> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 1
> but this crashes:
> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 2
>
> Can you verify this?
> I'm working with Linux Mint. Using the same fox ats with standard analyzing
> options.
>
> (I have not yet tried the other ATS opcodes that has the same "offset +
> npartials*incr " system, like ATSadd, bufread, cross.)
>
>
>
>
> --
> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>
> 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



-- 
Dr. Oscar Pablo Di Liscia
Profesor Titular
Director Programa de Investigación "Sistemas Temporales y Síntesis
Espacial en el Arte Sonoro"
http://stseas.web.unq.edu.ar/
Director Colección Editorial "Música y Ciencia"
Escuela Universitaria de Artes
Universidad Nacional de Quilmes
Argentina

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

It looksas if it fails in the initialiation pass

Thread 1 "csound" received signal SIGSEGV, Segmentation fault.
0x00007ffff7ab8117 in band_energy_to_res (csound=0x61fe80, p=0x86f160)
     at /home/jpff/csound6/Opcodes/ugnorman.c:1534
1534                  (*(curframe + 1 + j * (int32_t) p->partialinc) * 
*(partialband[j])) /
(gdb) where
#0  0x00007ffff7ab8117 in band_energy_to_res (csound=0x61fe80, p=0x86f160)
     at /home/jpff/csound6/Opcodes/ugnorman.c:1534
#1  0x00007ffff7aba6fc in atssinnoiset_S (csound=0x61fe80, p=0x86f160)
     at /home/jpff/csound6/Opcodes/ugnorman.c:1844
#2  0x00007ffff78f4049 in init_pass (ip=0x86eba0, csound=0x61fe80)
     at /home/jpff/csound6/Engine/insert.c:116

In y example j is 177 way beyond the 150 partials I asked for (I think). I 
have o idea of the akgoritm being used  The code was contributed in 2004 
and I have never looked into it.



On Wed, 20 Mar 2019, Oscar Pablo Di Liscia wrote:

> Yes, you´re right.
> Any value for increment > 1 will cause that the output of ATSsinnoi is 0.
> It does not crash, but it outputs 0.
> I did not find this bug before. I will see the code, thanks for your report.
> Best
> Pablo
>
> El lun., 18 mar. 2019 a las 7:25, Menno Knevel () escribió:
>>
>> I think i have discovered another bug as well:
>> ATSadd works well with incr > 1 but ATSsinnoi with inc > 1 crashes all the
>> time.
>> so
>> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 1
>> but this crashes:
>> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 2
>>
>> Can you verify this?
>> I'm working with Linux Mint. Using the same fox ats with standard analyzing
>> options.
>>
>> (I have not yet tried the other ATS opcodes that has the same "offset +
>> npartials*incr " system, like ATSadd, bufread, cross.)
>>
>>
>>
>>
>> --
>> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>>
>> 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
>
>
>
> -- 
> Dr. Oscar Pablo Di Liscia
> Profesor Titular
> Director Programa de Investigación "Sistemas Temporales y Síntesis
> Espacial en el Arte Sonoro"
> http://stseas.web.unq.edu.ar/
> Director Colección Editorial "Música y Ciencia"
> Escuela Universitaria de Artes
> Universidad Nacional de Quilmes
> Argentina
>
> 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

Thanks John, this give me a clue on where to look at.
Me neither looked into the code in detail. It was coded
by Alex Norman.
I will see if I find out where the error is.
Best
Pablo

El mié., 20 mar. 2019 a las 18:55, john () escribió:
>
> It looksas if it fails in the initialiation pass
>
> Thread 1 "csound" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7ab8117 in band_energy_to_res (csound=0x61fe80, p=0x86f160)
>      at /home/jpff/csound6/Opcodes/ugnorman.c:1534
> 1534                  (*(curframe + 1 + j * (int32_t) p->partialinc) *
> *(partialband[j])) /
> (gdb) where
> #0  0x00007ffff7ab8117 in band_energy_to_res (csound=0x61fe80, p=0x86f160)
>      at /home/jpff/csound6/Opcodes/ugnorman.c:1534
> #1  0x00007ffff7aba6fc in atssinnoiset_S (csound=0x61fe80, p=0x86f160)
>      at /home/jpff/csound6/Opcodes/ugnorman.c:1844
> #2  0x00007ffff78f4049 in init_pass (ip=0x86eba0, csound=0x61fe80)
>      at /home/jpff/csound6/Engine/insert.c:116
>
> In y example j is 177 way beyond the 150 partials I asked for (I think). I
> have o idea of the akgoritm being used  The code was contributed in 2004
> and I have never looked into it.
>
>
>
> On Wed, 20 Mar 2019, Oscar Pablo Di Liscia wrote:
>
> > Yes, you´re right.
> > Any value for increment > 1 will cause that the output of ATSsinnoi is 0.
> > It does not crash, but it outputs 0.
> > I did not find this bug before. I will see the code, thanks for your report.
> > Best
> > Pablo
> >
> > El lun., 18 mar. 2019 a las 7:25, Menno Knevel () escribió:
> >>
> >> I think i have discovered another bug as well:
> >> ATSadd works well with incr > 1 but ATSsinnoi with inc > 1 crashes all the
> >> time.
> >> so
> >> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 1
> >> but this crashes:
> >> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 2
> >>
> >> Can you verify this?
> >> I'm working with Linux Mint. Using the same fox ats with standard analyzing
> >> options.
> >>
> >> (I have not yet tried the other ATS opcodes that has the same "offset +
> >> npartials*incr " system, like ATSadd, bufread, cross.)
> >>
> >>
> >>
> >>
> >> --
> >> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
> >>
> >> 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
> >
> >
> >
> > --
> > Dr. Oscar Pablo Di Liscia
> > Profesor Titular
> > Director Programa de Investigación "Sistemas Temporales y Síntesis
> > Espacial en el Arte Sonoro"
> > http://stseas.web.unq.edu.ar/
> > Director Colección Editorial "Música y Ciencia"
> > Escuela Universitaria de Artes
> > Universidad Nacional de Quilmes
> > Argentina
> >
> > 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



-- 
Dr. Oscar Pablo Di Liscia
Profesor Titular
Director Programa de Investigación "Sistemas Temporales y Síntesis
Espacial en el Arte Sonoro"
http://stseas.web.unq.edu.ar/
Director Colección Editorial "Música y Ciencia"
Escuela Universitaria de Artes
Universidad Nacional de Quilmes
Argentina

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

I've been looking at the ATSsinnoi code and now I know for sure where
the bugs are.
But to fix them will take me some time. I also contacted Alex Norman
to see if he will help
to debug.
In the mean time, I've coded an instrument that uses the ATSread, ATSreadnz and
Poly to get very similar results than the ones by ATSsinnoi opcode.
I've tested extensively ATSread and ATSreadnz and are very reliable to
my knowledge,
and have the advantage that they allow and individual treatment of the
partials and/or noise bands.
I share it in a different thread,  just in case someone other is interested.
Best
Pablo

El mié., 20 mar. 2019 a las 20:23, Oscar Pablo Di Liscia
() escribió:
>
> Thanks John, this give me a clue on where to look at.
> Me neither looked into the code in detail. It was coded
> by Alex Norman.
> I will see if I find out where the error is.
> Best
> Pablo
>
> El mié., 20 mar. 2019 a las 18:55, john () escribió:
> >
> > It looksas if it fails in the initialiation pass
> >
> > Thread 1 "csound" received signal SIGSEGV, Segmentation fault.
> > 0x00007ffff7ab8117 in band_energy_to_res (csound=0x61fe80, p=0x86f160)
> >      at /home/jpff/csound6/Opcodes/ugnorman.c:1534
> > 1534                  (*(curframe + 1 + j * (int32_t) p->partialinc) *
> > *(partialband[j])) /
> > (gdb) where
> > #0  0x00007ffff7ab8117 in band_energy_to_res (csound=0x61fe80, p=0x86f160)
> >      at /home/jpff/csound6/Opcodes/ugnorman.c:1534
> > #1  0x00007ffff7aba6fc in atssinnoiset_S (csound=0x61fe80, p=0x86f160)
> >      at /home/jpff/csound6/Opcodes/ugnorman.c:1844
> > #2  0x00007ffff78f4049 in init_pass (ip=0x86eba0, csound=0x61fe80)
> >      at /home/jpff/csound6/Engine/insert.c:116
> >
> > In y example j is 177 way beyond the 150 partials I asked for (I think). I
> > have o idea of the akgoritm being used  The code was contributed in 2004
> > and I have never looked into it.
> >
> >
> >
> > On Wed, 20 Mar 2019, Oscar Pablo Di Liscia wrote:
> >
> > > Yes, you´re right.
> > > Any value for increment > 1 will cause that the output of ATSsinnoi is 0.
> > > It does not crash, but it outputs 0.
> > > I did not find this bug before. I will see the code, thanks for your report.
> > > Best
> > > Pablo
> > >
> > > El lun., 18 mar. 2019 a las 7:25, Menno Knevel () escribió:
> > >>
> > >> I think i have discovered another bug as well:
> > >> ATSadd works well with incr > 1 but ATSsinnoi with inc > 1 crashes all the
> > >> time.
> > >> so
> > >> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 1
> > >> but this crashes:
> > >> aout      ATSsinnoi ktime_pointer, 1, 0, 1, "fox.ats", 20, 0, 2
> > >>
> > >> Can you verify this?
> > >> I'm working with Linux Mint. Using the same fox ats with standard analyzing
> > >> options.
> > >>
> > >> (I have not yet tried the other ATS opcodes that has the same "offset +
> > >> npartials*incr " system, like ATSadd, bufread, cross.)
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
> > >>
> > >> 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
> > >
> > >
> > >
> > > --
> > > Dr. Oscar Pablo Di Liscia
> > > Profesor Titular
> > > Director Programa de Investigación "Sistemas Temporales y Síntesis
> > > Espacial en el Arte Sonoro"
> > > http://stseas.web.unq.edu.ar/
> > > Director Colección Editorial "Música y Ciencia"
> > > Escuela Universitaria de Artes
> > > Universidad Nacional de Quilmes
> > > Argentina
> > >
> > > 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
>
>
>
> --
> Dr. Oscar Pablo Di Liscia
> Profesor Titular
> Director Programa de Investigación "Sistemas Temporales y Síntesis
> Espacial en el Arte Sonoro"
> http://stseas.web.unq.edu.ar/
> Director Colección Editorial "Música y Ciencia"
> Escuela Universitaria de Artes
> Universidad Nacional de Quilmes
> Argentina



-- 
Dr. Oscar Pablo Di Liscia
Profesor Titular
Director Programa de Investigación "Sistemas Temporales y Síntesis
Espacial en el Arte Sonoro"
http://stseas.web.unq.edu.ar/
Director Colección Editorial "Música y Ciencia"
Escuela Universitaria de Artes
Universidad Nacional de Quilmes
Argentina

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