bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] Windows and RPI-builds

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

Rainer Schuetz wrote on 24/07/2020 11:50:
> Dear Bernard ’n friends,
>
>> Dear Rainer,
>>
>> It is great that you are following development trying things on different systems. For instance, the question remains open regarding paths in command lines that contain spaces: is it ok to pack them between quotes or should we replace them backslash spaces?
> The only simple answer I know is: no. Quotes can be swallowed by parsers, and backslash is not recognised by Windows as escape character (Instead it is used as directory separator in paths - OMG!!!. Windows uses ^ instead of \, and in some cases it works, but not reliably. It’s a bit like that keyboard problem we spoke about like 10 years ago, so many layers of reinterpretation interact that it’s really hard to keep things apart. And then - in our desperation - we submit to the trial and error approach (the results of which usually fail in the next environment);-)  ). So if we take support of elderly Windows systems including cross-compile environments like msys2/mingw serious, spaces unfortunately should be avoided.
A reasonable way of avoiding this problem would be that the interface 
automatically replaces spaces with '_' when a file of BP is opened. This 
is feasible on the PHP interface and I will implement it. Thus, 
"-gr.notReich copy" would become "-gr.notReich_copy".

PHP/HTML are quite user-friendly (and international) with respect to 
file names and links. They re-encode odd characters when necessary (such 
as "%20" for a space). I am even using them with multibyte UTF codes 
such as the Devanagari script.
> But then the "accessing csound" problem is not really something we/you have control over, so I guess when it appears - like in that script, one needs to hunt for a local solution. Note that this only happens, because I am running bp3 in a non-native console. In a modern “Dosbox” I could’ve queried the csound path with “where” and the path (including spaces) would have been passed over properly to the system. But alas, the Dosbox doesn’t understand the bash-script - so for now no automatic testing in really native Windows (cmake might be a solution at the price of another language, but that introduces another dependency and doesn’t support old systems). A nice aspect about using something like PHP is that they do “cross platform” as a fundamental requirement - so while I don’t have concrete knowledge about this yet - I would bet PHP (maybe actually Apache) solves all these problems for you - at the price of a different language - and I guess - another “command line syntax”.
Yes. When jumping to page "produce.php", arguments are send in $_GET 
format (visible on the URL) and could as well be sent via $_POST. Then 
the page takes care of building the appropriate command line.
> Btw., I am kind of surprised that you can do so much with binaries from PHP - generally - for security reasons - browsers are very restrictive in what they allow to happen on a local system (imagine somebody formatting the system disk when you press a button on a php-site - after all you don’t see what happens). I will try to understand better this weekend or next week.
This we had discussed earlier. We are running this PHP interface on 
local web service (such as MAMP). For this reason calling "system" 
commands also accept calling binaries. If we want to expose this 
interface to the public we'll need a dedicated hosting with permission 
to do the same. Practically it should be restricted to identified users 
so that robots and hackers don't blow processor time and RAM space.

My suggestion is to install a Wordpress site from which only identified 
users with some level of permission will be able to access the pages 
from which BP commands can be issued. Their "material" (grammars, 
alphabet etc.) would be stored in posts. I am quite conversant with 
Wordpress + PHP environments after developing these tools:

https://lebonheurestpossible.org/pid-management/
https://lebonheurestpossible.org/revision-tracker-en/

If the "produce.php" page is in the Wordpress folder it can 
automatically check the status of a connected user and accept or deny 
access.

The host of my websites (OVH) said that they cannot grant me with such 
features unless I take a "dedicated account" — indeed more expensive.
>> (Indeed I could search for the answer but it's easier to try!) When I do experiments on a grammar I create a copy of it, which means "-gr.NotReich" will become "-gr.NotReich copy" on the Mac.
> Yes, stuff like that could drive the parser mad;-)  Not only that you start the filename with the “argument marker” - when it’s gotten past that hurdle, you add to its confusion with a space that is not a separation marker. I am sure Anthony loves this challenge of a totally non-conventional approach. It has something of a “really rare steak” - some love it, others shudder;-)
This he solved elegantly: if the grammar is "-gr.NotReich" he reads 
"-gr" as the argument maker. If the name is different, for instance 
"NotReich.bpgr" then we use the command "-gr NotReich.bpgr". This allows 
more complex paths and dealing with spaces such as:

/Applications/MAMP/htdocs/bolprocessor/bp produce -gr 
"/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich copy"

In the end, command lines become very long because of the use of 
absolute paths (starting with /Applications...), but these lines are 
displayed at the top of the page on which they are executed. This 
facilitates debugging.
>> I also like very much your submissions of PHP files to GitHub. PHP gives immediate results and I don't spend time documenting changes, with the risk of forgetting some worthy material in an older version. For instance, useful to see the updates in the reformat_grammar() command:
>> https://github.com/bagong/bolprocessor/commit/489ccd57554ebebdbbfc6faeed393c6a7b5b3349#diff-e1f470c90e7b480908538e55dd6ecfcd
> I am glad you appreciate it! I wasn’t sure if you minded the public exposure of early code, or even thought that I am running away with something - which of course is not the case. It just helps me doing testing in an environment that I am used to, and who knows - if someone saw it on Github, he/she might get interested in contributing to the project.
Yes, this might happen. Much like I believe there exist exoplanets 
peopled with intelligent and gentle aliens, my theory is that there are 
a few "Anthony Kozars" flying in cyberspace for the team to grow :-) 
After all, you are one of them, with specific experience and expectations!
> I did hope that you'd appreciate the aspect of documenting code-development by “freezing” stages in commits. A git-repo is really another window into history. And if the commit-messages are expressive, they can tell the story of the project. And diffs with a button are so cool to. Really the relation of Github to git is somewhat like the relation of bp-php to bpconsole. The ability to create diffs is built into the binary, and Github just calls the functionality (I imagine ;-)). That is maybe an interesting analogy when thinking about how responsibilities are shared between yours and Anthony's work (I remember that “reinventing the wheel” sentence).
>
> But coming back to commits: I am happy to add your snapshots as commits to the repo to create sort of a history of code development. That would not only be interesting, but maybe also helpful if regressions occur or one needs to find out why something went wrong in the past (I think it’s called “disecting” in git lingo). But as I don’t really understand what you’re doing - and as I depend on your little descriptions of your changes for the commit-messages, the usefulness will be the bigger, the more detailed you describe, what individual snapshots do. If I just look if there is a new snapshot on your download-site every day or week, I can update the Github repo - but I wouldn’t really be able to tell what the innovations of each snapshot were….
Right. Now that I know all major changes will be recorded in the Git 
repository, I will take care of describing modifications and pointing at 
the implementation of new features. Bug fixes are less interesting 
although sometimes they reveal the misunderstanding of procedures and 
algorithms. (For example, should we do "mkdir" in PHP or as a system 
command?)
> But tbh - I am sneekily trying to convince you to use git yourself;-)
I will certainly end up doing the commits myself. I always feel lazy 
learning new procedures, so I work intensively on one at a time. I spent 
2 months designing a "history tracing" of Wordpress pages 
(https://lebonheurestpossible.org/revision-tracker-en/) — actually using 
string algorithms I was fond of when starting the BP project — in order 
to display only relevant changes. But this made me versed in 
Wordpress/PHP interactions (keeping protection plugins silent).
> If one keeps it simple, it’s almost banal to use, one just needs to keep remembering to commit. After the warmup-period to the “different world” that becomes second nature.
I am sure it will!
> Yes, it’s nice to work in different fields with a common goal, and 
> it’s so lovely that Anthony likes to do this kind of work. Anthony is 
> a star! Git actually also helps to undo accidental change and helps to 
> reduce anxieties if people reach out into the “others” domain ;-) - 
> especially if people are well minded and friendly - another aspect why 
> you are so lucky to have found Anthony. But then I guess nice natures 
> are bound to find each other at some point ;-)
The link is our common understanding of the program's operation at a 
mature stage (in 1998), and I guess part of his initial motivation was 
the possibility of dealing with Csound scores and instruments. Because 
of complimentary experience we covered already a wide range of "visions 
of music". We have enough in common to reach a consensus when issues are 
discussed. Much like Harm Visser's interest was in polyrhythmic 
structures and tools for creating a kind of serial music. Everyday he 
would blow the application's RAM using recursive rules. This took me to 
the idea of quantization.

The musical experience that is still missing in Bol Processor is that of 
jazz music. Once we get feedback from jazz musicians we'll have more 
ideas about "collective improvization" with several BPs joining the "band".

Sometimes I dream seeing things like this:
https://arcopypaste.app/ :-)
Designed by a young French student!

Bernard Bel

Re: [bp-dev] Windows and RPI-builds

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

Dear Bernard ’n friends,

> Dear Rainer,
> 
> It is great that you are following development trying things on different systems. For instance, the question remains open regarding paths in command lines that contain spaces: is it ok to pack them between quotes or should we replace them backslash spaces?

The only simple answer I know is: no. Quotes can be swallowed by parsers, and backslash is not recognised by Windows as escape character (Instead it is used as directory separator in paths - OMG!!!. Windows uses ^ instead of \, and in some cases it works, but not reliably. It’s a bit like that keyboard problem we spoke about like 10 years ago, so many layers of reinterpretation interact that it’s really hard to keep things apart. And then - in our desperation - we submit to the trial and error approach (the results of which usually fail in the next environment) ;-) ). So if we take support of elderly Windows systems including cross-compile environments like msys2/mingw serious, spaces unfortunately should be avoided. But then the "accessing csound" problem is not really something we/you have control over, so I guess when it appears - like in that script, one needs to hunt for a local solution. Note that this only happens, because I am running bp3 in a non-native console. In a modern “Dosbox” I could’ve queried the csound path with “where” and the path (including spaces) would have been passed over properly to the system. But alas, the Dosbox doesn’t understand the bash-script - so for now no automatic testing in really native Windows (cmake might be a solution at the price of another language, but that introduces another dependency and doesn’t support old systems). A nice aspect about using something like PHP is that they do “cross platform” as a fundamental requirement - so while I don’t have concrete knowledge about this yet - I would bet PHP (maybe actually Apache) solves all these problems for you - at the price of a different language - and I guess - another “command line syntax”. Btw., I am kind of surprised that you can do so much with binaries from PHP - generally - for security reasons - browsers are very restrictive in what they allow to happen on a local system (imagine somebody formatting the system disk when you press a button on a php-site - after all you don’t see what happens). I will try to understand better this weekend or next week.

> (Indeed I could search for the answer but it's easier to try!) When I do experiments on a grammar I create a copy of it, which means "-gr.NotReich" will become "-gr.NotReich copy" on the Mac.

Yes, stuff like that could drive the parser mad ;-) Not only that you start the filename with the “argument marker” - when it’s gotten past that hurdle, you add to its confusion with a space that is not a separation marker. I am sure Anthony loves this challenge of a totally non-conventional approach. It has something of a “really rare steak” - some love it, others shudder ;-)

> I also like very much your submissions of PHP files to GitHub. PHP gives immediate results and I don't spend time documenting changes, with the risk of forgetting some worthy material in an older version. For instance, useful to see the updates in the reformat_grammar() command:
> https://github.com/bagong/bolprocessor/commit/489ccd57554ebebdbbfc6faeed393c6a7b5b3349#diff-e1f470c90e7b480908538e55dd6ecfcd

I am glad you appreciate it! I wasn’t sure if you minded the public exposure of early code, or even thought that I am running away with something - which of course is not the case. It just helps me doing testing in an environment that I am used to, and who knows - if someone saw it on Github, he/she might get interested in contributing to the project.

I did hope that you'd appreciate the aspect of documenting code-development by “freezing” stages in commits. A git-repo is really another window into history. And if the commit-messages are expressive, they can tell the story of the project. And diffs with a button are so cool to. Really the relation of Github to git is somewhat like the relation of bp-php to bpconsole. The ability to create diffs is built into the binary, and Github just calls the functionality (I imagine ;-)). That is maybe an interesting analogy when thinking about how responsibilities are shared between yours and Anthony's work (I remember that “reinventing the wheel” sentence).

But coming back to commits: I am happy to add your snapshots as commits to the repo to create sort of a history of code development. That would not only be interesting, but maybe also helpful if regressions occur or one needs to find out why something went wrong in the past (I think it’s called “disecting” in git lingo). But as I don’t really understand what you’re doing - and as I depend on your little descriptions of your changes for the commit-messages, the usefulness will be the bigger, the more detailed you describe, what individual snapshots do. If I just look if there is a new snapshot on your download-site every day or week, I can update the Github repo - but I wouldn’t really be able to tell what the innovations of each snapshot were….

But tbh - I am sneekily trying to convince you to use git yourself ;-) If one keeps it simple, it’s almost banal to use, one just needs to keep remembering to commit. After the warmup-period to the “different world” that becomes second nature. After one has implemented an idea, one just does `git add .` and then `git commit -m “My beautiful new idea”` and the thought is kept for posterity. To go public one just does “git push”. Changes/fixes are never changed in the past but added on top, so both the mistake or misconception and its later correction remain visible in the git-log. Again that’s interesting, but more importantly it keeps things simple. Things get more complicated when commit accidents occur or one works in teams and with multiple remotes, but those three commands “add .”, "commit -m “…””, and “push” are the three functionalities you can work with most of the time, once a repo is set up and linked to a remote. Git is also brilliantly documented. Any question you can imagine has been asked before and answered on some website, so it’s just a matter of enquiring, and maybe digest tips from a few friends about how “to think” the thing.

> At the moment I don't modify C code — just sending a few suggestions to Anthony — and I feel uneasy with potential conflicts in modifying bits of code which I remember have been strongly interdependant. (I can indeed modify a C source file and recompile calling MakeFile to check a minor change.)

Yes, it’s nice to work in different fields with a common goal, and it’s so lovely that Anthony likes to do this kind of work. Anthony is a star! Git actually also helps to undo accidental change and helps to reduce anxieties if people reach out into the “others” domain ;-) - especially if people are well minded and friendly - another aspect why you are so lucky to have found Anthony. But then I guess nice natures are bound to find each other at some point ;-)

Best
.r.

[bp-dev] Real-time MIDI

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

As far as real-time MIDI is concerned we'll probably need conditional 
compilation for various systems. Making it work on both Mac and Windows 
would be a good start!

The first thing I had done to implement MIDI output was to create a 
minimum C program that could send a simple NoteOn/NoteOff pair. It's 
probably documented in some obscure web archive… ;-) On a Mac, use for 
instance the General MIDI Player as the default destination. If my 
memory is correct (as the MIDI environment changed radically over years) 
we now send time-stamped MIDI messages, so they all can be sent in advance.

In versions earlier than OMS it was necessary to run a loop that would 
send messages at a time checked on the computer's clock. The drawback of 
the current version, in an interactive environment, is that you can't 
modify events already sent to the sound machine. In the old version they 
could be picked up and modified while doing circles on the loop.

In CoreMIDI settings on BP2.9.8 we have MIDI filters for input/output. 
By default (as per the enclosed "-se.startup") receive all messages but 
transmit none. If this is not set properly, messages sent to an 
instrument might loop forever. I had this trouble trying to play 
"-gr.NotReich" on piano instruments: the instrument received a message 
but it sent it again to the same port, so BP2 again transmitted it…

The correct default settings for MIDI input filter is 262143 and 0 for 
the transmit filter. I haven't yet checked how we get the "262143" 
figure when all messages are accepted at the input. This may be useful 
to make sure that the machine makes sounds when checked with the new 
MIDI driver!

Bernard

Re: [bp-dev] Windows and RPI-builds

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

Dear Rainer,

It is great that you are following development trying things on 
different systems. For instance, the question remains open regarding 
paths in command lines that contain spaces: is it ok to pack them 
between quotes or should we replace them backslash spaces? (Indeed I 
could search for the answer but it's easier to try!) When I do 
experiments on a grammar I create a copy of it, which means 
"-gr.NotReich" will become "-gr.NotReich copy" on the Mac.

I also like very much your submissions of PHP files to GitHub. PHP gives 
immediate results and I don't spend time documenting changes, with the 
risk of forgetting some worthy material in an older version. For 
instance, useful to see the updates in the reformat_grammar() command:
https://github.com/bagong/bolprocessor/commit/489ccd57554ebebdbbfc6faeed393c6a7b5b3349#diff-e1f470c90e7b480908538e55dd6ecfcd

At the moment I don't modify C code — just sending a few suggestions to 
Anthony — and I feel uneasy with potential conflicts in modifying bits 
of code which I remember have been strongly interdependant. (I can 
indeed modify a C source file and recompile calling MakeFile to check a 
minor change.)

Bernard

Rainer Schütz wrote on 23/07/2020 22:24:
> Dear friends,
> 
> I’ve come around now to try building on Windows and the Raspberry Pi. It looks great. I’ve been spending some time filing on a script that builds and runs the commands Anthony suggested to try out his new version. I am keeping that script (“tests”;-)  ) in a Github repo where I mirror Anthony’s repo, and where I also fold in Bernard’s snapshots (I think I wrote about this already? If not, tell me what you think).
> 
> It’s onhttps://github.com/bagong/bolprocessor  on the branch bagong (default branch there). On that branch I’ve also put the ctests folder under version control because that way I can easily move it to any computer on which I try building. The script sends all output to a file, puts them in an archive, and uploads it to a a webserver. You can download recent output and the binaries from here:
> 
> https://bp.bagong.de
> 
> Hopefully I’ll find some time on the weekend to configure a apache-php environment on Windows. I’ll let you know how that went;-)
> 
> Best
> Rainer

[bp-dev] MIDI files via PHP interface

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

PS. In fact both links point to the same "MIDI class" package except 
that the first one is 12-year old and the second one has been updated on 
GIThub 4 years ago…

-----------

We do need to import MIDI files when editing a sound-object prototypes, 
and this takes place on the PHP interface at the moment.

It's not complicated. I downloaded "MIDI class" by Fluxus:

https://www.phpclasses.org/package/1362-PHP-Read-write-and-manipulate-MIDI-files-and-data.html

but that one is more recent:

https://github.com/robbie-cao/midi-class-php

Their code looks familiar and promising! It is true that we could 
request the console to do the conversion and send back the time-stamped 
MIDI codes, but using a more advanced package might give access to 
advanced methods.

The console will be invoked to play the sound-object that is being 
edited, or an arbitrary polymetrric structure that may first be 
interpreted by the grammar. For this we'll only need a "--startstring" 
option. If the option to write a Csound output is set, the same will be 
used for converting MIDI codes to Csound, using either the default BP2 
Csound orchestra or a "-cs" file defining an orchestra.

Bernard

Anthony Kozar wrote on 24/07/2020 00:22:
>> I am now tempted to work on the import of MIDI files into sound object
>> prototypes, and converting MIDI sequences to Csound. Looking at the C
>> code should make it easy.
>
> These operations might be good to implement as actions in BP console. 
> That way we can use the existing code instead of "reinventing the wheel".
>
> Anthony 

[bp-dev] MIDI files via PHP interface

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

We do need to import MIDI files when editing a sound-object prototypes, 
and this takes place on the PHP interface at the moment.

It's not complicated. I downloaded "MIDI class" by Fluxus:

https://www.phpclasses.org/package/1362-PHP-Read-write-and-manipulate-MIDI-files-and-data.html

but that one is more recent:

https://github.com/robbie-cao/midi-class-php

Their code looks familiar and promising! It is true that we could 
request the console to do the conversion and send back the time-stamped 
MIDI codes, but using a more advanced package might give access to 
advanced methods.

The console will be invoked to play the sound-object that is being 
edited, or an arbitrary polymetrric structure that may first be 
interpreted by the grammar. For this we'll only need a "--startstring" 
option. If the option to write a Csound output is set, the same will be 
used for converting MIDI codes to Csound, using either the default BP2 
Csound orchestra or a "-cs" file defining an orchestra.

Bernard

Anthony Kozar wrote on 24/07/2020 00:22:
>> I am now tempted to work on the import of MIDI files into sound object
>> prototypes, and converting MIDI sequences to Csound. Looking at the C
>> code should make it easy.
>
> These operations might be good to implement as actions in BP console. 
> That way we can use the existing code instead of "reinventing the wheel".
>
> Anthony 

Re: [bp-dev] Windows and RPI-builds

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

Very nice, Rainer!  Thanks for continuing to test on so many platforms!! 
  I'll take a look at your results when I can.

I thought about putting all of those example commands in a script but 
didn't take the time.  So, thanks! :)

Anthony


On 7/23/20, 4:35 PM, Rainer Schütz wrote:
> Eh, sorry, the link to the binaries and test-output-files is
>
> https://bp.bagong.de/archives
>
> And I attach the script if anybody is interested and not too fond of
> cloning GitHub repos. It should actually work in Anthony’s ANSI-branch
> (or the snapshot he sent), provided the test folder is available. It
> doesn’t do anything with the php-side yet, but it does create the
> “output”-folder Bernard suggested in the beginning.

Re: [bp-dev] Trace file/window remained empty + scripts

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

On 7/23/20, 5:25 PM, Bernard Bel wrote:

> I also found out that we get an error message with an empty Trace file
> when there is a mistake in the command, which is not the case here. I
> got a mistake trying to run a grammar whose name contains a space… This
> is now fixed by putting spaced names or paths between quotes.

Yes, quoting or escaping spaces and some other characters like *? is 
necessary when constructing command lines.  I'm not sure of all of the 
rules myself.  Any online shell tutorial/reference should be able to 
clarify problems that come up.

> I also completed the reformat_grammar() procedure after checking all
> reserved words on BP2.9.8, many of which I had forgotten as they date
> back to modelling drum improvisation!
>
> The files I modified are attached. They are also in
> https://leti.lt/bolprocessor/

I'll check it out when I get a chance.

> Indeed the crash log tells something but I am unable to make sense of
> it!  It might be difficult to trace the process on such a complicated
> grammar. I use it only because it contains a great diversity of
> instructions. So the error may just be stored on the to-do list.

If I'm lucky, when I run this example in Xcode with the debugger it will 
just show me which line of code the segmentation fault occurs on.  Then 
I can set an earlier breakpoint if necessary to understand how it got there.

-gr.ShapesInRhythm does seem like a good test. :)

> [...]  Probably a few script commands will be used by the PHP
> interface, e.g. load a file, produce x items etc. and executed via
> command lines.

I think a few of the planned command line "actions" were inspired by 
script commands: produce-items N, play-item N, expand-item N, etc.

> At some point we may need to find a method for waiting for a mouseclick
> or any human action triggering the performance of an item that has been
> prepared.

This and other custom or scripted "workflows" will be very easy to 
implement in client programs once the API is available (i.e. "BP4").  If 
it is needed before then, we can consider alternatives.

> I am now tempted to work on the import of MIDI files into sound object
> prototypes, and converting MIDI sequences to Csound. Looking at the C
> code should make it easy.

These operations might be good to implement as actions in BP console. 
That way we can use the existing code instead of "reinventing the wheel".

Anthony

Re: [bp-dev] Trace file/window remained empty + scripts

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

Dear Anthony,

I also found out that we get an error message with an empty Trace file 
when there is a mistake in the command, which is not the case here. I 
got a mistake trying to run a grammar whose name contains a space… This 
is now fixed by putting spaced names or paths between quotes.

I also completed the reformat_grammar() procedure after checking all 
reserved words on BP2.9.8, many of which I had forgotten as they date 
back to modelling drum improvisation!

The files I modified are attached. They are also in
https://leti.lt/bolprocessor/

Indeed the crash log tells something but I am unable to make sense of 
it!  It might be difficult to trace the process on such a complicated 
grammar. I use it only because it contains a great diversity of 
instructions. So the error may just be stored on the to-do list.

Scripts will be useful once we have real-time MIDI in/out, but we'll 
need to ignore the ones having effects on the interface, such as loading 
a file, changing work folder, sounding a beep, waiting for the space key 
to be pressed etc. I will prepare a list of the ones that should be 
ignored. Many of them were reproducing menu commands, as a script could 
be constructed in the "learning mode": every action on the interface was 
recorded as a script command. But this all has to do with real-time 
operations. Probably a few script commands will be used by the PHP 
interface, e.g. load a file, produce x items etc. and executed via 
command lines.

At some point we may need to find a method for waiting for a mouseclick 
or any human action triggering the performance of an item that has been 
prepared.

Once interface-connected script commands have been neutralized, the 
relevant script operations should work flawlessly. There is nothing 
complicated in the process.  "BP2 script" is a header on top of a script 
or glossary file. It does nothing in particular.

When I was developing the core program in Delhi, BP2 was connected to my 
D50 synth. Every evening (once my colleagues had left the office) I used 
to run "+sc.checkall" designed for trying all features. This took about 
30 minutes. I was listening while doing other things, then checking 
errors on the Trace. By ear I would immediately identify odd behaviour. ;-)

I am now tempted to work on the import of MIDI files into sound object 
prototypes, and converting MIDI sequences to Csound. Looking at the C 
code should make it easy.

Bernard


Anthony Kozar wrote on 23/07/2020 22:19:
> I have reproduced the problem here.  When I attempt to create a Csound 
> score on the command line, BP console gets as far as time setting the 
> last sequence (?) and then crashes:
>
> 3566 objects. Compression rate = 51  Sequence 11/11
> Sizing objects
> Setting limits
> Placing objects
> Solving constraints
> Calculating global drift
> Calculating legato/staccato
> Segmentation fault: 11
>
> When you don't get any output running a command from the PHP interface 
> it may help to run it directly on the command line.
>
> The crash log shows that this occurred in MakeSound() and the 
> exception that caused the crash was
>
> Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
>
> I'm guessing that that is an attempt to access a null pointer.  I'm 
> guessing that it is related to the use of script commands but I'll 
> have to trace the problem in the debugger to be sure.
>
> Interestingly, the segmentation fault does not occur if you run this 
> grammar with --rtmidi instead of --csoundout.  Then the output 
> continues after time setting:
>
> 3566 objects. Compression rate = 51  Sequence 11/11
> Sizing objects
> Setting limits
> Placing objects
> Solving constraints
> Calculating global drift
> Calculating legato/staccato
> Ignoring script command: MIDI controller #98 = 1 channel 1
> (Scripts do not work yet in the console version).
> Ignoring script command: MIDI program 63
> (Scripts do not work yet in the console version).
> Ignoring script command: Beep
> (Scripts do not work yet in the console version).
> Ignoring script command: Wait for space
> (Scripts do not work yet in the console version).
> Ignoring script command: Tick cycle OFF
> (Scripts do not work yet in the console version).
>
> The fact that the very next message after where it seg faults for 
> --csoundout is "Ignoring script command: MIDI controller #98" is 
> evidence that my hunch is correct.
>
> Nothing related to script commands currently works in BP console.  And 
> the only other crash I have experienced with it so far had to do with 
> loading a glossary file that I think began with "BP2 SCRIPT".  IIRC, I 
> took some shortcuts to get the console version to compile in 2013 and 
> I did not really finish substituting appropriate code everywhere for 
> the non-functional script commands.
>
> I will add fixing these crashes to my to do list.  Making script 
> commands work in the console version is a large task though and I was 
> not sure how important it is to do.  Certainly some of the script 
> commands are no longer relevant (e.g. Freeze windows).  And I have the 
> impression (which may not be correct) that many of the others 
> duplicate functionality that can be achieved in other ways(??).
>
> I'd like to hear what you think.
>
> Anthony
>
>
> On 7/22/20, 11:14 AM, Bernard Bel wrote:
>> Dear Anthony,
>>
>> When I compile grammar “-gr.ShapesInRhythm” in the PHP interface, it
>> says "no error".
>>
>> When producing a "BP data file" I get the (presumably correct) data on
>> the Data window.
>>
>> However, attempting to produce a Csoud file ends up in an error.
>> However, no messages have been produced and the Trace window remained 
>> empty.
>>
>> Note that this grammar does produce Csound (and MIDI) files on BP2.9.8
>> although it asks the user to press the space key before doing it. This
>> is due to instruction "_script(Wait for space)" which should be ignored
>> in the context of creating a file.
>>
>> I guess that BP is not able to create Csound events reproducing
>> performance parameters such as "_script(MIDI controller #98 = 1 channel
>> 1)", but at least when it fails it should send a message to Trace.
>>
>> Maybe this will be solved by loading “-se.ShapesInRhythm.QTM” ?
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Windows and RPI-builds

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

Dear friends,

I’ve come around now to try building on Windows and the Raspberry Pi. It looks great. I’ve been spending some time filing on a script that builds and runs the commands Anthony suggested to try out his new version. I am keeping that script (“tests” ;-) ) in a Github repo where I mirror Anthony’s repo, and where I also fold in Bernard’s snapshots (I think I wrote about this already? If not, tell me what you think).

It’s on https://github.com/bagong/bolprocessor on the branch bagong (default branch there). On that branch I’ve also put the ctests folder under version control because that way I can easily move it to any computer on which I try building. The script sends all output to a file, puts them in an archive, and uploads it to a a webserver. You can download recent output and the binaries from here:

https://bp.bagong.de

Hopefully I’ll find some time on the weekend to configure a apache-php environment on Windows. I’ll let you know how that went ;-)

Best
Rainer

Re: [bp-dev] Windows and RPI-builds

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

Eh, sorry, the link to the binaries and test-output-files is

https://bp.bagong.de/archives

And I attach the script if anybody is interested and not too fond of cloning GitHub repos. It should actually work in Anthony’s ANSI-branch (or the snapshot he sent), provided the test folder is available. It doesn’t do anything with the php-side yet, but it does create the “output”-folder Bernard suggested in the beginning.



Best
.r.

> Begin forwarded message:
> 
> From: Rainer Schütz <rs...@ig...>
> Subject: Windows and RPI-builds
> Date: 23. July 2020 at 22:24:05 CEST
> To: Bol Processor developer discussion list <bol...@li...>
> 
> Dear friends,
> 
> I’ve come around now to try building on Windows and the Raspberry Pi. It looks great. I’ve been spending some time filing on a script that builds and runs the commands Anthony suggested to try out his new version. I am keeping that script (“tests” ;-) ) in a Github repo where I mirror Anthony’s repo, and where I also fold in Bernard’s snapshots (I think I wrote about this already? If not, tell me what you think).
> 
> It’s on https://github.com/bagong/bolprocessor on the branch bagong (default branch there). On that branch I’ve also put the ctests folder under version control because that way I can easily move it to any computer on which I try building. The script sends all output to a file, puts them in an archive, and uploads it to a a webserver. You can download recent output and the binaries from here:
> 
> https://bp.bagong.de
> 
> Hopefully I’ll find some time on the weekend to configure a apache-php environment on Windows. I’ll let you know how that went ;-)
> 
> Best
> Rainer
> 

Re: [bp-dev] Trace file/window remained empty

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

I have reproduced the problem here.  When I attempt to create a Csound 
score on the command line, BP console gets as far as time setting the 
last sequence (?) and then crashes:

3566 objects. Compression rate = 51  Sequence 11/11
Sizing objects
Setting limits
Placing objects
Solving constraints
Calculating global drift
Calculating legato/staccato
Segmentation fault: 11

When you don't get any output running a command from the PHP interface 
it may help to run it directly on the command line.

The crash log shows that this occurred in MakeSound() and the exception 
that caused the crash was

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000

I'm guessing that that is an attempt to access a null pointer.  I'm 
guessing that it is related to the use of script commands but I'll have 
to trace the problem in the debugger to be sure.

Interestingly, the segmentation fault does not occur if you run this 
grammar with --rtmidi instead of --csoundout.  Then the output continues 
after time setting:

3566 objects. Compression rate = 51  Sequence 11/11
Sizing objects
Setting limits
Placing objects
Solving constraints
Calculating global drift
Calculating legato/staccato
Ignoring script command: MIDI controller #98 = 1 channel 1
(Scripts do not work yet in the console version).
Ignoring script command: MIDI program 63
(Scripts do not work yet in the console version).
Ignoring script command: Beep
(Scripts do not work yet in the console version).
Ignoring script command: Wait for space
(Scripts do not work yet in the console version).
Ignoring script command: Tick cycle OFF
(Scripts do not work yet in the console version).

The fact that the very next message after where it seg faults for 
--csoundout is "Ignoring script command: MIDI controller #98" is 
evidence that my hunch is correct.

Nothing related to script commands currently works in BP console.  And 
the only other crash I have experienced with it so far had to do with 
loading a glossary file that I think began with "BP2 SCRIPT".  IIRC, I 
took some shortcuts to get the console version to compile in 2013 and I 
did not really finish substituting appropriate code everywhere for the 
non-functional script commands.

I will add fixing these crashes to my to do list.  Making script 
commands work in the console version is a large task though and I was 
not sure how important it is to do.  Certainly some of the script 
commands are no longer relevant (e.g. Freeze windows).  And I have the 
impression (which may not be correct) that many of the others duplicate 
functionality that can be achieved in other ways(??).

I'd like to hear what you think.

Anthony


On 7/22/20, 11:14 AM, Bernard Bel wrote:
> Dear Anthony,
>
> When I compile grammar “-gr.ShapesInRhythm” in the PHP interface, it
> says "no error".
>
> When producing a "BP data file" I get the (presumably correct) data on
> the Data window.
>
> However, attempting to produce a Csoud file ends up in an error.
> However, no messages have been produced and the Trace window remained empty.
>
> Note that this grammar does produce Csound (and MIDI) files on BP2.9.8
> although it asks the user to press the space key before doing it. This
> is due to instruction "_script(Wait for space)" which should be ignored
> in the context of creating a file.
>
> I guess that BP is not able to create Csound events reproducing
> performance parameters such as "_script(MIDI controller #98 = 1 channel
> 1)", but at least when it fails it should send a message to Trace.
>
> Maybe this will be solved by loading “-se.ShapesInRhythm.QTM” ?
>
> Bernard

[bp-dev] Bullets

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

Dear Anthony,

Back to the discussion of "bullets".

Now in grammar files saved by the PHP interface, bullets are replaced by 
"•" which makes no difference to the display on a web page.

An example is the attached "-gr.acceleration"

Nonetheless, its compilation produces an error telling the "bull;" is 
not a licit variable or whatever. So, the solution would be to identify 
"•" properly and map it to the same token as "•"

Unfortunately we have no 7-bit equivalent in BP, unlike "…" which now 
gets automatically converted as "_rest" rather than "…". Indeed, 
if you program the conversion of "•" you may be able to convert 
"…" as well!

Bernard


Bernard Bel wrote on 13/07/2020 16:22:

> 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 ‘•••’.

[bp-dev] Reformat grammars

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

Dear Anthony,

A few days ago I had suggested that when compiling a grammar we should 
get it in the fully formated format so that subgrammar numbers and rule 
numbers are explicit.

For instance the following grammar:

RND
S --> _chan(1) _vel(50) _volumecont _volume(80) 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


will be reformated as:

RND
gram#1[1] S --> _chan(1) _vel(50) _volumecont _volume(80) 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

Although BP does this automatically, it might have been a bit difficult 
to export the updated grammar to a temporary file and reload it to 
replace the original grammar.

For this reason I implemented reformat_grammar() in _basic_tasks.php 
that does the same. Less complicated that I had anticipated!

I checked the process by compiling a few old grammars to trace reserved 
words and everything that indicates that the current line is a rule and 
needs numbering.

By the way, old grammars would notate "GRAM" instead of "gram": a 
reminiscence of the Apple II version! ;-)

I also worked on the display of the Trace window. The console 
application saves its output to a Trace text file if requested to do it. 
But a display of the plain file on a browser window was incorrect 
because of MacOS Roman versus Unicode encodings. So, the interface now 
converts the text file to a HTML file with proper headers and correction 
of garbage signs. It's done by clean_up_file() on the same PHP page.

I am now working on the issue of dealing with the bullet period ‘•’ 
which is not accepted by the console application. The trick will be to 
save it as "•" and display it as a bullet.

As usual, the new version is on my site:
https://leti.lt/bolprocessor/

Bernard

[bp-dev] Autosave of object prototypes

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

Dear all,

In a previous message I mentioned the risk of missing changes in the 
settings of sound-object prototypes if the "SAVE" button had not been 
clicked on the "objects.php" window which loaded the "-mi" file.

This could also be worrying once the new BP produces sounds and a user 
wishes to immediately listen to the effet of modifying some parameters 
in an object.

This problem is solved :-)

I had already worked on an "autosave" procedure for people editing texts 
on line and forgetting to click the "save button". This is becoming 
frequent with those spoiled children working on Google docs. The 
"autosave" feature does exactly the same thing: once the "objects.php" 
has been open, it saves all its data every 20 seconds. You can safely 
work separately on sound-objects in various tabs.

I did a few more improvements on the interface. The best is to download 
it again from:

https://leti.lt/bolprocessor/

Bernard

[bp-dev] Trace file/window remained empty

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

Dear Anthony,

When I compile grammar “-gr.ShapesInRhythm” in the PHP interface, it 
says "no error".

When producing a "BP data file" I get the (presumably correct) data on 
the Data window.

However, attempting to produce a Csoud file ends up in an error. 
However, no messages have been produced and the Trace window remained empty.

Note that this grammar does produce Csound (and MIDI) files on BP2.9.8 
although it asks the user to press the space key before doing it. This 
is due to instruction "_script(Wait for space)" which should be ignored 
in the context of creating a file.

I guess that BP is not able to create Csound events reproducing 
performance parameters such as "_script(MIDI controller #98 = 1 channel 
1)", but at least when it fails it should send a message to Trace.

Maybe this will be solved by loading “-se.ShapesInRhythm.QTM” ?

Bernard

Re: [bp-dev] New PHP interface

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

I fixed a few small details on the PHP interface.

First, the "index.php" page cleans up every temp trace file or temp 
object prototypes folder if these are older than 24 hours and not 
created in the current session. (This might happen if your browser stays 
on while you are doing other things.)

Various problems are solved, among which the output file and format 
would be reset to "out.sco" and "Csound" when compiling the grammar or 
changing the output folder.

The Csound object prototype normally deals with all variables currently 
used by BP2.9.8. However I don't remember the meaning of “Tpict”, so it 
is displayed and cannot be changed. Probably dealing with the graphic 
interface.

I am also unable to calculate the standard duration of an object. 
Variable Tref is not the duration. I remember it is important but I need 
to look at the C code to remember its use.

File headers saved on the PHP interface all start with:

// Bol Processor BP3 compatible with version BP2.9.8

The important part is BP2.9.8 because when BP2.9.8 reads it, it will 
figure out that this is the format of the latest version, namely iv = 18 
if I rememember well. There is a table in the C code containing the 
names of all versions, and BP2.9.8 is the 18th entry.

This may be useful for making BP2.9.8 able to read the "-mi" files 
edited by the PHP code, so we can check in sounds and graphics that no 
parameter has been confused.

I said that the "objects.php" page is problematic because the "SAVE" 
button should be clicked after modifying parameters in some prototypes. 
There is a risk that changes be lost. I am working on an ‘autosave’ 
procedure that will record data changes every minute.

THat's all for the moment!  I am enclosing the 8 PHP files which have 
been modified.

Bernard Bel

Re: [bp-dev] New PHP interface

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

Dear Anthony,

I guess all these problems were related to file/folder permissions in 
your local "bolprocessor" folder.

Each time you load a page, the help file is recompiled. This is taken 
care of by compile_help($text_help_file,$html_help_file) on top of the" 
_basic_tasks.php" file. The source is "BP2_help.txt" and the result is 
"BP2_help.html" containing useful tags.

Once you have lodaded a grammar, clich "SHOW HELP ENTRIES" at the bottom 
right which will hilite reserved tokens and link them to entries on the 
Help window. Each entry opens its own small window, so you can put side 
by side explanations on  "_volumecont" and "_volume(x)" for instance. I 
modify "BP2_help.txt" form time to time to adjust the order of entries 
so that the longest prefix of a word appears at the bottom. So, 
"_volumecont" appears after its prefix "_volume" and will be first 
searched for on the grammar line. In BP2.9.8 you needed to type 
command-question mrk and click on the reserved word… This looks better!

Problem with that "sortie" directory is also probably one of write 
permissions. On top of grammar.php you can see that the output directory 
is automatically created if it does not exist. Well, I use the "mkdir" 
system command with no options, instead of PHP's own mkdir(). It might 
make the difference. Long ago I stopped using PHP mkdir() for a reason I 
have forgotten.

You might face a similar problem when editing a '-mi' file. If you edit 
"-mi.abc1" it immediately creates a "-mi.abc1_temp" folder at the same 
level as "-mi.abc1", then writes a text file in that folder containing 
the code for each prototype, i.e. "a.txt", "a'.txt", "chik.txt" etc. 
These are the files you will be modifying in separate tabaswhen editing 
each sound-object prototype. After you finished editing, go back to the 
tag created by opening "-mi.abc1" and click the "SAVE ‘-mi.abc1’" 
button. This will take all text files and pack them together as an 
updated "-mi.abc1".

I recommend working on a copy to try this! This makes it possible to 
edit a large collection of sound-object prototypes, each in its own tag, 
without rewriting the entire '-mi' file each time you changed a parameter.

I checked that saving a prototype after changing parameters maintains 
its consistency. For instance, if you had a dilation range permitted 
from 30% to 70% and you click the "Never rescale" option, then these 
values of dilatio ranges should be erased. I am still working on it to 
avoid accepting zero values in some places (e.g. Resolution).

I will add features clearing garbage each time the interface is used, 
for instance deleting trace files and these temporary folders used to 
store sound-object prototypes once they are more than 24 hour old. So, 
make sure that your environment will authorize PHP to do "rm" commands!

I have already fixed a few minor problems while writing this message. ;-)

You may write installation instructions so that the interface runs 
smoothly in a new environment. I have only experience with MAMP Pro. We 
should also try it on Unix and Windows machines…

Bernard

Anthony Kozar wrote on 22/07/2020 04:40:

> Dear Bernard,
>
> The interface looks & works great!  ^_^
>
> After I installed XAMPP for OS X, I followed your setup instructions. 
> The first time I loaded the interface, I had a bunch of warnings 
> because it could not open & write to the file php/BP2_help.html.  The 
> files are writable by their owner which was me because I dragged them 
> into the "htdocs" folder.  But the Apache server & PHP script run as 
> user "daemon".  This is probably just a naive mistake on my part.  I 
> was wondering why XAMPP includes an FTP server since it is running on 
> the local machine.  Perhaps I am supposed to use it to "upload" files 
> so that they get the right owner/group/permissions?
>
> Well, I just changed the owner manually and then the warnings went 
> away.  Things were working after that except that the interface could 
> not create the "sortie" directory.  After I created it, everything 
> works great!
>
> It's wonderful how one can browse the folders under /bolprocessor/ and 
> select any BP file to open or create a new grammar.  And I can have as 
> many files open as I want since each one opens in a new tab.
>
> I'm going to bed early tonight, so I'll write more tomorrow.
>
> Anthony 

Re: [bp-dev] New PHP interface

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

Dear Bernard,

The interface looks & works great!  ^_^

After I installed XAMPP for OS X, I followed your setup instructions. 
The first time I loaded the interface, I had a bunch of warnings because 
it could not open & write to the file php/BP2_help.html.  The files are 
writable by their owner which was me because I dragged them into the 
"htdocs" folder.  But the Apache server & PHP script run as user 
"daemon".  This is probably just a naive mistake on my part.  I was 
wondering why XAMPP includes an FTP server since it is running on the 
local machine.  Perhaps I am supposed to use it to "upload" files so 
that they get the right owner/group/permissions?

Well, I just changed the owner manually and then the warnings went away. 
  Things were working after that except that the interface could not 
create the "sortie" directory.  After I created it, everything works 
great! :)

It's wonderful how one can browse the folders under /bolprocessor/ and 
select any BP file to open or create a new grammar.  And I can have as 
many files open as I want since each one opens in a new tab. :)

I'm going to bed early tonight, so I'll write more tomorrow.

Anthony


On 7/21/20, 6:47 PM, Bernard Bel wrote:
> Dear colleagues,
>
> I uploaded a new version of the PHP interface “bolprocessor_php.zip”
> which works with all commands currently available. You will find it in
> this folder:
>
> https://leti.lt/bolprocessor/
>
> After unzipping, put the content into the "bolprocessor" folder at the
> root of your MAMP installation. In that folder you will have the
> "ctest", "data" and source files sent yesterday by Anthony. You probably
> need to recompile "bp"…
>
> This is a work in progress but it already gives an idea of a possible
> work environment for the new version. I used pop-up windows to create
> "consoles" containing the results of actions independently of tags
> containing the editable material.
>
> I have checked it on Chrome but I am confident that it works on other
> browsers irrespective of their security settings.
>
> Enjoy!
>
> Bernard Bel
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>

[bp-dev] New PHP interface

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

Dear colleagues,

I uploaded a new version of the PHP interface “bolprocessor_php.zip” 
which works with all commands currently available. You will find it in 
this folder:

https://leti.lt/bolprocessor/

After unzipping, put the content into the "bolprocessor" folder at the 
root of your MAMP installation. In that folder you will have the 
"ctest", "data" and source files sent yesterday by Anthony. You probably 
need to recompile "bp"…

This is a work in progress but it already gives an idea of a possible 
work environment for the new version. I used pop-up windows to create 
"consoles" containing the results of actions independently of tags 
containing the editable material.

I have checked it on Chrome but I am confident that it works on other 
browsers irrespective of their security settings.

Enjoy!

Bernard Bel

Re: [bp-dev] New BP console snapshot

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

Dear Bernard,

I'm very happy that you are pleased with the updates! :)  There is still 
lot to do, of course, but I feel like the console version is 
significantly more usable now.

I started working on LoadSettings() yesterday and I'm hoping to finish 
that today.  I think all of the various Load[something]() functions will 
go much easier than I thought since I can now just delete some of the 
Carbon GUI code.  All of the file input is nicely encapsulated in the 
functions ReadInteger(), ReadLong(), etc. so that I don't have to modify 
hundreds of FSRead() calls. :)

More below...

On 7/21/20, 9:22 AM, Bernard Bel wrote:
> Dear Anthony,
>
> I have tried all these commands. Everything works perfect, and I set up
> the interface to display output and/or trace files on separate windows.
>
> The interface reads the console output. If it finds an "Errors: 0" it
> offers displaying the output, otherwise it gives a warning and a link to
> the trace.

The screenshot looks great!  It had not occurred to me that you could 
display the various output stream in separate windows with the PHP 
interface.  You could almost recreate the Mac interface this way! ;)

> I have a suggestion regarding settings. In examples such as:
>
> ../bp64 compile --indian -gr.Nadaka
> ../bp64 produce --indian -gr.Nadaka
> ../bp64 produce-all produce-all.bpgr
> ../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout
> trace.txt --trace-production
>
> I don't need to select the options in the interface because they are in
> the "-se" file. The interface reads the "-se" file and tells that the
> options are set.
>
> Yet this is not a straightforward practice. I understand the interest in
> putting these options in the command line, but I don't think you will
> design such options for the 127 parameters set by the '-se' file. It
> seems better to read the '-se' file and apply its options…
>
> In case the option in the command line contradicts an option in the
> '-se' file, the command line instruction should have a priority.

Sounds good.  I was also thinking that some options could be specified 
in either an -se file or on the command line with priority given to the 
command line.  I definitely will not create command-line options for 
every parameter though!  I am choosing the ones that (a) help me test 
unique paths thru the code, and (b) that I think will be most useful to 
front ends or users who actually want to work directly with the console 
version.

Until you started creating editors for -se and -mi files in your 
interface, I was really thinking that it could be years before BP3 users 
on Catalina, Linux, or Windows would have good ways to edit all of the 
parameters.  But you are already solving those problems in only a few 
weeks time!  That is amazing.  I think it would take me MUCH longer to 
construct GUIs for editing those files in something like Java.  It will 
be wonderful for users to be able to use the PHP interface to create 
these "non-text" files even if they are running their projects on their 
local machines.

> The PHP interface will probably be shared tomorrow. I still need to
> complete a few details. I am enclosing the image of a production…

Great!  I will install MAMP and try it out.

I see now too how much value the PHP interface will have for any future 
front-end designers.  I was slow to appreciate the fact that many 
developers wanting to create a Bol Processor GUI will not be able to run 
the Carbon GUI to see how it worked.  Your PHP interface will definitely 
help to bridge that gap!

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

> "Zero byte(s) leaked". My favourite message.

I'll have to make sure that the final release versions print that 
message whenever they detect that you are the user ;)

> When time permits (no emergency) you might update BP2.9.8 to read at
> least ‘-se’ and ‘-mi’ files with the Unix line endings. This would make
> it possible to check changes via the sound output. Don’t bother about
> the saving format that can remain MacOS Roman, since it is automatically
> converted by the PHP interface.

That is a good idea.  I have been thinking that we will need an official 
2.9.9 release to include the changes that I made in 2013 plus anything 
else important that comes up while working on BP3.  Making sure that BP2 
can read the files created with your PHP interface falls into that category.

> Probably my next work on the interface will be the edition of ‘-cs’
> Csound orchestra files.

That's a big job too.  I've had some ideas for a while for a more 
compact interface design for the Csound instruments.  I would like to 
eventually create a Java app for editing them.  Maybe I can create a 
mockup of the interface though to share my ideas.

Thanks, as always, for the feedback!

Anthony

Re: [bp-dev] Path of grammar

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

Yes, I haven't gotten around to fixing that although it should be very easy.

But you don't have to use chdir().  You'll note that the error message 
from BP console tells you how to fix it! ;-)

 > If '/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich' is an
 > input file, indicate the file type (eg. -gr
 > /Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich).

Just put "-gr " (with a space) in front of the full pathname.

Anthony


On 7/21/20, 2:57 AM, Bernard Bel wrote:
> Still a small problem trying to do:
>
> /Applications/MAMP/htdocs/bolprocessor/bp compile
> /Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich --traceout
> trace.txt
>
> It generated these messages:
>
> -----------
> Bol Processor console app
> Version 2.999... (Jul 20 2020)
> This is a beta version for evaluation...
>
> Unknown action '/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich'
> If '/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich' is an
> input file, indicate the file type (eg. -gr
> /Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich).
> Use '/Applications/MAMP/htdocs/bolprocessor/bp --help' to see help
> information.
> -----------
>
> This means that BP isn't yet able to recognize
> /Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich
>
> as a grammar path, and it complains that the "action" is incorrect.
>
> We can bypass this limitation doing a chdir() to the folder containing
> the grammar, and it does work, but this might not be good practice in
> all situations…
>
> Bernard

Re: [bp-dev] New BP console snapshot

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

Dear Anthony,

I have tried all these commands. Everything works perfect, and I set up 
the interface to display output and/or trace files on separate windows.

The interface reads the console output. If it finds an "Errors: 0" it 
offers displaying the output, otherwise it gives a warning and a link to 
the trace.

I have a suggestion regarding settings. In examples such as:

../bp64 compile --indian -gr.Nadaka
../bp64 produce --indian -gr.Nadaka
../bp64 produce-all produce-all.bpgr
../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout 
trace.txt --trace-production

I don't need to select the options in the interface because they are in 
the "-se" file. The interface reads the "-se" file and tells that the 
options are set.

Yet this is not a straightforward practice. I understand the interest in 
putting these options in the command line, but I don't think you will 
design such options for the 127 parameters set by the '-se' file. It 
seems better to read the '-se' file and apply its options…

In case the option in the command line contradicts an option in the 
'-se' file, the command line instruction should have a priority.

The PHP interface will probably be shared tomorrow. I still need to 
complete a few details. I am enclosing the image of a production…

I believe the MIDI file output should not be a big deal because BP2.9.8 
was writing them directly.

Bernard

Anthony Kozar wrote on 20/07/2020 20:49:
> 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
> ../bp32 produce -gr.NotReich -d --csoundout -
> ../bp32 produce -gr.NotReich -d --csoundout out.sco
> 
> ../bp64 templates -gr.checktemplates --traceout trace.txt
> 
> // the next command will generate some compilation errors
> ../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
> 
> // 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

Re: [bp-dev] Path of grammar

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

Still a small problem trying to do:

/Applications/MAMP/htdocs/bolprocessor/bp compile 
/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich --traceout 
trace.txt

It generated these messages:

-----------
Bol Processor console app
Version 2.999... (Jul 20 2020)
This is a beta version for evaluation...

Unknown action '/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich'
If '/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich' is an 
input file, indicate the file type (eg. -gr 
/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich).
Use '/Applications/MAMP/htdocs/bolprocessor/bp --help' to see help 
information.
-----------

This means that BP isn't yet able to recognize
/Applications/MAMP/htdocs/bolprocessor/ctests/-gr.NotReich

as a grammar path, and it complains that the "action" is incorrect.

We can bypass this limitation doing a chdir() to the folder containing 
the grammar, and it does work, but this might not be good practice in 
all situations…

Bernard


Anthony Kozar wrote on 20/07/2020 20:49:
> Hello everyone,
> 
> I've uploaded a new snapshot of my development folder to my website. 
> Just download and unzip the file "bpconsole-2020-07-20.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
> -----------------------
> • Makefile included
> • the action argument is now required on the command line; all actions 
> listed in the command line help are recognized but only these actions 
> work: compile, produce, produce-all, templates
> • the --csoundout option now works as advertised. It requires a file 
> name for the output score or "-" to print to stdout.
> • a default f-table statement is now written into the score file.
> • --midiout now requires an argument but a Midi file is still not produced.
> • implemented -o option for writing produced items to a file
> • new option --seed [num] for setting the random number seed
> • new options --show-production and --trace-production
> • all messages are now directed to standard output by default instead of 
> standard error
> • new options -e or --use-stderr redirect messages to standard error, 
> allowing you to get just the "algorithmic output" on standard out
> • new option '--traceout [filename]' for routing compilation errors and 
> trace outputs to a trace file
> • console output has been cleaned up a lot
> • can read input files with any line ending convention (please let me 
> know if this doesn't always work)
> • changed the version number to "2.999..."
> 
> The --traceout option is recommended right now for viewing compilation 
> errors, the output of the "templates" action, or when --show-production 
> & --trace-production are used.  Currently, the output of all of these 
> processes still contain carriage returns and will not display properly 
> in a terminal.  --traceout will route them to a file which you can then 
> open in a text editor that is "CR-aware".
> 
> 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
> ../bp32 produce -gr.NotReich -d --csoundout -
> ../bp32 produce -gr.NotReich -d --csoundout out.sco
> 
> ../bp64 templates -gr.checktemplates --traceout trace.txt
> 
> // the next command will generate some compilation errors
> ../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
> 
> // 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
> 
> 
> 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 BP console snapshot

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

Amazing work!

I compiled and ran the new version (creating a Csound score).

Messages on the console were perfect. The out.sco and NotReich.bpda look 
good. Double-clicking "NotReich.bpda" even opened it in BP2.9.8 (with 
just an expected garbage sign at the end) and it played it on the piano!

"Zero byte(s) leaked". My favourite message. :-)

Today I will adjust the PHP interface to the new syntax and share it.

I spent 3 days on the sound-object prototype (‘-mi’ file) editor. So 
many parameters requiring to be checked one by one to avoid any 
confusion. An error might take a while to be detected! In addition, the 
interface must check the consistency of some combinations as the old 
good BP2.9.8 was doing…

When time permits (no emergency) you might update BP2.9.8 to read at 
least ‘-se’ and ‘-mi’ files with the Unix line endings. This would make 
it possible to check changes via the sound output. Don’t bother about 
the saving format that can remain MacOS Roman, since it is automatically 
converted by the PHP interface.

Probably my next work on the interface will be the edition of ‘-cs’ 
Csound orchestra files.

We're moving forward nicely :-)

Bernard

Anthony Kozar wrote on 20/07/2020 20:49:
> Hello everyone,
> 
> I've uploaded a new snapshot of my development folder to my website. 
> Just download and unzip the file "bpconsole-2020-07-20.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
> -----------------------
> • Makefile included
> • the action argument is now required on the command line; all actions 
> listed in the command line help are recognized but only these actions 
> work: compile, produce, produce-all, templates
> • the --csoundout option now works as advertised. It requires a file 
> name for the output score or "-" to print to stdout.
> • a default f-table statement is now written into the score file.
> • --midiout now requires an argument but a Midi file is still not produced.
> • implemented -o option for writing produced items to a file
> • new option --seed [num] for setting the random number seed
> • new options --show-production and --trace-production
> • all messages are now directed to standard output by default instead of 
> standard error
> • new options -e or --use-stderr redirect messages to standard error, 
> allowing you to get just the "algorithmic output" on standard out
> • new option '--traceout [filename]' for routing compilation errors and 
> trace outputs to a trace file
> • console output has been cleaned up a lot
> • can read input files with any line ending convention (please let me 
> know if this doesn't always work)
> • changed the version number to "2.999..."
> 
> The --traceout option is recommended right now for viewing compilation 
> errors, the output of the "templates" action, or when --show-production 
> & --trace-production are used.  Currently, the output of all of these 
> processes still contain carriage returns and will not display properly 
> in a terminal.  --traceout will route them to a file which you can then 
> open in a text editor that is "CR-aware".
> 
> 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
> ../bp32 produce -gr.NotReich -d --csoundout -
> ../bp32 produce -gr.NotReich -d --csoundout out.sco
> 
> ../bp64 templates -gr.checktemplates --traceout trace.txt
> 
> // the next command will generate some compilation errors
> ../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
> 
> // 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
> 
> 
> 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