bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] Standard-out output of bpconsole

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

Dear Rainer,

I worked on the consistency of paths so that they all relate to 
$bp_application_path which is the top of "bolprocessor". This was not 
the case and this explains a few bizarre displays you got.

Then I tried two cases, the results of which are shown on attached 
pictures.

Case 1 (which is the current one):
$bp_application_path = "..".DIRECTORY_SEPARATOR;

The picture shows the production of -gr.NotReich on a BP console pop-up 
window, and the output file "out.sco" on another pop-up window.

Case 2 (one of your suggestions):
$bp_application_path = dirname(getcwd()).DIRECTORY_SEPARATOR;

This makes all paths "absolute", i.e. related to the root created by MAMP.

The picture shows that the console responded (which may not be the case 
in Windows), the pop-up BP console opened but the pop-up "outs.sco" did 
not.

The reason is that javascript window.open() does not work if the URL 
provided for filling the window is an absolute one.

It accepts:
../my_output/out.sco

But it does not accept:
/Applications/MAMP/htdocs/try/bolprocessor/my_output/out.sco

I had faced this problem some time ago and decided to avoid absolute 
paths for that reason.

In the interface I have just committed I also set this:

define('SLASH',DIRECTORY_SEPARATOR);

so that you will see backslashes in your paths.

The "BP Help" and "Console help" links work on Mac in both cases.

I have difficulties following your explanation of the system-path 
solution. My guess is that you may want to call the console with "bp 
etc." instead of "../bp etc."

And may be replace relative links with absolute ones in the command 
line? The result would be:

bp produce -gr 
/Applications/MAMP/htdocs/try/bolprocessor/ctests/-gr.NotReich -se 
/Applications/MAMP/htdocs/try/bolprocessor/ctests/-se.NotReich -d 
--csoundout /Applications/MAMP/htdocs/try/bolprocessor/my_output/out.sco 
etc.

or the same with backslashes?

It is not difficult to modify URLs according to the operating system. I 
implemented a function that returns the OS platform, so it would be very 
easy to make conditional changes once we know exactly which syntax fits 
which system…

Regarding the Makefile, this sounds like a real mess! My guess is that 
we should distribute ready-compiled versions of the console and let the 
interface select the one fitting the operating system.

Bernard


Rainer Schuetz wrote on 07/10/2020 14:59:

> On 7. Oct 2020, at 07:33, Bernard Bel<ber...@gm...> wrote:
>
> Rainer Schuetz wrote on 06/10/2020 23:44:
>
>> For now I think the symbolic link approach works fine  - except - bad 
>> news, sorry to realise it so late - on Windows the php-frontend 
>> doesn’t receive the standard-out output of bpconsole - it’s there on 
>> the command-line, but php doesn’t get it… (and no, it’s not related 
>> to symlinking (which doesn’t work for the binary anyways), I tried 
>> all alternative ways of merging the repos).
> Dear Rainer,
>
> I am not 100%  sure about what you mean…
Sorry for unclear language. I think I understand what’s going wrong now, 
but symptoms first:

Currently - when I run the php-frontend - clicking “help” at the top of 
the index.php (where it says "or the console’s help-output") will open 
an empty browser window (well, the window contains “No message produced…”).
Likewise all links, that are supposed to display output from the console 
do not display anything in the popup Window.

No the reason, for the simple console-help case first:

The link calles produce.php?instruction=help, which in turn constructs 
the command "../bp --help" which is sent to the system. Unfortunately 
"../bp --help" doesn't work in Windows, even if I go to the command 
line, change to the php-frontend/php folder and type "../bp --help" the 
vision statement (humor!) doesn't appear, instead the system returns 
`'..' is not recognized as an internal or external command,
operable program or batch file.`. If I type `..\bp --help` instead, it 
works as expected. So while "/" generally works as a folder-level 
seperator in Windows, there seem to be corner cases, and one of them 
seems to be the ".." shortcut for parent directory.

Staying with the simple "help" case for now, I see four quick fix 
alternatives:

- let $application_path return a backslash on Windows (if - on Windows - 
I replace `$application_path = "..".SLASH;` by `$application_path = 
"..\\";` the vision statement is displayed properly. But it's not cross 
platform and you'd have to do a OS-check to control that literally 
yourself. No need, I think, PHP provides the means itself.
- use DIRECTORY_SEPARATOR instead, which should be crossplatform: 
`$application_path = "..".DIRECTORY_SEPARATOR;` works on Windows.
- let the frontend assume, that the bp executable is available in the 
system (or user) PATH (envir-var). So, if for the sake of this 
experiment, I add the bolprocessor folder to the system path (which 
makes bp.exe avaible to be called from anywhere), and I replace 
`$application_path = "..".SLASH;` by `$application_path = "";`, bare `bp 
--help` is constructed as command, and I do get output.
- make $application_path return the absolute path with the standard 
syntax of the current OS. `$application_path = 
dirname(getcwd()).DIRECTORY_SEPARATOR;` works on Windows and should be 
cross-platform.

The system-path solution is appealing for it's simplicity and 
flexibility, it allows to keep the bp-folder and the php-frontend folder 
totally separate, but it requires people to add the bolprocessor folder 
to the path, which might have side effects, and which might be 
difficult/confusing for some. The dirname(...) solution is nice in that 
it let's php decide how to expand getcwd. It would also work if there 
was a supported OS that doesn't use ".." at all. 
"..".DIRECTORY_SEPARATOR is midway between being totally literal and 
using some PHP-smartness.

I tend to using full PHP-smartness, though at some point, I think, one 
should consider more flexible ways of "adressing" a bp-executable.

So now to the complex constructed bp commands (I tried this while having 
replaced your $application_path assignment with: `$application_path = 
dirname(getcwd()).DIRECTORY_SEPARATOR;`):

Opening -gr.NotReich and pressing Produce item(s) constructs this command:

../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich-d 
--csoundout ../my_output/out.sco --traceout 
../temp_bolprocessor/trace_ee9b7331d6f62db3a5194abb54a84e1b.txt --seed 
15524

which fails for at least the constant use of "../" So at this point the 
bp-executable seems not to be addressed using $application_path any 
more, and all other paths continue to use the 
parent-dir-dots.forward-slash that doesn't work in Windows. 
Unfortunately I don't understand that $_GET and urldecode-stuff yet, so 
I can't make suggestions, but I can say that if above command is 
replaced by:

..\bp produce -gr ..\ctests\-gr.NotReich -se ..\ctests\-se.NotReich -d 
--csoundout ..\my_output\out.sco --traceout 
..\temp_bolprocessor\trace_ee9b7331d6f62db3a5194abb54a84e1b.txt --seed 
15524

on the command line in the php-folder at least it get's to:

Bol Processor console app
Version 2.999... (Oct5 2020)
This is a beta version for evaluation...
Reading grammar file ..\ctests\-gr.NotReich...
Error reading data from file.

If I do the  `define('SLASH',DIRECTORY_SEPARATOR);` "trick" in 
_basic_tasks.php, I get this constructed command:

command = ../bp produce -gr ..\ctests\-gr.NotReich -se -se.NotReich-d 
--csoundout ../\my_output\out.sco --traceout 
..\temp_bolprocessor\trace_ee9b7331d6f62db3a5194abb54a84e1b.txt --seed 
15524

So it seems there seems to be some inconsistency left in path 
construction...

So much from me right now, a combination of not understanding the more 
complex parts of the code and lack of time require me to stop. I guess 
if this path construction is cleaned up, there might be more detective 
work necessary to find out if some of the complex commands on Windows 
don't work at expected even though they are executed with correct paths.

Best
.r.

PS: as to "make". I think of make/Makefile as belonging gcc. That is not 
actually true, but in practice it's what mostly happens (?). Make is an 
executable (on MacOS it's in /usr/bin/make) that interprets a file 
called "Makefile" that resides in the root-folder of the project to be 
built (look it up, it's quite transparent) in order to automate all the 
steps of the build. It's consdered native on Linux. I can work on MacOS, 
but the "native" compiler of MacOS is Apple clang, and the native 
toolchain is Xcode, using the xcodeproj-files Anthony has stored in the 
BP2 folder instead of make + Makefile. On Windows the situation is more 
difficult. You can't just install gcc and then use make like on MacOS 
because make expects a posix environment and tools that won't work in 
the Windows environment. Yes, there is mingw, which basically is a gcc 
that works in Windows natively, but it cannot be used with "make", 
because of said reasons. Therefore environments like msys, msys2 or 
cygwin were created, that allow to run all the build (automation) tools 
in Windows by emulating a unixy enviroment. msys and msys2 surpass 
cygwin in that they produce executables that*once built*  can run in the 
native Windows environment. That is how I use bp.exe in Windows.

Now, MAMP, i.e. Apache and PHP run in the native Windows enviroment and 
expect bp to behave like a native Windows app. As such, you cannot 
compile bp.exe using the "make"-approach. You'd need to switch to that 
dedicated, unixy "build-environment". That might actually be possible 
(provided a lot of preconditions are met), but it's far from trivial, 
not even easy. The bottom line, I think, is: Making compile by make part 
of the php-interface isn't likely to work in more than very few 
use-cases. The "normal" MacOS user will want to use Xcode, the 
Windows-user will be forced to build in a "for building only", emulated 
environment - in both cases make won't work the way you envision it. And 
even on Linux (likely the smallest user-group) installing the toolchain 
isn't something that comes natural to the majority of the users. So tbh 
I am sceptical that compiling from the php-interface covers any 
practical use case: the ones who can install gcc in a non-native 
environment, will always also be able (and prefer!) to compile from the 
command-line.


> Enclosed is the display of what you should see after clicking the 
> PRODUCE ITEM(s) button on grammar "-gr.NotReich". It creates a pop-up 
> window named "BP console" and displays the output.
>
> The process is the following (in produce.php):
>
> exec($command,$o);
> $n_messages = count($o);
> $no_error = FALSE;
> for($i = 0; $i < $n_messages; $i++) {
>     $mssg = $o[$i];
>     if(is_integer($pos=strpos($mssg,"Errors: 0")) AND $pos == 0) 
> $no_error = TRUE;
>     }
>
> This runs the console command displayed in red on top of BP console.
> Then it checks whether "Errors: 0" was found in one of the messages.
>
> After displaying links to output file and if necessary to the trace 
> file, it displays all messages in a standard way:
>
> for($i = 0; $i < $n_messages; $i++) {
>     $mssg = $o[$i];
>     $mssg = clean_up_encoding(TRUE,$mssg);
>     echo $mssg."<br />";
>     }
>
> clean_up_encoding() is a function that replaces garbage signs with the 
> correct UTF-8 ones (in _basic_tasks.php):
>
> function clean_up_encoding($convert,$text) {
>     if($convert) $text = mb_convert_encoding($text, "UTF-8", 
> mb_detect_encoding($text, "UTF-8, ISO-8859-1, ISO-8859-15", true));
>     $text = str_replace("¥","•",$text);
>     $text = str_replace("Ô","‘",$text);
>     $text = str_replace("Õ","’",$text);
>     $text = str_replace("Ò","“",$text);
>     $text = str_replace("Ó","”",$text);
>     $text = str_replace("É","…",$text);
>     $text = str_replace("Â","¬",$text);
>     $text = str_replace("¤","•",$text);
>     $text = str_replace("•","•",$text);
>     $text = str_replace(" . ","•",$text);
>     $text = str_replace("²","≤",$text);
>     $text = str_replace("³","≥",$text);
>     return $text;
>     }
>
> On this particular example, clean_up_encoding() does nothing and could 
> be ignored.
>
> The only thing I guess might not work in a different environment is 
> the pop-up window opening — which would be very, very troublesome…
>
> Let us sort out this problem, if confirmed!
>
> Bernard
>
> <Screen Shot 2020-10-07 at 07.17.17 
> (2).png>_______________________________________________
> 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

Re: [bp-dev] Work on graphics - problem with branch

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

> On 7. Oct 2020, at 15:36, Bernard Bel <ber...@gm...> wrote:
> 
> Dear all,
> 
> I created a new branch for implementing graphics on the console. Its URL is:
> https://github.com/bolprocessor/bolprocessor/tree/graphics-for-BP3

You don't actually work with the URL that a branch of a repo has in the Github interface. And you don't clone a branch, you only clone a repo once, all branches are contained within the repo. The one thing necessary though is to sync branches between the local and the remote repo. If you create a branch on the remote in a web interface (not really common practice at all), you need to make your local repo now about it by fetching from the remote (in the one-remote case):

git fetch

And then you can checkout that branch like:

git checkout graphics-for-BP3

I think apart from an amusingly non-conventional approach you also made a mistake: when you "start" a new branch, an important question is, "from where" to start the branch, because the branch will contain all commits preceding that "from where" point. Without knowing so, you created the branch "from the head of master" - which means, all the bp3 stuff is not conained in your branch. That is not what you wanted, right?

I'd recommend:

delete the created branch in the web interface - it will be gone without a trace...

Have you already cloned the bolprocessor repo? If not, do so now:

git clone https://github.com/bolprocessor/bolprocessor <https://github.com/bolprocessor/bolprocessor> yourPreferredFoldername

change into that folder

checkout the bp3-develop branch, to get to the starting point, from which you want your new branch to start:

git checkout bp3-develop // it'll tell you someting about setting up a tracking relation

At this point create the new branch:

git branch graphics-for-BP3

You still need to check that branch out:

git checkout graphics-for-BP3

Now you could start developing - no need actually to push, until you "have" something you want to commit... (but you could, in order to create the branch on the remote as well):

git push --set-upstream origin graphics-for-BP3

That should create the branch in the bolprocessor repo. From now on a simple `git push` should do the job.

Best
.r.


> 
> Now I am trying a "git clone" to work on these files locally, but it does not find the repository of that branch:
> 
> git clone https://github.com/bolprocessor/bolprocessor/tree/graphics-for-BP3 graphics-for-BP3
> Cloning into 'graphics-for-BP3'...
> fatal: repository 'https://github.com/bolprocessor/bolprocessor/tree/graphics-for-BP3/' not found
> macbookpro-bernard:BPCONSOLE bernardbel$
> 
> Otherwise I've been able to do:
> git clone https://github.com/bolprocessor/bolprocessor console_git
> 
> and got all files in "console_git", but this was the master branch…
> 
> In fact I haven't found documentation on pushing/pulling inside a branch!
> 
> Bernard
> 
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Work on graphics - problem with branch

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

Dear all,

I created a new branch for implementing graphics on the console. Its URL is:
https://github.com/bolprocessor/bolprocessor/tree/graphics-for-BP3

Now I am trying a "git clone" to work on these files locally, but it 
does not find the repository of that branch:

git clone 
https://github.com/bolprocessor/bolprocessor/tree/graphics-for-BP3 
graphics-for-BP3
Cloning into 'graphics-for-BP3'...
fatal: repository 
'https://github.com/bolprocessor/bolprocessor/tree/graphics-for-BP3/' 
not found
macbookpro-bernard:BPCONSOLE bernardbel$

Otherwise I've been able to do:
git clone https://github.com/bolprocessor/bolprocessor console_git

and got all files in "console_git", but this was the master branch…

In fact I haven't found documentation on pushing/pulling inside a branch!

Bernard

Re: [bp-dev] Standard-out output of bpconsole

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

> On 7. Oct 2020, at 07:33, Bernard Bel <ber...@gm...> wrote:
> 
> Rainer Schuetz wrote on 06/10/2020 23:44:
> 
>> For now I think the symbolic link approach works fine  - except - bad news, sorry to realise it so late - on Windows the php-frontend doesn’t receive the standard-out output of bpconsole - it’s there on the command-line, but php doesn’t get it… (and no, it’s not related to symlinking (which doesn’t work for the binary anyways), I tried all alternative ways of merging the repos).
> 
> Dear Rainer,
> 
> I am not 100%  sure about what you mean…

Sorry for unclear language. I think I understand what’s going wrong now, but symptoms first:

Currently - when I run the php-frontend - clicking “help” at the top of the index.php (where it says "or the console’s help-output") will open an empty browser window (well, the window contains “No message produced…”).
Likewise all links, that are supposed to display output from the console do not display anything in the popup Window.

No the reason, for the simple console-help case first:

The link calles produce.php?instruction=help, which in turn constructs the command "../bp --help" which is sent to the system. Unfortunately "../bp --help" doesn't work in Windows, even if I go to the command line, change to the php-frontend/php folder and type "../bp --help" the vision statement (humor!) doesn't appear, instead the system returns `'..' is not recognized as an internal or external command,
operable program or batch file.`. If I type `..\bp --help` instead, it works as expected. So while "/" generally works as a folder-level seperator in Windows, there seem to be corner cases, and one of them seems to be the ".." shortcut for parent directory.

Staying with the simple "help" case for now, I see four quick fix alternatives:

- let $application_path return a backslash on Windows (if - on Windows - I replace `$application_path = "..".SLASH;` by `$application_path = "..\\";` the vision statement is displayed properly. But it's not cross platform and you'd have to do a OS-check to control that literally yourself. No need, I think, PHP provides the means itself.
- use DIRECTORY_SEPARATOR instead, which should be crossplatform: `$application_path = "..".DIRECTORY_SEPARATOR;` works on Windows.
- let the frontend assume, that the bp executable is available in the system (or user) PATH (envir-var). So, if for the sake of this experiment, I add the bolprocessor folder to the system path (which makes bp.exe avaible to be called from anywhere), and I replace `$application_path = "..".SLASH;` by `$application_path = "";`, bare `bp --help` is constructed as command, and I do get output. 
- make $application_path return the absolute path with the standard syntax of the current OS. `$application_path = dirname(getcwd()).DIRECTORY_SEPARATOR;` works on Windows and should be cross-platform.

The system-path solution is appealing for it's simplicity and flexibility, it allows to keep the bp-folder and the php-frontend folder totally separate, but it requires people to add the bolprocessor folder to the path, which might have side effects, and which might be difficult/confusing for some. The dirname(...) solution is nice in that it let's php decide how to expand getcwd. It would also work if there was a supported OS that doesn't use ".." at all. "..".DIRECTORY_SEPARATOR is midway between being totally literal and using some PHP-smartness.

I tend to using full PHP-smartness, though at some point, I think, one should consider more flexible ways of "adressing" a bp-executable. 

So now to the complex constructed bp commands (I tried this while having replaced your $application_path assignment with: `$application_path = dirname(getcwd()).DIRECTORY_SEPARATOR;`):

Opening -gr.NotReich and pressing Produce item(s) constructs this command:

../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d --csoundout ../my_output/out.sco --traceout ../temp_bolprocessor/trace_ee9b7331d6f62db3a5194abb54a84e1b.txt --seed 15524

which fails for at least the constant use of "../" So at this point the bp-executable seems not to be addressed using $application_path any more, and all other paths continue to use the parent-dir-dots.forward-slash that doesn't work in Windows. Unfortunately I don't understand that $_GET and urldecode-stuff yet, so I can't make suggestions, but I can say that if above command is replaced by:

..\bp produce -gr ..\ctests\-gr.NotReich -se ..\ctests\-se.NotReich -d --csoundout ..\my_output\out.sco --traceout ..\temp_bolprocessor\trace_ee9b7331d6f62db3a5194abb54a84e1b.txt --seed 15524

on the command line in the php-folder at least it get's to:

Bol Processor console app
Version 2.999... (Oct  5 2020)
This is a beta version for evaluation...
Reading grammar file ..\ctests\-gr.NotReich...
Error reading data from file.

If I do the  `define('SLASH',DIRECTORY_SEPARATOR);` "trick" in _basic_tasks.php, I get this constructed command:

command = ../bp produce -gr ..\ctests\-gr.NotReich -se -se.NotReich -d --csoundout ../\my_output\out.sco --traceout ..\temp_bolprocessor\trace_ee9b7331d6f62db3a5194abb54a84e1b.txt --seed 15524

So it seems there seems to be some inconsistency left in path construction...

So much from me right now, a combination of not understanding the more complex parts of the code and lack of time require me to stop. I guess if this path construction is cleaned up, there might be more detective work necessary to find out if some of the complex commands on Windows don't work at expected even though they are executed with correct paths.

Best
.r.

PS: as to "make". I think of make/Makefile as belonging gcc. That is not actually true, but in practice it's what mostly happens (?). Make is an executable (on MacOS it's in /usr/bin/make) that interprets a file called "Makefile" that resides in the root-folder of the project to be built (look it up, it's quite transparent) in order to automate all the steps of the build. It's consdered native on Linux. I can work on MacOS, but the "native" compiler of MacOS is Apple clang, and the native toolchain is Xcode, using the xcodeproj-files Anthony has stored in the BP2 folder instead of make + Makefile. On Windows the situation is more difficult. You can't just install gcc and then use make like on MacOS because make expects a posix environment and tools that won't work in the Windows environment. Yes, there is mingw, which basically is a gcc that works in Windows natively, but it cannot be used with "make", because of said reasons. Therefore environments like msys, msys2 or cygwin were created, that allow to run all the build (automation) tools in Windows by emulating a unixy enviroment. msys and msys2 surpass cygwin in that they produce executables that *once built* can run in the native Windows environment. That is how I use bp.exe in Windows.

Now, MAMP, i.e. Apache and PHP run in the native Windows enviroment and expect bp to behave like a native Windows app. As such, you cannot compile bp.exe using the "make"-approach. You'd need to switch to that dedicated, unixy "build-environment". That might actually be possible (provided a lot of preconditions are met), but it's far from trivial, not even easy ;-). The bottom line, I think, is: Making compile by make part of the php-interface isn't likely to work in more than very few use-cases. The "normal" MacOS user will want to use Xcode, the Windows-user will be forced to build in a "for building only", emulated environment - in both cases make won't work the way you envision it. And even on Linux (likely the smallest user-group) installing the toolchain isn't something that comes natural to the majority of the users. So tbh I am sceptical that compiling from the php-interface covers any practical use case: the ones who can install gcc in a non-native environment, will always also be able (and prefer!) to compile from the command-line.


> 
> Enclosed is the display of what you should see after clicking the PRODUCE ITEM(s) button on grammar "-gr.NotReich". It creates a pop-up window named "BP console" and displays the output.
> 
> The process is the following (in produce.php):
> 
> exec($command,$o);
> $n_messages = count($o);
> $no_error = FALSE;
> for($i = 0; $i < $n_messages; $i++) {
> 	$mssg = $o[$i];
> 	if(is_integer($pos=strpos($mssg,"Errors: 0")) AND $pos == 0) $no_error = TRUE;
> 	}
> 
> This runs the console command displayed in red on top of BP console.
> Then it checks whether "Errors: 0" was found in one of the messages.
> 
> After displaying links to output file and if necessary to the trace file, it displays all messages in a standard way:
> 
> for($i = 0; $i < $n_messages; $i++) {
> 	$mssg = $o[$i];
> 	$mssg = clean_up_encoding(TRUE,$mssg);
> 	echo $mssg."<br />";
> 	}
> 
> clean_up_encoding() is a function that replaces garbage signs with the correct UTF-8 ones (in _basic_tasks.php):
> 
> function clean_up_encoding($convert,$text) {
> 	if($convert) $text = mb_convert_encoding($text, "UTF-8", mb_detect_encoding($text, "UTF-8, ISO-8859-1, ISO-8859-15", true));
> 	$text = str_replace("¥","•",$text);
> 	$text = str_replace("Ô","‘",$text);
> 	$text = str_replace("Õ","’",$text);
> 	$text = str_replace("Ò","“",$text);
> 	$text = str_replace("Ó","”",$text);
> 	$text = str_replace("É","…",$text);
> 	$text = str_replace("Â","¬",$text);
> 	$text = str_replace("¤","•",$text);
> 	$text = str_replace("•","•",$text);
> 	$text = str_replace(" . ","•",$text);
> 	$text = str_replace("²","≤",$text);
> 	$text = str_replace("³","≥",$text);
> 	return $text;
> 	}
> 
> On this particular example, clean_up_encoding() does nothing and could be ignored.
> 
> The only thing I guess might not work in a different environment is the pop-up window opening — which would be very, very troublesome…
> 
> Let us sort out this problem, if confirmed!
> 
> Bernard
> 
> <Screen Shot 2020-10-07 at 07.17.17 (2).png>_______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Work on graphics

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

Rainer Schuetz wrote on 06/10/2020 23:44:

> It’s your (Bernard) choice of course, but I think you’re missing out on opportunities if you don’t  Maybe my sentence “be considerate” when committing sounded intimidating (or even patronising), sorry if so. My git intro up to now might have focused on “push” too much, really “pull” is as important. And if Anthony knows you just need to do “git pull” (well, yea, maybe with a few arguments  ) to try something he did, that’s a lot easier than uploading a snapshot, and then downloading and extracting it - maybe needing to assemble a working environment. With git pull you can just stay in your given environment. As to the risk: in highly formalised and policy-driven workflows one tries at all cost to prevent accidental pushes to master, but I think at this stage one needn’t be too sensitive about it. And really, as Anthony demonstrated, the way out is simple: the (90% safe) keyword is “branch". In this context is is good to stress that “pushing” is by default done “per branch” - i.e. if you work in a branch, and you “push”, only commits in that branch are pushed. So if you’re working in “new-graphics” you might never have to switch to master (or “main” - the new default name for the primary branch, trying to avoid discriminatory language), and whatever is in “master” (or BP3-develop) won’t be affected by “git push”.

I did not feel shy to take part in this push-pull process on the 
console… ;-) My only concern was to interfere with Anthony's work, for 
instance if I had tried to change code in the real-time MIDI implementation.

Working on graphics is entirely independent on MIDI procedures, so I 
feel safe to do the work on a separate branch.

My initial problem will be to display an empty window and install GD 
graphics properly. I hope to find tutorials and simple examples… Doing 
the picture by itself won't be complicated.

This will be my next project because there isn't much to add to the PHP 
interface at the moment.

Bernard

[bp-dev] Compilation and pre-compilation

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

Rainer Schuetz wrote on 06/10/2020 23:44:

> Ultimately I think the goal should be to consolidate that ctests folder so much, that it gets a fixed place and static purpose in the “bolprocessor” repo, and the php-frontend should become a single simple folder … but there is no urgency at all I think.

On top of https://bolprocessor.org/check-bp3/ the installation procedure 
is explained and the small picture summarizes it… I doubt that it would 
be difficult for users who have been able to install and sett up MAMP. 
At the moment, our target "clients" are more clever than ordinary 
musicians (joke!)

I added automatic tests on the top of the php/index.php page. It checks 
whether "bp" has been found in the right place and whether it responds 
to the "--help" command. If not, it tries to find the "source" folder. 
If successful it provides a link to the "compile.php" page. If not found 
it tells the user to return to 
https://bolprocessor.org/check-bp3/#install and check their installation.

Now I have questions about compiling. Let's agree that all files have 
been downloaded from bolprocessor-BP3-develop.zip

1) I assume that running "make" will produce a "bp" binary compatible 
with the current environment. I mean, are there different "Makefile" for 
different environments?

2) It may be a good idea to distribute precompiled versions in 
"bolprocessor-BP3-develop.zip". I guess bp, bp16, bp32, bp.exe etc. In 
this case I would modify the home page index.php to try to run 
"<version> --help" on every version and collect the answer silently. 
Once it gets a correct answer it would guess which version runs in the 
environnment and save it in settings. All this would remain invsible 
except when no version replies, in which case we would again have the 
option of recompiling ‘bp’.

Bernard

[bp-dev] Standard-out output of bpconsole

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

Rainer Schuetz wrote on 06/10/2020 23:44:

> For now I think the symbolic link approach works fine  - except - bad news, sorry to realise it so late - on Windows the php-frontend doesn’t receive the standard-out output of bpconsole - it’s there on the command-line, but php doesn’t get it… (and no, it’s not related to symlinking (which doesn’t work for the binary anyways), I tried all alternative ways of merging the repos).

Dear Rainer,

I am not 100%  sure about what you mean…

Enclosed is the display of what you should see after clicking the 
PRODUCE ITEM(s) button on grammar "-gr.NotReich". It creates a pop-up 
window named "BP console" and displays the output.

The process is the following (in produce.php):

exec($command,$o);
$n_messages = count($o);
$no_error = FALSE;
for($i = 0; $i < $n_messages; $i++) {
	$mssg = $o[$i];
	if(is_integer($pos=strpos($mssg,"Errors: 0")) AND $pos == 0) $no_error 
= TRUE;
	}

This runs the console command displayed in red on top of BP console.
Then it checks whether "Errors: 0" was found in one of the messages.

After displaying links to output file and if necessary to the trace 
file, it displays all messages in a standard way:

for($i = 0; $i < $n_messages; $i++) {
	$mssg = $o[$i];
	$mssg = clean_up_encoding(TRUE,$mssg);
	echo $mssg."<br />";
	}

clean_up_encoding() is a function that replaces garbage signs with the 
correct UTF-8 ones (in _basic_tasks.php):

function clean_up_encoding($convert,$text) {
	if($convert) $text = mb_convert_encoding($text, "UTF-8", 
mb_detect_encoding($text, "UTF-8, ISO-8859-1, ISO-8859-15", true));
	$text = str_replace("¥","•",$text);
	$text = str_replace("Ô","‘",$text);
	$text = str_replace("Õ","’",$text);
	$text = str_replace("Ò","“",$text);
	$text = str_replace("Ó","”",$text);
	$text = str_replace("É","…",$text);
	$text = str_replace("Â","¬",$text);
	$text = str_replace("¤","•",$text);
	$text = str_replace("•","•",$text);
	$text = str_replace(" . ","•",$text);
	$text = str_replace("²","≤",$text);
	$text = str_replace("³","≥",$text);
	return $text;
	}

On this particular example, clean_up_encoding() does nothing and could 
be ignored.

The only thing I guess might not work in a different environment is the 
pop-up window opening — which would be very, very troublesome…

Let us sort out this problem, if confirmed!

Bernard

Re: [bp-dev] GitHub migration

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

Dear Bernard and Anthony,

>  It would be nice if we didn't have to rearrange files or folders to get the repositories to work together…

For now I think the symbolic link approach works fine  - except - bad news, sorry to realise it so late - on Windows the php-frontend doesn’t receive the standard-out output of bpconsole - it’s there on the command-line, but php doesn’t get it… (and no, it’s not related to symlinking (which doesn’t work for the binary anyways), I tried all alternative ways of merging the repos). Ultimately I think the goal should be to consolidate that ctests folder so much, that it gets a fixed place and static purpose in the “bolprocessor” repo, and the php-frontend should become a single simple folder … but there is no urgency at all I think.

> It is my intention going forward that the BP3-develop branch will always compile and work.  The advantage of my "development snapshots" though was that they contained already compiled binaries.

While it’s not “canonical”, and it doesn’t make sense from a text based “source-control”-logic, I am pretty sure it is possible to add binaries to a git repo (I believe to have seen and used such repos. That “miss”-use implies a lot of trust, of course, but so do private distributions). The nice thing about the bp binary is that it still runs without requiring additional libraries or a specific install location. And as the file is still quite small I think it would actually be nice to add it for the time being. The ones for whom the binaries won’t work will have to install a toolchain anyways.

> I would like to get setup again for cross-compiling Windows binaries so that I can include a bp.exe as well.

Until you have that, I am happy to send you a binary if you want.

>> I will not pull the https://github.com/bolprocessor/bolprocessor to my
>> personal computer for the time being. I may need to do it later when
>> implementing new graphic procedures…
> 
> No problem.  You can start working on the new graphics whenever you wish.  If you checkout the BP3-develop branch and then create a new branch from that point, you shouldn't interfere with anything that I am working on.  Something like
> 
> git clone https://github.com/bolprocessor/bolprocessor.git
cd bolprocessor
> git checkout BP3-develop
> git branch new-graphics // this *creates* a new branch that contains everything in BP3-develop, at the moment (or commit) you created the branch. from now on these to diverge until they are merged again.
> git checkout new-graphics // creating a branch doesn’t automatically switch to it, respectively “check it out” (from .git), that is why this step is necessary.

It’s your (Bernard) choice of course, but I think you’re missing out on opportunities if you don’t ;-) Maybe my sentence “be considerate” when committing sounded intimidating (or even patronising), sorry if so. My git intro up to now might have focused on “push” too much, really “pull” is as important. And if Anthony knows you just need to do “git pull” (well, yea, maybe with a few arguments ;-) ) to try something he did, that’s a lot easier than uploading a snapshot, and then downloading and extracting it - maybe needing to assemble a working environment. With git pull you can just stay in your given environment. As to the risk: in highly formalised and policy-driven workflows one tries at all cost to prevent accidental pushes to master, but I think at this stage one needn’t be too sensitive about it. And really, as Anthony demonstrated, the way out is simple: the (90% safe) keyword is “branch". In this context is is good to stress that “pushing” is by default done “per branch” - i.e. if you work in a branch, and you “push”, only commits in that branch are pushed. So if you’re working in “new-graphics” you might never have to switch to master (or “main” - the new default name for the primary branch, trying to avoid discriminatory language), and whatever is in “master” (or BP3-develop) won’t be affected by “git push”.

> If you would be more comfortable with a GUI interface for Git, there are several out there for macOS.  I like GitX.  

Another interesting option is to use modern text-editors with git support. I highly recommend vscode, yes, it’s from MS$ - but it’s free, both gratis and libre, and it’s a brilliant editor with excellent git-integration (both faster and conceptually more integrative than the quite similar Atom). I personally find dedicated git-frontends rather confusing than helpful, but that is obviously a personal thingy ;-)

Best
.r.

Re: [bp-dev] GitHub migration

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

See below...

On 10/6/20, 10:02 AM, Bernard Bel wrote:
> Thank you for clarifications!
>
> I created and uploaded https://github.com/bolprocessor/bp3-ctests/
>
> Then I updated installation instructions in
> https://bolprocessor.org/check-bp3/ so that all zip files are taken from
> the GitHub repositories. Notably the console's code is now coming from
> https://github.com/bolprocessor/bolprocessor/archive/BP3-develop.zip

Great!  I've checked out all three repositories, side-by-side.  I'll see 
about testing it soon.  It would be nice if we didn't have to rearrange 
files or folders to get the repositories to work together...

> We may suppose that the “BP3-develop”-branch contains a version that
> compiles and work… If this were not the case I would revert to
> http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip.

It is my intention going forward that the BP3-develop branch will always 
compile and work.  The advantage of my "development snapshots" though 
was that they contained already compiled binaries.  The "bp32" and 
"bp64" binaries should work on OS X 10.6 or later and the "bp" binary on 
10.11 or later.  So for most macOS users, it shouldn't be necessary to 
recompile the console app when using that snapshot.

I would like to get setup again for cross-compiling Windows binaries so 
that I can include a bp.exe as well.

> I will not pull the https://github.com/bolprocessor/bolprocessor to my
> personal computer for the time being. I may need to do it later when
> implementing new graphic procedures…

No problem.  You can start working on the new graphics whenever you 
wish.  If you checkout the BP3-develop branch and then create a new 
branch from that point, you shouldn't interfere with anything that I am 
working on.  Something like

git clone https://github.com/bolprocessor/bolprocessor.git
git checkout BP3-develop
git branch new-graphics
git checkout new-graphics

After you've made some commits on the new branch, you can push the 
branch to GitHub with

git push --set-upstream origin new-graphics

The --set-upstream option is only needed the first time you push.  After 
that you can just use "git push" as long as you are on the new-graphics 
branch.

If you would be more comfortable with a GUI interface for Git, there are 
several out there for macOS.  I like GitX.  It is simple and far from a 
full GUI for Git but it is nice for simple workflows.  I still have to 
use the commandline for pushing, pulling, and merging but GitX has a 
very nice interface for selectively committing changes and for 
visualizing the history of a repository.  There are several forks of 
GitX out there.  I'm still using the older (original?) version from

http://gitx.frim.nl/

But there are newer versions which appear to have more features from 
these two forks on GitHub:

https://github.com/rowanj/gitx/releases

https://github.com/gitx/gitx/releases

>>> To avoid any confusion, "ctests" should be deleted
>>> from http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip

I will do that for the next snapshot.

>>> Once we have done these changes, all download links on
>>> pagehttps://bolprocessor.org/check-bp3/would point
>>> athttps://github.com/bolprocessor/.

That's fine.  I'm sure at this stage that most interested testers can 
handle running "make" if they can handle setting up a MAMP server. :)

Anthony

Re: [bp-dev] Looking inside MIDI files with Hex Fiend

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

It works enough for checking MIDIfiles produced by our  devices because 
we never use running status, which was a savings scheme at the time 
memory space and connexion speed were critical. If I remember well, 
however, we need to be able to deal with running status at the input. I 
am not sure a template would be suitable for this: there is no 
declaration of how many bytes will stay in that status — as it makes 
sense in real-time communication — the only warning that it is finished 
being a status byte. So, you need to wait untill a byte is received with 
value greater than (127 ?).

The 0x21 is appaarently a meta-event for displaying text. "Midi Class" 
displays them as follows in MF2T code:

MTrk
0 Meta 0x21 00
0 Meta TrkName "sequenced by:"
0 Meta TrkEnd
TrkEnd
MTrk
0 Meta 0x21 00
0 Meta TrkName "Don Carroll"
0 Meta TrkEnd
TrkEnd
MTrk
0 Meta 0x21 00
0 Meta TrkName "Houston, Texas"
0 Meta TrkEnd
TrkEnd
MTrk
0 Meta 0x21 00
0 Meta TrkName "do...@ix..."
0 Meta TrkEnd
TrkEnd



Anthony Kozar wrote on 06/10/2020 17:37:
> Thanks! There was a bug in my code when looking up the name of a 
> meta-event.  I've corrected this bug in the attached version of the 
> template.  (I've no idea what meta 0x21 is and apparently MF2T does 
> not recognize it either.  But it was helpful to find this bug! :)
>
> Unfortunately, while my template now runs it still will not decode the 
> MIDI file you sent completely correctly.  The file appears to use the 
> "running status" feature which my template doesn't support yet.  As a 
> result you will see lots of events with blank summaries and invalid 
> "event type" fields.  But this should be a very good test file for 
> improving the template with its 10 tracks and lots of different event 
> types.
>
> I'll let you know whenever I have an improved template.
>
> Thanks!
>
> Anthony
>
>
> On 10/6/20, 10:21 AM, Bernard Bel wrote:
>> Yes! After selecting "refresh" it worked… The Option key trick also 
>> worked.
>>
>> However it did not work with the enclosed "this_song.mid" MIDI file
>> which is correctly interpreted by "sound-object prototype" and
>> "timebase" pages. This file wasn't created by BP. The beginning of this
>> file in MF2T format (after trackname fixes of the the interface) is:
>>
>> MFile 1 10 444.444
>> MTrk
>> 0 Meta TrkName "untitled"
>> 0 SMPTE 96 0 3 0 0
>> 0 TimeSig 4/4 24 8
>> 0 KeySig 255 major
>> 0 Tempo 444444
>> 21333 TimeSig 3/4 24 8
>> 22667 TimeSig 4/4 24 8
>> 31556 TimeSig 3/4 24 8
>> 34222 TimeSig 4/4 24 8
>> 46667 TimeSig 3/4 24 8
>> 49333 TimeSig 4/4 24 8
>> 13798 Tempo 444444
>> 13802 Tempo 454545
>> 13808 Tempo 451128
>> 13810 Tempo 461538
>> 13818 Tempo 465116
>> 13826 Tempo 468750
>> 13836 Tempo 472441
>> 13844 Tempo 476190
>> 13852 Tempo 480000
>> 13858 Tempo 483871
>> 13886 Tempo 487805
>> 13894 Tempo 491803
>> 13904 Tempo 495868
>> 13920 Tempo 500000
>> 13932 Tempo 504202
>> 13950 Tempo 508475
>> 13958 Tempo 512821
>> 13970 Tempo 517241
>> 13988 Tempo 521739
>> 13996 Tempo 526316
>> 14012 Tempo 530973
>> 14022 Tempo 535714
>> 14038 Tempo 540541
>> 14050 Tempo 545455
>> 14060 Tempo 550459
>> 14078 Tempo 555556
>> 14100 Tempo 560748
>> 14114 Tempo 566038
>> 14126 Tempo 571429
>> 14138 Tempo 576923
>> 14158 Tempo 582524
>> 14168 Tempo 588235
>> 14184 Tempo 594059
>> 14198 Tempo 600000
>> 14216 Tempo 606061
>> 14232 Tempo 612245
>> 58222 TimeSig 3/4 24 8
>> 59555 TimeSig 4/4 24 8
>> 63111 TimeSig 3/4 24 8
>> 65778 TimeSig 4/4 24 8
>> 74667 TimeSig 3/4 24 8
>> 77333 TimeSig 4/4 24 8
>> 80889 TimeSig 3/4 24 8
>> 83555 TimeSig 4/4 24 8
>> 83555 Meta TrkEnd
>> TrkEnd
>> MTrk
>> 0 Meta TrkName "imported_1"
>> 0 Meta 0x21 00
>> 0 Meta TrkName "SOPSAX 166"
>> 0 PrCh ch=1 p=64
>> 0 Par ch=1 c=7 v=120
>> 0 Par ch=1 c=10 v=20
>> 0 Par ch=1 c=64 v=0
>> 0 Pb ch=1 v=8192
>> 1333 On ch=1 n=72 v=125
>> 1552 On ch=1 n=72 v=0
>> 1556 On ch=1 n=72 v=125
>> 1774 On ch=1 n=72 v=0
>> 1778 On ch=1 n=72 v=125
>>
>>
>> Bernard
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Looking inside MIDI files with Hex Fiend

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

Thanks!  There was a bug in my code when looking up the name of a 
meta-event.  I've corrected this bug in the attached version of the 
template.  (I've no idea what meta 0x21 is and apparently MF2T does not 
recognize it either.  But it was helpful to find this bug! :)

Unfortunately, while my template now runs it still will not decode the 
MIDI file you sent completely correctly.  The file appears to use the 
"running status" feature which my template doesn't support yet.  As a 
result you will see lots of events with blank summaries and invalid 
"event type" fields.  But this should be a very good test file for 
improving the template with its 10 tracks and lots of different event types.

I'll let you know whenever I have an improved template.

Thanks!

Anthony


On 10/6/20, 10:21 AM, Bernard Bel wrote:
> Yes! After selecting "refresh" it worked… The Option key trick also worked.
>
> However it did not work with the enclosed "this_song.mid" MIDI file
> which is correctly interpreted by "sound-object prototype" and
> "timebase" pages. This file wasn't created by BP. The beginning of this
> file in MF2T format (after trackname fixes of the the interface) is:
>
> MFile 1 10 444.444
> MTrk
> 0 Meta TrkName "untitled"
> 0 SMPTE 96 0 3 0 0
> 0 TimeSig 4/4 24 8
> 0 KeySig 255 major
> 0 Tempo 444444
> 21333 TimeSig 3/4 24 8
> 22667 TimeSig 4/4 24 8
> 31556 TimeSig 3/4 24 8
> 34222 TimeSig 4/4 24 8
> 46667 TimeSig 3/4 24 8
> 49333 TimeSig 4/4 24 8
> 13798 Tempo 444444
> 13802 Tempo 454545
> 13808 Tempo 451128
> 13810 Tempo 461538
> 13818 Tempo 465116
> 13826 Tempo 468750
> 13836 Tempo 472441
> 13844 Tempo 476190
> 13852 Tempo 480000
> 13858 Tempo 483871
> 13886 Tempo 487805
> 13894 Tempo 491803
> 13904 Tempo 495868
> 13920 Tempo 500000
> 13932 Tempo 504202
> 13950 Tempo 508475
> 13958 Tempo 512821
> 13970 Tempo 517241
> 13988 Tempo 521739
> 13996 Tempo 526316
> 14012 Tempo 530973
> 14022 Tempo 535714
> 14038 Tempo 540541
> 14050 Tempo 545455
> 14060 Tempo 550459
> 14078 Tempo 555556
> 14100 Tempo 560748
> 14114 Tempo 566038
> 14126 Tempo 571429
> 14138 Tempo 576923
> 14158 Tempo 582524
> 14168 Tempo 588235
> 14184 Tempo 594059
> 14198 Tempo 600000
> 14216 Tempo 606061
> 14232 Tempo 612245
> 58222 TimeSig 3/4 24 8
> 59555 TimeSig 4/4 24 8
> 63111 TimeSig 3/4 24 8
> 65778 TimeSig 4/4 24 8
> 74667 TimeSig 3/4 24 8
> 77333 TimeSig 4/4 24 8
> 80889 TimeSig 3/4 24 8
> 83555 TimeSig 4/4 24 8
> 83555 Meta TrkEnd
> TrkEnd
> MTrk
> 0 Meta TrkName "imported_1"
> 0 Meta 0x21 00
> 0 Meta TrkName "SOPSAX 166"
> 0 PrCh ch=1 p=64
> 0 Par ch=1 c=7 v=120
> 0 Par ch=1 c=10 v=20
> 0 Par ch=1 c=64 v=0
> 0 Pb ch=1 v=8192
> 1333 On ch=1 n=72 v=125
> 1552 On ch=1 n=72 v=0
> 1556 On ch=1 n=72 v=125
> 1774 On ch=1 n=72 v=0
> 1778 On ch=1 n=72 v=125
>
>
> Bernard

Re: [bp-dev] Looking inside MIDI files with Hex Fiend

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

Yes! After selecting "refresh" it worked… The Option key trick also worked.

However it did not work with the enclosed "this_song.mid" MIDI file 
which is correctly interpreted by "sound-object prototype" and 
"timebase" pages. This file wasn't created by BP. The beginning of this 
file in MF2T format (after trackname fixes of the the interface) is:

MFile 1 10 444.444
MTrk
0 Meta TrkName "untitled"
0 SMPTE 96 0 3 0 0
0 TimeSig 4/4 24 8
0 KeySig 255 major
0 Tempo 444444
21333 TimeSig 3/4 24 8
22667 TimeSig 4/4 24 8
31556 TimeSig 3/4 24 8
34222 TimeSig 4/4 24 8
46667 TimeSig 3/4 24 8
49333 TimeSig 4/4 24 8
13798 Tempo 444444
13802 Tempo 454545
13808 Tempo 451128
13810 Tempo 461538
13818 Tempo 465116
13826 Tempo 468750
13836 Tempo 472441
13844 Tempo 476190
13852 Tempo 480000
13858 Tempo 483871
13886 Tempo 487805
13894 Tempo 491803
13904 Tempo 495868
13920 Tempo 500000
13932 Tempo 504202
13950 Tempo 508475
13958 Tempo 512821
13970 Tempo 517241
13988 Tempo 521739
13996 Tempo 526316
14012 Tempo 530973
14022 Tempo 535714
14038 Tempo 540541
14050 Tempo 545455
14060 Tempo 550459
14078 Tempo 555556
14100 Tempo 560748
14114 Tempo 566038
14126 Tempo 571429
14138 Tempo 576923
14158 Tempo 582524
14168 Tempo 588235
14184 Tempo 594059
14198 Tempo 600000
14216 Tempo 606061
14232 Tempo 612245
58222 TimeSig 3/4 24 8
59555 TimeSig 4/4 24 8
63111 TimeSig 3/4 24 8
65778 TimeSig 4/4 24 8
74667 TimeSig 3/4 24 8
77333 TimeSig 4/4 24 8
80889 TimeSig 3/4 24 8
83555 TimeSig 4/4 24 8
83555 Meta TrkEnd
TrkEnd
MTrk
0 Meta TrkName "imported_1"
0 Meta 0x21 00
0 Meta TrkName "SOPSAX 166"
0 PrCh ch=1 p=64
0 Par ch=1 c=7 v=120
0 Par ch=1 c=10 v=20
0 Par ch=1 c=64 v=0
0 Pb ch=1 v=8192
1333 On ch=1 n=72 v=125
1552 On ch=1 n=72 v=0
1556 On ch=1 n=72 v=125
1774 On ch=1 n=72 v=0
1778 On ch=1 n=72 v=125


Bernard

Anthony Kozar wrote on 06/10/2020 14:43:
> Hmm... I find that when I open a new file in Hex Fiend that the app 
> displays the last used template in the pop-up menu but that it does 
> not actually apply the template until I select it again from the 
> menu.  It should probably display "None" instead.  Try that and see if 
> it helps.
>
> I am using the latest beta version (2.14.0b1) but my template appears 
> to work fine in version 2.13.1 as well.  I am able to apply it to the  
> file acceleration.mid that you sent in either version.
>
> Generally, when the template is not working correctly you will see 
> some kind of error message in the window instead of nothing.  But let 
> me know if you still can't get it to work.
>
> Another tip:  To reduce the amount of detail being shown by the MIDI 
> template, hold down the Option key and click on the disclosure 
> triangle for each track then click on them again without the Option 
> key to reopen.  The subfields for each event will then be hidden and 
> you will see just the summaries for those events. :)
>
> Anthony
>
>
> On 10/6/20, 2:04 AM, Bernard Bel wrote:
>> Dear Anthony,
>>
>> This is a great tool! I downloaded and ran the latest version.
>>
>> There seems to be a mismatch between the template you sent and the MIDI
>> type 1 files I tried to open (see attached picture, template and MIDI
>> file). Or is it an incorrect setting?
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] GitHub migration

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

Thank you for clarifications!

I created and uploaded https://github.com/bolprocessor/bp3-ctests/

Then I updated installation instructions in 
https://bolprocessor.org/check-bp3/ so that all zip files are taken from 
the GitHub repositories. Notably the console's code is now coming from 
https://github.com/bolprocessor/bolprocessor/archive/BP3-develop.zip

We may suppose that the “BP3-develop”-branch contains a version that 
compiles and work… If this were not the case I would revert to 
http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip.

I will not pull the https://github.com/bolprocessor/bolprocessor to my 
personal computer for the time being. I may need to do it later when 
implementing new graphic procedures…

Bernard

Rainer Schuetz wrote on 06/10/2020 11:45:
>> Now I guess I should create a repository such as 
>> "https://github.com/bolprocessor/bp3-ctests/" for modifying the 
>> sample test, and you would synchronize your "bp3-ctests" with that one. 
>
> Yes, if you’re willing to share ctests as a repo! (The name is also up 
> to you, of course)
>
>
>> Or should we rather push new versions to 
>> https://github.com/bagong/bp3-ctests ?
>
> No, I only created that one as I personally like moving files from 
> computer to computer via git/github (and maybe to show you how simple 
> it is ;-) ). It is much more consistent and convenient for you to 
> create such a repo yourself in the bolprocessor org (if you like! It’s 
> kind of a commitment to a certain workflow, so I didn’t want to push 
> for it, but I’d love to see you do it). I’ll happily connect to that 
> one once it exists...
>
>> Probably the best thing would be that Anthony, you and I are 
>> authorized committing to that new "bp3-ctests" repository, which 
>> would allow you you to create more examples while checking the package.
>
> For me no need (and you two have automatic write access to anything in 
> the org). I am used to the dual-repo workflow and pull-requests, so I 
> can always create a pull-request if we think some file should be 
> shared. After all we gradually want to consolidate that folder, so I 
> think it’s better when you or Anthony see and check everything that 
> enters. And as you’ve seen, merging a PR can be as little as a click.
>
> Best
> .r.
>
> PS: "A suggestion: you could add the "Makefile" to 
> https://github.com/bolprocessor/bolprocessor;” - the makefile *is* in 
> that repo, it is in the “BP3-develop”-branch. In order to get it, you 
> need to “checkout” that branch.
>
> git checkout BP3-develop
>
> Git will automagically switch to the branch and create a tracking 
> relation between your local branch and the remote branch (there is a 
> more explicit version of that command, but this works fine in a basic 
> single repo setup). You can then switch between branches by checking 
> out any of them, e.g. `git checkout master`, (master, BP3-develop, 
> CoreMIDI-for-BP3 and more (see the remote ones, the ones that you 
> haven’t checked out locally yet, with `git branch -r`)). Note that one 
> thing can get in the way of switching branches: if you have 
> uncommitted changes in a branch that would be overwritten by the 
> switch/checkout). Note also that you want to be considerate with 
> commits to branches that are shared between you and Anthony, as things 
> can get out of synch. One of the things why branches are really useful 
> is because they create a space to try out - and save separately - 
> stuff you want to try out or do provisionally. That stuff remains in a 
> separate branch safely, to be worked on, or merged, or discarded any time.
>
>
>
>>
>> Anthony :
>>
>> To avoid any confusion, "ctests" should be deleted 
>> fromhttp://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip
>>
>> A suggestion: you could add the "Makefile" 
>> tohttps://github.com/bolprocessor/bolprocessor; Then, users would be 
>> instructed to 
>> downloadhttps://github.com/bolprocessor/bolprocessor/archive/master.zipinstead 
>> ofhttp://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip
>>
>> Once we have done these changes, all download links on 
>> pagehttps://bolprocessor.org/check-bp3/would point 
>> athttps://github.com/bolprocessor/.
>>
>> Bernard
>>
>>
>> Rainer Schuetz wrote on 05/10/2020 21:26:
>>> Dear Bernard,
>>> Ah, great!
>>> I’ve forked both repos to bagong now and setup my new environment:
>>> git clone https://github.com/bagong/bolprocessor
>>> git clone https://github.com/bagong/php-frontend bp3-php-frontend 
>>> (I’ve renamed the parent folder for my environment)
>>> Then I added the repos from the organisation as secondary remotes 
>>> with the remote name org:
>>> Within the bolprocessor folder:
>>> git remote add org https://github.com/bolprocessor/bolprocessor
>>> And in the bp3-php-frontend-folder
>>> git remote add org https://github.com/bolprocessor/php-frontend
>>> That allows me to “fetch” new commits from the org and “push” them 
>>> to my repo.
>>> I also turned the ctests folder into a repo to be able to copy it 
>>> quickly from one computer to the other. It’s on bagong as bp3-ctests
>>> Now comes the nice part:
>>> I created two symbolic links in my clone of your php-frontend 
>>> folder, one to the bp binary and one to the ctests-folder:
>>> ln -s $HOME/bp3-ctests $HOME/bp3-php-frontend/ctests
>>> ln -s $HOME/bolprocessor/bp $HOME/bp3-php-frontend/bp
>>> Finally I created another symbolic link into the root-folder of my 
>>> Web-server:
>>> ln -s $HOME/bp3-php-frontend $HOME/Sites/bolprocessor
>>> That seems to work well, the only thing that doesn’t work is the 
>>> compile.php, but that could probably be made to work by replacing 
>>> “make” by “make ../bolprocessor/“
>>> Anyways, what I actually wanted to reach at ;-): I modified the 
>>> .gitignore file to support this setup, i.e. I added the 
>>> ctests-folder and the bp-binary (and also my_output and 
>>> temp_bolprocessor) to the files and committed it in a separate 
>>> branch. That way the added symlinks don’t get in the way of 
>>> version-control. I pushed it to my repo, and created a pull-request 
>>> in yours - if you like it, you can accept/commt it ;-)
>>> Best
>>> .r.
>>>> On 5. Oct 2020, at 15:20, Bernard Bel <ber...@gm... 
>>>> <mailto:ber...@gm...><mailto:ber...@gm...>> wrote:
>>>>
>>>> Dear Rainer,
>>>>
>>>> I followed your instructions. Everything worked without problem!
>>>>
>>>> The repository of the PHP interface now contains the first version:
>>>> https://github.com/bolprocessor/php-frontend
>>>>
>>>> For the time being I will keep committing new versions without 
>>>> creating branches. As I proceed on my own, every change of the 
>>>> interface is meant to be an improvement. Keeping a history of major 
>>>> steps will be useful in I need code which had been deleted, but 
>>>> this is quite rare.
>>>>
>>>> Now ready to go ahead! Thanks again for this tutorial!
>>>>
>>>> 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.
>>>>
>>>>
>>>> _______________________________________________
>>>> bolprocessor-devel mailing list
>>>> bol...@li... 
>>>> <mailto:bol...@li...><mailto:bol...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li... 
>>> <mailto:bol...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>
>>
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... 
>> <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Looking inside MIDI files with Hex Fiend

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

Hmm...  I find that when I open a new file in Hex Fiend that the app 
displays the last used template in the pop-up menu but that it does not 
actually apply the template until I select it again from the menu.  It 
should probably display "None" instead.  Try that and see if it helps.

I am using the latest beta version (2.14.0b1) but my template appears to 
work fine in version 2.13.1 as well.  I am able to apply it to the  file 
acceleration.mid that you sent in either version.

Generally, when the template is not working correctly you will see some 
kind of error message in the window instead of nothing.  But let me know 
if you still can't get it to work.

Another tip:  To reduce the amount of detail being shown by the MIDI 
template, hold down the Option key and click on the disclosure triangle 
for each track then click on them again without the Option key to 
reopen.  The subfields for each event will then be hidden and you will 
see just the summaries for those events. :)

Anthony


On 10/6/20, 2:04 AM, Bernard Bel wrote:
> Dear Anthony,
>
> This is a great tool! I downloaded and ran the latest version.
>
> There seems to be a mismatch between the template you sent and the MIDI
> type 1 files I tried to open (see attached picture, template and MIDI
> file). Or is it an incorrect setting?
>
> Bernard

Re: [bp-dev] GitHub migration

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

> Now I guess I should create a repository such as "https://github.com/bolprocessor/bp3-ctests/ <https://github.com/bolprocessor/bp3-ctests/>" for modifying the sample test, and you would synchronize your "bp3-ctests" with that one.

Yes, if you’re willing to share ctests as a repo! (The name is also up to you, of course)


> Or should we rather push new versions to https://github.com/bagong/bp3-ctests <https://github.com/bagong/bp3-ctests> ?

No, I only created that one as I personally like moving files from computer to computer via git/github (and maybe to show you how simple it is ;-) ). It is much more consistent and convenient for you to create such a repo yourself in the bolprocessor org (if you like! It’s kind of a commitment to a certain workflow, so I didn’t want to push for it, but I’d love to see you do it). I’ll happily connect to that one once it exists...

> Probably the best thing would be that Anthony, you and I are authorized committing to that new "bp3-ctests" repository, which would allow you you to create more examples while checking the package.

For me no need (and you two have automatic write access to anything in the org). I am used to the dual-repo workflow and pull-requests, so I can always create a pull-request if we think some file should be shared. After all we gradually want to consolidate that folder, so I think it’s better when you or Anthony see and check everything that enters. And as you’ve seen, merging a PR can be as little as a click.

Best
.r.

PS: "A suggestion: you could add the "Makefile" to https://github.com/bolprocessor/bolprocessor <https://github.com/bolprocessor/bolprocessor>;” - the makefile *is* in that repo, it is in the “BP3-develop”-branch. In order to get it, you need to “checkout” that branch.

git checkout BP3-develop 

Git will automagically switch to the branch and create a tracking relation between your local branch and the remote branch (there is a more explicit version of that command, but this works fine in a basic single repo setup). You can then switch between branches by checking out any of them, e.g. `git checkout master`, (master, BP3-develop, CoreMIDI-for-BP3 and more (see the remote ones, the ones that you haven’t checked out locally yet, with `git branch -r`)). Note that one thing can get in the way of switching branches: if you have uncommitted changes in a branch that would be overwritten by the switch/checkout). Note also that you want to be considerate with commits to branches that are shared between you and Anthony, as things can get out of synch. One of the things why branches are really useful is because they create a space to try out - and save separately - stuff you want to try out or do provisionally. That stuff remains in a separate branch safely, to be worked on, or merged, or discarded any time.



> 
> Anthony :
> 
> To avoid any confusion, "ctests" should be deleted from http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip <http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip>
> 
> A suggestion: you could add the "Makefile" to https://github.com/bolprocessor/bolprocessor <https://github.com/bolprocessor/bolprocessor>; Then, users would be instructed to download https://github.com/bolprocessor/bolprocessor/archive/master.zip <https://github.com/bolprocessor/bolprocessor/archive/master.zip> instead of http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip <http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip>
> 
> Once we have done these changes, all download links on page https://bolprocessor.org/check-bp3/ <https://bolprocessor.org/check-bp3/> would point at https://github.com/bolprocessor/ <https://github.com/bolprocessor/> .
> 
> Bernard
> 
> 
> Rainer Schuetz wrote on 05/10/2020 21:26:
>> Dear Bernard,
>> Ah, great!
>> I’ve forked both repos to bagong now and setup my new environment:
>> git clone https://github.com/bagong/bolprocessor
>> git clone https://github.com/bagong/php-frontend bp3-php-frontend (I’ve renamed the parent folder for my environment)
>> Then I added the repos from the organisation as secondary remotes with the remote name org:
>> Within the bolprocessor folder:
>> git remote add org https://github.com/bolprocessor/bolprocessor
>> And in the bp3-php-frontend-folder
>> git remote add org https://github.com/bolprocessor/php-frontend
>> That allows me to “fetch” new commits from the org and “push” them to my repo.
>> I also turned the ctests folder into a repo to be able to copy it quickly from one computer to the other. It’s on bagong as bp3-ctests
>> Now comes the nice part:
>> I created two symbolic links in my clone of your php-frontend folder, one to the bp binary and one to the ctests-folder:
>> ln -s $HOME/bp3-ctests $HOME/bp3-php-frontend/ctests
>> ln -s $HOME/bolprocessor/bp $HOME/bp3-php-frontend/bp
>> Finally I created another symbolic link into the root-folder of my Web-server:
>> ln -s $HOME/bp3-php-frontend $HOME/Sites/bolprocessor
>> That seems to work well, the only thing that doesn’t work is the compile.php, but that could probably be made to work by replacing “make” by “make ../bolprocessor/“
>> Anyways, what I actually wanted to reach at ;-): I modified the .gitignore file to support this setup, i.e. I added the ctests-folder and the bp-binary (and also my_output and temp_bolprocessor) to the files and committed it in a separate branch. That way the added symlinks don’t get in the way of version-control. I pushed it to my repo, and created a pull-request in yours - if you like it, you can accept/commt it ;-)
>> Best
>> .r.
>>> On 5. Oct 2020, at 15:20, Bernard Bel <ber...@gm... <mailto:ber...@gm...> <mailto:ber...@gm... <mailto:ber...@gm...>>> wrote:
>>> 
>>> Dear Rainer,
>>> 
>>> I followed your instructions. Everything worked without problem!
>>> 
>>> The repository of the PHP interface now contains the first version:
>>> https://github.com/bolprocessor/php-frontend
>>> 
>>> For the time being I will keep committing new versions without creating branches. As I proceed on my own, every change of the interface is meant to be an improvement. Keeping a history of major steps will be useful in I need code which had been deleted, but this is quite rare.
>>> 
>>> Now ready to go ahead! Thanks again for this tutorial!
>>> 
>>> 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.
>>> 
>>> 
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li... <mailto:bol...@li...> <mailto:bol...@li... <mailto:bol...@li...>>
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li... <mailto:bol...@li...>
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>

Re: [bp-dev] GitHub migration

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

Dear Rainer,

The only part I need to clarify is the "ctests" repository. I see that 
https://github.com/bagong/bp3-ctests contains the latest version of 
"ctests" folder which I had uploaded to 
https://bolprocessor.org/misc/BP3/ctests.zip

Now I guess I should create a repository such as 
"https://github.com/bolprocessor/bp3-ctests/" for modifying the sample 
test, and you would synchronize your "bp3-ctests" with that one. Or 
should we rather push new versions to https://github.com/bagong/bp3-ctests ?

It is a good idea to share this set of examples because it is used as a 
reference in https://bolprocessor.org/check-bp3/

Probably the best thing would be that Anthony, you and I are authorized 
committing to that new "bp3-ctests" repository, which would allow you 
you to create more examples while checking the package.

Anthony :

To avoid any confusion, "ctests" should be deleted from 
http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip

A suggestion: you could add the "Makefile" to 
https://github.com/bolprocessor/bolprocessor; Then, users would be 
instructed to download 
https://github.com/bolprocessor/bolprocessor/archive/master.zip instead 
of http://www.anthonykozar.net/files/BolProcessor/bpconsole-2020-08-17.zip

Once we have done these changes, all download links on page 
https://bolprocessor.org/check-bp3/ would point at 
https://github.com/bolprocessor/ .

Bernard


Rainer Schuetz wrote on 05/10/2020 21:26:
> Dear Bernard,
> 
> Ah, great!
> 
> I’ve forked both repos to bagong now and setup my new environment:
> 
> git clone https://github.com/bagong/bolprocessor
> git clone https://github.com/bagong/php-frontend bp3-php-frontend (I’ve 
> renamed the parent folder for my environment)
> 
> Then I added the repos from the organisation as secondary remotes with 
> the remote name org:
> 
> Within the bolprocessor folder:
> git remote add org https://github.com/bolprocessor/bolprocessor
> 
> And in the bp3-php-frontend-folder
> git remote add org https://github.com/bolprocessor/php-frontend
> 
> That allows me to “fetch” new commits from the org and “push” them to my 
> repo.
> 
> I also turned the ctests folder into a repo to be able to copy it 
> quickly from one computer to the other. It’s on bagong as bp3-ctests
> 
> Now comes the nice part:
> 
> I created two symbolic links in my clone of your php-frontend folder, 
> one to the bp binary and one to the ctests-folder:
> 
> ln -s $HOME/bp3-ctests $HOME/bp3-php-frontend/ctests
> ln -s $HOME/bolprocessor/bp $HOME/bp3-php-frontend/bp
> 
> Finally I created another symbolic link into the root-folder of my 
> Web-server:
> 
> ln -s $HOME/bp3-php-frontend $HOME/Sites/bolprocessor
> 
> That seems to work well, the only thing that doesn’t work is the 
> compile.php, but that could probably be made to work by replacing “make” 
> by “make ../bolprocessor/“
> 
> Anyways, what I actually wanted to reach at ;-): I modified the 
> .gitignore file to support this setup, i.e. I added the ctests-folder 
> and the bp-binary (and also my_output and temp_bolprocessor) to the 
> files and committed it in a separate branch. That way the added symlinks 
> don’t get in the way of version-control.  I pushed it to my repo, and 
> created a pull-request in yours - if you like it, you can accept/commt 
> it ;-)
> 
> Best
> .r.
> 
> 
>> On 5. Oct 2020, at 15:20, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> Dear Rainer,
>>
>> I followed your instructions. Everything worked without problem!
>>
>> The repository of the PHP interface now contains the first version:
>> https://github.com/bolprocessor/php-frontend
>>
>> For the time being I will keep committing new versions without 
>> creating branches. As I proceed on my own, every change of the 
>> interface is meant to be an improvement. Keeping a history of major 
>> steps will be useful in I need code which had been deleted, but this 
>> is quite rare.
>>
>> Now ready to go ahead! Thanks again for this tutorial!
>>
>> 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.
>>
>>
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... 
>> <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
> 
> 
> 
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
> 

Re: [bp-dev] Looking inside MIDI files with Hex Fiend

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

Dear Anthony,

This is a great tool! I downloaded and ran the latest version.

There seems to be a mismatch between the template you sent and the MIDI 
type 1 files I tried to open (see attached picture, template and MIDI 
file). Or is it an incorrect setting?

Bernard

Anthony Kozar wrote on 06/10/2020 04:28:
> Hello all,
>
> Back when I was updating the MIDI file output code for BP3, I was 
> using a basic hex editor named Hex Fiend to look at the files and 
> verify their contents.  It was tedious work, examining the hexadecimal 
> values for each byte and decoding their meaning mentally.  For years, 
> I have wanted a (free) hex editor that would allow one to write 
> templates for decoding the information in arbitrary binary files.  To 
> make a long story shorter,  it turned out that the version of Hex 
> Fiend that I had was more than 10 years old, and that recent versions 
> have added lots of wonderful features including the ability to write 
> binary data templates and display the decoded data with a great 
> interface!
>
> So, I've written a first draft of a template for standard MIDI files 
> (attached).  You can see the results in the attached image.
>
> Hex Fiend is free and open source!  I highly recommend trying this 
> fantastic tool.  (It is Mac-only).
>
> https://ridiculousfish.com/hexfiend/
>
> https://github.com/ridiculousfish/HexFiend
>
> (Note that the latest versions appear to be only on the GitHub site. 
> You will also want to download the source code to get templates for 
> common file types because they aren't included with the application).
>
> Anthony
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Looking inside MIDI files with Hex Fiend

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

Hello all,

Back when I was updating the MIDI file output code for BP3, I was using 
a basic hex editor named Hex Fiend to look at the files and verify their 
contents.  It was tedious work, examining the hexadecimal values for 
each byte and decoding their meaning mentally.  For years, I have wanted 
a (free) hex editor that would allow one to write templates for decoding 
the information in arbitrary binary files.  To make a long story 
shorter,  it turned out that the version of Hex Fiend that I had was 
more than 10 years old, and that recent versions have added lots of 
wonderful features including the ability to write binary data templates 
and display the decoded data with a great interface!

So, I've written a first draft of a template for standard MIDI files 
(attached).  You can see the results in the attached image.

Hex Fiend is free and open source!  I highly recommend trying this 
fantastic tool.  (It is Mac-only).

https://ridiculousfish.com/hexfiend/

https://github.com/ridiculousfish/HexFiend

(Note that the latest versions appear to be only on the GitHub site. 
You will also want to download the source code to get templates for 
common file types because they aren't included with the application).

Anthony

Re: [bp-dev] GitHub migration

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

Great!  I'm looking forward to trying this latest version.  There have 
been a lot of additions recently.

I don't think there is any need for branches with the PHP repository. 
Just having it in Git should make it easier for Rainer and I to keep up 
with your changes.

Thanks!

Anthony


On 10/5/20, 9:20 AM, Bernard Bel wrote:
> Dear Rainer,
>
> I followed your instructions. Everything worked without problem!
>
> The repository of the PHP interface now contains the first version:
> https://github.com/bolprocessor/php-frontend
>
> For the time being I will keep committing new versions without creating
> branches. As I proceed on my own, every change of the interface is meant
> to be an improvement. Keeping a history of major steps will be useful in
> I need code which had been deleted, but this is quite rare.

Re: [bp-dev] GitHub migration

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

Dear Bernard,

Ah, great!

I’ve forked both repos to bagong now and setup my new environment:

git clone https://github.com/bagong/bolprocessor <https://github.com/bagong/bolprocessor>
git clone https://github.com/bagong/php-frontend <https://github.com/bagong/php-frontend> bp3-php-frontend (I’ve renamed the parent folder for my environment)

Then I added the repos from the organisation as secondary remotes with the remote name org:

Within the bolprocessor folder:
git remote add org https://github.com/bolprocessor/bolprocessor <https://github.com/bolprocessor/bolprocessor> 

And in the bp3-php-frontend-folder
git remote add org https://github.com/bolprocessor/php-frontend <https://github.com/bolprocessor/php-frontend> 

That allows me to “fetch” new commits from the org and “push” them to my repo.

I also turned the ctests folder into a repo to be able to copy it quickly from one computer to the other. It’s on bagong as bp3-ctests

Now comes the nice part:

I created two symbolic links in my clone of your php-frontend folder, one to the bp binary and one to the ctests-folder:

ln -s $HOME/bp3-ctests $HOME/bp3-php-frontend/ctests 
ln -s $HOME/bolprocessor/bp $HOME/bp3-php-frontend/bp 

Finally I created another symbolic link into the root-folder of my Web-server:

ln -s $HOME/bp3-php-frontend $HOME/Sites/bolprocessor 

That seems to work well, the only thing that doesn’t work is the compile.php, but that could probably be made to work by replacing “make” by “make ../bolprocessor/“

Anyways, what I actually wanted to reach at ;-): I modified the .gitignore file to support this setup, i.e. I added the ctests-folder and the bp-binary (and also my_output and temp_bolprocessor) to the files and committed it in a separate branch. That way the added symlinks don’t get in the way of version-control.  I pushed it to my repo, and created a pull-request in yours - if you like it, you can accept/commt it ;-)

Best
.r.


> On 5. Oct 2020, at 15:20, Bernard Bel <ber...@gm...> wrote:
> 
> Dear Rainer,
> 
> I followed your instructions. Everything worked without problem!
> 
> The repository of the PHP interface now contains the first version:
> https://github.com/bolprocessor/php-frontend
> 
> For the time being I will keep committing new versions without creating branches. As I proceed on my own, every change of the interface is meant to be an improvement. Keeping a history of major steps will be useful in I need code which had been deleted, but this is quite rare.
> 
> Now ready to go ahead! Thanks again for this tutorial!
> 
> 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.
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] GitHub migration

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

Dear Rainer,

I followed your instructions. Everything worked without problem!

The repository of the PHP interface now contains the first version:
https://github.com/bolprocessor/php-frontend

For the time being I will keep committing new versions without creating 
branches. As I proceed on my own, every change of the interface is meant 
to be an improvement. Keeping a history of major steps will be useful in 
I need code which had been deleted, but this is quite rare.

Now ready to go ahead! Thanks again for this tutorial!

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.

[bp-dev] PHP interface and checklist documentation

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

Dear all,

I updated the documentation of the PHP interface and converted it to a 
Wordpress post:

https://bolprocessor.org/check-bp3/

The old URL is automatically redirected.

This version takes into account recent developments mentioned on this 
list. This material may serve later for the construction of an 
up-to-date users' manual. All suggestions weelcome!

Now ready for the initial GIT upload. ;-)

Bernard

Re: [bp-dev] GitHub migration

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

I’ll just comment on one issue, other than that I think it’s just a matter of you and Anthony agreeing on one or the other. Github offers a solution to all of the "where put what" questions (even pointing your domain-name to the GitHub presence), but of course that implies entangling yourself deeper with them and giving up some of your own “Web-identity”. Otoh they do provide really hip stuff if you want to use it, like comparatively easy and free “continuous integration” (regular automatic builds) for different platforms, up to triggering a multi-platform release almost full-automatically, with accompanying source snapshot. But that does require quite a bit of initial work for “administrative” scripts, something that maybe only pay off in larger projects. Anyways, I think all options are fine and an almost personal thing for the two of you to agree upon. Maybe two experiences from the SC migration back in the day: discussion tends to split up between the different communication channels that exist, and keeping track off all of them can get a bit burdensome. The other thing are Search-engines. Over time for some mysterious reason they tend to point to outdated links ;-)

> I could also go on uploading latest versions of the PHP interface to https://bolprocessor.org/misc/BP3/bolprocessor_php.zip <https://bolprocessor.org/misc/BP3/bolprocessor_php.zip> independently of commits to GitHub.

(Apart from the work of doing it), it’s mostly about where you want to point attention too. If to your own site, that makes sense, if it’s just about downloading a snapshot without the requirement of doing clone by git: I think Github provides a download button for each individual commit to a repo through it’s web-interface, so that functionality comes with the repo automatically.

> It might be a good idea to give separate links for the php folder, "BP2_help.txt" and the "ctests" folder.

Maybe a provisional, third repo for shared files with yet unclear destination would make sense? (After all it can be removed at any time…) Anything outside of php could go there until a longterm decision is made? Maybe Anthony has other stuff that makes sense there… For the bolprocessor repo you’d just need to add ctests (or tmp?) and php(-frontend) to the .gitignore list then. And the other two wouldn’t be bothered by the “surrounding” bolprocessor repo, because they only look “downwards”. That seems like a rather simple temporary solution to me.

> The "ctests" folder is problematic because at the moment both Anthony and I may be adding/modifying files to check our development work. This morning I created new scripts for instance… Therefore, at the moment I recommend keeping it here: https://bolprocessor.org/misc/BP3/ctests.zip <https://bolprocessor.org/misc/BP3/ctests.zip> . It is absent from https://github.com/bolprocessor/bolprocessor/ <https://github.com/bolprocessor/bolprocessor/> yet not from http://www.anthonykozar.net/files/BolProcessor/ <http://www.anthonykozar.net/files/BolProcessor/> . If you agree I will merge versions, so we could go on sharing it only as https://bolprocessor.org/misc/BP3/ctests.zip <https://bolprocessor.org/misc/BP3/ctests.zip> as it is necessary for the temporary "checklist".

To me exactly that use case - both Anthony and you changing files frequently - cries for putting it on a remote git repo both you and Anthony push to (and “pull” from). On occasion you might go through push-pull rather than sending email-attachments ;-)

Best
.r.




> 
> I will start uploading to GitHub as soon as these points are clear.
> 
> Bernard
> 
> Rainer Schuetz wrote on 01/10/2020 13:13:
>> Dear All,
>> 
>>> Does this sound like a reasonable strategy/policy?
>> 
>> Yes, the simpler/clearer the better, and this sounds good!
>> 
>>>> 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. ;-)
>> 
>> Yea, I mainly had Bernard in mind, and his specific requirement to get going with his repo. After all I had to prove that my initial promise “git were just “commit ’n push” had some reality to it ;-) Generally as a strategy for learning git I think interest-driven learning (“hey, I can actually try this out without messing with my old files - you mean I don’t need to copy the entire project and then loose overview? I want to learn branches!!!” ;-) ) is much better than following policies and adapting to a formalised workflow - those back in the days caused a lot of frustration and created an entry-level that didn't really foster collaboration. Nowadays git is almost considered a given, so that might not be that relevant any more, but I sympathise with Bernard’s perspective and hope he’ll enjoy the new horse ;-). But a defined base-structure is certainly required and what you outlined sounds very reasonable to me. It also concerns the bolprocessor repo more than Bernad’s current child. And in the end I feel, anything reasonably clear that is actively and so to say happily supported by the maintainer is fine.
>> 
>>>> 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 <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.
>> 
>> Yes, I’ll give it some thought. While writing this again I am thinking more of Bernard and the channel through which his progress hits Github ;-) (I myself don’t have in mind to commit anything to the bp.org <http://bp.org/> without confirmation at all, for me BP feels like an author-driven/owned project. If I’d do some experiments that I want to store on Github for some reason, I’d keep them in my own account, of course). Currently it is not possible to keep both the bolprocessor and php-frontend repos together as an active working environment. Only one can be an environment dynamically linked to a remote and the other needs to be copied in as “dead material” - and git of course complains about the presence of “alien” files. So in the current state it’s not really as helpful for Bernard as it could be. Having both repos as totally independent folders would make things much simpler and clearer.
>> 
>> As to submodules, back in the day in SC they did create lot’s of frustration - you needed to initialise and update them manually (people didn’t understand the requirement or simply forgot), maintaining synch between the parent and the sub requires separate commits (yea, it’s a feature, but also a nuisance ;-) ), and other complications can arise. Maybe more recent git offers more seamless options, but in my experience submodules are not as intuitive as they seem. 
>> 
>> Separating the folders might also reinforce thinking well about how to split duties between bp3 and the php-frontend. Atm it seems only the help-file really reaches out into the main repo?
>> 
>> Usually I’d have said it’s not an urgent question at all, but with this unanticipated availability of repos it is maybe something to prioritise, to make things as comfortable as possible for Bernard.
>> 
>> Best
>> .r.
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] GitHub migration

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

Dear all,

I am trying to follow this discussion — while working on a crashed 
Wordpress site ;-)

Your talk is comprensible but it requires a long time acquiring the 
basic ideas… Therefore I will follow your consensus. Just a few points 
to keep in mind:

1) The idea of a separate repository comes from the fact that the PHP 
interface is only an initial proposal for checking processes of the 
console, and perhaps creating an on-line service with BP3. If it is 
well-written and documented it might serve as a guideline for the 
development of stand-alone interfaces in any language/system. For this 
reason I keep using the most elementary PHP programming techniques — 
anyway I don't know the sophisticated ones! ;-)

2) I doubt that developers joining the project would engage into 
improving php-frontend because of the sobriety option expressed above. 
For instance it wouldn't make sense to write more css and Javascript 
while the core PHP interface does its work interacting with the console.

3) PHP needs no compilation. Therefore versions that will be committed 
will all be "latest-stable" ones. This makes things easier than keeping 
track of programming the console.

3) We probably all consider the sharing with developers and users as two 
separate issues. This means publishing "download" links with direct 
access to stable versions. For instance, page 
https://bolprocessor.org/bol-processor-downloads/ has the links to old 
versions of BP2 on SourceForge, and I understand that it will remain 
unchanged.

I also understand that SourceForge and GitHub will be synchronized with 
respect to stable versions. This means we could use a SourceForge link 
for BP3 console as well. This is a bit more complicated because users 
need to recompile it in their own environment. So I don't mind asking 
users to download it from 
http://www.anthonykozar.net/files/BolProcessor/ which will only be 
updated for the latest stable version.

In the current stage of the project, users downloading a package will 
mostly be new-comers to this approach, unlike engineers who rush 
updating their software because of the latest published security threat.

I could also go on uploading latest versions of the PHP interface to 
https://bolprocessor.org/misc/BP3/bolprocessor_php.zip independently of 
commits to GitHub. These links appear on page 
https://bolprocessor.org/misc/BP3/CheckList.html which may be modified 
so that "Install the package" will move to a separate page on the 
Wordpress site.

It might be a good idea to give separate links for the php folder, 
"BP2_help.txt" and the "ctests" folder.

"BP2_help.txt" could be put inside the php folder as php scripts 
reformat it in html. However it is also logical to keep it outside php 
because the same document may be used for other implementations of the 
interface. Maybe its proper place would be in 
https://github.com/bolprocessor/bolprocessor

Not to be confused with this old "BP2 help" which had been designed for 
installations of BP2:
https://github.com/bolprocessor/bolprocessor/blob/master/BP2%20help

This one probably deserves being deleted, as well as "_bp2_key" and the 
"y2k" which created a funny message on 1st January 2000!

The "ctests" folder is problematic because at the moment both Anthony 
and I may be adding/modifying files to check our development work. This 
morning I created new scripts for instance… Therefore, at the moment I 
recommend keeping it here: https://bolprocessor.org/misc/BP3/ctests.zip 
. It is absent from https://github.com/bolprocessor/bolprocessor/ yet 
not from http://www.anthonykozar.net/files/BolProcessor/ . If you agree 
I will merge versions, so we could go on sharing it only as 
https://bolprocessor.org/misc/BP3/ctests.zip as it is necessary for the 
temporary "checklist".

I will start uploading to GitHub as soon as these points are clear.

Bernard

Rainer Schuetz wrote on 01/10/2020 13:13:
> Dear All,
>
>> Does this sound like a reasonable strategy/policy?
>
> Yes, the simpler/clearer the better, and this sounds good!
>
>>> 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. ;-)
>
> Yea, I mainly had Bernard in mind, and his specific requirement to get 
> going with his repo. After all I had to prove that my initial promise 
> “git were just “commit ’n push” had some reality to it ;-) Generally 
> as a strategy for learning git I think interest-driven learning (“hey, 
> I can actually try this out without messing with my old files - you 
> mean I don’t need to copy the entire project and then loose overview? 
> I want to learn branches!!!” ;-) ) is much better than following 
> policies and adapting to a formalised workflow - those back in the 
> days caused a lot of frustration and created an entry-level that 
> didn't really foster collaboration. Nowadays git is almost considered 
> a given, so that might not be that relevant any more, but I sympathise 
> with Bernard’s perspective and hope he’ll enjoy the new horse ;-). But 
> a defined base-structure is certainly required and what you outlined 
> sounds very reasonable to me. It also concerns the bolprocessor repo 
> more than Bernad’s current child. And in the end I feel, anything 
> reasonably clear that is actively and so to say happily supported by 
> the maintainer is fine.
>
>>> 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.
>
> Yes, I’ll give it some thought. While writing this again I am thinking 
> more of Bernard and the channel through which his progress hits Github 
> ;-) (I myself don’t have in mind to commit anything to the bp.org 
> <http://bp.org> without confirmation at all, for me BP feels like an 
> author-driven/owned project. If I’d do some experiments that I want to 
> store on Github for some reason, I’d keep them in my own account, of 
> course). Currently it is not possible to keep both the bolprocessor 
> and php-frontend repos together as an active working environment. Only 
> one can be an environment dynamically linked to a remote and the other 
> needs to be copied in as “dead material” - and git of course complains 
> about the presence of “alien” files. So in the current state it’s not 
> really as helpful for Bernard as it could be. Having both repos as 
> totally independent folders would make things much simpler and clearer.
>
> As to submodules, back in the day in SC they did create lot’s of 
> frustration - you needed to initialise and update them manually 
> (people didn’t understand the requirement or simply forgot), 
> maintaining synch between the parent and the sub requires separate 
> commits (yea, it’s a feature, but also a nuisance ;-) ), and other 
> complications can arise. Maybe more recent git offers more seamless 
> options, but in my experience submodules are not as intuitive as they 
> seem.
>
> Separating the folders might also reinforce thinking well about how to 
> split duties between bp3 and the php-frontend. Atm it seems only the 
> help-file really reaches out into the main repo?
>
> Usually I’d have said it’s not an urgent question at all, but with 
> this unanticipated availability of repos it is maybe something to 
> prioritise, to make things as comfortable as possible for Bernard.
>
> Best
> .r.

Re: [bp-dev] GitHub migration

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

Dear All,

> Does this sound like a reasonable strategy/policy?

Yes, the simpler/clearer the better, and this sounds good!

>> 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. ;-)

Yea, I mainly had Bernard in mind, and his specific requirement to get going with his repo. After all I had to prove that my initial promise “git were just “commit ’n push” had some reality to it ;-) Generally as a strategy for learning git I think interest-driven learning (“hey, I can actually try this out without messing with my old files - you mean I don’t need to copy the entire project and then loose overview? I want to learn branches!!!” ;-) ) is much better than following policies and adapting to a formalised workflow - those back in the days caused a lot of frustration and created an entry-level that didn't really foster collaboration. Nowadays git is almost considered a given, so that might not be that relevant any more, but I sympathise with Bernard’s perspective and hope he’ll enjoy the new horse ;-). But a defined base-structure is certainly required and what you outlined sounds very reasonable to me. It also concerns the bolprocessor repo more than Bernad’s current child. And in the end I feel, anything reasonably clear that is actively and so to say happily supported by the maintainer is fine.

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

Yes, I’ll give it some thought. While writing this again I am thinking more of Bernard and the channel through which his progress hits Github ;-) (I myself don’t have in mind to commit anything to the bp.org <http://bp.org/> without confirmation at all, for me BP feels like an author-driven/owned project. If I’d do some experiments that I want to store on Github for some reason, I’d keep them in my own account, of course). Currently it is not possible to keep both the bolprocessor and php-frontend repos together as an active working environment. Only one can be an environment dynamically linked to a remote and the other needs to be copied in as “dead material” - and git of course complains about the presence of “alien” files. So in the current state it’s not really as helpful for Bernard as it could be. Having both repos as totally independent folders would make things much simpler and clearer.

As to submodules, back in the day in SC they did create lot’s of frustration - you needed to initialise and update them manually (people didn’t understand the requirement or simply forgot), maintaining synch between the parent and the sub requires separate commits (yea, it’s a feature, but also a nuisance ;-) ), and other complications can arise. Maybe more recent git offers more seamless options, but in my experience submodules are not as intuitive as they seem. 

Separating the folders might also reinforce thinking well about how to split duties between bp3 and the php-frontend. Atm it seems only the help-file really reaches out into the main repo?

Usually I’d have said it’s not an urgent question at all, but with this unanticipated availability of repos it is maybe something to prioritise, to make things as comfortable as possible for Bernard.

Best
.r.