bolprocessor-devel — Bol Processor developer discussion list

[bp-dev] Automatic relocation of Csound resources

[Bernard B. <ber...@gm...>]

Dear all,

The PHP interface now does an automatic relocation to the (automatically 
created) folder "csound_resources" of Csound orchestra files contained 
in the work folder. This includes all related files — the ones used by 
GEN01, GEN23, GEN28 and GEN48, read 
https://www.csounds.com/manual/html/ScoreGenRef.html

Relocating all files is important because if a single one is missing 
Csound will generally produce a silent sound file and this error is 
uneasy to trace.

The interface also checks whether Csound is installed and "responsive", 
i.e. returning messages when called by a command line.

I am enclosing a screenshot of the top of a grammar showing that all 
relevant parameters are listed…

Bernard

Re: [bp-dev] New Csound orchestra

[Bernard B. <ber...@gm...>]

Now this fade-out time is added to Csound scores.  I tried it with 
-gr.Mozart, using the "0-default.orc". It sounds good! Better if 
preceded with "_transpose(-18)".

I also updated the interface, automatically creating "csound_resources" 
folder and moving orchestra files into it.

Bernard

Anthony Kozar wrote on 11/11/2020 19:57:
> Dear Bernard,
>
> Thanks for offering to modify the fade out option for Csound.  I made 
> a mistake in my example of saying that the end time should be in 
> seconds.  This is wrong, the time supplied to "e" should be in beats.  
> So, it would be necessary to multiply the fade out time by a factor 
> based on the metronome setting except for another reason (see below).
>
> I just did a quick check to make sure that the effects instruments 
> will work over multiple sections and it seems that they do without 
> gaps.  So, yes, the correct thing to do is to add time only to the 
> final section via the "e" statement.
>
> It seems like BP2 always writes an "s" statement after each section 
> and an "e" following the final "s".  Technically, this is not 
> necessary as it creates an extra section of zero length.  But we might 
> leave it as is.  At the beginning of each section, the tempo resets to 
> mm=60 and the beat count resets to 0.  So, if BP3 continues to write 
> an "s" statement after the final notes, then the "extra" section can 
> consist only of the fade out time which can be specified then in 
> seconds because the tempo will be 60.
>
> So, for example, with a fade out time of 2 seconds (which seems to be 
> adequate for the default orchestra), the score should just end with
>
> s
> e 2.000
>
> Anthony
>
>
> On 11/11/20, 12:14 PM, Bernard Bel wrote:
>> Dear Anthony,
>>
>> I looked at the code of this orchestra file which you documented with so
>> much care! Tomorrow I will try it for good and reorganize the location
>> of Csound "resources" as suggested in my previous message.
>>
>> Yes, the "fade-out" time can be used very easily to modify the "s" or
>> "e" statement. I'll do it also tomorrow. I believe it is better to
>> modify "e" because in the Improvize mode (creating a score of 10 items)
>> we string together all items and should not break the tempo.
>>
>> I'll try -gr.Mozart with a plucked-string instrument which should sound
>> way better than crude sinewaves…
>>
>> Bernard
>>
>> Anthony Kozar wrote on 11/11/2020 17:18:
>
>>> So, for example, if the last note ends at 100 seconds and the fade out
>>> time is 2 seconds, then BP3 should write
>>>
>>> s 102
>>>    or
>>> e 102
>>>
>>> at the end of the score.
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] New Csound orchestra

[Bernard B. <ber...@gm...>]

Very good, I'll program it this way. :-)

Bernard

Anthony Kozar wrote on 11/11/2020 19:57:
> Dear Bernard,
>
> Thanks for offering to modify the fade out option for Csound.  I made 
> a mistake in my example of saying that the end time should be in 
> seconds.  This is wrong, the time supplied to "e" should be in beats.  
> So, it would be necessary to multiply the fade out time by a factor 
> based on the metronome setting except for another reason (see below).
>
> I just did a quick check to make sure that the effects instruments 
> will work over multiple sections and it seems that they do without 
> gaps.  So, yes, the correct thing to do is to add time only to the 
> final section via the "e" statement.
>
> It seems like BP2 always writes an "s" statement after each section 
> and an "e" following the final "s".  Technically, this is not 
> necessary as it creates an extra section of zero length.  But we might 
> leave it as is.  At the beginning of each section, the tempo resets to 
> mm=60 and the beat count resets to 0.  So, if BP3 continues to write 
> an "s" statement after the final notes, then the "extra" section can 
> consist only of the fade out time which can be specified then in 
> seconds because the tempo will be 60.
>
> So, for example, with a fade out time of 2 seconds (which seems to be 
> adequate for the default orchestra), the score should just end with
>
> s
> e 2.000
>
> Anthony
>
>
> On 11/11/20, 12:14 PM, Bernard Bel wrote:
>> Dear Anthony,
>>
>> I looked at the code of this orchestra file which you documented with so
>> much care! Tomorrow I will try it for good and reorganize the location
>> of Csound "resources" as suggested in my previous message.
>>
>> Yes, the "fade-out" time can be used very easily to modify the "s" or
>> "e" statement. I'll do it also tomorrow. I believe it is better to
>> modify "e" because in the Improvize mode (creating a score of 10 items)
>> we string together all items and should not break the tempo.
>>
>> I'll try -gr.Mozart with a plucked-string instrument which should sound
>> way better than crude sinewaves…
>>
>> Bernard
>>
>> Anthony Kozar wrote on 11/11/2020 17:18:
>
>>> So, for example, if the last note ends at 100 seconds and the fade out
>>> time is 2 seconds, then BP3 should write
>>>
>>> s 102
>>>    or
>>> e 102
>>>
>>> at the end of the score.
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] New Csound orchestra

[Anthony K. <mai...@an...>]

Dear Bernard,

Thanks for offering to modify the fade out option for Csound.  I made a 
mistake in my example of saying that the end time should be in seconds. 
  This is wrong, the time supplied to "e" should be in beats.  So, it 
would be necessary to multiply the fade out time by a factor based on 
the metronome setting except for another reason (see below).

I just did a quick check to make sure that the effects instruments will 
work over multiple sections and it seems that they do without gaps.  So, 
yes, the correct thing to do is to add time only to the final section 
via the "e" statement.

It seems like BP2 always writes an "s" statement after each section and 
an "e" following the final "s".  Technically, this is not necessary as 
it creates an extra section of zero length.  But we might leave it as 
is.  At the beginning of each section, the tempo resets to mm=60 and the 
beat count resets to 0.  So, if BP3 continues to write an "s" statement 
after the final notes, then the "extra" section can consist only of the 
fade out time which can be specified then in seconds because the tempo 
will be 60.

So, for example, with a fade out time of 2 seconds (which seems to be 
adequate for the default orchestra), the score should just end with

s
e 2.000

Anthony


On 11/11/20, 12:14 PM, Bernard Bel wrote:
> Dear Anthony,
>
> I looked at the code of this orchestra file which you documented with so
> much care! Tomorrow I will try it for good and reorganize the location
> of Csound "resources" as suggested in my previous message.
>
> Yes, the "fade-out" time can be used very easily to modify the "s" or
> "e" statement. I'll do it also tomorrow. I believe it is better to
> modify "e" because in the Improvize mode (creating a score of 10 items)
> we string together all items and should not break the tempo.
>
> I'll try -gr.Mozart with a plucked-string instrument which should sound
> way better than crude sinewaves…
>
> Bernard
>
> Anthony Kozar wrote on 11/11/2020 17:18:

>> So, for example, if the last note ends at 100 seconds and the fade out
>> time is 2 seconds, then BP3 should write
>>
>> s 102
>>    or
>> e 102
>>
>> at the end of the score.

Re: [bp-dev] New Csound orchestra

[Bernard B. <ber...@gm...>]

Dear Anthony,

I looked at the code of this orchestra file which you documented with so 
much care! Tomorrow I will try it for good and reorganize the location 
of Csound "resources" as suggested in my previous message.

Yes, the "fade-out" time can be used very easily to modify the "s" or 
"e" statement. I'll do it also tomorrow. I believe it is better to 
modify "e" because in the Improvize mode (creating a score of 10 items) 
we string together all items and should not break the tempo.

I'll try -gr.Mozart with a plucked-string instrument which should sound 
way better than crude sinewaves…

Bernard

Anthony Kozar wrote on 11/11/2020 17:18:
> Hello everyone,
>
> I'm attaching an early version of a new default orchestra.  It 
> contains the following instruments and effects.
>
> ; Instruments:
> ;    1    Plucked string (outputs to StereoDelay)
> ;    10    Sine wave (outputs to GlobalReverb)
> ;
> ; Effects:
> ;    StereoDelay (outputs to GlobalReverb)
> ;    GlobalReverb (outputs to file/speakers)
>
>
> Even though both of the instruments are incredibly simplistic, they 
> already sound better due to the application of the sound effects 
> (particularly the plucked string)(*).  I discovered that Csound now 
> has an easy way to turn on effects instruments from the orchestra for 
> the entire duration of the performance.  This avoids having to add 
> i-statements to the score for them which simplifies things 
> considerably for BP users.
>
> The only problem is that these instruments are shut off immediately 
> after the last note ends which cuts off the tail of delay-based 
> effects like reverberation.  We need a way in BP3 to extend the 
> performance by a few seconds (preferably user-specified) at the end.  
> I'm thinking that the "fade out" option could be used for this.  
> Csound does allow the score to have an arbitrary end time specified by 
> the "s" or "e" statement in the score.
>
> So, for example, if the last note ends at 100 seconds and the fade out 
> time is 2 seconds, then BP3 should write
>
> s 102
>    or
> e 102
>
> at the end of the score.
>
> I'm still planning to add several more instruments to this orchestra.
>
> Anthony
>
> (*) I also fixed a problem with the old sine wave instrument that 
> caused discontinuities (audible "clicks") at the end of notes.
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] New Csound orchestra

[Anthony K. <mai...@an...>]

Hello everyone,

I'm attaching an early version of a new default orchestra.  It contains 
the following instruments and effects.

; Instruments:
;	1	Plucked string (outputs to StereoDelay)
;	10	Sine wave (outputs to GlobalReverb)
;
; Effects:
;	StereoDelay (outputs to GlobalReverb)
;	GlobalReverb (outputs to file/speakers)


Even though both of the instruments are incredibly simplistic, they 
already sound better due to the application of the sound effects 
(particularly the plucked string)(*).  I discovered that Csound now has 
an easy way to turn on effects instruments from the orchestra for the 
entire duration of the performance.  This avoids having to add 
i-statements to the score for them which simplifies things considerably 
for BP users.

The only problem is that these instruments are shut off immediately 
after the last note ends which cuts off the tail of delay-based effects 
like reverberation.  We need a way in BP3 to extend the performance by a 
few seconds (preferably user-specified) at the end.  I'm thinking that 
the "fade out" option could be used for this.  Csound does allow the 
score to have an arbitrary end time specified by the "s" or "e" 
statement in the score.

So, for example, if the last note ends at 100 seconds and the fade out 
time is 2 seconds, then BP3 should write

s 102
    or
e 102

at the end of the score.

I'm still planning to add several more instruments to this orchestra.

Anthony

(*) I also fixed a problem with the old sine wave instrument that caused 
discontinuities (audible "clicks") at the end of notes.

[bp-dev] Fixed SetVariation() (ctd)

[Bernard B. <ber...@gm...>]

Today I looked in greater detail at the algorithm in function 
SetVariation(), a complicated one that is building tables of values of 
parameters (MIDI or Csound) varying stepwise or continuously. I checked 
it on a very simple example, trying many combinations of parameter 
assignments. In this process I discovered a bug that would happen in 
rare cases and remain unnnoticed. It was the calculation of a table 
called "p_NumberConstant"… I fixed it and uploaded the revised version.

I am now going to work on the interface so that all Csound orchestra 
files can be stored in a single folder named for instance 
"csound_resources". In the current version, the orchestra file should be 
in the same folder as the grammar, which is a silly constraint because 
we should not need to duplicate or move orchestra files!

At present, the name of the orchestra file is stored in the settings 
file of a grammar. This makes it easy to attach an orchestra to a 
project even if no Csound instruments file is used. By default the 
machine calls "default.orc".

Bernard

---------

Dear all,

I spent the whole day trying to solve a crash happening about once in 
ten times when producing the Csound score of -gr.vina3. This required 
putting dozen of trace messages and comparing the good and bad output.

Looking carefully at the production I remembered having faced this 
problem in the last century. The issue is the building of a Csound table 
setting up variations of a continuous parameter. In this example the 
parameter is called "slide".

At the end of the piece we have approximately this:

_cont(slide) _value(slide,0) C#3 _value(slide,-101) _ _fixed(slide) B2

The problem is that the machine cannot guess the final value of "slide". 
We should have a _value(slide,xxx) at the end of the piece. This may be 
seen as a syntactic error but I believe it is more clever to assume that 
this final value, if not specified, should be the default value of "slide".

The problem remains to get this default value. Parameters may be 
additive or multiplicative with default values respectively "0" or "1".

For the time being I used "0" in this situation, but I will try to pick 
up the real default value. At least, this example no longer crashes!

We'll probably face similar problems when dealing with continuous 
parameters when the score lacks accuracy or consistency. But experiments 
should help stabilizing solutions by compensating design errors.

Hunting for bugs in the "CsoundMath.c" file is a real headache! ;-)

Bernard

[bp-dev] Fixed SetVariation()

[Bernard B. <ber...@gm...>]

Dear all,

I spent the whole day trying to solve a crash happening about once in 
ten times when producing the Csound score of -gr.vina3. This required 
putting dozen of trace messages and comparing the good and bad output.

Looking carefully at the production I remembered having faced this 
problem in the last century. The issue is the building of a Csound table 
setting up variations of a continuous parameter. In this example the 
parameter is called "slide".

At the end of the piece we have approximately this:

_cont(slide) _value(slide,0) C#3 _value(slide,-101) _ _fixed(slide) B2

The problem is that the machine cannot guess the final value of "slide". 
We should have a _value(slide,xxx) at the end of the piece. This may be 
seen as a syntactic error but I believe it is more clever to assume that 
this final value, if not specified, should be the default value of "slide".

The problem remains to get this default value. Parameters may be 
additive or multiplicative with default values respectively "0" or "1".

For the time being I used "0" in this situation, but I will try to pick 
up the real default value. At least, this example no longer crashes!

We'll probably face similar problems when dealing with continuous 
parameters when the score lacks accuracy or consistency. But experiments 
should help stabilizing solutions by compensating design errors.

Hunting for bugs in the "CsoundMath.c" file is a real headache! ;-)

Bernard

Re: [bp-dev] Csound tuning?

[Bernard B. <ber...@gm...>]

Wonderful idea! I believe that the weakness of our Csound documentation 
is that many examples don't have sound renderings - except perhaps 
Kumar's Sarasvati vina, which is still perfectible regarding tonal 
intervals.

Whenever an event is encoded as a i-statement it should be possible to 
handle it with BP. Even now we could create Csound objects whose score 
is the unique statement of an effect, to switch it on or off.

I am also planning to work again on microtonality. Dealing with indices 
peeking numbers in a frequency ratio table is a good approach because it 
makes it possible to construct scales with more than 12 divisions per 
octave. We could for instance create a scale of 22 intervals to deal 
with the intonation of Indian music or "just intonation" in Western 
music. Grammars could contain rules for selecting enharmonic positions 
on the basis of the harmonic or modal context… This brings me back to 
work in the early 1980s (https://hal.archives-ouvertes.fr/hal-00373725) ;-)

I updated the code for taking into account the setting of the C4 key 
number — which actually has no influence on Csound scores/sound output, 
see https://bolprocessor.org/csound-tuning/

I'll be delighted to hear more Csound instruments. I remember a guitar 
sound that sounded amazing, very short in terms of code, but I have lost 
the instrument… While looking for it I found an old exchange of mail 
with Barry Vercoe (dated 1993) in which he was telling: "I sense that 
your BP2 software and Csound will move closer in the near future." 
Right! :-)

Bernard

Anthony Kozar wrote on 09/11/2020 01:28:
> I'm planning to work tonight on some new instruments using the default 
> BP parameters.  I'm hoping to create some "musical" instruments along 
> the lines of synth strings, synth brass, plucked string, bells, organ, 
> etc.
>
> One thing that would really help the instruments sound better would 
> some reverberation and other effects.  These are usually implemented 
> in Csound as instruments with a single i-statement that lasts the 
> entire performance.  I'm not sure whether Bol Processor has a good way 
> to handle this automatically though.  (Could be a good idea for a new 
> feature).
>
> Anthony
>
>
> On 11/8/20, 4:34 PM, Bernard Bel wrote:
>> Very good!
>>
>> At first view, modifying "default.orc" is probably the best idea. It
>> would be easy to instruct BP to use cps whenever A4 is not 440 Hz.
>>
>> In the same time, it would be good to have a better sound quality on the
>> default instrument, for instance a sawtooth waveform…
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Csound tuning?

[Bernard B. <ber...@gm...>]

Done and pushed. :-)

Just 2 lines of code, but it will take more time updating the 
documentation (https://bolprocessor.org/csound-objects/)!

Bernard

--------

This works! I am enclosing the updated "default.orc".

Now working on the minor change to deal with A4 != 440 in the console…

Bernard

Anthony Kozar wrote on 08/11/2020 21:16:
> Since an octave point pitch-class of 15.00 and an octave point decimal 
> pitch value of 15.0 represent a C seven octaves above middle C having 
> a frequency > 32000 Hz and there is rarely a reason to use a pitch 
> lower than 15.0 Hz, the Csound instrument can interpret pitch values < 
> 15.0 with cpspch() or cpsoct() and assume higher values are cps.  
> Something like this should do (but I haven't tested it):
>
> if (p4 < 15.0) then
>    icps = cpspch(p4)
> else
>    icps = p4
> endif

Re: [bp-dev] Csound tuning?

[Bernard B. <ber...@gm...>]

This works! I am enclosing the updated "default.orc".

Now working on the minor change to deal with A4 != 440 in the console…

Bernard

Anthony Kozar wrote on 08/11/2020 21:16:
> Since an octave point pitch-class of 15.00 and an octave point decimal 
> pitch value of 15.0 represent a C seven octaves above middle C having a 
> frequency > 32000 Hz and there is rarely a reason to use a pitch lower 
> than 15.0 Hz, the Csound instrument can interpret pitch values < 15.0 
> with cpspch() or cpsoct() and assume higher values are cps.  Something 
> like this should do (but I haven't tested it):
> 
> if (p4 < 15.0) then
>    icps = cpspch(p4)
> else
>    icps = p4
> endif

Re: [bp-dev] Csound tuning?

[Anthony K. <mai...@an...>]

I'm planning to work tonight on some new instruments using the default 
BP parameters.  I'm hoping to create some "musical" instruments along 
the lines of synth strings, synth brass, plucked string, bells, organ, etc.

One thing that would really help the instruments sound better would some 
reverberation and other effects.  These are usually implemented in 
Csound as instruments with a single i-statement that lasts the entire 
performance.  I'm not sure whether Bol Processor has a good way to 
handle this automatically though.  (Could be a good idea for a new feature).

Anthony


On 11/8/20, 4:34 PM, Bernard Bel wrote:
> Very good!
>
> At first view, modifying "default.orc" is probably the best idea. It
> would be easy to instruct BP to use cps whenever A4 is not 440 Hz.
>
> In the same time, it would be good to have a better sound quality on the
> default instrument, for instance a sawtooth waveform…
>
> Bernard

Re: [bp-dev] Csound tuning?

[Bernard B. <ber...@gm...>]

Very good!

At first view, modifying "default.orc" is probably the best idea. It 
would be easy to instruct BP to use cps whenever A4 is not 440 Hz.

In the same time, it would be good to have a better sound quality on the 
default instrument, for instance a sawtooth waveform…

Bernard


Anthony Kozar wrote on 08/11/2020 21:16:
> Using an f-table with cpstuni is one possibility.  But the pitch for 
> each note would have to be passed as an integer index (e.g. MIDI note 
> number).  That doesn't appear to be an option in BP2 right now (?), 
> although it would be easy to add.
>
> Csound 6.08 and later support changing the diapason with the A4 global 
> variable.  The value of A4 is used by orchestra functions like cpspch 
> & cpsoct.
>
> https://csound.com/docs/manual/A4.html
>
> However, A4 must be set at the top of the orchestra similarly to sr, 
> kr, etc.  And I don't see any way that it can be changed by the score 
> after the orchestra is initialized.  It would be possible to add an 
> instrument to the orchestra specifically for setting the diapason via 
> a global k-rate variable.  All other instruments would have to use 
> that value then.  For example,
>
> ; in the header section
> gkA4 = 440.0
>
> instr 1 ; set the diapason
>   gkA4 = p4
> endin
>
> instr 2 ; normal instrument
>   kcps = cpspch(p4) + (gkA4 - 440.0)
>   ...
>   kpitch = kcps * exp(kcents * ik2)
>   ...
> endin
>
> ; in the Csound score
> i1 0 0 415.0  ; use Baroque pitch
> i2 ...
> i2 ...
>
> I _think_ Csound runs instruments in instrument # order so it would 
> probably be best if the diapason instrument has a # less than all of 
> the others.
>
> It might be best though to advise users to have BP output pitch as 
> frequencies in cps/Hz when the tuning is not 440 Hz.  The default 
> orchestra could be modified to support both cps and octave point 
> pitch-class/decimal in a reasonable way.
>
> Since an octave point pitch-class of 15.00 and an octave point decimal 
> pitch value of 15.0 represent a C seven octaves above middle C having 
> a frequency > 32000 Hz and there is rarely a reason to use a pitch 
> lower than 15.0 Hz, the Csound instrument can interpret pitch values < 
> 15.0 with cpspch() or cpsoct() and assume higher values are cps.  
> Something like this should do (but I haven't tested it):
>
> if (p4 < 15.0) then
>   icps = cpspch(p4)
> else
>   icps = p4
> endif
>
> ...
>
> pitchbendlin: kpitch = icps * exp(kcents * ik2)
>
> Anthony
>
>
> On 11/8/20, 9:44 AM, Bernard Bel wrote:
>> Dear all,
>>
>> At the end of the documentation of -gr.Mozart
>> (https://bolprocessor.org/mozarts-musical-dice-game/) I raised the issue
>> of the diapason. By default, A4 = 440Hz both in MIDI and Csound
>> productions, the latter using the cpspch() function in the "default.orc"
>> orchestra.
>>
>> In other words, entering a different frequency of A4 on the Settings
>> page does not modify the output. Things are only different when calling
>> a Csound instrument whose pitch argument is in the "cps" format.
>>
>> All fine, but I guess there is a way of changing this 440 Hz value, and
>> it might be done by putting an appropriate "f1" line on top of the
>> score, as indicated on page http://csounds.com/manual/html/cpstuni.html
>>
>> Thus, to set the diapason to 435 Hz and an equally-tempered scale we
>> should perhaps insert:
>>
>> f1 0 64 -2 12 2 435 69 1 1.059 1.122 1.189 1.260 1.335 1.414 1.498 1.588
>> 1.682 1.782 1.888 2.000
>>
>> If this is correct, how should we instruct "default.orc" to use this
>> table for its cpspch() conversions?
>>
>> It is an exciting challenge because BP would gain in being able to
>> control more parameters of the Csound devices…
>>
>> Bernard
>>
>> PS. The "default.orc" orchestra file:
>>
>> ----------
>> ; This is a simple orchestra file for Bol Processor's default Csound
>> score output
>>
>> ; It contains one single instrument: an oscillator using wave-table 1
>> ; Argument p2 is the start date, p3 the duration (as per the standard)
>> ; Argument p4 is the pitch in octave point pitch-class format
>> ; Volume (range 0..127) is supplied by performance control _volume()
>> ; to arguments p5 (beginning value) and p6 (end value), or via the table
>> ; whose index is supplied by p7.
>> ; Pitchbend is supplied in cents to arguments p8 (beginning value)
>> ; and p9 (end value), or via the table whose index is supplied by p10.
>>
>> sr = 22050
>> kr = 2205
>> ksmps = 10
>> nchnls = 1
>>
>> instr 1
>>
>> ik1 = 32767. / 127.
>> ik2 = log(2.) / 1200.
>>
>> ifvol = p7
>> ifcents = p10
>>
>> kvol line p5, p3, p6
>> if (ifvol <= 0) goto volumelin
>> ilenvol = ftlen(ifvol)
>> kndxvol line 0, p3, ilenvol
>> kvol tablei kndxvol, ifvol
>>
>> volumelin: kcents line p8, p3, p9
>> if (ifcents <= 0) goto pitchbendlin
>> ilencents = ftlen(ifcents)
>> kndxcents line 0, p3, ilencents
>> kcents tablei kndxcents, ifcents
>>
>> pitchbendlin: kpitch = cpspch(p4) * exp(kcents * ik2)
>> kamp = kvol * ik1
>>
>> a1 oscil kamp, kpitch, 1
>> out a1 * 0.1
>> endin
>> ---------
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Csound tuning?

[Anthony K. <mai...@an...>]

Using an f-table with cpstuni is one possibility.  But the pitch for 
each note would have to be passed as an integer index (e.g. MIDI note 
number).  That doesn't appear to be an option in BP2 right now (?), 
although it would be easy to add.

Csound 6.08 and later support changing the diapason with the A4 global 
variable.  The value of A4 is used by orchestra functions like cpspch & 
cpsoct.

https://csound.com/docs/manual/A4.html

However, A4 must be set at the top of the orchestra similarly to sr, kr, 
etc.  And I don't see any way that it can be changed by the score after 
the orchestra is initialized.  It would be possible to add an instrument 
to the orchestra specifically for setting the diapason via a global 
k-rate variable.  All other instruments would have to use that value 
then.  For example,

; in the header section
gkA4 = 440.0

instr 1 ; set the diapason
   gkA4 = p4
endin

instr 2 ; normal instrument
   kcps = cpspch(p4) + (gkA4 - 440.0)
   ...
   kpitch = kcps * exp(kcents * ik2)
   ...
endin

; in the Csound score
i1 0 0 415.0  ; use Baroque pitch
i2 ...
i2 ...

I _think_ Csound runs instruments in instrument # order so it would 
probably be best if the diapason instrument has a # less than all of the 
others.

It might be best though to advise users to have BP output pitch as 
frequencies in cps/Hz when the tuning is not 440 Hz.  The default 
orchestra could be modified to support both cps and octave point 
pitch-class/decimal in a reasonable way.

Since an octave point pitch-class of 15.00 and an octave point decimal 
pitch value of 15.0 represent a C seven octaves above middle C having a 
frequency > 32000 Hz and there is rarely a reason to use a pitch lower 
than 15.0 Hz, the Csound instrument can interpret pitch values < 15.0 
with cpspch() or cpsoct() and assume higher values are cps.  Something 
like this should do (but I haven't tested it):

if (p4 < 15.0) then
   icps = cpspch(p4)
else
   icps = p4
endif

...

pitchbendlin: kpitch = icps * exp(kcents * ik2)

Anthony


On 11/8/20, 9:44 AM, Bernard Bel wrote:
> Dear all,
>
> At the end of the documentation of -gr.Mozart
> (https://bolprocessor.org/mozarts-musical-dice-game/) I raised the issue
> of the diapason. By default, A4 = 440Hz both in MIDI and Csound
> productions, the latter using the cpspch() function in the "default.orc"
> orchestra.
>
> In other words, entering a different frequency of A4 on the Settings
> page does not modify the output. Things are only different when calling
> a Csound instrument whose pitch argument is in the "cps" format.
>
> All fine, but I guess there is a way of changing this 440 Hz value, and
> it might be done by putting an appropriate "f1" line on top of the
> score, as indicated on page http://csounds.com/manual/html/cpstuni.html
>
> Thus, to set the diapason to 435 Hz and an equally-tempered scale we
> should perhaps insert:
>
> f1 0 64 -2 12 2 435 69 1 1.059 1.122 1.189 1.260 1.335 1.414 1.498 1.588
> 1.682 1.782 1.888 2.000
>
> If this is correct, how should we instruct "default.orc" to use this
> table for its cpspch() conversions?
>
> It is an exciting challenge because BP would gain in being able to
> control more parameters of the Csound devices…
>
> Bernard
>
> PS. The "default.orc" orchestra file:
>
> ----------
> ; This is a simple orchestra file for Bol Processor's default Csound
> score output
>
> ; It contains one single instrument: an oscillator using wave-table 1
> ; Argument p2 is the start date, p3 the duration (as per the standard)
> ; Argument p4 is the pitch in octave point pitch-class format
> ; Volume (range 0..127) is supplied by performance control _volume()
> ; to arguments p5 (beginning value) and p6 (end value), or via the table
> ; whose index is supplied by p7.
> ; Pitchbend is supplied in cents to arguments p8 (beginning value)
> ; and p9 (end value), or via the table whose index is supplied by p10.
>
> sr = 22050
> kr = 2205
> ksmps = 10
> nchnls = 1
>
> instr 1
>
> ik1 = 32767. / 127.
> ik2 = log(2.) / 1200.
>
> ifvol = p7
> ifcents = p10
>
> kvol line p5, p3, p6
> if (ifvol <= 0) goto volumelin
> ilenvol = ftlen(ifvol)
> kndxvol line 0, p3, ilenvol
> kvol tablei kndxvol, ifvol
>
> volumelin: kcents line p8, p3, p9
> if (ifcents <= 0) goto pitchbendlin
> ilencents = ftlen(ifcents)
> kndxcents line 0, p3, ilencents
> kcents tablei kndxcents, ifcents
>
> pitchbendlin: kpitch = cpspch(p4) * exp(kcents * ik2)
> kamp = kvol * ik1
>
> a1 oscil kamp, kpitch, 1
> out a1 * 0.1
> endin
> ---------

[bp-dev] Csound tuning?

[Bernard B. <ber...@gm...>]

Dear all,

At the end of the documentation of -gr.Mozart 
(https://bolprocessor.org/mozarts-musical-dice-game/) I raised the issue 
of the diapason. By default, A4 = 440Hz both in MIDI and Csound 
productions, the latter using the cpspch() function in the "default.orc" 
orchestra.

In other words, entering a different frequency of A4 on the Settings 
page does not modify the output. Things are only different when calling 
a Csound instrument whose pitch argument is in the "cps" format.

All fine, but I guess there is a way of changing this 440 Hz value, and 
it might be done by putting an appropriate "f1" line on top of the 
score, as indicated on page http://csounds.com/manual/html/cpstuni.html

Thus, to set the diapason to 435 Hz and an equally-tempered scale we 
should perhaps insert:

f1 0 64 -2 12 2 435 69 1 1.059 1.122 1.189 1.260 1.335 1.414 1.498 1.588 
1.682 1.782 1.888 2.000

If this is correct, how should we instruct "default.orc" to use this 
table for its cpspch() conversions?

It is an exciting challenge because BP would gain in being able to 
control more parameters of the Csound devices…

Bernard

PS. The "default.orc" orchestra file:

----------
; This is a simple orchestra file for Bol Processor's default Csound 
score output

; It contains one single instrument: an oscillator using wave-table 1
; Argument p2 is the start date, p3 the duration (as per the standard)
; Argument p4 is the pitch in octave point pitch-class format
; Volume (range 0..127) is supplied by performance control _volume()
; to arguments p5 (beginning value) and p6 (end value), or via the table
; whose index is supplied by p7.
; Pitchbend is supplied in cents to arguments p8 (beginning value)
; and p9 (end value), or via the table whose index is supplied by p10.

sr = 22050
kr = 2205
ksmps = 10
nchnls = 1

instr 1

ik1 = 32767. / 127.
ik2 = log(2.) / 1200.

ifvol = p7
ifcents = p10

kvol line p5, p3, p6
if (ifvol <= 0) goto volumelin
ilenvol = ftlen(ifvol)
kndxvol line 0, p3, ilenvol
kvol tablei kndxvol, ifvol

volumelin: kcents line p8, p3, p9
if (ifcents <= 0) goto pitchbendlin
ilencents = ftlen(ifcents)
kndxcents line 0, p3, ilencents
kcents tablei kndxcents, ifcents

pitchbendlin: kpitch = cpspch(p4) * exp(kcents * ik2)
kamp = kvol * ik1

a1 oscil kamp, kpitch, 1
out a1 * 0.1
endin
---------

[bp-dev] Many small improvements

[Bernard B. <ber...@gm...>]

Dear all,

I spent a long time (even a whole night) programming while listening to 
TV news. Anxiety is a drive for my neurones. And it seems that things 
are getting "fixed"… :-)

Changes of BP are summarized in many commits, both console and interface.

The main issue has been the control of "emergency exit" when computation 
time exceeds a given limit set by the settings. Setting it to 10 seconds 
is fair but it can be increased if a time-out message is returned.

Improvize mode is now accepted, except that in the absence of real-time 
MIDI it only creates 10 items. So, you can "improvize" to a MIDI file or 
a Csound score. If a grammar is using substitutions, such as typically 
-gr.koto3, and if "Use each substitution" is selected, then it will also 
play/display the intermediary workstrings in addition to the 10 final items.

Seeding the random sequence is apparently satisfactory. If seed = 0 then 
a new sequence will be created each time, otherwise we get a repetition 
of a sequence which depends on the seed value.

The machine crops images if their height or width exceeds 32767 which is 
a limit for CANVAS.

I carefully studied the creation of Cscores as described on the site, 
including cases starting on a negative date (because of a displaced 
pivot) which force the machine to shift the background blue lines on the 
pianoroll.

Finally I started trying many old grammars used for drumming or unusual 
situations such as "negative context", "destruction of structure" etc. 
This forced me to spend time in the core mechanism and fix details. All 
examples I used have been pushed to the "ctests" folder. I will probably 
use a few of them for the documentation.

In this process I became aware of the immense amount of work 
accomplished by Anthony while upgrading to MacOS X and creating the 
console version! It was a great challenge, and we now benefit from this 
very neat work. Pending issues are also documented in the code which we 
certainly will examine in great detail "when time permits".

Anxiety is a bit less and I will take rest. :-)

All the best!

Bernard

Re: [bp-dev] MIDI data consistency

[Bernard B. <ber...@gm...>]

The problem is now solved both onn the console and the interface.

I also checked the case of sound-objects truncated in the beginninng. 
During the truncation we shouldn't send any NoteOn nor NoteOffs. However 
we still send channel messages : controllers, switches etc., because the 
only requirement of a truncation is to suppress notes… It works fine 
both in MIDI and Csound.

I started building a set of sound-objects and a grammar for specifically 
checking unusual issues. I will document it and share it when it gets 
more elaborate. I dream of the days when a script was running for 30 
minutes checking all features and returning a diagnosis both in text and 
sound. ;-)

Finally, I modified the creation of random sequences at startup. If the 
seed is positive it will set the sequence to start always from the same 
number. If seed = 0 it will be unpredictable. This makes it easy to 
produce sets of variations of -gr.Mozart which nobody ever listened to 
and will never be played again ;-)

Bernard

---------

Dear Anthony,

This makes everything clear and consistent with the reference guide I am 
enclosing (page 11). The problem with those "guides" is that they don't 
give a single example and I had been unsuccessful searching the web for 
examples or discussions. MIDI format is an old forgotten topic except 
for the ones who had picked it up correctly at a young age! ;-)

My confusion was strengthened by MF2T code. For instance this is the 
beginning of an imported MIDI file (created by BP3):

MTrk
0 Par ch=1 c=7 v=90
0 Par ch=1 c=10 v=64
0 Pb ch=1 v=8191
0 ChPr ch=1 v=0
0 Par ch=1 c=1 v=0
0 Par ch=1 c=33 v=0
0 On ch=1 n=108 v=120

"c=1" is the modulation which is set to "v=0". But then it tells that 
"c=33" is set to "v=0". Your explanation (and the guide) make it clear 
that "33" is the LSB of controller "33-32"!

In the old BP2.9.8 code we only took care of the LSB for Modulation, 
ignoring the one for Volume and Portamento. This is clear in function 
SendControl().

For this reason we see this "Par c=33" in the MF2T code, never c=39 nor 
c=42… It works, indeed, because MIDI devices are satisfied with range 0…127. 


I am now fixing the conversion of MF2T to strings of bytes in the 
interface, and will update the filter in FormatMIDIstream() using 
correct input data and paying attention to running status.

Thanks a lot for this clarification!

Bernard

Anthony Kozar wrote on 01/11/2020 21:47:
> Hmmm... this does not agree with my understanding of the MIDI spec.  I 
> thought all controller messages are 3 bytes long (2 bytes if running 
> status is used).  The first 32 controllers are paired with the second 
> 32 controllers so that when a pair is used in concert with one another 
> they form a 14-bit control signal.  The controllers between 0 and 31 
> carry the most-significant 7 bits (MSB) and the those between 32 and 
> 63 carry the least-significant 7 bits (LSB).  I think the spec is 
> supposed to require two control changes messages with paired 
> controller numbers to send a 14-bit value.  The system is flexible 
> because devices can send 
> and respond to only the MSB controllers and ignore the LSB ones.
>
> For example, a MIDI stream may contain the messages
>
> B0 01 40  Controller #1 (Mod Wheel MSB) value: 64
> B0 21 10  Controller #33 (Mod Wheel LSB) value: 16
> B0 01 40  Controller #1 (Mod Wheel MSB) value: 64
> B0 21 00  Controller #33 (Mod Wheel LSB) value: 0
>
> A device that recognizes 14-bit controllers would interpret this as 
> two Mod Wheel messages with values 8208 (0x2000) and 8192 (0x2010).  A 
> device that only recognizes 7-bit controllers would interpret it as 
> two Mod Wheel MSB messages with the same value of 64 (and might 
> interpret 
> the other messages as controller #33 changes with values 16 & 0 ??).
>
> At least, this is how I understand it to work.  You can send me the 
> MIDI files that are causing problems and I will take a look at them.
>
> Anthony

Re: [bp-dev] MIDI data consistency

[Bernard B. <ber...@gm...>]

Dear Anthony,

This makes everything clear and consistent with the reference guide I am 
enclosing (page 11). The problem with those "guides" is that they don't 
give a single example and I had been unsuccessful searching the web for 
examples or discussions. MIDI format is an old forgotten topic except 
for the ones who had picked it up correctly at a young age! ;-)

My confusion was strengthened by MF2T code. For instance this is the 
beginning of an imported MIDI file (created by BP3):

MTrk
0 Par ch=1 c=7 v=90
0 Par ch=1 c=10 v=64
0 Pb ch=1 v=8191
0 ChPr ch=1 v=0
0 Par ch=1 c=1 v=0
0 Par ch=1 c=33 v=0
0 On ch=1 n=108 v=120

"c=1" is the modulation which is set to "v=0". But then it tells that 
"c=33" is set to "v=0". Your explanation (and the guide) make it clear 
that "33" is the LSB of controller "33-32"!

In the old BP2.9.8 code we only took care of the LSB for Modulation, 
ignoring the one for Volume and Portamento. This is clear in function 
SendControl().

For this reason we see this "Par c=33" in the MF2T code, never c=39 nor 
c=42… It works, indeed, because MIDI devices are satisfied with range 0…127.

I am now fixing the conversion of MF2T to strings of bytes in the 
interface, and will update the filter in FormatMIDIstream() using 
correct input data and paying attention to running status.

Thanks a lot for this clarification!

Bernard

Anthony Kozar wrote on 01/11/2020 21:47:
> Hmmm... this does not agree with my understanding of the MIDI spec.  I 
> thought all controller messages are 3 bytes long (2 bytes if running 
> status is used).  The first 32 controllers are paired with the second 32 
> controllers so that when a pair is used in concert with one another they 
> form a 14-bit control signal.  The controllers between 0 and 31 carry 
> the most-significant 7 bits (MSB) and the those between 32 and 63 carry 
> the least-significant 7 bits (LSB).  I think the spec is supposed to 
> require two control changes messages with paired controller numbers to 
> send a 14-bit value.  The system is flexible because devices can send 
> and respond to only the MSB controllers and ignore the LSB ones.
> 
> For example, a MIDI stream may contain the messages
> 
> B0 01 40  Controller #1 (Mod Wheel MSB) value: 64
> B0 21 10  Controller #33 (Mod Wheel LSB) value: 16
> B0 01 40  Controller #1 (Mod Wheel MSB) value: 64
> B0 21 00  Controller #33 (Mod Wheel LSB) value: 0
> 
> A device that recognizes 14-bit controllers would interpret this as two 
> Mod Wheel messages with values 8208 (0x2000) and 8192 (0x2010).  A 
> device that only recognizes 7-bit controllers would interpret it as two 
> Mod Wheel MSB messages with the same value of 64 (and might interpret 
> the other messages as controller #33 changes with values 16 & 0 ??).
> 
> At least, this is how I understand it to work.  You can send me the MIDI 
> files that are causing problems and I will take a look at them.
> 
> Anthony

Re: [bp-dev] MIDI data consistency

[Anthony K. <mai...@an...>]

Hmmm... this does not agree with my understanding of the MIDI spec.  I 
thought all controller messages are 3 bytes long (2 bytes if running 
status is used).  The first 32 controllers are paired with the second 32 
controllers so that when a pair is used in concert with one another they 
form a 14-bit control signal.  The controllers between 0 and 31 carry 
the most-significant 7 bits (MSB) and the those between 32 and 63 carry 
the least-significant 7 bits (LSB).  I think the spec is supposed to 
require two control changes messages with paired controller numbers to 
send a 14-bit value.  The system is flexible because devices can send 
and respond to only the MSB controllers and ignore the LSB ones.

For example, a MIDI stream may contain the messages

B0 01 40  Controller #1 (Mod Wheel MSB) value: 64
B0 21 10  Controller #33 (Mod Wheel LSB) value: 16
B0 01 40  Controller #1 (Mod Wheel MSB) value: 64
B0 21 00  Controller #33 (Mod Wheel LSB) value: 0

A device that recognizes 14-bit controllers would interpret this as two 
Mod Wheel messages with values 8208 (0x2000) and 8192 (0x2010).  A 
device that only recognizes 7-bit controllers would interpret it as two 
Mod Wheel MSB messages with the same value of 64 (and might interpret 
the other messages as controller #33 changes with values 16 & 0 ??).

At least, this is how I understand it to work.  You can send me the MIDI 
files that are causing problems and I will take a look at them.

Anthony


On 11/1/20, 3:10 PM, Bernard Bel wrote:

> Finally the main problem is an inconsistency of formatting "Control"
> MIDI events (with status 176). These events can be 3-bytes or 4-bytes
> depnding on the controler. If the controler is greater than 64 then they
> are on 7 bits (range 0 .. 127) whereas with a controler below 65 they
> are (should be or could be?) on 14 bits.
>
> However it works this way, perhaps because MIDI devices are tolerant on
> data format, or possibly both 7 and 14 bit representations are licit for
> controlers below 65.
>
> The problem is that so far BP has represented volume control #7 and
> panoramic #10 on 7 bits only. We have a function "ThreeByteEvent()" that
> only checks the status byte, which is insufficient for Control.
>
> Things went bas when I imported MIDI files in which the standard 14-bit
> representation was used. I arranged filters to avoid the jamming but it
> will need to be investigated further: make sure that a flexible format
> is licit. I guess that Anthony worked on this when implementing the MIDI
> file output. We'll later check MIDI samples with all possible
> combinations to make sure the implementation is robust.
>
> Bernard

[bp-dev] MIDI data consistency

[Bernard B. <ber...@gm...>]

Dear all,

Today I checked importing data from MIDI files to sound-object 
prototypes and then combining them via a grammar, both in MIDI and 
Csound output. This revealed inconsistencies which took long to trace…

Finally the main problem is an inconsistency of formatting "Control" 
MIDI events (with status 176). These events can be 3-bytes or 4-bytes 
depnding on the controler. If the controler is greater than 64 then they 
are on 7 bits (range 0 .. 127) whereas with a controler below 65 they 
are (should be or could be?) on 14 bits.

However it works this way, perhaps because MIDI devices are tolerant on 
data format, or possibly both 7 and 14 bit representations are licit for 
controlers below 65.

The problem is that so far BP has represented volume control #7 and 
panoramic #10 on 7 bits only. We have a function "ThreeByteEvent()" that 
only checks the status byte, which is insufficient for Control.

Things went bas when I imported MIDI files in which the standard 14-bit 
representation was used. I arranged filters to avoid the jamming but it 
will need to be investigated further: make sure that a flexible format 
is licit. I guess that Anthony worked on this when implementing the MIDI 
file output. We'll later check MIDI samples with all possible 
combinations to make sure the implementation is robust.

Bernard

[bp-dev] Improvize mode is implemented

[Bernard B. <ber...@gm...>]

Dear all,

Today I completed the pianoroll display of notes produced by Csound 
scripts in sound-objects. It does the work even if the Csound mode is 
not active. So, for instance when producing a MIDI file (or real-time 
MIDI) the pianoroll will show (in green color) notes that cannot be 
heard on MIDI because they are destined to Csound.

After days working on these routines I start getting familiar again with 
the code. It looks complicated but there is no redundant procedure. It 
only deserves to be better commented and described in detail… When time 
permits!

I took the opportunity to implement the "Improvize" mode. I have set up 
an internal limit to 10 items because Improvize should normally be 
interrupted by an external device: either a MIDI message mapped to a 
"stop" procedure, or some hit on the computer keyboard, which will 
probably require system-dependent programming. A hit on the spacebar 
could for instance work as a pause.

Improvize produces a MIDI file or a Csound file containing the 10 items, 
which the interface immediately converts to audible sound.

In the Improvize mode, the console stops sending messages after creating 
the first item. It again "talks" once the improvization is over.

You can for instance set -gr.Mozart to the Improvize mode and listen for 
almost 5 minutes to a sequence which never existed and will never exist 
again! :-)  Avoid listening to this example in Csound mode because notes 
will be played as sinewaves. This would be bad publicity for Csound! I 
hope that we soon can install a "default.orc" producing a real musical 
sound.

All this programming will be useful for the real-time MIDI output as the 
framework of arranging events is now working well.

Bernard

[bp-dev] Both image formats

[Bernard B. <ber...@gm...>]

Now the console creates both images (pianoroll + objects) if options are 
selected in the settings.

Bernard

[bp-dev] Csound score problems solves

[Bernard B. <ber...@gm...>]

Dear all,

I spent the day implementing a missing graphic procedure. Now, all notes 
produced via the scores of "Csound objects" are displayed in the 
pianoroll. This, of course, in addition to notes contained in MIDI 
streams. It was confusing getting incomplete pianorolls even though 
invisible notes were also inaudible in the MIDI format as they would 
only be processed by Csound.

Now I realize that on small examples and experiments it may be important 
to see both graphics, one in "objects" and the other one in "pianoroll". 
For the time being this is possible by changing options in the settings, 
but if both options are selected the machine should create both images. 
I will try to implement this to-morrow. Today's work was quite hard 
because extracting notes from a Csound score is not evident.

I also changed the status of displaying Csound scores in messages. Now 
this is only possible when the "Trace Csound" option is active.

I also noticed that the console could go wild when trying to read a 
'"-mi" or a "-cs" file that is being autosaved. It did not handle well 
arbitrary failures in reading these files. I fixed some problems but we 
might see other situations in which the process is not complete. Bad 
because the interface returns a blank page.

Regarding "autosave", now the interface creates a "lock file" during 
autosave and deletes it afterwards. When PRODUCE ITEM(s) is called, the 
machine waits until the lock files have been deleted. After 5 seconds it 
ignores the warning but it tells the user that something went wrong.

Bernard

[bp-dev] Csound score problems solves

[Bernard B. <ber...@gm...>]

Dear all,

Two days ago I posted a message complaining that Csound seems to go wild 
on large files. This was wrong.

Indeed I was trying -gr.Nadaka which produces a piece of 2mn 50s. The 
score (see enclosed) was in fact wrong with respect to event durations.

The complexity of this example made it very difficult to trace the 
process. Fortunately I came over a short piece that was showing the same 
faulty durations. Durations were incorrect whenever the metronome was 
not 60 beats/min.

The problem has been solved and I pushed the corrected version of the 
console… Hopefully for the last time before merging branches ;-)

For the time being I am updating the documentation, which makes it 
necessary to check again all examples…

I also update the PHP interface quite often.

Bernard

[bp-dev] Csound score automatic processing complete

[Bernard B. <ber...@gm...>]

Dear all,

The new interface I have just pushed does the automatic creation of 
sound files from their Csound scores. It works well except for large 
items such as "-gr.Nadaka". This one produces a garbage WAVE file.

Running Csound on the Terminal yields (for 50 seconds) a string of error 
messages such as:

B748.998 ..750.000 T125.000 TT125.000 M:  44008.1
	 number of samples out of range:       75
...

end of section 1	 sect peak amps: 148370.3
	 number of samples out of range:   547819
inactive allocs returned to freespace

In the end, no joke, Csound concludes "0 errors in performance" ;-)

I am enclosing the score file which doesn't seem abnormal.

I guess that there may be an option of Csound assigning more "space" to 
samples but I have not identified which one… Suggestions ?

Bernard