bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] GitHub migration

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

Comments below.

On 9/30/20, 3:21 PM, Rainer Schuetz wrote:

> I didn’t think Anthony would go ahead that quickly with the
> organisation, but I like it.

:)  I've been thinking about this since August or July and Bernard gave 
the "thumbs up" so I thought I'd run with the idea.

I've pushed all of my local branches to the new repository along with 
the tags for old releases.  GitHub automatically created source packages 
for each tag.  I added some info to the BP 2.9.8 tag so that it shows up 
as the "latest release" and there are links to the download pages for 
the application package on the new website and Sourceforge.  (We don't 
want people finding only the source code packages on GitHub and 
wondering what they are supposed to do with them...)

> In advanced collaboration workflows including an organisation people
> usually maintain a private version of a repo that mirrors the one in
> the organisation (a “fork"). The typical/recommended workflow is that
> you fork the repo of the organisation through the web-interface to
> your own Github account and then set that “fork” up as your primary
> remote (“origin”) for your daily work -

I will probably do this for my own work on the BP2/3 repository.  But 
you and Bernard are welcome to do whatever you are comfortable with.

> In larger organisations with multiple contributors, some authors,
> some not, and different degrees of privileges, there are often
> recommended workflows, even compulsory policies, that define how
> these things should be done.

I am going to suggest a policy for managing the main repository. 
Currently, the main branches and their statuses are

   master       BP2 GUI code matching the August 15, 2013 preview release
   ANSI-branch  latest BP3 development code that compiles and "works"

I also pushed two other branches, one with some experimental changes to 
BP2 and another with the in-progress CoreMIDI driver for BP3.

GitHub is showing the "master" branch by default.  We can set the 
default branch to any branch we want, but "master" is the standard name 
for the current stable branch.  When new users find the project and want 
to compile it themselves, this is the branch they are most likely to try 
first.  So I suggest the following branch strategy.

   master       current stable release (currently BP2 GUI, but BP3 soon)
   BP3-develop  latest working code for BP3 console
   BP2-develop  latest working code for BP2 GUI
   BP2-stable   future branch for last stable release of BP2 GUI

I'll rename the ANSI-branch to BP3-develop soon and create the 
BP2-stable branch after BP3 is released.  I suggest that we all try to 
make sure that code pushed to these four (remote) branches always 
compiles and "works".  When working on code that may not compile or on 
new features that will take a while to complete, I suggest that we work 
in separate branches from the four above.  You are welcome to push your 
personal development branches to GitHub as a remote backup of your local 
copy but use branches with other names (or push to your own fork of the 
repository).

For example, when I started working on updating the CoreMIDI driver, I 
created a new branch off of ANSI-branch called "CoreMIDI-for-BP3".  That 
way I could break anything I needed to break and try different solutions 
without making ANSI-branch unusable for others.  When I am finished with 
that feature and everything works again, I will merge the 
CoreMIDI-for-BP3 branch back into ANSI-branch (or BP3-develop if I've 
renamed it).

Whenever a new release is made, the development branch should be merged 
with the matching stable branch.  So, when a new BP2 release is made, 
BP2-develop would be merged with BP2-stable.  When a BP3 release is 
made, BP3-develop would be merged with master.

Does this sound like a reasonable strategy/policy?

> I am pretty sure you want to totally ignore that option, in which
> case it’s better to create your remote directly in the organisation.
> Just keep in mind that there are alternative models of maintaining
> repos in an organisations, and that most expect two remotes: the
> central, “official” repo and a private fork

For now, I'm thinking we will keep the Sourceforge repo as the central, 
"official" one but do most of our development in the GitHub repo as well 
as accept pull requests there.  I will periodically sync the four main 
branches of the GitHub copy to Sourceforge so that no matter where 
people find us they can get up-to-date code.  This way, if a new 
enthusiastic developer comes along, we can feel free to add them to the 
GitHub organization and give them push access to one or more 
repositories but still sleep soundly at night. ;-)

> Once both repos are set up in the organisation, I’ll delete my current
> one and use the organisations repos. If a .gitignore-file is enough to
> fold both repos into each other in the workspace, I’ll give you a first
> exposure at pull-requests in your repo ;-)

You can probably add https://github.com/bolprocessor/bolprocessor as an 
additional remote for your local copy of bagong/bolprocessor and merge 
between the two to update your personal repo (if desired).  Note that 
there is no "ctests" folder in the main repository yet and as Bernard 
suggested we should give some thought to how to organize our test files.

If the PHP interface needs to be in the "bolprocessor" folder, then it 
probably should be added as a submodule -- i.e. a reference to a 
specific commit in the php-frontend repository.  That would avoid any 
duplication of code or history between the php-frontend and bolprocessor 
repositories.

https://www.git-scm.com/book/en/v2/Git-Tools-Submodules

Thanks for your suggestions and help, Rainer!

Anthony

[bp-dev] Scripts

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

Dear all,

Scripts start working on the PHP interface… Look at attached picture!

The "CHECK THIS SCRIPT" button verifies the syntax and indicates which 
instructions are valid, obsolete, or forthcoming (in development).

"Add script instruction" buttons copy the selected instruction to the 
script, thereby avoiding typing mistakes.

"RUN THIS SCRIPT" launches the script on a pop-up window.

This example shows instructions "Type" which outputs text and "Play" 
which calls the Play command on the console, having stored the itemin a 
temporary "outdata.bpda" file.

It also takes into account the note convention.

A script can call subscripts if these are stored in the same folder.

Bernard

Re: [bp-dev] GitHub migration

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

Yes, we can share BP1 program and data disks. It would be great to 
include the separated files!

Maybe add the BigMac compiler (attached disk image) because it works 
fine — even though I have forgotten detailed operation. It reads the 
6502 source files. I don't remember how BP1 data files had been encoded…

QAVAID also can be shared even though it works on the antique Prolog II. 
Let all this be free access! :-)

I renamed the repository of the PHP interface as suggested by Rainer:

https://github.com/bolprocessor/php-frontend

Bernard

Anthony Kozar wrote on 30/09/2020 21:18:
> Excellent. :)
>
> Should I create new repositories for the BP2 manual, QAVAID, and BP1?
>
> Is it OK to make all three of those things public on GitHub?
>
> Is it OK to include the BP1 data disks along with the binaries and 
> source?
>
> Back in August, I made a first attempt at extracting the individual 
> files from the BP1 disk images.  The BASIC programs and the assembler 
> source code extracted as plain text files with the Apple Commander 
> program, which is great.  I think it detokenized the BASIC code to 
> achieve this.  Unfortunately, it also converted the binary executables 
> and data files into plain text files containing hexadecimal dumps of 
> the data.  I may just need to try again with different options.  Or I 
> may need a different tool to extract those files.
>
> Anyways, if it's OK to make a BP1 repository, I will include both the 
> Apple II disk images and the individual files from those disks so that 
> they can be edited on modern machines. :)
>
> Anthony
>
>
> On 9/30/20, 2:54 PM, Bernard Bel wrote:
>> I've done the transfer. Ready for the upload!
>>
>> Bernard
>>
>> Anthony Kozar wrote on 30/09/2020 20:40:
>>> Welcome Bernard and Rainer to the new BP GitHub organization! :)
>>>
>>> Yes.  If you want the PHP repository to be under the Bol Processor
>>> organization instead of your personal account, then you can transfer
>>> it from the repository's settings page.
>>>
>>> Visit your repository and click "Settings" in the navigation bar
>>> underneath the repository name.  Then scroll all of the way down to
>>> the bottom of the page.  You should see a section like in the attached
>>> image.  Choose "transfer" and enter "bolprocessor" for the new owner.
>>>
>>> Good luck with setting up the PHP repository!  Rainer's instructions
>>> and explanations look very good. (Thanks, Rainer, for being so
>>> thorough! :)  I can always try to answer questions that come up too.
>>>
>>> Anthony
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] GitHub migration

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

Haha, I missed your posts concerning “transfer” - that’s even easier.

Best
.r.

Re: [bp-dev] GitHub migration

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

> On 30. Sep 2020, at 20:13, Bernard Bel <ber...@gm...> wrote:
> 
> Dear Rainer,
> 
> I will do the uploading to-morrow.  Your explanations will be fabulous help!
> 
> At the moment I am worried that the URL of the repository contains my name:
> https://github.com/belbernard/bolprocessor-php
> 
> Anthony created a repository with a neutral URL:
> https://github.com/belbernard/bolprocessor-php
> 
> Can we fix this?


Your second link is the same as the first - but I think another way of expressing what you hope to achieve is to say “placing the bolprocessor-php repo in the organisation", which would result in the link:

    https://github.com/bolprocessor/bolprocessor-php <https://github.com/bolprocessor/bolprocessor-php>

You might also consider calling the repo php-frontend or something like that in the context of the organisation, which would make the link

    https://github.com/bolprocessor/php-frontend <https://github.com/bolprocessor/php-frontend>

With an optional .git at the end.

Placing your repo in the organisation (with whichever name) at the current stage is better, I think. Maybe the easiest way so that most of what I wrote remains applicable is to re-create a fresh repo in the organisation (you’ll find the button when you visit the organisations page, but basically it’s the same you already did in your own account). Then use the new link for the cloning (you can then delete the repo in your own account through the web-interface (it’s a button in the repo's “settings"), just for cleanliness, you can recreate a private copy (fork) of the organisations repo at any time with the press of a button). I didn’t think Anthony would go ahead that quickly with the organisation, but I like it.

In advanced collaboration workflows including an organisation people usually maintain a private version of a repo that mirrors the one in the organisation (a “fork"). The typical/recommended workflow is that you fork the repo of the organisation through the web-interface to your own Github account and then set that “fork” up as your primary remote (“origin”) for your daily work - and then you sync the changes in your “private remote” to the organisation's repo (which would be a secondary remote for you). There are various ways to do this syncing. In larger organisations with multiple contributors, some authors, some not, and different degrees of privileges, there are often recommended workflows, even compulsory policies, that define how these things should be done. One way if people want to make sure that things are discussed before they “become official” is to allow commits to the organisations main repo through pull-requests only, even for maintainers. Making pull requests requires a forked repo. BUT: I think at the size of this organisation, the trust level between the contributors/authors (“total”), and your degree of conversance with git (“limited” ;-) ) I am pretty sure you want to totally ignore that option, in which case it’s better to create your remote directly in the organisation. Just keep in mind that there are alternative models of maintaining repos in an organisations, and that most expect two remotes: the central, “official” repo and a private fork (“forking” as a word has lost the flavour of “taking away and doing your own thing” it used to have, forking is just creating a working copy, a way to facilitate organised collaboration. Most repos invite you to fork them and and are happy to see that happen).

Once both repos are set up in the organisation, I’ll delete my current one and use the organisations repos. If a .gitignore-file is enough to fold both repos into each other in the workspace, I’ll give you a first exposure at pull-requests in your repo ;-)

Looking forward to things!
Best
.r.

Re: [bp-dev] GitHub migration

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

Excellent. :)

Should I create new repositories for the BP2 manual, QAVAID, and BP1?

Is it OK to make all three of those things public on GitHub?

Is it OK to include the BP1 data disks along with the binaries and source?

Back in August, I made a first attempt at extracting the individual 
files from the BP1 disk images.  The BASIC programs and the assembler 
source code extracted as plain text files with the Apple Commander 
program, which is great.  I think it detokenized the BASIC code to 
achieve this.  Unfortunately, it also converted the binary executables 
and data files into plain text files containing hexadecimal dumps of the 
data.  I may just need to try again with different options.  Or I may 
need a different tool to extract those files.

Anyways, if it's OK to make a BP1 repository, I will include both the 
Apple II disk images and the individual files from those disks so that 
they can be edited on modern machines. :)

Anthony


On 9/30/20, 2:54 PM, Bernard Bel wrote:
> I've done the transfer. Ready for the upload!
>
> Bernard
>
> Anthony Kozar wrote on 30/09/2020 20:40:
>> Welcome Bernard and Rainer to the new BP GitHub organization! :)
>>
>> Yes.  If you want the PHP repository to be under the Bol Processor
>> organization instead of your personal account, then you can transfer
>> it from the repository's settings page.
>>
>> Visit your repository and click "Settings" in the navigation bar
>> underneath the repository name.  Then scroll all of the way down to
>> the bottom of the page.  You should see a section like in the attached
>> image.  Choose "transfer" and enter "bolprocessor" for the new owner.
>>
>> Good luck with setting up the PHP repository!  Rainer's instructions
>> and explanations look very good. (Thanks, Rainer, for being so
>> thorough! :)  I can always try to answer questions that come up too.
>>
>> Anthony

Re: [bp-dev] GitHub migration

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

I've done the transfer. Ready for the upload!

Bernard

Anthony Kozar wrote on 30/09/2020 20:40:
> Welcome Bernard and Rainer to the new BP GitHub organization! :)
>
> Yes.  If you want the PHP repository to be under the Bol Processor 
> organization instead of your personal account, then you can transfer 
> it from the repository's settings page.
>
> Visit your repository and click "Settings" in the navigation bar 
> underneath the repository name.  Then scroll all of the way down to 
> the bottom of the page.  You should see a section like in the attached 
> image.  Choose "transfer" and enter "bolprocessor" for the new owner.
>
> Good luck with setting up the PHP repository!  Rainer's instructions 
> and explanations look very good. (Thanks, Rainer, for being so 
> thorough! :)  I can always try to answer questions that come up too.
>
> Anthony
>
>
> On 9/30/20, 2:13 PM, Bernard Bel wrote:
>> Dear Rainer,
>>
>> I will do the uploading to-morrow.  Your explanations will be 
>> fabulous help!
>>
>> At the moment I am worried that the URL of the repository contains my 
>> name:
>> https://github.com/belbernard/bolprocessor-php
>>
>> Anthony created a repository with a neutral URL:
>> https://github.com/belbernard/bolprocessor-php
>>
>> Can we fix this?
>>
>> Bernard
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] GitHub migration

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

Welcome Bernard and Rainer to the new BP GitHub organization! :)

Yes.  If you want the PHP repository to be under the Bol Processor 
organization instead of your personal account, then you can transfer it 
from the repository's settings page.

Visit your repository and click "Settings" in the navigation bar 
underneath the repository name.  Then scroll all of the way down to the 
bottom of the page.  You should see a section like in the attached 
image.  Choose "transfer" and enter "bolprocessor" for the new owner.

Good luck with setting up the PHP repository!  Rainer's instructions and 
explanations look very good. (Thanks, Rainer, for being so thorough! :) 
  I can always try to answer questions that come up too.

Anthony


On 9/30/20, 2:13 PM, Bernard Bel wrote:
> Dear Rainer,
>
> I will do the uploading to-morrow.  Your explanations will be fabulous help!
>
> At the moment I am worried that the URL of the repository contains my name:
> https://github.com/belbernard/bolprocessor-php
>
> Anthony created a repository with a neutral URL:
> https://github.com/belbernard/bolprocessor-php
>
> Can we fix this?
>
> Bernard

Re: [bp-dev] GitHub migration

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

Dear Rainer,

I will do the uploading to-morrow.  Your explanations will be fabulous help!

At the moment I am worried that the URL of the repository contains my name:
https://github.com/belbernard/bolprocessor-php

Anthony created a repository with a neutral URL:
https://github.com/belbernard/bolprocessor-php

Can we fix this?

Bernard


Rainer Schuetz wrote on 30/09/2020 13:37:
> Dear Bernard,
> 
> Fab! I am not an expert at all myself but I’ll try my best to take your 
> hand until things have settled ;-) My own memory of git has faded a bit, 
> but fortunately I can look up things easily on the web. Once one is able 
> to put questions in the right words, almost everything is answered well 
> out there… Let me add this at the outset: anything we run into can be 
> changed, undone etc… Deleting a Github repo takes two minutes and 
> setting it up again 5….
> 
> 
>> Now I created this repository: 
>> https://github.com/belbernard/bolprocessor-php
>> and a small README file. It will contain exclusively the PHP interface.
> 
> Okay, let’s take this as given. I’ll give you the concrete steps with a 
> few explanations to get going first, and we can discuss the implications 
> later when problems arise or questions pose themselves. I am assuming 
> you do this on the command-line.
> 
> But first, before you actually start, let’s get identity straight: there 
> are two levels to this: one is that you tell git how you identify as an 
> author. This requires a “name” and an email address. You’re free to 
> chose what you like here, this is not bound to your Github account. The 
> other level are the credentials you use to show Github that you have the 
> right to access the repo and write to it. The later will be asked from 
> you when you try to push to GitHub. So let’s get that authorship id out 
> of the way: when you start this is usually done on the “global” git 
> configuration level (global is not as global as it sounds, there is also 
> “system” and "local”. Global is the default in your userspace, it could 
> be overwritten with “local”). The config information is stored in a file 
> in your $HOME directory, called .gitconfig. You can edit that file, or 
> add entries with git commands. This is mine .gitconfig:
> 
> 
> 
> 
> You can also add the entries with git-commands:
> 
>      git config --global user.name "whatever you chose to appear as author"
>      git config --global user.email "the email address that will be 
> visibly associated with your authorship”
> 
> 
> Now let's “clone” the rep you created into your local environment (this 
> will create the folder coprocessor-php in the folder you are, so mind a 
> potential conflict):
> 
>      git clone https://github.com/belbernard/bolprocessor-php
> 
> You can actually tell git to clone into a folder of a different name (or 
> you can later rename the folder, git doesn’t care about the parent 
> folder name):
> 
>      git clone https://github.com/belbernard/bolprocessor-php bolprocessor
> 
> Once that’s done you’ll have an almost empty folder, it contains the 
> Readme, License and most importantly: a hidden folder .git that contains 
> all the current information about the repo. In theory you could delete 
> all files in your folder (e.g. accidentally) *except that .git folder* 
> and reinstate the entire repo by having git reconstruct them from the 
> info in .git (the command would be `git checkout *`). `git init` creates 
> that .git folder (but without any version-control-information, when you 
> start!).
> 
> Now come the crucial steps: you want to add your files to the (that ;-)) 
> repo: taking files under version control should be thought of, I think, 
> as having two steps: the first is to “add” the files (or to stage them), 
> and the second is to “commit” them. Only what is committed has ended up 
> under version control or is uploaded if you push. Splitting the process 
> into two steps might seem like a nuisance at first, but it allows you to 
> organise your commits, remove files again from the stage if you changed 
> your mind, keep spontaneous/temporary changes (“untracked” files and 
> folders) separate from stuff that is considered a candidate to be 
> committed. And once you think you aggregated a nice bunch of changes you 
> can commit them as a meaningful unit. Commit will commit everything that 
> is staged and none of the “untracked files"
> 
> So extract your snapshot into that folder and think of it as creating 
> the files you will want to add, and subsequently commit and then push to 
> your remote repo. You want all the files of the snapshot in the right 
> location and nothing else for now (so after getting the files in place 
> delete the .zip ’n further artefacts that might have appeared as 
> sideffect of extracting the snapshot).
> 
> You might want to have a look at what git thinks you’ve changed so far. 
> It’s basically a diff of the repo-state stored in the .git folder and 
> the current folder state:
> 
>      git status
> 
> It should give you a short list of files and the folder php/ listing 
> them as “untracked files"
> 
> 
> 
> If you’re like me and hate those hidden system-files like .DS_Store you 
> might want to add that exclusion list right away that I mentioned the 
> other day. It’s a file called “.gitignore” residing in the root folder 
> of your repo. You can freely edit it, every entry is a line. To exclude 
> .DS_Store just add it as a line in a file called .gitignore. The result 
> (`git status`) should look like this:
> 
> 
> 
> The gitignore file could at some point get quite long, it might even be 
> possible to include Anthony’s repo in that file and exclude it from 
> version control… I haven’t fully thought it through, but it could be a 
> simple way to keep you working environment, which I assume is having 
> both Anthony’s and your files in a shared parent folder. Note that you 
> can rename the parent folder, git only looks inside of it. But that’s 
> for another day, right? Just keep in mind that .gitignore is maintained 
> like any other file in the repo. If you change it, it will “work” right 
> away, but if you’d like it to be available for anybody you need to add, 
> commit and push it. If you just want it for yourself, you could add 
> .gitignore to .gitignore and git wouldn’t remind you of it any more.
> 
> Now you’re ready to add the whole bunch using kind of a regex (or a glob 
> expression, I am not sure, anyways “.” is "all"):
> 
>      git add .
> 
> If you run `git status` again it’s shows you what it did, it should have 
> “added" all files ’n folders to the “stage”:
> 
> 
> 
> Now you’re ready to commit. A commit requires a commit message, and you 
> can add it with -m, so that git doesn’t open a text-editor for you (this 
> editor thing might be confusing. Not sure if you’re used to a specific 
> editor on the command line, it might be helpful to configure that - but 
> for now you can avoid the editor by adding the commit message with -m). 
> The commit message can be anything you chose. Some people warn it’s 
> important to be considerate about it ;-)
> 
>      git commit -m "Initial commit php-interface for bp3”
> 
> Git status will tell you now that the repo has caught up with the folder 
> state, *and* that it has overtaken the remote repo by one commit:
> 
> 
> 
> At that point you’re ready to push:
> 
>      git push
> 
> Note that when you cloned the repo git protocolled the remote you used. 
> As long as you only have one remote repo, git will use it as the target 
> destination. In multi-repo setups (e.g. private repo and Organisation 
> repo you might need to configure the default remote or make it explicit 
> on the command line).
> 
> At this point it should ask you for your Github credentials and store 
> them somewhere. Hopefully it won’t ask you each time you push, otherwise 
> some more configuration might become necessary. Github also provides a 
> way to store ssh-keys, similar to what you might have done with your 
> web-provider, so I am pretty sure you’ll get over this.
> 
> Fingers crossed your initial commit was uploaded to Github, you should 
> be able to see it on the Github-site, Github is usually very fast in 
> updating the repo-state on the site.
> 
> From now on - as long as things remain basic - i.e. you only have one 
> remote, and you only need one-way synching because you’re the only one 
> that commits - you just need to get used to going through that “make 
> untracked changes (edit something or create a file) - stage (git add …) 
> - commit (git commit -m “…”) and upload (git push)” cycle to keep the 
> public version of your repo in sync with the local one (some people skip 
> add by doing “git commit -am “…”, but that’s considered careless ;-) ). 
> All these commands have many options and you can use globs ’n stuff in 
> many places, so there is a lot to learn if one wants (most interesting 
> maybe branches, that give you a space to explore stuff without messing 
> with the main development thread). But the basic cycle can be handled 
> like that. A nice thing about git is that it’s quite smart about what 
> you might want to do, and it tells you stuff like that you can do “git 
> restore —staged <file>” after you added or “git push” after you 
> commited. Some of these terms likely require some Googling, but 
> generally speaking git is amazingly well documented on all levels. 
> Undoing local commits is also possible in various ways (git reset with 
> various options like —soft, —hard and more). The hairy thing you want to 
> avoid is undoing commits that have already been pushed. As long as 
> you’re alone, even that is still possible, but it requires more 
> commands. Git wants you to avoid this, because if multiple users share a 
> remote and you keep deleting stuff from the remote, synching problems 
> are very likely to occur. The general git philosophy, I’d say is - 
> rather than undo/delete stuff, add such changes on top as well. They’ll 
> be visible in history then, but you avoid synching problems.
> 
> I am happy to answer questions that come up (but maybe we better do that 
> with private email)
> 
> Best
> .r.
> 
> 
> 
>>
>> I chose "GNU General Public License v3.0" which should be ok for 
>> our approach.
>>
>> Now, looking at https://guides.github.com/activities/hello-world/ , 
>> I guess that I should push all current files (the content 
>> of bolprocessor_php.zip) into this "master" branch, and thereafter 
>> create a new "work" branch to push next versions… Is this the case ? I 
>> am careful because there seems to be no "undo" for dummies…
>>
>> One more thing: if I push the zip file, will it deflate on its own?
>>
>> In the Terminal I went to the work folder and did "git init" as 
>> you suggested. Now, "ls -l" yields:
>>
>> drwxr-xr-x@ 10 bernardbel  staff     340 29 sep 15:41 .git
>> -rw-r--r--@  1 bernardbel  staff  181679 22 jul 00:19 BP2_help.txt
>> -rw----r--@  1 bernardbel  staff     166 25 sep 09:54 compile.php
>> drwxr-xr-x@ 44 bernardbel  staff    1496 29 sep 14:17 php
>>
>> What should I do next?
>>
>> I will also think about the structure you are discussing below. The 
>> main point is that for the time being we are sharing a version of 
>> the package designed to run under MAMP or a similar local server. The 
>> next stage might be to install it as an on-line service, but 
>> developers joining the project would still run their new versions on 
>> local servers.
>>
>> So, until we have a standalone application (rendering the PHP 
>> interface obsolete) the installation procedure will remain the one 
>> described on top of https://bolprocessor.org/misc/BP3/CheckList.html. 
>> The only complication is that both Anthony and I are delivering a 
>> "bolprocessor" folder and their contents should be merged. As 
>> you suggested, the console's folder could be named "console" and put 
>> inside the "bolprocessor" folder at the same level as "php". I Anthony 
>> agrees with this change, he may change the folder's name to "console" 
>> or "bp_console" whatever…
>>
>> Bernard
>>
>> Rainer Schuetz wrote on 29/09/2020 14:19:
>>>
>>>
>>>> On 29. Sep 2020, at 06:53, Bernard Bel <ber...@gm...> wrote:
>>>>
>>>> So, when the whole project moves to GitHub you could take 
>>>> the current version of the interface as an initial version.
>>>
>>> Okay!
>>>
>>>> I am now planning genuine developments such as running scripts via 
>>>> the interface — i.e. translating their actions to commands sent 
>>>> to the console.  This will be worth following stepwise.
>>>
>>> Good! This feels to me like the ideal moment for you to start 
>>> switching to the git workflow yourself - it would only require you to 
>>> run “git init” in your development folder, create a 
>>> Github account and push to it, Github even guides through the steps.
>>>
>>> But if you’re not comfortable jumping off right now: how about 
>>> creating a Github account for you and I push to a repo there 
>>> - ideally borrowing your identity temporarily, as that would 
>>> allow commits to appear with proper authorship assignment. Once 
>>> you’re happy to take over, you just need to “pull” into a new folder 
>>> and can maintain things yourself. And pushing a commit is less work 
>>> than creating an archive, uploading to a server and sending emails 
>>> ;-) And once the organisation is created, the repo can be moved in 
>>> with proper authorship-assignment and history as intended.
>>>
>>>> We will also need to figure out a procedure for sharing examples of 
>>>> grammars, data, scripts etc. used for checking the software or 
>>>> constructing tutorials. Up to now we use the "ctests" folder but it 
>>>> is not systematic.
>>>
>>> Right, and when going “official” one might want to disentangle the 
>>> interface and bp3 a bit more. Other than the php-interface, and 
>>> ctests, one could also think about the help.txt and compile.php 
>>> files. They’re special in that they are thought of as concerning bp 
>>> as a whole rather than just the interface. So this is about how to 
>>> split duties between bp3 and the php-interface. I’ve thought about 
>>> this a bit in the past and found it quite tricky. Actually separating 
>>> the php-interface and the bp-repo into separate sibling-folders might 
>>> be an interesting experiment to see which unintended dependencies and 
>>> hardcoded paths between both components slipped in. As to help-files, 
>>> one could ask if bp3 should require the php-interface to be 
>>> available, or if some text-only documentation could allow bp3 to 
>>> display (some) help without it. Ideally the php-interface could 
>>> access the bp3-binary/repo wherever it resides, and bp3 would 
>>> not depend on the interface for anything essential. If the 
>>> webserver requires the binary in the webspace of the php-interface, 
>>> one might even think it intuitive to install bp3-console as a 
>>> subdirectory of the php-interface rather than the opposite. I am 
>>> still not clear on which requirements are given by security 
>>> restrictions of the web-server, but there are other reasons why one 
>>> might want the php-interface to be able to find bp3 in different 
>>> folders/locations, e.g. multiple versions of a Bolprocessor binary 
>>> required by different user files. One could also imagine binary and 
>>> interface developing at different paces, so that multiple installs of 
>>> both become a “nice to have”. (This issue is pretty thorny for 
>>> SuperCollider, the binaries of which write configuration- and 
>>> runtime-files to hardcoded system-locations by default. If for 
>>> some reason you need multiple installs on your system, each 
>>> overwrites the other's files. Creating “standalone” installs is not 
>>> as trivial as it should be, and SC has become such a complex project 
>>> that things are not easy to set straight any more).
>>>
>>> Best
>>> .r.

> 

Re: [bp-dev] GitHub migration

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

Dear Bernard,

Fab! I am not an expert at all myself but I’ll try my best to take your hand until things have settled ;-) My own memory of git has faded a bit, but fortunately I can look up things easily on the web. Once one is able to put questions in the right words, almost everything is answered well out there… Let me add this at the outset: anything we run into can be changed, undone etc… Deleting a Github repo takes two minutes and setting it up again 5…. 


> Now I created this repository: https://github.com/belbernard/bolprocessor-php
> and a small README file. It will contain exclusively the PHP interface.

Okay, let’s take this as given. I’ll give you the concrete steps with a few explanations to get going first, and we can discuss the implications later when problems arise or questions pose themselves. I am assuming you do this on the command-line. 

But first, before you actually start, let’s get identity straight: there are two levels to this: one is that you tell git how you identify as an author. This requires a “name” and an email address. You’re free to chose what you like here, this is not bound to your Github account. The other level are the credentials you use to show Github that you have the right to access the repo and write to it. The later will be asked from you when you try to push to GitHub. So let’s get that authorship id out of the way: when you start this is usually done on the “global” git configuration level (global is not as global as it sounds, there is also “system” and "local”. Global is the default in your userspace, it could be overwritten with “local”). The config information is stored in a file in your $HOME directory, called .gitconfig. You can edit that file, or add entries with git commands. This is mine .gitconfig:




You can also add the entries with git-commands:

    git config --global user.name "whatever you chose to appear as author"
    git config --global user.email "the email address that will be visibly associated with your authorship”


Now let's “clone” the rep you created into your local environment (this will create the folder coprocessor-php in the folder you are, so mind a potential conflict):

    git clone https://github.com/belbernard/bolprocessor-php

You can actually tell git to clone into a folder of a different name (or you can later rename the folder, git doesn’t care about the parent folder name):

    git clone https://github.com/belbernard/bolprocessor-php bolprocessor

Once that’s done you’ll have an almost empty folder, it contains the Readme, License and most importantly: a hidden folder .git that contains all the current information about the repo. In theory you could delete all files in your folder (e.g. accidentally) *except that .git folder* and reinstate the entire repo by having git reconstruct them from the info in .git (the command would be `git checkout *`). `git init` creates that .git folder (but without any version-control-information, when you start!).

Now come the crucial steps: you want to add your files to the (that ;-)) repo: taking files under version control should be thought of, I think, as having two steps: the first is to “add” the files (or to stage them), and the second is to “commit” them. Only what is committed has ended up under version control or is uploaded if you push. Splitting the process into two steps might seem like a nuisance at first, but it allows you to organise your commits, remove files again from the stage if you changed your mind, keep spontaneous/temporary changes (“untracked” files and folders) separate from stuff that is considered a candidate to be committed. And once you think you aggregated a nice bunch of changes you can commit them as a meaningful unit. Commit will commit everything that is staged and none of the “untracked files"

So extract your snapshot into that folder and think of it as creating the files you will want to add, and subsequently commit and then push to your remote repo. You want all the files of the snapshot in the right location and nothing else for now (so after getting the files in place delete the .zip ’n further artefacts that might have appeared as sideffect of extracting the snapshot). 

You might want to have a look at what git thinks you’ve changed so far. It’s basically a diff of the repo-state stored in the .git folder and the current folder state:

    git status 

It should give you a short list of files and the folder php/ listing them as “untracked files"



If you’re like me and hate those hidden system-files like .DS_Store you might want to add that exclusion list right away that I mentioned the other day. It’s a file called “.gitignore” residing in the root folder of your repo. You can freely edit it, every entry is a line. To exclude .DS_Store just add it as a line in a file called .gitignore. The result (`git status`) should look like this:



The gitignore file could at some point get quite long, it might even be possible to include Anthony’s repo in that file and exclude it from version control… I haven’t fully thought it through, but it could be a simple way to keep you working environment, which I assume is having both Anthony’s and your files in a shared parent folder. Note that you can rename the parent folder, git only looks inside of it. But that’s for another day, right? Just keep in mind that .gitignore is maintained like any other file in the repo. If you change it, it will “work” right away, but if you’d like it to be available for anybody you need to add, commit and push it. If you just want it for yourself, you could add .gitignore to .gitignore and git wouldn’t remind you of it any more.

Now you’re ready to add the whole bunch using kind of a regex (or a glob expression, I am not sure, anyways “.” is "all"):

    git add .

If you run `git status` again it’s shows you what it did, it should have “added" all files ’n folders to the “stage”:



Now you’re ready to commit. A commit requires a commit message, and you can add it with -m, so that git doesn’t open a text-editor for you (this editor thing might be confusing. Not sure if you’re used to a specific editor on the command line, it might be helpful to configure that - but for now you can avoid the editor by adding the commit message with -m). The commit message can be anything you chose. Some people warn it’s important to be considerate about it ;-)

    git commit -m "Initial commit php-interface for bp3”

Git status will tell you now that the repo has caught up with the folder state, *and* that it has overtaken the remote repo by one commit:



At that point you’re ready to push:

    git push

Note that when you cloned the repo git protocolled the remote you used. As long as you only have one remote repo, git will use it as the target destination. In multi-repo setups (e.g. private repo and Organisation repo you might need to configure the default remote or make it explicit on the command line). 

At this point it should ask you for your Github credentials and store them somewhere. Hopefully it won’t ask you each time you push, otherwise some more configuration might become necessary. Github also provides a way to store ssh-keys, similar to what you might have done with your web-provider, so I am pretty sure you’ll get over this.

Fingers crossed your initial commit was uploaded to Github, you should be able to see it on the Github-site, Github is usually very fast in updating the repo-state on the site.

From now on - as long as things remain basic - i.e. you only have one remote, and you only need one-way synching because you’re the only one that commits - you just need to get used to going through that “make untracked changes (edit something or create a file) - stage (git add …) - commit (git commit -m “…”) and upload (git push)” cycle to keep the public version of your repo in sync with the local one (some people skip add by doing “git commit -am “…”, but that’s considered careless ;-) ). All these commands have many options and you can use globs ’n stuff in many places, so there is a lot to learn if one wants (most interesting maybe branches, that give you a space to explore stuff without messing with the main development thread). But the basic cycle can be handled like that. A nice thing about git is that it’s quite smart about what you might want to do, and it tells you stuff like that you can do “git restore —staged <file>” after you added or “git push” after you commited. Some of these terms likely require some Googling, but generally speaking git is amazingly well documented on all levels. Undoing local commits is also possible in various ways (git reset with various options like —soft, —hard and more). The hairy thing you want to avoid is undoing commits that have already been pushed. As long as you’re alone, even that is still possible, but it requires more commands. Git wants you to avoid this, because if multiple users share a remote and you keep deleting stuff from the remote, synching problems are very likely to occur. The general git philosophy, I’d say is - rather than undo/delete stuff, add such changes on top as well. They’ll be visible in history then, but you avoid synching problems.

I am happy to answer questions that come up (but maybe we better do that with private email)

Best
.r.



> 
> I chose "GNU General Public License v3.0" which should be ok for our approach.
> 
> Now, looking at https://guides.github.com/activities/hello-world/ , I guess that I should push all current files (the content of bolprocessor_php.zip) into this "master" branch, and thereafter create a new "work" branch to push next versions… Is this the case ? I am careful because there seems to be no "undo" for dummies…
> 
> One more thing: if I push the zip file, will it deflate on its own?
> 
> In the Terminal I went to the work folder and did "git init" as you suggested. Now, "ls -l" yields:
> 
> drwxr-xr-x@ 10 bernardbel  staff     340 29 sep 15:41 .git
> -rw-r--r--@  1 bernardbel  staff  181679 22 jul 00:19 BP2_help.txt
> -rw----r--@  1 bernardbel  staff     166 25 sep 09:54 compile.php
> drwxr-xr-x@ 44 bernardbel  staff    1496 29 sep 14:17 php
> 
> What should I do next?
> 
> I will also think about the structure you are discussing below. The main point is that for the time being we are sharing a version of the package designed to run under MAMP or a similar local server. The next stage might be to install it as an on-line service, but developers joining the project would still run their new versions on local servers.
> 
> So, until we have a standalone application (rendering the PHP interface obsolete) the installation procedure will remain the one described on top of https://bolprocessor.org/misc/BP3/CheckList.html. The only complication is that both Anthony and I are delivering a "bolprocessor" folder and their contents should be merged. As you suggested, the console's folder could be named "console" and put inside the "bolprocessor" folder at the same level as "php". I Anthony agrees with this change, he may change the folder's name to "console" or "bp_console" whatever…
> 
> Bernard
> 
> Rainer Schuetz wrote on 29/09/2020 14:19:
>> 
>> 
>>> On 29. Sep 2020, at 06:53, Bernard Bel <ber...@gm...> wrote:
>>> 
>>> So, when the whole project moves to GitHub you could take the current version of the interface as an initial version.
>> 
>> Okay!
>> 
>>> I am now planning genuine developments such as running scripts via the interface — i.e. translating their actions to commands sent to the console.  This will be worth following stepwise.
>> 
>> Good! This feels to me like the ideal moment for you to start switching to the git workflow yourself - it would only require you to run “git init” in your development folder, create a Github account and push to it, Github even guides through the steps.
>> 
>> But if you’re not comfortable jumping off right now: how about creating a Github account for you and I push to a repo there - ideally borrowing your identity temporarily, as that would allow commits to appear with proper authorship assignment. Once you’re happy to take over, you just need to “pull” into a new folder and can maintain things yourself. And pushing a commit is less work than creating an archive, uploading to a server and sending emails ;-) And once the organisation is created, the repo can be moved in with proper authorship-assignment and history as intended.
>> 
>>> We will also need to figure out a procedure for sharing examples of grammars, data, scripts etc. used for checking the software or constructing tutorials. Up to now we use the "ctests" folder but it is not systematic.
>> 
>> Right, and when going “official” one might want to disentangle the interface and bp3 a bit more. Other than the php-interface, and ctests, one could also think about the help.txt and compile.php files. They’re special in that they are thought of as concerning bp as a whole rather than just the interface. So this is about how to split duties between bp3 and the php-interface. I’ve thought about this a bit in the past and found it quite tricky. Actually separating the php-interface and the bp-repo into separate sibling-folders might be an interesting experiment to see which unintended dependencies and hardcoded paths between both components slipped in. As to help-files, one could ask if bp3 should require the php-interface to be available, or if some text-only documentation could allow bp3 to display (some) help without it. Ideally the php-interface could access the bp3-binary/repo wherever it resides, and bp3 would not depend on the interface for anything essential. If the webserver requires the binary in the webspace of the php-interface, one might even think it intuitive to install bp3-console as a subdirectory of the php-interface rather than the opposite. I am still not clear on which requirements are given by security restrictions of the web-server, but there are other reasons why one might want the php-interface to be able to find bp3 in different folders/locations, e.g. multiple versions of a Bolprocessor binary required by different user files. One could also imagine binary and interface developing at different paces, so that multiple installs of both become a “nice to have”. (This issue is pretty thorny for SuperCollider, the binaries of which write configuration- and runtime-files to hardcoded system-locations by default. If for some reason you need multiple installs on your system, each overwrites the other's files. Creating “standalone” installs is not as trivial as it should be, and SC has become such a complex project that things are not easy to set straight any more).
>> 
>> Best
>> .r.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> bolprocessor-devel mailing list
>> 
>> bol...@li...
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Scripts

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

Dear all,

I started working on running scripts via the PHP interface.

A small change: we can't use "+sc" as a prefix for script files. We'll 
use "-sc", which is consistent with other prefixes. The reason is that 
filenames are carried in URLs (GET parameters) and "+"" is decoded as a 
space.

In the old days of BP2, the "+" sign was convenient for highlighting 
scripts in lists of files.

Many script commands are translatable to actions in browsing. Still, a 
few of them such as _script(wait for NoteOn ...) will need to be taken 
care of by the console once real-time MIDI is working.

Bernard

Re: [bp-dev] GitHub migration

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

Thanks for giving me this "push", Rainer!

I had created a GitHub account for communicating on the Csound forum.

Now I created this repository: 
https://github.com/belbernard/bolprocessor-php
and a small README file. It will contain exclusively the PHP interface.

I chose "GNU General Public License v3.0" which should be ok for our 
approach.

Now, looking at https://guides.github.com/activities/hello-world/ , I 
guess that I should push all current files (the content of 
bolprocessor_php.zip) into this "master" branch, and thereafter create a 
new "work" branch to push next versions… Is this the case ? I am careful 
because there seems to be no "undo" for dummies…

One more thing: if I push the zip file, will it deflate on its own?

In the Terminal I went to the work folder and did "git init" as you 
suggested. Now, "ls -l" yields:

drwxr-xr-x@ 10 bernardbel  staff     340 29 sep 15:41 .git
-rw-r--r--@  1 bernardbel  staff  181679 22 jul 00:19 BP2_help.txt
-rw----r--@  1 bernardbel  staff     166 25 sep 09:54 compile.php
drwxr-xr-x@ 44 bernardbel  staff    1496 29 sep 14:17 php

What should I do next?

I will also think about the structure you are discussing below. The main 
point is that for the time being we are sharing a version of the package 
designed to run under MAMP or a similar local server. The next stage 
might be to install it as an on-line service, but developers joining the 
project would still run their new versions on local servers.

So, until we have a standalone application (rendering the PHP interface 
obsolete) the installation procedure will remain the one described on 
top of https://bolprocessor.org/misc/BP3/CheckList.html. The only 
complication is that both Anthony and I are delivering a "bolprocessor" 
folder and their contents should be merged. As you suggested, the 
console's folder could be named "console" and put inside the 
"bolprocessor" folder at the same level as "php". I Anthony agrees with 
this change, he may change the folder's name to "console" or 
"bp_console" whatever…

Bernard

Rainer Schuetz wrote on 29/09/2020 14:19:
>
>
>> On 29. Sep 2020, at 06:53, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> So, when the whole project moves to GitHub you could take the current 
>> version of the interface as an initial version.
>
> Okay!
>
>> I am now planning genuine developments such as running scripts via 
>> the interface — i.e. translating their actions to commands sent to 
>> the console.  This will be worth following stepwise.
>
> Good! This feels to me like the ideal moment for you to start 
> switching to the git workflow yourself - it would only require you to 
> run “git init” in your development folder, create a Github account and 
> push to it, Github even guides through the steps.
>
> But if you’re not comfortable jumping off right now: how about 
> creating a Github account for you and I push to a repo there - ideally 
> borrowing your identity temporarily, as that would allow commits to 
> appear with proper authorship assignment. Once you’re happy to take 
> over, you just need to “pull” into a new folder and can maintain 
> things yourself. And pushing a commit is less work than creating an 
> archive, uploading to a server and sending emails ;-) And once the 
> organisation is created, the repo can be moved in with proper 
> authorship-assignment and history as intended.
>
>> We will also need to figure out a procedure for sharing examples of 
>> grammars, data, scripts etc. used for checking the software or 
>> constructing tutorials. Up to now we use the "ctests" folder but it 
>> is not systematic.
>
> Right, and when going “official” one might want to disentangle the 
> interface and bp3 a bit more. Other than the php-interface, and 
> ctests, one could also think about the help.txt and compile.php files. 
> They’re special in that they are thought of as concerning bp as a 
> whole rather than just the interface. So this is about how to split 
> duties between bp3 and the php-interface. I’ve thought about this a 
> bit in the past and found it quite tricky. Actually separating the 
> php-interface and the bp-repo into separate sibling-folders might be 
> an interesting experiment to see which unintended dependencies and 
> hardcoded paths between both components slipped in. As to help-files, 
> one could ask if bp3 should require the php-interface to be available, 
> or if some text-only documentation could allow bp3 to display (some) 
> help without it. Ideally the php-interface could access the 
> bp3-binary/repo wherever it resides, and bp3 would not depend on the 
> interface for anything essential. If the webserver requires the binary 
> in the webspace of the php-interface, one might even think it 
> intuitive to install bp3-console as a subdirectory of the 
> php-interface rather than the opposite. I am still not clear on which 
> requirements are given by security restrictions of the web-server, but 
> there are other reasons why one might want the php-interface to be 
> able to find bp3 in different folders/locations, e.g. multiple 
> versions of a Bolprocessor binary required by different user files. 
> One could also imagine binary and interface developing at different 
> paces, so that multiple installs of both become a “nice to have”. 
> (This issue is pretty thorny for SuperCollider, the binaries of which 
> write configuration- and runtime-files to hardcoded system-locations 
> by default. If for some reason you need multiple installs on your 
> system, each overwrites the other's files. Creating “standalone” 
> installs is not as trivial as it should be, and SC has become such a 
> complex project that things are not easy to set straight any more).
>
> Best
> .r.
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] GitHub migration

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

> On 29. Sep 2020, at 06:53, Bernard Bel <ber...@gm...> wrote:
> 
> So, when the whole project moves to GitHub you could take the current version of the interface as an initial version.

Okay!

> I am now planning genuine developments such as running scripts via the interface — i.e. translating their actions to commands sent to the console.  This will be worth following stepwise.

Good! This feels to me like the ideal moment for you to start switching to the git workflow yourself - it would only require you to run “git init” in your development folder, create a Github account and push to it, Github even guides through the steps.

But if you’re not comfortable jumping off right now: how about creating a Github account for you and I push to a repo there - ideally borrowing your identity temporarily, as that would allow commits to appear with proper authorship assignment. Once you’re happy to take over, you just need to “pull” into a new folder and can maintain things yourself. And pushing a commit is less work than creating an archive, uploading to a server and sending emails ;-) And once the organisation is created, the repo can be moved in with proper authorship-assignment and history as intended.

> We will also need to figure out a procedure for sharing examples of grammars, data, scripts etc. used for checking the software or constructing tutorials. Up to now we use the "ctests" folder but it is not systematic.


Right, and when going “official” one might want to disentangle the interface and bp3 a bit more. Other than the php-interface, and ctests, one could also think about the help.txt and compile.php files. They’re special in that they are thought of as concerning bp as a whole rather than just the interface. So this is about how to split duties between bp3 and the php-interface. I’ve thought about this a bit in the past and found it quite tricky. Actually separating the php-interface and the bp-repo into separate sibling-folders might be an interesting experiment to see which unintended dependencies and hardcoded paths between both components slipped in. As to help-files, one could ask if bp3 should require the php-interface to be available, or if some text-only documentation could allow bp3 to display (some) help without it. Ideally the php-interface could access the bp3-binary/repo wherever it resides, and bp3 would not depend on the interface for anything essential. If the webserver requires the binary in the webspace of the php-interface, one might even think it intuitive to install bp3-console as a subdirectory of the php-interface rather than the opposite. I am still not clear on which requirements are given by security restrictions of the web-server, but there are other reasons why one might want the php-interface to be able to find bp3 in different folders/locations, e.g. multiple versions of a Bolprocessor binary required by different user files. One could also imagine binary and interface developing at different paces, so that multiple installs of both become a “nice to have”. (This issue is pretty thorny for SuperCollider, the binaries of which write configuration- and runtime-files to hardcoded system-locations by default. If for some reason you need multiple installs on your system, each overwrites the other's files. Creating “standalone” installs is not as trivial as it should be, and SC has become such a complex project that things are not easy to set straight any more).

Best
.r.

[bp-dev] GitHub migration

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

Dear Rainer,

Reconstructing the history of the PHP interface development might be of 
little interest because initial changes did not reflect a choice of 
options worth discussing afterwards. Up to now this interface has been 
mainly a replica of BP2's interface.

So, when the whole project moves to GitHub you could take the current 
version of the interface as an initial version.

I am now planning genuine developments such as running scripts via the 
interface — i.e. translating their actions to commands sent to the 
console.  This will be worth following stepwise.

We will also need to figure out a procedure for sharing examples of 
grammars, data, scripts etc. used for checking the software or 
constructing tutorials. Up to now we use the "ctests" folder but it is 
not systematic.

Thank you for your support!

Bernard

Rainer Schuetz wrote on 28/09/2020 16:28:
> I am looking forward to Bolprocessor official on Github (or Gitlab?)! 
> Unfortunately I didn’t commit Bernards stuff on a branch separate from 
> my own (rare and separate) additions, but I still have the snapshots, 
> and it should be rather easy to reconstruct a clean history of the 
> emergeance of the php-interface, should that be wished.
>
> Best
> .r.

Re: [bp-dev] Making some plans

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

Dear Anthony,

It is very wise to think about the long term. My tendency is to move on 
small steps with little attention to priorities!

I suggest that BP3.0.0 be released with the main features allowing the 
production of "complex" musical items. The analytical part — parsing 
items, infering weights, mapping the keyboard etc. — may be studied 
later. These are certainly covered by your list of pending tasks. I 
would add the graphic output which I will be very pleased to take over 
now that I have become conversant with GD graphics.

Once BP3 is publicly available — may be an on-line service with 
registered users — we may anticipate that sharing the news will create a 
new community of users. If we want it to survive we'll need to be 
careful about bug fixes and regular enhancements of thhe implementation. 
It is probably helpful not to be under such pressure while working on 
aspects that do not deliver "flashy" changes. You are "under the car" 
fixing the engine while I am outside decorating its body — which is 
indeed more rewarding!

For orchestra files — a simple mapping of instrument names to MIDI 
channels — we may need to look at General MIDI version 2 
(https://en.wikipedia.org/wiki/General_MIDI) and up-to-date standards as 
well (https://en.wikipedia.org/wiki/Comparison_of_MIDI_standards). 
Instrument names are variables listed in a glossary, up to now using 
"-gl.GeneralMIDI" that translates these names to standard changes of 
MIDI programs, in turn encoded as script instructions.

We'll need to recognise a few script commands: the ones that start with 
"MIDI" and with "IN". The latter will take into account MIDI input, for 
instance a NoteOn to synchronize an event. There is no emergency in 
figuring out the use of scripts for automatizing processes, as this will 
probably be the job of the interface.

Regarding GitHub I fully agree with your proposal. I am not yet familiar 
with distributed development — always afraid of unwanted interference 
between changes pushed by isolated programmers — but if we think about 
the long term and a desirable expansion of the groups of 
users/designers, this is the way to go!

Documentation: At present I am taking small steps collecting and 
updating old bits of documentation. I am confident that these are 
initial steps focusing on the content and less on the presentation. The 
Wordpress website creates a little bit of order in a set that still 
looks rather like a dusty attic. Once BP3 is available, new users will 
join and they will need a good "startup manual".

The framed BP2.9.8 manual (https://bolprocessor.org/misc/docs/) had been 
generated by an outdated application converting MS-Word files to HTML. 
This was very easy but this method is obsolete and it would be difficult 
to update HTML pages manually. I am confident we should restart from 
scratch even though many details will be picked up in the old documentation.

Looking carefully at DocBook and Texinfo might help making a decision. 
Csound colleagues might have used DocBook because Texinfo was not yet 
available… You may ask them which one they would prefer if they were 
doing it again. Basically I am attracted to an environment not too far 
from WYSWYG for the creation of source files. Now I feel impatient to 
try any of these tools!

Roadmap for the future: Putting together ideas also will require a 
structured presentation. We need to find a tradeoff between a very flat 
structure (for instance sets of Googledocs) and a complex one with a 
long learning curve. I have a tendency to solve this kind of problem 
with a database design as it makes it easy to adapt the structure to new 
priorities showing up. Sorry if this statement is a bit vague! Maybe 
think about it when users join the team after the release of BP3…

Bernard

Anthony Kozar wrote on 28/09/2020 10:48:

> Dear everyone,
> 
> Here are some topics that I've been wanting to discuss for awhile.
> 
> 1. BP 3.0.0 release
> 
> Which features must be in BP 3.0.0 and which are acceptable to leave for 
> later releases?
> 
> Here is a short list of features that I think probably should be 
> finished in the console for the 3.0.0 release:
> 
>    - write new docs for BP3 (command-line usage, differences, etc.)
>    - implement play command (and possibly play-item N & play-all)
>    - fix crash when loading a glossary file
>    - fix crash when grammar contains script commands
>    - port loading of -or MIDI orchestra files
>    - port loading of -cs Csound instruments files
>    - port loading of -mi Sound Object Prototypes files
>    - implement the -s/-S options for specifying the start string
>    - identify input files with prefixes even when they are preceded by
>      a path
>    - restore the feature that looks for names of related files in the
>      input files and auto-loads them
>    - new action for listing RT MIDI devices
>    - finish revising CoreMIDI driver and allow optionally building with
>      it on Mac OS X
>    - write a new cross-platform MIDI driver using the PortMIDI(?) library
> 
> The PHP interface seems to be coming along wonderfully!  I am not sure 
> what else needs to be added at this time.
> 
> 
> 2. GitHub presence
> 
> I think we should create a GitHub "organization" for the Bol Processor 
> project.  It does not have to replace the Sourceforge project, but it 
> could increase project visibility and help us organize & collaborate 
> better.  On GitHub we can more easily manage multiple repositories (BP3, 
> PHP interface, docs, Qavaid, BP1?, a Java "launcher"?).  More 
> importantly, a presence on GitHub makes it very simple for anyone to 
> "fork" our repository, make changes of any size, and then submit a 
> request to us to "pull" (merge) their changes into the official repository.
> 
> Many popular open-source projects these days seem to have a few primary 
> developers and then a constellation of occasional "outside" contributors 
> who submit small patches.  Git was designed for this sort of 
> "distributed development", although in practice each contributor needs a 
> server to host their copy of a repository to make it easy to pull 
> changes from each other.  This eliminates the need to give direct access 
> to the main repository to everyone who might be interested in submitting 
> a patch.  Sourceforge is not really set up for this distributed 
> development model but GitHub is.  We can still keep the official BP 
> repository on Sourceforge with only Bernard and I currently having 
> access.  But I suggest creating a clone of that repository on GitHub for 
> day to day development and for accepting commits from other developers. 
>   I will take responsibility for keeping the two repositories in sync.
> 
> 
> 3. Updating the BP2 documentation
> 
> In addition to documenting the new console & PHP interfaces, I think the 
> BP2 documentation could use a significant overhaul.  A few ideas for 
> changes:
> 
> - a new introduction that reflects the current status of BP
> - generalize the text to be applicable to different interfaces (BP2, 
> console, PHP)
> - needs all new screenshots
> - cross-references between sections should be hyperlinks
> - convert HTML files to some (open-source) document authoring system 
> that can help maintain the organization & internal links as well as 
> output in multiple formats (HTML, PDF, etc.)
> - eliminate frames in the HTML version?
> - reorganize and trim the topics that are included in the "Quickstart" 
> section; move some "advanced topics" and topics that are BP2-only for 
> now into the reference section.
> 
> Bernard, do you have any suggestions for a document authoring system? I 
> am not that familiar with any particular system so I don't have any 
> recommendations.  Below are a couple of systems that I've heard of.
> 
> DocBook (https://en.wikipedia.org/wiki/DocBook) is based on XML and SGML 
> and it supports HTML, XHTML, EPUB, PDF, man pages, and HTML Help output. 
>   The Csound project uses DocBook for their manual.  It seemed like a 
> complex system to me when I added some new pages to the Csound manual in 
> 2008.  I did not take the time back then to understand how all of the 
> parts worked together.
> 
> Texinfo (https://en.wikipedia.org/wiki/Texinfo) is the GNU system for 
> producing documentation: "The main purpose of Texinfo is to provide a 
> way to easily typeset software manuals."  I think its syntax is similar 
> to LaTeX and it supports HTML, DVI, PDF, DocBook, XML, and GNU Info 
> output. I have never used Texinfo or LaTeX but the syntax appears 
> simpler than XML.
> 
> I suppose that adding PHP to the existing HTML files and then rendering 
> static pages to distribute would be a simple way to go too...
> 
> 
> 4. Road map for the future
> 
> I'm not going to get into any details for this topic, but I would like 
> to discuss the long-term plans for the project.  This can include plans 
> for when & how to port BP2 features that will not be in BP 3.0.0, new 
> features to add, new output targets, new interfaces, the BP API, etc.  I 
> think that it would be helpful for us to gather all of the ideas that 
> we've had over the years into one document and to discuss, broadly, 
> which ones we might want to work on in the next few years.  This 
> document could also be a place to direct new recruits who are looking 
> for a sub-project to devote their time to -- if we ever get lucky enough 
> to have one! ;-)  This discussion could be put off until after the 
> release of 3.0.0 if there is too much else to work on.
> 
> 
> Well, that's plenty to discuss for now.  If it is easier, please feel 
> free to respond to these topics in separate threads.
> 
> Thanks,
> 
> Anthony

Re: [bp-dev] Variables as startup strings

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

> On 28. Sep 2020, at 15:56, Bernard Bel <ber...@gm...> wrote:
> 
> No change in the documentation until commands are fully operational. This new interface may be committed with comment: "New commands on Grammar and Data pages”.

Done!

I am looking forward to Bolprocessor official on Github (or Gitlab?)! Unfortunately I didn’t commit Bernards stuff on a branch separate from my own (rare and separate) additions, but I still have the snapshots, and it should be rather easy to reconstruct a clean history of the emergeance of the php-interface, should that be wished.

Best
.r.

[bp-dev] Variables as startup strings

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

Dear all,

The PHP interface is ready to deal with the (forthcoming) "startup" 
option in producing items. The new version is available here:

https://bolprocessor.org/misc/BP3/bolprocessor_php.zip

Look at the attached picture showing the bottom of grammar "-gr.Mozart". 
All variables have been identified and displayed as buttons. Clicking 
button "T158", for instance, generates the following command:

command = ../bp produce -gr ../ctests/-gr.Mozart -se 
../ctests/-se.Mozart --start T158 -d --csoundout ../my_output/out.sco 
--traceout ../temp_bolprocessor/trace_23b8c472d110e537e37fb82154298581.txt

This command will produce a Csound score because it is the current 
outpout option. Other options (MIDI file, BP data, real-time MIDI) will 
be taken into account.

In this particular example it may be interesting to derive a variable 
(used as startup) but the user may also want to hear/look at a 
particular expression. For instance, I entered {{3,si2 re3 sol3 re3 si2 
sol2},sol5 sol4 sol4} and clicked PRODUCE ITEM… at the bottom of the 
page. This generated the command:

../bp produce -gr ../ctests/-gr.Mozart -S 
../temp_bolprocessor/temp_23b8c472d110e537e37fb82154298581outdata.bpda 
-se "../ctests/-se.Mozart" -d --csoundout ../my_output/out.sco

In this case, the startup expression is stored in a temporary file 
"...outdata.bpda".

This covers all cases which previously (in BP2.9.8) were dealt with by 
"playing the selection".

At present, warnings are displayed telling that "--start" is not yet a 
valid option. This is meant to complete work on the PLAY command which I 
had mentioned yesterday.

No change in the documentation until commands are fully operational. 
This new interface may be committed with comment: "New commands on 
Grammar and Data pages".

Bernard

[bp-dev] Making some plans

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

Dear everyone,

Here are some topics that I've been wanting to discuss for awhile.

1. BP 3.0.0 release

Which features must be in BP 3.0.0 and which are acceptable to leave for 
later releases?

Here is a short list of features that I think probably should be 
finished in the console for the 3.0.0 release:

   - write new docs for BP3 (command-line usage, differences, etc.)
   - implement play command (and possibly play-item N & play-all)
   - fix crash when loading a glossary file
   - fix crash when grammar contains script commands
   - port loading of -or MIDI orchestra files
   - port loading of -cs Csound instruments files
   - port loading of -mi Sound Object Prototypes files
   - implement the -s/-S options for specifying the start string
   - identify input files with prefixes even when they are preceded by
     a path
   - restore the feature that looks for names of related files in the
     input files and auto-loads them
   - new action for listing RT MIDI devices
   - finish revising CoreMIDI driver and allow optionally building with
     it on Mac OS X
   - write a new cross-platform MIDI driver using the PortMIDI(?) library

The PHP interface seems to be coming along wonderfully!  I am not sure 
what else needs to be added at this time.


2. GitHub presence

I think we should create a GitHub "organization" for the Bol Processor 
project.  It does not have to replace the Sourceforge project, but it 
could increase project visibility and help us organize & collaborate 
better.  On GitHub we can more easily manage multiple repositories (BP3, 
PHP interface, docs, Qavaid, BP1?, a Java "launcher"?).  More 
importantly, a presence on GitHub makes it very simple for anyone to 
"fork" our repository, make changes of any size, and then submit a 
request to us to "pull" (merge) their changes into the official repository.

Many popular open-source projects these days seem to have a few primary 
developers and then a constellation of occasional "outside" contributors 
who submit small patches.  Git was designed for this sort of 
"distributed development", although in practice each contributor needs a 
server to host their copy of a repository to make it easy to pull 
changes from each other.  This eliminates the need to give direct access 
to the main repository to everyone who might be interested in submitting 
a patch.  Sourceforge is not really set up for this distributed 
development model but GitHub is.  We can still keep the official BP 
repository on Sourceforge with only Bernard and I currently having 
access.  But I suggest creating a clone of that repository on GitHub for 
day to day development and for accepting commits from other developers. 
  I will take responsibility for keeping the two repositories in sync.


3. Updating the BP2 documentation

In addition to documenting the new console & PHP interfaces, I think the 
BP2 documentation could use a significant overhaul.  A few ideas for 
changes:

- a new introduction that reflects the current status of BP
- generalize the text to be applicable to different interfaces (BP2, 
console, PHP)
- needs all new screenshots
- cross-references between sections should be hyperlinks
- convert HTML files to some (open-source) document authoring system 
that can help maintain the organization & internal links as well as 
output in multiple formats (HTML, PDF, etc.)
- eliminate frames in the HTML version?
- reorganize and trim the topics that are included in the "Quickstart" 
section; move some "advanced topics" and topics that are BP2-only for 
now into the reference section.

Bernard, do you have any suggestions for a document authoring system? 
I am not that familiar with any particular system so I don't have any 
recommendations.  Below are a couple of systems that I've heard of.

DocBook (https://en.wikipedia.org/wiki/DocBook) is based on XML and SGML 
and it supports HTML, XHTML, EPUB, PDF, man pages, and HTML Help output. 
  The Csound project uses DocBook for their manual.  It seemed like a 
complex system to me when I added some new pages to the Csound manual in 
2008.  I did not take the time back then to understand how all of the 
parts worked together.

Texinfo (https://en.wikipedia.org/wiki/Texinfo) is the GNU system for 
producing documentation: "The main purpose of Texinfo is to provide a 
way to easily typeset software manuals."  I think its syntax is similar 
to LaTeX and it supports HTML, DVI, PDF, DocBook, XML, and GNU Info 
output. I have never used Texinfo or LaTeX but the syntax appears 
simpler than XML.

I suppose that adding PHP to the existing HTML files and then rendering 
static pages to distribute would be a simple way to go too...


4. Road map for the future

I'm not going to get into any details for this topic, but I would like 
to discuss the long-term plans for the project.  This can include plans 
for when & how to port BP2 features that will not be in BP 3.0.0, new 
features to add, new output targets, new interfaces, the BP API, etc.  I 
think that it would be helpful for us to gather all of the ideas that 
we've had over the years into one document and to discuss, broadly, 
which ones we might want to work on in the next few years.  This 
document could also be a place to direct new recruits who are looking 
for a sub-project to devote their time to -- if we ever get lucky enough 
to have one! ;-)  This discussion could be put off until after the 
release of 3.0.0 if there is too much else to work on.


Well, that's plenty to discuss for now.  If it is easier, please feel 
free to respond to these topics in separate threads.

Thanks,

Anthony

[bp-dev] PLAY command + MIDI setup

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

Dear Anthony,

Sorry for the confusion! I was relying on the console's help file and 
not remembering that it anticipates commands not yet implemented…

With respect to the PLAY command and the current interface, the only 
syntactic form that we need is "play the first item in the input data 
file". You can forget "play the Nth item in the input data file" etc. 
because items are automatically isolated on Data pages — see attached 
picture. The same holds with "expand-item" triggered by the "EXP" button 
on that same page. Today I will do a similar extraction on the Grammar 
page so that we can select any variable or a polymetric expression as 
the startup string. This should simplify the console's process.

For the MIDI setup it might be wise to store all required information 
(MIDI in/out devices etc.) in a file whose name would not be related 
with a specific grammar or data file. In 2007 (BP2.9.6) you had created 
"-md" files such as "-md.Visser.Waves.bpmd" containing data for setting 
up CoreMIDI. This format is probably obsolete and the drawback is that 
it was necessary to create a setup for every grammar in BP2.9.8. It 
would be easier to have a generic setup file which can be edited 
separately. It could even be in XML to facilitate figuring out its 
meaning 10 years later… I understand that you have been working on a 
standalone application communicating with devices and creating this file.

The MIDI setup file's name could be stored in settings files of grammars 
or data. I am enclosing part of "-se.Visser.Waves" showing that field 53 
contained "Output ID and OMS output name" which was set as "32115 
QuickTime Music". This is obsolete data which could be renamed and 
replaced with the name of the MIDI setup file, presumably to be found 
either in the same folder or higher in the hierarchy. Another option is 
to keep using "-md" files and redesign their content to match the new 
requirements. After all, grammar "Visser.Waves.bpgr" could refer to a 
generic file succh as "MyMIDIsettings.bpmd". We could also decide on the 
name of a default MIDI settings file which the interface would 
automatically add to a grammar or data file in case no file is declared 
or the file is not found.

Finally, the rtmidi command could only contain an extension such as 
"--midisetup name_of_file". Indeed, the PHP interface would not allow 
editing those files because setting them up requires a  connection with 
the MIDI environment which is not available in PHP, as far as I know.

Indeed we look forward to a release of BP3 in a couple of months, but do 
not get burnt out with this project! I keep developing this interface 
ahead of implemented commands, which is useful to confirm the syntax. I 
will also take time describing important algorithms as these may be 
required for future development.

On the Apple II the only thing I've been able to achieve is retrieving 
"Mister Robot" (file enclosed), my son's favourite game at age 6 years! 
I could open source files in BigMac but wasn't able to edit and compile, 
which I had done zillions of times in the 1980s… :-(  If you have new 
things too share I would be happy to convey the news to the group of 
Apple II fans in Marseille!

Bernard

Anthony Kozar wrote on 28/09/2020 03:08:
> Bernard,
>
> The play command has not been implemented yet.  These are the 
> commands/actions that I haven't gotten to yet: produce-items, play, 
> play-item, play-all, analyze-item, expand-item & show-beats.
>
> The syntax of the commands that you are trying look good though; i.e. 
> that is the syntax I am planning to implement for the play command, 
> loading -mi & -cs files, etc.
>
> I unfortunately haven't worked on BP during September.  The last thing 
> I was working on was the CoreMIDI driver and trying to decide what the 
> syntax for specifying CoreMIDI destinations with --rtmidi should be.  
> I got distracted writing a standalone tool to print out information 
> about all available CoreMIDI devices, sources, and destinations.  I 
> will probably add that functionality to the BP3 console app so that 
> users can determine the names of MIDI destinations that BP3 expects.
>
> My goal is to release a 3.0.0 version of BP console by the end of this 
> year.  But recently, I've been distracted by (re-)learning some Apple 
> II software and programming tools (among other things).  I will need 
> to make a real effort to reprioritize BP development during October in 
> order to meet my goal.  (The last five weeks or so of the year are 
> usually too busy to work on projects).
>
> There are number of things that I've been planning to discuss.  I'll 
> send another email shortly.
>
> Anthony
>
>
> On 9/27/20, 11:56 AM, Bernard Bel wrote:
>> Dear Anthony,
>>
>> The following are attempts of using the Play command to read a
>> "playthis.bpda" file that contains:
>>
>> // Bol Processor BP3 compatible with version BP2.9.8
>> // Data saved as "playthis.bpda". Date: 2020-09-27 15:47:13
>> {C4 D4 B3, A#3 G3}
>>
>> I tried to output as a Csound score "check_play.sco", as a MIDIfile
>> "check_play.mid" and as BP data file "essai_play.txt". None worked. The
>> last trial produced an empty "essai_play.txt" file.
>>
>> Is there something wrong in the syntax? I tried adding and removing
>> double quotes around paths.
>>
>> I skipped loading the "-se" file which produces the same non-effect…
>>
>> There is no emergency solving this problem… Just keep it on the agenda
>> if the solution isn't trivial! ;-)
>>
>> All the best
>>
>> Bernard
>>
>> ../bp play -da ../temp_bolprocessor/playthis.bpda -d --csoundout
>> "../ctests/check_play.sco"
>>
>>      Reading data file ../temp_bolprocessor/playthis.bpda...
>>      BP2 Console completed initialization.
>>      Random seed = 27263
>>      New project memory use: 60484 [leaked: 0]
>>      This session used 60 Kbytes maximum. 52 handles created and
>> released. [0 bytes leaked]
>>
>>
>> ../bp play -da ../temp_bolprocessor/playthis.bpda -d --midiout
>> ../ctests/check_play.mid
>>
>>      Reading data file ../temp_bolprocessor/playthis.bpda...
>>      BP2 Console completed initialization.
>>      Random seed = 24218
>>      New project memory use: 60484 [leaked: 0]
>>      This session used 60 Kbytes maximum. 52 handles created and
>> released. [0 bytes leaked]
>>
>>
>> ../bp play -da ../temp_bolprocessor/playthis.bpda -d -o
>> ../ctests/essai_play.txt
>>
>>      Reading data file ../temp_bolprocessor/playthis.bpda...
>>      BP2 Console completed initialization.
>>      Random seed = 9836
>>      Opening output file ../ctests/essai_play.txt
>>      New project memory use: 60484 [leaked: 0]
>>      This session used 60 Kbytes maximum. 52 handles created and
>> released. [0 bytes leaked]
>>      Closed output file ../ctests/essai_play.txt

Re: [bp-dev] PLAY command not working?

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

Bernard,

The play command has not been implemented yet.  These are the 
commands/actions that I haven't gotten to yet: produce-items, play, 
play-item, play-all, analyze-item, expand-item & show-beats.

The syntax of the commands that you are trying look good though; i.e. 
that is the syntax I am planning to implement for the play command, 
loading -mi & -cs files, etc.

I unfortunately haven't worked on BP during September.  The last thing I 
was working on was the CoreMIDI driver and trying to decide what the 
syntax for specifying CoreMIDI destinations with --rtmidi should be.  I 
got distracted writing a standalone tool to print out information about 
all available CoreMIDI devices, sources, and destinations.  I will 
probably add that functionality to the BP3 console app so that users can 
determine the names of MIDI destinations that BP3 expects.

My goal is to release a 3.0.0 version of BP console by the end of this 
year.  But recently, I've been distracted by (re-)learning some Apple II 
software and programming tools (among other things).  I will need to 
make a real effort to reprioritize BP development during October in 
order to meet my goal.  (The last five weeks or so of the year are 
usually too busy to work on projects).

There are number of things that I've been planning to discuss.  I'll 
send another email shortly.

Anthony


On 9/27/20, 11:56 AM, Bernard Bel wrote:
> Dear Anthony,
>
> The following are attempts of using the Play command to read a
> "playthis.bpda" file that contains:
>
> // Bol Processor BP3 compatible with version BP2.9.8
> // Data saved as "playthis.bpda". Date: 2020-09-27 15:47:13
> {C4 D4 B3, A#3 G3}
>
> I tried to output as a Csound score "check_play.sco", as a MIDIfile
> "check_play.mid" and as BP data file "essai_play.txt". None worked. The
> last trial produced an empty "essai_play.txt" file.
>
> Is there something wrong in the syntax? I tried adding and removing
> double quotes around paths.
>
> I skipped loading the "-se" file which produces the same non-effect…
>
> There is no emergency solving this problem… Just keep it on the agenda
> if the solution isn't trivial! ;-)
>
> All the best
>
> Bernard
>
> ../bp play -da ../temp_bolprocessor/playthis.bpda -d --csoundout
> "../ctests/check_play.sco"
>
>      Reading data file ../temp_bolprocessor/playthis.bpda...
>      BP2 Console completed initialization.
>      Random seed = 27263
>      New project memory use: 60484 [leaked: 0]
>      This session used 60 Kbytes maximum. 52 handles created and
> released. [0 bytes leaked]
>
>
> ../bp play -da ../temp_bolprocessor/playthis.bpda -d --midiout
> ../ctests/check_play.mid
>
>      Reading data file ../temp_bolprocessor/playthis.bpda...
>      BP2 Console completed initialization.
>      Random seed = 24218
>      New project memory use: 60484 [leaked: 0]
>      This session used 60 Kbytes maximum. 52 handles created and
> released. [0 bytes leaked]
>
>
> ../bp play -da ../temp_bolprocessor/playthis.bpda -d -o
> ../ctests/essai_play.txt
>
>      Reading data file ../temp_bolprocessor/playthis.bpda...
>      BP2 Console completed initialization.
>      Random seed = 9836
>      Opening output file ../ctests/essai_play.txt
>      New project memory use: 60484 [leaked: 0]
>      This session used 60 Kbytes maximum. 52 handles created and
> released. [0 bytes leaked]
>      Closed output file ../ctests/essai_play.txt

[bp-dev] PLAY command not working?

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

Dear Anthony,

The following are attempts of using the Play command to read a 
"playthis.bpda" file that contains:

// Bol Processor BP3 compatible with version BP2.9.8
// Data saved as "playthis.bpda". Date: 2020-09-27 15:47:13
{C4 D4 B3, A#3 G3}

I tried to output as a Csound score "check_play.sco", as a MIDIfile 
"check_play.mid" and as BP data file "essai_play.txt". None worked. The 
last trial produced an empty "essai_play.txt" file.

Is there something wrong in the syntax? I tried adding and removing 
double quotes around paths.

I skipped loading the "-se" file which produces the same non-effect…

There is no emergency solving this problem… Just keep it on the agenda 
if the solution isn't trivial! ;-)

All the best

Bernard

../bp play -da ../temp_bolprocessor/playthis.bpda -d --csoundout 
"../ctests/check_play.sco"

    Reading data file ../temp_bolprocessor/playthis.bpda...
    BP2 Console completed initialization.
    Random seed = 27263
    New project memory use: 60484 [leaked: 0]
    This session used 60 Kbytes maximum. 52 handles created and 
released. [0 bytes leaked]


../bp play -da ../temp_bolprocessor/playthis.bpda -d --midiout 
../ctests/check_play.mid

    Reading data file ../temp_bolprocessor/playthis.bpda...
    BP2 Console completed initialization.
    Random seed = 24218
    New project memory use: 60484 [leaked: 0]
    This session used 60 Kbytes maximum. 52 handles created and 
released. [0 bytes leaked]


../bp play -da ../temp_bolprocessor/playthis.bpda -d -o 
../ctests/essai_play.txt

    Reading data file ../temp_bolprocessor/playthis.bpda...
    BP2 Console completed initialization.
    Random seed = 9836
    Opening output file ../ctests/essai_play.txt
    New project memory use: 60484 [leaked: 0]
    This session used 60 Kbytes maximum. 52 handles created and 
released. [0 bytes leaked]
    Closed output file ../ctests/essai_play.txt

[bp-dev] Syntax of PLAY command

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

Dear all,

While working on "converting MIDI codes to a Csound score" in a 
sound-object prototype, I found that it would be difficult — and utterly 
useless! — to translate the C implementation of this algorithm to PHP. 
In any case, it is a bad idea to have the same algorithm in several 
places (and different languages)…

The good news is that we can use the console for this conversion. More 
precisely the PLAY command.

I have written the interface part on "prototype.php", which may still be 
modified to match the final syntax of the PLAY command.

Below is an example of a command creating Csound codes for sound-object 
prototype "machin" in file "-mi.tryCsoundObjects".

I copied the command as generated by "prototype.php". Paths of temporary 
files contain a long string mentioning the prototype string and the 
session ID. Here it goes:

../bp play -da 
../temp_bolprocessor/-mi.tryCsoundObjects_46b1bc344c81d6a7fba475870ce7f952_temp/machin.bpda 
-ho 
../temp_bolprocessor/-mi.tryCsoundObjects_46b1bc344c81d6a7fba475870ce7f952_temp/temp.bpho 
-mi "../ctests/-mi.tryCsoundObjects" -cs 
"../ctests/-cs.tryCsoundObjects" -d --csoundout 
../temp_bolprocessor/-mi.tryCsoundObjects_46b1bc344c81d6a7fba475870ce7f952_temp/machin_codes/csound.txt

Explanation:

• A temporary Bol Processor data file "machin.bpda" contains the 
standard header and only word "machin".
• A temporary Bol Processior alphabet file "temp.bpho" contains the 
standard header and the names of all sound-object prototypes defined in 
"-mi.tryCsoundObjects".
• File "-mi.tryCsoundObjects" will be called and its full path is 
between double quotes because such names might contain spaces.
• File "-cs.tryCsoundObjects" will be called and its full path is 
between double quotes because such names might contain spaces.
• The Csound output will be saved as "csound.txt" in the temporary folder.

When sending the command, the console replies that everything is correct 
except that it still ignores the "-mi" and "-cs" files. I take it for 
granted that the command will be completed when once files are taken 
into account.

I have set up the interface in the same way to "play" (in real-time 
MIDI) a polymetric expression entered on the "prototype.php" page.

I have an idea for replacing the "play selection" command in data and 
grammar files that will be workable in PHP. I am working on it now.

Bernard Bel

Re: [bp-dev] Timebase on PHP interface + algorithms

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

> On 26. Sep 2020, at 07:09, Bernard Bel <ber...@gm...> wrote:
> 
> It would be wise to commit this new version of the interface (https://bolprocessor.org/misc/BP3/bolprocessor_php.zip <https://bolprocessor.org/misc/BP3/bolprocessor_php.zip>) with the comment "Timebase polymetric expression”.

Done ;-)
Best
.r.

[bp-dev] Timebase on PHP interface + algorithms

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

Dear all,

I completed the PHP interface for editing Timebases. The main change is 
the automatic display of a polymetric expression equivalent to the 
rhythmic structure defined by the database. This may be used to design a 
"cyclic sound-object" replacing the timebase on top of the produced 
musical item:

https://bolprocessor.org/misc/BP3/CheckList.html#tickpatterns

I also decided to document all important algorithms used for the 
interface. This will facilitate the design of future interfaces. We 
should not rely on the designer's ability to "decode" PHP procedures.

For instance, the algorithm creating the polymetric expression 
associated with a timebase is documented here:

https://bolprocessor.org/timebase-to-polymetric/

It would be wise to commit this new version of the interface 
(https://bolprocessor.org/misc/BP3/bolprocessor_php.zip) with the 
comment "Timebase polymetric expression".

I am now working on the conversion of MIDI code sequences to Csound 
scores which is used in sound-object prototypes. I will document the 
algorithm in the same manner…

Pauses in the implementation of the console are helpful in allowing time 
for documentation and reflections on improving algorithms and the 
interface! :-)

Bernard Bel

Re: [bp-dev] Timebase on PHP interface + updated documentation

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

> While writing the documentation, I fixed a few problems in the MIDI file import. Therefore it would be wise to commit this new version with the comment "Fixing MIDI file import".

Done ;-)
.r.