Hi,

Thanks to all developers for their continuous effort improving Csound!!!! 

During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.

I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.

I have three short test files attached: 

       FOXP2OneThread.mp3 which is produce without '-j N' 
       FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
       FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128

(this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:

AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC

Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )

I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11

I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.

Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?

Regards,

Karin

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 karin -

without diving deeper into your question:  did you try the option
	--realtime ?

according to the manual (https://csound.com/docs/manual/CommandFlags.html):

--realtime
     realtime priority mode is switched on which the following effects:
         all opcode audio file reading/writing is handled asynchronously 
by a separate thread.
         all init-pass operations are also performed asynchronously.


best -
	joachim




On 28/10/18 09:53, Karin Daum wrote:
> Hi,
>
> Thanks to all developers for their continuous effort improving Csound!!!!
>
> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>
> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>
> I have three short test files attached:
>
>        FOXP2OneThread.mp3 which is produce without '-j N'
>        FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>        FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>
> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>
> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>
> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>
> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>
> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>
> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>
> Regards,
>
> Karin
>
> 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

Are you suggesting thtte orderof summatio is the problem or something 
else?  Previously we had cases where te semantic information was wrong 
which gives rise to incorrecrt partial orders of the opcodes.  To 
investgate I need to have the orc to check thesemantics and implemetation 
of locks is correct.

==John ff

On Sun, 28 Oct 2018, Karin Daum wrote:

> Hi,
>
> Thanks to all developers for their continuous effort improving Csound!!!!
>
> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>
> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>
> I have three short test files attached:
>
>       FOXP2OneThread.mp3 which is produce without '-j N'
>       FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>       FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>
> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>
> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>
> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>
> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>
> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>
> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>
> Regards,
>
> Karin
>
> 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

The problem is your use of clear opcode which does not knowm that the 
input argument is actually an output one, so the partial orering is wrong. 
Replacing "clear gal" with "gal=0" should gfix it -- not tested.

Sorry about last message -- I did not see the csd file attached

Not sure how to fix clear.....

On Sun, 28 Oct 2018, Karin Daum wrote:

> Hi,
>
> Thanks to all developers for their continuous effort improving Csound!!!!
>
> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>
> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>
> I have three short test files attached:
>
>       FOXP2OneThread.mp3 which is produce without '-j N'
>       FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>       FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>
> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>
> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>
> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>
> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>
> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>
> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>
> Regards,
>
> Karin
>
> 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

PS Multicore may not give you much as far as I can see, or even slow you 
down, as there is only one instr1 running at a time and one i100.  So 
maximum 2 processes and due to global reverb they are constrained to run 
sequentially.  See my paper in St Petersberg ICSC.

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 Joachim,

thank you for your answer. No, I did not try —realtime yet.

When I'm doing so, I get an errors:

If I’m using the small input file (4 lines of input), which I’ve used for the audio files which I’ve attached to my initial post, it runs but Csound ends with:

csound command: Bus error

If I’m using a more realistic input file with about 9,000 lines of input in case of the FOXP2 gene, then it crashes when reading the file

Starting realtime mode queue: 0x137747010 thread: 0x7fe6f393b460
ftable 1:
….
Initialising spinlock...
Starting realtime mode queue: 0x12daff010 thread: 0x7fad7826f570
ftable 1:
new alloc for instr 101:
reading from file /Users/daum/Downloads/Homo_sapiens_FOXP2.fa
Score finished in csoundPerform().
PERF ERROR in instr 101: readf: read failure
   note aborted

++++

instr 101 is the genome reader. The score statement for it is e.g.:

i101 0 100 0.5 0.8 “/Users/daum/Downloads/Homo_sapiens_FOXP2.fa" 0 120; Homo sapiens FOXP2 ("Sprach-Gen")

and the code of instr 101 is attached. It crashed when opening or start reading the somewhat larger text input file using the readfi opcode.

This problem does not appear when running Csound not using —realtime

The clicks I reported initially when the scheduling instrument is relaunched about every 20 second with using a single thread, I only get in CsoundQT. When running the csd with Csound in the terminal, I don’t get clicks when using a single thread. The average Csound CPU load is about 30% and reaches peak values of about 50% (many instruments playing simultaneously + the scheduler). This means that I can run the csd without using -n or —realtime.

best,

Karin


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 28 Oct 2018, at 14:08, joachim heintz  wrote:
> 
> hi karin -
> 
> without diving deeper into your question:  did you try the option
> 	--realtime ?
> 
> according to the manual (https://csound.com/docs/manual/CommandFlags.html):
> 
> --realtime
>    realtime priority mode is switched on which the following effects:
>        all opcode audio file reading/writing is handled asynchronously by a separate thread.
>        all init-pass operations are also performed asynchronously.
> 
> 
> best -
> 	joachim
> 
> 
> 
> 
> On 28/10/18 09:53, Karin Daum wrote:
>> Hi,
>> 
>> Thanks to all developers for their continuous effort improving Csound!!!!
>> 
>> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>> 
>> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>> 
>> I have three short test files attached:
>> 
>>       FOXP2OneThread.mp3 which is produce without '-j N'
>>       FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>>       FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>> 
>> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>> 
>> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
>> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
>> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>> 
>> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>> 
>> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>> 
>> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>> 
>> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>> 
>> Regards,
>> 
>> Karin
>> 
>> 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

I just used problem.csd and replaced in instr 1000

clear gal
clear gar

by 

gal=0
gar=0

The result is the same - you get the same distortions

cheers,

Karin 
> On 28 Oct 2018, at 15:49, jpff  wrote:
> 
> The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.
> 
> Sorry about last message -- I did not see the csd file attached
> 
> Not sure how to fix clear.....
> 
> On Sun, 28 Oct 2018, Karin Daum wrote:
> 
>> Hi,
>> 
>> Thanks to all developers for their continuous effort improving Csound!!!!
>> 
>> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>> 
>> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>> 
>> I have three short test files attached:
>> 
>>      FOXP2OneThread.mp3 which is produce without '-j N'
>>      FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>>      FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>> 
>> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>> 
>> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
>> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
>> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>> 
>> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>> 
>> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>> 
>> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>> 
>> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>> 
>> Regards,
>> 
>> Karin
>> 
>> 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

yes, I’m aware of the problem of global variables and multicores (from your paper). When using my SoundOfLife.csd I get an improvement in speed when using 2 cores (with the problem reported), because of the many instruments and instances thereof running simultaneously. But indeed, using three cores slows down everything significantly.

cheers,

Karin

> On 28 Oct 2018, at 16:08, jpff  wrote:
> 
> PS Multicore may not give you much as far as I can see, or even slow you down, as there is only one instr1 running at a time and one i100.  So maximum 2 processes and due to global reverb they are constrained to run sequentially.  See my paper in St Petersberg ICSC.
> 
> 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

OK; it was a god idea and clearly a bug.  Now to look elsewhere.


On Sun, 28 Oct 2018, Karin Daum wrote:

> I just used problem.csd and replaced in instr 1000
>
> clear gal
> clear gar
>
> by
>
> gal=0
> gar=0
>
> The result is the same - you get the same distortions
>
> cheers,
>
> Karin
>> On 28 Oct 2018, at 15:49, jpff  wrote:
>>
>> The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.
>>
>> Sorry about last message -- I did not see the csd file attached
>>
>> Not sure how to fix clear.....
>>
>> On Sun, 28 Oct 2018, Karin Daum wrote:
>>
>>> Hi,
>>>
>>> Thanks to all developers for their continuous effort improving Csound!!!!
>>>
>>> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>>>
>>> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>>>
>>> I have three short test files attached:
>>>
>>>      FOXP2OneThread.mp3 which is produce without '-j N'
>>>      FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>>>      FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>>>
>>> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>>>
>>> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
>>> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
>>> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>>>
>>> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>>>
>>> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>>>
>>> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>>>
>>> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>>>
>>> Regards,
>>>
>>> Karin
>>>
>>> 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

I have fixed (locally) the clear problem and also saw some oter oddity. 
Anway working to file -j1 and -j2 outputs are identical; in realtime there 
are some articats of being too slow I think.  Also it looks as if -j2 is 
faster but I need to check that again


On Sun, 28 Oct 2018, Karin Daum wrote:

> I just used problem.csd and replaced in instr 1000
>
> clear gal
> clear gar
>
> by
>
> gal=0
> gar=0
>
> The result is the same - you get the same distortions
>
> cheers,
>
> Karin
>> On 28 Oct 2018, at 15:49, jpff  wrote:
>>
>> The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.
>>
>> Sorry about last message -- I did not see the csd file attached
>>
>> Not sure how to fix clear.....
>>
>> On Sun, 28 Oct 2018, Karin Daum wrote:
>>
>>> Hi,
>>>
>>> Thanks to all developers for their continuous effort improving Csound!!!!
>>>
>>> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>>>
>>> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>>>
>>> I have three short test files attached:
>>>
>>>      FOXP2OneThread.mp3 which is produce without '-j N'
>>>      FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>>>      FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>>>
>>> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>>>
>>> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
>>> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
>>> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>>>
>>> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>>>
>>> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>>>
>>> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>>>
>>> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>>>
>>> Regards,
>>>
>>> Karin
>>>
>>> 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

Hi, it seems to me like something going wrong with multithreading, with global values changed before they should, but if you do this little change, your code will work flawless in multithreading too (I tried with 8 threads):

<CsoundSynthesizer>
<CsOptions>
</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 2
0dbfs  = 1

gal     init    0
gar     init    0

instr 1
    iadd    init    0.2
    p3      +=      iadd
    kpan    init    p6
    idur    =       p3
    iamp    =       p4 * 2
    ifqc    =       cpspch(p5)
    kcps    =       k(ifqc)
    irise   =       0.05
    kdclik  linseg  0, irise, iamp, idur - .12 - irise, iamp, .02, 0
    kdclik1 expseg  0.001, irise, 0.901, 0.9 * idur - irise - iadd, 0.901, iadd, 0.001
    kdclik1 =       kdclik1 - 0.001
    kdclik1 port    kdclik1, 0.05
    kdclik  =       kdclik * kdclik1
    aout    oscil   iamp, ifqc, 1
    al, ar  pan2    aout * a(kdclik), kpan
    
    ;gal        +=      al
    ;gar        +=      ar
    
    gal     =       gal * 0.99 + al * 0.01
    gar     =       gar * 0.99 + ar * 0.01
endin



instr 1000
    ;; render output
    
    kamp    init    p5
            prints  "instr1 %f \n", p3
    al1     eqfil   gal, 8000, 4000, 1.5
    ar1     eqfil   gar, 8000, 4000, 1.5
    
    a1, a2  reverbsc al1, ar1, p4, 10000, sr, 0.5
    
    al      =       a1 + al1
    ar      =       a2 + ar1
    al1     dcblock al
    ar1     dcblock ar
    
            outs    al1 * a(kamp) * 10, ar1 * a(kamp) * 10
            clear   gal, gar
endin

</CsInstruments>
<CsScore>
f1 0 16384 10 1                               ; Sine
i1  1.00 1.00 0.5  5.08 0.5
i1  2.00 0.25 0.5  6.06 0.5
i1  2.25 0.25 0.5  7.01 0.5
i1  2.50 0.25 0.5  7.10 0.5
i1  2.75 0.25 0.5  6.11 0.5
i1  3.00 0.25 0.5  6.10 0.5
i1  3.25 0.50 0.5  5.08 0.5
i1  3.75 0.50 0.5  5.02 0.5
i1  4.25 0.25 0.5  7.01 0.5
i1  4.50 0.25 0.5  7.10 0.5
i1  4.75 0.50 0.5  5.04 0.5
i1  5.25 0.25 0.5  7.01 0.5
i1  5.50 0.25 0.5  7.02 0.5
i1  5.75 0.25 0.5  7.01 0.5
i1  6.00 0.25 0.5  8.10 0.5
i1  6.25 0.25 0.5  6.06 0.5
i1  6.50 0.25 0.5  7.05 0.5
i1  6.75 0.25 0.5  7.01 0.5
i1  7.00 0.25 0.5  8.05 0.5
i1  7.25 0.25 0.5  7.01 0.5
i1  7.50 0.25 0.5  7.01 0.5
i1  7.75 0.25 0.5 10.01 0.5
i1  8.00 0.25 0.5  8.01 0.5
i1  8.25 0.25 0.5  7.04 0.5
i1  8.50 0.25 0.5  8.03 0.5
i1  8.75 0.25 0.5  7.04 0.5
i1  9.00 0.25 0.5  8.01 0.5
i1  9.25 0.25 0.5  6.10 0.5
i1  9.50 0.25 0.5  7.01 0.5
i1  9.75 0.25 0.5  6.05 0.5
i1 10.00 0.25 0.5  6.10 0.5
i1 10.25 0.25 0.5  6.06 0.5
i1 10.50 0.25 0.5  6.09 0.5
i1 10.75 0.25 0.5  8.01 0.5
i1 11.00 0.25 0.5  7.01 0.5
i1 11.25 0.25 0.5  7.08 0.5
i1 11.50 0.25 0.5  7.01 0.5
i1 11.75 0.25 0.5  6.10 0.5
i1 12.00 0.25 0.5  6.09 0.5
i1 12.25 0.25 0.5  7.02 0.5
i1 12.50 0.25 0.5 10.00 0.5
i1 12.75 0.25 0.5 10.03 0.5
i1 13.00 0.25 0.5  6.02 0.5
i1 13.25 0.25 0.5  7.02 0.5
i1 13.50 0.25 0.5  7.02 0.5
i1 13.75 0.25 0.5  6.10 0.5
i1 14.00 0.25 0.5  7.03 0.5
i1 14.25 0.25 0.5  6.10 0.5
i1 14.50 0.25 0.5  7.06 0.5
i1 14.75 0.25 0.5  8.03 0.5
i1 15.00 0.25 0.5  8.02 0.5
i1 15.25 0.25 0.5  8.03 0.5
i1 15.50 0.25 0.5  9.05 0.5
i1 15.75 0.25 0.5  9.06 0.5
i1 16.00 0.25 0.5  8.01 0.5
i1 16.25 0.25 0.5  6.09 0.5
i1 16.50 0.25 0.5  6.09 0.5
i1 16.75 0.25 0.5  7.05 0.5
i1 17.00 0.25 0.5  6.09 0.5
i1 17.25 0.25 0.5  8.06 0.5
i1 17.50 0.25 0.5  7.01 0.5
i1 17.75 0.25 0.5  8.01 0.5
i1 18.00 0.25 0.5  6.09 0.5
i1 18.25 0.25 0.5  6.05 0.5
i1 18.50 0.25 0.5  9.06 0.5
i1 18.75 0.25 0.5  7.02 0.5
i1 19.00 0.25 0.5  6.06 0.5
i1 19.25 0.25 0.5  6.06 0.5
i1 19.50 0.25 0.5  7.06 0.5
i1 19.75 0.25 0.5  6.09 0.5

i1000 0 22 0.85 0.4

</CsScore>
</CsoundSynthesizer>

It does just a very smooth linear transition from the previous global a-variable to the new one, so to "hide" eventual abrupt changes of those global variables by other threads.

P.S.: those sounds are very relaxing to listen to. :-)

Regards,
Mauro

Il 2018-10-28 16:20 Karin Daum ha scritto:

I just used problem.csd and replaced in instr 1000

clear gal
clear gar

by

gal=0
gar=0

The result is the same - you get the same distortions

cheers,

Karin

On 28 Oct 2018, at 15:49, jpff <jpff@CODEMIST.CO.UK> wrote:

The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.

Sorry about last message -- I did not see the csd file attached

Not sure how to fix clear.....

On Sun, 28 Oct 2018, Karin Daum wrote:

Hi,

Thanks to all developers for their continuous effort improving Csound!!!!

During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.

I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.

I have three short test files attached:

     FOXP2OneThread.mp3 which is produce without '-j N'
     FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
     FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128

(this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:

AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC

Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )

I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11

I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.

Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?

Regards,

Karin

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

Oscil doesn't do interpolation, so its output is raw, but you can try to use 'poscil3' that should be the most accurate oscillator in the Csound library:

aout poscil3 iamp, ifqc, 1

Then you can try to make a table with a bigger resolution for the sin wave:

f1 0 [2^16] 10 1 ; Sine

I don't know if it could make some difference, but you can try to lower the ksmps too (maybe 8?).

Regards,
Mauro

Il 2018-10-28 19:59 Karin Daum ha scritto:

Hi Mauro,

 

indeed this seems to work for this simple example except that I would apply a factor 100 in instr 1000 to get the same output level. I don't know how this will behave for the csd file I'm working on, where easily can happen that 20 instruments or so play simultaneously.

 

I looked at the signal in detail using praat. From my experience from the past using a different software it looks to me like some pointer problem. There are many more small distortions which you can see, when you look at the waveform in detail, but which you hardly can hear.

 

cheers,

 

Karin

 

PS: It is composed by nature (DNA). I often listen to some gene from some species while programming. Even Ebola played on a harp sounds quite relaxing.  

On 28 Oct 2018, at 18:44, Mauro Giubileo <mgiubileo@COMPUTERALTAFED.IT> wrote:

Hi, it seems to me like something going wrong with multithreading, with global values changed before they should, but if you do this little change, your code will work flawless in multithreading too (I tried with 8 threads):

<CsoundSynthesizer>
<CsOptions>
</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 2
0dbfs  = 1

gal     init    0
gar     init    0

instr 1
    iadd    init    0.2
    p3      +=      iadd
    kpan    init    p6
    idur    =       p3
    iamp    =       p4 * 2
    ifqc    =       cpspch(p5)
    kcps    =       k(ifqc)
    irise   =       0.05
    kdclik  linseg  0, irise, iamp, idur - .12 - irise, iamp, .02, 0
    kdclik1 expseg  0.001, irise, 0.901, 0.9 * idur - irise - iadd, 0.901, iadd, 0.001
    kdclik1 =       kdclik1 - 0.001
    kdclik1 port    kdclik1, 0.05
    kdclik  =       kdclik * kdclik1
    aout    oscil   iamp, ifqc, 1
    al, ar  pan2    aout * a(kdclik), kpan
    
    ;gal        +=      al
    ;gar        +=      ar
    
    gal     =       gal * 0.99 + al * 0.01
    gar     =       gar * 0.99 + ar * 0.01
endin



instr 1000
    ;; render output
    
    kamp    init    p5
            prints  "instr1 %f \n", p3
    al1     eqfil   gal, 8000, 4000, 1.5
    ar1     eqfil   gar, 8000, 4000, 1.5
    
    a1, a2  reverbsc al1, ar1, p4, 10000, sr, 0.5
    
    al      =       a1 + al1
    ar      =       a2 + ar1
    al1     dcblock al
    ar1     dcblock ar
    
            outs    al1 * a(kamp) * 10, ar1 * a(kamp) * 10
            clear   gal, gar
endin

</CsInstruments>
<CsScore>
f1 0 16384 10 1                               ; Sine
i1  1.00 1.00 0.5  5.08 0.5
i1  2.00 0.25 0.5  6.06 0.5
i1  2.25 0.25 0.5  7.01 0.5
i1  2.50 0.25 0.5  7.10 0.5
i1  2.75 0.25 0.5  6.11 0.5
i1  3.00 0.25 0.5  6.10 0.5
i1  3.25 0.50 0.5  5.08 0.5
i1  3.75 0.50 0.5  5.02 0.5
i1  4.25 0.25 0.5  7.01 0.5
i1  4.50 0.25 0.5  7.10 0.5
i1  4.75 0.50 0.5  5.04 0.5
i1  5.25 0.25 0.5  7.01 0.5
i1  5.50 0.25 0.5  7.02 0.5
i1  5.75 0.25 0.5  7.01 0.5
i1  6.00 0.25 0.5  8.10 0.5
i1  6.25 0.25 0.5  6.06 0.5
i1  6.50 0.25 0.5  7.05 0.5
i1  6.75 0.25 0.5  7.01 0.5
i1  7.00 0.25 0.5  8.05 0.5
i1  7.25 0.25 0.5  7.01 0.5
i1  7.50 0.25 0.5  7.01 0.5
i1  7.75 0.25 0.5 10.01 0.5
i1  8.00 0.25 0.5  8.01 0.5
i1  8.25 0.25 0.5  7.04 0.5
i1  8.50 0.25 0.5  8.03 0.5
i1  8.75 0.25 0.5  7.04 0.5
i1  9.00 0.25 0.5  8.01 0.5
i1  9.25 0.25 0.5  6.10 0.5
i1  9.50 0.25 0.5  7.01 0.5
i1  9.75 0.25 0.5  6.05 0.5
i1 10.00 0.25 0.5  6.10 0.5
i1 10.25 0.25 0.5  6.06 0.5
i1 10.50 0.25 0.5  6.09 0.5
i1 10.75 0.25 0.5  8.01 0.5
i1 11.00 0.25 0.5  7.01 0.5
i1 11.25 0.25 0.5  7.08 0.5
i1 11.50 0.25 0.5  7.01 0.5
i1 11.75 0.25 0.5  6.10 0.5
i1 12.00 0.25 0.5  6.09 0.5
i1 12.25 0.25 0.5  7.02 0.5
i1 12.50 0.25 0.5 10.00 0.5
i1 12.75 0.25 0.5 10.03 0.5
i1 13.00 0.25 0.5  6.02 0.5
i1 13.25 0.25 0.5  7.02 0.5
i1 13.50 0.25 0.5  7.02 0.5
i1 13.75 0.25 0.5  6.10 0.5
i1 14.00 0.25 0.5  7.03 0.5
i1 14.25 0.25 0.5  6.10 0.5
i1 14.50 0.25 0.5  7.06 0.5
i1 14.75 0.25 0.5  8.03 0.5
i1 15.00 0.25 0.5  8.02 0.5
i1 15.25 0.25 0.5  8.03 0.5
i1 15.50 0.25 0.5  9.05 0.5
i1 15.75 0.25 0.5  9.06 0.5
i1 16.00 0.25 0.5  8.01 0.5
i1 16.25 0.25 0.5  6.09 0.5
i1 16.50 0.25 0.5  6.09 0.5
i1 16.75 0.25 0.5  7.05 0.5
i1 17.00 0.25 0.5  6.09 0.5
i1 17.25 0.25 0.5  8.06 0.5
i1 17.50 0.25 0.5  7.01 0.5
i1 17.75 0.25 0.5  8.01 0.5
i1 18.00 0.25 0.5  6.09 0.5
i1 18.25 0.25 0.5  6.05 0.5
i1 18.50 0.25 0.5  9.06 0.5
i1 18.75 0.25 0.5  7.02 0.5
i1 19.00 0.25 0.5  6.06 0.5
i1 19.25 0.25 0.5  6.06 0.5
i1 19.50 0.25 0.5  7.06 0.5
i1 19.75 0.25 0.5  6.09 0.5

i1000 0 22 0.85 0.4

</CsScore>
</CsoundSynthesizer>

It does just a very smooth linear transition from the previous global a-variable to the new one, so to "hide" eventual abrupt changes of those global variables by other threads.

P.S.: those sounds are very relaxing to listen to. :-)

Regards,
Mauro

Il 2018-10-28 16:20 Karin Daum ha scritto:

I just used problem.csd and replaced in instr 1000

clear gal
clear gar

by

gal=0
gar=0

The result is the same - you get the same distortions

cheers,

Karin

On 28 Oct 2018, at 15:49, jpff <jpff@CODEMIST.CO.UK> wrote:

The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.

Sorry about last message -- I did not see the csd file attached

Not sure how to fix clear.....

On Sun, 28 Oct 2018, Karin Daum wrote:

Hi,

Thanks to all developers for their continuous effort improving Csound!!!!

During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.

I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.

I have three short test files attached:

     FOXP2OneThread.mp3 which is produce without '-j N'
     FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
     FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128

(this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:

AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC

Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )

I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11

I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.

Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?

Regards,

Karin

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

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

If it's just a sine then maybe also oscils?

On 28/10/18 16:45, Mauro Giubileo wrote:
> Oscil doesn't do interpolation, so its output is raw, but you can try to
> use 'poscil3' that should be the most accurate oscillator in the Csound
> library: 
>
> aout poscil3 iamp, ifqc, 1 
>
> Then you can try to make a table with a bigger resolution for the sin
> wave: 
>
> f1 0 [2^16] 10 1 ; Sine 
>
> I don't know if it could make some difference, but you can try to lower
> the ksmps too (maybe 8?). 
>
> Regards,
> Mauro
>
> Il 2018-10-28 19:59 Karin Daum ha scritto:
>
>> Hi Mauro, 
>>
>> indeed this seems to work for this simple example except that I would apply a factor 100 in instr 1000 to get the same output level. I don't know how this will behave for the csd file I'm working on, where easily can happen that 20 instruments or so play simultaneously. 
>>
>> I looked at the signal in detail using praat. From my experience from the past using a different software it looks to me like some pointer problem. There are many more small distortions which you can see, when you look at the waveform in detail, but which you hardly can hear. 
>>
>> cheers, 
>>
>> Karin 
>>
>> PS: It is composed by nature (DNA). I often listen to some gene from some species while programming. Even Ebola played on a harp sounds quite relaxing.   
>>
>> On 28 Oct 2018, at 18:44, Mauro Giubileo  wrote: 
>>
>> Hi, it seems to me like something going wrong with multithreading, with global values changed before they should, but if you do this little change, your code will work flawless in multithreading too (I tried with 8 threads): 
>>
>> 
>> 
>> 
>> 
>>
>> sr = 44100
>> ksmps = 32
>> nchnls = 2
>> 0dbfs  = 1
>>
>> gal     init    0
>> gar     init    0
>>
>> instr 1
>> iadd    init    0.2
>> p3      +=      iadd
>> kpan    init    p6
>> idur    =       p3
>> iamp    =       p4 * 2
>> ifqc    =       cpspch(p5)
>> kcps    =       k(ifqc)
>> irise   =       0.05
>> kdclik  linseg  0, irise, iamp, idur - .12 - irise, iamp, .02, 0
>> kdclik1 expseg  0.001, irise, 0.901, 0.9 * idur - irise - iadd, 0.901, iadd, 0.001
>> kdclik1 =       kdclik1 - 0.001
>> kdclik1 port    kdclik1, 0.05
>> kdclik  =       kdclik * kdclik1
>> aout    oscil   iamp, ifqc, 1
>> al, ar  pan2    aout * a(kdclik), kpan
>>
>> ;gal        +=      al
>> ;gar        +=      ar
>>
>> gal     =       gal * 0.99 + al * 0.01
>> gar     =       gar * 0.99 + ar * 0.01
>> endin
>>
>> instr 1000
>> ;; render output
>>
>> kamp    init    p5
>> prints  "instr1 %f \n", p3
>> al1     eqfil   gal, 8000, 4000, 1.5
>> ar1     eqfil   gar, 8000, 4000, 1.5
>>
>> a1, a2  reverbsc al1, ar1, p4, 10000, sr, 0.5
>>
>> al      =       a1 + al1
>> ar      =       a2 + ar1
>> al1     dcblock al
>> ar1     dcblock ar
>>
>> outs    al1 * a(kamp) * 10, ar1 * a(kamp) * 10
>> clear   gal, gar
>> endin
>>
>> 
>> 
>> f1 0 16384 10 1                               ; Sine
>> i1  1.00 1.00 0.5  5.08 0.5 
>> i1  2.00 0.25 0.5  6.06 0.5 
>> i1  2.25 0.25 0.5  7.01 0.5 
>> i1  2.50 0.25 0.5  7.10 0.5 
>> i1  2.75 0.25 0.5  6.11 0.5 
>> i1  3.00 0.25 0.5  6.10 0.5 
>> i1  3.25 0.50 0.5  5.08 0.5 
>> i1  3.75 0.50 0.5  5.02 0.5 
>> i1  4.25 0.25 0.5  7.01 0.5 
>> i1  4.50 0.25 0.5  7.10 0.5 
>> i1  4.75 0.50 0.5  5.04 0.5 
>> i1  5.25 0.25 0.5  7.01 0.5 
>> i1  5.50 0.25 0.5  7.02 0.5 
>> i1  5.75 0.25 0.5  7.01 0.5 
>> i1  6.00 0.25 0.5  8.10 0.5 
>> i1  6.25 0.25 0.5  6.06 0.5 
>> i1  6.50 0.25 0.5  7.05 0.5 
>> i1  6.75 0.25 0.5  7.01 0.5 
>> i1  7.00 0.25 0.5  8.05 0.5 
>> i1  7.25 0.25 0.5  7.01 0.5 
>> i1  7.50 0.25 0.5  7.01 0.5 
>> i1  7.75 0.25 0.5 10.01 0.5 
>> i1  8.00 0.25 0.5  8.01 0.5 
>> i1  8.25 0.25 0.5  7.04 0.5 
>> i1  8.50 0.25 0.5  8.03 0.5 
>> i1  8.75 0.25 0.5  7.04 0.5 
>> i1  9.00 0.25 0.5  8.01 0.5 
>> i1  9.25 0.25 0.5  6.10 0.5 
>> i1  9.50 0.25 0.5  7.01 0.5 
>> i1  9.75 0.25 0.5  6.05 0.5 
>> i1 10.00 0.25 0.5  6.10 0.5 
>> i1 10.25 0.25 0.5  6.06 0.5 
>> i1 10.50 0.25 0.5  6.09 0.5 
>> i1 10.75 0.25 0.5  8.01 0.5 
>> i1 11.00 0.25 0.5  7.01 0.5 
>> i1 11.25 0.25 0.5  7.08 0.5 
>> i1 11.50 0.25 0.5  7.01 0.5 
>> i1 11.75 0.25 0.5  6.10 0.5 
>> i1 12.00 0.25 0.5  6.09 0.5 
>> i1 12.25 0.25 0.5  7.02 0.5 
>> i1 12.50 0.25 0.5 10.00 0.5 
>> i1 12.75 0.25 0.5 10.03 0.5 
>> i1 13.00 0.25 0.5  6.02 0.5 
>> i1 13.25 0.25 0.5  7.02 0.5 
>> i1 13.50 0.25 0.5  7.02 0.5 
>> i1 13.75 0.25 0.5  6.10 0.5 
>> i1 14.00 0.25 0.5  7.03 0.5 
>> i1 14.25 0.25 0.5  6.10 0.5 
>> i1 14.50 0.25 0.5  7.06 0.5 
>> i1 14.75 0.25 0.5  8.03 0.5 
>> i1 15.00 0.25 0.5  8.02 0.5 
>> i1 15.25 0.25 0.5  8.03 0.5 
>> i1 15.50 0.25 0.5  9.05 0.5 
>> i1 15.75 0.25 0.5  9.06 0.5 
>> i1 16.00 0.25 0.5  8.01 0.5 
>> i1 16.25 0.25 0.5  6.09 0.5 
>> i1 16.50 0.25 0.5  6.09 0.5 
>> i1 16.75 0.25 0.5  7.05 0.5 
>> i1 17.00 0.25 0.5  6.09 0.5 
>> i1 17.25 0.25 0.5  8.06 0.5 
>> i1 17.50 0.25 0.5  7.01 0.5 
>> i1 17.75 0.25 0.5  8.01 0.5 
>> i1 18.00 0.25 0.5  6.09 0.5 
>> i1 18.25 0.25 0.5  6.05 0.5 
>> i1 18.50 0.25 0.5  9.06 0.5 
>> i1 18.75 0.25 0.5  7.02 0.5 
>> i1 19.00 0.25 0.5  6.06 0.5 
>> i1 19.25 0.25 0.5  6.06 0.5 
>> i1 19.50 0.25 0.5  7.06 0.5 
>> i1 19.75 0.25 0.5  6.09 0.5 
>>
>> i1000 0 22 0.85 0.4
>>
>> 
>>  
>>
>> It does just a very smooth linear transition from the previous global a-variable to the new one, so to "hide" eventual abrupt changes of those global variables by other threads. 
>>
>> P.S.: those sounds are very relaxing to listen to. :-) 
>>
>> Regards,
>> Mauro 
>>
>> Il 2018-10-28 16:20 Karin Daum ha scritto: 
>> I just used problem.csd and replaced in instr 1000
>>
>> clear gal
>> clear gar
>>
>> by 
>>
>> gal=0
>> gar=0
>>
>> The result is the same - you get the same distortions
>>
>> cheers,
>>
>> Karin On 28 Oct 2018, at 15:49, jpff  wrote:
>>
>> The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.
>>
>> Sorry about last message -- I did not see the csd file attached
>>
>> Not sure how to fix clear.....
>>
>> On Sun, 28 Oct 2018, Karin Daum wrote:
>>
>> Hi,
>>
>> Thanks to all developers for their continuous effort improving Csound!!!!
>>
>> During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.
>>
>> I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.
>>
>> I have three short test files attached:
>>
>> FOXP2OneThread.mp3 which is produce without '-j N'
>> FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
>> FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128
>>
>> (this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:
>>
>> AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
>> TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
>> TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC
>>
>> Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )
>>
>> I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11
>>
>> I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.
>>
>> Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?
>>
>> Regards,
>>
>> Karin
>>
>> 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 
>
> 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

Interesting... So, when you have to generate just a simple sinusoidal waveform, oscils could be faster than poscil3 and doesn't need precalculated tables?

Regards,
Mauro

Il 2018-10-28 21:28 Guillermo Senna ha scritto:

If it's just a sine then maybe also oscils?

On 28/10/18 16:45, Mauro Giubileo wrote:

Oscil doesn't do interpolation, so its output is raw, but you can try to
use 'poscil3' that should be the most accurate oscillator in the Csound
library:

aout poscil3 iamp, ifqc, 1

Then you can try to make a table with a bigger resolution for the sin
wave:

f1 0 [2^16] 10 1 ; Sine

I don't know if it could make some difference, but you can try to lower
the ksmps too (maybe 8?).

Regards,
Mauro

Il 2018-10-28 19:59 Karin Daum ha scritto:

Hi Mauro,

indeed this seems to work for this simple example except that I would apply a factor 100 in instr 1000 to get the same output level. I don't know how this will behave for the csd file I'm working on, where easily can happen that 20 instruments or so play simultaneously.

I looked at the signal in detail using praat. From my experience from the past using a different software it looks to me like some pointer problem. There are many more small distortions which you can see, when you look at the waveform in detail, but which you hardly can hear.

cheers,

Karin

PS: It is composed by nature (DNA). I often listen to some gene from some species while programming. Even Ebola played on a harp sounds quite relaxing.   

On 28 Oct 2018, at 18:44, Mauro Giubileo <mgiubileo@COMPUTERALTAFED.IT> wrote:

Hi, it seems to me like something going wrong with multithreading, with global values changed before they should, but if you do this little change, your code will work flawless in multithreading too (I tried with 8 threads):

<CsoundSynthesizer>
<CsOptions>
</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 2
0dbfs  = 1

gal     init    0
gar     init    0

instr 1
iadd    init    0.2
p3      +=      iadd
kpan    init    p6
idur    =       p3
iamp    =       p4 * 2
ifqc    =       cpspch(p5)
kcps    =       k(ifqc)
irise   =       0.05
kdclik  linseg  0, irise, iamp, idur - .12 - irise, iamp, .02, 0
kdclik1 expseg  0.001, irise, 0.901, 0.9 * idur - irise - iadd, 0.901, iadd, 0.001
kdclik1 =       kdclik1 - 0.001
kdclik1 port    kdclik1, 0.05
kdclik  =       kdclik * kdclik1
aout    oscil   iamp, ifqc, 1
al, ar  pan2    aout * a(kdclik), kpan

;gal        +=      al
;gar        +=      ar

gal     =       gal * 0.99 + al * 0.01
gar     =       gar * 0.99 + ar * 0.01
endin

instr 1000
;; render output

kamp    init    p5
prints  "instr1 %f \n", p3
al1     eqfil   gal, 8000, 4000, 1.5
ar1     eqfil   gar, 8000, 4000, 1.5

a1, a2  reverbsc al1, ar1, p4, 10000, sr, 0.5

al      =       a1 + al1
ar      =       a2 + ar1
al1     dcblock al
ar1     dcblock ar

outs    al1 * a(kamp) * 10, ar1 * a(kamp) * 10
clear   gal, gar
endin

</CsInstruments>
<CsScore>
f1 0 16384 10 1                               ; Sine
i1  1.00 1.00 0.5  5.08 0.5
i1  2.00 0.25 0.5  6.06 0.5
i1  2.25 0.25 0.5  7.01 0.5
i1  2.50 0.25 0.5  7.10 0.5
i1  2.75 0.25 0.5  6.11 0.5
i1  3.00 0.25 0.5  6.10 0.5
i1  3.25 0.50 0.5  5.08 0.5
i1  3.75 0.50 0.5  5.02 0.5
i1  4.25 0.25 0.5  7.01 0.5
i1  4.50 0.25 0.5  7.10 0.5
i1  4.75 0.50 0.5  5.04 0.5
i1  5.25 0.25 0.5  7.01 0.5
i1  5.50 0.25 0.5  7.02 0.5
i1  5.75 0.25 0.5  7.01 0.5
i1  6.00 0.25 0.5  8.10 0.5
i1  6.25 0.25 0.5  6.06 0.5
i1  6.50 0.25 0.5  7.05 0.5
i1  6.75 0.25 0.5  7.01 0.5
i1  7.00 0.25 0.5  8.05 0.5
i1  7.25 0.25 0.5  7.01 0.5
i1  7.50 0.25 0.5  7.01 0.5
i1  7.75 0.25 0.5 10.01 0.5
i1  8.00 0.25 0.5  8.01 0.5
i1  8.25 0.25 0.5  7.04 0.5
i1  8.50 0.25 0.5  8.03 0.5
i1  8.75 0.25 0.5  7.04 0.5
i1  9.00 0.25 0.5  8.01 0.5
i1  9.25 0.25 0.5  6.10 0.5
i1  9.50 0.25 0.5  7.01 0.5
i1  9.75 0.25 0.5  6.05 0.5
i1 10.00 0.25 0.5  6.10 0.5
i1 10.25 0.25 0.5  6.06 0.5
i1 10.50 0.25 0.5  6.09 0.5
i1 10.75 0.25 0.5  8.01 0.5
i1 11.00 0.25 0.5  7.01 0.5
i1 11.25 0.25 0.5  7.08 0.5
i1 11.50 0.25 0.5  7.01 0.5
i1 11.75 0.25 0.5  6.10 0.5
i1 12.00 0.25 0.5  6.09 0.5
i1 12.25 0.25 0.5  7.02 0.5
i1 12.50 0.25 0.5 10.00 0.5
i1 12.75 0.25 0.5 10.03 0.5
i1 13.00 0.25 0.5  6.02 0.5
i1 13.25 0.25 0.5  7.02 0.5
i1 13.50 0.25 0.5  7.02 0.5
i1 13.75 0.25 0.5  6.10 0.5
i1 14.00 0.25 0.5  7.03 0.5
i1 14.25 0.25 0.5  6.10 0.5
i1 14.50 0.25 0.5  7.06 0.5
i1 14.75 0.25 0.5  8.03 0.5
i1 15.00 0.25 0.5  8.02 0.5
i1 15.25 0.25 0.5  8.03 0.5
i1 15.50 0.25 0.5  9.05 0.5
i1 15.75 0.25 0.5  9.06 0.5
i1 16.00 0.25 0.5  8.01 0.5
i1 16.25 0.25 0.5  6.09 0.5
i1 16.50 0.25 0.5  6.09 0.5
i1 16.75 0.25 0.5  7.05 0.5
i1 17.00 0.25 0.5  6.09 0.5
i1 17.25 0.25 0.5  8.06 0.5
i1 17.50 0.25 0.5  7.01 0.5
i1 17.75 0.25 0.5  8.01 0.5
i1 18.00 0.25 0.5  6.09 0.5
i1 18.25 0.25 0.5  6.05 0.5
i1 18.50 0.25 0.5  9.06 0.5
i1 18.75 0.25 0.5  7.02 0.5
i1 19.00 0.25 0.5  6.06 0.5
i1 19.25 0.25 0.5  6.06 0.5
i1 19.50 0.25 0.5  7.06 0.5
i1 19.75 0.25 0.5  6.09 0.5

i1000 0 22 0.85 0.4

</CsScore>
</CsoundSynthesizer>

It does just a very smooth linear transition from the previous global a-variable to the new one, so to "hide" eventual abrupt changes of those global variables by other threads.

P.S.: those sounds are very relaxing to listen to. :-)

Regards,
Mauro

Il 2018-10-28 16:20 Karin Daum ha scritto:
I just used problem.csd and replaced in instr 1000

clear gal
clear gar

by

gal=0
gar=0

The result is the same - you get the same distortions

cheers,

Karin On 28 Oct 2018, at 15:49, jpff <jpff@CODEMIST.CO.UK> wrote:

The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.

Sorry about last message -- I did not see the csd file attached

Not sure how to fix clear.....

On Sun, 28 Oct 2018, Karin Daum wrote:

Hi,

Thanks to all developers for their continuous effort improving Csound!!!!

During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.

I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.

I have three short test files attached:

FOXP2OneThread.mp3 which is produce without '-j N'
FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128

(this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:

AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC

Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )

I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11

I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.

Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?

Regards,

Karin

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

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

I hope it will work well for you. ;-)

Regards,
Mauro

Il 2018-10-29 16:38 Karin Daum ha scritto:

HI Mauro,

 

the csd is a simple example, which demonstrates the problem. I wrote it specifically for the developers to allow them to easily verify the feature and to debug the Csound code. As far as I understood, John has solved the problem on his local version.

 

best,

 

Karin 

On 28 Oct 2018, at 20:45, Mauro Giubileo <mgiubileo@COMPUTERALTAFED.IT> wrote:

Oscil doesn't do interpolation, so its output is raw, but you can try to use 'poscil3' that should be the most accurate oscillator in the Csound library:

aout poscil3 iamp, ifqc, 1

Then you can try to make a table with a bigger resolution for the sin wave:

f1 0 [2^16] 10 1 ; Sine

I don't know if it could make some difference, but you can try to lower the ksmps too (maybe 8?).

Regards,
Mauro

 

Il 2018-10-28 19:59 Karin Daum ha scritto:

Hi Mauro,

 

indeed this seems to work for this simple example except that I would apply a factor 100 in instr 1000 to get the same output level. I don't know how this will behave for the csd file I'm working on, where easily can happen that 20 instruments or so play simultaneously.

 

I looked at the signal in detail using praat. From my experience from the past using a different software it looks to me like some pointer problem. There are many more small distortions which you can see, when you look at the waveform in detail, but which you hardly can hear.

 

cheers,

 

Karin

 

PS: It is composed by nature (DNA). I often listen to some gene from some species while programming. Even Ebola played on a harp sounds quite relaxing.  

On 28 Oct 2018, at 18:44, Mauro Giubileo <mgiubileo@COMPUTERALTAFED.IT> wrote:

Hi, it seems to me like something going wrong with multithreading, with global values changed before they should, but if you do this little change, your code will work flawless in multithreading too (I tried with 8 threads):

<CsoundSynthesizer>
<CsOptions>
</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 2
0dbfs  = 1

gal     init    0
gar     init    0

instr 1
    iadd    init    0.2
    p3      +=      iadd
    kpan    init    p6
    idur    =       p3
    iamp    =       p4 * 2
    ifqc    =       cpspch(p5)
    kcps    =       k(ifqc)
    irise   =       0.05
    kdclik  linseg  0, irise, iamp, idur - .12 - irise, iamp, .02, 0
    kdclik1 expseg  0.001, irise, 0.901, 0.9 * idur - irise - iadd, 0.901, iadd, 0.001
    kdclik1 =       kdclik1 - 0.001
    kdclik1 port    kdclik1, 0.05
    kdclik  =       kdclik * kdclik1
    aout    oscil   iamp, ifqc, 1
    al, ar  pan2    aout * a(kdclik), kpan
    
    ;gal        +=      al
    ;gar        +=      ar
    
    gal     =       gal * 0.99 + al * 0.01
    gar     =       gar * 0.99 + ar * 0.01
endin



instr 1000
    ;; render output
    
    kamp    init    p5
            prints  "instr1 %f \n", p3
    al1     eqfil   gal, 8000, 4000, 1.5
    ar1     eqfil   gar, 8000, 4000, 1.5
    
    a1, a2  reverbsc al1, ar1, p4, 10000, sr, 0.5
    
    al      =       a1 + al1
    ar      =       a2 + ar1
    al1     dcblock al
    ar1     dcblock ar
    
            outs    al1 * a(kamp) * 10, ar1 * a(kamp) * 10
            clear   gal, gar
endin

</CsInstruments>
<CsScore>
f1 0 16384 10 1                               ; Sine
i1  1.00 1.00 0.5  5.08 0.5
i1  2.00 0.25 0.5  6.06 0.5
i1  2.25 0.25 0.5  7.01 0.5
i1  2.50 0.25 0.5  7.10 0.5
i1  2.75 0.25 0.5  6.11 0.5
i1  3.00 0.25 0.5  6.10 0.5
i1  3.25 0.50 0.5  5.08 0.5
i1  3.75 0.50 0.5  5.02 0.5
i1  4.25 0.25 0.5  7.01 0.5
i1  4.50 0.25 0.5  7.10 0.5
i1  4.75 0.50 0.5  5.04 0.5
i1  5.25 0.25 0.5  7.01 0.5
i1  5.50 0.25 0.5  7.02 0.5
i1  5.75 0.25 0.5  7.01 0.5
i1  6.00 0.25 0.5  8.10 0.5
i1  6.25 0.25 0.5  6.06 0.5
i1  6.50 0.25 0.5  7.05 0.5
i1  6.75 0.25 0.5  7.01 0.5
i1  7.00 0.25 0.5  8.05 0.5
i1  7.25 0.25 0.5  7.01 0.5
i1  7.50 0.25 0.5  7.01 0.5
i1  7.75 0.25 0.5 10.01 0.5
i1  8.00 0.25 0.5  8.01 0.5
i1  8.25 0.25 0.5  7.04 0.5
i1  8.50 0.25 0.5  8.03 0.5
i1  8.75 0.25 0.5  7.04 0.5
i1  9.00 0.25 0.5  8.01 0.5
i1  9.25 0.25 0.5  6.10 0.5
i1  9.50 0.25 0.5  7.01 0.5
i1  9.75 0.25 0.5  6.05 0.5
i1 10.00 0.25 0.5  6.10 0.5
i1 10.25 0.25 0.5  6.06 0.5
i1 10.50 0.25 0.5  6.09 0.5
i1 10.75 0.25 0.5  8.01 0.5
i1 11.00 0.25 0.5  7.01 0.5
i1 11.25 0.25 0.5  7.08 0.5
i1 11.50 0.25 0.5  7.01 0.5
i1 11.75 0.25 0.5  6.10 0.5
i1 12.00 0.25 0.5  6.09 0.5
i1 12.25 0.25 0.5  7.02 0.5
i1 12.50 0.25 0.5 10.00 0.5
i1 12.75 0.25 0.5 10.03 0.5
i1 13.00 0.25 0.5  6.02 0.5
i1 13.25 0.25 0.5  7.02 0.5
i1 13.50 0.25 0.5  7.02 0.5
i1 13.75 0.25 0.5  6.10 0.5
i1 14.00 0.25 0.5  7.03 0.5
i1 14.25 0.25 0.5  6.10 0.5
i1 14.50 0.25 0.5  7.06 0.5
i1 14.75 0.25 0.5  8.03 0.5
i1 15.00 0.25 0.5  8.02 0.5
i1 15.25 0.25 0.5  8.03 0.5
i1 15.50 0.25 0.5  9.05 0.5
i1 15.75 0.25 0.5  9.06 0.5
i1 16.00 0.25 0.5  8.01 0.5
i1 16.25 0.25 0.5  6.09 0.5
i1 16.50 0.25 0.5  6.09 0.5
i1 16.75 0.25 0.5  7.05 0.5
i1 17.00 0.25 0.5  6.09 0.5
i1 17.25 0.25 0.5  8.06 0.5
i1 17.50 0.25 0.5  7.01 0.5
i1 17.75 0.25 0.5  8.01 0.5
i1 18.00 0.25 0.5  6.09 0.5
i1 18.25 0.25 0.5  6.05 0.5
i1 18.50 0.25 0.5  9.06 0.5
i1 18.75 0.25 0.5  7.02 0.5
i1 19.00 0.25 0.5  6.06 0.5
i1 19.25 0.25 0.5  6.06 0.5
i1 19.50 0.25 0.5  7.06 0.5
i1 19.75 0.25 0.5  6.09 0.5

i1000 0 22 0.85 0.4

</CsScore>
</CsoundSynthesizer>

It does just a very smooth linear transition from the previous global a-variable to the new one, so to "hide" eventual abrupt changes of those global variables by other threads.

P.S.: those sounds are very relaxing to listen to. :-)

Regards,
Mauro

Il 2018-10-28 16:20 Karin Daum ha scritto:

I just used problem.csd and replaced in instr 1000

clear gal
clear gar

by

gal=0
gar=0

The result is the same - you get the same distortions

cheers,

Karin

On 28 Oct 2018, at 15:49, jpff <jpff@CODEMIST.CO.UK> wrote:

The problem is your use of clear opcode which does not knowm that the input argument is actually an output one, so the partial orering is wrong. Replacing "clear gal" with "gal=0" should gfix it -- not tested.

Sorry about last message -- I did not see the csd file attached

Not sure how to fix clear.....

On Sun, 28 Oct 2018, Karin Daum wrote:

Hi,

Thanks to all developers for their continuous effort improving Csound!!!!

During a talk on the  symposium "Physics and Art[efacts]" held recently at Berlin I was wondering: What is the "Sound of Life" (DNA)? So I started to play with it and I'm thinking about some large Multimedia-Project. For the sound this is quite CPU consuming, especially if many instruments play simultaneously. Currently I'm using a single csd, which converts the nucleotides to pitch-values, which schedules the instruments and produces the output. Whenever the scheduling instrument starts to schedule the next couple of notes to be played you hear a click because the single CPU reaches 100%. Rendering to a file would not be an option (see below). Therefore, I thought multithreading would be a solution.

I have problems using multithreading. In the version 6.09 I was using until today multithreading resulted segmentation violations. Therefore, I just changed to Csound 6.12. In this version '-j N' does not produce segmentation violation anymore. That's good news. However, multithreading produces some noise on output, both when rendering to file or when playing in CsoundQT. The noise depends on the choice of ksmps.

I have three short test files attached:

     FOXP2OneThread.mp3 which is produce without '-j N'
     FOXP2TwoThredsKSMPS8.mp3 with -j 2 and ksmps=8
     FOXP2TwoThredsKSMPS128.mp3 with -j 2 and ksmps=128

(this is a simple attempt of a sonification of the human gene FOXP2, which is responsible for our ability to speak. These are only the very first few nucleotides of this gene:

AGACAGCGCGAGCCTCCGAGAAAGCGCGAGACACGCCGGCGCGTGCAGCTCCGCGGCCGCCGCTTCGCCC
TAGCTCTAGCCCCGCGCCACCCGCAGCCCGCCCGCGAACGCCCGCCCCGGTTATTTATGCGGCGGCCGCG
TCCGCTGGCTGCGGCTTCCTCGGCCCCCCCCCTCCCCGGGCGCGCCCCCCACTCGCGGCAGCAGCTGCCC

Playing the complete FOXP2 gene takes about 8 hours and the complete human genome would take about 10 to 12 years. )

I checked that the noise is also present on files produced using -j 2 with 6.10 and 6.11

I think I found the problem. It is related to the fact that I'm using global variables gal, gar for summing up the outputs from from the different instruments, which is then rendered/output with reverberation by a special instrument. I've attached a small csd-file (problem.csd), which can be used to verify the problem. Here a simple oscillator (instr 1) is used to "fill" the variables gal, gar which is then rendered by instr 1000, which also does the reverberation.

Is there a proposal, to avoid this problem by summing up the signals from the individual instruments in a different way?

Regards,

Karin

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

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