bolprocessor-devel — Bol Processor developer discussion list

[bp-dev] Scale management completed - with graphics

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

Dear all,

I have completed (and uploaded) a long series of updates in the handling 
of microtonal scales on the PHP interface.

The immediate purpose was to develop all necessary tools to demonstrate 
the construction of scales for raga performance according to the 
"flexible" model I had derived from ancient Indian musicology. The same 
tools will be helpful in many situations unrelated with Indian music.

Modifying the value of the syntonic comma, and to this effect marking 
intervals as belonging to harmonic or pythagorean series, having the 
machine guess the nearest integer fraction when an arbitrary ratio is 
entered or calculated in floating-point format, these are some of the 
new valuable features of this interface.

On the console the main developmentt was the possibility of setting the 
mapping of notes to key numbers: when using an pentatonic scale you may 
not want key A4 to produce C4! So, in this case, notes could be mapped 
to the black keys.

This development has taken me a long way reviewing the fundamentals of 
Indian musicology via concrete experiments. I will publish a page or two 
on this subject and a practical guide for musicians eager to travel 
along similar routes... I am waiting for the reception of "The Raga 
Guide" 
(https://www.amazon.com/Raga-Guide-Survey-Hindustani-Ragas/dp/0954397606) 
by Bor and Rao who had taken part in our early research on raga 
intonation. The recordings will be necessary to extract meaningful examples.

For the time being I am enclosing the display of a reconstruction of the 
scale of raga "Todi" matching experimental readings within 4 cents… 
Sound examples will follow! Graphics are indispensable to compare scales 
and highlight their internal structures.

I hope that you will enjoy Xmas celebrations despite sanitary 
restrictions. We're planning family meetings not exceeding 6 guests. ;-)

All the best,

Bernard

[bp-dev] Just intonation scales + documentation

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

Dear colleagues,

I worked hard these last days, reviewing, synthesizing and implementing 
work done with my late colleague Jim Arnold in 1979-1981. This was the 
time of experiments with the Shruti harmonium, trying to check the 
relevance of Jim's interpretation of the ancient grama-murcchana system 
to current musical practice in North India.

The result was negative, which incited us to drop the subject for a 
while (let's say 40 years!) and construct a melodic movement analyzer 
looking at the "flesh" rather than the "skeleton" of raga music 
performance. A few years later, selective statistical analysis again 
suggested intonational models, but we did not take time to return to the 
ancient theory and discover that the model it describes is "flexible". 
In other worrds, it may match raga statistics far beyond the Western 
model of "just intonation" that Jim had earlier presented as "the model".

I summarized this work on page:
https://bolprocessor.org/just-intonation-framework/

It was great fun (and lot of work) to reconstruct Jim's "shruti wheel" 
on a PowerPoint document (see enclosed) that can be used dynamically to 
illustrate transpositions (murcchana)… I am going to write another 
article on the "two-vina experiment" which is poorly explained by 
musicologists and Wikipedians. This will complete my tribute to Arnold. ;-)

On the same page and on https://bolprocessor.org/microtonality/ I 
documented the construction of "optimally consonant" chromatic scales to 
set intervals of Western major and minor scales. This also was Jim's 
contribution. We spent months writing and translating a paper on this 
topic which was published 4 years later by a confidential French journal 
of musicology. Now, the Bol Processor Scale interface constructs all 
these scales in single clicks and compares their tonal contents.

I have gone up to the point of demonstrating the lowering of C, F and G 
when switching from C major to C minor. Now I would like to reproduce 
experiments with Pierre-Yves Asselin performing Bach's preludes while 
Jim was manipulating switches on the Shruti harmonium. For this we need 
to write an algorithm converting a musical score to Bol Processor 
polymetric structures. Let's find a format that can be produced by 
playing with a standard MIDI instrument… I see that programs like 
ScoreCloud (https://scorecloud.com/) convert music to scores, but we 
need exported files that can be analyzed and transcribed to Bol 
Processor. Is there a standard format?

In the grama-murcchana system I also plan to extend the interface to 
dealing with scales based on different sizes of the syntonic comma. We 
already know tuning schemes with a comma of 6 or 18 cents suitable to 
the performance of some certain Indian ragas. Those scales would be fun 
to experiment — and attract Indian musicologists!

I also plan to implement a model encompassing all temperament methods 
used in medieval Europe, following the outstanding work of Pierre-Yves 
Asselin. We'll need a beautiful pipe-organ instrument in Csound! ;-)

It's time for my daily walk in the forest. Feedback and corrections on 
these publications are welcome! :-)

Bernard

Re: [bp-dev] Csound microtonality

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

Dear all,

Documentation on microtonality in BP3 / Csound is ready:

https://bolprocessor.org/microtonality/

Certainly not complete because I need to rework the issue of meantone 
temperament. Fortunately, today I received the book of Pierre-Yves 
Asselin, a specialist of tuning systems (and their implementation on 
pipe organs or harpsichords) who documented the whole history of 
"temperament". The book's content is basically the PhD thesis he was 
busy with as we met in Paris in 1980. A wonderful piece of work! I will 
certainly recontact him when the model is fully iimplemented on BP3…

At the moment I mainly documented the Indian grama-murcchana system 
which was my hobby in the early 1980s. At the bootom of the page you 
ccan listen to the 22 "shrutis" as per our interpretation of the ancient 
sanskrit treatise.

I tried to create a tanpura sound. To this effect I spent 3$ buying a 
sample of a beautiful sound produced by a Miraj tanpura (enclosed file). 
That sample contained a bried moment in which only the base note was 
heard. I measured its frequency with great accuracy (using BP3) and 
extracted a sample of waveform whose duration was exactly the measured 
period. I put it in a table of the Csound instrument and it worked. :-) 
It's nice but it sounds like a string without the ivory bridge and 
cotton thread producing the higher partials.

I wish I could figure out how to create this fascinating sound in a 
Csound orchestra but I haven't seen any example...

Bernard

Re: [bp-dev] Csound microtonality

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

Dear all,

I edited a basic documentation on microtonality in BP3/Csound:

https://bolprocessor.org/microtonality/

I hope to design examples using pitchbend with accurate positions 
demonstrating the interest of microtonal scales!

Bernard

Re: [bp-dev] Csound microtonality

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

Dear all,

I have completed important steps for the handling of microtonal scales. 
It will take a long time to document all aspects…

Most important is the possibility of mixing different scales on the same 
data and of getting it correctly parsed with specific note names. For 
instance in this grammar:

-cs.vina
ORD
gram#1[1] <1> S --> _tempo(2) _scale(grama,sa_4) sa_4 r4_4 g3_4 m1_4 
p4_4 d3_4 n3_4 sa_5 _scale(just intonation,C4) C4 D4 E4 F4 G4 A4 B4 C5 
_scale(piano,C4) do4 re4 mi4 fa4 sol4 la4 si4 do5

The machine picks up the definitions of scales "grama", "just 
intonation" and "piano" in the "-cs.vina" file. I am now calling it a 
"Csound resource file" rather than "Csound instruments" because it 
contains all the material required by the grammar to operate with 
Csound, including links to waveform files and the Csound orchestra.

Scale "just intonation" is the one most often used under that name, here 
built on simple ratios of 3, 4, 5.

Scale "piano" is an equal-tempered piano tuning scheme with octaves 
streched to 1204 cents. As a consequence, all major fifths are perfect 
(3/2).

Scale "grama" is a 23-interval scale based on the ancient India theory 
of scales. Usually it is said to contain 22 "shrutis" (micro-intervals) 
and it would take long to explain why we may find an extra one. The 
"grama" scale is actually a set of 2048 chromatic scales among which 
only 12 have an almost perfect harmonicity, which means only 1 
"incorrect" fifth. Presumably a scale should be selected for harmonic 
contexts in which this "wolf tone" will never occur.

My regretted colleague Jim Arnold had theorized these scales for their 
use in raga music in connection with raga performance times. I had built 
a "shruti harmonium" to check his hypothesis but was cautious enough to 
make every interval programmable. When we switched to the Melodic 
Movement Analyzer and statistical methods we found that actual practice 
is much more complex. Later, reading again the Natyashastra treatise 
describing this scale (as a set of constraints) I found out that the 
model could be made flexible because Bharata (the author) did not 
classify the major third as a "harmonic" interval. Therefore it could be 
anywhere between the harmonic major third (5/4) and the Pythagorean 
third (81/64). This amounts to changing the value of the comma between 0 
and 22 cents.

Anyway, to make it short, you see the names of notes in the "grama" 
scale: there are 4 values for D (re in Sanskrit): r1 and r2 for D flat 
and r4 and r4 for D.

I am enclosing pictures of the "grama" and "piano" scales as shown on 
the interface. If you change a ratio it automatically adjusts the 
floating-point ratio, cents values etc. The "INTERPOLATE" button creates 
temperament over undefined intervals and the "CREATE" button produces 
meantone temperament. This is just a start for the inumerable manners of 
constructing scales!

Listening to the example (MP3 attached) may not be convincing but you 
can look at the Csound score to check significant features:

1) The first two scales display a frequency ration of 2/1 from C4 to C5 
and their intervals are identical. So the Western "just-intonation" 
scale is an instance of scales summarized in "grama". Figures are 
slightly different between d4_4 and A4 but that's just a rounding effect 
because the difference is 6 per 10000.
2) The "piano" scale confirms octave stretching by a ratio of 2.0046 = 
1204 cents and perfect fifths such as 392.445 / 261.630.
3) Frequency of C4 is identical on the three scales because in 
statements such as _scale(piano,C4) the "block key" is C4. If you change 
it to A4, all equivalent notes will come as close as possible to 440 Hz.

I had a hard time programming this, notably until I found out that the 
modulo operator in C misbehaves dealing with negative numbers… The 
solution is:

int mod(a, b) {
   (((a % b) + b) % b)
}

All changes in the console and in the interface have been uploaded.

In the long term we may wish to develop generic tools for dealing with 
modal systems and "exotic tunings". First I need to study in detail the 
theoretical work of Jean Chatillon and his student Pierre-Yves Asselin. 
In 1980, Pierre-Yves had done his PhD on the (many) traditional tuning 
schemes of pipe organs.

More explanations in the documentation!

Bernard

Re: [bp-dev] Strange waveforms with 0-default.orc

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

It was https://csound.com/download.html
This is the link I wrote on https://bolprocessor.org/check-bp3/

The processor of my MacBook is "2.5 GHz Intel Core i5".

Best wishes! ;-)

Bernard

Anthony Kozar wrote on 19/11/2020 07:45:
> Hmm... Interesting. It sounds like we installed the same version of Csound 6 on the same version of OS X and it works for you but not for me.  Just to be sure, can you confirm that you downloaded the DMG archive with an installer .pkg inside from either https://csound.com/ or https://github.com/csound/csound/releases/latest/ ??  I'd like to have the facts straight when I report this to the mailing list.
>
> IIRC, the error message I got when trying to run Csound 6.15 was "illegal instruction".  So perhaps the problem is not the OS version as I assumed, but the specific CPU in my computer?
>
> Anthony
>
> On Nov 19, 2020 12:32 AM, Bernard Bel <ber...@gm...> wrote:
>
>> Dear Anthony,
>>
>> Well, I am using a recent version of Csound:
>>
>> Csound version 6.15 (double samples) Aug 10 2020
>> [commit: 8b4fd4f626b145721a9f20793a05ebcd227b3fd4]
>>
>> which I installed in a single click on MacOS 10.11.6 using their
>> installation tool!
>>
>> This should help to solve the paradox :-)
>>
>> Bernard
>>
>> Anthony Kozar wrote on 18/11/2020 21:32:
>>> On 11/16/20, 10:49 AM, Bernard Bel wrote:
>>>> Wonderful work!
>>> Thanks :)
>>>
>>>> I installed the new "0-default.orc" in "csound_resources", created a
>>>> "-cs.Nadaka" file covering the first 3 instruments (enclosed) and
>>>> inserted an "_ins(3)" instruction in the beginning of "-gr.Nadaka".
>>>>
>>>> I am getting the same score as yours (see enclosed) and it does play the
>>>> brass instrument, but the result is a bit different. It seems that
>>>> another effect has been applied in the sample you sent…
>>> Hmmm, they do sound very different.  It sounds to me like the attack
>>> time is much shorter in your rendition than mine.
>>>
>>> I have been testing the instruments by renumbering the one that I wish
>>> to use to be instr 1.  But I rendered it again using the score that
>>> you sent with "i3" statements and I get a synth brass sound that
>>> matches what I got before.  So, I don't think the difference is in the
>>> effects routing.  I suspect some change in Csound given that I am
>>> using a very old version.
>>>
>>> Csound development policy does not allow "incompatible changes" but
>>> fixing an opcode that gives incorrect output could significantly
>>> change the resulting sound.  I see that some bug was fixed in the
>>> xadsr opcode in version 6.05.  Perhaps that could account for a
>>> difference in the attack portion of the amplitude envelope.
>>>
>>> I am using Csound "version 5.14 (float samples) Oct 10 2011".  Which
>>> version are you using, Bernard?
>>>
>>> (I tried the latest Csound installer for macOS, but it doesn't work on
>>> OS X 10.11.  I haven't taken the time to find out which installers are
>>> compatible with my system nor to compile Csound from scratch ...)
>>>
>>> Anthony
>>>
>>>
>>>
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>
>>
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li...
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Strange waveforms with 0-default.orc

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

Hmm... Interesting. It sounds like we installed the same version of Csound 6 on the same version of OS X and it works for you but not for me.  Just to be sure, can you confirm that you downloaded the DMG archive with an installer .pkg inside from either https://csound.com/ or https://github.com/csound/csound/releases/latest/ ??  I'd like to have the facts straight when I report this to the mailing list.

IIRC, the error message I got when trying to run Csound 6.15 was "illegal instruction".  So perhaps the problem is not the OS version as I assumed, but the specific CPU in my computer?

Anthony

On Nov 19, 2020 12:32 AM, Bernard Bel <ber...@gm...> wrote:

> Dear Anthony, 
>
> Well, I am using a recent version of Csound: 
>
> Csound version 6.15 (double samples) Aug 10 2020 
> [commit: 8b4fd4f626b145721a9f20793a05ebcd227b3fd4] 
>
> which I installed in a single click on MacOS 10.11.6 using their 
> installation tool! 
>
> This should help to solve the paradox :-) 
>
> Bernard 
>
> Anthony Kozar wrote on 18/11/2020 21:32: 
> > On 11/16/20, 10:49 AM, Bernard Bel wrote: 
> >> Wonderful work! 
> > 
> > Thanks :) 
> > 
> >> I installed the new "0-default.orc" in "csound_resources", created a 
> >> "-cs.Nadaka" file covering the first 3 instruments (enclosed) and 
> >> inserted an "_ins(3)" instruction in the beginning of "-gr.Nadaka". 
> >> 
> >> I am getting the same score as yours (see enclosed) and it does play the 
> >> brass instrument, but the result is a bit different. It seems that 
> >> another effect has been applied in the sample you sent… 
> > 
> > Hmmm, they do sound very different.  It sounds to me like the attack 
> > time is much shorter in your rendition than mine. 
> > 
> > I have been testing the instruments by renumbering the one that I wish 
> > to use to be instr 1.  But I rendered it again using the score that 
> > you sent with "i3" statements and I get a synth brass sound that 
> > matches what I got before.  So, I don't think the difference is in the 
> > effects routing.  I suspect some change in Csound given that I am 
> > using a very old version. 
> > 
> > Csound development policy does not allow "incompatible changes" but 
> > fixing an opcode that gives incorrect output could significantly 
> > change the resulting sound.  I see that some bug was fixed in the 
> > xadsr opcode in version 6.05.  Perhaps that could account for a 
> > difference in the attack portion of the amplitude envelope. 
> > 
> > I am using Csound "version 5.14 (float samples) Oct 10 2011".  Which 
> > version are you using, Bernard? 
> > 
> > (I tried the latest Csound installer for macOS, but it doesn't work on 
> > OS X 10.11.  I haven't taken the time to find out which installers are 
> > compatible with my system nor to compile Csound from scratch ...) 
> > 
> > Anthony 
> > 
> > 
> > 
> > _______________________________________________ 
> > bolprocessor-devel mailing list 
> > bol...@li... 
> > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel 
>
>
>
> _______________________________________________ 
> bolprocessor-devel mailing list 
> bol...@li... 
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel 
>

Re: [bp-dev] Strange waveforms with 0-default.orc

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

Dear Anthony,

Well, I am using a recent version of Csound:

Csound version 6.15 (double samples) Aug 10 2020
[commit: 8b4fd4f626b145721a9f20793a05ebcd227b3fd4]

which I installed in a single click on MacOS 10.11.6 using their 
installation tool!

This should help to solve the paradox :-)

Bernard

Anthony Kozar wrote on 18/11/2020 21:32:
> On 11/16/20, 10:49 AM, Bernard Bel wrote:
>> Wonderful work!
>
> Thanks :)
>
>> I installed the new "0-default.orc" in "csound_resources", created a
>> "-cs.Nadaka" file covering the first 3 instruments (enclosed) and
>> inserted an "_ins(3)" instruction in the beginning of "-gr.Nadaka".
>>
>> I am getting the same score as yours (see enclosed) and it does play the
>> brass instrument, but the result is a bit different. It seems that
>> another effect has been applied in the sample you sent…
>
> Hmmm, they do sound very different.  It sounds to me like the attack 
> time is much shorter in your rendition than mine.
>
> I have been testing the instruments by renumbering the one that I wish 
> to use to be instr 1.  But I rendered it again using the score that 
> you sent with "i3" statements and I get a synth brass sound that 
> matches what I got before.  So, I don't think the difference is in the 
> effects routing.  I suspect some change in Csound given that I am 
> using a very old version.
>
> Csound development policy does not allow "incompatible changes" but 
> fixing an opcode that gives incorrect output could significantly 
> change the resulting sound.  I see that some bug was fixed in the 
> xadsr opcode in version 6.05.  Perhaps that could account for a 
> difference in the attack portion of the amplitude envelope.
>
> I am using Csound "version 5.14 (float samples) Oct 10 2011".  Which 
> version are you using, Bernard?
>
> (I tried the latest Csound installer for macOS, but it doesn't work on 
> OS X 10.11.  I haven't taken the time to find out which installers are 
> compatible with my system nor to compile Csound from scratch ...)
>
> Anthony
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Strange waveforms with 0-default.orc

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

On 11/16/20, 10:49 AM, Bernard Bel wrote:
> Wonderful work!

Thanks :)

> I installed the new "0-default.orc" in "csound_resources", created a
> "-cs.Nadaka" file covering the first 3 instruments (enclosed) and
> inserted an "_ins(3)" instruction in the beginning of "-gr.Nadaka".
>
> I am getting the same score as yours (see enclosed) and it does play the
> brass instrument, but the result is a bit different. It seems that
> another effect has been applied in the sample you sent…

Hmmm, they do sound very different.  It sounds to me like the attack 
time is much shorter in your rendition than mine.

I have been testing the instruments by renumbering the one that I wish 
to use to be instr 1.  But I rendered it again using the score that you 
sent with "i3" statements and I get a synth brass sound that matches 
what I got before.  So, I don't think the difference is in the effects 
routing.  I suspect some change in Csound given that I am using a very 
old version.

Csound development policy does not allow "incompatible changes" but 
fixing an opcode that gives incorrect output could significantly change 
the resulting sound.  I see that some bug was fixed in the xadsr opcode 
in version 6.05.  Perhaps that could account for a difference in the 
attack portion of the amplitude envelope.

I am using Csound "version 5.14 (float samples) Oct 10 2011".  Which 
version are you using, Bernard?

(I tried the latest Csound installer for macOS, but it doesn't work on 
OS X 10.11.  I haven't taken the time to find out which installers are 
compatible with my system nor to compile Csound from scratch ...)

Anthony

[bp-dev] Warning/error messages tagged

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

Dear all,

In the console I modified hundreds of error/warning messages to insert a 
tag "=> " (anywhere in the line) recognized by the interface.

Be default, the interface does not display all messages sent by the 
console: a button can be clicked to display them on a separate window. 
However, if messages include tagged errors/warings, a red blinking flag 
prompts the user to look at the entire message sequence. Lines 
containing "=> " are displayed in red colour.

This is very practical when an error occured which did not modify the 
sound output in a sensitive amount. This notably happens when dealing 
with microtonal scales.

Now that the "tonal scale" tool is fully operational, I will document 
microtonality on the site. ;-)

Bernard

Re: [bp-dev] Csound microtonality

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

Dear all,

Today I developed the PHP interface for editing/creating microtonal 
scales — from a Csound instruments file which may even contain no 
instrument…

The file now stores integer ratios, if these have been declared, and 
floating-point ratios. The console uses only the latter.

A nice feature is that in any scale you can declare a few important 
ratios such as 3/2, 5/4, 6/5 etc. and then ask the machine to 
"interpolate" missing ratios, which may be named a "local temperament".

We deal with scales containing any number of grades and covering any 
interval. For instance I created a "piano" scale (see attached picture) 
in which octaves are stretched to 1204 cents so that fifths are near to 
perfect. This is he way pianos are (should be?) tuned, as octave 
stretching is a physical property of vibrating strings.

All I needed to enter was the 1204 cents value, then click INTERPOLATE.

I am enclosing an example repeating the same phrase in three tunings:

1) equal-tempered
2) piano with stretched octaves
3) just intonation

The BP score is:
_scale(0,0) C4 E4 A4 {8,{C4,E4,G4,C5}}{8,{C4,Eb4,G4,C5}} - 
_scale(piano,C4) C4 E4 A4 {8,{C4,E4,G4,C5}}{8,{C4,Eb4,G4,C5}} - 
_scale(just intonation,C4)C4 E4 A4 {8,{C4,E4,G4,C5}}{8,{C4,Eb4,G4,C5}}

The Csound score and the MP3 rendering are attached. Quite interesting, 
notably the "strength" of the minor chord when the minor third is 
precisely 6/5.

I am now trying to implement a process creating various kinds of 
meantone temperament…

Bernard

Re: [bp-dev] Csound microtonality

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

With sound-objects as "exotic notes" it is difficult to use integer 
ratios for their labels because these would clash with fractional 
silences. But we can modify the representation. For instance, "27|16" 
could label a sound-object designating a pythagorean sixth, instead of 
"27/16".

I will check that this labeling is possible and modify the console to 
make it licit. In the end, the interface building scales stored in "-cs" 
files could automatically produce the corresponding "-mi" and "-ho" files!

It might be useful to add a scale identifier to each of these 
sound-objects. This would break compatibility with BP2 but anyway BP2 
wasn't designed for microtonality...

Bernard

Anthony Kozar wrote on 16/11/2020 14:19:
> In the long run, I would like to be able to define new vocabularies of 
> symbols for simple notes with any number of pitch-classes per octave (or 
> other interval) and be able to map those symbols to frequencies using 
> your _scale() tool.  Also, I think that the ability to directly specify 
> ratios for just intervals in a BP score would be great.  The notation 
> would require some thought since "p/q" where p & q are integers is 
> already used for rests.

Re: [bp-dev] Csound microtonality

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

Dear Anthony,

We are perfectly "in tune" on this topic.  :-)

At the moment I am completing an interface page to define tonal scales 
with any parameters. It is still a basic one in which ratios are entered 
as floating-point numbers, the ones we see on Csound GEN51 tables, but I 
will make it easy to enter integer ratios even though these, in the end, 
will be converted to floats.

With respect to note names, so far the interface allows entering a name 
for every note position in the scale, and these names are loaded by the 
console when reading the "-cs" file. It would not be difficult to 
display them in an output: a Csound score or a Bol Processor score. 
Things get more difficult for using arbitrary names in grammars. Maybe 
convert all notes to sound-objects?

More precisely, when playing equal-tempered 12-tone wwe would use the 
note names and when playing the exotic scale we would use the labels of 
sound-objects. Still feasible, but… An additional difficulty is that the 
polymetric syntax makes it possible to use different scales together in 
the same piece. The trumpet on one line will use a trumpet scale and the 
piano its own. This already works and it was a reason for specifying the 
"block key" which is needed to tune instruments against each other. But 
then, using these different sets of names in the syntax might be 
complicated. Oh well, while I am writing this I figure out that it must 
be possible thanks to the sound-object model! ;-)

I am also mesmerized by this new development. About ten years ago I 
disposed as junk the Shruti Harmonium I had designed and built 41 years 
ago, a great piece of hardware (several hundreds of chips) producing 
polyphonic music with programmable intervals tuned digitally with less 
than 1 cent accuracy. It had switches to select 1 among 2 preselections 
in the scale. We used it in India for initial work on intonation, then I 
went on with the construction of the melodic movement analyzer, 
understanding that tuning procedures were not appropriate to capture the 
practice of North Indian raga. But I had used a wooden keyboard which 
over years became unusable. And when I asked a friend to send me back 
the instrument via Fedex, it reached completely crashed because of bad 
packing. The day I disposed of it I had only in mind the hope of 
continuing this research with computers, but I was far from figuring out 
that BP + Csound would be an excellent tool to work on real musical 
examples!

For this reason I am trying to deal with this issue at the same level of 
abstraction as I had done dealing with the representation of time 
structures: any scale and (almost) any naming of "notes" should be licit!

Bernard

Anthony Kozar wrote on 16/11/2020 14:19:
> Dear Bernard,
>
> This is fantastic!  The vina3 example DOES sound a lot better with 
> just intervals as does the simple tryScales example. :)
>
> I've had a long-time interest in microtonality going back to my 
> earliest exposure to early music and electronic synthesizers.  (The 
> fact that those two things complement each other is both strange and 
> interesting).  I have been interested in expanding BP's support for 
> alternate scales and arbitrary just intervals for some time now.  
> Being able to define microtonal tunings is a great step.
>
> In the long run, I would like to be able to define new vocabularies of 
> symbols for simple notes with any number of pitch-classes per octave 
> (or other interval) and be able to map those symbols to frequencies 
> using your _scale() tool.  Also, I think that the ability to directly 
> specify ratios for just intervals in a BP score would be great.  The 
> notation would require some thought since "p/q" where p & q are 
> integers is already used for rests.
>
> Anthony
>
>
> On 11/13/20, 2:52 PM, Bernard Bel wrote:
>> Dear all,
>>
>> I have completed the first part of microtonal scale processing in BP3.
>>
>> Enclosed are examples in just-intonation and equal-tempered scales:
>>
>> 1) a "tryScales" phrase in which you can hear beats in equal-tempered 
>> chords
>>
>> 2) the "vina3" example which is way better in just intonation, even if
>> the actual ratios would be subject of discussion, as it is the case in
>> Indian musicology since the day I created a melodic movement analyzer 
>> ;-)
>>
>> I am enclosing the equal-tempered examples in this message and the
>> just-intonation ones in the next one.
>>
>> For me it's a great achievement. :-)
>>
>> The second part will be an implementation of the "_scale()" performance
>> tool to change the choice of scale. I like it!
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Strange waveforms with 0-default.orc

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

Wonderful work!

I installed the new "0-default.orc" in "csound_resources", created a 
"-cs.Nadaka" file covering the first 3 instruments (enclosed) and 
inserted an "_ins(3)" instruction in the beginning of "-gr.Nadaka".

I am getting the same score as yours (see enclosed) and it does play the 
brass instrument, but the result is a bit different. It seems that 
another effect has been applied in the sample you sent…

Don't bother about amplitudes. I understand the care in not producing 
saturation. I was only suprized hearing the difference with 
"new-vina.orc". This is normal since there is an almost unchanged volume 
in the phrase composed by Kumar.

I will also try this example in "pure intonation". Now busy with the 
interface for editing all sorts of tonal scales. ;-)

Bernard

Anthony Kozar wrote on 16/11/2020 13:22:
> Bernard,
>
> Thanks for noticing the DC offset in the pluck sound!  I vaguely 
> recall encountering this issue with the Csound pluck opcode before, 
> although perhaps other instruments or the effects are adding or 
> intensifying the offset too.  Csound has a couple of opcodes for 
> blocking DC components.  To be safe, I added these after the final 
> reverb effect, just before the output is written to file/DAC.
>
> My current orchestra (with some new instruments), test score, and some 
> MP3 examples are attached.
>
> I haven't addressed the low amplitude issue yet.  I intentionally set 
> the starting amplitude on the low side while I am developing 
> instruments.  On my computer, the headphones jack produces much louder 
> output than the built-in speakers and it is too easy to create 
> deafening output with Csound. :|
>
> Once the orchestra is relatively finalized, I will perform some 
> experiments to see how many notes can be played simultaneously without 
> clipping and to determine how much the effects reduce the amplitude 
> level.  Then an appropriate scaling factor can be determined.
>
> Thanks for the feedback!
>
> Anthony
>
> On 11/12/20, 1:20 PM, Bernard Bel wrote:
>> Another problem is the low amplitude of signal produced by this
>> orchestra. To use these sound files I need to amplify them by 18dB…
>>
>> Bernard
>>
>> -------
>>
>> Dear Anthony,
>>
>> "0-default.orc" produces beautiful plucked-string sounds but they look
>> bizarre in a sound editor: there is a 0 Hz component displacing curves
>> up ans down. (It has nothing to do with the pitchbend.)
>>
>> The enclosed is a performance of:
>>
>> _pitchcont _pitchrange(200) C5 _pitchbend(0) D5 _ _pitchbend(120) _
>> _pitchbend(-150) _ _ _pitchbend(0) E5
>>
>> We need a low-cut filter! :-)
>>
>> Bernard
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Csound microtonality

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

Dear Bernard,

This is fantastic!  The vina3 example DOES sound a lot better with just 
intervals as does the simple tryScales example. :)

I've had a long-time interest in microtonality going back to my earliest 
exposure to early music and electronic synthesizers.  (The fact that 
those two things complement each other is both strange and interesting). 
  I have been interested in expanding BP's support for alternate scales 
and arbitrary just intervals for some time now.  Being able to define 
microtonal tunings is a great step.

In the long run, I would like to be able to define new vocabularies of 
symbols for simple notes with any number of pitch-classes per octave (or 
other interval) and be able to map those symbols to frequencies using 
your _scale() tool.  Also, I think that the ability to directly specify 
ratios for just intervals in a BP score would be great.  The notation 
would require some thought since "p/q" where p & q are integers is 
already used for rests.

Anthony


On 11/13/20, 2:52 PM, Bernard Bel wrote:
> Dear all,
>
> I have completed the first part of microtonal scale processing in BP3.
>
> Enclosed are examples in just-intonation and equal-tempered scales:
>
> 1) a "tryScales" phrase in which you can hear beats in equal-tempered chords
>
> 2) the "vina3" example which is way better in just intonation, even if
> the actual ratios would be subject of discussion, as it is the case in
> Indian musicology since the day I created a melodic movement analyzer ;-)
>
> I am enclosing the equal-tempered examples in this message and the
> just-intonation ones in the next one.
>
> For me it's a great achievement. :-)
>
> The second part will be an implementation of the "_scale()" performance
> tool to change the choice of scale. I like it!
>
> Bernard

Re: [bp-dev] Strange waveforms with 0-default.orc

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

Bernard,

Thanks for noticing the DC offset in the pluck sound!  I vaguely recall 
encountering this issue with the Csound pluck opcode before, although 
perhaps other instruments or the effects are adding or intensifying the 
offset too.  Csound has a couple of opcodes for blocking DC components. 
  To be safe, I added these after the final reverb effect, just before 
the output is written to file/DAC.

My current orchestra (with some new instruments), test score, and some 
MP3 examples are attached.

I haven't addressed the low amplitude issue yet.  I intentionally set 
the starting amplitude on the low side while I am developing 
instruments.  On my computer, the headphones jack produces much louder 
output than the built-in speakers and it is too easy to create deafening 
output with Csound. :|

Once the orchestra is relatively finalized, I will perform some 
experiments to see how many notes can be played simultaneously without 
clipping and to determine how much the effects reduce the amplitude 
level.  Then an appropriate scaling factor can be determined.

Thanks for the feedback!

Anthony

On 11/12/20, 1:20 PM, Bernard Bel wrote:
> Another problem is the low amplitude of signal produced by this
> orchestra. To use these sound files I need to amplify them by 18dB…
>
> Bernard
>
> -------
>
> Dear Anthony,
>
> "0-default.orc" produces beautiful plucked-string sounds but they look
> bizarre in a sound editor: there is a 0 Hz component displacing curves
> up ans down. (It has nothing to do with the pitchbend.)
>
> The enclosed is a performance of:
>
> _pitchcont _pitchrange(200) C5 _pitchbend(0) D5 _ _pitchbend(120) _
> _pitchbend(-150) _ _ _pitchbend(0) E5
>
> We need a low-cut filter! :-)
>
> Bernard

[bp-dev] Full implementation of _scale() tool

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

Dear all,

The "_scale()" is now fully operational and briefly documented in the 
(enclosed) "BP2_help.txt" file (uploaded with the "php" folder).

I carefully checked frequency ratios and adjustments done by the 
'blockkey' parameter in a comparison between "just-intonation" and 
"equal-tempered". I picked up a few ready-made results in the page:
https://en.wikipedia.org/wiki/Equal_temperament

As you see on Wiikipedia, there are many systems describing 
unconventional scales, for instance 11 equal steps in a perfect fifth! ;-)

All these can be easily set on Bol Processor. I hope to design a page of 
the interface generating scales (the GEN51 function tables) from 
human-understandable specifications.

However I need to be sure how these scales are handled by Csound for at 
least a simple reason: knowing whether we should put 11 or 12 ratios 
when dealing with a 12-interval scale. It would be silly to implement a 
different standard on BP3...

More reflection/programming will be required for users who need to 
define the names of note positions. At the moment we only have 12-tone 
notation plus key numbers. Incidently I renamed the "French" convention 
as "Italian/French" because, after all, it originates from Italy! :-)

I am glad that this implementation is complete. It forced me to review 
many steps of the production process and fix a few programming details — 
no bug, just more consistency. I see that Anthony already wrote very 
relevant remarks in the code: points that need to be studied in greater 
detail, notably for a better memory management.

Now I will document all this on the site before I forget how it works. ;-)

Bernard

[bp-dev] Enharmonic adjustment in Csound microtonal scales

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

Dear all,

I pushed a new version of the console and the interface in which we can 
specify which note has a "fixed frequency" when the scale is changed. 
Let me explain…

Suppose that we fixed A4 = 440 Hz. If an equal-tempered scale is used, 
the frequency of C4 will be 261.63 Hz.

Now let us use a "just-intonation" scale without changing A4. Since the 
C4 - A4 interval has changed (to a smaller value), C4 frequency will be 
263.70 Hz.

This may sound OK but it will create problems if several instruments use 
different scales, or if the scale of an instrument is changed during the 
performance to do (what I call) "enharmonic adjustement", for instance 
replacing Pythagorean major thirds or sixths by their harmonic 
equivalents. In these cases we may want a certain note to stay at the 
same frequency. In Indian music it would be "sa" = C, but different 
situations may occur with different tonal systems. Keep in mind that the 
mechanism implemented (using Csound's convention) is able to define 
scales with more/less than 12 intervals and an "octave" interval 
more/less than 2.

So, in the settings we now have a slot for a key number telling the 
console which note should remain "fixed". By default we can set it to C 
= 60 or 48 or 36 etc.

It is not unlikely that this "fixed note" will be different for 
different scales and in different contexts. For this reason I plan to 
implement the "_scale()" tool with 2 parameters, one for the scale and 
the other one for the fixed key number; with value 0 if same as the 
previous value for the same scale.

The good news is that it opens BP3 to communities of musicians eager to 
play with "just intonation" and all sorts of microtonal scales, some of 
which "extra-European". They will only need to install Csound!

Now I am working on the "_scale()" tool ;-)

Bernard

[bp-dev] Csound microtonality

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

(The just-intonation versions)

[bp-dev] Csound microtonality

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

Dear all,

I have completed the first part of microtonal scale processing in BP3.

Enclosed are examples in just-intonation and equal-tempered scales:

1) a "tryScales" phrase in which you can hear beats in equal-tempered chords

2) the "vina3" example which is way better in just intonation, even if 
the actual ratios would be subject of discussion, as it is the case in 
Indian musicology since the day I created a melodic movement analyzer ;-)

I am enclosing the equal-tempered examples in this message and the 
just-intonation ones in the next one.

For me it's a great achievement. :-)

The second part will be an implementation of the "_scale()" performance 
tool to change the choice of scale. I like it!

Bernard

[bp-dev] Csound microtonality

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

Dear all,

Regardless of Csound's own way of dealing with a microtonal scale, it is 
worth having an option of doing all cps calculations in the console. The 
main reason is that changes of scales might be necessary within the 
musical piece. A practical example is that some instruments (or 
synthesized sounds of the same kind) require microtonal adjustements to 
stay "in tune", due to their upper-partial structure.

A well-known example is the tuning of a  piano in which octaves may be 
stretched to 1202 cents instead of 1200 cents (ratio 2/1).  More 
sensitive, the North-Indian shahnai in which fifths are raised by almost 
a comma (22 cents). If we use similar sounds we might need the same 
amount of correction that piano tuners or wind instrument players 
spontaneously apply. Indeed these can be worked out in the Csound 
orchestra itself but we shouldn't expect musicians to temper with this 
file… The best would be to have scales defined in a clear manner (using 
cents and/or integer ratios) at the bottom  of the Csound instruments page.

I am working on the creation of a "_scale(x)" performance controler. 'x' 
would be a number or a label (set in the Csound instruments file).

By default — "_scale(0)" — the production would use either the 
equal-tempered scale or the one declared on top of the Csound score, 
letting Csound the care of computing frequencies. Other values — 
"_scale(1)", "_scale(2)", "_scale(pythagorean)" etc. — would be other 
scales defined in the Csound instruments file. Scale numbers would be 
the order in which GEN51 tables have been listed on top of the Csound score.

We could have for instance:

{_ins(piano) _scale(piano) {C5,G5,C6}, _ins(shahnai) _scale(shahnai) G4_ 
E4} _scale(0) _ins(flute) G3 D3 C4

All this will indeed work with Csound. What about MIDI? In fact we could 
  have rewrite rules replacing "_scale(x)" with some MIDI 
system-exclusive instruction selecting a scale on a MIDI device. 
Similarily, _ins(x) instructions could be rewritten as program changes. 
This would be done in a Glossary file, e.g. "-gl.GeneralMIDI".

I am starting work on this new development. With great excitement ;-)

Bernard

[bp-dev] Csound microtonality

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

It is clear that once the GEN51 table has been read by the console, it 
has all required data to calculate frequencies and put them in 
replacement of octave point pitch-class values in the score. In this 
case, the table could even be removed from the score…

So, I guess that Csound has its own algorithm to do the same 
calculations. All we need to know is how a "i" note statement should be 
formatted to use this device. I have not found an example in the 
documentation.

For the user it makes no difference whether calculations are done by BP 
or by Csound…

Bernard

-------

Dear all,

I am  trying to implement the use of a microtonal scale — a 
"just-intonation" in replacement of "equal-tempered" scale — on project 
-gr.vina3.

So far I have been able to insert the function table for GEN51 on top of 
the score, with correct intervals — although I am not sure that the 
final "2" is required. See "f2" on top of the score. I am also enclosing 
"new-vina.orc" equipped with the little trick to discriminate between 
octave point pitch-class and cps input.

Now I guess that to build the score we should pick up frequency ratio 
values in "f2" and multiply them by the A4 frequency to get the 
frequency that will be taken care of by the orchestra.

What would be the actual process? If the console finds a GEN51 table it 
should be able to do the calculations and produce a suitable score.

This would be wonderful news because, on the side of the interface, when 
editing "-cs.Vina" we would also pick up the GEN51 table and create 
input fields to modify ratios and other parameters, including the number 
of steps in the scale, its tonal ambitus etc.

We could even deal with several scales selected by a reserved "scale" 
parameter, for instance _value(scale,1), _value(scale,2) to allow for 
enharmonic modifications depending on context.

So, this branch of creation/research can be opened at low cost thanks to 
Csound! :-)

Bernard

[bp-dev] Strange waveforms with 0-default.orc

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

Another problem is the low amplitude of signal produced by this 
orchestra. To use these sound files I need to amplify them by 18dB…

Bernard

-------

Dear Anthony,

"0-default.orc" produces beautiful plucked-string sounds but they look 
bizarre in a sound editor: there is a 0 Hz component displacing curves 
up ans down. (It has nothing to do with the pitchbend.)

The enclosed is a performance of:

_pitchcont _pitchrange(200) C5 _pitchbend(0) D5 _ _pitchbend(120) _ 
_pitchbend(-150) _ _ _pitchbend(0) E5

We need a low-cut filter! :-)

Bernard

[bp-dev] Strange waveforms with 0-default.orc

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

Dear Anthony,

"0-default.orc" produces beautiful plucked-string sounds but they look 
bizarre in a sound editor: there is a 0 Hz component displacing curves 
up ans down. (It has nothing to do with the pitchbend.)

The enclosed is a performance of:

_pitchcont _pitchrange(200) C5 _pitchbend(0) D5 _ _pitchbend(120) _ 
_pitchbend(-150) _ _ _pitchbend(0) E5

We need a low-cut filter! :-)

Bernard

[bp-dev] Csound microtonality

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

Dear all,

I am  trying to implement the use of a microtonal scale — a 
"just-intonation" in replacement of "equal-tempered" scale — on project 
-gr.vina3.

So far I have been able to insert the function table for GEN51 on top of 
the score, with correct intervals — although I am not sure that the 
final "2" is required. See "f2" on top of the score. I am also enclosing 
"new-vina.orc" equipped with the little trick to discriminate between 
octave point pitch-class and cps input.

Now I guess that to build the score we should pick up frequency ratio 
values in "f2" and multiply them by the A4 frequency to get the 
frequency that will be taken care of by the orchestra.

What would be the actual process? If the console finds a GEN51 table it 
should be able to do the calculations and produce a suitable score.

This would be wonderful news because, on the side of the interface, when 
editing "-cs.Vina" we would also pick up the GEN51 table and create 
input fields to modify ratios and other parameters, including the number 
of steps in the scale, its tonal ambitus etc.

We could even deal with several scales selected by a reserved "scale" 
parameter, for instance _value(scale,1), _value(scale,2) to allow for 
enharmonic modifications depending on context.

So, this branch of creation/research can be opened at low cost thanks to 
Csound! :-)

Bernard