bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] A "Help" feature on the PHP interface

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

I guess you will need the text version of the Help file, which is 
identical to "BP2 help" that was used by BP2.9.8, except that it has 
been converted to UTF-8. I also renamed it "BP2_help.txt" for this 
purpose. The updated version is enclosed, and it should be placed close 
to the application.

Each time a page is loaded on the PHP interface, this text file is read 
and converted to "BP2_help.html" which is used by the interface and 
located in the "php" folder.

Bernard

Anthony Kozar wrote on 17/07/2020 02:30:
> That looks great, Bernard! :)
>
> I have been thinking about the possibility of adding a command to BP 
> console for searching the help entries.  One question would be where 
> should the help file be installed so that it can be found by the program?
>
> Anthony
>
> On 7/16/20, 12:45 PM, Bernard Bel wrote:
>> Hello,
>>
>> Today I worked on the integration of “Help” in the PHP interface. It
>> worked beautifully!
>>
>> When editing a grammar, alphabet, data etc. (anything that contains
>> reserved words), the machine first creates a help file in HTML based on
>> the text file that was used by BP2.9.8. (I only converted it to UTF8.)
>>
>> Then you click a button and the grammar, alphabet etc. is displayed
>> along with links covering (almost) every reserved word having an entry
>> in the Help.
>>
>> (See attached picture)
>>
>> If you click one of these links, a window will pop up with the Help file
>> positioned exactly on that entry. For instance I had clicked “IN Repeat
>> 'v' times” and the explanation is displayed.
>>
>> Designer's note: the window will pop up even if the browser has been set
>> to reject pop-ups. A different process is used. ;-)
>>
>> The nice thing about this Help is that we can modify entries just
>> editing the same text file we had on BP2.9.8.
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Survey: what features of BP2 do you use?

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

Hello Bol Processor users!


If you are unaware of what has been transpiring, I'd like to let you 
know that work on the next, cross-platform versions of Bol Processor has 
resumed with a flurry of activity in the past two weeks.  I have made 
some progress improving the command line version of "BP console" that I 
posted about last summer.  With the help of Bernard and "super test 
user" Rainer Schütz, we have discovered that BP console builds and works 
on current versions of MacOS, Windows, and Linux with both 32-bit and 
64-bit Intel processors.  Rainer even got it working on an ARM-based 
Raspberry Pi! :)

Bernard has made great progress on implementing a friendlier user 
interface by creating a web browser front-end for BP console.  This 
requires a web server on which to run but will allow anyone with a web 
browser to try out BP without installing anything.  Ideally, once it is 
ready we will try to make a public BP server available online.  But 
there may be opportunities to try out this new user interface sooner.

As we make plans and move forward with development, it would be very 
helpful if we could get feedback from our users.  The following survey 
was posted to the BP discussion forum on Sourceforge.  If you could take 
a few minutes to answer these questions, I'd appreciate it.

-----

I am interested in knowing which parts of BP2 are important to our users 
to retain in future versions and which parts we could forgo 
reimplementing (at least for awhile). Also, knowing whether BP2 users 
are willing to work with a command-line-only version or a very simple 
GUI that launches the command-line version would be helpful.

So, what features of BP2 do you use? Which are critical?

Grammars?
Alphabets?
Data files (BP scores)?
Glossaries?
Sound-objects?
Time-bases?
Interactions?
Scripts?
Keyboards ("type tokens")?
"Type from Midi"?

Midi file output?
Midi file import?
Real-time Midi playback?
Real-time Midi input & control?
Csound score output?
Graphical score/piano roll output?

Step-by-step production?
Choosing candidate rules?
Other interactive/improvisation features?

A complete, "all-in-one app" replacement for BP2 is pretty unlikely any 
time soon. So, would you be comfortable with:

1) Using a command-line-only version?
2) Installing a command-line version that can be controlled from a 
simple GUI where you select BP2 files and choose an operation to perform?
3) Using an external text editor for editing text-based BP2 files?
4) Specifying options, Midi orchestras, Csound instruments, and possibly 
sound-object prototypes using a text format instead of a GUI?
5) Using separate (GUI) "mini apps" for editing Csound instruments or 
sound-object prototypes if such apps could be provided?
6) Using a web browser-based interface to a BP server?

-----

Thanks, everyone, for your continued interest in Bol Processor!

Anthony Kozar

Re: [bp-dev] We need a "compile" command (PS)

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

A "compile" command is on the to do list.  It might be fairly easy to 
implement since "produce items" ends up calling the compiler and we know 
that it works ;-)  (Although compiler error output has the same \r 
problem as trace outputs).  I probably just need to find the right 
function in the code to call.

I'm going to disagree though about writing the compiled grammar back out 
to the same file.  In my "vision" for BP console, I think it should 
behave more like a server application.  It should receive requests from 
"clients" with input files and options specified and then return output 
on the console or as new output files.  The idea would be that any 
request should be exactly repeatable.  If input files are modified, that 
would not be true.  In my opinion, it should be up to the client 
environment to make decisions about modifying the input files.

I understand that BP2 worked differently, automatically inserting 
changes to "open files".  That made sense in the GUI environment 
especially since the user could decide whether to keep the changes or 
not by saving or not saving the open file.  I just think that as we move 
towards BP becoming a tool used by various clients or user interfaces 
that the approach I outlined above will be more flexible.

In general, I have thought a lot about which parts of BP2 should become 
"client" functions and which should become "library" or "server" 
functions.  I think the client portion should be larger than just 
providing a GUI interface.  Of course, I don't have all of the details 
hammered out and there is plenty of room for discussion. :)

Anthony


On 7/15/20, 9:55 AM, Bernard Bel wrote:
> PS Should this command mention the alphabet file, if any? It is used for
> compilation. I believe that it is not necessary because the application
> is able to pick up, load and compile the alphabet when asked to produce
> items. This means that the compiler does take care of file names at the
> top of the grammar…
>
> ----
>
> Dear Anthony,
>
> Till now we have tried the console-driven BP using ready-made grammars.
> Indeed the machine recompiles the grammar before running it, but we no
> longer see the result in a "grammar" window.
>
> We need a command such as for instance:
>
>      ./bp somepath/-gr.NotReich --compile
>
> This would pick up the “-gr.NotReich” grammar, compile it and save the
> result in the same file as the source. It would send compilation
> messages and compilation errors to stdout (unless some option instructs
> otherwise).
>
 > [...]
>
> This is the process currently implemented in BP2.9.8: adding rule
> numbers and inserting the “_mm(60.0000) _striated” instruction picked up
> from timebase settings.
>
> Compilation errors should go to "stdout" which could be retrieved and
> displayed on the PHP interface.
>
> The interface would also take care of reloading the (updated) grammar
> "some time" after it has been compiled.
>
> In other words, this operation would be identical to that on BP2.9.8.
>
> I understand that you'll need to redirect display commands to the
> grammar window to writing a temp file, and thereafter copy this temp
> file over the source grammar file if computation has been successful.
> There is no emergency but this may be put on the agenda!
>
> Bernard

Re: [bp-dev] A "Help" feature on the PHP interface

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

That looks great, Bernard! :)

I have been thinking about the possibility of adding a command to BP 
console for searching the help entries.  One question would be where 
should the help file be installed so that it can be found by the program?

Anthony

On 7/16/20, 12:45 PM, Bernard Bel wrote:
> Hello,
>
> Today I worked on the integration of “Help” in the PHP interface. It
> worked beautifully!
>
> When editing a grammar, alphabet, data etc. (anything that contains
> reserved words), the machine first creates a help file in HTML based on
> the text file that was used by BP2.9.8. (I only converted it to UTF8.)
>
> Then you click a button and the grammar, alphabet etc. is displayed
> along with links covering (almost) every reserved word having an entry
> in the Help.
>
> (See attached picture)
>
> If you click one of these links, a window will pop up with the Help file
> positioned exactly on that entry. For instance I had clicked “IN Repeat
> 'v' times” and the explanation is displayed.
>
> Designer's note: the window will pop up even if the browser has been set
> to reject pop-ups. A different process is used. ;-)
>
> The nice thing about this Help is that we can modify entries just
> editing the same text file we had on BP2.9.8.
>
> Bernard

Re: [bp-dev] New commit [2447a9] by Anthony Kozar

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

Bernard,  I hope you don't mind that I moved this discussion to the dev 
list.

An option to write trace outputs to a file is a good idea.  I prefer the 
option of being able to specify the trace file name too.  Because there 
are at least 9-10 processes that write output to the Trace window in BP2 
and several of them may be enabled at once, I'm thinking maybe we should 
have separate options for specifying the trace file and enabling each 
trace process.  Something like

     --traceout filename

     --show-production
     --trace-production
     --step-production
     --step-subgrammars
     --choose-rules
     --show-time-setting
     --step-time-setting
     --trace-time-setting
     --trace-csound

Once we have a more complete idea of how many command line options there 
will be, we can choose "short option" variants for the most commonly 
used options.

I noticed that compilation errors also go to the Trace window.  Should 
they or any of the other above outputs be directed to separate destinations?

While I added some code last night for the first 5 of the above trace 
processes, there are two main issues to deal with to make them useful. 
First, it appears that all lines are terminated by '\r' in the strings 
these processes output.  As you probably know, on a Unix-like console a 
carriage return by itself repositions the next output to the beginning 
of the current line so that whatever is on that line gets overwritten. 
The second issue is that the "step" and "choose rules" processes need 
input from the user.  I believe that all features requiring user input 
while BP is running should eventually be handled by a client application 
that uses the (not yet existent) BP API.  In the mean time, I could 
probably rewrite the code for BP console to handle some of the simpler 
such input situations.

Anthony


On 7/16/20, 4:58 AM, Bernard Bel wrote:
> I suggest to write "trace" outputs to a "trace.txt" file near the
> grammar or data file that produced it.
> The PHP interface will look for "trace.txt" and display it on a pop-up
> window.
>
> However it would be better to have options like:
>
>      --trace-production somepath/sometracefile
>
>      --show-production somepath/someproductionfile
>
> so that a different trace file will be produced by calls relating to
> different projects.
>
> Bol Processor Git repository wrote on 16/07/2020 10:19:
>>
>>
>>     Branch: ANSI-branch
>>
>> New options --seed [num], --show-production, and --trace-production.
>>
>> FIXME: Because of carriage returns, some of the output from
>> --show-production and --trace-production is overwritten on the console.
>>
>> By Anthony Kozar on 07/16/2020 08:18
>> *View Changes*
>> <https://sourceforge.net/p/bolprocessor/git/ci/2447a9f1f69cc2291e782226745438cdad065323/>
>>
>> ------------------------------------------------------------------------
>>
>> Sent from sourceforge.net because you indicated interest in
>> https://sourceforge.net/p/bolprocessor/git/
>>
>> To unsubscribe from further messages, please visit
>> https://sourceforge.net/auth/subscriptions/
>>
>

[bp-dev] A "Help" feature on the PHP interface

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

Hello,

Today I worked on the integration of “Help” in the PHP interface. It 
worked beautifully!

When editing a grammar, alphabet, data etc. (anything that contains 
reserved words), the machine first creates a help file in HTML based on 
the text file that was used by BP2.9.8. (I only converted it to UTF8.)

Then you click a button and the grammar, alphabet etc. is displayed 
along with links covering (almost) every reserved word having an entry 
in the Help.

(See attached picture)

If you click one of these links, a window will pop up with the Help file 
positioned exactly on that entry. For instance I had clicked “IN Repeat 
'v' times” and the explanation is displayed.

Designer's note: the window will pop up even if the browser has been set 
to reject pop-ups. A different process is used. ;-)

The nice thing about this Help is that we can modify entries just 
editing the same text file we had on BP2.9.8.

Bernard

Re: [bp-dev] A simple PHP environment to start with BP3

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

Dear Rainer,

Now I remember very well sharing ideas with you and julian during the 
Gamelan seminar in Gratz. This was in 2006. I am enclosing the small 
chapter I had taken part in following the seminar. Julian had a talk on 
"Algorithms in Anthropology" (abstract enclosed) and you both presented 
the Virtual Gamelan project… I was fascinated by the SuperCollider and I 
see that it is in full swing. Now that we are contemplating a 
cross-platform version of BP, we should come back to the suggestion of 
interfacing systems via the OSC driver. Plus real-time Csound?

In 2006 the priority was on porting to MacOS X. Definitely, our 
interactions in Gratz and a few months later in Edinburgh School of 
Informatics and London Goldsmith College revived my interest in this 
migration. I am very impressed that you come back "in the scene" just at 
the moment the "animal" is planning to change its "skin" again. Maybe it 
will get large wings this time?

I seriously consider writing material for a book, following the thread 
of BP story. I enjoy the way you are looking at it! This all happened in 
parallel with another story in which I had designed hardware for the 
study of microtonal intonation and melodic movements in raga music. Also 
in 1980 (watch this video https://tinyurl.com/27eps78) but that story 
came to its end the day free software such as Paul Bosma's PRAAT could 
replace the electronic junk I had assembled.

I would be delighted to communicate again with Julian and seek his 
advice on publications I need to read to fill the gap and rethink about 
possible technical and theoretical connections. At present we are in a 
situation that would welcome open-minded programmers to join the project 
and investigate directions requiring more time and competence.

Regarding virtual machines, I figured out today (during my ritual forest 
walk) that the new application will make it easy to run several copies 
simultaneously on the same computer. Once MIDI in/out work again we can 
set up virtual musicians improvising together and exchanging 
synchronisation signals, tempo instructions etc. via MIDI messages. I 
had never done it practically with the current BP2.9.8 because it 
required several computers and a network of MIDI wires. But I am 
convinced it will make an impressive demo. Maybe try to involve again 
Harm Visser and his physical-model synthetic instruments.

It's time to take rest as to-morrow I should try to fix my tenants' 
Internet connection…

Warm regards

Bernard

Rainer Schütz wrote on 15/07/2020 12:02:
> I always thought it would be a nice idea to write a book about IT and 
> human's encounter with it, by starting from a 21st century boy, a 
> proficient Minecraft player, who accidentally gets caught in a black 
> vim screen with just a blinking cursor left - and panics ;-). One of 
> the nice things about Emacs and Vim is that they are tools maintained 
> so well that they work perfectly in the most modern environments, and 
> thus provide a peephole into how diverse original imaginations were 
> about interacting with these new beasts that had been beamed in from 
> outer space, and what they might be good for. The one thing I could 
> see, which would provide incomparably richer material - as it reaches 
> out into the areas of arts and interculturality - is BP. So it’s about 
> humans interacting with new machines, about humans imagining music, 
> and humans communicating across cultural borders at the same time. I 
> can’t imagine anything richer!  And the thing that would beat a book, 
> would we a role playing game (no, a RPG, man!) with Bernard, Jim, the 
> beach of Goa, sand in toes and floppies, cockroaches in power 
> adaptors, and the Raja of Bopal, as some of the main actors. Imagine 
> adventures where you’d have to overcome both modern parsers struggling 
> with file-names starting with minus and codepages (HMMM?, what the 
> hell is that), as well as the problem of finding a shaver and a tie 
> while struggling to wake up on the beach of Goa, hoping to impress the 
> Raja of Bopal for another round of funding  ;-) Compare that to 
> current “digital education discourse” where politicians think it’s a 
> good idea to hand out Android tablets to every student in the country...
>
> IRL (https://www.urbandictionary.com/define.php?term=IRL) a more 
> realistic alternative would be a nice event bringing together the 
> people who keep BP alive with people who appreciate that story. And 
> that 40-years anniversary sounds like a fantastic opportunity. It’s a 
> bit quick, I think, and - alas - Covid-times are the worst thing to 
> coincide with such a plan. I mean, it might lend itself well to a 
> “virtual” meeting, but remembering Bernards charms in Graz I would 
> consider this a serious loss!!!
>
> But I really need to say that while I am maybe among not so many 
> others, that can appreciate and imagine the significance of such an 
> event, I am in no position at all myself to enable something like 
> this. I am totally outside of academia these days and leading a 
> precarious kind of existence that doesn’t allow me to act practically 
> on such ideas (I am not saying that to lament, just to avoid raising 
> unjustified hopes, or creating the wrong impression). Also my link to 
> Julian would have to be revitalised first, but I trust he would like 
> this, as he almost got watery eyes back then, when he heard BP would 
> be featured in Graz ;-). I mainly brought him into play because he is 
> - next to Anthony - one of the very few people I have come into touch 
> with that both deeply and knowledgeably appreciate this kind of stuff…
>
> I find all three lanes of handling this topic *very* interesting: a) 
> restoring the old systems with actual original hardware (cheating a 
> bit with crosscompilers, maxed out memory and fast hard-drives is 
> legit, I think, at least to get it starting), b) porting it to work in 
> as many as possible modern systems - and last but not least - c) using 
> virtual machines to experience this side by side. People think of 
> virtual machines as something that allows you to run Windows 
> applications on a Mac, or as something allowing to balance the load of 
> big server farms, but they also have the potential of becoming the 
> replacement of history books, once much of our cultural artefacts 
> actually exist in digital form. And compared to history books they 
> will be able to provide much more of the past. Microsoft's move to 
> provide “Linux in folder” is an interesting move to open up to this 
> trend, I find. Unfortunately Apple seems to be going in the rather 
> opposite direction these days, getting more and more exclusive rather 
> than inclusive, something that won’t pay out on the long term, I think….
>
> Well, I think I’ll ask Julian what he thinks soon, but maybe you two 
> (or somebody listening?) have more/other ideas in which form this 
> anniversary could take concrete shape?
>
> Best
> .r.
>
>> On 15. Jul 2020, at 04:39, Anthony Kozar 
>> <mai...@an... 
>> <mailto:mai...@an...>> wrote:
>>
>> Not a stupid impression at all, Rainer! I was (mostly jokingly) 
>> suggesting that it would be fun and cool if BP3 could be made to run 
>> on some member of the Apple II family. ^_^
>>
>> I suggested the IIgs because its memory can be extended up to at 
>> least 8 MB.  An 800k binary would not even fit in the memory of the 
>> other Apple IIs. It also has a 16-bit microprocessor running at 2.7 
>> Mhz (IIRC). And I know that there were C compilers available for it.
>>
>> I would expect those ancient compilers to be totally incapable of 
>> compiling BP3 though.  So, unless some hobbyists have created a GCC 
>> cross-compiler for the IIgs, my idea is probably just a crazy dream.
>>
>> I actually still own my family's Apple IIgs!  I have an assembler for 
>> it too but not a C compiler.  So, if anyone were to attempt this 
>> crazed idea, it should probably be me.  However, my machine only has 
>> 512k memory.  But there is no need to actually own the hardware.  
>> There are software emulators for the whole Apple II family that work 
>> very well and run on all modern computers. An emulated Apple IIgs 
>> could be maxed out with memory, four disk drives, and even a 32 MB 
>> hard drive! (I think that was the limit supported by ProDOS 16).
>>
>> By the way, the Apple IIgs hardware had an emulation mode under which 
>> it behaved almost identically to an Apple IIe and it supported both 
>> 5-1/4" and 3-1/2" floppies, so DOS 3.3 is no problem for it.
>>
>> Bernard, have you ever transferred the BP1 program files to a Mac? I 
>> think it would be cool for the 40th anniversary to make a screenshot 
>> showing all three (or four) generations of Bol Processor running on 
>> the same computer simultaneously. BP1 and BP2 on Mac OS Classic could 
>> be run in emulators while the Carbon and console versions run 
>> natively on Mac OS X!  ^_^
>>
>> If not, I could transfer BP1 from my IIgs to my beige PowerMac G3 
>> assuming that I could get a copy of the original floppy disk. ;-)
>>
>> Anthony
>>
>> On Jul 14, 2020 1:20 PM, Rainer Schütz <rs...@ba... 
>> <mailto:rs...@ba...>> wrote:
>>
>>
>>
>> > On 14. Jul 2020, at 18:32, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>> >
>> > Yes, but Apple IIgs runs the Prodos system, not the initial DOS 3.3 
>> on which Bol Processor had been compiled.
>> >
>> > Bernard
>>
>>
>> Good to know, thanks! I was under the (likely stupid) impression that 
>> Anthony thought it might be fun to try and backport BP3 to the Apple 
>> IIgs - so to say to overstretch the cross-platform idea symbolically, 
>> and try to span almost all of BPs history with version 3... ;)
>> .r.
>>

[bp-dev] We need a "compile" command (PS)

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

PS Should this command mention the alphabet file, if any? It is used for 
compilation. I believe that it is not necessary because the application 
is able to pick up, load and compile the alphabet when asked to produce 
items. This means that the compiler does take care of file names at the 
top of the grammar…

----

Dear Anthony,

Till now we have tried the console-driven BP using ready-made grammars. 
Indeed the machine recompiles the grammar before running it, but we no 
longer see the result in a "grammar" window.

We need a command such as for instance:

    ./bp somepath/-gr.NotReich --compile

This would pick up the “-gr.NotReich” grammar, compile it and save the 
result in the same file as the source. It would send compilation 
messages and compilation errors to stdout (unless some option instructs 
otherwise).

Before the compilation the grammar would be for instance:

===============
// Bol Processor on-line test via PHP
// Grammar file saved as ‘-gr.NotReich’. Date: 2020-07-13

-or.NotReich
-se.NotReich

RND
S --> _chan(1) _vel(110) _volumecont _volume(90) A' B' C'
--------
RND
A' --> A A A A A A A A
B' --> B B B" B" C C D D D D E E E E
===============


and after the compilation:

===============
// Bol Processor on-line test via PHP
// Grammar file saved as ‘-gr.NotReich’. Date: 2020-07-13

-or.NotReich
-se.NotReich

RND
_mm(60.0000) _striated
gram#1[1] S --> _chan(1) _vel(110) _volumecont _volume(90) A' B' C'
--------

RND
gram#2[1] A' --> A A A A A A A A
gram#2[2] B' --> B B B" B" C C D D D D E E E E
===============

This is the process currently implemented in BP2.9.8: adding rule 
numbers and inserting the “_mm(60.0000) _striated” instruction picked up 
from timebase settings.

Compilation errors should go to "stdout" which could be retrieved and 
displayed on the PHP interface.

The interface would also take care of reloading the (updated) grammar 
"some time" after it has been compiled.

In other words, this operation would be identical to that on BP2.9.8.

I understand that you'll need to redirect display commands to the 
grammar window to writing a temp file, and thereafter copy this temp 
file over the source grammar file if computation has been successful. 
There is no emergency but this may be put on the agenda!

Bernard

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

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

Good link!

We would also need the proper power supply plus a USB controller:
http://shop.deviceside.com/prod/FC5025

Maybe the USB controller does power the disk drive…

Bernard

Rainer Schütz wrote on 15/07/2020 13:08:
>> Can we solve the 5 1/4 floppy drive problem?
>
> Something like this might be cheaper and safer than shipping a disk:
>
> https://www.ebay.de/itm/APPLE-II-DISK-II-Floppy-Drive-525-Model-A2M0003-Tested-Working-01/264754815254?hash=item3da49de116:g:3DsAAOSwNQNe2sdg
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

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

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

And sorry for bombarding the list: But Bernard, you TOTALLY need to write that book! Somebody has to put you in chains to do it, if necessary!
.r.

> On 15. Jul 2020, at 13:08, Rainer Schütz <*@igong.co> wrote:
> 
>> Can we solve the 5 1/4 floppy drive problem?
> 
> Something like this might be cheaper and safer than shipping a disk:
> 
> https://www.ebay.de/itm/APPLE-II-DISK-II-Floppy-Drive-525-Model-A2M0003-Tested-Working-01/264754815254?hash=item3da49de116:g:3DsAAOSwNQNe2sdg <https://www.ebay.de/itm/APPLE-II-DISK-II-Floppy-Drive-525-Model-A2M0003-Tested-Working-01/264754815254?hash=item3da49de116:g:3DsAAOSwNQNe2sdg>
> 

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

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

> Can we solve the 5 1/4 floppy drive problem?

Something like this might be cheaper and safer than shipping a disk:

https://www.ebay.de/itm/APPLE-II-DISK-II-Floppy-Drive-525-Model-A2M0003-Tested-Working-01/264754815254?hash=item3da49de116:g:3DsAAOSwNQNe2sdg <https://www.ebay.de/itm/APPLE-II-DISK-II-Floppy-Drive-525-Model-A2M0003-Tested-Working-01/264754815254?hash=item3da49de116:g:3DsAAOSwNQNe2sdg>

Re: [bp-dev] A simple PHP environment to start with BP3

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

I always thought it would be a nice idea to write a book about IT and human's encounter with it, by starting from a 21st century boy, a proficient Minecraft player, who accidentally gets caught in a black vim screen with just a blinking cursor left - and panics ;-). One of the nice things about Emacs and Vim is that they are tools maintained so well that they work perfectly in the most modern environments, and thus provide a peephole into how diverse original imaginations were about interacting with these new beasts that had been beamed in from outer space, and what they might be good for. The one thing I could see, which would provide incomparably richer material - as it reaches out into the areas of arts and interculturality - is BP. So it’s about humans interacting with new machines, about humans imagining music, and humans communicating across cultural borders at the same time. I can’t imagine anything richer!  And the thing that would beat a book, would we a role playing game (no, a RPG, man!) with Bernard, Jim, the beach of Goa, sand in toes and floppies, cockroaches in power adaptors, and the Raja of Bopal, as some of the main actors. Imagine adventures where you’d have to overcome both modern parsers struggling with file-names starting with minus and codepages (HMMM?, what the hell is that), as well as the problem of finding a shaver and a tie while struggling to wake up on the beach of Goa, hoping to impress the Raja of Bopal for another round of funding  ;-) Compare that to current “digital education discourse” where politicians think it’s a good idea to hand out Android tablets to every student in the country...

IRL (https://www.urbandictionary.com/define.php?term=IRL <https://www.urbandictionary.com/define.php?term=IRL>) a more realistic alternative would be a nice event bringing together the people who keep BP alive with people who appreciate that story. And that 40-years anniversary sounds like a fantastic opportunity. It’s a bit quick, I think, and - alas - Covid-times are the worst thing to coincide with such a plan. I mean, it might lend itself well to a “virtual” meeting, but remembering Bernards charms in Graz I would consider this a serious loss!!!

But I really need to say that while I am maybe among not so many others, that can appreciate and imagine the significance of such an event, I am in no position at all myself to enable something like this. I am totally outside of academia these days and leading a precarious kind of existence that doesn’t allow me to act practically on such ideas (I am not saying that to lament, just to avoid raising unjustified hopes, or creating the wrong impression). Also my link to Julian would have to be revitalised first, but I trust he would like this, as he almost got watery eyes back then, when he heard BP would be featured in Graz ;-). I mainly brought him into play because he is - next to Anthony - one of the very few people I have come into touch with that both deeply and knowledgeably appreciate this kind of stuff…

I find all three lanes of handling this topic *very* interesting: a) restoring the old systems with actual original hardware (cheating a bit with crosscompilers, maxed out memory and fast hard-drives is legit, I think, at least to get it starting), b) porting it to work in as many as possible modern systems - and last but not least - c) using virtual machines to experience this side by side. People think of virtual machines as something that allows you to run Windows applications on a Mac, or as something allowing to balance the load of big server farms, but they also have the potential of becoming the replacement of history books, once much of our cultural artefacts actually exist in digital form. And compared to history books they will be able to provide much more of the past. Microsoft's move to provide “Linux in folder” is an interesting move to open up to this trend, I find. Unfortunately Apple seems to be going in the rather opposite direction these days, getting more and more exclusive rather than inclusive, something that won’t pay out on the long term, I think….

Well, I think I’ll ask Julian what he thinks soon, but maybe you two (or somebody listening?) have more/other ideas in which form this anniversary could take concrete shape?

Best
.r.

> On 15. Jul 2020, at 04:39, Anthony Kozar <mai...@an...> wrote:
> 
> Not a stupid impression at all, Rainer! I was (mostly jokingly) suggesting that it would be fun and cool if BP3 could be made to run on some member of the Apple II family. ^_^
> 
> 
> I suggested the IIgs because its memory can be extended up to at least 8 MB.  An 800k binary would not even fit in the memory of the other Apple IIs. It also has a 16-bit microprocessor running at 2.7 Mhz (IIRC).  And I know that there were C compilers available for it.
> 
> 
> I would expect those ancient compilers to be totally incapable of compiling BP3 though.  So, unless some hobbyists have created a GCC cross-compiler for the IIgs, my idea is probably just a crazy dream.
> 
> 
> I actually still own my family's Apple IIgs!  I have an assembler for it too but not a C compiler.  So, if anyone were to attempt this crazed idea, it should probably be me.  However, my machine only has 512k memory.  But there is no need to actually own the hardware.  There are software emulators for the whole Apple II family that work very well and run on all modern computers. An emulated Apple IIgs could be maxed out with memory, four disk drives, and even a 32 MB hard drive! (I think that was the limit supported by ProDOS 16).
> 
> 
> By the way, the Apple IIgs hardware had an emulation mode under which it behaved almost identically to an Apple IIe and it supported both 5-1/4" and 3-1/2" floppies, so DOS 3.3 is no problem for it. 
> 
> 
> Bernard, have you ever transferred the BP1 program files to a Mac? I think it would be cool for the 40th anniversary to make a screenshot showing all three (or four) generations of Bol Processor running on the same computer simultaneously. BP1 and BP2 on Mac OS Classic could be run in emulators while the Carbon and console versions run natively on Mac OS X!  ^_^
> 
> 
> If not, I could transfer BP1 from my IIgs to my beige PowerMac G3 assuming that I could get a copy of the original floppy disk. ;-)
> 
> 
> Anthony
> 
> 
> On Jul 14, 2020 1:20 PM, Rainer Schütz <rs...@ba...> wrote:
> 
> 
> 
> 
> > On 14. Jul 2020, at 18:32, Bernard Bel <ber...@gm...> wrote:
> 
> >
> 
> > Yes, but Apple IIgs runs the Prodos system, not the initial DOS 3.3 on which Bol Processor had been compiled.
> 
> >
> 
> > Bernard
> 
> 
> 
> Good to know, thanks! I was under the (likely stupid) impression that Anthony thought it might be fun to try and backport BP3 to the Apple IIgs - so to say to overstretch the cross-platform idea symbolically, and try to span almost all of BPs history with version 3... ;)
> 
> .r.
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] File prefix and extension

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

Anthony Kozar wrote on 14/07/2020 13:03:

> Yes, BP console checks for extensions too.  Also, I added the feature to 
> the Mac OS X port to put the names of related files with arbitrary names 
> at the tops of files.  So, for instance, in BP 2.9.8 if you save a 
> settings file with the name "Newfile.bpse", it will insert this line at 
> the top of the grammar:
> 
> -se.:Newfile.bpse
> 
> The colon indicates that the file name does not really start with 
> "-se.".  It's an ugly syntax but it worked and maintained backwards 
> compatibility since the colon is not a legal character in a file name on 
> MacOS.

Now the PHP interface also recognizes “-se.:Newfile.bpse” and 
understands that the settings file shall be called “Newfile.bpse”.

Bernard

[bp-dev] We need a "compile" command

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

Dear Anthony,

Till now we have tried the console-driven BP using ready-made grammars. 
Indeed the machine recompiles the grammar before running it, but we no 
longer see the result in a "grammar" window.

We need a command such as for instance:

   ./bp somepath/-gr.NotReich --compile

This would pick up the “-gr.NotReich” grammar, compile it and save the 
result in the same file as the source. It would send compilation 
messages and compilation errors to stdout (unless some option instructs 
otherwise).

Before the compilation the grammar would be for instance:

===============
// Bol Processor on-line test via PHP
// Grammar file saved as ‘-gr.NotReich’. Date: 2020-07-13

-or.NotReich
-se.NotReich

RND
S --> _chan(1) _vel(110) _volumecont _volume(90) A' B' C'
--------
RND
A' --> A A A A A A A A
B' --> B B B" B" C C D D D D E E E E
===============


and after the compilation:

===============
// Bol Processor on-line test via PHP
// Grammar file saved as ‘-gr.NotReich’. Date: 2020-07-13

-or.NotReich
-se.NotReich

RND
_mm(60.0000) _striated
gram#1[1] S --> _chan(1) _vel(110) _volumecont _volume(90) A' B' C'
--------

RND
gram#2[1] A' --> A A A A A A A A
gram#2[2] B' --> B B B" B" C C D D D D E E E E
===============

This is the process currently implemented in BP2.9.8: adding rule 
numbers and inserting the “_mm(60.0000) _striated” instruction picked up 
from timebase settings.

Compilation errors should go to "stdout" which could be retrieved and 
displayed on the PHP interface.

The interface would also take care of reloading the (updated) grammar 
"some time" after it has been compiled.

In other words, this operation would be identical to that on BP2.9.8.

I understand that you'll need to redirect display commands to the 
grammar window to writing a temp file, and thereafter copy this temp 
file over the source grammar file if computation has been successful. 
There is no emergency but this may be put on the agenda!

Bernard

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

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

Well, a challenging perspective!

I do have 2 copies of BP1 source on 5 1/4 floppy disks. Unfortunately I 
was careless not to transfer them to Mac while using Kermit to migrate 
writings and various data… There was little hope of emulation software 
in those days and the incentive was to "move on". Keeping the floppy 
disks was a mere sentimental support. ;-)

Now we have 2 options:

1) Find a 5 1/4 floppy disk drive with USB port and I do the transfer. 
That is my prefered option though at the moment I only see 3 1/2 inch 
drives.

2) In case you have this drive, I send you one of the two floppy disks 
in a safe package — still risky due to security scanners. Still, I am 
confident that these 143 Kb disks remain readable. This would include a 
data floppy disk which Kippen was using in field work.

I also have 2 floppy disks of the compiled version and one of the Big 
Mac compiler. All these are supposed to run on Apple II 64Kb.

Ten years ago I tried to run BP1 before offering Jim Kippen's Apple IIc 
to a colleague. I was able launch it but did not remember any of the 
commands! It is quite hard to return to a mouseless computer handled via 
its keyboard… Borrowing the Apple IIc (in case he still owns it) would 
not be useful because it did not have an external drive and I don't have 
a copy program that would duplicate floppies on a single drive.

Can we solve the 5 1/4 floppy drive problem?

Bernard

Anthony Kozar wrote on 15/07/2020 04:39:
>
> Not a stupid impression at all, Rainer! I was (mostly jokingly) 
> suggesting that it would be fun and cool if BP3 could be made to run 
> on some member of the Apple II family. ^_^
>
> I suggested the IIgs because its memory can be extended up to at least 
> 8 MB.  An 800k binary would not even fit in the memory of the other 
> Apple IIs. It also has a 16-bit microprocessor running at 2.7 Mhz 
> (IIRC). And I know that there were C compilers available for it.
>
> I would expect those ancient compilers to be totally incapable of 
> compiling BP3 though.  So, unless some hobbyists have created a GCC 
> cross-compiler for the IIgs, my idea is probably just a crazy dream.
>
> I actually still own my family's Apple IIgs!  I have an assembler for 
> it too but not a C compiler.  So, if anyone were to attempt this 
> crazed idea, it should probably be me.  However, my machine only has 
> 512k memory.  But there is no need to actually own the hardware.  
> There are software emulators for the whole Apple II family that work 
> very well and run on all modern computers. An emulated Apple IIgs 
> could be maxed out with memory, four disk drives, and even a 32 MB 
> hard drive! (I think that was the limit supported by ProDOS 16).
>
> By the way, the Apple IIgs hardware had an emulation mode under which 
> it behaved almost identically to an Apple IIe and it supported both 
> 5-1/4" and 3-1/2" floppies, so DOS 3.3 is no problem for it.
>
> Bernard, have you ever transferred the BP1 program files to a Mac? I 
> think it would be cool for the 40th anniversary to make a screenshot 
> showing all three (or four) generations of Bol Processor running on 
> the same computer simultaneously. BP1 and BP2 on Mac OS Classic could 
> be run in emulators while the Carbon and console versions run natively 
> on Mac OS X!  ^_^
>
> If not, I could transfer BP1 from my IIgs to my beige PowerMac G3 
> assuming that I could get a copy of the original floppy disk. ;-)
>
> Anthony
>
> On Jul 14, 2020 1:20 PM, Rainer Schütz <rs...@ba...> wrote:
>
>
>
> > On 14. Jul 2020, at 18:32, Bernard Bel <ber...@gm...> wrote:
> >
> > Yes, but Apple IIgs runs the Prodos system, not the initial DOS 3.3 
> on which Bol Processor had been compiled.
> >
> > Bernard
>
>
> Good to know, thanks! I was under the (likely stupid) impression that 
> Anthony thought it might be fun to try and backport BP3 to the Apple 
> IIgs - so to say to overstretch the cross-platform idea symbolically, 
> and try to span almost all of BPs history with version 3... ;)
> .r.
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] A simple PHP environment to start with BP3

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

<p dir="ltr">Not a stupid impression at all, Rainer! I was (mostly jokingly) suggesting that it would be fun and cool if BP3 could be made to run on some member of the Apple II family. ^_^<br>
&#13;<br>
&#13;I suggested the IIgs because its memory can be extended up to at least 8 MB.&#160; An 800k binary would not even fit in the memory of the other Apple IIs. It also has a 16-bit microprocessor running at 2.7 Mhz (IIRC).&#160; And I know that there were C compilers available for it.<br>
&#13;<br>
&#13;I would expect those ancient compilers to be totally incapable of compiling BP3 though.&#160; So, unless some hobbyists have created a GCC cross-compiler for the IIgs, my idea is probably just a crazy dream.<br>
&#13;<br>
&#13;I actually still own my family's Apple IIgs!&#160; I have an assembler for it too but not a C compiler.&#160; So, if anyone were to attempt this crazed idea, it should probably be me.&#160; However, my machine only has 512k memory.&#160; But there is no need to actually own the hardware.&#160; There are software emulators for the whole Apple II family that work very well and run on all modern computers. An emulated Apple IIgs could be maxed out with memory, four disk drives, and even a 32 MB hard drive! (I think that was the limit supported by ProDOS 16).<br>
&#13;<br>
&#13;By the way, the Apple IIgs hardware had an emulation mode under which it behaved almost identically to an Apple IIe and it supported both 5-1/4" and 3-1/2" floppies, so DOS 3.3 is no problem for it. <br>
&#13;<br>
&#13;Bernard, have you ever transferred the BP1 program files to a Mac? I think it would be cool for the 40th anniversary to make a screenshot showing all three (or four) generations of Bol Processor running on the same computer simultaneously. BP1 and BP2 on Mac OS Classic could be run in emulators while the Carbon and console versions run natively on Mac OS X!&#160; ^_^<br>
&#13;<br>
&#13;If not, I could transfer BP1 from my IIgs to my beige PowerMac G3 assuming that I could get a copy of the original floppy disk. ;-)<br>
&#13;<br>
&#13;Anthony<br>
&#13;<br>
&#13;On Jul 14, 2020 1:20 PM, Rainer Sch&#252;tz &lt;rs...@ba...&gt; wrote:<br>
&#13;<br>
&#13;<br>
&#13;<br>
&#13;&gt; On 14. Jul 2020, at 18:32, Bernard Bel &lt;ber...@gm...&gt; wrote:<br>
&#13;&gt;<br>
&#13;&gt; Yes, but Apple IIgs runs the Prodos system, not the initial DOS 3.3 on which Bol Processor had been compiled.<br>
&#13;&gt;<br>
&#13;&gt; Bernard<br>
&#13;<br>
&#13;<br>
&#13;Good to know, thanks! I was under the (likely stupid) impression that Anthony thought it might be fun to try and backport BP3 to the Apple IIgs - so to say to overstretch the cross-platform idea symbolically, and try to span almost all of BPs history with version 3... ;)<br>
&#13;.r.<br>
&#13;<br>
&#13;</p>

Re: [bp-dev] A simple PHP environment to start with BP3

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

It maybe more a hardware than a software problem. These old machines had 
in/out serial ports that would look exotic today, nothing of the 
flexibility of USB. Perhaps we could find a card adding USB ports to 
Apple IIgs, but adding cards is more or less a manner of reconstructing 
a Mac…

For a long time I was still using the old Apple II for various projects 
while my colleagues were busy with Lisa, early Macs and Sun computers. I 
only switched to Mac when the C compiler became affordable…

Bernard

Rainer Schütz wrote on 14/07/2020 19:20:
>> On 14. Jul 2020, at 18:32, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> Yes, but Apple IIgs runs the Prodos system, not the initial DOS 3.3 
>> on which Bol Processor had been compiled.
>>
>> Bernard
>
> Good to know, thanks! I was under the (likely stupid) impression that 
> Anthony thought it might be fun to try and backport BP3 to the Apple 
> IIgs - so to say to overstretch the cross-platform idea symbolically, 
> and try to span almost all of BPs history with version 3... ;)
> .r.

Re: [bp-dev] A simple PHP environment to start with BP3

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

Probably the reasons why Bol Processor did not become popular in the 
start were (1) it worked on MacOS while "serious people" use Windows, 
and (2) it has an exotic taste: snake charmers and sacred cows. Indian 
scholars who might have been interested only had access to IBM PCs.

The Apple IIc version was welcome in fieldwork with traditional tabla 
players because they couldn't figure out that Jim Kippen was reading 
musical items on the LCD screen: text was almost invisible. One day we 
thought they might appreciate seeing the output on a small TV. But after 
a few minutes they suggested to zap and watch the cricket match!

I would love to take part in a conference/seminar — any event — to 
celebrate 40 years of continuous development of a text-based music 
composition/improvisation program. I had been invited to do the at 
Goldsmith College (London UK) in winter 2006, just before Anthony's 
MacOS 9 to 10 migration. Also in Gratz (Austria) and another one at the 
AI department of Edinbugh University, after which a scholar admitted 
that this representation of musical time "blows up everything we had 
previously said about musical time". I had explained and played a few 
examples by Harm Visser.

We need a "critical mass" to make a tool popular. Rich people would hire 
dozens of programmers and launch an advertizing campaign… But it only 
works if the tool fits with current expectations of professionals, or 
creating expectations via advertizing. But I never dreamed of running a 
company. ;-)

Musicians either watch cricket matches (in India) or they want a program 
that will quickly compose music "in the style of X" which they sell the 
next day. Only a few open-minded composers like Harm Visser or music 
teachers in North American Universities (the French can't read English!) 
take time to explore new concepts regardless of software limitations. 
Yet this does not create a "critical mass". I have faith that a 
cross-platform version will make it happen!

I would be delighted to attend an event in Germany. In January I was in 
Tübingen for a seminar on "sacred sound" dealing with an unrelated 
project I have also been leading since 1993 (https://grindmill.org). 
Germany is one of my favourite places for personal reasons… Düsseldorf 
is an exciting suggestion. I do not know Julian Rohrhuber personally (or 
I don't remember having met him) but his fields of interest seel very 
close to mine/ours. This might be an opportunity for making friends in 
the SuperCollider community and working on a Open Sound Control 
interface in this cross-platform environment.

I have plenty of funny anecdotes about years in India. So many and so 
bizarre that I should write them down before reaching an age at which 
people will tell I am inventing souvenirs! The Bol Processor started one 
evening as I was about to take a train from Old Delhi railway station to 
Lucknow. I wanted to visit Jim Kippen and understand why he needed a 
"find-replace" procedure on the tokenized text processor I had created 
for his work on drumming. For travelling a whole night in a noisy train 
I used to buy books from the station's bookstall — you can imagine how 
it looked in Old Delhi station. Generally it was Agatha Christie, but 
that night they did not have an unread one. Looking more carefully at 
the pile, I found a book titled "Mathematical Linguistics" by Maurice 
Gross (a French scholar). I immediately purchased it (one Rupee) and 
studied it overnight. The next morning I told Jim that I had found the 
theoretical foundation for our future R&D… Later I borrowed "Automata 
Theory" from the American Library but a cow ate the book I was reading 
it on a beach in Goa. ;-)

Regarding gamelan, I should ask Jim KIppen because he and his wife are 
accomplished performers of this musical style. The seminar I had 
attended in Gratz was at the start of a gamelan project but I did not 
see a follow-up of that study which I found quite complicated!

Don't bother about "pressing buttons"! The more I read the more I 
realize I having stayed apart from fascinating projects, theories, 
philosophical systems etc.

Bernard

Rainer Schütz wrote on 14/07/2020 14:12:
> On 14. Jul 2020, at 13:03, Anthony Kozar 
> <mai...@an... 
> <mailto:mai...@an...>> wrote:
>>
>> :)  I like that BP has such a rich history!
>
> Totally!!! Not only on the technical side, but also because for the 
> interculturality of it’s application. Bernards anecdotes of acquiring 
> funding in India out of the mids of wild parties are fab (did my 
> fantasy take of with me? ;-) ). But seriously: this must be a pretty 
> unique project world wide. It should be object of a serious and 
> adequate research project. A really tech savvy anthropologist would be 
> needed. Not easy to find, unfortunately...
>
>>  I realized a couple of days ago when looking at the "Bol Processor - 
>> 39 Years!" video that you made that this year is the 40th anniversary 
>> of BP1!  How wonderful would it be to celebrate this anniversary with 
>> the release of BP3 having cross-platform support?!  ^_^
>
> Totally awesome! And need to find an institution that could host an 
> occasion! It’s almost too late to prepare something adequate!
>
>> (Unfortunately, I doubt it would compile for any Apple II computers 
>> unless there is a recent C compiler for them.  A beefed-up IIgs 
>> *might* have enough memory to run some basic tasks. A challenge for 
>> Rainer ?? ;-)
>
> Hahaha, if only my understanding of these things were deeper. 
> Unfortunately I mainly just press buttons without really knowing what 
> I am doing, unfortunately…
>
>
> Bernard, a friend of mine once wrote a litte php script that took 
> keyboard input of gamelan cipher notation using ‘,. n'stuff and 
> converted it on the fly to a different but structurally similar 
> notation in a mysql database. Nothing that can be directly applied, 
> but maybe a source of inspiration?
>
>
> Best
> .r.

Re: [bp-dev] A simple PHP environment to start with BP3

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

> On 14. Jul 2020, at 18:32, Bernard Bel <ber...@gm...> wrote:
> 
> Yes, but Apple IIgs runs the Prodos system, not the initial DOS 3.3 on which Bol Processor had been compiled.
> 
> Bernard

Good to know, thanks! I was under the (likely stupid) impression that Anthony thought it might be fun to try and backport BP3 to the Apple IIgs - so to say to overstretch the cross-platform idea symbolically, and try to span almost all of BPs history with version 3... ;)
.r.

Re: [bp-dev] A simple PHP environment to start with BP3

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

Anthony Kozar wrote on 14/07/2020 13:03:
> Alternatively, it would probably suffice for now for your PHP 
> interface to convert '•' to '.' and '…' to '_rest' in all input files.
If you can solve the problem of reading/recognizing '•'  in a grammar or 
data file, then the same solution will apply to '…'

Certainly we could convert symbols automatically when loading/saving 
files on the PHP interface, but the conversion will also affect text in 
comments. In addition, I can't remember whether or not floating point 
numbers are allowed in BP data. If this is the case, a conversion will 
mess them up.

Once you've recognized a ‘•’ character you don't need to convert it to 
some other ASCII value. You may just store it as "•" and you may 
store ‘…’ as "…". If they are written as such in output files, 
then the interface can convert them to whatever we wish to display. In 
fact the old BP had an option for displaying bullets or periods — 
depending on the age of the captain! ;-)

>> Do you mean that instead of calling
>>
>>      bp -gr.NotReich
>>
>> we should call:
>>
>>      bp -gr.NotReich -or.NotReich -se.NotReich ?
>
> What I meant is that only data, grammar, alphabet, and glossary files 
> can be loaded by BP console.  The names of all other file types are 
> recognized as command line arguments but those files will not be 
> loaded.  In addition, related files listed at the tops of grammars or 
> other files are currently ignored no matter what file type they are.
This is fine for the moment. If we send a command like

bp -gr.NotReich -or.NotReich -se.NotReich

it looks redundant because we're indicating two times the attached files 
— assuming that there is no contradiction. In reality this is correct 
because the PHP interface analyses the top of the grammar file and picks 
up the names of the two related files. So, it allows the user to edit 
those files, and it will copy these names to create the required 
parameters of the console command.
> The reasons for the current limitations are that the BP2 functions for 
> loading most file types and those for interpreting script commands use 
> Mac OS calls quite a bit and thus require substantial rewrites.  The 
> four mentioned types were easy to write new code to load using only 
> std C routines.  While interaction and script files would also be easy 
> to load this way, there is currently little point in doing so.
Yes, this should be kept for later. The SaveLoads.c files reminded me 
that BP was modifying its environment while reading a settings file. 
These calls need to be left out for the time being. Nonetheless, some 
parameters read in a settings file will need to be taken into account, 
such as for instance Pclock and Qclock (for the metronome setting), time 
resolution and quantization (for simplifying complex structures), 
resetting rule weights, note convention (English/French/Indian), using 
"Db" instead of "C#" etc. There are many parameters that you will see on 
the test interface. Since it would be quite complex to send all these 
parameters as options on the command line, reading the (revised) “-se” 
file remains the best option.
> :)  I like that BP has such a rich history!  I realized a couple of 
> days ago when looking at the "Bol Processor - 39 Years!" video that 
> you made that this year is the 40th anniversary of BP1!  How wonderful 
> would it be to celebrate this anniversary with the release of BP3 
> having cross-platform support?!  ^_^
Well, at the speed we're flying now there is a chance we can show 
something very interesting next year!

Soon I will study carefully how we could produce (cross-platform) 
graphics in the new version. One I get C code to draw a single line it 
won't take long to convert all instructions in "Graphic.c"!

Regarding real-time MIDI I have a naive question. Currently BP2.9.8 on 
my computer sends output to any instrument connected to the IAC driver 
whatever it is. I don't understand why the console version can't do it 
with the same settings. I guess you deactivated real-time MIDI out/in 
but connecting IAC to the new version seems to be quite the same as in 
the old one.

I am probably a bit confused regarding MIDI because it radically changed 
several times over years. I remember that prior to OMS I had to program 
an event stack to send MIDI messages at the time they were expected to 
produce effects. Later it became much more simple but I have forgotten why…
> (Unfortunately, I doubt it would compile for any Apple II computers 
> unless there is a recent C compiler for them.  A beefed-up IIgs 
> *might* have enough memory to run some basic tasks. A challenge for 
> Rainer ?? ;-)
The suggestion with Apple II was to run 6502 code compiled by BIG MAC. 
The floppy disks are still on my desk ;-)

Sometimes I dream
> So, when I get automatic loading of related files working again, they 
> will be able to use prefixes but will not be required to do so.
>
>>> A simpler solution for BP might just be to give messages a priority
>>> level and only output messages whose priority is less than specified
>>> by the user.  E.g.
>>>
>>> "-m 3" -- print all messages
>>> "-m 2" -- only print errors and warnings
>>> "-m 1" -- only print errors
>>> "-m 0" -- suppress all messages
>>>
>>> Other command line programs use "-q" or "--quiet" to suppress normal
>>> output and "-v" or "--verbose" to print extra diagnostic output.
>
>> Excellent idea!
>
> Which idea do you like better?  "-m number" or the combination of "-q" 
> and '-v' ?
Maybe -m numbers.
> OK.  Should we make a distinction between errors caused by bad input 
> data (in the grammar, etc.) and errors caused by bad command line 
> arguments or failed operations ("file could not be opened", etc.) ?
I believe all could go to the same output provided that they are mixed 
with a few messages telleing what the machine is doing, such as 
"Compiling grammar", "Producing item", "Expanding polymetric 
expression", "Quantizing" etc.
> I'll upload a new version once I get a few more things working.  Of 
> course, my current code is available from Git if anyone wants it sooner.
>
That's fine. I will try the new version and share the updated PHP interface.

Bernard

Re: [bp-dev] A simple PHP environment to start with BP3

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

> On 14. Jul 2020, at 14:12, Rainer Schütz <*@igong.co> wrote:
> 
>> :)  I like that BP has such a rich history!
> 


Maybe Julian Rohrhuber could be won to host an event that celebrates BP’s round anniversary! Bernard, do you remember him? He is a professor of musicinformatics and mediatheory at the Music Hischool in Düsseldorf now. He is one of the few people among my friends/in my circles, who can appreciate the uniqueness, depth of richness of flair of BP. There must be other people also, but I am not that widely connected…

Best
.r.

Re: [bp-dev] A simple PHP environment to start with BP3

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

> On 14. Jul 2020, at 13:03, Anthony Kozar <mai...@an...> wrote:
> 
> :)  I like that BP has such a rich history!

Totally!!! Not only on the technical side, but also because for the interculturality of it’s application. Bernards anecdotes of acquiring funding in India out of the mids of wild parties are fab (did my fantasy take of with me? ;-) ). But seriously: this must be a pretty unique project world wide. It should be object of a serious and adequate research project. A really tech savvy anthropologist would be needed. Not easy to find, unfortunately...

>  I realized a couple of days ago when looking at the "Bol Processor - 39 Years!" video that you made that this year is the 40th anniversary of BP1!  How wonderful would it be to celebrate this anniversary with the release of BP3 having cross-platform support?!  ^_^

Totally awesome! And need to find an institution that could host an occasion! It’s almost too late to prepare something adequate!

> (Unfortunately, I doubt it would compile for any Apple II computers unless there is a recent C compiler for them.  A beefed-up IIgs *might* have enough memory to run some basic tasks. A challenge for Rainer ?? ;-)

Hahaha, if only my understanding of these things were deeper. Unfortunately I mainly just press buttons without really knowing what I am doing, unfortunately…


Bernard, a friend of mine once wrote a litte php script that took keyboard input of gamelan cipher notation using ‘,. n'stuff and converted it on the fly to a different but structurally similar notation in a mysql database. Nothing that can be directly applied, but maybe a source of inspiration?


Best
.r.

Re: [bp-dev] A simple PHP environment to start with BP3

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

On 7/13/20, 10:22 AM, Bernard Bel wrote:

> I am still working on the PHP interface: adding possibilities of
> creating new files and the automatic conversion of files to UTF8,
> because there is no alternative to UTF8 in that environment. It should
> be possible to set up the console for UTF8-compliant input/output as
> discussed 10 years ago:
>
> https://stackoverflow.com/questions/2062875/show-utf-8-characters-in-console
>
> Apparently the trick was to use Console.Write() instead of
> Console.Writeline()

Unfortunately, that solution appears to be for C# .NET.  As I mentioned 
in my private reply, I haven't found a working solution yet for plain C.

> If it's too complicated in the beginning we can convert files back to
> MacOS at the time of sending them to the console. Probably a very bad
> idea! ;-)

Alternatively, it would probably suffice for now for your PHP interface 
to convert '•' to '.' and '…' to '_rest' in all input files.

> The high-ascii encoding problem concerns only two signs:
>
> ‘•’ = ascii #149 = •
> ‘…’ = ascii #133 = …
>
> (Source: https://assiste.com/SEO_Webmaster/Tables_ascii_unicode_utf_8.html)
>
> The first one is the period used in “period notation”. It is an
> alternate glyph for a plain period ‘.’ and both work identically in the
> old BP. Therefore it wouldn't be a problem to get periods instead of
> bullets in console or file outputs. I switched to bullets when my
> eyesight started declining. ;-)
>
> I am attaching a copy of “-gr.acceleration” in clean UTF8 format
> containing a bullet on line gram#[2]. You may use it to check that the
> grammar is read and processed correctly with respect to the bullet and
> to end of lines (see below).

OK. Thanks. :)

> The second is an undetermined rest. It also has a low-ascii equivalent:
> “_rest”. Many users are not familiar with typing ‘…’ so they have a
> tendency to type ‘...’ which is equivalent in publications but not in BP
> since it represents 3 periods, that is ‘•••’.
>
> The solution could be the same: let the console display/save expressions
> containing ‘_rest’ but let it accept ‘…’ as an equivalent input. I am
> enclosing “-gr.Ames” which you can use to check the compatibility.

*nod*

>> -se and -or files are not loaded yet by the console version.  In fact,
>> any related files named at the top of another input file are not
>> loaded yet either, even if the file type is supported by BP console.
>> All input files must currently be specified on the command line.

> Do you mean that instead of calling
>
>      bp -gr.NotReich
>
> we should call:
>
>      bp -gr.NotReich -or.NotReich -se.NotReich ?

What I meant is that only data, grammar, alphabet, and glossary files 
can be loaded by BP console.  The names of all other file types are 
recognized as command line arguments but those files will not be loaded. 
  In addition, related files listed at the tops of grammars or other 
files are currently ignored no matter what file type they are.

The reasons for the current limitations are that the BP2 functions for 
loading most file types and those for interpreting script commands use 
Mac OS calls quite a bit and thus require substantial rewrites.  The 
four mentioned types were easy to write new code to load using only std 
C routines.  While interaction and script files would also be easy to 
load this way, there is currently little point in doing so.

> Since the ‘-or’ and ‘-se’ files are listed on top of the grammar, the
> PHP interface picks up their names to make it possible to edit them. So,
> it will be very easy to create the detailed instruction in that environment.

That's very handy!

> The interface also makes sure that these files exist at the same level
> as the grammar. I guess your syntax might permit something like:
>
>      bp -gr.NotReich somepath/-or.NotReich anotherpath/-se.NotReich
>
> if settings and orchestra are stored in different folders. Paths
> ‘somepath’ and ‘anotherpath’ could be absolute or relative.

Yes, that's fine.  File names and path names passed as command line 
arguments are passed to the C library fopen() function exactly as they 
are given.

> At this stage, remember that appending prefixes such as ‘-gr’, ‘-ho’
> etc. dates back to the Apple II version when it facilitated the
> alphabetic sorting of files on a floppy disk!

:)  I like that BP has such a rich history!  I realized a couple of days 
ago when looking at the "Bol Processor - 39 Years!" video that you made 
that this year is the 40th anniversary of BP1!  How wonderful would it 
be to celebrate this anniversary with the release of BP3 having 
cross-platform support?!  ^_^

(Unfortunately, I doubt it would compile for any Apple II computers 
unless there is a recent C compiler for them.  A beefed-up IIgs *might* 
have enough memory to run some basic tasks. A challenge for Rainer ?? ;-)

> Well done, but the habit had been taken to use prefixes and include a
> list of these related files on top of grammars, data, alphabet etc. so
> that the compiler could pick up names and load these files.
>
> Therefore we should not abandon prefixes in related files except for
> grammar files since they are always at the top of the hierarchy. I guess
> that the console version looks for the extension in case there is no prefix.

Yes, BP console checks for extensions too.  Also, I added the feature to 
the Mac OS X port to put the names of related files with arbitrary names 
at the tops of files.  So, for instance, in BP 2.9.8 if you save a 
settings file with the name "Newfile.bpse", it will insert this line at 
the top of the grammar:

-se.:Newfile.bpse

The colon indicates that the file name does not really start with 
"-se.".  It's an ugly syntax but it worked and maintained backwards 
compatibility since the colon is not a legal character in a file name on 
MacOS.

So, when I get automatic loading of related files working again, they 
will be able to use prefixes but will not be required to do so.

>> A simpler solution for BP might just be to give messages a priority
>> level and only output messages whose priority is less than specified
>> by the user.  E.g.
>>
>> "-m 3" -- print all messages
>> "-m 2" -- only print errors and warnings
>> "-m 1" -- only print errors
>> "-m 0" -- suppress all messages
>>
>> Other command line programs use "-q" or "--quiet" to suppress normal
>> output and "-v" or "--verbose" to print extra diagnostic output.

> Excellent idea!

Which idea do you like better?  "-m number" or the combination of "-q" 
and '-v' ?

>> There is also the issue of which messages to send to std out and which
>> to std error.
>>
>> How would all of you prefer that BP console messages work?

> When working in console mode I find it difficult to go and fetch errors
> in errors.log. It might be better to send them to std out since these
> errors make it impossible to produce the expected output.

OK.  Should we make a distinction between errors caused by bad input 
data (in the grammar, etc.) and errors caused by bad command line 
arguments or failed operations ("file could not be opened", etc.) ?

> So, my agenda is on ‘-se’ files now. Once you have uploaded a new
> version I will use it in the PHP environment, then share my new version
> of that environment. Indeed I can share the content of the “php” folder
> if anyone wishes to try the current editor.

I'll upload a new version once I get a few more things working.  Of 
course, my current code is available from Git if anyone wants it sooner.

Thanks!

Anthony

Re: [bp-dev] A simple PHP environment to start with BP3

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

Dear Anthony,

I always guess that when you stay silent you are actually working on the 
code to get practical answers… Don't worry about this!

To avoid a long message I only copied excerpts of your message that 
required my immediate comments.

I am still working on the PHP interface: adding possibilities of 
creating new files and the automatic conversion of files to UTF8, 
because there is no alternative to UTF8 in that environment. It should 
be possible to set up the console for UTF8-compliant input/output as 
discussed 10 years ago:

https://stackoverflow.com/questions/2062875/show-utf-8-characters-in-console

Apparently the trick was to use Console.Write() instead of 
Console.Writeline()

If it's too complicated in the beginning we can convert files back to 
MacOS at the time of sending them to the console. Probably a very bad 
idea! ;-)

The high-ascii encoding problem concerns only two signs:

‘•’ = ascii #149 = •
‘…’ = ascii #133 = …

(Source: https://assiste.com/SEO_Webmaster/Tables_ascii_unicode_utf_8.html)

The first one is the period used in “period notation”. It is an 
alternate glyph for a plain period ‘.’ and both work identically in the 
old BP. Therefore it wouldn't be a problem to get periods instead of 
bullets in console or file outputs. I switched to bullets when my 
eyesight started declining. ;-)

I am attaching a copy of “-gr.acceleration” in clean UTF8 format 
containing a bullet on line gram#[2]. You may use it to check that the 
grammar is read and processed correctly with respect to the bullet and 
to end of lines (see below).

The second is an undetermined rest. It also has a low-ascii equivalent: 
“_rest”. Many users are not familiar with typing ‘…’ so they have a 
tendency to type ‘...’ which is equivalent in publications but not in BP 
since it represents 3 periods, that is ‘•••’.

The solution could be the same: let the console display/save expressions 
containing ‘_rest’ but let it accept ‘…’ as an equivalent input. I am 
enclosing “-gr.Ames” which you can use to check the compatibility.

==> Note: SourceForge rejected my message with "zip" attachments, 
telling "550 Blacklisted file extension detected "! Therefore I have put 
the "Ames" and "acceleration" zip files in:
https://leti.lt/bolprocessor

That's all. High-ascii or multibyte characters might be found in 
comments, so I suggest the console leaves out every part of line 
starting with ‘//’. Comments will only taken care of in graphic 
interfaces, e.g. the PHP environment.||||
||||||
> After looking at some of your examples below I realized that the 
> changes I made yesterday would crash if the output file name or path 
> name was longer than 31 characters.  That would clearly be a problem!  
> So, I have reworked all of that again tonight.  It is fixed now (I 
> hope) in the Git repository.
Excellent! We do need long paths for locating the output file.
> -se and -or files are not loaded yet by the console version.  In fact, 
> any related files named at the top of another input file are not 
> loaded yet either, even if the file type is supported by BP console.  
> All input files must currently be specified on the command line.
Do you mean that instead of calling

     bp -gr.NotReich

we should call:

     bp -gr.NotReich -or.NotReich -se.NotReich ?

Since the ‘-or’ and ‘-se’ files are listed on top of the grammar, the 
PHP interface picks up their names to make it possible to edit them. So, 
it will be very easy to create the detailed instruction in that environment.

The interface also makes sure that these files exist at the same level 
as the grammar. I guess your syntax might permit something like:

     bp -gr.NotReich somepath/-or.NotReich anotherpath/-se.NotReich

if settings and orchestra are stored in different folders. Paths 
‘somepath’ and ‘anotherpath’ could be absolute or relative.
> In fact,
>
> bp -gr -ho.abc
>
> would result in "-ho.abc" be loaded as a grammar file, although that 
> would probably be a mistake.  :)
Yes, certainly!

At this stage, remember that appending prefixes such as ‘-gr’, ‘-ho’ 
etc. dates back to the Apple II version when it facilitated the 
alphabetic sorting of files on a floppy disk! Files created under MacOS 
before MacOS 10 had a 'resource’ fork containing an identifier telling 
it belongs to Bol Processor and it is a file of type ‘x’. However the 
resource fork disappeared in MacOS 10, so you choose the option of 
adding an extension so that the system can learn where it comes from. 
Well done, but the habit had been taken to use prefixes and include a 
list of these related files on top of grammars, data, alphabet etc. so 
that the compiler could pick up names and load these files.

(Bizarre, SourceForge rejected earlier attemps of sending this message 
because it traced "bpgr" as an "illicit extension", see 
https://fortiguard.com/encyclopedia/virus/8154925!)

Therefore we should not abandon prefixes in related files except for 
grammar files since they are always at the top of the hierarchy. I guess 
that the console version looks for the extension in case there is no prefix.

>> command = /Applications/MAMP/htdocs/bolprocessor/bp -gr.NotReich -d
>> --csoundout /Applications/MAMP/htdocs/bolprocessor/output/out.sco
>
> Yes, this should work with the latest code in Git!  And only the 
> Csound score lines will be in the file out.sco when done.  (And I 
> added a default f-table statement to the output so that you won't have 
> to edit the score before using it with Csound now).
Great! When the next version is ready you could send us a list of 
typical commands you have tried.
> I am planning to work on implementing the -o option next.  The 
> challenging part is that in BP2 items are written to the Data window 
> using the TextInsert() and DoKey() calls.  But text is written to 
> windows at other times using these same calls which we do not want to 
> end up in the output of "produce items", wherever that might be 
> directed.  Also, because symbols are written just a few at a time 
> without line endings, the output will be all jumbled together with the 
> info messages if everything is sent to stdout.  It would be nice, for 
> displaying items in the terminal window, if all of the text for a 
> single item could be buffered until it is finished and then output all 
> at once.  This would not be necessary, of course, if the output is 
> being directed to a file though.
>
> Hmm... typing that sentence just gave me the idea that items could be 
> written to a temporary file and then that file would be printed to the 
> screen when done.  This could be a temporary solution for BP console, 
> but eventually, I want to rewrite production so that the output is 
> returned to the calling function as a string.
I think you could set an option for saving to a temp file (with detailed 
path) results that will be displayed in the output of the console.
When the command is called via the PHP interface, if the expected output 
is Data we should be able  to read/edit it later.

Still, if the PHP interface lauches a command such as:

     bp -gr.NotReich -o somepath/-da.output_of_NotReich

it should then jump to “-da.output_of_NotReich” and open it. The problem 
is that it will try to open it before it has been saved! I plan to 
create a loop checking every 5 seconds whether the file is existing and 
opening it 5 seconds after it has been created. This presupposes that 
the file has be created, written and closed in a single shot. All I need 
to check is the value of:

     (time() - filemtime($file)) > 5

Later I will work on the important feature of the old BP that made it 
possible to select some data (a polymetric expression) and send it to 
the grammar as a start string to be processed and played. The solution 
will probably be to save the selection to a temp file and then call for 
instance:

      bp -gr.NotReich --startstring somepath/tempfile etc.

I may need to do complicated things in Javascript to create the temp 
file. (Sigh)

> A simpler solution for BP might just be to give messages a priority 
> level and only output messages whose priority is less than specified 
> by the user.  E.g.
>
> "-m 3" -- print all messages
> "-m 2" -- only print errors and warnings
> "-m 1" -- only print errors
> "-m 0" -- suppress all messages
>
> Other command line programs use "-q" or "--quiet" to suppress normal 
> output and "-v" or "--verbose" to print extra diagnostic output.
Excellent idea!
> There is also the issue of which messages to send to std out and which 
> to std error.
>
> How would all of you prefer that BP console messages work?
When working in console mode I find it difficult to go and fetch errors 
in errors.log. It might be better to send them to std out since these 
errors make it impossible to produce the expected output.
>> Indeed, BP still reads “-se.NotReich” and it requires it for setting a
>> few parameters required for the CSOUND output score. Once I have
>> developed the interface for changing settings, we will be able to do
>> things that otherwise would require many more options in the command 
>> line.
>
> I don't think that this is true, but perhaps I should check...
I am going to work next on the ‘-se’ files and identify the parameters 
that are stored there. I know many of them will be ignored, such as the 
positions and sizes of the various windows.

>> Actually, the problem appears to be with Unix line endings (a 
>> linefeed character without a carriage return).  I need to fix this so 
>> that BP can read files with any of the three line ending conventions 
>> (CR, LF, or CRLF).  The UTF8 version of Visser3 does not work when 
>> line endings are changed to Mac Classic but the Mac Roman version does.
Definitely, the program should accept all these combinations and it is 
not difficult to do so. In PHP I first load the entire file as a 
"string", then I perform the following changes:

     $content = str_replace(chr(13).chr(10),chr(10),$content);
     $content = str_replace(chr(13),chr(10),$content);
     $content = str_replace(chr(9),' ',$content); // Remove tabulations
     $content = mb_convert_encoding($content, "UTF-8", 
mb_detect_encoding($content, "UTF-8, ISO-8859-1, ISO-8859-15", true));
     $content = str_replace("¥","•",$content);
     $content = str_replace("Ò","“",$content);
     $content = str_replace("Ó","”",$content);
     $content = str_replace("É","…",$content);
     do $content = 
str_replace(chr(10).chr(10).chr(10),chr(10).chr(10),$content,$count);
     while($count > 0);

The last command eliminates useless empty lines, leaving out not more 
than one empty line between two paragraphs. But that's for the nice 
display. There is no need to take care of it when computing…

So, my agenda is on ‘-se’ files now. Once you have uploaded a new 
version I will use it in the PHP environment, then share my new version 
of that environment. Indeed I can share the content of the “php” folder 
if anyone wishes to try the current editor.

Things are getting clearer… :-)

Bernard

Re: [bp-dev] A simple PHP environment to start with BP3

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

Hello everyone,

Bernard, your new PHP environment looks great! :)  It sounds like you 
have made quite a bit of progress.  I'm looking forward to trying it out 
soon.

I am now free to work on BP again.  I have looked at most of the emails, 
videos, and presentations that were shared this past week.  I hope that 
you will forgive me if I postpone responding to everything a little 
longer.  I was excited to get back to working on the code this weekend 
and was worried that replying to emails would prevent me from doing so.

More below...

On 7/12/20, 9:34 AM, Bernard Bel wrote:

> I have just seen a new commit by Anthony solving the problem of Csound
> output files. The work I am presenting here is anterior to this update,
> so it will require a small adjustment.

After looking at some of your examples below I realized that the changes 
I made yesterday would crash if the output file name or path name was 
longer than 31 characters.  That would clearly be a problem!  So, I have 
reworked all of that again tonight.  It is fixed now (I hope) in the Git 
repository.

> I have put much more material than needed because I wanted to trace
> encoding mistakes: we're moving files from MacOS Roman to UTF8, which
> generates garbage on a few characters. When loading a file a few bugs
> are fixed. Others need to be fixed by hand, notably the '•' sign used
> for "period notation".

I'm not sure yet how BP console responds to characters above the 7-bit 
ASCII limit in input files.  It seems like neither the Mac Roman nor the 
UTF8 versions of Visser3.bpgr in my ctests folder work.  There are also 
lots of 8-bit characters in the messages that BP outputs.  The Terminal 
app on OS X displays these as "?" and I've seen other glyphs on Linux. 
It seems like terminal programs still only handle ASCII?

I definitely want to adopt Unicode eventually but I'm not sure how/when 
that will be feasible.  Also, I *thought* BP console was agnostic about 
line endings but it is not (see below).

> Move to the "ctest" folder and click “-gr.NotReich”. I am attaching a
> picture of the scene, so you can follow my explanation.
>
> You can edit and save the grammar. At the bottom of the page two buttons
> are displayed for editing “-se.NotReich” and “-or.NotReich”. The
> “orchestra” file is a mapping of MIDI channels to GeneralMIDI
> instruments. Only useful when composing music for several instruments.
> Still, the format needs to be extended to more than 16 channels.
>
> The “settings” file contains all settings. It also could be edited and
> saved but this is risky because we have no clue to the actual meaning of
> each parameter. My next work will be to extract all variables and
> display them in a comprehensive format.

-se and -or files are not loaded yet by the console version.  In fact, 
any related files named at the top of another input file are not loaded 
yet either, even if the file type is supported by BP console.  All input 
files must currently be specified on the command line.

> command = /Applications/MAMP/htdocs/bolprocessor/bp -gr.NotReich -d
> --csoundout > /Applications/MAMP/htdocs/bolprocessor/output/out.sco
>
> Well, absolute links are used to avoid mistakes on relative paths. After
> all, this is internal cuisine and I needed to make sure that BP would
> handle these absolute links. It does, except for the grammar because it
> checks its name is compliant with a BP grammar but it does it without
> removing the path. To go around this I did a chdir() in PHP that located
> the process in the same "ctest" folder containing the grammar.

I plan to fix the problem with BP file names not being identified if 
there are additional path elements in front of them.  For now though, 
this works just fine:

bp -gr /some/path/-gr.NotReich

BP's file name prefixes (-gr, -ho, etc.) can also be used like options 
on the commandline to load a file with any name as a particular type.  So,

bp -gr.NotReich
bp NotReich.bpgr
bp -gr NotReich.txt

will result in the files "-gr.NotReich", "NotReich.bpgr", or 
"NotReich.txt" respectively being loaded as a grammar file.  In fact,

bp -gr -ho.abc

would result in "-ho.abc" be loaded as a grammar file, although that 
would probably be a mistake.  :)

> Other absolute paths are in fact well-managed by the Linux command, and
> we get the "/output/out.sco" file as expected. Except that it contains a
> mixture of the score with computation messages as I had pointed out. For
> this reason, Anthony fixed the output option which I guess should fit
> with the new command:
>
> command = /Applications/MAMP/htdocs/bolprocessor/bp -gr.NotReich -d
> --csoundout /Applications/MAMP/htdocs/bolprocessor/output/out.sco

Yes, this should work with the latest code in Git!  And only the Csound 
score lines will be in the file out.sco when done.  (And I added a 
default f-table statement to the output so that you won't have to edit 
the score before using it with Csound now).

> Other commands produced by the PHP interface in compliance with
> BP2-Help, but which do not work, are:
>
> command = /Applications/MAMP/htdocs/bolprocessor/bp -gr.NotReich -d --rtmidi
> command = /Applications/MAMP/htdocs/bolprocessor/bp -gr.NotReich -d
> --midiout /Applications/MAMP/htdocs/bolprocessor/output/out.mid
> command = /Applications/MAMP/htdocs/bolprocessor/bp -gr.NotReich -d -o
> /Applications/MAMP/htdocs/bolprocessor/output/-da.out
>
> The last one complains that '-o' is not a valid option.
> The first one is real-time MIDI which we will address later…

I am planning to work on implementing the -o option next.  The 
challenging part is that in BP2 items are written to the Data window 
using the TextInsert() and DoKey() calls.  But text is written to 
windows at other times using these same calls which we do not want to 
end up in the output of "produce items", wherever that might be 
directed.  Also, because symbols are written just a few at a time 
without line endings, the output will be all jumbled together with the 
info messages if everything is sent to stdout.  It would be nice, for 
displaying items in the terminal window, if all of the text for a single 
item could be buffered until it is finished and then output all at once. 
  This would not be necessary, of course, if the output is being 
directed to a file though.

Hmm... typing that sentence just gave me the idea that items could be 
written to a temporary file and then that file would be printed to the 
screen when done.  This could be a temporary solution for BP console, 
but eventually, I want to rewrite production so that the output is 
returned to the calling function as a string.

> Maybe there should be a '-m' option (set by default) meaning that we
> don't want to see any of those messages that used to appear at the
> bottom line of the old BP. Their main purpose was to make the user aware
> that the machine is doing something and not stuck or looping. Now the
> machine is running so much faster that they don't make sense. If
> necessary we'll set up "Trace" in the settings.

This is a good idea.  Csound has a '-m' option that sets the "message 
level".  Each message that Csound could output is assigned a category 
with an integer identifier and only messages whose category match the 
current message level are actually printed.  In Csound, the message 
level is the sum of the category identifiers which are all powers of 2, 
allowing any combination of categories to be enabled or disabled by the 
user.

A simpler solution for BP might just be to give messages a priority 
level and only output messages whose priority is less than specified by 
the user.  E.g.

"-m 3" -- print all messages
"-m 2" -- only print errors and warnings
"-m 1" -- only print errors
"-m 0" -- suppress all messages

Other command line programs use "-q" or "--quiet" to suppress normal 
output and "-v" or "--verbose" to print extra diagnostic output.

There is also the issue of which messages to send to std out and which 
to std error.

How would all of you prefer that BP console messages work?

> Indeed, BP still reads “-se.NotReich” and it requires it for setting a
> few parameters required for the CSOUND output score. Once I have
> developed the interface for changing settings, we will be able to do
> things that otherwise would require many more options in the command line.

I don't think that this is true, but perhaps I should check...

> Take for instance “-gr.Mozart”. As shown on the video I sent a few days
> ago, it continuously creates new variations. This is a setting of
> “-se.Mozart”. If we don't change the setting and run the grammar to
> create a file, it will grow forever!
>
> I tried to create that incident but it failed for another reason: the
> display of “-gr.Mozart” is perfect but its computation fails. You will
> find the list of errors in "output/Mozart.out". The same happens with
> the “Visser3_UTF8.bpgr” and both yield the same bizarre errors:
>
> BP2 Console completed initialization.
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. GetTextChar(). pos out of range
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Compiling alphabet…
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. GetTextChar(). pos out of range
> Looking for time patterns…
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. GetTextChar(). pos out of range
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Compiling subgrammar #1…
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
> Err. ReadLine(). c == '\n'
>
> I tried to understand why a '\n' character was doing a mess and how to
> compensate it in the editor. Empty lines? No doubt it will make sense to
> Anthony! ;-)

I saw these same messages when I tried "Visser3_UTF8.bpgr" a little bit 
ago too.  I though it might be because of the '•' characters but 
replacing them with '.' doesn't help.

Actually, the problem appears to be with Unix line endings (a linefeed 
character without a carriage return).  I need to fix this so that BP can 
read files with any of the three line ending conventions (CR, LF, or 
CRLF).  The UTF8 version of Visser3 does not work when line endings are 
changed to Mac Classic but the Mac Roman version does.

So for now, all input files should use Mac Roman encoding and Mac 
Classic line endings (just CR, although CRLF *might* work).  The '•' 
character appears to work under these conditions.  (The source code 
files are still in Mac Roman encoding so I think this will be true even 
when compiling on Linux or Windows but I haven't tested it).

> I still have a lot of work to do on this minimal interface. I am using
> beginner's PHP: no session variable, no javascript, to make it easy to
> reconstruct in a different environment.

I clearly have a lot of work to do too! ;-)  I hope to continue making 
progress this week.

Thanks for sharing your work!

Anthony