bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] Real-time MIDI

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

Midishare (from Grame) is still around.  A new package for OS X El 
Capitan was posted about two years ago.  It is not clear to me whether 
this package has any code changes compared to the previous release for 
Mac OS X but the libraries in it are Universal binaries for i386 and 
x86_64.  While there has been activity in the Git repository as recent 
as 2016, the last Windows and Linux releases appear to be from 2013 and 
2006 respectively.

http://midishare.sourceforge.net/

The JACK Audio Connection Kit is cross-platform and appears to have some 
support for real-time MIDI even though it is primarily a tool for 
routing audio signals.  The JACK project appears to be pretty active.

https://jackaudio.org/

Overall, I am guessing that PortMidi will be the easiest to distribute 
with BP so that BP users don't have to install anything extra.  But I'm 
really not that familiar with any of these libraries.

Anthony


On 8/19/20, 11:20 PM, Bernard Bel wrote:
> It has a drawback: "RtMidi does not provide timing functionality (i.e.,
> output messages are sent immediately)."
>
> In the tutorial (http://www.music.mcgill.ca/~gary/rtmidi/), time spacing
> between events is created by a "sleep" function which is
> platform-dependent. My objection is that it will cumulate errors.
> However, developers might have found tricks to avoid error cumulation —
> unless they estimate that it is not so important.
>
> One of the reasons for insisting on time accuracy is that several BPs
> improvizing together would need to stay perfectly synchronized (without
> sending specific MIDI messages for their synchonization).
>
> Bernard
>
>
> Rainer Schuetz wrote on 20/08/2020 00:36:
>> You might want to have a look at RtMidi for comparison:
>>
>> https://github.com/thestk/rtmidi
>>
>> There are Portaudio and Portmidi, and RtAudio and RtMidi… The later seem
>> to be a result of some lack of responsiveness of the team behind the
>> “portXYs”. I can’t make a judgement at all but I know that projects that
>> still have a choice, tend to prefer the RtXY’s for the community
>> responsiveness, and the codebase is much more recent.
>>
>> Best
>> .r.

Re: [bp-dev] New BP3 console snapshot

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

Good! I will try to use this test...

Bernard Bel

> Le 21 août 2020 à 22:38, Anthony Kozar <mai...@an...> a écrit :
> 
> The tenth byte in a MIDI file (or byte 9 if indexed from 0) is the format.  Values are 0, 1, or 2 as one would expect.
> 
> Anthony
> 
> 
>> On 8/19/20, 11:32 PM, Bernard Bel wrote:
>> 
>> I haven't yet found a way of checking the type of a MIDI file before
>> trying to process it with MIDI class…
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] New BP3 console snapshot

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

The tenth byte in a MIDI file (or byte 9 if indexed from 0) is the 
format.  Values are 0, 1, or 2 as one would expect.

Anthony


On 8/19/20, 11:32 PM, Bernard Bel wrote:

> I haven't yet found a way of checking the type of a MIDI file before
> trying to process it with MIDI class…

Re: [bp-dev] Real-time MIDI

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

> On 20. Aug 2020, at 05:20, Bernard Bel <ber...@gm...> wrote:
> 
> One of the reasons for insisting on time accuracy is that several BPs improvizing together would need to stay perfectly synchronized (without sending specific MIDI messages for their synchonization).

Sounds convincing!
.r.

Re: [bp-dev] New BP3 console snapshot

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

This is true. I set "-se.hamsad" to type-1 MIDI files and the 
"-gr.Nadaka" grammar produced a file that played perfectly.

I haven't yet found a way of checking the type of a MIDI file before 
trying to process it with MIDI class…

Bernard

Anthony Kozar wrote on 19/08/2020 21:03:
> I checked and the MIDI files that didn't work are type 2.  I'm guessing 
> that the file -se.hamsad was saved with MIDI type 2 selected.  You can 
> either edit it or use the --midiformat option to regenerate the MIDI file.
> 
> I'm glad that NotReich64.mid worked for you!  If you install QuickTime 
> Player version 7.x, you will be able to check that MIDI files can be 
> played by it.  Newer versions of QuickTime no longer support MIDI files. :(
> 
> Anthony
> 
> 
> On 8/19/20, 2:36 PM, Bernard Bel wrote:
>> If I try to load Nadaka.mid to a sound-object prototpe, MIDI class
>> replies with the error message:
>>
>> Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code:1 Stack trace: #0
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407):
>> eval() #1
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492):
>> _err('only SMF Typ 0 ...') #2
>> /Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693):
>> Midi->importMid('../temp_bolproc...') #3
>> /Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60):
>> convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi),
>> '../temp_bolproc...') #4 {main} thrown in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code on line
>>
>>
>> With Nadaka32.mid and Nadaka64.mid it's the same:
>>
>> Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code:1 Stack trace: #0
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407):
>> eval() #1
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492):
>> _err('only SMF Typ 0 ...') #2
>> /Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693):
>> Midi->importMid('../temp_bolproc...') #3
>> /Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60):
>> convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi),
>> '../temp_bolproc...') #4 {main} thrown in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code on line 1
>>
>> But NotReich64.mid loaded and played perfectly.
>>
>> Bernard

Re: [bp-dev] Real-time MIDI

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

It has a drawback: "RtMidi does not provide timing functionality (i.e., 
output messages are sent immediately)."

In the tutorial (http://www.music.mcgill.ca/~gary/rtmidi/), time spacing 
between events is created by a "sleep" function which is 
platform-dependent. My objection is that it will cumulate errors. 
However, developers might have found tricks to avoid error cumulation — 
unless they estimate that it is not so important.

One of the reasons for insisting on time accuracy is that several BPs 
improvizing together would need to stay perfectly synchronized (without 
sending specific MIDI messages for their synchonization).

Bernard


Rainer Schuetz wrote on 20/08/2020 00:36:
> You might want to have a look at RtMidi for comparison:
> 
> https://github.com/thestk/rtmidi
> 
> There are Portaudio and Portmidi, and RtAudio and RtMidi… The later seem 
> to be a result of some lack of responsiveness of the team behind the 
> “portXYs”. I can’t make a judgement at all but I know that projects that 
> still have a choice, tend to prefer the RtXY’s for the community 
> responsiveness, and the codebase is much more recent.
> 
> Best
> .r.
> 
> 

Re: [bp-dev] Real-time MIDI

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

You might want to have a look at RtMidi for comparison:

https://github.com/thestk/rtmidi <https://github.com/thestk/rtmidi>

There are Portaudio and Portmidi, and RtAudio and RtMidi… The later seem to be a result of some lack of responsiveness of the team behind the “portXYs”. I can’t make a judgement at all but I know that projects that still have a choice, tend to prefer the RtXY’s for the community responsiveness, and the codebase is much more recent.

Best
.r.



> On 19. Aug 2020, at 22:39, Bernard Bel <ber...@gm...> wrote:
> 
> PS. I haven't checked PortMIDI, but it might handle a message that would cancel all cued events… Being able to stop playing immediately is quite important. This is the only reason why I had suggesyed a separate scheduler.
> 
> -------
> 
> This sounds very encouraging. Maybe start with PortMIDI (http://portmedia.sourceforge.net/portmidi/ <http://portmedia.sourceforge.net/portmidi/>) since it has been recently fixed for Windows, and you have experience with it. Since the environments (CoreMIDI, MME, ALSA) are different, I suppose that conditional compilation will be necessary… 
> 
> I guess that the difficulty in picking up accurate timings from the system is the reason why Rick's event scheduler was using assembly language. I had forgotten that time() returns dates with 1 second resolution! 
> 
> We do have events in chronological order with increasing time-stamps, so the implementation won't affect time-setting algorithms. 
> 
> Indeed, these "free of charge but…" licenses sound a bit unsane ! 
> 
> Bernard 
> 
> Anthony Kozar wrote on 19/08/2020 22:12: 
>> Bernard, 
>> 
>> I'm sorry that I didn't reply to this thread earlier to soothe your late night worries!  PortMidi DOES appear to support timestamped messages. 
>> 
>> The GitHub project you looked at is for a PortMidi binding in the Go language.  The project for the original C library is here: 
>> 
>> http://portmedia.sourceforge.net/portmidi/ <http://portmedia.sourceforge.net/portmidi/> 
>> 
>> The functions for writing MIDI data to a stream are described in the documentation as 
>> 
>> PmError Pm_WriteShort (PortMidiStream *stream, PmTimestamp when, long msg) 
>> Pm_WriteShort() writes a timestamped non-system-exclusive midi message. 
>> Messages are delivered in order as received, and timestamps must be non-decreasing. (But timestamps are ignored if the stream was opened with latency = 0.) 
>> 
>> PmError    Pm_WriteSysEx (PortMidiStream *stream, PmTimestamp when, unsigned char *msg) 
>> Pm_WriteSysEx() writes a timestamped system-exclusive midi message. 
>> 
>> I also looked at the source code which has a little more information about the latency parameter.  If we set a positive latency of at least 1 ms, then the timestamps will be honored and PortMidi will use the system's native Midi scheduler if there is one.  (CoreMIDI has a very accurate scheduler with times measured in nanoseconds!)  Only with a latency of 0 would the timestamps be ignored.  So, I think we can either let the system or PortMidi schedule the events or do it ourselves. 
>> 
>> I think it will be easier for getting started to send timestamped messages and let the native libraries on macOS/Windows/Linux do the scheduling if they support that.  On today's multitasking OSes it is much harder, I think, to guarantee that a program can accurately perform timed tasks without resorting to system-specific timer calls and possibly a multithreaded architecture.  IIRC, functions like sleep() are not guaranteed to return in time and the function time() has only 1 second precision.  For the CoreMIDI driver, I used functions from the CoreAudio library to get very precise times from the system clock and convert them to milliseconds to use for BP2's ClockZero reference time. 
>> 
>> That said, I am definitely open to other options for a cross-platform MIDI library.  I was just aware of PortMidi because it is used by Csound and some other software I've used.  But there was a very recent discussion on the Csound dev list about how PortMidi had not been updated in a very long time and was causing some issues with their Windows build.  The problem appears to have been solved by contacting the PortMidi developers and they patched the source code repository this month, IIRC.  But if there is a better supported, open-source library out there, I think we should strongly consider it. 
>> 
>> Although I have heard some good "buzz" about JUCE in the past, I didn't realize that it is not open source.  I think the JUCE licensing model would definitely be a deterrent to other developers getting involved in BP development or reusing BP in their own projects. 
>> 
>> Anthony 
>> 
>> P.S. Rick Taube has made some great music software tools over the years (primarily Common Music which I used to use).  Even though the source code for his software was available to everyone, it was not always possible for other individuals to redistribute his software with modifications because he used tools that required expensive redistribution licenses (~$2000-2500 IIRC for Macintosh Common Lisp). He would purchase those distribution licenses so that anyone could use his software (I assume with grant money).  But it was disappointing to me that I couldn't distribute Mac OS 9 builds of software made with MCL after he (and others) stopped even though I purchased a (user-level) license for MCL. 
>> 
>> 
>> On 8/19/20, 2:01 PM, Bernard Bel wrote: 
>>> I thought about all this again last night… 
>>> 
>>> The argument that PortMIDI only accepting real-time MIDI messages rather 
>>> than time-stamped MIDI events would generate a cumulation of errors does 
>>> not hold! It is easy to schedule events according to absolute time 
>>> (starting from a defined zero date). 
>>> 
>>> The following is (approximate) code for playing a 2-second C major chord 
>>> starting after 1 second. 
>>> 
>>> time_zero = time(); // milliseconds 
>>> 
>>> next_event_date = 1000; 
>>> while(time() < (time_zero + next_event_date)) { 
>>>     $result = ListenMIDI(); 
>>>     if($result == STOP) break; 
>>>     } 
>>> 
>>> out.WriteShort(0x90, 60, 100) 
>>> out.WriteShort(0x90, 64, 100) 
>>> out.WriteShort(0x90, 67, 100) 
>>> 
>>> next_event_date = 2000; 
>>> while(time() < (time_zero + next_event_date)) { 
>>>     $result = ListenMIDI(); 
>>>     if($result == STOP) break; 
>>>     } 
>>> 
>>> out.WriteShort(0x80, 60, 100) 
>>> out.WriteShort(0x80, 64, 100) 
>>> out.WriteShort(0x80, 67, 100) 
>>> 
>>> Variables "next_event_date" are the time stamps that we used to imbed 
>>> into MIDI events. We could even count in microseconds at the same cost. ;-) 
>>> 
>>> ListenMIDI() is trying to capture an incoming event (or a keyboard 
>>> stroke) that would instruct the console to modify some settings or stop 
>>> playing immediately. (It is already implemented.) 
>>> 
>>> Frankly I don't understand why a complex scheduler was required when it 
>>> looks so simple. Maybe there is a hidden problem that I haven't figured out! 
>>> 
>>> If you create a very simple C program, we can check this procedure and 
>>> then implement it in the console. The only difficult problem, which 
>>> PortMIDI will solve, is the connection to MIDI in/out devices… 
>>> 
>>> I also felt reluctant to use a framework like JUCE because it has a 
>>> license that might prevent the reuse of BP3 in other (possibly 
>>> commercial) environments. 
>>> 
>>> Bernard 
>>> 
>>> ----------- 
>>> 
>>> 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 <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 
>> 
>> 
>> _______________________________________________ 
>> bolprocessor-devel mailing list 
>> bol...@li... <mailto:bol...@li...> 
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] New BP3 console snapshot

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

THis will probably be equivalent to the current version.

The PHP interface picks up the file's name and searches for it in the 
same folder as the grammar or data file. An implicit rule is that 
related files should be located in the same folder.

This may lack flexibility when an alphabet or sound-object file is 
shared by several grammars/data in different folders. Either it is 
duplicated or (on the Mac) we use aliases. BP2 was resolving aliases to 
this effect, but that's merely MacOS.

A more sophisticated device would search for the file in parent 
directories till the root. So, shared files would be placed higher in 
the hierarchy. This looks good. I can also implement it in PHP, but if 
it is there in the core program the design of interfaces will be easier.

Bernard

Anthony Kozar wrote on 19/08/2020 22:40:
> (Hmmm... I started this reply hours ago and thought I sent it.  
> Appears that I didn't...)
>
> Bernard,
>
> I'm glad that things are working for you.
>
> I can still restore the ability to auto-load related files.  The 
> console program may not always know where to find them, but it can at 
> least try a) the path given (if any) for the file that contains the 
> reference, and b) the current directory.
>
> I've added these two items to the To Do List file:
>
> - identify input files with prefixes even when they are preceded by a 
> path
>
> - restore the feature that looks for names of related files in the 
> input files and auto-loads them
>
> Anthony
>
>
> On 8/19/20, 1:27 PM, Bernard Bel wrote:
>> Dear Anthony.
>>
>> I did a quick check and everything worked.
>>
>> It compiled. Then, after modifying the interface, I forced the console
>> to read the settings file and get the note convention. It also worked.
>>
>> I still need to check other options.
>>
>> It is now clear that instructions such as
>>
>> -or.Nadaka
>> -se.hamsad
>>
>> on top of the grammar are ignored by the console and must be read by the
>> interface to add the options to the command line. This is logocal
>> because the console cannot guess the full path.
>>
>> Compilations also worked and used note conventions found in the 
>> settings.
>>
>> This was a minimum test but I am uplaoding the revised PHP files.
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] New BP3 console snapshot

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

(Hmmm... I started this reply hours ago and thought I sent it.  Appears 
that I didn't...)

Bernard,

I'm glad that things are working for you.

I can still restore the ability to auto-load related files.  The console 
program may not always know where to find them, but it can at least try 
a) the path given (if any) for the file that contains the reference, and 
b) the current directory.

I've added these two items to the To Do List file:

- identify input files with prefixes even when they are preceded by a path

- restore the feature that looks for names of related files in the input 
files and auto-loads them

Anthony


On 8/19/20, 1:27 PM, Bernard Bel wrote:
> Dear Anthony.
>
> I did a quick check and everything worked.
>
> It compiled. Then, after modifying the interface, I forced the console
> to read the settings file and get the note convention. It also worked.
>
> I still need to check other options.
>
> It is now clear that instructions such as
>
> -or.Nadaka
> -se.hamsad
>
> on top of the grammar are ignored by the console and must be read by the
> interface to add the options to the command line. This is logocal
> because the console cannot guess the full path.
>
> Compilations also worked and used note conventions found in the settings.
>
> This was a minimum test but I am uplaoding the revised PHP files.
>
> Bernard

Re: [bp-dev] Real-time MIDI

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

PS. I haven't checked PortMIDI, but it might handle a message that would 
cancel all cued events… Being able to stop playing immediately is quite 
important. This is the only reason why I had suggesyed a separate scheduler.

-------

This sounds very encouraging. Maybe start with PortMIDI 
(http://portmedia.sourceforge.net/portmidi/) since it has been recently 
fixed for Windows, and you have experience with it. Since the 
environments (CoreMIDI, MME, ALSA) are different, I suppose that 
conditional compilation will be necessary…

I guess that the difficulty in picking up accurate timings from the 
system is the reason why Rick's event scheduler was using assembly 
language. I had forgotten that time() returns dates with 1 second 
resolution!

We do have events in chronological order with increasing time-stamps, so 
the implementation won't affect time-setting algorithms.

Indeed, these "free of charge but…" licenses sound a bit unsane !

Bernard

Anthony Kozar wrote on 19/08/2020 22:12:
> Bernard,
>
> I'm sorry that I didn't reply to this thread earlier to soothe your 
> late night worries!  PortMidi DOES appear to support timestamped 
> messages.
>
> The GitHub project you looked at is for a PortMidi binding in the Go 
> language.  The project for the original C library is here:
>
> http://portmedia.sourceforge.net/portmidi/
>
> The functions for writing MIDI data to a stream are described in the 
> documentation as
>
> PmError Pm_WriteShort (PortMidiStream *stream, PmTimestamp when, long 
> msg)
> Pm_WriteShort() writes a timestamped non-system-exclusive midi message.
> Messages are delivered in order as received, and timestamps must be 
> non-decreasing. (But timestamps are ignored if the stream was opened 
> with latency = 0.)
>
> PmError    Pm_WriteSysEx (PortMidiStream *stream, PmTimestamp when, 
> unsigned char *msg)
> Pm_WriteSysEx() writes a timestamped system-exclusive midi message.
>
> I also looked at the source code which has a little more information 
> about the latency parameter.  If we set a positive latency of at least 
> 1 ms, then the timestamps will be honored and PortMidi will use the 
> system's native Midi scheduler if there is one.  (CoreMIDI has a very 
> accurate scheduler with times measured in nanoseconds!)  Only with a 
> latency of 0 would the timestamps be ignored.  So, I think we can 
> either let the system or PortMidi schedule the events or do it ourselves.
>
> I think it will be easier for getting started to send timestamped 
> messages and let the native libraries on macOS/Windows/Linux do the 
> scheduling if they support that.  On today's multitasking OSes it is 
> much harder, I think, to guarantee that a program can accurately 
> perform timed tasks without resorting to system-specific timer calls 
> and possibly a multithreaded architecture.  IIRC, functions like 
> sleep() are not guaranteed to return in time and the function time() 
> has only 1 second precision.  For the CoreMIDI driver, I used 
> functions from the CoreAudio library to get very precise times from 
> the system clock and convert them to milliseconds to use for BP2's 
> ClockZero reference time.
>
> That said, I am definitely open to other options for a cross-platform 
> MIDI library.  I was just aware of PortMidi because it is used by 
> Csound and some other software I've used.  But there was a very recent 
> discussion on the Csound dev list about how PortMidi had not been 
> updated in a very long time and was causing some issues with their 
> Windows build.  The problem appears to have been solved by contacting 
> the PortMidi developers and they patched the source code repository 
> this month, IIRC.  But if there is a better supported, open-source 
> library out there, I think we should strongly consider it.
>
> Although I have heard some good "buzz" about JUCE in the past, I 
> didn't realize that it is not open source.  I think the JUCE licensing 
> model would definitely be a deterrent to other developers getting 
> involved in BP development or reusing BP in their own projects.
>
> Anthony
>
> P.S. Rick Taube has made some great music software tools over the 
> years (primarily Common Music which I used to use).  Even though the 
> source code for his software was available to everyone, it was not 
> always possible for other individuals to redistribute his software 
> with modifications because he used tools that required expensive 
> redistribution licenses (~$2000-2500 IIRC for Macintosh Common Lisp). 
> He would purchase those distribution licenses so that anyone could use 
> his software (I assume with grant money).  But it was disappointing to 
> me that I couldn't distribute Mac OS 9 builds of software made with 
> MCL after he (and others) stopped even though I purchased a 
> (user-level) license for MCL.
>
>
> On 8/19/20, 2:01 PM, Bernard Bel wrote:
>> I thought about all this again last night…
>>
>> The argument that PortMIDI only accepting real-time MIDI messages rather
>> than time-stamped MIDI events would generate a cumulation of errors does
>> not hold! It is easy to schedule events according to absolute time
>> (starting from a defined zero date).
>>
>> The following is (approximate) code for playing a 2-second C major chord
>> starting after 1 second.
>>
>> time_zero = time(); // milliseconds
>>
>> next_event_date = 1000;
>> while(time() < (time_zero + next_event_date)) {
>>     $result = ListenMIDI();
>>     if($result == STOP) break;
>>     }
>>
>> out.WriteShort(0x90, 60, 100)
>> out.WriteShort(0x90, 64, 100)
>> out.WriteShort(0x90, 67, 100)
>>
>> next_event_date = 2000;
>> while(time() < (time_zero + next_event_date)) {
>>     $result = ListenMIDI();
>>     if($result == STOP) break;
>>     }
>>
>> out.WriteShort(0x80, 60, 100)
>> out.WriteShort(0x80, 64, 100)
>> out.WriteShort(0x80, 67, 100)
>>
>> Variables "next_event_date" are the time stamps that we used to imbed
>> into MIDI events. We could even count in microseconds at the same 
>> cost. ;-)
>>
>> ListenMIDI() is trying to capture an incoming event (or a keyboard
>> stroke) that would instruct the console to modify some settings or stop
>> playing immediately. (It is already implemented.)
>>
>> Frankly I don't understand why a complex scheduler was required when it
>> looks so simple. Maybe there is a hidden problem that I haven't 
>> figured out!
>>
>> If you create a very simple C program, we can check this procedure and
>> then implement it in the console. The only difficult problem, which
>> PortMIDI will solve, is the connection to MIDI in/out devices…
>>
>> I also felt reluctant to use a framework like JUCE because it has a
>> license that might prevent the reuse of BP3 in other (possibly
>> commercial) environments.
>>
>> Bernard
>>
>> -----------
>>
>> 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
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Real-time MIDI

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

This sounds very encouraging. Maybe start with PortMIDI 
(http://portmedia.sourceforge.net/portmidi/) since it has been recently 
fixed for Windows, and you have experience with it. Since the 
environments (CoreMIDI, MME, ALSA) are different, I suppose that 
conditional compilation will be necessary…

I guess that the difficulty in picking up accurate timings from the 
system is the reason why Rick's event scheduler was using assembly 
language. I had forgotten that time() returns dates with 1 second 
resolution!

We do have events in chronological order with increasing time-stamps, so 
the implementation won't affect time-setting algorithms.

Indeed, these "free of charge but…" licenses sound a bit unsane !

Bernard

Anthony Kozar wrote on 19/08/2020 22:12:
> Bernard,
>
> I'm sorry that I didn't reply to this thread earlier to soothe your 
> late night worries!  PortMidi DOES appear to support timestamped 
> messages.
>
> The GitHub project you looked at is for a PortMidi binding in the Go 
> language.  The project for the original C library is here:
>
> http://portmedia.sourceforge.net/portmidi/
>
> The functions for writing MIDI data to a stream are described in the 
> documentation as
>
> PmError Pm_WriteShort (PortMidiStream *stream, PmTimestamp when, long 
> msg)
> Pm_WriteShort() writes a timestamped non-system-exclusive midi message.
> Messages are delivered in order as received, and timestamps must be 
> non-decreasing. (But timestamps are ignored if the stream was opened 
> with latency = 0.)
>
> PmError    Pm_WriteSysEx (PortMidiStream *stream, PmTimestamp when, 
> unsigned char *msg)
> Pm_WriteSysEx() writes a timestamped system-exclusive midi message.
>
> I also looked at the source code which has a little more information 
> about the latency parameter.  If we set a positive latency of at least 
> 1 ms, then the timestamps will be honored and PortMidi will use the 
> system's native Midi scheduler if there is one.  (CoreMIDI has a very 
> accurate scheduler with times measured in nanoseconds!)  Only with a 
> latency of 0 would the timestamps be ignored.  So, I think we can 
> either let the system or PortMidi schedule the events or do it ourselves.
>
> I think it will be easier for getting started to send timestamped 
> messages and let the native libraries on macOS/Windows/Linux do the 
> scheduling if they support that.  On today's multitasking OSes it is 
> much harder, I think, to guarantee that a program can accurately 
> perform timed tasks without resorting to system-specific timer calls 
> and possibly a multithreaded architecture.  IIRC, functions like 
> sleep() are not guaranteed to return in time and the function time() 
> has only 1 second precision.  For the CoreMIDI driver, I used 
> functions from the CoreAudio library to get very precise times from 
> the system clock and convert them to milliseconds to use for BP2's 
> ClockZero reference time.
>
> That said, I am definitely open to other options for a cross-platform 
> MIDI library.  I was just aware of PortMidi because it is used by 
> Csound and some other software I've used.  But there was a very recent 
> discussion on the Csound dev list about how PortMidi had not been 
> updated in a very long time and was causing some issues with their 
> Windows build.  The problem appears to have been solved by contacting 
> the PortMidi developers and they patched the source code repository 
> this month, IIRC.  But if there is a better supported, open-source 
> library out there, I think we should strongly consider it.
>
> Although I have heard some good "buzz" about JUCE in the past, I 
> didn't realize that it is not open source.  I think the JUCE licensing 
> model would definitely be a deterrent to other developers getting 
> involved in BP development or reusing BP in their own projects.
>
> Anthony
>
> P.S. Rick Taube has made some great music software tools over the 
> years (primarily Common Music which I used to use).  Even though the 
> source code for his software was available to everyone, it was not 
> always possible for other individuals to redistribute his software 
> with modifications because he used tools that required expensive 
> redistribution licenses (~$2000-2500 IIRC for Macintosh Common Lisp). 
> He would purchase those distribution licenses so that anyone could use 
> his software (I assume with grant money).  But it was disappointing to 
> me that I couldn't distribute Mac OS 9 builds of software made with 
> MCL after he (and others) stopped even though I purchased a 
> (user-level) license for MCL.
>
>
> On 8/19/20, 2:01 PM, Bernard Bel wrote:
>> I thought about all this again last night…
>>
>> The argument that PortMIDI only accepting real-time MIDI messages rather
>> than time-stamped MIDI events would generate a cumulation of errors does
>> not hold! It is easy to schedule events according to absolute time
>> (starting from a defined zero date).
>>
>> The following is (approximate) code for playing a 2-second C major chord
>> starting after 1 second.
>>
>> time_zero = time(); // milliseconds
>>
>> next_event_date = 1000;
>> while(time() < (time_zero + next_event_date)) {
>>     $result = ListenMIDI();
>>     if($result == STOP) break;
>>     }
>>
>> out.WriteShort(0x90, 60, 100)
>> out.WriteShort(0x90, 64, 100)
>> out.WriteShort(0x90, 67, 100)
>>
>> next_event_date = 2000;
>> while(time() < (time_zero + next_event_date)) {
>>     $result = ListenMIDI();
>>     if($result == STOP) break;
>>     }
>>
>> out.WriteShort(0x80, 60, 100)
>> out.WriteShort(0x80, 64, 100)
>> out.WriteShort(0x80, 67, 100)
>>
>> Variables "next_event_date" are the time stamps that we used to imbed
>> into MIDI events. We could even count in microseconds at the same 
>> cost. ;-)
>>
>> ListenMIDI() is trying to capture an incoming event (or a keyboard
>> stroke) that would instruct the console to modify some settings or stop
>> playing immediately. (It is already implemented.)
>>
>> Frankly I don't understand why a complex scheduler was required when it
>> looks so simple. Maybe there is a hidden problem that I haven't 
>> figured out!
>>
>> If you create a very simple C program, we can check this procedure and
>> then implement it in the console. The only difficult problem, which
>> PortMIDI will solve, is the connection to MIDI in/out devices…
>>
>> I also felt reluctant to use a framework like JUCE because it has a
>> license that might prevent the reuse of BP3 in other (possibly
>> commercial) environments.
>>
>> Bernard
>>
>> -----------
>>
>> 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
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Real-time MIDI

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

Bernard,

I'm sorry that I didn't reply to this thread earlier to soothe your late 
night worries!  PortMidi DOES appear to support timestamped messages.

The GitHub project you looked at is for a PortMidi binding in the Go 
language.  The project for the original C library is here:

http://portmedia.sourceforge.net/portmidi/

The functions for writing MIDI data to a stream are described in the 
documentation as

PmError Pm_WriteShort (PortMidiStream *stream, PmTimestamp when, long msg)
Pm_WriteShort() writes a timestamped non-system-exclusive midi message.
Messages are delivered in order as received, and timestamps must be 
non-decreasing. (But timestamps are ignored if the stream was opened 
with latency = 0.)

PmError	Pm_WriteSysEx (PortMidiStream *stream, PmTimestamp when, 
unsigned char *msg)
Pm_WriteSysEx() writes a timestamped system-exclusive midi message.

I also looked at the source code which has a little more information 
about the latency parameter.  If we set a positive latency of at least 1 
ms, then the timestamps will be honored and PortMidi will use the 
system's native Midi scheduler if there is one.  (CoreMIDI has a very 
accurate scheduler with times measured in nanoseconds!)  Only with a 
latency of 0 would the timestamps be ignored.  So, I think we can either 
let the system or PortMidi schedule the events or do it ourselves.

I think it will be easier for getting started to send timestamped 
messages and let the native libraries on macOS/Windows/Linux do the 
scheduling if they support that.  On today's multitasking OSes it is 
much harder, I think, to guarantee that a program can accurately perform 
timed tasks without resorting to system-specific timer calls and 
possibly a multithreaded architecture.  IIRC, functions like sleep() are 
not guaranteed to return in time and the function time() has only 1 
second precision.  For the CoreMIDI driver, I used functions from the 
CoreAudio library to get very precise times from the system clock and 
convert them to milliseconds to use for BP2's ClockZero reference time.

That said, I am definitely open to other options for a cross-platform 
MIDI library.  I was just aware of PortMidi because it is used by Csound 
and some other software I've used.  But there was a very recent 
discussion on the Csound dev list about how PortMidi had not been 
updated in a very long time and was causing some issues with their 
Windows build.  The problem appears to have been solved by contacting 
the PortMidi developers and they patched the source code repository this 
month, IIRC.  But if there is a better supported, open-source library 
out there, I think we should strongly consider it.

Although I have heard some good "buzz" about JUCE in the past, I didn't 
realize that it is not open source.  I think the JUCE licensing model 
would definitely be a deterrent to other developers getting involved in 
BP development or reusing BP in their own projects.

Anthony

P.S. Rick Taube has made some great music software tools over the years 
(primarily Common Music which I used to use).  Even though the source 
code for his software was available to everyone, it was not always 
possible for other individuals to redistribute his software with 
modifications because he used tools that required expensive 
redistribution licenses (~$2000-2500 IIRC for Macintosh Common Lisp). 
He would purchase those distribution licenses so that anyone could use 
his software (I assume with grant money).  But it was disappointing to 
me that I couldn't distribute Mac OS 9 builds of software made with MCL 
after he (and others) stopped even though I purchased a (user-level) 
license for MCL.


On 8/19/20, 2:01 PM, Bernard Bel wrote:
> I thought about all this again last night…
>
> The argument that PortMIDI only accepting real-time MIDI messages rather
> than time-stamped MIDI events would generate a cumulation of errors does
> not hold! It is easy to schedule events according to absolute time
> (starting from a defined zero date).
>
> The following is (approximate) code for playing a 2-second C major chord
> starting after 1 second.
>
> time_zero = time(); // milliseconds
>
> next_event_date = 1000;
> while(time() < (time_zero + next_event_date)) {
>     $result = ListenMIDI();
>     if($result == STOP) break;
>     }
>
> out.WriteShort(0x90, 60, 100)
> out.WriteShort(0x90, 64, 100)
> out.WriteShort(0x90, 67, 100)
>
> next_event_date = 2000;
> while(time() < (time_zero + next_event_date)) {
>     $result = ListenMIDI();
>     if($result == STOP) break;
>     }
>
> out.WriteShort(0x80, 60, 100)
> out.WriteShort(0x80, 64, 100)
> out.WriteShort(0x80, 67, 100)
>
> Variables "next_event_date" are the time stamps that we used to imbed
> into MIDI events. We could even count in microseconds at the same cost. ;-)
>
> ListenMIDI() is trying to capture an incoming event (or a keyboard
> stroke) that would instruct the console to modify some settings or stop
> playing immediately. (It is already implemented.)
>
> Frankly I don't understand why a complex scheduler was required when it
> looks so simple. Maybe there is a hidden problem that I haven't figured out!
>
> If you create a very simple C program, we can check this procedure and
> then implement it in the console. The only difficult problem, which
> PortMIDI will solve, is the connection to MIDI in/out devices…
>
> I also felt reluctant to use a framework like JUCE because it has a
> license that might prevent the reuse of BP3 in other (possibly
> commercial) environments.
>
> Bernard
>
> -----------
>
> 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] New BP3 console snapshot

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

Yes, the problem is with type 2 that MIDI class rejects without a 
friendly warning! ;-)

Bernard

Anthony Kozar wrote on 19/08/2020 21:03:
> I checked and the MIDI files that didn't work are type 2.  I'm 
> guessing that the file -se.hamsad was saved with MIDI type 2 
> selected.  You can either edit it or use the --midiformat option to 
> regenerate the MIDI file.
>
> I'm glad that NotReich64.mid worked for you!  If you install QuickTime 
> Player version 7.x, you will be able to check that MIDI files can be 
> played by it.  Newer versions of QuickTime no longer support MIDI 
> files. :(
>
> Anthony
>
>
> On 8/19/20, 2:36 PM, Bernard Bel wrote:
>> If I try to load Nadaka.mid to a sound-object prototpe, MIDI class
>> replies with the error message:
>>
>> Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code:1 Stack trace: #0
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407):
>> eval() #1
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492):
>> _err('only SMF Typ 0 ...') #2
>> /Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693):
>> Midi->importMid('../temp_bolproc...') #3
>> /Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60):
>> convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi),
>> '../temp_bolproc...') #4 {main} thrown in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code on line
>>
>>
>> With Nadaka32.mid and Nadaka64.mid it's the same:
>>
>> Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code:1 Stack trace: #0
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407):
>> eval() #1
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492):
>> _err('only SMF Typ 0 ...') #2
>> /Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693):
>> Midi->importMid('../temp_bolproc...') #3
>> /Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60):
>> convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi),
>> '../temp_bolproc...') #4 {main} thrown in
>> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
>> eval()'d code on line 1
>>
>> But NotReich64.mid loaded and played perfectly.
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] New BP3 console snapshot

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

I checked and the MIDI files that didn't work are type 2.  I'm guessing 
that the file -se.hamsad was saved with MIDI type 2 selected.  You can 
either edit it or use the --midiformat option to regenerate the MIDI file.

I'm glad that NotReich64.mid worked for you!  If you install QuickTime 
Player version 7.x, you will be able to check that MIDI files can be 
played by it.  Newer versions of QuickTime no longer support MIDI files. :(

Anthony


On 8/19/20, 2:36 PM, Bernard Bel wrote:
> If I try to load Nadaka.mid to a sound-object prototpe, MIDI class
> replies with the error message:
>
> Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
> eval()'d code:1 Stack trace: #0
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407):
> eval() #1
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492):
> _err('only SMF Typ 0 ...') #2
> /Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693):
> Midi->importMid('../temp_bolproc...') #3
> /Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60):
> convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi),
> '../temp_bolproc...') #4 {main} thrown in
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
> eval()'d code on line
>
>
> With Nadaka32.mid and Nadaka64.mid it's the same:
>
> Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
> eval()'d code:1 Stack trace: #0
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407):
> eval() #1
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492):
> _err('only SMF Typ 0 ...') #2
> /Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693):
> Midi->importMid('../temp_bolproc...') #3
> /Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60):
> convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi),
> '../temp_bolproc...') #4 {main} thrown in
> /Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) :
> eval()'d code on line 1
>
> But NotReich64.mid loaded and played perfectly.
>
> Bernard

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

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

I appreciate that!  I only quit the emulator a few minutes ago.  I 
decided to recreate one of my favorite BASIC programs for "wowing" 
people back in the day...

10 HGR2
20 HCOLOR = RND(1)*8
30 HPLOT 140,96 TO RND(1)*280,RND(1)*192
40 GOTO 20

;-)

I was disappointed that I couldn't remember the command for drawing a 
line (HPLOT).

Anthony


On 8/19/20, 2:11 PM, Bernard Bel wrote:

> I won't upload the diskette of "Mr Robot" Apple II game, otherwise you
> might just stop doing anything else :-)

Re: [bp-dev] New BP3 console snapshot

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

If I try to load Nadaka.mid to a sound-object prototpe, MIDI class 
replies with the error message:

Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) : 
eval()'d code:1 Stack trace: #0 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407): 
eval() #1 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492): 
_err('only SMF Typ 0 ...') #2 
/Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693): 
Midi->importMid('../temp_bolproc...') #3 
/Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60): 
convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi), 
'../temp_bolproc...') #4 {main} thrown in 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) : 
eval()'d code on line


With Nadaka32.mid and Nadaka64.mid it's the same:

Fatal error: Uncaught Exception: only SMF Typ 0 and 1 supported in 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) : 
eval()'d code:1 Stack trace: #0 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407): 
eval() #1 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(492): 
_err('only SMF Typ 0 ...') #2 
/Applications/MAMP/htdocs/try/bolprocessor/php/_basic_tasks.php(693): 
Midi->importMid('../temp_bolproc...') #3 
/Applications/MAMP/htdocs/try/bolprocessor/php/prototype.php(60): 
convert_mf2t_to_bytes(false, '../temp_bolproc...', Object(Midi), 
'../temp_bolproc...') #4 {main} thrown in 
/Applications/MAMP/htdocs/try/bolprocessor/php/midi.class.php(1407) : 
eval()'d code on line 1

But NotReich64.mid loaded and played perfectly.

Bernard

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

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

Yes, we'll need Jim's advice as I am equally confused! Your grammar 
looks correct in BP1 syntax. I am not sure that spaces are required and 
even allowed, because BP1 used to bind together terminal symbols and 
space only according to the specified tempo, if any, for instance "/4" 
to create blocks of 4 terminal symbols.

I will document the setting up of the emulation so that Jim can easily 
set it up. I will then send him your message to ask for explanations.

I won't upload the diskette of "Mr Robot" Apple II game, otherwise you 
might just stop doing anything else :-)

Bernard

Anthony Kozar wrote on 19/08/2020 19:54:
> Bernard,
>
> I have been able to figure out how to load, save, and edit (mostly) 
> alphabets, data, and grammars.  The interface is fairly intuitive and 
> vaguely familiar after having used BP2.  I like the "smart cursor" 
> feature that skips over each bol/token with a single press of the 
> arrow key! :)
>
> I have tried to derive something from a grammar but I am probably not 
> understanding the correct way to do so.  I'm also not sure what the 
> lexical requirements are for variables and terminals.  I created an 
> alphabet with the symbols C4, D4, E4 ... C5, D5 and started creating a 
> grammar with them, then it occurred to me that BP1 might think they 
> are variables since it has no notion of simple notes (right?).  So, I 
> added q,w,e,r,t,y to my alphabet and finished my grammar like this:
>
> S --> C4 D4 E4
> C4 --> q C4 r
> D4 --> w e
> D4 --> e w
> E4 --> t y
> E4 --> y t
> C4 --> D4
> C4 --> E4
>
> (I included spaces after each token in the alphabet.  I don't know if 
> that is valid but it does display the way I wanted it to in the Data & 
> Grammar editors).
>
> When I select "Compute" from the Grammar menu, I am taken to the first 
> data item and asked if I want to "Revise processing?".  I don't know 
> what that means.  I reply "Y" to that and "Step by Step?" and then BP1 
> beeps and displays the item (unchanged) along with the menu "Q)uit 
> P)rint R)epeat K)eep ..."
>
> Sometimes I get a different sequence of prompts for "Compute" 
> including "First grammar?" and "Last grammar?" followed by the menu 
> "A)nalyse S)ynthesize D)estroy structure ..."  I reply with 1, 1, and 
> S for Synthesize, "N" to "Create templates?" and "Systematic 
> tree-search?", "Y" to "Step by Step?" and I'm back at the menu "Q)uit 
> P)rint R)epeat K)eep ..." with no change or derivation of the item.  
> (I performed these steps starting from the Data menu for an item 
> containing only "S"). *shrug*
>
> There is no need for you to try to explain right now what is happening 
> and where I am going wrong.  As you said in your message, you "have 
> not yet found the way of producing items!" either. ;-)  I can wait 
> until you have time to consult with Jim Kippen and/or to work it out 
> on your own.
>
> I'm curious to hear what the "Sound" option does but I think you may 
> be right that Catakig may not be fully functional in that area.  I 
> hear nothing when I choose that option from the menu.  (But I also 
> have no idea what sort of data is required for it to work).
>
> Well, BP1 is lots of fun.  It's tempting to keep playing with it 
> instead of working on other things. ;-)  But there are issues to 
> address in email and the BP3 code.
>
> Anthony
>
> P.S.  I also had to read the Catakig User Guide just to figure out how 
> to turn the Apple II on.  Not very intuitive. :(
>
>
> On 8/19/20, 1:08 AM, Bernard Bel wrote:
>> This is very encouraging!
>>
>> Next week I will post a tutorial on http://bolprocessor.org to explain
>> how to install an emulator and start running BP1. Make it easier to find
>> the Apple IIe ROM and "create" the machine, then how to insert diskettes
>> in the proper "drive".
>>
>> I may suggest running one of the free-of-charge emulators. I tried
>> catakig and it worked after figuring out (from their user guide) that
>> you need to press the space bar to "switch it on" when snow appears on
>> the screen. ;-)
>>
>> True, usage of the "control" key wasn't evident as it was the one
>> located near the space bar…
>>
>> This latest version of BP1 was also making sounds in the Apple II
>> speaker. This was fun but useless for research! With virtualii we can
>> make sounds. I am not sure catakig will do it.
>>
>> I have not yet found the way of producing items! Jim Kippen probably
>> will remember. Then we'll write a new tutorial. There was one in the
>> past but it got lost, some AppleWriter file…
>>
>> I also plan return to Marseille and transfer more data disks. All these
>> 40-year old floppy disks were read without difficulty! :-)
>>
>> 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 thought about all this again last night…

The argument that PortMIDI only accepting real-time MIDI messages rather 
than time-stamped MIDI events would generate a cumulation of errors does 
not hold! It is easy to schedule events according to absolute time 
(starting from a defined zero date).

The following is (approximate) code for playing a 2-second C major chord 
starting after 1 second.

time_zero = time(); // milliseconds

next_event_date = 1000;
while(time() < (time_zero + next_event_date)) {
   $result = ListenMIDI();
   if($result == STOP) break;
   }

out.WriteShort(0x90, 60, 100)
out.WriteShort(0x90, 64, 100)
out.WriteShort(0x90, 67, 100)

next_event_date = 2000;
while(time() < (time_zero + next_event_date)) {
   $result = ListenMIDI();
   if($result == STOP) break;
   }

out.WriteShort(0x80, 60, 100)
out.WriteShort(0x80, 64, 100)
out.WriteShort(0x80, 67, 100)

Variables "next_event_date" are the time stamps that we used to imbed 
into MIDI events. We could even count in microseconds at the same cost. ;-)

ListenMIDI() is trying to capture an incoming event (or a keyboard 
stroke) that would instruct the console to modify some settings or stop 
playing immediately. (It is already implemented.)

Frankly I don't understand why a complex scheduler was required when it 
looks so simple. Maybe there is a hidden problem that I haven't figured out!

If you create a very simple C program, we can check this procedure and 
then implement it in the console. The only difficult problem, which 
PortMIDI will solve, is the connection to MIDI in/out devices…

I also felt reluctant to use a framework like JUCE because it has a 
license that might prevent the reuse of BP3 in other (possibly 
commercial) environments.

Bernard

-----------

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

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

Bernard,

I have been able to figure out how to load, save, and edit (mostly) 
alphabets, data, and grammars.  The interface is fairly intuitive and 
vaguely familiar after having used BP2.  I like the "smart cursor" 
feature that skips over each bol/token with a single press of the arrow 
key! :)

I have tried to derive something from a grammar but I am probably not 
understanding the correct way to do so.  I'm also not sure what the 
lexical requirements are for variables and terminals.  I created an 
alphabet with the symbols C4, D4, E4 ... C5, D5 and started creating a 
grammar with them, then it occurred to me that BP1 might think they are 
variables since it has no notion of simple notes (right?).  So, I added 
q,w,e,r,t,y to my alphabet and finished my grammar like this:

S --> C4 D4 E4
C4 --> q C4 r
D4 --> w e
D4 --> e w
E4 --> t y
E4 --> y t
C4 --> D4
C4 --> E4

(I included spaces after each token in the alphabet.  I don't know if 
that is valid but it does display the way I wanted it to in the Data & 
Grammar editors).

When I select "Compute" from the Grammar menu, I am taken to the first 
data item and asked if I want to "Revise processing?".  I don't know 
what that means.  I reply "Y" to that and "Step by Step?" and then BP1 
beeps and displays the item (unchanged) along with the menu "Q)uit 
P)rint R)epeat K)eep ..."

Sometimes I get a different sequence of prompts for "Compute" including 
"First grammar?" and "Last grammar?" followed by the menu "A)nalyse 
S)ynthesize D)estroy structure ..."  I reply with 1, 1, and S for 
Synthesize, "N" to "Create templates?" and "Systematic tree-search?", 
"Y" to "Step by Step?" and I'm back at the menu "Q)uit P)rint R)epeat 
K)eep ..." with no change or derivation of the item.  (I performed these 
steps starting from the Data menu for an item containing only "S").  *shrug*

There is no need for you to try to explain right now what is happening 
and where I am going wrong.  As you said in your message, you "have not 
yet found the way of producing items!" either. ;-)  I can wait until you 
have time to consult with Jim Kippen and/or to work it out on your own.

I'm curious to hear what the "Sound" option does but I think you may be 
right that Catakig may not be fully functional in that area.  I hear 
nothing when I choose that option from the menu.  (But I also have no 
idea what sort of data is required for it to work).

Well, BP1 is lots of fun.  It's tempting to keep playing with it instead 
of working on other things. ;-)  But there are issues to address in 
email and the BP3 code.

Anthony

P.S.  I also had to read the Catakig User Guide just to figure out how 
to turn the Apple II on.  Not very intuitive. :(


On 8/19/20, 1:08 AM, Bernard Bel wrote:
> This is very encouraging!
>
> Next week I will post a tutorial on http://bolprocessor.org to explain
> how to install an emulator and start running BP1. Make it easier to find
> the Apple IIe ROM and "create" the machine, then how to insert diskettes
> in the proper "drive".
>
> I may suggest running one of the free-of-charge emulators. I tried
> catakig and it worked after figuring out (from their user guide) that
> you need to press the space bar to "switch it on" when snow appears on
> the screen. ;-)
>
> True, usage of the "control" key wasn't evident as it was the one
> located near the space bar…
>
> This latest version of BP1 was also making sounds in the Apple II
> speaker. This was fun but useless for research! With virtualii we can
> make sounds. I am not sure catakig will do it.
>
> I have not yet found the way of producing items! Jim Kippen probably
> will remember. Then we'll write a new tutorial. There was one in the
> past but it got lost, some AppleWriter file…
>
> I also plan return to Marseille and transfer more data disks. All these
> 40-year old floppy disks were read without difficulty! :-)
>
> Bernard

Re: [bp-dev] New BP3 console snapshot

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

Dear Anthony.

I did a quick check and everything worked.

It compiled. Then, after modifying the interface, I forced the console 
to read the settings file and get the note convention. It also worked.

I still need to check other options.

It is now clear that instructions such as

-or.Nadaka
-se.hamsad

on top of the grammar are ignored by the console and must be read by the 
interface to add the options to the command line. This is logocal 
because the console cannot guess the full path.

Compilations also worked and used note conventions found in the settings.

This was a minimum test but I am uplaoding the revised PHP files.

Bernard

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] New BP3 console snapshot

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

Great.  Thanks, Rainer! :)

Anthony


On 8/18/20, 1:48 PM, Rainer Schuetz wrote:
>> 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.

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

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

This is very encouraging!

Next week I will post a tutorial on http://bolprocessor.org to explain 
how to install an emulator and start running BP1. Make it easier to find 
the Apple IIe ROM and "create" the machine, then how to insert diskettes 
in the proper "drive".

I may suggest running one of the free-of-charge emulators. I tried 
catakig and it worked after figuring out (from their user guide) that 
you need to press the space bar to "switch it on" when snow appears on 
the screen. ;-)

True, usage of the "control" key wasn't evident as it was the one 
located near the space bar…

This latest version of BP1 was also making sounds in the Apple II 
speaker. This was fun but useless for research! With virtualii we can 
make sounds. I am not sure catakig will do it.

I have not yet found the way of producing items! Jim Kippen probably 
will remember. Then we'll write a new tutorial. There was one in the 
past but it got lost, some AppleWriter file…

I also plan return to Marseille and transfer more data disks. All these 
40-year old floppy disks were read without difficulty! :-)

Bernard

Anthony Kozar wrote on 19/08/2020 00:34:
> DEAR BERNARD,
>
> THIS IS INCREDIBLY COOL!!!  I'M RUNNING BP1 RIGHT NOW ON A VIRTUAL 
> APPLE IIE.  (Oops! I don't have to use all caps on my Mac ;-)
>
> I was able to load "Grammar Q.6.6 version 36" too after some trial and 
> error with the emulator program.  Then I got stuck in the grammar 
> editor for awhile before I figured out that the menu commands in the 
> editor require the Control key.  I really don't know what I'm doing 
> but it is fascinating! :)
>
> I found some of the Apple II emulators and tools that I used to use 20 
> years ago when I had a long bout of nostalgia for everything from my 
> childhood.  The following are on Sourceforge and GitHub, so free and 
> open source.
>
> Catakig  (II,II+,IIe,IIc)  http://catakig.sourceforge.net/
> KEGS     (IIgs only)       http://kegs.sourceforge.net/
> Jace     (IIe in Java)     https://github.com/badvision/jace
>
> AppleCommander (disk image utility)  https://applecommander.github.io/
>
> I don't think Catakig or KEGS have been updated in a long while and 
> they may not be the best emulators out there.  (I think "Bernie II the 
> Rescue" was my favorite IIgs emulator).  But Catakig is working OK for 
> me so far.  (BP1 couldn't read the data files when I had the same disk 
> in both drives, but ejecting the disk in drive 2 fixed that.  Probably 
> an issue with Catakig...)
>
> I set the emulator to x6 speed because I was feeling impatient. :)
>
> I'm looking forward to playing with BP1 some more and learning how to 
> use it!
>
> THANKS SO MUCH for making the journey to copy disks and for posting 
> the disk images!!
>
> Anthony
>
>
> On 8/18/20, 2:31 PM, Bernard Bel wrote:
>> 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
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

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

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

DEAR BERNARD,

THIS IS INCREDIBLY COOL!!!  I'M RUNNING BP1 RIGHT NOW ON A VIRTUAL APPLE 
IIE.  (Oops! I don't have to use all caps on my Mac ;-)

I was able to load "Grammar Q.6.6 version 36" too after some trial and 
error with the emulator program.  Then I got stuck in the grammar editor 
for awhile before I figured out that the menu commands in the editor 
require the Control key.  I really don't know what I'm doing but it is 
fascinating! :)

I found some of the Apple II emulators and tools that I used to use 20 
years ago when I had a long bout of nostalgia for everything from my 
childhood.  The following are on Sourceforge and GitHub, so free and 
open source.

Catakig  (II,II+,IIe,IIc)  http://catakig.sourceforge.net/
KEGS     (IIgs only)       http://kegs.sourceforge.net/
Jace     (IIe in Java)     https://github.com/badvision/jace

AppleCommander (disk image utility)  https://applecommander.github.io/

I don't think Catakig or KEGS have been updated in a long while and they 
may not be the best emulators out there.  (I think "Bernie II the 
Rescue" was my favorite IIgs emulator).  But Catakig is working OK for 
me so far.  (BP1 couldn't read the data files when I had the same disk 
in both drives, but ejecting the disk in drive 2 fixed that.  Probably 
an issue with Catakig...)

I set the emulator to x6 speed because I was feeling impatient. :)

I'm looking forward to playing with BP1 some more and learning how to 
use it!

THANKS SO MUCH for making the journey to copy disks and for posting the 
disk images!!

Anthony


On 8/18/20, 2:31 PM, Bernard Bel wrote:
> 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

[bp-dev] Real-time MIDI

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

Looking for scheduler algorithms I saw the name of Rick Taube and 
remembered having use his scheduler for the old version of BP2… So I 
sent him a message asking what he would recommend next. He replied the 
following:

“I’ve been using the JUCE framework since about 2007 and I would 
recommend that to you. It is cross platform and provides very high 
quality audio, midi, osc, and graphics support. Its pretty much the 
industry standard now for plugins etc and you can also build console 
apps with it.”

https://juce.com/

Let's see! :-)
I am not sure it would fit inside/over the BP environment.

Bernard

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

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...>]

> On 18. Aug 2020, at 20:31, Bernard Bel <ber...@gm...> wrote:
> 
> The illusion is complete because the temperature in the South of France is the same as in India 40 years ago. :-/

This soo cool! Just need some virtual sand!
Love .r.