Hi all Csounders,
just a month ago, I toke part in the Open Day event of the Conservatory
which I am currently attending, doing a short live performance using Csound.
This live performance was nothing but a reproduction of an 8-channel
electroacoustic composition, re-arranged in order to work properly with the
quadraphonic system of our auditorium and accompanied by the addition of
some interventions in real time, like controlling the spatialization of the
materials through gestures, etc.
So, I coded a little Csound project and, mainly, I instanciated two
instruments for the reproduction of the octophonic piece and other ones for
the real time interaction. The first two instruments were briefly built
around the diskin2 opcode because I was looking just for a kind of track
player and I felt unnecessary to instanciate (and moreover, more difficul to
implement) two 600MB buffers in RAM. All was fine, except that - and,
actually, I still don't undestrand why this happens - the above mentioned
opcode seems to works properly only if the signal vector size is set to less
then 64 samples, that is 32, for instance: in fact, if ksmps is set to
greater values, ideally to lighten the CPU load, unfortunately, the opcode
returns noisy artifacts. I tried also to change the size of the buffer which
is used by the opcode itself, the -B and the -b flags with greater values
but the result doesn't change.
Said this, does anyone know what is actually going on and why?
Thanks in advance.



--
View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160.html
Sent from the Csound - General mailing list archive at Nabble.com.

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

Do you have a simple CSD that demonstrates the issue?

I can only think that -b was too small and if you were using CsoundQT, that its settings were overriding the values you put on for -b and -B.

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

> On 14 Jun 2016, at 03:37, Rodolfo Cangiotti  wrote:
> 
> Hi all Csounders,
> just a month ago, I toke part in the Open Day event of the Conservatory
> which I am currently attending, doing a short live performance using Csound.
> This live performance was nothing but a reproduction of an 8-channel
> electroacoustic composition, re-arranged in order to work properly with the
> quadraphonic system of our auditorium and accompanied by the addition of
> some interventions in real time, like controlling the spatialization of the
> materials through gestures, etc.
> So, I coded a little Csound project and, mainly, I instanciated two
> instruments for the reproduction of the octophonic piece and other ones for
> the real time interaction. The first two instruments were briefly built
> around the diskin2 opcode because I was looking just for a kind of track
> player and I felt unnecessary to instanciate (and moreover, more difficul to
> implement) two 600MB buffers in RAM. All was fine, except that - and,
> actually, I still don't undestrand why this happens - the above mentioned
> opcode seems to works properly only if the signal vector size is set to less
> then 64 samples, that is 32, for instance: in fact, if ksmps is set to
> greater values, ideally to lighten the CPU load, unfortunately, the opcode
> returns noisy artifacts. I tried also to change the size of the buffer which
> is used by the opcode itself, the -B and the -b flags with greater values
> but the result doesn't change.
> Said this, does anyone know what is actually going on and why?
> Thanks in advance.
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 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

Thank you for your reply.
I remember I tried to set, from the CsoundQt preferences, doubled or halved
values, compared to the default ones, for the -B and -b flags but the
artifacts kept going on.
Anyway, I am going to code a .csd file including only the diskin2 centered
instruments of the live electronics project and attach it later.



--
View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160p5750164.html
Sent from the Csound - General mailing list archive at Nabble.com.

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

Well, it is weird to say this but, despite I checked the entire project
several times during the past weeks, it seems that only this kind of
instrument isolation I did this afternoon made me actually understand what
is the reason of the previously mentioned artifacts. As you can see from the
attached .csd file, the signal read by the diskin2 opcode is then sent to a
delay line in order to simulate the Doppler effect and, almost surely, that
is the code section where these artifacts are generated: I say this because,
erroneously making the signal from diskin2 skip this delay line, the output
is definitely clean. I always assumed that these statements were right,
maybe because when I was coding this part of the project, this latter was
still very simple and then I was testing it using also smaller vector sizes.
Anyway, I am sincerely a bit surprised that this delay line is not working
properly. Currently, I am not familiar with this topic in Csound, but I used
delay lines a lot of time with Max, PD and the syntax of the statements
seems correct. Would you make me point out what is the mistake and why, when
I increase the vector size, the system doen't work as expectec?
diskin2_Issue.csd
  



--
View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160p5750171.html
Sent from the Csound - General mailing list archive at Nabble.com.

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

Here's a suggestion. If you reduced ksmps to, for example, 16 does the problem go away? I am guessing that the 0.001 in the deltapi line is to lift the delay time above zero / 1 ksmps period, but at ksmps=256 this would need to be about 0.006 seconds.
Iain.

> Date: Tue, 14 Jun 2016 19:09:02 -0700
> From: cangio.ps@HOTMAIL.IT
> Subject: Re: [Csnd] Issue with diskin2 opcode
> To: CSOUND@LISTSERV.HEANET.IE
>
> Well, it is weird to say this but, despite I checked the entire project
> several times during the past weeks, it seems that only this kind of
> instrument isolation I did this afternoon made me actually understand what
> is the reason of the previously mentioned artifacts. As you can see from the
> attached .csd file, the signal read by the diskin2 opcode is then sent to a
> delay line in order to simulate the Doppler effect and, almost surely, that
> is the code section where these artifacts are generated: I say this because,
> erroneously making the signal from diskin2 skip this delay line, the output
> is definitely clean. I always assumed that these statements were right,
> maybe because when I was coding this part of the project, this latter was
> still very simple and then I was testing it using also smaller vector sizes.
> Anyway, I am sincerely a bit surprised that this delay line is not working
> properly. Currently, I am not familiar with this topic in Csound, but I used
> delay lines a lot of time with Max, PD and the syntax of the statements
> seems correct. Would you make me point out what is the mistake and why, when
> I increase the vector size, the system doen't work as expectec?
> diskin2_Issue.csd
> <http://csound.1045644.n5.nabble.com/file/n5750171/diskin2_Issue.csd>
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160p5750171.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> 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

@Iain and @Victor, thank you for your gentle replies.
So, the delayr/delayw opcodes just instanciate a simple recirculating
buffer, with a reading phase which is always before the writing one. There
is no checking about the exactness of the parameters given to those opcodes:
I mean, I see I can actually set negative delay values, outputting really
weird artifacts. I am not properly familiar with low level programming (I'm
just learning Python by myself), but these opcodes recall such a very low
level approach to signal processing, doesn't they?
Anyway, thank you once more for your advices; I am going to fix the issue
limiting the delay value to a DSP cycle.
Last quick question: just for curiosity, is it possible to see how these
mentioned opcodes have been implemented in Csound? Are there, on the main
repository, the source files of these ones?



--
View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160p5750174.html
Sent from the Csound - General mailing list archive at Nabble.com.

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

@Iain and @Victor, thank you for your gentle replies.
So, the delayr/delayw opcodes just instanciate a simple recirculating
buffer, with a reading phase which is always before the writing one. There
is no checking about the exactness of the parameters given to those opcodes:
I mean, I see I can actually set negative delay values, outputting really
weird artifacts. I am not properly familiar with low level programming (I'm
just learning Python by myself), but these opcodes recall such a very low
level approach to signal processing, doesn't they?
Anyway, thank you once more for your advices; I am going to fix the issue
limiting the delay value to a DSP cycle.
Last quick question: just for curiosity, is it possible to see how these
mentioned opcodes have been implemented in Csound? Are there, on the main
repository, the source files of these ones?



--
View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160p5750174.html
Sent from the Csound - General mailing list archive at Nabble.com.

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

Look at OOps/ugens6.c  -- this is original code from 1980s I tink

On Wed, 15 Jun 2016, Rodolfo Cangiotti wrote:

> @Iain and @Victor, thank you for your gentle replies.
> So, the delayr/delayw opcodes just instanciate a simple recirculating
> buffer, with a reading phase which is always before the writing one. There
> is no checking about the exactness of the parameters given to those opcodes:
> I mean, I see I can actually set negative delay values, outputting really
> weird artifacts. I am not properly familiar with low level programming (I'm
> just learning Python by myself), but these opcodes recall such a very low
> level approach to signal processing, doesn't they?
> Anyway, thank you once more for your advices; I am going to fix the issue
> limiting the delay value to a DSP cycle.
> Last quick question: just for curiosity, is it possible to see how these
> mentioned opcodes have been implemented in Csound? Are there, on the main
> repository, the source files of these ones?
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160p5750174.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> 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 so much for the information. I am going to look at the source code
file that you have mentioned.
Regards.



--
View this message in context: http://csound.1045644.n5.nabble.com/Issue-with-diskin2-opcode-tp5750160p5750177.html
Sent from the Csound - General mailing list archive at Nabble.com.

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