In the standard use of the Bol Processor, all data is stored in the "bolprocessor" folder located in the "htdocs" folder created by MAMP or XAMPP. Read the installation instructions for more details. This is acceptable in most cases because Bol Processor data is basically made of text files that do not take up much space.
However, there are a number of reasons why a user might want to store data in locations other than the "bolprocessor" folder:
Need for additional space
Avoid storing data on the startup disk
Sharing data with other applications and other users
Sharing data via a cloud device (e.g. DropBox).
A procedure for moving the entire "bolprocessor" folder is described in the installation instructions: for example, in the MacOS environment. Unfortunately, as of today, the relocated installation does not work on MacOS with XAMPP after a reboot, unless the "BolProcessorInstaller.pkg" installer is run again. The same problem might exist in both Windows and Linux environments where MAMP or XAMPP is used.
In fact, there is not much interest in relocating the entire "bolprocessor" folder. Moving data folders outside this folder will suffice. This tutorial will tell you how to do this.
The first time you install the Bol Processor, the "bolprocessor" folder will contain a unique folder called "ctests" for storing data. This folder contains examples that are updated when a new version is installed. However, you can use it to store new projects, new subfolders, etc., which will not be affected by new versions.
You can also create your own folders (and subfolders) at the same level as "ctests". The interface is designed for the creation, moving and deletion of folders and files within the "bolprocessor" folder. Always use the interface. Creating a folder (or a file) via the Finder or File Manager may not work, especially with XAMPP, because the owner may be different from the Apache server's identity. For geeks:XAMPP runs as "daemon" while the Finder runs as your personal identity.
Creating folders and files without using the Bol Processor interface may result in "permission errors" when a file is saved. Indeed, there are workarounds, for those familiar with shell scripts, for example the "change_permissions.sh" script designed for Linux and MacOS. But this is not a pleasant way to use the Bol Processor…
In short, always create folders using the CREATE FOLDERS function in the interface. Once created, they can be moved (even with the Finder or File Manager) within the "bolprocessor" folder, and even renamed. The Bol Processor will always recognise them as its own.
Below is an example of two folders called "data" and "my_data" created at the same level as "ctests":
Now, how can we move a folder outside the "bolprocessor" folder? Once we've moved it, the interface no longer shows it. For example, let us do this with "my_data". (The folder may be empty or contain other folders and files.)
Using the Finder in MacOS, or copy/paste in Windows and Linux, we move "my_data" to the desired location, for example a "MUSIC" folder at the root of an external drive called "EXT". Make sure that this location accepts read/write operations.
At this point, there is no more "my_data" in "bolprocessor", or we delete it using the DELETE FOLDERS button. You can't delete "ctests" with this delete function.
To make "my_data" visible again from its remote location, we need to create a symbolic link. Unfortunately, the Bol Processor's interface cannot do this due to security restrictions. I've spent hours with a chatbot trying to find a workaround!
In MacOS and Linux, the symbolic link is created from a (Unix) Terminal. In Windows, you will use the Windows PowerShell (admin).
This procedure doesn't work with aliases created by the Finder in MacOS. You really need to use symbolic links.
MacOS or Linux
Open the Terminal (in the Applications folder) and point it to the "htdocs" directory. For those unfamiliar with Unix commands, you will need to type "cd " (followed by a space) and drag "htdocs" to the end of this command, then press "return". You can type the instruction "ls -al" to see the contents of "htdocs", which contains "bolprocessor", "ctests", and more.
Suppose that your"MUSIC" folder is on disk "EXT" and you want to link to the relocated "my_data" folder. Type this command:
ln -s /Volumes/EXT/MUSIC/my_data my_data
This will create the "my_data" symbolic link pointing to the remote "my_data" folder. Check that the link has been created by typing "ls -al".
Depending on the disk or disk area used to store relocated data, you might encounter problems due to MacOS access restrictions, especially if the System Integrity Protection (SIP) is enabled.
If you are using a recent installer (as of 3 Feb 2025) and a XAMPP Apache server, the 'daemon' identity used by XAMPP is automatically added to the 'admin', 'wheel' and 'staff' groups which are commonly used by the Finder.
There are probably fewer restrictions with MAMP because this server runs under your personal identity, and file owners are set to that identity.
Windows
Right-click the start icon at the bottom left of the screen, and select Windows PowerShell (admin). Then type the following command to create a symbolic link — in fact a junction (/J instead of /D):
If you are using XAMPP, replace "\MAMP\" with "\xampp\".
Depending on the disk or disk area used to store relocated data, you may encounter issues due to Windows 10 access restrictions.
For example, moving your data to the OneDrive directory won't work by default. If you must keep the target folder inside OneDrive, you must disable the synchronisation of your files:
Open OneDrive Settings
Go to "Choose folders"
Uncheck your data folder(s).
Return to the Bol Processor
Now, the BolProcessor interface will show "my_data" as if the folder was in "bolprocessor". If it doesn't, make sure that the paths used to create the link were correct.
Make sure that you can create and save data in the relocated folder. Welcome to shared projects!
This page is intended for developers of the Bol Processor BP3 (read installation). It is not a formal description of the algorithms carried by the console's C code, but rather an illustration of their management of musical processes, which may be useful for checking or extending algorithms.
When the Bol Processor produces MIDI material (real-time or files), each note is associated with two events: a NoteOn at its beginning and a NoteOff at its end. Additional parameters are its velocity (range 0 to 127) and its MIDI channel (range 1 to 16).
When a keyboard instrument is used to produce the sound, each NoteOn will press a key at the appropriate location. By default, note C4 (in English notation) will press key #60. A NoteOff of the same pitch will release the key.
All examples on this page can be found in the "-da.checkNoteOff" project. NoteOn/NoteOff tracking can be enabled by selecting this option in the "-se.checkNoteOff" settings of the project.
Two (or more) consecutive NoteOns of the same note and the same channel should not be sent to a MIDI instrument. Nevertheless, the attacks of C4, which occur at the 1.00 s and 2.00 s times in this example, should be audible. To achieve this, they are automatically preceded by a NoteOff.
The list of NoteOn/NoteOff events is as follows:
NoteOn C4 channel 1 at 0 ms NoteOff C4 channel 1 at 1000 ms NoteOn C4 channel 1 at 1000 ms NoteOff C4 channel 1 at 2000 ms NoteOn C4 channel 1 at 2000 ms NoteOff C4 channel 1 at 5000 ms NoteOn D4 channel 1 at 5000 ms NoteOff D4 channel 1 at 6000 ms
This feature is not necessary for the creation of Csound scores. The score generated by this example is as follows:
A large random time (50 ms) has been chosen to make the graphs clearer. In general, _rndtime(x) is used for a less mechanical rendering of simultaneous notes, with 10 to 20 ms being the recommended value for keyboard instruments.
Errors would occur if the order of fast notes were reversed. However, this does not happen because the timing of the NoteOns in fast movements is not made random:
The same excerpt with 50 ms random time, except on the starting fast sequence C#4 D4 C#4.
Below we will deal with the elimination of some NoteOns except in fast movements: read Dealing with fast movements.
The following example is the (slowed down) first measure of François Couperin's Les Ombres Errantes (1730) (read page) with a quantization of 50 ms and a randomisation of 50 ms:
First measure of François Couperin's Les Ombres Errantes (1730) with quantization and randomised NoteOns
These relatively high values have been chosen to show that the order of notes is respected in fast movements. Quantization (typically 20 ms) is generally necessary to play a complicated polymetric structure, such as an entire piece of music. Once the times of the NoteOns have been calculated and rounded to the quantization grid, they are given small random changes. However, notes in a fast motion (C5 B4 C5) and the first note after this motion (B4) are excluded from the randomisation.
Duplication of notes in a MusicXML score
When several MIDI channels are used, we can imagine that each of them controls a separate keyboard, or that the channels are combined to control the same keyboard. The first case is called Omni Off Poly mode and the second case is called Multi mode (see details).
Importing music from MusicXML scores often creates a Bol Processor score that uses different MIDI channels (or Csound instruments). If the music is sent on a single channel or played by an instrument in Multi mode, there may be overlaps for the same note assigned to different channels.
This situation is also found in music imported from MusicXML scores (see details of this process). For example, again the first measure of François Couperin's Les Ombres errantes:
Original staff (source) - Creative Commons CC0 1.0 Universal
This (slowed down) interpretation is microtonally adjusted according to the Rameau en si bémol temperament (see explanation).
Notes at the bottom of the staff: Eb4, D4, C4 are shown both as quarter notes and as eight notes. As this dual status cannot be managed in the MusicXML score, they are duplicated (link to the XML score). This duplication is necessary for the conventional representation of the staff.
The staff would look less conventional if the redundant eight notes Eb4, D4, C4 were suppressed (link to the modified XML score):
Modified staff drawn by MuseScore 3
The output of the Bol Processor from the original XML score is as follows, with duplicate notes clearly marked:
A sound-object display of the Bol Processor's interpretation of the MusicXML score. Note that the durations of C5 and Eb5 are extended to allow slurs to be played correctly (see explanation)
The Bol Processor score is an overlay of three lines created by sequentially interpreting the XML score:
Eliminating the redundant eight notes Eb4, D4, C4 would require a backtracking to modify the second line when reading the notes of the third line. But this complicated process is not necessary because the Bol Processor handles duplicate notes correctly. The following piano roll shows this:
A piano roll display of the Bol Processor's interpretation of the MusicXML score.
This rendering requires a proper control of NoteOffs and NoteOns. This can be done in several ways. (For geeks) we present the old method (before version BP3.2) and the new one.
The old method
Events listed by the PianoTeq synthesiser
The image on the right shows the beginning of a sequence of MIDI events played by a synthesiser. (The date "6.802" is actually time 0.) Events are distributed on separate MIDI channels to allow for microtonal adjustments by the pitchbender. (Pitchbender messages are not displayed.)
The performance starts with a NoteOnC5, then a NoteOnEb4 at the same date. However, another NoteOnEb4 is required at the same time. However, two NoteOns of the same note and the same channel should not be sent to a MIDI instrument. so, a NoteOffEb4 is sent just before the second NoteOnEb4, all at the same time. In this way, the first NoteOn/NoteOffEB4 sequence is not audible because its duration is zero.
At time 1 second, a NoteOnC4 is sent as expected. The sound-object graph shows that the Eb4 eight note is ending, but no NoteOff is sent because the Eb4 quarter note should continue to sound. The NoteOffEb4 will only occur at time 2 seconds.
The new method
In the old method, sequences of NoteOn and Noteoff of the same note could be sent to the synthesiser at the same time. This worked because the NoteOn/Noteoff order was respected, and they could be processed by the synthesiser even if the times were (almost) identical. The new method aims to eliminate this case.
To achieve this, the machine calculates "MaxDeltaTime", an estimate of the maximum time between two NoteOns (of the same note and channel), beyond which they should be interpreted as separate events. If dates are randomised by _rndtime(x), then MaxDeltaTime is set to 2 times x. Otherwise it is set to 2 times the quantization. If there is no quantization and no randomisation, it is set to 20 milliseconds.
A Trace NoteOn/Noteoff option can be selected in the new version to display the sequence of notes along with indications of decisions made to send or keep a NoteOn message. Here is the sequence for the first measure of Couperin's Les Ombres Errantes randomised to ± 50 ms and quantified to 20 ms. Therefore, we expect MaxDeltaTime to be set to 100 milliseconds.
NoteOn Eb4 channel 1 at 2 ms NoteOn C5 channel 1 at 14 ms ? Eb4 channel 1 at = 27 ms, last = 2, delta = 25 > 100 ms ¿ NoteOn G4 channel 1 at 1031 ms ? C5 channel 1 at = 1955 ms, last = 14, delta = 1941 > 100 ms ¿ NoteOff C5 channel 1 at 1955 ms NoteOn C5 channel 1 at 1955 ms NoteOn D4 channel 1 at 1995 ms NoteOff Eb4 channel 1 at 2002 ms ? D4 channel 1 at = 2030 ms, last = 1995, delta = 35 > 100 ms ¿ NoteOff G4 channel 1 at 2031 ms NoteOn B4 channel 1 at 2159 ms ? C5 channel 1 at = 2316 ms, last = 1955, delta = 361 > 100 ms ¿ NoteOff C5 channel 1 at 2316 ms NoteOn C5 channel 1 at 2316 ms NoteOff B4 channel 1 at 2326 ms NoteOff C5 channel 1 at 2483 ms NoteOn B4 channel 1 at 2497 ms NoteOn F4 channel 1 at 2961 ms NoteOn C4 channel 1 at 3951 ms NoteOff F4 channel 1 at 3961 ms NoteOff D4 channel 1 at 3995 ms NoteOff B4 channel 1 at 3997 ms NoteOn Eb5 channel 1 at 4031 ms ? C4 channel 1 at = 4040 ms, last = 3951, delta = 89 > 100 ms ¿ NoteOn Eb4 channel 1 at 4981 ms NoteOff C4 channel 1 at 5951 ms NoteOff Eb4 channel 1 at 5981 ms NoteOff Eb5 channel 1 at 6431 ms
This trace shows that the machine compared the time interval between successive NoteOns of the same note and channel. On the green line, this interval was 25 ms, which is less than 100 ms, so the Eb4NoteOn (of the duplicated note) was discarded. On the red lines, the intervals were greater than 100 ms and the NoteOns were played.
Channel information is irrelevant, as microtonal adjustments assign a specific channel to each note and its pitchbend adjustment. However, this selection of NoteOns is made prior to the assignment of specific channels for microtonal corrections.
Dealing with fast movements
The new method (BP3.2.0 and higher) eliminates NoteOns of the same note and channel if they occur in an interval less than MaxDeltaTime. However it takes into account fast movements. For example:
In this example, two different occurrences of C#4 should be separated by less than MaxDeltaTime (100 ms). The following trace shows that the sequence C#4 D4 C#4 (a trill) has been identified as a fast movement, and no time separation condition has been applied:
NoteOn C#4 channel 1 at 0 ms NoteOn E5 channel 1 at 14 ms NoteOff C#4 channel 1 at 31 ms NoteOn D4 channel 1 at 31 ms NoteOff D4 channel 1 at 62 ms NoteOn C#4 channel 1 at 62 ms NoteOn B3 channel 1 at 493 ms NoteOff C#4 channel 1 at 500 ms NoteOff E5 channel 1 at 514 ms NoteOn A4 channel 1 at 531 ms NoteOn E5 channel 1 at 955 ms NoteOn C#4 channel 1 at 983 ms NoteOff B3 channel 1 at 993 ms NoteOff A4 channel 1 at 1031 ms NoteOff E5 channel 1 at 1455 ms NoteOff C#4 channel 1 at 1483 ms
A quantization of 20 ms may not be desirable for rendering fast movements such as:
{1/16, C4 - E4 F4} {15/16, G4 A4 B4}
The graphic shows that notes E4 and F4 have been assigned the same time (60 ms)
If the quantization is set to 10 ms, the differentiation of the timings is retained:
NoteOn C4 channel 1 at 0 ms NoteOff C4 channel 1 at 15 ms NoteOn E4 channel 1 at 31 ms NoteOff E4 channel 1 at 46 ms NoteOn F4 channel 1 at 46 ms NoteOff F4 channel 1 at 62 ms NoteOn G4 channel 1 at 62 ms NoteOff G4 channel 1 at 375 ms NoteOn A4 channel 1 at 375 ms NoteOff A4 channel 1 at 687 ms NoteOn B4 channel 1 at 687 ms NoteOff B4 channel 1 at 1000 ms
Installing the Bol Processor BP3 does not require any programming skills. Just download and run the installers for MacOS and Windows, or the installation scripts for Linux.
To use the Bol Processor BP3, you first need to install a local Apache HTML/PHP server on your desktop computer. This server runs a dedicated "web service" that is restricted to your computer. Only PHP (with its GD Graphics option) needs to be running, as no database is used by the Bol Processor interface.
On MacOS and Windows we recommend MAMP or XAMPP, both of which are Apache servers with pre-installed features. On Linux, XAMPP is the only choice. This part of the implementation is described on the pages that show the installation of BP3 in the different environments, see below.
Once you've installed MAMP or XAMPP, installing Bol Processor is almost a one-click process.
MacOS users can quickly do the installation using a (certified) installer called BolProcessorInstaller.pkg. Follow instructions on this page.
Windows users can quickly do the installation using a (certified) installer called BolProcessorInstaller.exe. Follow instructions on this page.
Linux users can quickly do the installation using dedicated scripts. Follow instructions on this page.
👉 Once you've installed the Bol Processor BP3, visit this page to familiarise yourself with how to use it.
The file structure of your installation
👉 Only for geeks!
Let us assume that your installation was successful. It created a "htdocs/bolprocessor" folder.
The file structure inside this folder is shown on the left. There is nothing related to Bol Processor outside of this folder.
This image includes "bp" which is the compiled version of the BP3 console for MacOS. The console is called "bp.exe" in Windows and "bp3" in Linux. In Linux, "bp3" will not be visible immediately after the installation because it needs to be created (in a single click) by the compiler. In Windows, "bp.exe" is installed, so that no compilation is required. The same is true for "bp" in MacOS.
The "temp_bolprocessor" and "my_output" folders are automatically created when the interface is run. The contents of the "temp_bolprocessor" folder is cleared of all files/folders older than 24 hours which were created in a different session.
Another folder called "midi_resources" is also created to store the settings for your real-time MIDI input and output ports.
Two additional folders, "csound_resources" and "tonality_resources", are created by the installation and filled with data shared by all projects.
Running the interface will also create "BP2_help.html" in the "php" folder using "BP2_help.txt" as its source.
The "ctests" folder — which we call a workspace — contains sample material used to check the operation of Bol Processor and to illustrate some musicological issues. It is updated by the installation scripts each time you upgrade to a new version.
If you create new material in the "ctests" workspace it won't be deleted by upgrades. However, if you modify files that come from the distribution, they will revert to the current distribution version on each upgrade. It is therefore a good idea to keep a copy of the "ctests" folder, as you are likely to modify some of its data files while using the program. You may want to restore the original versions later. You can also create your own workspaces (in tree structures) using your computer's file manager.
The core of the Bol Processor, in all its versions, is an inference engine capable of generating 'items' — strings of variables and terminal symbols — treated like the score of a musical work. The inference engine does this through the use of rules from a formal grammar.
In its initial versions (BP1 and BP2), the inference engine was also able to analyse a score — for example, a sequence of drum beats — to check its validity against the current grammar. This feature is not (yet) implemented in BP3.
A brief presentation of grammars
The grammars used by the Bol processor are similar to those described in formal language theory with a comprehensive layout:
Rules can be context-sensitive, including with remote contexts on the left and the right.
Rules can contain patterns of exact or pseudo repetitions of fragments. Pseudo repetitions make use of transformations (homomorphisms) on the terminal symbols.
A terminal symbol represents a time object which can be instantiated as a simple note or a sound object, i.e. a sequence of simple actions (MIDI messages or Csound score lines).
The grammars are layered — we call them 'transformational'. The inference engine first does everything it can with the first grammar, then jumps to the second, and so on.
The “produce all items” procedure
Grammars can produce infinite strings of symbols if they contain recursive rules. This is of no practical use in the Bol Processor, as it will eventually lead to a memory overflow. When recursive rules are used, control is exercised by dynamically decreasing rule weights or using 'flags' to invalidate recursivity.
This means that the machine only generates finite languages within its technical limitations. Theoretically, it should be able to enumerate all productions. This is the aim of the "produce all items" procedure. In addition, identical items are not repeated; to this effect, each new item is compared with the preceding ones.
For geeks:This is done by storing productions in a text file which is scanned for repetitions. The efficiency of this method depends on the technology of the working disk. A SSD is highly recommended!
A simple example
Let us start with a very simple grammar "-gr.tryAllItems0" which is made up of two layers of subgrammars:
-se.tryAllItems0 -al.abc
RND gram#1[1] S --> X X X gram#1[2] S --> X X ----- RND gram#2[1] X --> a gram#2[2] X --> b
The RND instruction indicates that the rules in the grammar will be selected randomly until no rule applies. The first subgrammar produces either "X X X" or "X X", then the machine jumps to the second subgrammar to replace each 'X' with either 'a' or 'b'.
In the " Produce all items" mode, rules are called in sequence, and their derivations are performed by picking up the leftmost occurrence of the left argument in the work string.
In the settings of " tryAllItems0 " (see picture), "Produce all items" is checked. A parameter " Max items produced" can be used to limit the number of productions.
The output is set to "BP data file" for this demo, although real-time MIDI, MIDI files and Csound score are possible because 'a' and 'b' are defined as sound-objects. However, the sound output is completely irrelevant with this simple grammar.
Any production that still contains a variable is discarded. This never happens with the " tryAllItems0 " grammar.
The production of this grammar is:
a a a a a b a b a a b b b a a b a b b b a b b b a a a b b a b b
All the steps are shown on the self-explanatory trace:
S X X X a X X a a X a a a a a b a X a a a a a b a a b X a b a a b b a X b a a b a b b X a X a a X a a a a a b X a a a a a b a a b a X b a a b a b X a b a a b b a b X X a a X a a a a a b a X a a a a a b a a b X a b a a b b a X b a a b a b b a b X X b a X b a a b a b b X a b a a b b a b b X b b a b b b b X b b a b b b b X b X a b X a b a a b b X b a a b a b b a b b X b b a b b b X b b a b b b b b X X b a X b a a b a b b X a b a a b b a b b X b b a b b b b X b b a b b b b b X X a X a a a b X a a a b a b X b a b b X b a b b b
A pattern grammar
Let us modify "-gr.tryAllItems0" as follows:
-se.tryAllItems0 -al.abc
RND gram#1[1] S --> (= X) X (: X) gram#1[2] S --> X X ----- RND gram#2[1] X --> a gram#2[2] X --> b
The first rule gram#1[1] contains a pattern of exact repetition: the third 'X' should remain identical to the first one. Keeping the pattern brackets, the production would be:
(= a) a (: a) (= a) b (: a) (= b) a (: b) (= b) b (: b) a a a b b a b b
This output shows that the third terminal symbol is a copy of the first. These items can be played on MIDI or Csound, as the machine will remove structural markers. However, structural markers can also be deleted on the display by placing a " _destru" instruction under the "RND" of the second subgrammar. This yields
a a a a b a b a b b b b a a a b b a b b
To become more familiar with patterns (including embedded forms), try "-gr.tryDESTRU" in the "ctests" folder.
A more complex example
Consider the following grammar "-gr.tryAllItems1" in the "ctests" folder:
RND gram#1[1] S --> X Y /Flag = 2/ /Choice = 1/ ----- RND gram#2[1] /Choice = 1/ /Flag - 1/ X --> C1 X gram#2[2] /Choice = 2/ X --> C2 X _repeat(1) gram#2[3] <100-50> /Choice = 3/ X --> C3 X gram#2[4] X --> C4 _goto(3,1) gram#2[5] Y --> D3 Gram#2[6] X --> T ----- RND gram#3[1] T --> C5 _failed(3,2) gram#3[2] Y --> D6
This grammar uses a flag 'Choice' to select which of the rules 1, 2 or 3 will be used in subgrammar #2. Just change its value to try a different option, as they produce the same 'language'. Terminals are simple notes in the English convention: C1, C2, etc.
The flag 'Flag' is set to 2 by the first rule. If 'Choice' is equal to 1, rule gram#2[1] is applied, and it can only be applied twice due to the decrementation. This ensures that the language will be finite.
Rule gram#2[4] contains a "_goto(3,1)" instruction. Whenever it is fired, the inference engine will leave subgrammar #2 and jump to rule #1 of subgrammar #3. If the rule is a candidate, it will be used and the engine will continue to look for candidate rules in subgrammar #3. If the gram#3[1] rule is not applicable, the engine will jump to rule #2 of subgrammar #3, as instructed by "_failed(3,2)". In fact, these _goto() and _failed() instruction have no effect on the final production, but they do modify the trace.
If 'Choice' is equal to 2, the " _repeat(1)" instruction will force the gram#2[2] rule to be applied two times. If 'Choice' is equal to 3, the rule gram#2[3] will be applied twice because it has an initial weight of 100 which is reduced by 50 after each application. When it reaches zero, the rule is neutralised.
Capturing MIDI input opens the way to "learning" from the performance of a musician or another MIDI device. The first step is to use the captured incoming NoteOn/Noteoff events, and optionally ControlChange and PitchBend events, to build a polymetric structure that reproduces the stream.
The difficulty of this task lies in the design of the most significant polymetric structure — for which AI tools may prove helpful in the future. Proper time quantization is also needed to avoid overly complicated results.
We've made it possible to capture MIDI events while other events are playing. For example, the output stream of events can provide a framework for the timing of the composite performance. Consider, for instance, the tempo set by a bass player in a jazz improvisation.
The _capture() command
A single command is used to enable/disable a capture: _capture(x), where x (in the range 1…127) is an identifier of the 'source'. This parameter will be used later to handle different parts of the stream in different ways.
_capture(0) is the default setting: input events are not recorded.
The captured events and the events performed on them are stored in a 'capture' file in the temp_bolprocessor folder. This file will later be processed by the interface.
(Examples are found in the project "-da.tryCapture".
The first step to use _capture() is to set up the MIDI input and more specifically its filter. It should at least treat NoteOn and NoteOff events. ControlChange and PitchBend messages can also be captured.
If the pass option is set (see picture), incoming events will also be heard on the output MIDI device. This is useful if the input device is a silent device.
It is possible to create several inputs connected to several sources of MIDI events, each one with its own filter settings. Read the Real-time MIDI page for more explanations.
Another important detail is the quantization setting. If we want to construct polymetric structures, it may be important to set the data to the nearest multiple of a fixed duration, typically 100 milliseconds. This can be set in the settings file "-se.tryCapture".
Simple example
Let us take a look at a very simple example of a capture on top of a performance.
C4 _D4 _capture(104) E4 F4 G4 _capture(0) A4 B4
The machine will play the sequence of notes C4 D4 E4 F4 G4 A4 B4. It will listen to the input while playing E4 F4 G4. It will record both the sequence E4 F4 G4 and the notes received from a source tagged "104".
Suppose that the sequence G3 F3 D3 was played on top of E4 F4 G4. The capture file might look like this:
It should be noted that all the dates are approximated to multiples of 100 milliseconds, i.e. the quantization. For example, the NoteOff of input note G3 falls exactly on the date 3000 ms, which is the NoteOff of the played note E4.
The recording of input and played notes starts at note E4 and ends at note G4, as specified by _capture(104) and _capture(0).
An acceptable approximation of this sequence would be the polymetric expression:
C4 D4 {E4 F4 G4, - - G3 - F3 - D3 - -} A4 B4
Approximations will be automatically created from the capture files at a later stage.
Pause and capture
MIDI input will continue to be captured and timed correctly after the Pause button is clicked. This makes it possible to play the beginning of a piece of music and stop exactly where an input is expected.
Combining 'wait' instructions
Try:
_script(wait for C3 channel 1) C4 D4 _capture(104) E4 F4 G4 _script(wait for D3 channel 1)_capture(0) A4 B4
The recording takes place during the execution of E4 F4 G4 and during the unlimited waiting time for note D3. This allows events to be recorded even when no events are being played.
The C3 and D3 notes have been used for ease of access on a simple keyboard. The dates in the capture file are not incremented by the wait times.
The following is a setup for recording an unlimited sequence of events while no event is being played. Note C0 will not be heard as it has a velocity of zero. Recording ends when the STOP or PANIC button is clicked.
_capture(65) _vel(0) C0 _script(wait forever) C0
Interpreting the recorded input as a polymetric structure will be made more complex by the fact that no rhythmic reference has been provided.
Microtonal corrections
In the following example, both input and output receive microtonal corrections of the just intonation scale.
Below is a capture file obtained by entering G3 F3 D3 over the sequence E4 F4 G4 A4. Note the pitchbend corrections in the last column, which indicate microtonal adjustments. The relevant values are those that precede NoteOns on the same channel.
The output events (source 0) are played on MIDI channel 2, and the input events (source 104) on MIDI channel 1. More channels will be used if output notes have an overlap — see the page MIDI microtonality. In this way, pitchbend commands and the notes they address are distributed across different channels.
Added pitchbend
In the following example, a pitchbend correction of +100 cents is applied to the entire piece. It does modify output events, but it has no effect on input events.
Again, after playing G3 F3 D3 over the sequence E4 F4 G4 A4:
Pitchbend corrections applied to the input (source 104) are only those induced by the microtonal scale. Pitchbend corrections applied to the output (source 0) are the combination of microtonal adjustments (see previous example) and the +100 cents of the pitchbend command.
Capturing and recording more events
The _capture() command allows you to capture most types of MIDI events: all 3-byte types, and the 2-byte type Channel pressure (also called Aftertouch).
Below is a (completely unmusical) example of capturing different messages.
The capture will take place in a project called "-da.tryReceive":
The recording will have a "111" marker to indicate which events have been received. Only two notes D4 are played during the recording, the second one is raised by 50 cents and has a channel pressure of 35 and a modulation of 42.
After playing back the two D4s, the machine will wait until the STOP button is clicked. This gives the other machine time to send its own data and have it recorded.
The second machine is another instance of BP3 — actually another tag on the interface's browser with the "-da.trySend" project:
This project will start by sending "{_vel(0) <<C0>>} " which is the note C0 with velocity 0 and duration null (an out-time object). This will trigger "-da.tryReceive" which waited for C0. The curly brackets {} restrict velocity 0 to the note C0. Outside of this expression, the velocities are set to their default value (64). In this data, channel pressure, modulation and a pitchbend correction of +100 cents are applied to the final note E3.
The resulting sound is terrible, you've been warned:
Performed and captured events. Forget the way it sounds and look at the file below!
However, the 'capture' file shows that all events have been correctly recorded:
Captured events (from "-da.trySend") are coloured red. They have been automatically assigned to MIDI channel 2, so that corrections will not be mixed between performance and reception.
The pitchbend corrections are shown in the "cents correction" column, each applied to its own channel.
The channel pressure corrections (coloured blue) display the expected values. The modulation corrections (in the range 0 to 16383) are divided into two 3-byte messages, the first carrying the MSB and the second the LSB.
There is a time mismatch of approximately 150 milliseconds between the expected and actual dates, but the durations of the notes are accurate. The mismatch is caused by the delay in the transmission of events over the virtual port. The data looks better if the quantization in the "-da.tryReceive" project is set to 100 ms instead of 10 ms. However, this is of minor importance, as a "normalisation" will take place during the (forthcoming) analysis of the "capture" file.
For geeks: The last column indicates where events have been recorded in the procedure sendMIDIEvent(), file MIDIdriver.c.
Capture events without the need to perform
The setup of the "-da.tryReceive" project should be for example:
_capture(99) _vel(0) C4 _script(wait forever)
Note C4 is not heard due to its velocity 0. It is followed with all MIDI events received by the input until the STOP button is clicked. This makes it possible to record an entire performance. The procedure can be checked with items produced and performed by the Bol Processor.
Note that the inclusion of pitchbend messages makes it possible to record music played on microtonal scales and (hopefully) identify the closest tunings suitable for reproduction of the piece of music.
For example, try to capture the following phrase from Oscar Peterson's Watch What Happens:
Only significant columns are displayed. The origin of dates is set to the first NoteOn or NoteOff received.
The next task on our agenda will be to analyse the 'capture' file and reconstruct the original polymetric expression (shown above) or an equivalent version. Then we can consider moving on to grammars, similar to what we've done with imported MusicXML scores (read page).
From the outset, I have viewed the "Bol Processor" project as a research endeavor rather than a straightforward software design project. Its focus is on "computational musicology," which involves using computational models to explore musicology across and beyond cultural boundaries.
This project represents a long-term commitment to developing music creation tools that address musicological challenges, rather than simply recombining pre-composed music or sound fragments. Our current goal is to integrate this approach with high-quality music and sound editors used by composers and sound designers.
The research nature of this project necessitates an open-access ethic. As such, the "Bol Processor" — including its installation and source files — will remain freely accessible. Software developers are encouraged to reuse the source code to create variants or updated versions of BP3.
However, there is a practical reason why I have chosen not to decline personal donations: I am increasingly incurring costs for various tools required for software development. These include hosting fees, the remuneration of "virtual" assistants (AI tools), and, when necessary, human experts.
For this reason, if you are so inclined, you can make a donation using the PayPal link below. Any funds not used for project related activities will be transferred to charities.
This page is a demo of the handling of microtonality in the real-time MIDI and MIDI file environments of the Bol Processor BP3 (version 3.0.7 and higher). Install BP3 by following the instructions for MacOS, Linux and Windows on the page Bol Processor 'BP3' and its PHP interface.
All examples here are from the "-da.tryMPE" project, which is part of the ctests folder (download here). The syntactic model for microtonality is explained here. For details on working with real-time MIDI, read the Real-time MIDI page. Some Csound scores are shown for the sake of clarity, as the handling of microtonality in the Csound environment of BP3 produces the same results as MIDI.
👉 The following is a comprehensive but detailed presentation of all aspects of the use of microtonality in BP3. It is not necessary to understand the details when starting with microtonality! The explanation is only intended to assist musicians who wish to create new material by combining several tuning schemes in the same musical work. To try the microtonal process on real musical works, listen for instance to the comparison of temperaments, or play François Couperin's Les Ombres Errantes (in the ctests/Imported_MusicXML folder) on a MIDI instrument using its optimal tuning scheme rameau_en_sib:
Couperin's Les Ombres Errantes, Csound rendering with scale rameau_en_sib ➡ Image
For geeks: Microtonality in real-time MIDI and MIDI files mimics the MIDI Polyphonic Expression (MPE) method of modifying pitchbend values on notes distributed on separate channels (up to 15 simultaneous notes). However, it works on devices that are not MPE-compliant.
Check pitchbender sensitivity
Make sure that your output MIDI device is sensitive to pitchbend messages. Try the following:
You should hear C4 F4 D4 Bb3 C4 instead of C4 C4 C4 C4 C4. This shows that the MIDI device accepts pitchbend messages and that its range is ± 200 cents, or ± 2 semitones. This is the range we use for microtonality.
For geeks: The actual values are in the range 0 - 16383, but thanks to the "_pitchrange(200)" instruction, the actual cent values can be used.
When using microtonal scales, this pitch range of ± 200 cents is set automatically by sending an appropriate message to the 16 MIDI channels.
The "_pitchbend()" commands will be taken care of, and their values will be added to the pitchbend commands that adjust the pitches to the microtonal scale. If this combination exceeds the range of ± 200 cents, an error message will be displayed.
MIDI channels
In the previous example, MIDI events (notes and pitchbender commands) were sent on channel 2. This is to ensure that your MIDI output device is receiving and mixing all channels, technically MIDI mode 4 (omni off, mono).
It was possible to send messages on channel 2 because the Microtonality mode was not set. This mode is set on as a "_scale()" command is found. In this case, the "_chan()" commands are ignored, as all channel assignments are made by the microtonality process.
Diapason tuning
Since note frequencies are displayed when the Trace microtonality mode is activated in "-se.tryMPE", the tuning of the diapason (note A4/la 3 on a conventional keyboard) is important.
By default (in Bol Processor settings and on MIDI devices) this setting is 440 Hz. If you change the value in the settings, the note frequencies will change accordingly. The BP3 will send a message to the MIDI device to tune the diapason, but many devices do not understand this command. (This is the case with PianoTeq Stage.) In this case, tune the device independently.
Microtonal scales
On top of project "-da.tryMPE" you can see the line:
-to.tryMPE
This refers to a tonality resource stored in the "tonality_resources" folder. This resource has been downloaded to your computer when running an installer (or a Linux script) as explained on pages Quick install MacOS, Quick install Windows, or Quick install Linux.
At the bottom of the project page there is a button called EDIT '-to.tryMPE'. This will take you to this resource:
Here are the scales stored in "-to.tryMPE":
Most of these are "exotic" in the sense that they won't produce interesting music. They have been designed to highlight technical features:
The grama scale is an interpretation of the Indian system that divides the octave into "twenty-two shrutis", see The two-vina experiment for details. We use one particular (probably incorrect) solution, which sets the pramana shruti at 21 cents. Technically speaking — the reason for this choice — this scale has 23 grades which count as 22 notes. Click the EDIT button to see its structure.
The just intonation scale is a standard scale with 12 grades and 12 notes, probably suitable for use in some harmonic contexts. Click the EDIT button and display the image to see that it has a wolf's fifth between D and A.
The meantone_try scale is purely technical. It has 12 grades and 7 notes. The grades are approximately semitones and the notes suggest the white keys of a piano keyboard. Another feature is that it has an extended octave of 1219 cents instead of 1200. Notes are labelled by key numbers.
The meantone_try2 scale is identical to meantone_try except that its base key is #64 instead of #60. This may be necessary to use specific key numbers of the keyboard of the MIDI output device.
The piano scale has 12 grades and 12 notes. It is an equal-tempered scale with an extended octave of 1204 cents. An interesting point is that all its fifths are perfect (see picture).
The zest24-supergoya17plus3_Db scale was created by importing its SCALA definition (from this archive). It covers a conventional octave (ratio 2/1) with 20 grades, but the SCALA file did not contain any note names. So, 12 notes were chosen at random, with key numbers as their names.
The Bohlen-Pierce scale which has a "tritave" interval of ratio 3/1 instead of 2/1 in the octave. The tritave is divided into 13 grades and 13 notes (see Wikipedia and picture).
These scales cover all the cases necessary to check the technical operation of microtonality handling in real-time MIDI, MIDI files, and Csound environments. Don't expect to hear interesting music in the following examples! Only make sure that Trace microtonality is checked in "-se_tryMPE", so that you can read cent corrections in the trace.
The second argument to the "_scale()" command is called the block key. It is the key whose frequency should remain equal to that of a conventional 12-grade equal-tempered scale (a standard tuning of electronic instruments). If it is set to 0 or 60, this means that the block key is the 60th key on a piano keyboard, usually called "middle C" or C4/do3. If the A4/la3 is 440 Hz, key #60 should be 261.63 Hz, which we call the base frequency, following the practice in Csound..
See for example the top of settings of the piano scale in the tonality resource "-to.tryMPE":
For geeks:The Csound GEN51 line at the top is purely informative. It could be placed on top of Csound scores, but the Bol Processor uses note frequencies instead when unconventional positions are required — see Csound tuning in BP3.
Looking at the trace of the process when playing the "_scale(piano,0)" sequence yields the following:
The first thing we notice is that the frequency of C4 (key #60) is 261.630 Hz, the base frequency of the block key. One octave higher, the frequency of C5 is 525.260 Hz. This gives an octave ratio of 2.0034, which equates to a stretching of 3 cents, close to 4 cents due to the rounding.
When the frequencies are displayed using the just intonation scale, the octave ratio is exactly 2/1. Listen to the scale with decreasing velocities:
On the same scale, listen to a series of fifths C4/G4, D4/A4, E4/B4, F5/C5 showing that they are perfect except the wolf's fifth D4/A4 (see picture):
Due to rounding (3 cents instead of 4) in the piano scale, check that rounding errors do not accumulate over octaves. The following is also an exercise for those whose ear is trained in piano tuning. We'll play identical notes in two scales: the piano scale with its extended octave, then the standard equal temperament scale with an octave of 2/1:
The instruction "_scale(0,0)" sets the scale to the standard standard equal temperament scale. The layout of the notes in this polymetric structure is as follows:
There is a short delay (1/16 beat) on the notes of the second line to emphasise the beats, if there are any. You can hear beats in the first part, as scales are different, but perfect unison in the second part. This is how it sounds on a PianoTeq Stage physical modelling synthesiser:
This result should not be taken as a radical statement about how to tune a piano! Pianoteq synthesizers already reproduce the octave stretching that piano tuners tend to do to compensate for the inharmonicity of the strings. An additional octave stretching of four cents is therefore not worth mentioning.
The trace only shows notes whose frequencies have been corrected:
We note that 5 octaves gives a total stretch of 18 cents, or 3.6 cents per octave. The frequency ratio between C4 and C7, three octaves higher, is 2106.381/261.630 = 8.0509, whose cube root is 2.0042, again very close to the ratio of 2.0046 in the piano scale definition. Unsurprisingly, the C-sound score reveals exactly the same numbers.
Effect of the block key
Let us superimpose two phrases of the same notes in the same scale but without the same block key:
First, key #72 (C5) of scale #4 has 0 cents correction because the block key of this scale is C4 and it has no octave stretching. The same for key #69 (A4) of scale #3 whose block key is A4.
Pitch values can be deduced from the image of the just intonation scale., For instance, A4 (key #69) has 0 cent correction on the score because it is the block key. The corrected C4 frequency of this scale is 263.907 Hz (i.e. 15 cents above its base frequency 261.63 Hz) and the frequency ratio for A is 5/3, which yields 440.007 Hz as shown above.
Secondly, since notes C4 and C5 are superimposed with different cent corrections, i.e. different pitchbender settings, they must be sent on different MIDI channels: 2 and 3. This is the approach borrowed from MPE. Same for D4/D5, E4/E5, A4/A5. Note that each MIDI channel is reused as soon as it is free of notes.
For geeks: In this example, the notes G3 A3 B3 played at the beginning are not modified by a microtonal scale. They are therefore played on the standard equal tempered scale of the MIDI device. As a result, they appear on the Csound score in octave point pitch-class format:
Let us use meantone_try and meantone_try2 scale to play the same phrase. We call these scales "exotic" because the names of their notes are not in the English, Italian/Spanish/French, or Indian standard. Here we use the key numbers of the MIDI output device.
The only difference is the key numbers. In meantone_try2, the base key is #64 instead of #60.
The frequency of key#69 is 440 Hz since it is the block key. The actual sequence heard on the MIDI output device is C4 D4 F4 A4 C5. Note that the octave ratio C5/C4 is 527.204/260.875 which is greater than 2 because this scale has an octave stretched by 19 cents.
Note again that the frequency of the base key #73 is 440 Hz. The frequencies are identical, the only change is the key numbers associated with the notes. The actual sequence played on the MIDI output device should again be C4 D4 F4 A4 C5, assuming that key #64 is the middle key of its keyboard.
A very exotic scale
The scale called zest24-supergoya17plus3_Db is more "exotic" than the previous one because it has 20 grades and 12 notes. The original scale downloaded from an archive did not have note names, so we decided to label twelve positions with the key numbers #60 to #71. As you can see in the picture, the intervals are very irregular. The choice of 12 tones is motivated by the desire to be able to map them onto the 12 keys of a standard piano keyboard. We'll see a different case later.
Key #60 is the base key and its frequency is 261.630 Hz as declared in the tonality resource. Note that the key #72, an octave higher, also has "key#60" as its note name. Its frequency of 523.260 Hz is twice 261.630 since octaves are not stretched.
Looking at the picture, we can calculate the frequency of key#65 which has a frequency ratio of 1.478. This gives 1.478 x 261.63 = 386.69 Hz, which is very close to that in the score. Minor errors are due to the rounding of cents to whole numbers.
If you play this score on a conventional MIDI device, you won't hear the correct frequencies unless the device is tuned to a 20-grade equal temperament scale. Conversely, the rendering in C-Sound is accurate.
When a scale has more than 12 grades, the reference tempered scale must have the same number of grades, regardless of the number of notes (which is indeed smaller). Apart from the musical aspect — which we won't discuss here — this has a technical advantage: the cent corrections, which are deviations from the equal temperament scale, will always be less than 100 cents. This is important because the sensitivity of pitchbenders is set to ± 200 cents.
The Bohlen-Pierce scale
The Bohlen-Pierce scale has a "tritave" interval of ratio 3/1 instead of 2/1 in the octave. The tritave is divided into 13 grades and 13 notes (see Wikipedia).
The "just-intonation" version has been implemented in the tonal resource -to.tryMPE — see picture.
The frequency ratio C5 / C4 is, as expected, 784.457 / 261.630 = 3.
The Bohlen-Pierce scale played on Pianoteq
Since the scale covers a tritave that would extend from A4 (key #60) to G5 (key #79) on a conventional 12-note MIDI device, each note is mapped to the key that requires the least amount of pitchbend. As a result, pitchbend corrections are never greater than ± 100 cents.
To convert to Bohlen-Pierce notes played on an external MIDI device, connect it to the input of BP3, then run the following "tuning daemon" (see below):
In the following example, two phrases are played on top of each other, using different microtonal scales.
On the pianoroll (see picture), key#60 is shown as C4. The note key#62, shown as D4, seems to be unique, although two key#62 notes are superimposed with slightly different cent corrections. The same is true with key#72 shown as C5.
The second (key 62) and last (key 72) notes are identical, but because they belong to different scales, their frequencies are not identical. For this purpose, they are played on different MIDI channels. The superimposition creates (nasty) mismatches that reflect the differences in tuning:
Use of _scale(0,0)
So far we have used "_scale(0,0)" to specify the return to a 12-grade equal tempered scale after using a microtonal scale. It can also be used to force microtonal mode in a musical item that does not require specific microtonal scales.
Pitchbend adjustments are not shown on this graph
This is a (rather silly) way of creating a sequence of notes using the same note with pitchbend corrections. In fact, we are looking forward to hearing:
C4 C#4 {B3, D4} C#4 C4
The first solution does not work because the chord {B3, D4} consists of two of the same note A4 with different pitchbend values. It works in Csound, but in MIDI we hear:
An incorrect rendering of C4 C#4 {B3, D4} C#4 C4
Proper notation, without the aid of microtonality, would be, for example:
So we have to send the two C4s of the polymetric expression on separate MIDI channels. But the microtonal calculation does this automatically. So, putting "_scale(0,0)" at the beginning won't change the tuning but it will force the microtonal mode:
For geeks:It wouldn't be a good idea to set microtonality mode by default for all musical works, because (1) channel assignment takes up processing time, and (2) this would render all "_chan()" commands ineffective. In some MIDI environments, MIDI channels are used to send messages to different instruments.
Combination with pitchbend commands
The following is an example of combining a microtonal phrase with a global pitchbend command of + 100 cents:
The "_chan(4)" command is used here to prove that it is ignored in microtonality mode. The MIDI trace shows that an additional correction has been applied. Therefore, the frequency values are not those played on the output MIDI device. However, the Csound score is explicit:
The numbers 99.988 and 99.988 are the pitchbend corrections (in cents) at the beginning and end of the note declared on each line.
The "grama" Indian scale
The grama scale
We have already discussed the ancient Indian tonal system which divides the octave into "twenty-two shrutis", see The two-vina experiment for details. We'll try this grama scale by setting the pramāņa ṣruti to 21 cents.
In short, this tuning scheme is a twelve degree chromatic scale: Sa, Re komal, Re, Ga komal, Ga, Ma, Ma tivra, Pa, Dha komal, Dha, Ni komal, Ni. These names stand for C, Db, D, Eb, E, F, F#, G, Ab, A, Bb, B in English notation.
Each note of the Indian scale, except Sa (C) and Ma tivra (F#), can occupy two enharmonic positions. This explains why the grama tuning scheme has 23 positions and 22 notes.
In accordance with the syntax of the Bol processor, notes are referred to as sound objects in lower case. For example, the two enharmonic positions of Re komal are called r1_ and r2_, and the two positions of Re are called r3_ and r4_. A trailing '_' is necessary to indicate octave numbers unambiguously: the note d3_4 is the low position of Dha in the 4th octave, which is admittedly close to A4 in the Western scale.
The pramāņa ṣruti is the tonal distance between all pairs of enharmonic positions, for instance between r1_ and r2_. For the sake of simplicity, we've set it to 21 cents (a syntonic comma), which is a common mistake made by Western and Indian musicologists. In reality it is a variable value — see Raga intonation.
Listen to the same scale played against a drone (read the Microtonality page):
The Csound rendering of the grama scale (23 grades) played against a drone. This version has an additional note m4_ that does not belong to the preceding scale.
We said earlier that, in the grama tuning scheme, d3_4 occupies the position of A4 in the Western scale. Since the block key is #76 (d3_4), the frequency of d3_4 is close to 440 Hz. Consequently, the position of sa_4 (263.907 Hz) is 15 cents higher than the base frequency (261.63 Hz).
This scale can be played on any MIDI device that accepts pitchbend commands. The 22 notes of the scale, covering an octave, are mapped to the 12 keys of a MIDI keyboard. Each note is mapped to the key that requires the least amount of pitchbend. As a result, pitchbend corrections are never greater than ± 100 cents. For example, d3_4 is mapped to key #69, which happens to be that of A4 on a conventional keyboard.
Read the Raga Intonation page to see how this theoretical framework can be adapted for modelling real music.
Microtonality in sound-objects
A sound-object is a sequence of MIDI events and/or Csound score lines — read Sound-object prototypes for details. Therefore the pitches of notes it contains can be modified by microtonal scales. In the "-da.tryMPE" project, try for instance:
_scale(just intonation,0) a f b b
and check frequency corrections in the trace (both MIDI and Csound):
The position of A on the just intonation scale (see picture) is 884 cents above C, which is 15 cents below its position on the equal temperament scale (900 cents). The same goes for B which is 1088 cents above C, and thus 11 cents below its position on the equal temperament scale (1100 cents).
Applying microtonal corrections to MIDI input notes
This demonstrates the BP3's ability to act as an interface between MIDI devices, retuning the input in real time to a microtonal scale.
The filter of the input MIDI device should be set to "treat & pass" for all categories of events that will be transmitted (see picture).
We show a temporary solution that works very well, but will be simplified in the future.
If, for example, you want to retune the input to the just intonation scale, run the following "tuning daemon":
_script(wait for C0 channel 16) _scale(just intonation,A4) _vel(0) C0
The "wait for C0 channel 16" command that causes the machine to hang up while it listens for some kind of input. In fact, the note "C0 channel 16" should not be part of the stream of notes you need to retune, otherwise it will stop the process!
The note C0 with velocity 0 is inaudible and will not be played unless the note "C0 channel 16" releases the waiting state. This note is needed for attaching the script instruction.
The "wait forever" command causes the machine to hang until the STOP or PANIC button is pressed. Again, we need a dummy (inaudible) note C0, at the end of which the script instruction is appended.
Because multiple instances of BP3 can be run simultaneously (read Real-time MIDI), you can set up a bank of "tuning daemons" that interact with people and MIDI devices to create interesting variations of tonal structures.
This installation is checked with Ubuntu +Linux Lite 7.0 running on an HP Intel Core i5-6200U (64-bit, 8 Gb RAM).
Install XAMPP
The installation of BP3 should take place after the installation of the local Apache server XAMPP. Follow instructions here: https://www.apachefriends.org/
XAMPP creates a /opt/lampp/htdocs/ directory that will contain "bolprocessor". The "bolprocessor" folder will contain (language C) source files for the "bp3" console, the "MakeFile" to compile them, and all the data files. It will also contain a "php" folder filled with PHP pages and some related files for running the interface.
If you wish to open XAMPP automatically at startup, read this page. (This can be done later.)
These zip files are updated regularly. Major updates are announced on the BP developers list and uploaded to their GIT repositories. Make sure that they can be found in your Downloads folder: /home/linuxlite/Downloads
Install the Bol Processor
Safely do the installation using the shell scripts "linux-scripts" downloaded here. Current version: 4 February 2025, size 14124 bytes. Unpack and copy these scripts to the /home folder:
cd /home/linuxlite/Downloads/ unzip linux-scripts.zip -x "__MACOSX/*" sudo chmod -R 775 linux-scripts cd linux-scripts sudo cp -a . /home/ cd /home/ sudo chmod +x *.sh
Scripts "modify_xampp.sh", "prepare.sh", "unpack_bp3.sh", "install_bp3.sh" and "get_ready_bp3.sh" have been copied to the /home folder.
Four more scripts: "update_console.sh", "update_interface.sh", "update_data.sh" and "restart_xampp.sh", have been copied to the /home folder. They will be used later.
The installation procedure is similar to that for MacOS and Windows, but includes a few actions specific to Linux.
Run the scripts in the following order. 👉 You will be asked for your password the first time, as they need to be run in "admin" mode (the "sudo" command).
sudo /home/modify_xampp.sh will adjust XAMPP settings.
sudo /home/prepare.sh will install required resources on your machine, and create two virtual MIDI ports if they are not yet existing.
sudo /home/unpack_bp3.sh will unpack the zip files.
sudo /home/install_bp3.sh will create the /opt/lampp/htdocs/bolprocessor/ directory and fill it with the contents of BP3 packages. Files/folders already existing will simply be updated.
sudo /home/get_ready_bp3.sh will configure the virtual MIDI ports and update the sudoers entry.
In the "bolprocessor" folder, the owner is "daemon" (the same one used by XAMPP), which is assigned to the groups "audio" and "linuxlite", and the permissions are set to "775". 👉 The content of "bolprocessor" is strictly private. No risk setting up permissions!
Avoid running the same script more than once, although this should not create duplicates or unwanted effects.
Once the Bol Processor BP3 is installed and running, you should delete the "zip" files in the Downloads folder. This will allow downloading new versions.
Compile the 'bp3' console
Start the XAMPPApache server. You can send the terminal command:
sudo /home/restart_xampp.sh
Point your browser at localhost/bolprocessor/php/. This will display the home page of the Bol Processor.
If you see this frame in the image at the top right of the page, your life will be easy! All you have to do is click on the link to compile the console, which will take less than a minute.
f you don't see the link to compile, and instead a mention that 'gcc' is not responsive, you are in great trouble! This suggests a bug in the interface (contact us) or in your installation.
Install Csound
Csound is not required to run the Bol Processor, as you can work with MIDI files and real-time MIDI. However, it will give you access to a different approach to sound synthesis, and it will handle microtonality in its own way.
If you wish to install Csound, simply type the following commands:
sudo apt update sudo apt install csound
Then verify the installation and check the path to the console:
csound --version which csound
By default, the Bol Processor sets the path to "usr/bin", which seems to be standard on Linux. It is given by the "which csound" command.
A frame asking for a correction of the path to Csound. The path "/usr/local/bin" is incorrect in Linux.
The BP3 interface will be able to figure out the location of "csound" and fix its path accordingly. If it does not respond, you will be asked to change the path and perhaps the name of the Csound console (see image).
👉 Currently, the Csound orchestra file "0-default.orc" does not work on Linux. We're trying to fix this… In the settings of your projects, enter "BP2test.orc" as replacement, or select other files such as "new-vina.orc".
😀 Enjoy Bol Processor BP3 on Linux!
Restarting XAMPP after a crash
If you blow up the memory, for example with a quantization that is too low for the size of a piece played in realtime MIDI, the XAMPP server may freeze: the browser will refuse to display pages.
To restart XAMPP, go to the terminal and run the following script:
sudo /home/restart_xampp.sh
Updating to new versions
👉 If you update the "bp3" console, you should also update the PHP interface, as the two are linked.
(1) Update the "bp3" console: Delete the graphics-for-BP3.zip file if it exists in your Downloads folder. Download https://github.com/bolprocessor/bolprocessor/archive/graphics-for-BP3.zip Run the (superfast!) script: sudo /home/update_console.sh This script deletes the 'bp3' console to force a compilation of the new version.
(2) Update the PHP interface: Delete the php-frontend-master.zip file if it exists in your Downloads folder. Download https://github.com/bolprocessor/php-frontend/archive/master.zip Run the (superfast!) script: sudo /home/update_interface.sh Note that this script will preserve the "_settings.php" file (if it exists), which contains your project settings.
(3) Update the set of examples: this will only update the contents of the "ctests" folder. If you have created folders and files for your personal data, these will not be affected. However, if you have modified a sample file without changing its name, it will be reverted to its distribution version. Delete the bp3-ctests-main.zip file if it exists in your Downloads folder. Download https://github.com/bolprocessor/bp3-ctests/archive/main.zip Run the (superfast!) script: sudo /home/update_data.sh
👉 Please send your suggestions or modified files to our contact.
Relocating "bolprocessor"
The Bol Processor can be installed outside the "htdocs" folder created by XAMPP (on your boot drive). You might want it near related projects, or use extra space from an external hard drive. There may also be situations where creating files on the boot drive is restricted.
Fortunately, the process of relocating is very straightforward. Not all cases have been tested, but installation and update scripts are designed to handle redirections.
You should have already created a "bolprocessor" folder by running the installer. Now, drag it to the desired location and delete it from the "htdocs" folder.
Then, open a terminal and point it to the "htdocs" directory. You can type the instruction "ls -al" to see the contents of "htdocs", which is normally empty.
Let's say you've created an empty folder "bolprocessor" inside a folder called "MUSIC" on an external drive called "EXT". You first need to find the path to the external drive. Plug in the drive, then type "lsblk". Look for the device name (e.g., "/dev/sdb1") and its mount point, e.g. "/media/username/EXT", where "username" is your own user name.
The command to create the symbolic link would then be:
Make sure that the symbolic link you created points to the correct location: you will now see a "bolprocessor" icon in the "htdocs" folder. Double-click it, it should open the destination folder.
You can now safely run the update scripts and proceed to compile the 'bp' console. Don't try to run the installation scripts!
👉 Never change the names of the "bolprocessor" folder and symbolic link, otherwise the installation will fail.
The first time you run the Bol Processor, XAMPP may ask your permission to display files outside its "htdocs" folder. Please contact us if you're experiencing issues with this relocation!
You can also use symbolic links to relocate folders outside the "bolprocessor" folder, as explained here.
Uninstall the Bol Processor
Uninstalling the Bol Processor and all the data downloaded or created for its use, is very simple: delete the "htdocs/bolprocessor" folder, or the relocated "bolprocessor" folder and the symbolic link pointing to it.
A one-click notarized installer of Bol Processor BP3 is available. It is called "BolProcessorInstaller.pkg" and it can be downloaded from here (unique location).
Geeks may prefer an equivalent method using a script included in this package, see below.
This installer (or the script) is used for both initial installation and updates. Each time you run it, it will download the latest versions of the BP3 console source files, the interface PHP files and the sample set contained in the 'ctests' folder. Data, grammars and scripts that you've created will not be deleted. However, if you have modified files in the 'ctests' folder, they will be reverted to the current distribution version.
Install MAMP or XAMPP
If you try to run the installer of Bol Processor, it will first check that a local Apache server (either MAMP or XAMPP) has been installed. Both are suitable since the Bol Processor interface contains exclusively HTML, PHP and JavaScript code. No database is required.
As of January 2025, it appears that the free version of MAMP has a script execution time of 30 seconds that cannot be overridden by the PHP scripts. If this limitation is confirmed, we will recommend the use of XAMPP (free) or MAMP PRO (for a charge).
Your Mac may refuse to run the XAMPP installer because it is from an "unknown developer". You can override this by allowing the application in the Privacy & Security section of the Mac's System Settings. Unpacking the files takes several minutes, so be patient and wait for it to finish!
👉Don't try the virtual machine version of XAMPP! It won't work on Macs with M1 chips (and above). Use the native installer.
Free MAMP on MacOS. Note that the top right icon indicates that the Apache server is running.
if you choose the (free) MAMP version, both MAMP and (commercial) MAMP PRO will be installed. The interface will occasionally prompt you to "upgrade" to MAMP PRO (see picture), although you don't need it for the Bol Processor!
Note that after downloading MAMP, you will find MAMP PRO in the Applications folder, whereas MAMP (free) is located in Applications/MAMP. Also note that this version of MAMP runs on port "8888" by default, as we will see below.
For MAMP, the "htdocs" folder is in Applications/MAMP. For XAMPP, it is in Applications/XAMPP/xamppfiles. The installer will find it in both cases.
👉You will not be able to run both MAMP/MAMP PRO and XAMPP Apache servers at the same time if they use the same ports. This wouldn't be a good idea anyway…
Start Apache at boot time
If you want Apache to start automatically when you start your computer, this process is easy with MAMP: check Login items in the system settings.
For XAMPP, things are a bit more complicated.
For geeks:You have the offer to create a startup script but is not entirely satisfactory with the current version (8.2.4). It allows XAMPP to restart Apache at boot time and PHP pages are displayed correctly. However, when real-time MIDI is used, MIDIClientCreate() returns an error.
Until this problem is fixed, the easiest way is to find the Application Manager manager-osx.app (in XAMPP/xamppfiles) and add it to the Login Items of the General settings of your MacOS system:
You can also place an alias of "manager-osx.app" on the desktop and click on it at startup if you intend to run the Bol Processor.
MAMP PRO
Below are instructions for (rich) people running MAMP PRO.
The MAMP PRO main page on MacOS (version 5.7)
Launch MAMP PRO from the Applications folder.
In the MAMP main window, click the Apache Enable button (see image). No need for MySQL.
The image shows the default settings for PHP, which is started with Apache.
In case of trouble, check the settings for ports (see image) and of hosts (general and Apache).
XAMPP
Open the XAMPP folder in the Applications folder and launch manager-osx.app as shown below.
The XAMPP main page will appear. If you click on the Manage Servers tab and select Apache Web Server, then Configure, you can make sure that the server is running on port "80". This can be changed (e.g. to "81") if it creates a conflict.
Then click the Start button. If there is no conflict with the ports, Apache will show up as "running":
The XAMPP folder (in the Applications folder on a Mac) and the XAMPP main page
Once Apache is running, you can click on the Welcome tag and the Go to Application button. This should display a (local) page about XAMPP in the path http://localhost/dashboard. Both the dashboard and (later) bolprocessor folders will be located in the Applications/XAMPP/xamppfiles/htdocs folder.
Install the Bol Processor
After installing XAMPP or MAMP, you can run the installer "BolProcessorInstaller.pkg" or the "install_bolprocessor.sh" script. Both are equivalent.
By default, all Bol Processor program, documentation and data files will be created in a folder called "bolprocessor" and will be contained in the "htdocs" folder created by XAMPP or MAMP — in other words, on your startup disk. This is not a problem as the whole set does not take up much space, typically less than 60 Mb when installed, and the Bol Processor data is basically pure text.
However, you may wish to install the "bolprocessor" folder to a different location, including an external device. In this case, follow the instructions for Relocating "bolprocessor" before running the installer or the script.
Using the installer
Download "BolProcessorInstaller.pkg" from here and double-click it.
👉 If you have previously downloaded an older version of the installer, your browser may be delivering the old version instead of the latest. The safest thing to do is to check the size of "BolProcessorInstaller.pkg" (reed below the Security section). If necessary, use a different browser for the download.
This installer has been notarized, which means it contains information that allows Apple to certify its validity. The only changes you will have to confirm are usual software installation procedures on your Mac.
For geeks:The installer sets up user/group parameters in the "bolprocessor" folder: "daemon:admin" if XAMPP is the Apache server. If MAMP is used, the "<user_id>:admin" setting is retained.
An equivalent method is to run the "install_bolprocessor.sh" script found in the "macos-scripts" folder downloaded here. This makes it possible to understand each step of the installation and possibly suggest improvements.
After downloading "macos-scripts.zip", open the Terminal and type:
cd Downloads unzip -qo macos-scripts.zip cd macos-scripts sudo ./install_bolprocessor.sh
Installation issues
If the installer (or the script) does not find a "htdocs" folder created by XAMPP or MAMP, it will stop the installation, warning you that one of them should be installed.
👉 The installer will create or feed a "bolprocessor" folder in the "htdocs" folder used by XAMPP (first choice) or MAMP (second choice). If you have used XAMPP in the past and want to switch to MAMP, you will need to rename the "XAMPP" or "xamppfiles" folder before running the installer.
There is a Go to Application button on XAMPP manager and a WebStart button on MAMP (free) which will display a page confirming that the Apache server is running.
MAMP setting of the port
Now, assuming that the installation was successful, and the Apache server is running, start XAMPP or MAMP and point your browser to localhost/bolprocessor/php/ or (if it doesn't work) to localhost:8888/bolprocessor/php/.
One of these will display the home page of the Bol Processor. The default port used by the free MAMP is "8888", but you can change it to "80" in MAMP settings (see picture), so that the ":8888" option is no longer required.
Compile the 'bp' console
👉 From 23 February 2025, the compiled 'bp' console will be installed (or updated) by the install script. So normally this step is no longer needed, except for geeks who wish to modify the source files in the "bolprocessor/source/BP3" folder.
If you see this frame in the image at the top right of the page, your life will be easy! All you have to do is click on the link to compile the console, which will take a minute or two.
👉 It is very unlikely that the compilation will fail. If it ever happens, please contact us!
Installing Xcode via the Mac App store. No charge!
If you don't see the link to compile, and instead a mention that 'gcc' is not responding, you may need to install the Xcode toolkit on your machine (link to App Store).
Install and launch Xcode (free) to enable the compilation. Click "Cancel" when Xcode asks you to "create a project", go back to the Bol Processor page and reload it.
Now, you should see the compilation link.
👉 There are other methods of installing 'gcc'. Fans of Terminal commands can simply try the command:
brew install gcc
Install Csound
Csound is not required to run the Bol Processor, as you can work with MIDI files and real-time MIDI. However, it will give you access to a different approach to sound synthesis.
A frame asking for a correction of the path to Csound
The BP3 interface should be able to figure out the location of "csound" and fix its path accordingly. If it does not respond, you will be asked to change the path and perhaps the name of the Csound console (see image).
😀 Now, the Bol Processor is fully operational! You can try examples contained in the 'ctests' folder, or follow the guided tour on page Bol Processor ‘BP3’ and its PHP interface.
Updating to new versions
To update the Bol Processor console, its PHP interface and examples (the contents of the "ctests" folder), simplyrerun "BolProcessorInstaller.pkg". Using the latest version is safe!
The installer will download and install current versions of the software and data.
Updating will not modify or delete any data you have created in the "ctests" folder or outside it. However, if you have modified a sample file without changing its name, it will be reverted to its distribution version.
The installer will also preserve the "_settings.php" file (if it exists), which contains your project settings.
Security
You are right to be concerned about security. Can you be sure that you have downloaded the correct (and latest) version of "BolProcessorInstaller.pkg"? Normally yes, this installer is safe because it has been notarized.
The size of the "BolProcessorInstaller.pkg" file is exactly 21075 bytes and its MD5 is df773f259b2f59ba0636446f1559d3e6. You can calculate the MD5 checksum on this page. These numbers will indeed be subject to change with the release of new versions of the installer. Current version: 23 February 2025.
Geeks may want to customise it for their own use. Just download this folder which contains the script files (install_bolprocessor.sh and postinstall) along with instructions on how the installer has been built.
For readers not conversant with Unix shell scripts, the following is a description of the process in human language:
Check that an Apache server MAMP or XAMPP is installed by finding either MAMP/htdocs or xampp/htdocs on the computer (not case-sensitive). If it is not found, exit with the warning that either MAMP or XAMPP should be installed.
Download the latest distribution files from GitHub: https://github.com/bolprocessor/bolprocessor/archive/graphics-for-BP3.zip https://github.com/bolprocessor/php-frontend/archive/master.zip https://github.com/bolprocessor/bp3-ctests/archive/main.zip
Unzip these three files. They create folders with names: bolprocessor-graphics-for-BP3 php-frontend-master bp3-ctests-main
Create a folder named "bolprocessor" (if it does not yet exist) inside the "htdocs" folder of the Apache server
Copy bolprocessor-graphics-for-BP3/source to bolprocessor/ If there is already a "source" folder, delete it
Copy bolprocessor-graphics-for-BP3/Makefile to bolprocessor/ Copy bolprocessor-graphics-for-BP3/BP3_help.txt to bolprocessor/ Copy bolprocessor-graphics-for-BP3/Credits.txt to bolprocessor/ Copy bolprocessor-graphics-for-BP3/BP3-To-Do.txt to bolprocessor/ Copy bolprocessor-graphics-for-BP3/License.txt to bolprocessor/ Copy bolprocessor-graphics-for-BP3/ReadMe.txt to bolprocessor/
Copy bolprocessor/php/_settings.php to bolprocessor/ (if it exists)
Copy php-frontend-master/php to bolprocessor/ If there is already a "php" folder, delete it
Copy bolprocessor/_settings.php to bolprocessor/php/ (if it exists)
Create a folder bolprocessor/csound_resources if it does not yet exist
Copy the content of php-frontend-master/csound_resources to bolprocessor/csound_resources Files that already exist should be replaced with their updated versions
Create a folder htdocs/bolprocessor/ctests if it does not yet exist
Copy the content of bp3-ctests-main to bolprocessor/ctests Files that already exist should be replaced with their updated versions
Delete the temporary download directory
Set permissions of the bolprocessor folder recursively to "775", and owner/group to <your_id>:admin if MAMP is used, or daemon:admin if XAMPP is used.
➡ There is no security risk in setting "775" permissions, as the MAMP or XAMPP Apache server will be running on your private computer. The Bol Processor never creates/modifies files outside of its "bolprocessor" folder.
Delete bolprocessor/bp if it exists and replace it with the current 'bp' console.
Relocating "bolprocessor"
👉 Apparently, relocated installations do not work with XAMPP after a reboot, unless the "BolProcessorInstaller.pkg" installer is run again. We're trying to fix this problem. In the meantime, you can at least relocate your data using symbolic links.
The Bol Processor can be installed outside the "htdocs" folder created by MAMP or XAMPP (on your boot drive). You might want it near related projects, or use extra space from an external hard drive. There may also be situations where creating files on the boot drive is restricted to the super admin.
Fortunately, the process of relocating is very simple.
If you have already created a "bolprocessor" folder by running the installer, drag it to the desired location and delete it from the "htdocs" folder. If not, create an empty "bolprocessor" folder in the desired location.
Then, open the Terminal (in the Applications folder) and point it to the "htdocs" directory. For those unfamiliar with Unix commands, you will need to type "cd " (followed by a space) and drag "htdocs" to the end of this command, then press "return". You can type the instruction "ls -al" to see the contents of "htdocs", which is normally empty.
Let's say you've created an empty folder "bolprocessor" inside a folder called "MUSIC" on an external drive called "EXT". The instruction creating the symbolic link is:
Make sure that the symbolic link you created points to the correct location: you will now see a "bolprocessor" icon with a small arrow in the bottom left corner. Double-click it, it should open the destination folder.
👉 You may wonder why symbolic links are used instead of MacOS aliases, which do not require the use of the Terminal. The reason is that the Apache servers don't accept alias redirections.
👉 Never change the names of the "bolprocessor" folder and symbolic link, otherwise the installation will fail.
The first time you run the Bol Processor, MAMP or XAMPP may ask your permission to display files outside its "htdocs" folder. Please contact us if you're experiencing issues with this relocation!
If you're not afraid of symbolic links, you can use the same technique to relocate some data files outside the "bolprocessor" folder, for example to a location in your Dropbox (including shared folders), as explained here.
Uninstall the Bol Processor
Uninstalling the Bol Processor, and all the data downloaded or created for its use, is very simple: delete the "bolprocessor" folder, and the "bolprocessor" symbolic link if you have created it.
A one-click installer of Bol Processor BP3 is available. It is called "BolProcessorInstaller.exe" and it can be downloaded here (unique location).
This installer is used for both initial installation and updates. Each time you run it, it will download the latest versions of the BP3 console, including its source files, the interface PHP files, and the sample set contained in the 'ctests' folder. Data, grammars and scripts that you've created will not be deleted. However, if you have modified files in the 'ctests' folder, they will be reverted to the distribution version.
This installation is checked with Windows 10 running on an HP Intel Core i5-6200U (64-bit, 8 Gb RAM) and MAMP (free) running PHP 8.3.1. It should work fine with Windows 11, please check it and report!
👉 26 January 2025: The installer "BolProcessorInstaller.exe" is now certified. It should not display a "malicious software" warning. Once opened, before starting the installation, it should mention the name of its creator: "Bernard Bel". Contact us if it doesn't work on your computer!
First install MAMP or XAMPP
The (free) MAMP device running on Windows 10 (July 2024). Note that Apache Server is active. You can click "Open WebStart Page" to check that it is effective.
If you try to run the installer (see below), it will first check that a local Apache server (MAMP or XAMPP) has been installed. Both are suitable since the Bol Processor interface contains exclusively HTML, PHP and JavaScript code. No database is required.
if you choose the (free) MAMP version, both MAMP and MAMP PRO will be installed, and the interface will occasionally invite you to "upgrade" to MAMP PRO. But you don't need it for the Bol Processor!
For MAMP on Windows, the "htdocs" folder is in "C:\MAMP". For XAMPP on Windows, the "htdocs" folder is in "C:\xampp". (To be verified)
If you want Apache to start automatically when you start your computer, this process is easy with MAMP, but a bit more complex with XAMPP: try this method.
Create the 'bp.exe' console
After installing MAMP or XAMPP, run the installer "BolProcessorInstaller.exe" downloaded here.
👉 The installer creates a "bolprocessor" folder in the "htdocs" folder used by MAMP or XAMPP. Make sure that there is only one such folder on your machine, notably if you tried both MAMP and XAMPP in the past. It is safe to rename any unused "htdocs" folder before running the installer.
If you plan to install the "bolprocessor" folder outside the "htdocs" folder, follow the instructions in Relocating "bolprocessor"before running the installer.
As "BolProcessorInstaller.exe" is not yet certified, you may receive a warning that it is from an "unknown source". Click on the option to ignore the warning. If you don't feel confident about doing this, please read the section on Security below.
All steps of the installation are displayed to ensure that they are successful. At the end you'll be asked to press a key.
Now start MAMP or XAMPP. There is an Open WebStart Page button on MAMP (free) which will display a page confirming that the Apache server is running. Probably you will find a Go to Application button on XAMPP manager.
Point your browser at localhost/bolprocessor/php/. This will display the home page of Bol Processor BP3. Otherwise, check that MAMP or XAMPP is set to use port #80.
If you see this image at the top right of the page, the console is ready. Click on the lamp if you prefer to use the light mode for the interface.
You can ignore the next section. 😀
Compile the 'bp.exe' console (if necessary)
The Windows installation of Bol Processor includes the pre-compiled console (named 'bp.exe' ). If, some some reason, the console is not responding, or if you modified its source code (in the source/BP3 directory), you may need to recompile it.
If you see this image at the top right of the page, your life will be easy!
All you have to do is click on the link to compile the console, which will take a minute or two.
If the frame says that 'gcc' is not responding (see picture) you need to install MinGW. This is the main drawback of Windows: its default installation does not handle 'gcc' (the standard C compiler). You need 'gcc' to compile the Bol Processor console, and perhaps other applications to come. So, install MinGW, carefully following instructions on this page. It is simple, but you shouldn't miss a step!
Once 'gcc' is responding, reload the Bol Processor home page and click on the link to compile the console.
Install Csound
Csound is not required to run the Bol Processor, as you can work with MIDI files and real-time MIDI. However, it will give you access to a different approach to sound synthesis.
A frame asking you to correct the path to Csound. This is the default path for Windows 10, by the way. We tricked the interface into saying it was wrong!
The BP3 interface will be able to figure out the location of "csound.exe" and fix its path accordingly. If it does not respond, you will be asked to change the path and perhaps the name of the Csound console (see image). Once it works after a modification, please contact us so that we can update the default paths and names of Csound in your installation of Windows.
To update the Bol Processor console, its PHP interface and examples (the contents of the "ctests" folder), simply rerun the installer. It will download and install the latest versions of the software and data. It will also delete and replace the precompiled "bp.exe" console.
The installer will not modify or delete any data you have created in the "ctests" folder or outside it. However, if you have modified a sample file without changing its name, it will be reverted to its distribution version.
The installer will also preserve the "_settings.php" file (if it exists), which contains your project settings.
Security
You are right to be concerned about security. Can you be sure that you have downloaded the correct version of "BolProcessorInstaller.exe"? As this executable is certified, there is no known risk of malicious modification.
The size of this file is exactly 1820992 bytes and its MD5 is 9524a9c20c3e300bab509238ad406db2. You can calculate the MD5 on this page. These numbers will indeed be subject to change with the release of new versions of the installer. The current version is dated 27 January 2025.
You may also want to know all the details of how it works. Geeks may want to customise it for their own use. Just download this folder which contains the source files (installer.ps1 and setup.iss) along with a summary of how to build the installer.
For readers not conversant with WindowsPowerShell, the following is a description of the process in human language:
Check that an Apache server MAMP or XAMPP is installed by finding either MAMP\htdocs or xampp\htdocs on the computer (not case-sensitive). If it is not found, exit with the warning that either MAMP or XAMPP should be installed.
Download the latest distribution files from GitHub: https://github.com/bolprocessor/bolprocessor/archive/graphics-for-BP3.zip https://github.com/bolprocessor/php-frontend/archive/master.zip https://github.com/bolprocessor/bp3-ctests/archive/main.zip
Unzip these three files. They create folders with names: bolprocessor-graphics-for-BP3 php-frontend-master bp3-ctests-main
Create a folder named "bolprocessor" (if it does not yet exist) inside the "htdocs" folder of the Apache server
Copy bolprocessor-graphics-for-BP3/source to htdocs/bolprocessor/ If there is already a "source" folder, delete it
Copy bolprocessor-graphics-for-BP3/Makefile to htdocs/bolprocessor/ Copy bolprocessor-graphics-for-BP3/BP2_help.txt to htdocs/bolprocessor/ Copy bolprocessor-graphics-for-BP3/Credits.txt to htdocs/bolprocessor/ Copy bolprocessor-graphics-for-BP3/BP3-To-Do.txt to htdocs/bolprocessor/ Copy bolprocessor-graphics-for-BP3/License.txt to htdocs/bolprocessor/ Copy bolprocessor-graphics-for-BP3/ReadMe.txt to htdocs/bolprocessor/
Copy bolprocessor/php/_settings.php to bolprocessor/ (if it exists)
Copy php-frontend-master/php to htdocs/bolprocessor/ If there is already a "php" folder, delete it
Copy bolprocessor/_settings.php to bolprocessor/php/ (if it exists)
Create a folder htdocs/bolprocessor/csound_resources if it does not yet exist
Copy the content of php-frontend-master/csound_resources to htdocs/bolprocessor/csound_resources Files that already exist should be replaced with their updated versions
Create a folder htdocs/bolprocessor/ctests if it does not yet exist
Copy the content of bp3-ctests-main to htdocs/bolprocessor/ctests Files that already exist should be replaced with their updated versions
Delete the temporary download directory
Replace htdocs/bolprocessor/bp.exe with the updated version.
Relocating "bolprocessor"
The Bol Processor can be installed outside the "htdocs" folder created by MAMP or XAMPP (on your boot drive). You might want it near related projects, or use extra space from an external hard drive. There may also be situations where creating files on the boot drive is restricted.
Fortunately, the process of relocating is very simple.
If you have already created a "bolprocessor" folder by running the installer, copy it to the desired location and delete it from the "htdocs" folder. If not, create an empty "bolprocessor" folder in the desired location.
Let's say you've created an empty folder called "bolprocessor" inside a folder called "MUSIC" on an external drive labelled "D", and MAMP is installed on drive "C". Right-click the start icon at the bottom left of the screen, and select Windows PowerShell (admin). Then type the following command to create a symbolic link — in fact a junction (/J instead of /D):
If you are using XAMPP, replace "\MAMP\" with "\xampp\".
Make sure that the symbolic link you created points to the correct location: you will now see a "bolprocessor" icon in the "htdocs" folder. Double-click it, it should open the destination folder.
You can now safely run the installer. Updates to new versions will be the same way.
👉 Never change the names of the "bolprocessor" folder and symbolic link, otherwise the installation will fail.
The first time you run the Bol Processor, MAMP or XAMPP may ask your permission to display files outside its "htdocs" folder. Please contact us if you're experiencing issues with this relocation!
You can use the same technique to relocate some data files outside the "bolprocessor" folder, for example to a location shared by Dropbox.
You can also use symbolic links to relocate folders outside the "bolprocessor" folder, as explained here.
Uninstall the Bol Processor
Uninstalling the Bol Processor and all the data downloaded or created for its use, is very simple: delete the "bolprocessor" folder and the "htdocs\bolprocessor" symbolic link, if you have created one.