bolprocessor-devel — Bol Processor developer discussion list

[bp-dev] Csound 6.17 doesn't work?

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

/The problem has been identified and will be fixed in version 6.18 of 
Csound/. ----------
Hello!

Currently we are facing a problem after replacing Csound 6.15 with 
Csound 6.17.

When calling " /usr/local/bin/csound --version" in the Terminal, both 
versions work perfectly.

However, when calling it via exec() or system() on a PHP page (namely 
_basic_tasks.php) the page hangs if version 6.17 is installed…

A Unix user already told me that he is getting "exit status 139" on Arch 
linux, which means "seg fault":
https://github.com/bolprocessor/php-frontend/issues/2

I tend to conclude that this problem is with Csound, perhaps we need to 
do something special in the configuration…

I posted a request on Csound forum:
https://github.com/csound/csound/issues/1633

All the best,

Bernard Bel

[bp-dev] Csound 6.17 doesn't work?

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

Hello!

Currently we are facing a problem after replacing Csound 6.15 with 
Csound 6.17.

When calling " /usr/local/bin/csound --version" in the Terminal, both 
versions work perfectly.

However, when calling it via exec() or system() on a PHP page (namely 
_basic_tasks.php) the page hangs if version 6.17 is installed…

A Unix user already told me that he is getting "exit status 139" on Arch 
linux, which means "seg fault":
https://github.com/bolprocessor/php-frontend/issues/2

I tend to conclude that this problem is with Csound, perhaps we need to 
do something special in the configuration…

I posted a request on Csound forum:
https://github.com/csound/csound/issues/1633

All the best,

Bernard Bel

[bp-dev] PHP Desktop, new development

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

Dear colleagues,

You may recall that in April 2021 I had started supporting PHP Desktop 
(https://github.com/cztomczak/phpdesktop) to initiate the development of 
a MacOS version. To make things clear, any version of PHP Desktop 
produces native desktop GUI applications running under Windows, Linux 
and MacOS. The only difference is that the forthcoming version will be 
installed on a Mac. I confess that I am very unskilled running Linux 
applications (apart from web servers)…

The good news is that funding of PHP Desktop/MacOS is now complete. 
Czarek Tomczak announced that "work started". Indeed, I am longing for 
the final product, given the challenge of creating a standalone 
application of BP3 running on the three popular platforms!

I take this opportunity to tell you that I updated many pages of the Bol 
Processor project website (https://bolprocessor.org), notably the 
homepage highlighting great features and perspectives for further 
development and applications. This updated presentation helped me to 
create many new connections on LinkedIn, all of whom are working in 
software development and/or sound design. We are in bad need for (even 
shortlived) collaborations to solve issues listed on 
https://github.com/bolprocessor/bolprocessor/blob/graphics-for-BP3/BP3-To-Do.txt

I made a point that we should welcome engineers eager to develop 
commercial products using (parts of) Bol Processor algorithms, as this 
should in turn pave the way to challenging musicological research…

Don't hesitate to publish viewpoints and questions in the "Comment" 
sections at the bottom of pages of the website… And install the latest 
version of BP3 (https://bolprocessor.org/check-bp3/) to try your own games.

All the best,

Bernard Bel

[bp-dev] The Well-tempered Clavier

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

Dear colleagues,

Recently (8 March) I had announced the implementation of a process named 
"tonal analysis" on BP3:
https://bolprocessor.org/tonal-analysis/

The basic idea was to evaluate the adequacy of a tonal scale (produced 
by a tuning scheme/procedure) to the rendering of a musical work, given 
a model of consonance of melodic and harmonic intervals.

This process is meaningful, when dealing with European Baroque music, 
owing to the detailed documentation of temperaments published by 
Pierre-Yves Asselin as an outcome of his PhD research: /Musique et 
tempérament 
<https://www.decitre.fr/livres/musique-et-temperament-9782905335005.html>/, 
Paris: Jobert (2000).

➡ I am sending a copy of this message to Pierre-Yves to urge him to 
publish an English version of his outstanding work!

Following the method applicable to physical stringed instruments 
(harpsichords), it is easy to "tune" an electronic instrument 
(programmed in Csound) and play music with its accurate intervals. The 
method for implementing these tuning schemes is explained on page 
"Microtonality":
https://bolprocessor.org/microtonality/

The next stage was to import musical scores in MusicXML format and 
convert them to Bol Processor "scores" — actually single polymetric 
expressions:
https://bolprocessor.org/importing-musicxml/

The scale-matching algorithm was enriched with a batch processing option 
making it possible to check many musical works against all scale models. 
At this stage it became logical to process J.S. Bach's entire corpus 
named "The Well-tempered Clavier":
https://bolprocessor.org/bach-well-tempered-tonal-analysis/

Batch processing is no magics: the result (which tuning scheme is the 
best choice for this piece?) depends on hypotheses of the composer's 
preference for various sizes of melodic/harmonic intervals. For 
instance, should we rate Pythagorean major thirds (frequency ratio close 
to 81/64) as "consonant" or "dissonant" in melodic intervals? In either 
case, what would be the positive/negative weight of each assessment?

Let us admit that this is a crude method — which I named the "deaf 
musicologist's approach" 
(https://bolprocessor.org/tonal-analysis/#a-deaf-musicologists-approach) 
— because the appreciation of tonal intervals may vary in different 
parts of the musical work. For instance, we might want to set hypotheses 
over ranges of measures in order to take this variability into 
consideration. This is technically possible although it requires a more 
detailed interface.

Tonal analysis applied to "The Well-tempered Clavier" yields different 
results depending on hypotheses. I tried two sets (named "standard" and 
"alternate") that seemed to make sense. The final decision is left to 
the ear. All musical works (48 preludes and fugues) can be checked on page:
https://bolprocessor.org/the-well-tempered-clavier/

Adding to the challenge, I included recordings of these works by human 
interpreters on their harpsichords.

The comparison is astonishing. Listen for instance to the recording of 
Fugue 2, book II, performed by Ottavio Dantone, and the same synthesised 
with a D'Alambert-Rousseau (or Kellner's BACH) temperament — my 
"alternate" hypothesis:

https://bolprocessor.org/misc/sounds/OttavioDantone2/F02.mp3
https://bolprocessor.org/misc/sounds/tonal2/Bach_book_II_2nd_fugue.mp3

As stated in my conclusive remarks 
(https://bolprocessor.org/the-well-tempered-clavier/#conclusive-remarks), 
such comparisons call for a greater awareness of the issue of tuning 
instruments when playing Baroque music, which in turn requires an 
accurate model of temperaments. In other words, the instrument should be 
tuned according to the musical corpus it aims at rendering, as advocated 
by Pierre-Yves Asselin.

This does not mean that interpretations with non-optimal tunings are 
"less musical". Great (human) performers explore different aspects of 
musicality if the tonal dimension is not cristal clear… Such is the case 
with "The Well-tempered Clavier" played on pianos presumably not 
"well-tempered" as figured out by J.S. Bach.

Listening to these works convinced me that European composers in that 
period (16th-17th century) had the same acute sense of tonality as 
Indian musicians performing ragas on long-stringed instruments such as 
the rudra vina. An exploration of the Indian concept — also supported by 
ancient musicology — has been proposed on page:
https://bolprocessor.org/raga-intonation/

Incidently, this research on Indian music started in 1980 as my 
colleague (the late Jim Arnold) met Pierre-Yves Asselin in Paris and 
demonstrated the "shruti harmonium" I had designed and built for these 
experiments. In French we say: « Le monde est petit »!

Don't hesitate to publish viewpoints and questions in the "Comment" 
sections at the bottom of pages… And install the latest version of BP3 
(https://bolprocessor.org/check-bp3/) to try your own analyses.

Bernard Bel

[bp-dev] Tonal analysis of musical items

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

Dear all,

A new process has been implemented on BP3 php interface, fully 
documented on page:
https://bolprocessor.org/tonal-analysis/

In brief, it calculates all melodic and harmonic intervals, using 
parameters that can be modified. Then it looks for a tonal scale that 
has been specified in the item, or it selects a tempered scale. Melodic 
and harmonic intervals are drawn in the image of the tonal scale, 
highlighting intervals (aand note positions) used in the performance.

This process is useful when looking for the best tuning scheme that may 
be used for a particular musical work, if "just intonation" (or 
consonance) is an issue. I have taken Baroque harpsichord pieces to 
illustrate this type of decision.

The implementation wasn't easy even if he code looks "evident". It 
required emulating the basic process of expanding polymetric expressions 
and building phase diagrams. Fortunately it wasn't as complicated as in 
the console because this process deals only with "simple notes": no 
sound-objects, no time patterns, no smooth time. Well, just Western 
classical music !

I am planning to extend this feature to a multiple evaluation of tuning 
schemes (temperaments) for a given musical work. This is addressed to 
"deaf musicologists".:-)

Bernard

[bp-dev] Bug in time-setting of time patterns (fixed)

[Bernard B. <be...@bo...>]

Dear all,

Checking the console with very old examples and recent trivial ones, I 
notived that the durations of silences could be wrong in some polymetric 
structures containing time-patterns, therefore associated with "smooth 
time":
https://bolprocessor.org/time-patterns-smooth-time/

This bug had been around for more than 30 years! Yet unnoticed because 
time-patterns (and smooth time in general) had become an obsolete 
approach in most cases after implementing the "_tempo" performance tool. 
Still, complex pattern structures might better respond to certain 
constraints, but this requires unusual compositional skills.

I am glad it has been fixed after 3 days/nights of intensive work, 
tracing these old algorithms!

All the best,

Bernard

[bp-dev] Pedals in MusicXML scores + controllers

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

Dear all,

I implemented the handling and seeting-up of pedals when importing 
MusicXML scores:
https://bolprocessor.org/importing-musicxml/#pedals

At the time of checking this option, I noticed that the pedal of my 
PianoTeq piano did not move whenever "Show graphics" was on in the 
settings… There was a bug in the C code discarding messages to some MIDI 
controllers. I fixed it and uploaded the correct C code version.

Validating pedal on/off controls in Listz's "La Campanella" scored by 
Heavilon makes a lot of difference!

All the best,

Bernard

[bp-dev] Important updates of C code

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

Dear all,

I worked on BP3 console source code and did a large number of changes, 
basically to eradicate multiple "warnings" in the compilation. Indeed 
there was no error and the console worked nicely — except for small 
details which I fixed — but my incentive is to have as clean as possible 
a code that will compile and run in diverse environments. I already felt 
relieved that Silvano confirmed a correct compilation (of the preceding 
version) working properly on Windows and Linux machines.

The main left-over issue of warnings in the compilation is the improper 
handling of multibyte Unicode characters. In the MacOS BP2 version 
special characters such as "•" for period notation, "…" for undetermined 
rests, "↵" for line breaks, and the "≥", "≤" and "≠" operators used in 
rule flags (read https://bolprocessor.org/flags/) were handled as simple 
chars by the Mac compiler. With Unicode these require multibyte 
procedures which I am not familiar with.

This is not a great burden because '•' and '…' are replaced with "." and 
"_rest" before sending data/grammars to the console. Line breaks are not 
necessary when editing on HTML forms. The trouble is number comparisons 
in flags, but since "<", ">" and "=" are available, most situations can 
be taken care of. In brief, there is no emergency upgrading to 
multibytes "wchar_t" types, but programmers conversant with the 
technique could plan it.

At least, we now compile source files all encoded in UTF8 since 
"high-ASCII" characters have been discarded.

While revising the code, I noticed large chunks of procedures that we 
are not currently using, either because these had been designed for the 
MacOS interface, or because they deal with real-time MIDI which we hope 
to finish implementing. With real-time MIDI we'll get access to non-stop 
improvisation, interactions with MIDI devices and scripts for a full 
automation of processes. The algorithms are ready, only waiting for the 
MIDI driver!

The BP3-To-Do text has been updated to summarize this state of development:
https://github.com/bolprocessor/bolprocessor/blob/graphics-for-BP3/BP3-To-Do.txt

New versions of the code, the PHP interface, and new data have been sent 
to GitHub. Follow links on the installation page:
https://bolprocessor.org/check-bp3/

Warm regards

Bernard

[bp-dev] Slurs and breaths in MusicXML files

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

Dear colleagues,

I implemented the translation of slurs and breath markers when importing 
MusicXML scores.

Explanations on page https://bolprocessor.org/importing-musicxml/

The set of updated PHPfiles has been submitted to GitHub:
https://github.com/bolprocessor/php-frontend

Both effects have been applied to the interpretation of François 
Couperin's “Les Ombres Errantes”:
https://bolprocessor.org/misc/sounds/Ombres_errantes_meantone_rameau_en_sib.mp3

Note the impressive consonances of this piece when played with a "Rameau 
en sib" temperament!

Bernard Bel

[bp-dev] Ornamentation in MusicXML files + BP3 development

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

Dear all,

I updated the algorithm for importing MusicXML scores to deal with 
ornamentation: mordents, turns and trills.

Explanations and examples on this page:
https://bolprocessor.org/importing-musicxml/

Please keep in mind that the aim of importing MusicXML scores is not to 
play them accurately — even though it is fun to try! We mainly wish to 
extract fragments of existing scores and reuse them for the production 
of new musical works. The polymetric format characteristic of Bol 
Processor "scores" makes it affordable to humans with more musical than 
computation skills… Don't hesitate to try after installing the current 
version of BP3 (https://bolprocessor.org/check-bp3/). Currently we are 
sure that it works in Mac and Linux environments. We still need a beta 
checker for Windows…

I need assistance for the two major development issues:

1) Designing a set of nice-sounding Csound instruments in te style of:
  + pipe organ
  + flute
  + piano
  + harpsichord
  + guitar
  + horn
  + saxo
  + marimba
  + drums

2) Using the platform of PHPdesktop 
(https://github.com/cztomczak/phpdesktop) to compile standalone versions 
of the BP3 interface working under MacOS, Linux and Windows. This is 
already possible running the Linux version of PHPdesktop, but my 
knowledge of Linux is insufficient — and I am too old/lazy to invest 
training time… To this effect, I am contributing via regular donations 
to the PHPdesktop project. So, if everything goes well, a MacOS version 
of PHPdesktop should be available by the end of this year. Meanwhile, a 
programmer conversant with Linux should try to produce this standalone 
application that will render BP3 accessible to the widest community of 
computer music experts.

Fans of microtonality and modal music may appreciate the comparison of 
meantone temperaments highlighted by two musical works of the late 
Baroque period in Europe:
https://bolprocessor.org/comparing-temperaments/
My apologies to ears accustomed to the sound of acoustic harpsichords!
If you own MusicXML scores of more pieces with indications of their 
recommended tunings, please share them.

All the best for a musical year!

Bernard Bel

[bp-dev] An interview with James Kippen

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

Dear all,

Jim Kippen is undoubtedly the co-inventor of Bol Processor — initially, an expert system for the modelling of compositional/improvisational processes by North-Indian drum players. The whole venture started in the summer of 1981, as we met in the foothills of the Himalayas…

The whole story is told on page:

https://bolprocessor.org/kippen-interview/

A French version is also accessible: https://bolprocessor.org/kippen-interview-fr/

Don't hesitate to share it!

I hope we can resume development work in the next weeks or months. Currently I am stuck with technical problems demanding more competence with Csound (instrument design), UDP, Linux, CoreMIDI etc.
There's too much on the agenda for a single programmer lacking expertise of recent tools… If you can join and share some of your experience for a few weeks, I am confident we will soon be able to release a standalone version of BP3. :-)

All the best!

Bernard Bel

Re: [bp-dev] Towards a standalone application - trying PHP Desktop

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

Dear Anthony,

It is a great pleasure to receive news from you! I had been reassured by 
Liz that your silence is related to good news. :-)

We have plenty of time, no deadlines. Today I am building a Ubuntu 
startup disk for the Macbook. The installer doesn't see the partition 
formated as MS-DOS, so I am trying different volumes, different methods 
and different versions…

I took advantage of being the sole contributor to development of the 
console: it was necessary to revise intricate algorithms in depth and 
get a  stable application, which very complex items (imported 
fromMusicXML) allowed to test. Not yet being familiar with multiple 
contributions to the GitHub repertory, I felt safe to focus on these 
aspects. Needless to say, none of the real-time MIDI code has been modified! 


Once the possibility of building a standalone application is confirmed I 
will return to Csound issues: implementing a UDP driver to interact with 
the Csound console in real time, and looking for more orchestra files in 
links sent by Jean Piché. Real-time Csound interaction might even make 
it possible to use their MIDI input.

Probably I will proceed further, laying the ground for Open Sound 
Control (OSC) as it would give access to PYO 
(http://ajaxsoundstudio.com/software/pyo/) and various recent sound 
software.

Distributing a standalone version in the current state may bring 
beta-users and hopefully contributers to the development!

All the best

Bernard


Anthony Kozar wrote on 22/04/2021 19:16:
> PHP Desktop sounds promising. Definitely no reason that I can see to pay for an expensive license of a proprietary product that as you say will not likely have a long life. Without the source code for such a product, we would be completely out of luck when it dies. 
>
>
> Sorry that I have been so quiet this year.  I have embarked on a new adventure here at home that is currently consuming all of my time. I regret that we did not finish BP 3.0.0 before now but maybe in a couple of months I will be able to find a little time to work on it now and then.  I think we should release version 3.0.0 sometime this year even if it is not really "finished". 
>
>
> Thanks for keeping the project going a Bernard! :-)
>
> Anthony
>
> On Apr 22, 2021 11:29 AM, Bernard Bel <ber...@gm...> wrote:
>
>> Dear all,
>>
>> I spent a long time looking for a proper platform to build a standalone
>> desktop version of BP3 based on the PHP/HTML/Javascript files of its
>> interface.
>>
>> I wasted energy and time trying LIANJA. First I needed to buy an
>> external SSD drive and install a recent MacOS system. This took a while
>> because of "firmware errors" and unavailable installations. Then LIANJA
>> itself — in its 30-day trial — was an obsolete and unstable version.
>> Gradually I found its limitations and real work environment: it does not
>> convert a set of PHP files, it is merely an application builder using
>> PHP (and other languages) for scripting its web-like content. Well, the
>> kind of package we were already using in the late 1980s to build
>> projects that would collapse forever as soon as the company stopped
>> selling and upgrading their magical product… It made me angry to waste
>> so much time because their "technical service" never came up with
>> constructive suggestions, only repeating the ready-made commercial
>> injonction to buy and install "version 6" developed for MacOS Big Sur
>> which my MacBook will never run. UTF-8 wasn't fully supported and even
>> crashed the application… And I was ready to pay 1000 USD per year for
>> LIANJA!
>>
>> Finally I returned to the collection of packages and listed the
>> requirements of the compilation platform:
>> https://bolprocessor.org/standalone-application/
>>
>> The only evident match seemed to be "PHP Desktop"
>> (https://github.com/cztomczak/phpdesktop) which is in full swing of
>> development in its Linux version. And free of charge! I contacted
>> Czarek, the designer, who immediately confirmed that all listed
>> requirements would be met.
>>
>> I installed Ubuntu on an external disk and I am going to try "PHP
>> Desktop" as soon as possible. :-)
>>
>> In case it works I will certainly send monthly contriibutions to support
>> Czarek's creation of a MacOS version.
>>
>> Bernard Bel
>>
>> _______________________________________________
>> 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] Towards a standalone application - trying PHP Desktop

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

Dear Anthony,

It is a great pleasure to receive news from you! I had been reassured by 
Liz that your silence is related to good news. :-)

We have plenty of time, no deadlines. Today I am building a Ubuntu 
startup disk for the Macbook. The installer doesn't see the partition 
formated as MS-DOS, so I am trying different volumes, different methods 
and different versions…

I took advantage of being the sole contributor to development of the 
console: it was necessary to revise intricate algorithms in depth and 
get a  stable application, which very complex items (imported 
fromMusicXML) allowed to test. Not yet being familiar with multiple 
contributions to the GitHub repertory, I felt safe to focus on these 
aspects. Needless to say, none of the real-time MIDI code has been modified!

Once the possibility of building a standalone application is confirmed I 
will return to Csound issues: implementing a UDP driver to interact with 
the Csound console in real time, and looking for more orchestra files in 
links sent by Jean Piché. Real-time Csound interaction might even make 
it possible to use their MIDI input.

Probably I will proceed further, laying the ground for Open Sound 
Control (OSC) as it would give access to PYO 
(http://ajaxsoundstudio.com/software/pyo/) and various recent sound 
software.

Distributing a standalone version in the current state may bring 
beta-users and hopefully contributers to the development!

All the best

Bernard


Anthony Kozar wrote on 22/04/2021 19:16:
> PHP Desktop sounds promising. Definitely no reason that I can see to pay for an expensive license of a proprietary product that as you say will not likely have a long life. Without the source code for such a product, we would be completely out of luck when it dies.
>
> Sorry that I have been so quiet this year.  I have embarked on a new adventure here at home that is currently consuming all of my time. I regret that we did not finish BP 3.0.0 before now but maybe in a couple of months I will be able to find a little time to work on it now and then.  I think we should release version 3.0.0 sometime this year even if it is not really "finished".
>
> Thanks for keeping the project going a Bernard! :-)
>
> Anthony
>
> On Apr 22, 2021 11:29 AM, Bernard Bel <ber...@gm...> wrote:
>
>> Dear all,
>>
>> I spent a long time looking for a proper platform to build a standalone
>> desktop version of BP3 based on the PHP/HTML/Javascript files of its
>> interface.
>>
>> I wasted energy and time trying LIANJA. First I needed to buy an
>> external SSD drive and install a recent MacOS system. This took a while
>> because of "firmware errors" and unavailable installations. Then LIANJA
>> itself — in its 30-day trial — was an obsolete and unstable version.
>> Gradually I found its limitations and real work environment: it does not
>> convert a set of PHP files, it is merely an application builder using
>> PHP (and other languages) for scripting its web-like content. Well, the
>> kind of package we were already using in the late 1980s to build
>> projects that would collapse forever as soon as the company stopped
>> selling and upgrading their magical product… It made me angry to waste
>> so much time because their "technical service" never came up with
>> constructive suggestions, only repeating the ready-made commercial
>> injonction to buy and install "version 6" developed for MacOS Big Sur
>> which my MacBook will never run. UTF-8 wasn't fully supported and even
>> crashed the application… And I was ready to pay 1000 USD per year for
>> LIANJA!
>>
>> Finally I returned to the collection of packages and listed the
>> requirements of the compilation platform:
>> https://bolprocessor.org/standalone-application/
>>
>> The only evident match seemed to be "PHP Desktop"
>> (https://github.com/cztomczak/phpdesktop) which is in full swing of
>> development in its Linux version. And free of charge! I contacted
>> Czarek, the designer, who immediately confirmed that all listed
>> requirements would be met.
>>
>> I installed Ubuntu on an external disk and I am going to try "PHP
>> Desktop" as soon as possible. :-)
>>
>> In case it works I will certainly send monthly contriibutions to support
>> Czarek's creation of a MacOS version.
>>
>> Bernard Bel
>>
>> _______________________________________________
>> 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] Towards a standalone application - trying PHP Desktop

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

PHP Desktop sounds promising. Definitely no reason that I can see to pay for an expensive license of a proprietary product that as you say will not likely have a long life. Without the source code for such a product, we would be completely out of luck when it dies.

Sorry that I have been so quiet this year.  I have embarked on a new adventure here at home that is currently consuming all of my time. I regret that we did not finish BP 3.0.0 before now but maybe in a couple of months I will be able to find a little time to work on it now and then.  I think we should release version 3.0.0 sometime this year even if it is not really "finished".

Thanks for keeping the project going a Bernard! :-)

Anthony

On Apr 22, 2021 11:29 AM, Bernard Bel <ber...@gm...> wrote:

> Dear all,
>
> I spent a long time looking for a proper platform to build a standalone 
> desktop version of BP3 based on the PHP/HTML/Javascript files of its 
> interface.
>
> I wasted energy and time trying LIANJA. First I needed to buy an 
> external SSD drive and install a recent MacOS system. This took a while 
> because of "firmware errors" and unavailable installations. Then LIANJA 
> itself — in its 30-day trial — was an obsolete and unstable version. 
> Gradually I found its limitations and real work environment: it does not 
> convert a set of PHP files, it is merely an application builder using 
> PHP (and other languages) for scripting its web-like content. Well, the 
> kind of package we were already using in the late 1980s to build 
> projects that would collapse forever as soon as the company stopped 
> selling and upgrading their magical product… It made me angry to waste 
> so much time because their "technical service" never came up with 
> constructive suggestions, only repeating the ready-made commercial 
> injonction to buy and install "version 6" developed for MacOS Big Sur 
> which my MacBook will never run. UTF-8 wasn't fully supported and even 
> crashed the application… And I was ready to pay 1000 USD per year for 
> LIANJA!
>
> Finally I returned to the collection of packages and listed the 
> requirements of the compilation platform:
> https://bolprocessor.org/standalone-application/
>
> The only evident match seemed to be "PHP Desktop" 
> (https://github.com/cztomczak/phpdesktop) which is in full swing of 
> development in its Linux version. And free of charge! I contacted 
> Czarek, the designer, who immediately confirmed that all listed 
> requirements would be met.
>
> I installed Ubuntu on an external disk and I am going to try "PHP 
> Desktop" as soon as possible. :-)
>
> In case it works I will certainly send monthly contriibutions to support 
> Czarek's creation of a MacOS version.
>
> Bernard Bel
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Towards a standalone application - trying PHP Desktop

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

Dear all,

I spent a long time looking for a proper platform to build a standalone 
desktop version of BP3 based on the PHP/HTML/Javascript files of its 
interface.

I wasted energy and time trying LIANJA. First I needed to buy an 
external SSD drive and install a recent MacOS system. This took a while 
because of "firmware errors" and unavailable installations. Then LIANJA 
itself — in its 30-day trial — was an obsolete and unstable version. 
Gradually I found its limitations and real work environment: it does not 
convert a set of PHP files, it is merely an application builder using 
PHP (and other languages) for scripting its web-like content. Well, the 
kind of package we were already using in the late 1980s to build 
projects that would collapse forever as soon as the company stopped 
selling and upgrading their magical product… It made me angry to waste 
so much time because their "technical service" never came up with 
constructive suggestions, only repeating the ready-made commercial 
injonction to buy and install "version 6" developed for MacOS Big Sur 
which my MacBook will never run. UTF-8 wasn't fully supported and even 
crashed the application… And I was ready to pay 1000 USD per year for 
LIANJA!

Finally I returned to the collection of packages and listed the 
requirements of the compilation platform:
https://bolprocessor.org/standalone-application/

The only evident match seemed to be "PHP Desktop" 
(https://github.com/cztomczak/phpdesktop) which is in full swing of 
development in its Linux version. And free of charge! I contacted 
Czarek, the designer, who immediately confirmed that all listed 
requirements would be met.

I installed Ubuntu on an external disk and I am going to try "PHP 
Desktop" as soon as possible. :-)

In case it works I will certainly send monthly contriibutions to support 
Czarek's creation of a MacOS version.

Bernard Bel

[bp-dev] Zero-crash version!

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

Dear all,

I worked hard during the past 2 weeks, trying to understand 
irregularities in the interpretation of large items (imported from 
MusixXML scores) sometimes leading to crashes (or loops) in the 
console's code.

This incited me to check how complex ratios are processed, e.g. a rest 
lasting 35542/24783 beats. Additional code was needed to get the correct 
durations and avoid overflows that might end up with crashes.

Read documentation on this topic: 
https://bolprocessor.org/complex-ratios-polymetric/

I also solved the problem of apparently non-matching pairs of tied 
notes. Now, mismatches can be explained and their reasons are outside 
the code, except one remaining untied pair in Beethoven's Fugue in B 
flat major, which I find too difficult to isolate and trace at the moment.

Read documentation on this topic: https://bolprocessor.org/tied-notes/

It has become my priority to document algorithms as soon as the code has 
been fixed and relate them to issues in real musical examples. Otherwise 
I feel unable to come back and fix errors after a week or two!

I suggest that you listen to the imported musical works on page 
https://bolprocessor.org/importing-musicxml/
I am fond of listening to Oscar Peterson's "Watch What Happens" and 
Beethoven's Fugue. :-)
No false notes if algorithms are correct!
I would never dream that BP3 would be able to process such complex 
pieces as a single "polymetric expression"… Time accuracy = 10 milliseconds.

I am now struggling to get an installation of MacOS Catalina on an 
external SSD disk and run a test of LIANJA to construct a standalone 
application compiled from PHP pages.

Next step will be trying the UDP connection with Csound. :-)

Bernard

[bp-dev] Optimizing code, a great step!

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

Dear all,

I worked several days on optimizing code in BP3 console. More precisely, 
understanding (and solving) crashes on large structures… The outcome is 
a much more stable version which so far hasn't crashed on the largest 
pieces imported from MusicXML.

Back in the 1990s, I was doing the same on BP2, trying to solve crashes 
on complex structures produced by grammars, notably designs by composer 
Harm Visser who enjoyed experiments with recursive rules! In those days, 
physical limitations such as memory space and computation time were the 
major limitations. To solve this, I developed data compression in 
polymetric structures, then time quantization. Both have been major 
achievements because they resulted in structures making sense to humans, 
unlike compression algorithms used for text, sound or images.

At present, BP3 is dealing with much larger structures, for instance the 
full performance of Beethoven's Fugue in B-flat major played by 4 
instruments. (Listen to it on 
https://bolprocessor.org/importing-musicxml/) First of all, the 
construction of its phase diagram requires the handling of integers 
larger than the largest "unsigned long"… These have been replaced with 
"double" floating-point numbers which the machine is likely to 
approximate at unpredictable points. The result is the production of 
incorrect numbers when rounding down to the actual line/column indices 
of the phase diagram. An error of a single unit can be fatal, which is 
illustrative of the time accuracy BP3 is trying to achieve — most often 
10 milliseconds.

Errors are likely to produce crashes when screening the phase diagram 
does not yield the expected result. These were the issues I was facing. 
I did a thorough check of all steps in time-setting algorithms which 
turned out successful.

Limitations are still "physical" but the amount of RAM seems to be much 
larger than required for this (optimized) processing of data and 
grammars. Computation time is sometimes a problem: creating the MIDI 
file or Csound score for Beethoven's Fugue takes 349 seconds on my 
mid-2012 PowerBook using the standard "PLAY" procedure. However, this 
time is reduced to 38 seconds if the "PLAY safe" procedure is invoked, 
chunking the piece to 41 slices. Both produce the same sound output, but 
the latter does not produce pictures. A couple of "tied notes" are 
missed — which means they are played twice instead of being merged — but 
my guess so far is that these are errors in the MusicXML code.

This morning I also worked on the optimization of CANVAS pictures used 
for pianoroll and sound-object graphics, hiding parts that would be 
plotted beyond a limit and render the image invisible on (at least) 
Firefox and Chrome. Surprisingly, images must be cropped to 32767 pixels 
but you can plot right/down to 65535!

I am now waiting for an installation of MacOS Catalina on a new startup 
disk that will allow me to try the LIANJA platform 
(https://www.lianja.com/) to create standalone applications using the 
PHP/Javascript code of the beta version of BP3. If this works, it will 
pave the way to a large distribution of BP3.

Bernard Bel

[bp-dev] MusicXML interface

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

Dear colleagues,

Work on MusicXML conversion is now completed — subject to more checks of 
large scores — and documented here:
https://bolprocessor.org/importing-musicxml/

This was complex because of the presence of performance controls (tempo 
and volume) in the MusicXML in addition to indications for the printed 
score (e.g. "prestissimo"). Finally, the interface offers options for 
reading a choice of these controls. After importing, changes are 
possible such as MIDI channels and Csound instrument assignments.

Items can be very complex (e.g. “-da.Hungarian_Rhapsody”) which created 
difficulties playing them back. Even if importing scores is aimed at 
picking up fragments for reusing them in compositions, the machine 
should be able to prove that it "understood" the score…

To manage large sizes I implemented an automatic segmenting of the item 
to "chunks" containing a smaller number of measures. A measure is 
interpreted as a polymetric expression. Measure borders can be 
identified by checking the levels of { } parentheses. The Console reads 
all these chunks and plays them in a perfect sequence (no time gap).

This is not a perfect solution because measures also contain notes which 
are tied to neighbouring measure(s). If these do not belong to the same 
chunk, ties will be boken and notes striked again instead of being 
elongated. Therefore, when chunking the item, ties are detected to chunk 
together measures with tied-note dependencies. Once a minimum number of 
measures are tied in this way, an approximate evaluation of dependency 
makes it possible to break the chunk without breaking any ties.

After playing back, messages indicate which tied notes have been broken 
in the process. For a reason I do not yet understand, 26 broken ties are 
detected in Liszt's 14th Rhapsody played in a single piece, and only 2 
broken ties when it is played in chunks. This should be the opposite!

The number of measures in a chunk is allowed to increase up to a certain 
limit (currently 50). This limit is set by the interface.

Being unsatisfied with this chunking (the "PLAY safe" command) I worked 
on solving overflow problems. Apparently with success because now the 
large items (Liszt's 14th Rhapsody and Beethoven's Fugue in Bflat major) 
can be played in one piece. This is a great achievement except that it 
take a great deal of computation time, compared with processing the 
chunked version. This is probably due to the time-setting algorithm that 
should be deactivated when the item does not contain sound-objects with 
topological properties.

For the time being I dropped the idea of using MusicXML as an output 
format. For a simple reason: MuseScore imports MIDI files, displays them 
on scores and exports them to MusicXML and many other formats! Why 
bother to do the same?

I am now going to pay attention to software converting 
PHP/Javascript/HTML packages to standalone applications for 
MacOS/Windows/Linux. This would be a perfect solution for creating a 
standalone BP3!

Bernard

[bp-dev] PLAY-ITEM + MusicXML

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

Dear friends and colleagues,

I am delighted to announce that the "play-item" action has been 
implemented in the console.

This implementation solved several pending issues because the input 
required as an "item" is a "bpda" data file created by the interface in 
a "temp" folder. This avoids sending data, variables, startup string 
etc. via the command line.

In practice:

1) On a Grammar window buttons are automatically created for each 
variable in the grammar. (This means a large number for a grammar like 
"-gr.Mozart".) Clicking the button generates an item using the variable 
as a start string. This includes the sound output from MIDI or from 
Csound, and graphic representations if this option is selected.

2) At the bottom of the same window is a textarea form for entering any 
expression (containing variables and/or terminal symbols) that can be 
saved an played in the same way. The interface even makes sure that 
polymetric expressions {} are balanced.

A typical command sent to the console is:

../bp play-item -se ../ctests/-se.Mozart -da 
../temp_bolprocessor/-gr.Mozart_18570907f3dcaa6a5651a9265846aafa_temp/startup.bpda 
-gr ../ctests/../ctests/-gr.Mozart -cs ../csound_resources/-cs.Mozart -d 
--csoundout ../my_output/Mozart.sco --traceout 
../temp_bolprocessor/trace_18570907f3dcaa6a5651a9265846aafa.txt

3) On a Data window, a side column is created listing all "items" found 
in the data file. (One item for each valid line)
Here also the {} balance is checked. A "PLAY" button plays this item.

There are also "EXPLODE" and "IMPLODE" buttons. EXPLODE will break every 
item to play separate polymetric expressions, which is very useful when 
checking complex items. IMPLODE brings them bak together.

If a "-gr" file is declared in the options, then it is possible to 
include variables that the grammar will try to derive.

There is more than that!

The MusicXML converter is ready and it works fine on the Data window. 
You can import  a MusicXML score and convert it automatically. As many 
scores include several parts (for instance "voice", "violin", "piano" 
etc.) it is possible to select parts and play them separately. The 
EXPLODE button will break the score further: most likely down to one 
item for each measure.

I checked this converter with a set of scores stored in a "xmlsamples" 
folder shared in the "ctests" folder. It works fine. One item gave me a 
lot of trouble because of an error in the interpretation of polymetric 
expression… Well, a whole day of work to change a ">" to a ">="! The 
trouble was due to the management of MIDI channels accross expressions.

I still hope to improve this converter with respect to the 
interpretation of grace notes. Calculating a reasonable duration is not 
an easy task, fingers of musicians are much better at it!

Now we have music but we need instruments… ;-)

All the best,

Bernard

[bp-dev] MusicXML interface

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

Dear all,

I am starting work on a MusicXML interface for BP.
https://en.wikipedia.org/wiki/MusicXML

First I will implement a MusicXML to BP data interface on the PHP 
interface. It will convert a score in Common Music Notation and store 
its as a "-da" file.

Next, the "-da" file will be sent to the console along with (optionally) 
a grammar, at least a "-se" file for fixing the note convention, tempo, 
diapason, output format etc., and optionally a "-cs" Csound resource 
file to provide Csound instruments and microtonal scales.

There is an urgent need for this device to check scale models against 
non-trivial musical pieces.

Another stage of development will be done on the console: an option for 
using MusicXML as the output format. This is indeed a broader 
perspective because we'll need to decide what to include in the file and 
make it more useful than a pianoroll output. This will require a study 
of a few MusicXML score examples of complex polyrythmic patterns, and 
their equivalent as polymetric expressions. Lot of work ;-)

I uploaded an update of the "BP3-To-Do.txt" file containing this proposal.

I also set up SSH key authentication for GitHub anticipating it to 
become mandatory in August. Follow instructions:
https://docs.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

Bernard

[bp-dev] UDP connection to Csound

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

Dear friends and colleagues,

I am more and more convinced that we should develop BP3's output to 
Csound in priority to MIDI.

This will give us access to unlimited sound production algorithms with 
no additional hardware, with a better control of all parameters, among 
which the use of microtonal intervals.

So, the next step will be to "stream" scores to Csound or simply send 
instructions line by line via a convenient network layer. I asked the 
question to forum.csound.com — a brand new forum, mine was the first 
message!

It received an immediate reply (by Rory and Steven) both suggesting the 
implementation of a UDP connection between the two devices. Since I only 
remember UDP from old tutorials on TCP/IP (and mentions on firewalls) I 
searched for documentation and found this very informative page:
https://www.geeksforgeeks.org/udp-server-client-implementation-c/

and the UDP topic in Csound:
https://csound.com/docs/manual/udpserver.html

I believe that this all makes sense. I am going to focus on this topic 
now that scales/microtonality and related subjects have been covered.

Once we have this connection we may install  BP3 on a cloud server, 
given that users will have their own Csound running on  local machine, 
waiting for instructions from the remote client… I hope I have 
understood this correctly.

All suggestions welcome as they might save days and weeks of work! ;-)

Bernard

[bp-dev] A multicultural model of consonance

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

Dear colleagues,

I have just published and shared an article on LinkedIn summarizing my 
past months of development on BP3:

https://www.linkedin.com/pulse/multicultural-model-consonance-bernard-bel/

A multicultural model of consonance

This was an opportunity for renewing contact with Pierre-Yves Asselin, 
an organ player and instrument maker in Montréal (Quebec). We had met in 
Paris in 1980! His work has been of immense help for research on 
microtonal intonation and tuning systems… His descriptions of meantone 
tempered tunings have all  been implemented in "-cs.tryTunings".

Now we need a more advanced Csound output. I am working on it. ;-)

Bernard Bel

[bp-dev] Real-time Csound?

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

Dear all,

Since I have been using almost exclusively Csound with BP3 and 
developing console/interface features compliant with Csound (and not 
MIDI), I am getting more convinced that we should focus on Csound in our 
current design.

The basic question is: are there things that MIDI devices can do unlike 
Csound? Indeed, we may want to use our favorite hardware to produce 
sounds (my old good D-50!). But in theory Csound can achieve (and 
outpass) the same sophistication.

Are there things that Csound can do unlike MIDI? Indeed yes, for 
instance microtonality, controlling the output via an unlimited number 
of "instruments" instead of MIDI channels, etc. Even MIDI channel events 
can be used by Csound because of the optional mapping of every MIDI 
channel to a Csound instrument in the "-cs" file.

So, the major incentive for implementing real-time MIDI is that of 
having real-time input/output. But why not try the same with Csound?

I find it hard to read most of the Csound literature because it makes 
reference to external pieces of software which I am not familiar with. 
Still, I understand that Csound is able to handle "real-time output" 
either in terms of sound production and even in MIDI. This might be an 
excellent offer: assuming that Csound is able to process a streamed 
Csound score, we would only need to use the XYZ driver to send scores in 
real time from BP3 to Csound. Let then leave to Csound the burden of 
creating sounds or converting these scores to MIDI output… This is 
reasonable because Csound scores (produced by BP) store events in 
chronological order.

We would hit two targets with a single shot: real-time output via Csound 
and MIDI! This would also make BP3's "continuous improvization" feasible 
in both environments.

Another reason for streaming out Csound scores is that a similar device 
could be used on BP3 interface to create notes via a HTML image 
keyboard. On the microtonal scale interface I dream to have buttons that 
will produce sounds at the exact frequencies of notes, using the Csound 
orchestra listed in the same "-cs" file.

The only thing that this development would not render possible is the 
real-time control of BP2 via a (MIDI) keyboard or another device: 
scripts activated by MIDI events. This will be another venture!

Bernard

[bp-dev] BP3 agenda

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

Dear friends and colleagues,

I haven't sent news for more than a month… The New Year is an 
opportunity to send my wishes for health, success and feeling of 
security in 2021. Most of us are witnessing or enduring tragedies that 
demand efficiency of actions and quietness of mind to remain happy and 
constructive.

Being retired in a small village (690 inhabitants) I have no difficulty 
cultivating this clarity of mind in a safe environment. I spend most of 
my time reflecting on musicological issues that had been addressed long 
time ago, yet left incomplete because of changes in the priorities of 
our agendas or departure of co-workers. The sanitary situation is there 
to remind us that life is short and it is important to terminate work 
that may become useful to others even after a long time.

When my colleague Arnold met a young student named Pierre-Yves Asselin 
in Paris in 1980, I did not not imagine that I would be studying his PhD 
thesis 40 years later in great detail for its insights into the complex 
issue of scale models. In 1994 I met a very modest person named C.K. 
Raju at the guesthouse of Centre for the Development of Advance 
Computing in Pune (India) but I could not imagine that his masterpiece 
"Cultural Foundations of Mathematics" would make sense of my entire work 
30 years later. These are lessons of patience and determination in 
achieving a destiny that we build ourselves in such moments. Never miss 
the right person, the right word, the right book; this is an increasing 
difficult task as we are saturated with (mis)information!

I have completed and documented developments of BP (mainly its 
interface) with respect to "just intonation", checking and merging 
advanced systems elaborated in India and  Europe/America during the past 
centuries. All links are in the "Musicology" category of our website: 
https://bolprocessor.org/category/related/musicology/
The documentation is modified every time I read it again because I need 
to make sure that explanations are clear and all steps can be reproduced 
by experimenters of BP. Indeed we'll need more musical examples!

I will now work on temperament techniques because it remains true that 
musicians prefer to use the same scale in all harmonic contexts of their 
production! All techniques will be exposed and documented.

At the beginning of the year it is time to revise the agenda of Bol 
Processor. Developing MIDI out/in indeed remains on the agenda but it 
may not be the first priority. Owing to Csound, BP3 can be used in a 
very productive manner. If we attract interest and support from Csound 
experts we will be able to publish examples of convincing examples using 
the sophistication of Csound orchestras. Work on microtonality will be 
an incentive to design examples and tutorials but BP should not be 
reduced to this feature.

In fact we need to provide an easier access to BP3. I doubt that many 
users (if any) will undertake installing MAMP, compiling the source code 
and trying the PHP interface. Sure it  works on Mac but there remain 
open questions on other systems… So, the best way would be to proceed 
with the installation of an online version. Anthony, does your offer of 
hiring space still hold? In case it is costly we could create a PayPal 
account and collect a little money to cover the expense of hosting the 
platform.

At this stage, this online version could do everything we do on our 
local machines, which is a lot (when using Csound) given that MIDI 
in/out will never be streamed real-time over the Net (as I understand 
it). So, I believe it is time to envisage this development…

I am enclosing a revised BP3-To-Do.txt file which I have just pushed to 
GitHub.

All the best!

Bernard

PS. Contact me in a private message if you face difficulties. I 
sometimes feel anxious not receiving news…

[bp-dev] Work on raga intonation completed

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

Dear colleagues,

I have completed the documentation and sharing of work on "Raga 
intonation" and related issues, demonstrating features of Bol 
Processor's (BP3) microtonal scale editor in the context of 
musicological research:

https://bolprocessor.org/raga-intonation/
https://bolprocessor.org/two-vina-experiment/
https://bolprocessor.org/just-intonation-framework/

The "grama-murcchana" theoretical model is a revival of work done in the 
early 1980s by my colleague Jim Arnold. Links to publications are given 
along with scans of papers not available in digital format.

For this project I had undertaken the design and construction of two 
monumental pieces of hardware: the "Shruti Harmonium" and the "Melodic 
Movement Analyzer". Building electronic equipment in early 1980s India 
was an interesting challenge…

Reading again published material and unpublished research notes 
convinced me that this model (in its full extension) deserves being 
shared with music/science communities. Its scope extends much beyond the 
(controversial) issue of raga intonation, its initial focus. Both in 
Western and "extra-European" contexts, the concept of "just intonation" 
is confusing as you may notice reading Wikipedia pages on the topic. 
Published information is reliable but it is driven by competitive models 
which lack consistency and completeness.

I remember with great nostalgy these years of research in New Delhi 
running two projects, one on raga intonation and the other one on 
rhythmic structures with the Bol Processor. I was convinced that these 
were entirely distinct activities. But now, BP3 is returning to India to 
have its word on intonation! ;-)

I am now planning to work on tuning schemes with the worthy material 
published by Pierre-Yves Asselin. He documented tuning techniques used 
in middle-age Europe. Again I will manage to formalize the model in a 
manner conducive to the design of versatile and comprehensive interfaces.

Bernard Bel