bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] Running BP1 on (emulated) Apple II

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

Despite other urgent tasks I couldn't resist trying to run BP1 on a Mac. 
Yesterday we had already checked it on a virtual Apple II under Windows.

I installed the first emulator found by a search engine:
https://www.virtualii.com/

and paid the cheapest license (around 19 euros).

It took a while finding ROMs for intalling the Apple II's system. On the 
machine it was a piece of hardware.

Finally I dowloaded "apple2_roms.zip" from:
https://mirrors.apple2.org.za/ftp.apple.asimov.net/emulators/rom_images/

and dragged the Apple_iie ROM to the ROM folder of the application, then 
ran "create a new machine" to create an Apple IIe. I vaguely remember 
this is the minimum setup to display 80 columns.

Then I called "Insert a diskette image" telling it should go to drive 1 
and selected "BP-PRG.DSK". The program started. When it asked for a data 
disk, I selected again drive 1 and uploaded "BP-OCT88.DSK".

Probably it is necessary to click the "drive 1" image as shown on the 
enclosed picture to instruct the machine we still want to use it… Having 
2 drives doesn't really matter because BP1 had been designed for a 
single drive of the AppleIIc. The program is held in the upper RAM and 
the program disk can be replaced with a data disk.

Look at the attached picture proving I was able to load "Grammar Q.6.6 
version 36"!

Frankly I haven't been able to do much with it because I have forgotten 
most procedures. Still, I managed to edit the grammar and play with the 
editor which is pure 6502 code. I will work with Jim Kippen to set up a 
real demo of all features and document it on the website.

The fun with this emulator is that it runs at the exact speed on an 
Apple II and even produces the sounds of floppy disks spinning in 
drives!  It can also be set to run faster.

The illusion is complete because the temperature in the South of France 
is the same as in India 40 years ago. :-/

Bernard Bel

----------

Hello fans of the Apple 2!

With the help of Philippe M. in Marseille, all floppy disks of Bol 
Processor BP1 dating back to 1980 have been duplicated. These include 
the source code in 6502, the binary program running on Apple 2 (64K) and 
sets of data — Jim Kippen's work on tabla improvisation in North India.

Philippe also transfered 3 disks to "DSK" images which can be downloaded 
here:

https://bolprocessor.org/misc/BP1/

The source+program disk is named "BP-PRG.DSK".

We ran BP1 on an Apple II emulator. (Beware that the display is on 80 
columns…) It all works fine even though I am no longer familiar with the 
interface! It will require an hour of training, remembering and documenting… 


This material could be used in a memorial meeting, next year, for 
celebrating 40 years of development on Bol Processor. :-)

Bernard

Re: [bp-dev] New BP3 console snapshot

[Rainer S. <rs...@ba...>]

> On 18. Aug 2020, at 00:25, Anthony Kozar <mai...@an...> wrote:
> 
> Hello everyone,
> 
> I've uploaded a new snapshot of my development folder to my website.
> Just download and unzip the file "bpconsole-2020-08-17.zip" from
> 
> http://www.anthonykozar.net/files/BolProcessor/

Very cool! I’ve seen the `bp --version` output

Bol Processor console app
Version 2.999... (Aug 18 2020)

already both on Windows and Raspberry Pi (and Catalina, the make-build), builds are fine!
No time for trying out yet, I hope I’ll find a few hours during the week!

Best
.r.

[bp-dev] Real-time MIDI

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

There is another advantage in creating a "merry-go-round" MIDI event 
loop sending events at their proper time instead of streaming them in 
advance with time-stamps as we had done with OMS.

In this setup, events can be modified or deleted at any time before they 
are played. In a time-stamped stream you cannot modify events once they 
have been queued to the MIDI driver.

For instance, the user may program an incoming event (a MIDI NoteOn, a 
stroke on the keyboard) to stop playing immediately and delete all 
pending events, or keep them on a pause. This will evidently happen in 
real-time music production, and even more if several machines are 
interacting in a cooperative manner.

So, I suggest that we look for (or design) an algorithm able to schedule 
events in real time… Then PortMIDI would be a workable option!

Bernard Bel

--------------

I had a quick look at PortMIDI which is one of the suggested tracks to 
solve the problem of real-time MIDI output/input:

https://github.com/rakyll/portmidi

The input (listening to events) is probably easy to implement as 
previously done in the ListenMIDI() loop. But the ouput seems more 
problematic. Their example for playing a C major chord for 2 seconds is:

// note on events to play C major chord
out.WriteShort(0x90, 60, 100)
out.WriteShort(0x90, 64, 100)
out.WriteShort(0x90, 67, 100)

// notes will be sustained for 2 seconds
time.Sleep(2 * time.Second)

// note off events
out.WriteShort(0x80, 60, 100)
out.WriteShort(0x80, 64, 100)
out.WriteShort(0x80, 67, 100)

This means that it would take MIDI events without a time-stamp, and all 
scheduling would be managed by time.Sleep().

Even though time.Sleep() might accept very accurate time intervals, the 
cumulation of intervals over thousands of events is likely to generate 
imprecision.

In the current layout (as I remember it) we send time-stamped MIDI 
events containing "absolute" timings (from a unique "zero" point) which 
makes it possible to maintain time accuracy with 1 millisecond whatever 
the number of events.

Maybe this has already been discussed (and solved) by developers using 
PortMIDI…

Before OMS I was using a loop (written in assembly language) to schedule 
events accurately as it was not yet possible to time-stamp them. I am 
not sure I still have the code which anyway is totally obsolete since it 
was for MacOS 9. Nonetheless, creating that kind of loop would be a 
manner of using PortMIDI without resorting to time.Sleep().

I remember using the image of a merry-go-round to visualize this event 
loop; but this may not be of great help! ;-)

An important detail is that BP2 (in MacOS 9 + OMS) did send events in 
their chronological order even though time-stamping did not make it 
compulsory. This feature might turn out useful when implementing a new 
driver…

A practical way of approaching this might be to write a very simple C 
program whose sole work is to broadcast a couple of MIDI events, then 
listen to capture an incoming event.

Bernard Bel

Re: [bp-dev] Running BP1 on (emulated) Apple II

[Rainer S. <rs...@ba...>]

Fabulous!!! :D 

> On 18. Aug 2020, at 05:53, Bernard Bel <ber...@gm...> wrote:
> 
> Hello fans of the Apple 2!
> 
> With the help of Philippe M. in Marseille, all floppy disks of Bol Processor BP1 dating back to 1980 have been duplicated. These include the source code in 6502, the binary program running on Apple 2 (64K) and sets of data — Jim Kippen's work on tabla improvisation in North India.
> 
> Philippe also transfered 3 disks to "DSK" images which can be downloaded here:
> 
> https://bolprocessor.org/misc/BP1/
> 
> The source+program disk is named "BP-PRG.DSK".
> 
> We ran BP1 on an Apple II emulator. (Beware that the display is on 80 columns…) It all works fine even though I am no longer familiar with the interface! It will require an hour of training, remembering and documenting…
> 
> This material could be used in a memorial meeting, next year, for celebrating 40 years of development on Bol Processor. :-)
> 
> Bernard
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Real-time MIDI

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

I had a quick look at PortMIDI which is one of the suggested tracks to 
solve the problem of real-time MIDI output/input:

https://github.com/rakyll/portmidi

The input (listening to events) is probably easy to implement as 
previously done in the ListenMIDI() loop. But the ouput seems more 
problematic. Their example for playing a C major chord for 2 seconds is:

// note on events to play C major chord
out.WriteShort(0x90, 60, 100)
out.WriteShort(0x90, 64, 100)
out.WriteShort(0x90, 67, 100)

// notes will be sustained for 2 seconds
time.Sleep(2 * time.Second)

// note off events
out.WriteShort(0x80, 60, 100)
out.WriteShort(0x80, 64, 100)
out.WriteShort(0x80, 67, 100)

This means that it would take MIDI events without a time-stamp, and all 
scheduling would be managed by time.Sleep().

Even though time.Sleep() might accept very accurate time intervals, the 
cumulation of intervals over thousands of events is likely to generate 
imprecision.

In the current layout (as I remember it) we send time-stamped MIDI 
events containing "absolute" timings (from a unique "zero" point) which 
makes it possible to maintain time accuracy with 1 millisecond whatever 
the number of events.

Maybe this has already been discussed (and solved) by developers using 
PortMIDI…

Before OMS I was using a loop (written in assembly language) to schedule 
events accurately as it was not yet possible to time-stamp them. I am 
not sure I still have the code which anyway is totally obsolete since it 
was for MacOS 9. Nonetheless, creating that kind of loop would be a 
manner of using PortMIDI without resorting to time.Sleep().

I remember using the image of a merry-go-round to visualize this event 
loop; but this may not be of great help! ;-)

An important detail is that BP2 (in MacOS 9 + OMS) did send events in 
their chronological order even though time-stamping did not make it 
compulsory. This feature might turn out useful when implementing a new 
driver…

A practical way of approaching this might be to write a very simple C 
program whose sole work is to broadcast a couple of MIDI events, then 
listen to capture an incoming event.

Bernard Bel

Re: [bp-dev] New BP3 console snapshot

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

These are great news!

I feel impatient to set the PHP interface to using these new options. It 
may be difficult during the rest of this week as I am busy with a workshop…

Meanwhile, all examples of commands fit the model I had in mind for an 
interface.

And thanks for indications for updating the code! The to-do list will be 
very useful for coordinating our tasks.

Bernard Bel

Anthony Kozar wrote on 18/08/2020 00:25:
> Hello everyone,
>
> I've uploaded a new snapshot of my development folder to my website.
> Just download and unzip the file "bpconsole-2020-08-17.zip" from
>
> http://www.anthonykozar.net/files/BolProcessor/
>
> Inside the "bolprocessor" folder you will find (amongst other things):
>
> bp    64-bit console app built with the Makefile
> bp32    32-bit console app built with Xcode (has debug info)
> bp64    64-bit console app built with Xcode (has debug info)
>
> BP2-ANSI.xc82.xcodeproj    current Xcode project file
>
> ctests/      folder full of test files and output files from tests
>
> source/BP2/  the folder containing all of the source for this version
>
> I haven't tested building this version yet under Linux or Windows.  I
> expect it to build fine with the Makefile.  On any platform (including
> MacOS), just try the command "make" from the "bolprocessor" folder to 
> build.
>
> Changes in this version
> -----------------------
> • now able to load -se settings files!
> • command-line options interact with options in the settings file in
>   the following ways:
>     • The settings file will override any "default" settings of the
>       command-line program.
>     • If any of the score output or performance options are specified
>       (-D, -d, -o, --csoundout, --midiout, or --rtmidi), then all of
>       those options from the settings file are ignored.
>     • Other command-line options override the settings file and are
>       applied independently.
> • cleaned up the console output more by
>     • replacing many "high-ASCII" characters in message strings with
>       their closest ASCII equivalents
>     • outputting system-native newline characters instead of carriage
>       returns
> • MIDI file output now works via the --midiout option!
> • changed default MIDI file format to type 1
> • new option '--midiformat num' for specifying the Midi file format
> • type 2 MIDI files now combine the tempo/time sign./key sign. info
>   with the note events into the same track. This was changed because
>   the intention of type 2 files is that each track is a separate item,
>   piece, song, etc.  Type 1 files still write tempo & other meta data
>   to the first track and note/control events to the second track.
>
> Other than the change to type 2 MIDI files, I expect the output of 
> MIDI files in this version to match that in BP2.9.8 when the options 
> "Store all items to same file" and "Write item immediately" are 
> selected.  My initial tests have found identical binary output between 
> the 32-bit and 64-bit versions of BP3 console.
>
> Please report any bugs, especially in the MIDI file output!
>
>
> Example command lines
> --------------------
>
> Here are some examples to try from the "ctests" folder (you can use
> "bp32" or "bp" instead of "bp64"):
>
> ../bp64 --version
> ../bp64 --help
>
> ../bp64 produce -gr.NotReich
> ../bp64 produce -gr.NotReich -o NotReich.bpda
> ../bp64 produce -gr.NotReich -d --csoundout -
> ../bp64 produce -gr.NotReich -d --csoundout out.sco
> ../bp64 produce -gr.NotReich -d --midiout NotReich.mid
>
> ../bp64 templates -gr.checktemplates --traceout trace.txt
>
> # the next two commands will generate some compilation errors
> ../bp64 compile symbols.bpgr
> ../bp64 compile symbols.bpgr --traceout trace.txt
>
> # adding the alphabet file fixes them
> ../bp64 compile symbols.bpgr symbols.bpho --traceout trace.txt
> ../bp64 produce symbols.bpgr symbols.bpho
>
> # type this all on one line
> ../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout
> trace.txt --show-production
>
> # type this all on one line
> ../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout
> trace.txt --trace-production
>
> ../bp64 produce produce-all.bpgr
> ../bp64 produce-all produce-all.bpgr
> ../bp64 produce produce-all.bpgr -d --midiout out.mid
>
> # type each of these commands all on one line
> ../bp64 produce produce-all.bpgr -d --midiout out-type-0.mid --seed 0 
> --midiformat 0
> ../bp64 produce produce-all.bpgr -d --midiout out-type-1.mid --seed 0 
> --midiformat 1
> ../bp64 produce produce-all.bpgr -d --midiout out-type-2.mid --seed 0 
> --midiformat 2
>
> # this command will also generate some compilation errors
> ../bp64 compile -gr.Nadaka --traceout Nadaka-errors.txt
>
> # adding the --indian option fixes them
> ../bp64 compile --indian -gr.Nadaka
> ../bp64 produce --indian -gr.Nadaka
> ../bp64 produce --indian -gr.Nadaka -d --rtmidi
>
> # the --indian option is not needed if the correct -se file is used
> ../bp64 produce -gr.Nadaka -se.hamsad
> ../bp64 produce -gr.Nadaka -se.hamsad --midiout Nadaka.mid
>
>
> Updating to the latest code
> ---------------------------
>
> The "bolprocessor" folder contains a Git repository.  Before you can
> download changes from Sourceforge you will need to reconfigure the
> remote settings because they are set up to use my username.  You can do
> so with these commands:
>
>    git remote remove origin
>    git remote add -f origin git://git.code.sf.net/p/bolprocessor/git
>    git branch --set-upstream-to=origin/ANSI-branch ANSI-branch
>
> After that, you can update to the latest code on Sourceforge anytime
> with just the command
>
>    git pull
>
> If you have made changes to the source code, it is safer to do
>
>    git fetch
>
> and examine any non-local changes first!
>
> --------
>
> I hope that this snapshot works for all of you.  Inquire here on the
> developer list if you have problems.
>
> Anthony
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Running BP1 on (emulated) Apple II

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

Hello fans of the Apple 2!

With the help of Philippe M. in Marseille, all floppy disks of Bol 
Processor BP1 dating back to 1980 have been duplicated. These include 
the source code in 6502, the binary program running on Apple 2 (64K) and 
sets of data — Jim Kippen's work on tabla improvisation in North India.

Philippe also transfered 3 disks to "DSK" images which can be downloaded 
here:

https://bolprocessor.org/misc/BP1/

The source+program disk is named "BP-PRG.DSK".

We ran BP1 on an Apple II emulator. (Beware that the display is on 80 
columns…) It all works fine even though I am no longer familiar with the 
interface! It will require an hour of training, remembering and documenting…

This material could be used in a memorial meeting, next year, for 
celebrating 40 years of development on Bol Processor. :-)

Bernard

[bp-dev] New BP3 console snapshot

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

Hello everyone,

I've uploaded a new snapshot of my development folder to my website.
Just download and unzip the file "bpconsole-2020-08-17.zip" from

http://www.anthonykozar.net/files/BolProcessor/

Inside the "bolprocessor" folder you will find (amongst other things):

bp	64-bit console app built with the Makefile
bp32	32-bit console app built with Xcode (has debug info)
bp64	64-bit console app built with Xcode (has debug info)

BP2-ANSI.xc82.xcodeproj    current Xcode project file

ctests/      folder full of test files and output files from tests

source/BP2/  the folder containing all of the source for this version

I haven't tested building this version yet under Linux or Windows.  I
expect it to build fine with the Makefile.  On any platform (including
MacOS), just try the command "make" from the "bolprocessor" folder to build.

Changes in this version
-----------------------
• now able to load -se settings files!
• command-line options interact with options in the settings file in
   the following ways:
     • The settings file will override any "default" settings of the
       command-line program.
     • If any of the score output or performance options are specified
       (-D, -d, -o, --csoundout, --midiout, or --rtmidi), then all of
       those options from the settings file are ignored.
     • Other command-line options override the settings file and are
       applied independently.
• cleaned up the console output more by
     • replacing many "high-ASCII" characters in message strings with
       their closest ASCII equivalents
     • outputting system-native newline characters instead of carriage
       returns
• MIDI file output now works via the --midiout option!
• changed default MIDI file format to type 1
• new option '--midiformat num' for specifying the Midi file format
• type 2 MIDI files now combine the tempo/time sign./key sign. info
   with the note events into the same track. This was changed because
   the intention of type 2 files is that each track is a separate item,
   piece, song, etc.  Type 1 files still write tempo & other meta data
   to the first track and note/control events to the second track.

Other than the change to type 2 MIDI files, I expect the output of MIDI 
files in this version to match that in BP2.9.8 when the options "Store 
all items to same file" and "Write item immediately" are selected.  My 
initial tests have found identical binary output between the 32-bit and 
64-bit versions of BP3 console.

Please report any bugs, especially in the MIDI file output!


Example command lines
--------------------

Here are some examples to try from the "ctests" folder (you can use
"bp32" or "bp" instead of "bp64"):

../bp64 --version
../bp64 --help

../bp64 produce -gr.NotReich
../bp64 produce -gr.NotReich -o NotReich.bpda
../bp64 produce -gr.NotReich -d --csoundout -
../bp64 produce -gr.NotReich -d --csoundout out.sco
../bp64 produce -gr.NotReich -d --midiout NotReich.mid

../bp64 templates -gr.checktemplates --traceout trace.txt

# the next two commands will generate some compilation errors
../bp64 compile symbols.bpgr
../bp64 compile symbols.bpgr --traceout trace.txt

# adding the alphabet file fixes them
../bp64 compile symbols.bpgr symbols.bpho --traceout trace.txt
../bp64 produce symbols.bpgr symbols.bpho

# type this all on one line
../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout
trace.txt --show-production

# type this all on one line
../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout
trace.txt --trace-production

../bp64 produce produce-all.bpgr
../bp64 produce-all produce-all.bpgr
../bp64 produce produce-all.bpgr -d --midiout out.mid

# type each of these commands all on one line
../bp64 produce produce-all.bpgr -d --midiout out-type-0.mid --seed 0 
--midiformat 0
../bp64 produce produce-all.bpgr -d --midiout out-type-1.mid --seed 0 
--midiformat 1
../bp64 produce produce-all.bpgr -d --midiout out-type-2.mid --seed 0 
--midiformat 2

# this command will also generate some compilation errors
../bp64 compile -gr.Nadaka --traceout Nadaka-errors.txt

# adding the --indian option fixes them
../bp64 compile --indian -gr.Nadaka
../bp64 produce --indian -gr.Nadaka
../bp64 produce --indian -gr.Nadaka -d --rtmidi

# the --indian option is not needed if the correct -se file is used
../bp64 produce -gr.Nadaka -se.hamsad
../bp64 produce -gr.Nadaka -se.hamsad --midiout Nadaka.mid


Updating to the latest code
---------------------------

The "bolprocessor" folder contains a Git repository.  Before you can
download changes from Sourceforge you will need to reconfigure the
remote settings because they are set up to use my username.  You can do
so with these commands:

    git remote remove origin
    git remote add -f origin git://git.code.sf.net/p/bolprocessor/git
    git branch --set-upstream-to=origin/ANSI-branch ANSI-branch

After that, you can update to the latest code on Sourceforge anytime
with just the command

    git pull

If you have made changes to the source code, it is safer to do

    git fetch

and examine any non-local changes first!

--------

I hope that this snapshot works for all of you.  Inquire here on the
developer list if you have problems.

Anthony

Re: [bp-dev] MIDI files on BP.2.9.8

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

Dear Anthony,

This is a partial answer to your message.

Today I completed the management of MIDI files on the Timbase and 
Prototype pages. At last I understand the timing parameters.

The important ones are "division" and "tempo".

"Tempo" alone is sufficient to designate the speed of the item. It is 
the duration of a quarternote (i.e. 1 beat) in microseconds. In BP the 
speed is fixed by Pclock and Qclock, namely how many beats (Pclock) in 
how many seconds (Qclock). We use an integer ratio which yields perfect 
accuracy.

So, by default, if mm = 60 beats per minute, Pclock = Qclock = 1. The 
period of the clock is 1 second and tempo = 1000000 (µs).

If mm = 120 bpm, Pclock = 2 and Qclock = 1. The period of the clock is 
0.5 second and tempo = 500000 (µs).

I think it is good to set this parameter according to the current Pclock 
and Qclock.

In "-gr.Visser.Waves", Harm did something unusual. He used the default 
mm = 60 bpm, but since the piece was too fast he wrote _tempo(0.8) at 
the beginning to slow it down. Yet, this is a "performance parameter" 
that we can't guess only from the MIDI file. He should have removed this 
parameter and set Pclock = 8, Qclock = 10.  Or simplify: Pclock = 4, 
Qclock = 5. Which yields tempo = 5/4 * 1000000 = 1250000.

Now, about "division"…

MIDI files contain time signatures which are number of "ticks". 
"Division" is the number of ticks in a quarternote. So, the duration of 
a tick is tempo/division (µs). We have complete freedom to decide on 
that duration as it won't change the playback. However, in BP I always 
used milliseconds for time signatures - as they are the ones needed for 
real-time MIDI streams.

Therefore, tempo/division = 1000. Once you know the tempo, calculate 
division = tempo / 1000 and assign milliseconds to time signatures. This 
will work perfectly.

On the PHP interface I fix MIDI files adding Meta track names. I am no 
longer sure, it seems that missing track names was crashing a process. 
The thing I am sure is that "Meta TrkEnd" is compulsory before TrkEnd, 
and its time signature must be the same as the last event.

I remember that in BP2 I had set up a slow volume fading out at the end 
of the piece because ending suddenly would produce unwanted noise on the 
D50. But this might be related with the missing code at the end! You can 
try to get rid of it. Playing the MIDIfile on a syth piano with 
resonance will indicate whether this is required or not.

I don't think it would make sense to include a TimeSig event in the 
first track. By default I insert "0 TimeSig 4/4 24 8" though I don't 
know what "24" and "8" stand for. This might be used for communication 
with a rhythm box.

The typical beginning of a MIDI file (in MF2T notation) is:

MFile 1 2 1000
MTrk
0 Meta TrkName "header"
0 TimeSig 1/4 24 8
0 Tempo 1000000
0 KeySig 0 major
0 Meta TrkEnd
TrkEnd
MTrk
0 Meta TrkName "track_1"
0 On ch=1 n=48 v=50
890 On ch=1 n=54 v=50
1780 On ch=1 n=48 v=0
1780 On ch=1 n=61 v=50
...

Here, "1780" is a time signature in milliseconds since division = 1000 and tempo = 1000000.

So, you see that I use one track only for the settings, among which TimeSig and KeySig are probably unnecessary. But some machines might require them even if they don't mean anything…

Type-0 files? No use, I believe. You can produce a type-1 file even with a single track. If you follow the idea of a "header" track then you will get at least 2 tracks.

I am not sure that we still can deal with producing MIDI files in the "Non-stop improvize" mode. It is supposed not to end until the machine receives a "stop" signal: key stroke or MIDI event (or Apple event in BP2). We could only tell the console to produce x items and store each one in a separate file. Or maybe "pipe" each file to a synthesizer and delete it afterwards — which would be a manner of doing almost real-time production!

Finally, I might have replied all questions. ;-)

Bernard


Anthony Kozar wrote on 14/08/2020 22:31:
> Thanks! This is all timely information since I have been working on 
> rewriting Midi file output in BP Console over the past two weeks.  
> I've ended up making many more changes than were strictly necessary.  
> Some will hopefully make the code more portable.  Some involve just 
> refactoring duplicated code into separate functions, etc.  There are 
> also two functions that I decided to rewrite from scratch because the 
> previous code appeared to have been copied from that MIDI file 
> specification document that you sent me, Bernard.
>
> Unfortunately, I haven't finished this task yet because of various 
> other things that have come up.
>
> Comments below...
>
> On 8/13/20, 5:20 AM, Bernard Bel wrote:
>> More on this topic:
>>
>> I was wrong regarding "division": in this MIDI file, division = 1000 is
>> the correct value, provided that we keep the information contained in
>> the first track, namely "TimeSig" and "Tempo".
>
> Yes, I have noticed that BP2 always writes a division of 1000, 
> presumably for millisecond accuracy?
>
>> The content of the MIDI file is attached in MF2T text format to make
>> things clear.
>>
>> The original content was incorrect and MIDIjs refused to play it. It
>> became correct after adding these metadata:
>>
>> 0 Meta TrkName "imported_1"
>> ...
>> 0 Meta TrkName "imported_2"
>> ...
>> 171250 Meta TrkEnd
> >
>> Therefore, tracks require (arbitrary) names and a "Meta TrkEnd" should
>> be placed just before each "TrkEnd" instruction. At least, these are
>> requirements for MIDIclass.php to produce a MIDI file accepted by 
>> MIDIjs.
>
> The specification that you sent does not say that the Meta TrkName 
> events are required.  It just says "Sequence Number and
> Sequence/Track Name events, if present, must appear at time 0." 
> However, it should be easy to add them for compatibility if desired.
>
> The "Meta TrkEnd" is required and BP2.9.8 should write it.  But the 
> TrkEnd for the final track appears not to be written until the file is 
> closed.  Therefore, I suspect that you may have copied the Midi file 
> before BP2 closed it.  This is related to the problem reported by Rob 
> Moore.  Perhaps it would be better to finish writing the file and 
> close it at the end of performance unless BP is in a mode where 
> producing multiple items is expected?  Alternatively, the file could 
> always be closed at the end of performance and reopened and extended 
> if necessary.
>
>> When trying to import it to a sound-object prototype I got an error in
>> MIDIclass.php indicating that the last event (a NoteOff) had been lost.
>> The file was imported anyway but the last event was missing. We do get
>> the last NoteOn timed 171250 ms but we miss its NoteOff around 180000 
>> ms.
>
> This is probably related to the same problem above.  The last normal 
> Midi event also does not get written until the file is closed.
>
> There are other related problems that I have discovered too.  If 
> "Non-stop improvise" is on with the option to write each item to a new 
> MIDI file after it is performed then the track duration is equal to 
> the total elapsed time of the performance _including_ the time it 
> takes the user to enter a file name and click "Save"!  It also appears 
> that that BP2 may be writing "0" for the time of the "Meta TrkEnd" 
> event when it should correspond to the track duration.
>
> If it sounds like the second issue contradicts the first, I think it 
> because BP2 writes a lot of volume controller events at the end of 
> each track to "fade out" the performance and that lengthens the track 
> if it doesn't occur immediately.  Is there a good reason for this fade 
> out?  I can imagine it being confusing if the MIDI file is played back 
> on a synth and then the user tries to play notes on that synth outside 
> of BP2 and hears no sound as a result.
>
>> In addition, the "division" found by MIDIclass is "1000" yielding a
>> faster playback. It should be set to "480" for a reason I still don't
>> understand…
>
> If I am remembering correctly, I think 480 is a common division of the 
> quarter note for MIDI sequencers.  I always thought it strange too, 
> but if you factor 480 you get 2*2*2*2*2*3*5 which is a clue, I think.  
> This division allows quarter notes to be accurately subdivided into 
> 128th notes or any triplet or quintuplet division of the power-of-2 
> note durations.  So, 480 divisions could be more accurate for some 
> music than the 1000 divisions BP2 is using.
>
>> Problems are identical when exporting type 0 and type 1 files. We should
>> avoid type 0 anyway, even though BP always produces single-track files.
>
> What is the reason for avoiding type 0?
>
>> This trace might be helpful for the design of MIDIfile export on the
>> console…
>
> Yes, thank you for delving into these issues!  I'll keep all of this 
> in mind as I work on the code.
>
> Anthony

Re: [bp-dev] MIDI files on BP.2.9.8

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

Thanks!  This is all timely information since I have been working on 
rewriting Midi file output in BP Console over the past two weeks.  I've 
ended up making many more changes than were strictly necessary.  Some 
will hopefully make the code more portable.  Some involve just 
refactoring duplicated code into separate functions, etc.  There are 
also two functions that I decided to rewrite from scratch because the 
previous code appeared to have been copied from that MIDI file 
specification document that you sent me, Bernard.

Unfortunately, I haven't finished this task yet because of various other 
things that have come up.

Comments below...

On 8/13/20, 5:20 AM, Bernard Bel wrote:
> More on this topic:
>
> I was wrong regarding "division": in this MIDI file, division = 1000 is
> the correct value, provided that we keep the information contained in
> the first track, namely "TimeSig" and "Tempo".

Yes, I have noticed that BP2 always writes a division of 1000, 
presumably for millisecond accuracy?

> The content of the MIDI file is attached in MF2T text format to make
> things clear.
>
> The original content was incorrect and MIDIjs refused to play it. It
> became correct after adding these metadata:
>
> 0 Meta TrkName "imported_1"
> ...
> 0 Meta TrkName "imported_2"
> ...
> 171250 Meta TrkEnd
 >
> Therefore, tracks require (arbitrary) names and a "Meta TrkEnd" should
> be placed just before each "TrkEnd" instruction. At least, these are
> requirements for MIDIclass.php to produce a MIDI file accepted by MIDIjs.

The specification that you sent does not say that the Meta TrkName 
events are required.  It just says "Sequence Number and
Sequence/Track Name events, if present, must appear at time 0." 
However, it should be easy to add them for compatibility if desired.

The "Meta TrkEnd" is required and BP2.9.8 should write it.  But the 
TrkEnd for the final track appears not to be written until the file is 
closed.  Therefore, I suspect that you may have copied the Midi file 
before BP2 closed it.  This is related to the problem reported by Rob 
Moore.  Perhaps it would be better to finish writing the file and close 
it at the end of performance unless BP is in a mode where producing 
multiple items is expected?  Alternatively, the file could always be 
closed at the end of performance and reopened and extended if necessary.

> When trying to import it to a sound-object prototype I got an error in
> MIDIclass.php indicating that the last event (a NoteOff) had been lost.
> The file was imported anyway but the last event was missing. We do get
> the last NoteOn timed 171250 ms but we miss its NoteOff around 180000 ms.

This is probably related to the same problem above.  The last normal 
Midi event also does not get written until the file is closed.

There are other related problems that I have discovered too.  If 
"Non-stop improvise" is on with the option to write each item to a new 
MIDI file after it is performed then the track duration is equal to the 
total elapsed time of the performance _including_ the time it takes the 
user to enter a file name and click "Save"!  It also appears that that 
BP2 may be writing "0" for the time of the "Meta TrkEnd" event when it 
should correspond to the track duration.

If it sounds like the second issue contradicts the first, I think it 
because BP2 writes a lot of volume controller events at the end of each 
track to "fade out" the performance and that lengthens the track if it 
doesn't occur immediately.  Is there a good reason for this fade out?  I 
can imagine it being confusing if the MIDI file is played back on a 
synth and then the user tries to play notes on that synth outside of BP2 
and hears no sound as a result.

> In addition, the "division" found by MIDIclass is "1000" yielding a
> faster playback. It should be set to "480" for a reason I still don't
> understand…

If I am remembering correctly, I think 480 is a common division of the 
quarter note for MIDI sequencers.  I always thought it strange too, but 
if you factor 480 you get 2*2*2*2*2*3*5 which is a clue, I think.  This 
division allows quarter notes to be accurately subdivided into 128th 
notes or any triplet or quintuplet division of the power-of-2 note 
durations.  So, 480 divisions could be more accurate for some music than 
the 1000 divisions BP2 is using.

> Problems are identical when exporting type 0 and type 1 files. We should
> avoid type 0 anyway, even though BP always produces single-track files.

What is the reason for avoiding type 0?

> This trace might be helpful for the design of MIDIfile export on the
> console…

Yes, thank you for delving into these issues!  I'll keep all of this in 
mind as I work on the code.

Anthony

Re: [bp-dev] Time-base

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

Dear all,

I completed the Timebase interface and uploaded its PHP code to 
https://leti.lt/bolprocessor/

Now it is possible to load a MIDIfile (e.g. a file created by BP2.9.8) 
and play it in superposition with the tick cycle.

Indeed, this only makes sense when beat patterns are identical. For 
instance, if you load "this_song.mid" you need to set the metronome to 
1000 beats in 444.444 seconds (meaning mm = 135 beats/min). How to guess 
it? I am working on an automatic setting as the MIDI file indicates 
"tempo = 444 444", i.e. the duration of a quarternote in microseconds.

Still, more adjustment may be required, for instance with 
"Visser.Waves.mid" which was produced at tempo 0.8 by 
"-gr.Visser.Waves". In this case, the metronome should be set to 8 beats 
in 10 seconds. The machine cannot guess it and it is not recorded in the 
MIDI file. (The pattern for this piece is a 5-beat cycle, which is not 
evident because of its complex polymetric structure!)

I have clarified the signification and effects of parameters "division" 
and "tempo" in MIDI files. All downloaded files are "normalized" such 
that division = 1000 and tempo = 1000 000 µs. The reason is that we want 
time signatures to indicate milliseconds rather than ticks of various 
durations. The result of this adjustement can be verified by looking at 
MF2T code files on the interface.

The combination works well. It is safe to use channels different than 
the ones of the tune to avoid jammed NoteOn/NoteOffs yiedling 
undesirable effects.

The combination uses a "lazy" method: adding a track to the MIDI file. 
This is not the way the console would deal with it. We will rather send 
a sequence of time-stamped MIDI bytes that will be inserted into the 
output stream of MIDI events. The console will be instructed to play 
this sequence in a continous loop, which is not very complicated.

The accuracy is very good and independent of the duration of the piece.

I will be busy for a couple of days, but don't hesitate to post comments 
and suggestions!

Bernard

[bp-dev] MIDI files on BP.2.9.8

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

More on this topic:

I was wrong regarding "division": in this MIDI file, division = 1000 is 
the correct value, provided that we keep the information contained in 
the first track, namely "TimeSig" and "Tempo".

The content of the MIDI file is attached in MF2T text format to make 
things clear.

The original content was incorrect and MIDIjs refused to play it. It 
became correct after adding these metadata:

0 Meta TrkName "imported_1"
...
0 Meta TrkName "imported_2"
...
171250 Meta TrkEnd

Therefore, tracks require (arbitrary) names and a "Meta TrkEnd" should 
be placed just before each "TrkEnd" instruction. At least, these are 
requirements for MIDIclass.php to produce a MIDI file accepted by MIDIjs.

The corrected MIDI file is attached, namely "imported_codes.mid". Both 
MIDIjs and PianoTeq accept it. (It sounds way better on PianoTeq!)

Bernard


----------

I checked MIDI files types 0 and 1 produced by BP2.9.8.

For instance I produced the enclosed "Visser.Waves1.mid" using 
"-gr.Visser.Waves".

When trying to import it to a sound-object prototype I got an error in 
MIDIclass.php indicating that the last event (a NoteOff) had been lost. 
The file was imported anyway but the last event was missing. We do get 
the last NoteOn timed 171250 ms but we miss its NoteOff around 180000 ms.

I modified "MIDIclass.php" so that it does not attempt to pick up the 
missing event, but the result is unchanged. Only the error message 
disappears.

In addition, the "division" found by MIDIclass is "1000" yielding a 
faster playback. It should be set to "480" for a reason I still don't 
understand…

Problems are identical when exporting type 0 and type 1 files. We should 
avoid type 0 anyway, even though BP always produces single-track files.

This trace might be helpful for the design of MIDIfile export on the 
console…

Bernard

[bp-dev] MIDI files on BP.2.9.8

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

I checked MIDI files types 0 and 1 produced by BP2.9.8.

For instance I produced the enclosed "Visser.Waves1.mid" using 
"-gr.Visser.Waves".

When trying to import it to a sound-object prototype I got an error in 
MIDIclass.php indicating that the last event (a NoteOff) had been lost. 
The file was imported anyway but the last event was missing. We do get 
the last NoteOn timed 171250 ms but we miss its NoteOff around 180000 ms.

I modified "MIDIclass.php" so that it does not attempt to pick up the 
missing event, but the result is unchanged. Only the error message 
disappears.

In addition, the "division" found by MIDIclass is "1000" yielding a 
faster playback. It should be set to "480" for a reason I still don't 
understand…

Problems are identical when exporting type 0 and type 1 files. We should 
avoid type 0 anyway, even though BP always produces single-track files.

This trace might be helpful for the design of MIDIfile export on the 
console…

Bernard

Re: [bp-dev] Time-base

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

New: the Timebase interface now creates sounds that can be heard via the 
MIDIjs application.

I upgraded the interface, allowing to add as many tracks as needed.

You can check the "-tb" file stored in "ctests.zip". Most of them are 
demos of traditional rhythmic cycles (tala) used by North-Indian musicians.

Try "-cs.slowshift" to hear the complexity of patterns that can be 
produced thanks to "speed ratios" assigned to each track. If played at 
fast speed this example is a good indication of the time accuracy of the 
MIDI player.

Replacing MIDI notes with sounds on an electronic drum machine will 
indeed yield a musical content!

My plan now is to allow the combination of these rhythmic patterns with 
musical items supplied via a MIDI file. This is theoretically very easy 
and will give an idea of the use of time bases in BP.

Bernard

--------

Dear all,

I completed the editor of Timebases that loads/saves "-tb" files. The 
PHP code (mainly "timebase.php") has been uploaded to 
https://leti.lt/bolprocessor/ and I also stored a revised set of 
examples "ctests.zip".

Only "-tb" files created by BP2.9.8 are correctly read by the new 
interface. Therefore I saved again all files available in example sets. 
Updated versions are in "ctests.zip".

Just now, it may not be evident to figure out what these Timebases are 
about! The interface does not yet produce sounds, nor did BP2.9.8 
because it was not correctly scheduling the ticks. They are still 
audible on MacOS 9 versions and very soon on the PHP interface…

Bernard Bel

Re: [bp-dev] Time-base

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

Dear all,

I completed the editor of Timebases that loads/saves "-tb" files. The 
PHP code (mainly "timebase.php") has been uploaded to 
https://leti.lt/bolprocessor/ and I also stored a revised set of 
examples "ctests.zip".

Only "-tb" files created by BP2.9.8 are correctly read by the new 
interface. Therefore I saved again all files available in example sets. 
Updated versions are in "ctests.zip".

Just now, it may not be evident to figure out what these Timebases are 
about! The interface does not yet produce sounds, nor did BP2.9.8 
because it was not correctly scheduling the ticks. They are still 
audible on MacOS 9 versions and very soon on the PHP interface…

Bernard Bel

Re: [bp-dev] Creating a Bol Processor website

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

Dear Anthony,

You are right, the site is already ready and running. The SSL key is now 
ready:

https://bolprocessor.org

OVH did it automatically; it always take a couple of hours.

I will of course grant you admin rights!

We can move it later for any good reason. There is an extension for 
moving an entire site including database and images.

Bernard

Anthony Kozar wrote on 10/08/2020 17:03:
> Yes, I think that this is a great idea!  I see there is already a 
> brand new WordPress site at bolprocessor.org!  :)
>
> I'm sorry that I didn't see your message yesterday as I might have 
> been able to save you the hosting costs.  I can host an unlimited 
> number of domains with my Dreamhost account at no additional cost.  
> So, if you ever want to move the site to my hosting service, that 
> would be possible.
>
> I am very familiar with WordPress too.  I have developed about 6 sites 
> using it including customizing the PHP templates for several sites.  
> If you are willing to provide me with a user account on the new site, 
> I can help with moving over some of the info from the Sourceforge site.
>
> Will you be able to add an SSL certificate to the new site without any 
> additional fees?  Let's Encrypt offers free certificates.
>
> Great work!
>
> Anthony
>
>
> On 8/9/20, 12:00 PM, Bernard Bel wrote:
>> If you agree with this proposal, I would like to create a Wordpress
>> website associated with domain "bolprocessor.org" (and/or other
>> extensions). A semi-professional hosting at OVH costs aroung 80 USD per
>> year, which I can afford… :-)
>>
>> This hosting would not allow us to run the console from pages driven by
>> the site, but I believe that the project of "on-line BP" should stay as
>> a project until we've implemented and checked all procedures in a
>> local-PHP environment.
>>
>> I feel the need to structure documentation for developers and future
>> users of the next Bol Processor who may temporarily try features on
>> BP2.9.8. A lot of information is circulating on this list which would
>> deserve being exposed, along with pictures and concrete examples
>> tentatively classified on a website.
>>
>> Wordpress is a good candidate to do this work — at least I am conversant
>> with its environment! To begin with, we could start with a
>> free-of-charge theme enhanced by half a dozen free-of-charge extensions
>> allowing a better classification of pages and posts.
>>
>> In the longer term, "when time permits", we would also feed the site
>> with revised contents of the old on-line documentation.
>>
>> Ready to start?
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Csound objects

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

I don't remember well. The playback of ticks was correct under OMS, as I 
remember demonstrating it in Cambridge under MacOS 9, and possibly it 
got broken in the MacOS 10 migration. Fixing it would only be 
interesting for BP2.9.9 which hopefully will be replaced with the new 
(BP2.10 or BP3 ?) So, I am not sure it is worth investigating, except 
for the pleasure of a challenge. ;-)

In the same way, we might need "type from MIDI" in the interface rather 
than in the console. I still need to find how to do it. Perhaps simply 
using another piece of software picking up data from a MIDI keyboard and 
saving it as a MIDI file… I'll try to figure it out in the Timebase editor.

Bernard

Anthony Kozar wrote on 10/08/2020 17:13:
> Sounds great!
>
> I tried the file -tb.rubak and as you said it doesn't seem to work 
> correctly.  I wonder if I broke the tick playback when I implemented 
> the CoreMIDI driver?  IIRC, there were some differences between OMS & 
> the serial driver in the way MIDI messages were routed thru BP2 code.  
> I didn't fully understand which code paths I should use in the new 
> driver and maybe I chose incorrectly.
>
> In fact, there is a problem in BP 2.9.8 that I've noticed with MIDI 
> input.  It shows up when one enters many notes quickly with "type from 
> MIDI".  BP 2.9.8 seems to pause noticeably between displaying each 
> note in the input window.  I think this is due to the event loop being 
> called in between the processing of each MIDI event.  I should try to 
> fix this problem for BP 2.9.9.
>
> Anthony
>
>
> On 8/9/20, 11:40 AM, Bernard Bel wrote:
>> I keep thinking about it when it gets too dark to walk in the forest! 
>> ;-)
>>
>> For the moment I try to reproduce procedures the very way they had been
>> designed in projects such as "-gr.tryCsoundObjects". I had designed a
>> few simple Csound instruments that for instance would "translate"
>> pitchbend messages to changes of frequency. THis may have an incidence
>> on the procedure of "translating" a MIDI sequence to a Csound score in
>> an object. I'll try to clarify how far it had been done. All this will
>> be taken care of by the interface when designing sound-object
>> prototypes, with no incidence on the console.
>>
>> Same thing with the Timebase: I am going to implement an advanced model
>> for generating "ticks", but mixing them with real-time MIDI output of
>> the console will be much easier than the former solution (which anyway
>> no longer worked). It is also very easy to merge MIDI files and this
>> method can be used now that machines have become much quicker writing
>> MIDI files! 

Re: [bp-dev] Csound objects

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

Sounds great!

I tried the file -tb.rubak and as you said it doesn't seem to work 
correctly.  I wonder if I broke the tick playback when I implemented the 
CoreMIDI driver?  IIRC, there were some differences between OMS & the 
serial driver in the way MIDI messages were routed thru BP2 code.  I 
didn't fully understand which code paths I should use in the new driver 
and maybe I chose incorrectly.

In fact, there is a problem in BP 2.9.8 that I've noticed with MIDI 
input.  It shows up when one enters many notes quickly with "type from 
MIDI".  BP 2.9.8 seems to pause noticeably between displaying each note 
in the input window.  I think this is due to the event loop being called 
in between the processing of each MIDI event.  I should try to fix this 
problem for BP 2.9.9.

Anthony


On 8/9/20, 11:40 AM, Bernard Bel wrote:
> I keep thinking about it when it gets too dark to walk in the forest! ;-)
>
> For the moment I try to reproduce procedures the very way they had been
> designed in projects such as "-gr.tryCsoundObjects". I had designed a
> few simple Csound instruments that for instance would "translate"
> pitchbend messages to changes of frequency. THis may have an incidence
> on the procedure of "translating" a MIDI sequence to a Csound score in
> an object. I'll try to clarify how far it had been done. All this will
> be taken care of by the interface when designing sound-object
> prototypes, with no incidence on the console.
>
> Same thing with the Timebase: I am going to implement an advanced model
> for generating "ticks", but mixing them with real-time MIDI output of
> the console will be much easier than the former solution (which anyway
> no longer worked). It is also very easy to merge MIDI files and this
> method can be used now that machines have become much quicker writing
> MIDI files!

Re: [bp-dev] Creating a Bol Processor website

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

Yes, I think that this is a great idea!  I see there is already a brand 
new WordPress site at bolprocessor.org!  :)

I'm sorry that I didn't see your message yesterday as I might have been 
able to save you the hosting costs.  I can host an unlimited number of 
domains with my Dreamhost account at no additional cost.  So, if you 
ever want to move the site to my hosting service, that would be possible.

I am very familiar with WordPress too.  I have developed about 6 sites 
using it including customizing the PHP templates for several sites.  If 
you are willing to provide me with a user account on the new site, I can 
help with moving over some of the info from the Sourceforge site.

Will you be able to add an SSL certificate to the new site without any 
additional fees?  Let's Encrypt offers free certificates.

Great work!

Anthony


On 8/9/20, 12:00 PM, Bernard Bel wrote:
> If you agree with this proposal, I would like to create a Wordpress
> website associated with domain "bolprocessor.org" (and/or other
> extensions). A semi-professional hosting at OVH costs aroung 80 USD per
> year, which I can afford… :-)
>
> This hosting would not allow us to run the console from pages driven by
> the site, but I believe that the project of "on-line BP" should stay as
> a project until we've implemented and checked all procedures in a
> local-PHP environment.
>
> I feel the need to structure documentation for developers and future
> users of the next Bol Processor who may temporarily try features on
> BP2.9.8. A lot of information is circulating on this list which would
> deserve being exposed, along with pictures and concrete examples
> tentatively classified on a website.
>
> Wordpress is a good candidate to do this work — at least I am conversant
> with its environment! To begin with, we could start with a
> free-of-charge theme enhanced by half a dozen free-of-charge extensions
> allowing a better classification of pages and posts.
>
> In the longer term, "when time permits", we would also feed the site
> with revised contents of the old on-line documentation.
>
> Ready to start?
>
> Bernard

[bp-dev] Creating a Bol Processor website

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

If you agree with this proposal, I would like to create a Wordpress 
website associated with domain "bolprocessor.org" (and/or other 
extensions). A semi-professional hosting at OVH costs aroung 80 USD per 
year, which I can afford… :-)

This hosting would not allow us to run the console from pages driven by 
the site, but I believe that the project of "on-line BP" should stay as 
a project until we've implemented and checked all procedures in a 
local-PHP environment.

I feel the need to structure documentation for developers and future 
users of the next Bol Processor who may temporarily try features on 
BP2.9.8. A lot of information is circulating on this list which would 
deserve being exposed, along with pictures and concrete examples 
tentatively classified on a website.

Wordpress is a good candidate to do this work — at least I am conversant 
with its environment! To begin with, we could start with a 
free-of-charge theme enhanced by half a dozen free-of-charge extensions 
allowing a better classification of pages and posts.

In the longer term, "when time permits", we would also feed the site 
with revised contents of the old on-line documentation.

Ready to start?

Bernard

Re: [bp-dev] Csound objects

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

I keep thinking about it when it gets too dark to walk in the forest! ;-)

For the moment I try to reproduce procedures the very way they had been 
designed in projects such as "-gr.tryCsoundObjects". I had designed a 
few simple Csound instruments that for instance would "translate" 
pitchbend messages to changes of frequency. THis may have an incidence 
on the procedure of "translating" a MIDI sequence to a Csound score in 
an object. I'll try to clarify how far it had been done. All this will 
be taken care of by the interface when designing sound-object 
prototypes, with no incidence on the console.

Same thing with the Timebase: I am going to implement an advanced model 
for generating "ticks", but mixing them with real-time MIDI output of 
the console will be much easier than the former solution (which anyway 
no longer worked). It is also very easy to merge MIDI files and this 
method can be used now that machines have become much quicker writing 
MIDI files!

Bernard

Anthony Kozar wrote on 06/08/2020 16:33:
> Working on you holiday, huh? ;-)
>
> I don't really know how to answer your questions right now either.  I 
> haven't really created any sound-object prototypes with Csound events 
> or experimented with any situations where the constraints are applied.
>
> We might need to create some specific examples with different types of 
> Csound instruments to fully appreciate the issues.
>
> Anthony
>
> On 8/6/20, 4:10 AM, Bernard Bel wrote:
>> Dear all,
>>
>> I had a short break in town, enough time to implement a few changes in
>> the images of sound-object prototypes. The updated PHP code has been
>> uploaded to https://leti.lt/bolprocessor/
>>
> > [...]
> >
>> Things get more complicated with respect to topological constraints. If
>> the MIDI sequence needs to be truncated at the beginning and/or the end,
>>    can we truncate the Csound sequence in the same way? Dealing with 
>> MIDI
>> means only displacing NoteOns and NoteOffs and suppressing continuous
>> changes such as pitchbend or pressure. But I cannot yet imagine that we
>> could manipulate a Csound object so easily. This requires reflection.
>>
>> As far as I remember, BP2.9.8 (and the current console) never tries to
>> truncate Csound events. They are only resized and displaced according to
>> constraints. Maybe we should stay with that?
>>
>> Bernard
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Csound objects

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

Working on you holiday, huh? ;-)

I don't really know how to answer your questions right now either.  I 
haven't really created any sound-object prototypes with Csound events or 
experimented with any situations where the constraints are applied.

We might need to create some specific examples with different types of 
Csound instruments to fully appreciate the issues.

Anthony

On 8/6/20, 4:10 AM, Bernard Bel wrote:
> Dear all,
>
> I had a short break in town, enough time to implement a few changes in
> the images of sound-object prototypes. The updated PHP code has been
> uploaded to https://leti.lt/bolprocessor/
>
 > [...]
 >
> Things get more complicated with respect to topological constraints. If
> the MIDI sequence needs to be truncated at the beginning and/or the end,
>    can we truncate the Csound sequence in the same way? Dealing with MIDI
> means only displacing NoteOns and NoteOffs and suppressing continuous
> changes such as pitchbend or pressure. But I cannot yet imagine that we
> could manipulate a Csound object so easily. This requires reflection.
>
> As far as I remember, BP2.9.8 (and the current console) never tries to
> truncate Csound events. They are only resized and displaced according to
> constraints. Maybe we should stay with that?
>
> Bernard

[bp-dev] Csound objects

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

Dear all,

I had a short break in town, enough time to implement a few changes in 
the images of sound-object prototypes. The updated PHP code has been 
uploaded to https://leti.lt/bolprocessor/

Look at sound-object a' in "-mi.abc1". It has both MIDI events and a 
Csound score. Its Csound score has been created automatically from MIDI 
events, using NoteOn and NoteOff events and their key numbers, 
velocities etc. I have not yet checked this procedure which I plan to 
implement on the PHP interface.

At present, the image displayed contains both MIDI and Csound events.

Nothing special because MIDI and Csound "scores" yield the same duration 
= 1500 ms = 1 beat. The Csound score makes it clear that mm = 40, which 
means a period of 1500 ms.

However, in general, the Csound score may not be a mere translation of 
the MIDI sequence. We expect more complicated constructions. For 
instance, the duration of the Csound score might not be equal to that of 
the MIDI sequence. These different durations will appear on the image.

Things get more complicated with respect to topological constraints. If 
the MIDI sequence needs to be truncated at the beginning and/or the end, 
  can we truncate the Csound sequence in the same way? Dealing with MIDI 
means only displacing NoteOns and NoteOffs and suppressing continuous 
changes such as pitchbend or pressure. But I cannot yet imagine that we 
could manipulate a Csound object so easily. This requires reflection.

As far as I remember, BP2.9.8 (and the current console) never tries to 
truncate Csound events. They are only resized and displaced according to 
constraints. Maybe we should stay with that?

Bernard

[bp-dev] Time-base

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

Dear all,

A very practical feature of BP2 — at least for educational material — 
has been left out from development for the main reason that it stopped 
working properly. I mean the "Time base", see enclosed picture.

It was working up to the MacOS 9 version and perhaps started being 
erratic as I dropped the in-built MIDI timer for OMS. Today, if you 
click the "PLAY TICKS" button, you will hear ticks without connection to 
what has been programmed. On the picture we have a default 4 beat 
sequence in which the first tick is played on key 96 and the following 3 
ticks are on key 84. Thus, you can program as many of 3 cycles of 40 
beats each, and even set up each cycle for a different speed ratio. This 
opens on very intricate rhythmic patterns. We used it to model most 
rhythmic cycles (tala) used in North Indian music. See for instance the 
enclosed "rupak" 7-beat cycle.

This feature is educational in the sense that a sophisticated metronome 
can highlight rythmic patterns which most listeners would not identify 
in a musical piece. An example is "-gr.Visser.Waves": it sounds 
"arythmic" because of its complexity. However, superimposing a cycle of 
5 beats renders the pattern audible. I remember having done it in a 
conference at Cambridge UK to convince a musician/linguist that the 
"waving" effect wasn't the result of randomization but of a 
self-imbedding polymetric structure.

How can we revive this in the next version? It is probably easier than I 
had anticipated. I will construct the same interface in the PHP 
environment so that time base cycles can be created independently and 
checked via the MIDI file player. Then the sequence will be sent to the 
console along with the grammar or data expected to produce the musical 
item. It may be sent as a sequence of time-stamped MIDI bytes or a MIDI 
file; the format is not important because timings will be exactly the 
ones expected to fit with the musical item. The console will only need 
to mix these codes with the ones it is sending to the MIDI sound device.

So, the complexity of editing a time base cycle will entirely be taken 
care of by the interface.

It's on my "to-do" list after the stay in mountains. ;-)

Bernard

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

I see SuperMario with his kids below a Christmas tree. The kids are not pleased by the speed of 7 beats per ? The grace of their dance movements is ruined.

PS: I knew you wouldn’t go to sleep!!! We nerds are all the same… :D

Best
.r.

> On 1. Aug 2020, at 23:27, Bernard Bel <ber...@gm...> wrote:
> 
> Since you are getting image and sound at the moment, you may try the last procedure: importing a MIDI file into a sound-object.
> 
> See "Create or replace MIDI codes loading a MIDI file..." at the boootom of the page. Click "Choose File", select a file, then "send". You can try this Xmas song which I uploaded as "this_song.mid" because it has various instruments and several tracks. I am confident Windows will play it correctly.
> 
> Then change its duration, for instance down to 7 beats to play it faster. Other buttons suppress evenst such as pitchbend or volume but that's not audible on this file.
> 
> Now we can move to more constructive tasks :-)
> 
> Bernard
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel