bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] Windows compatibility of the PHP interface

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

Dear Bernard,

I’ve created a mess now, I am pretty nervous with other stuff. I might actually have tested your code with the wrong branches, I am not even sure and can’t go into it now, people calling out for me…

Best
.r.



> On 31. Jul 2020, at 15:39, Bernard Bel <ber...@gm...> wrote:
> 
> I am enclosing a versio of prototype.php that uses relative paths to call window.open().  It works fine, juste a few additional lines are required. If it solves the problem then I will put relative paths for all window.open() calls…
>> 
>> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> As I am still in a hurry, I couldn’t look at leisure or in an attempt-at-understanding-way at the stuff. But when randomly trying out buttons, I did bump into a bug which is also an incostency between Mac and Windows. These buttons:
>> 
>> <image.png>
>> 
>> Generate a) paths that don’t work
>> 
>> Mac: http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> 
> 
> <prototype.php>_______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

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

Yes, and you will see more if you modify some parameters regarding 
"truncate", "continuity" etc. ;-)

The only thing that worries me with GD Library is that it seems very 
complicated to modify fonts, text size etc. So, we'll keep that Courier 
for the time being…

Rainer Schuetz wrote on 31/07/2020 14:52:
> Es sorry, forgot that:
>
>
>
>> On 31. Jul 2020, at 13:44, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> Dear Rainer,
>>
>> Yes, your screenshots indicate a perfect display of sound-object 
>> prototypes !
>>
>> With the latest version I have just uploaded you would see even many 
>> more details on the image. This is meant for comparing the same with 
>> a display on BP2.9.8. Now all topological properties, and a few 
>> metric properties are displayed, plus a few more that I could include 
>> due to the fact that we get higher resolution images. We'll see later 
>> how this display could still be enriched…
>>
>> Bernard
>>
>>
>>
>>
>> _______________________________________________
>> 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] Windows compatibility of the PHP interface

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

I am enclosing a versio of prototype.php that uses relative paths to 
call window.open().  It works fine, juste a few additional lines are 
required. If it solves the problem then I will put relative paths for 
all window.open() calls…
>
> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>
> As I am still in a hurry, I couldn’t look at leisure or in an 
> attempt-at-understanding-way at the stuff. But when randomly trying 
> out buttons, I did bump into a bug which is also an incostency between 
> Mac and Windows. These buttons:
>
>
> Generate a) paths that don’t work
>
> Mac: 
> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>
>

Re: [bp-dev] Windows compatibility of the PHP interface

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

> On 31. Jul 2020, at 15:11, Bernard Bel <ber...@gm...> wrote:
> 
> I'll reply the next part of your message in a separate mail.

Yea, I realised my path-related descriptions were too messy to be helpful. So on Windows the correct path is:

http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt <http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt>

The path generated in the browser:

http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt <http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt>

So it’s swallowing multiple slashes and and adding in stuff.

On Mac displays as:

users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

Which is an absolute path starting with the word “users” spelt wrong (Users) and maybe missing an initial slash. I can’t remember ever having seen such a path in a browser… not sure if it’s even allowed… But now I see that it’s the browser converts it to that. The manually corrected path:

http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

Or

http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

Doesn’t open either. If absolute path is required, the only thing that opens for me is:

file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

But it would make much more sense to just use 

http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

So the path generated by php for server-based http-access should be 

bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

Or (not sure)

/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

Which opens just fine for me… But this is a bit confusing, and I really can’t think through it these days…. Very sorry (but the issues are there)

Best
.r.

Re: [bp-dev] Windows compatibility of the PHP interface

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

At present, a "trace" file and a temp folder containing data on 
sound-objects are created in the work folder, which is "ctests" for 
instance. But whenever you browse "ctests" (via the "index.php" page) 
all temp files and folder older than 24 hours and not tagged with the 
current session ID are deleted. The browser does not even display them. 
You only see them if you visit the folde via the Finder.

This seems acceptable because anyway the "ctests" folder is one we use 
for storing and editing data. And it makes it easy to locate these 
folders. Anyway, if we have a good reason to create an additional "temp" 
folder the process can be modified.

We never write outside the "bolprocessor" folder. The "output" folders 
are created inside it at the top level.

Indeed we can rearrange data for demo, work etc. Up to now we've used 
"tests" for material used to check the interface and console, but at soe 
point we may want to develop real projects with real sounds and these 
will be classified in a different tree.

Bernard

Rainer Schuetz wrote on 31/07/2020 14:52:
> As you are creating all these session files in the ctests or “home" 
> folder… We might want to start thinking about some additional 
> conventions of folder structure? I could think of 3 additional folders 
> that could be conventionalised as storage-location. Two excluded from 
> version control (go to .gitignore), and one added and gradually 
> populated, maybe:
>
> tmp (for session files)
> output (or my_output) we generate with an intention and want to keep
> tests  (as a folder for considered files we want to use in tests or demos)
>
> I think (but I am not sure) the server shouldn’t write to folders 
> outside of the bolprocessor folder. It could, but it would complicate 
> a server configuration that has security in mind. The tmp and 
> output-folder could be ignored by git, “tests” could be added, and the 
> ctests could gradually be faded out, the role of it being taken over 
> by the three I suggested. Not urgent at all, though...

Re: [bp-dev] Windows compatibility of the PHP interface

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

Rainer Schuetz wrote on 31/07/2020 14:52:
> Here a screenshot:
>
> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>
> As I am still in a hurry, I couldn’t look at leisure or in an 
> attempt-at-understanding-way at the stuff. But when randomly trying 
> out buttons, I did bump into a bug which is also an incostency between 
> Mac and Windows. These buttons:
>
>
> Generate a) paths that don’t work
>
> Mac: 
> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>
> The u should be /U - and I am surprised it writes absolute paths at 
> all? - might require file:// then? (but can’t think through that 
> either ;-) )

I don't understand "The u should be /U"...  The same link wit MAMP on 
the Mac is:

http://localhost/try/bolprocessor/ctests/-mi.abc1_09daff2089a5a3a392ce0637044d8c49_temp/cycle2_codes/midicodes.txt

The "try" folder is the one containing "bolprocessor".

This link (named "$text_link") and the two ones pointing at MIDI code 
should open new windows, calling the window.open() procedure of Javascript:

<a 
onclick=\"window.open('".$text_link."','MIDItext','width=300,height=300'); 
return false;\" href=\"".$text_link."\">EXPLICIT MIDI codes</a>

$text_link should be an aboslute path. I am not sure a relative path 
will work, but I will try it. To create a relative path we need to move 
up (out of "php") then down in "ctests". This I have done for a link to 
the MIDI file because the Javascript MIDI player only wants relative paths.

I am going to generate this relative path and let you know whether it works…

I'll reply the next part of your message in a separate mail.

Bernard

Re: [bp-dev] Windows compatibility of the PHP interface

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

Es sorry, forgot that:




> On 31. Jul 2020, at 13:44, Bernard Bel <ber...@gm...> wrote:
> 
> Dear Rainer,
> 
> Yes, your screenshots indicate a perfect display of sound-object prototypes !
> 
> With the latest version I have just uploaded you would see even many more details on the image. This is meant for comparing the same with a display on BP2.9.8. Now all topological properties, and a few metric properties are displayed, plus a few more that I could include due to the fact that we get higher resolution images. We'll see later how this display could still be enriched…
> 
> Bernard
> 
> 
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

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

Dear Berny,

Thanks for more!

Here a screenshot:

http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

As I am still in a hurry, I couldn’t look at leisure or in an attempt-at-understanding-way at the stuff. But when randomly trying out buttons, I did bump into a bug which is also an incostency between Mac and Windows. These buttons:



Generate a) paths that don’t work

Mac: http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>

The u should be /U - and I am surprised it writes absolute paths at all? - might require file:// then? (but can’t think through that either ;-) )

Win: /bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt

That one might work without /bolprocessor?

As you are creating all these session files in the ctests or “home" folder… We might want to start thinking about some additional conventions of folder structure? I could think of 3 additional folders that could be conventionalised as storage-location. Two excluded from version control (go to .gitignore), and one added and gradually populated, maybe:

tmp (for session files)
output (or my_output) we generate with an intention and want to keep 
tests  (as a folder for considered files we want to use in tests or demos)

I think (but I am not sure) the server shouldn’t write to folders outside of the bolprocessor folder. It could, but it would complicate a server configuration that has security in mind. The tmp and output-folder could be ignored by git, “tests” could be added, and the ctests could gradually be faded out, the role of it being taken over by the three I suggested. Not urgent at all, though...

Btw, putting the project folder under version control (I think I can use that Nazi-like sounding word now, as we see it’s actually a nice thing) allows instant switching between code-versions (branches), and also quick removal of termpory files (something like `git reset —hard`) just recreates the virgin state (well, more or less). This model of working is very popular with coding oriented applications (see f.e. Sonic Pi), or - not in the music domain - homebrew (!), many editors (e.g. libre ones like Atom, or VS-Code) support it in their interface.

Good times and best

Best
.r.


> On 31. Jul 2020, at 13:44, Bernard Bel <ber...@gm...> wrote:
> 
> Dear Rainer,
> 
> Yes, your screenshots indicate a perfect display of sound-object prototypes !
> 
> With the latest version I have just uploaded you would see even many more details on the image. This is meant for comparing the same with a display on BP2.9.8. Now all topological properties, and a few metric properties are displayed, plus a few more that I could include due to the fact that we get higher resolution images. We'll see later how this display could still be enriched…
> 
> Bernard
> 
> 
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

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

Dear Rainer,

Yes, your screenshots indicate a perfect display of sound-object 
prototypes !

With the latest version I have just uploaded you would see even many 
more details on the image. This is meant for comparing the same with a 
display on BP2.9.8. Now all topological properties, and a few metric 
properties are displayed, plus a few more that I could include due to 
the fact that we get higher resolution images. We'll see later how this 
display could still be enriched…

Bernard

Re: [bp-dev] Windows compatibility of the PHP interface

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

Dear Rainer,

Yes, these screenshots indicate a perfect display of sound-object 
prototypes !

With the latest version I have just uploaded you would see even many 
more details on the image. This is meant for comparing the same with a 
display on BP2.9.8. Now all topological properties, and a few metric 
properties are displayed, plus a few more that I could include due to 
the fact that we get higher resolution images. We'll see later how this 
display could still be enriched…

Bernard

Rainer Schuetz wrote on 31/07/2020 00:18:
> Maybe these quick screenshots give you some hints? I have no idea what 
> they mean. There are many similarities and a few little discrepancies 
> between Wi and Ma ;-) but the actual graph at the end is pixel identical.
>
> All the best and congratulations to your rapid progress!!!
>
>
>
>
>
>
>
>
> Hugs!
> .r.
>
>
>> On 30. Jul 2020, at 23:15, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> Dear Rainer,
>>
>> Your test revealed that there was still a problem: "root" displays 
>> both slashes and backslashes!
>>
>> I fixed it with these two instructions:
>>
>> $root = str_replace("\\",DIRECTORY_SEPARATOR,$root);
>> $root = str_replace("/",DIRECTORY_SEPARATOR,$root);
>>
>> "A sound-object that contains MIDI codes"... I should just have 
>> suggested to open "-mi.abc1" and look at its sound-object prototypes! 
>> Each of them will yield an audible MIDI sequence and an image (link 
>> at the bottom of the page).
>>
>> I spent the evening programming the image. It works great. GD Library 
>> is so easy, and I found a tricky fast method to pass on many 
>> variables to the image page… The secret is 
>> "require_once($image_file);" which includes a php file constructed 
>> dynamically by the prototype.php page.
>>
>> I uploaded the new version (with the correction on "root").  I still 
>> need to do some more work on images to make them look at least as 
>> complete as BP2.9.78.
>>
>> Have a nice holiday!  I guess that by mid-August we'll have a 
>> stronger connection between the interface and the console. We're 
>> checking on Mac and you will be able to do the same checks on 
>> Windows. ;-)
>>
>> 44°C today, it's time to go to mountains — though it reminds me of 
>> India :-)
>>
>> Bernard
>>
>> Rainer Schuetz wrote on 30/07/2020 18:20:
>>> Dear Berny,
>>>
>>> Wow thanks, that was quick!! You are faster doing all this than I 
>>> was trying out stuff ;-). Unfortunately I am kind of under a 
>>> deadline for the weekend and can’t invest substantial time before 
>>> next week (when you’re in holidays)… Hopefully in August I’ll find 
>>> some time to try and understand this better. Atm I don’t even 
>>> understand a sentence like "if you open "prototypes.php" on a 
>>> sound-object that contains MIDI codes” - let alone be able to act 
>>> upon it. But hopefully in August that will get better.
>>>
>>> So I just had time to push your changes and screenshoot the output 
>>> of your test in _basic_tasks:
>>>
>>> <image.png>
>>>
>>> <image.png>
>>>
>>> Best!!
>>> .r.
>>>
>>>
>>>> On 30. Jul 2020, at 17:07, Bernard Bel <ber...@gm... 
>>>> <mailto:ber...@gm...>> wrote:
>>>>
>>>> I worked on updated PHP files supplied by Rainer this morning and 
>>>> merged them with my latest changes on the "prototypes.php" window.
>>>>
>>>> Basically it worked file, except for links requiring absolute 
>>>> paths. For instance the ones opening windows for "output" and 
>>>> "trace" on the "produce.php" window. BP should work if folder 
>>>> "bolprocessor" is not exactly at the root of the web server. To 
>>>> test it, I have a "try" folder at the root, so the actual path to 
>>>> php files is /try/bolprocessor/php/
>>>>
>>>> For instance, the link to the output window should be:
>>>>
>>>> /try/bolprocessor/test_output/out.sco
>>>>
>>>> and not:
>>>>
>>>> /bolprocessor/test_output/out.sco
>>>>
>>>> To this effect I constructed variable $path_above which is equal to 
>>>> "try" in this case. Not just one folder, it could be a longer path… 
>>>> To this effect I had no other choice than using the $root variable 
>>>> equal to  "/Applications/MAMP/htdocs/"
>>>>
>>>> I checked the use of DIRECTORY_SEPARATOR in all files, including 
>>>> "protoptypes.php" in which it was still missing in several places. 
>>>> Now, if you open "prototypes.php" on a sound-object that contains 
>>>> MIDI codes, you'll get a link, near the bottom of the page, to 
>>>> listen to them. This also needs to be verified on Windows.
>>>>
>>>> Finally, the "IMAGE" link at the bottom of the sound-object 
>>>> prototype should open a window with some graphics and texts. I am 
>>>> now working on its content.
>>>>
>>>> The new version has been pushed to my repertory 
>>>> (https://leti.lt/bolprocessor/). The main changes should be called 
>>>> "Windows compatibility". I modified some parameters for object 
>>>> durations and their proper rendering as MIDI files, but that's only 
>>>> a cleaning up of code. I might even revise that part once we can 
>>>> load back a "-mi" file to BP2.9.8.  I know Anthony is working hard 
>>>> — fixing my old bugs! — and compatibility will be achieved soon. I 
>>>> am aware that has taken care of ensuring that command-line options 
>>>> have a priority over settings in the "-se" files.
>>>>
>>>> Bernard
>>>>
>>>> Rainer Schuetz wrote on 30/07/2020 03:56:
>>>>> Dear Bernard (eh, I need to remember to call you Berny!),
>>>>>
>>>>> I thought I have to show some responsibility for Windows, as I 
>>>>> pushed it and you even wrote the checklist. I took a slightly 
>>>>> deeper look into it… It’s unfortunately quite time consuming for 
>>>>> me, as for one I am very slow with this kind of stuff, and also I 
>>>>> need to learn by doing. So I am far from having gotten through 
>>>>> your checklist, and we are getting to this unfortunate state, 
>>>>> where I bump into problems while you already happily move on to 
>>>>> more interesting stuff. And now there is a Windows version where a 
>>>>> bit more works than before - but the changes are based on a 
>>>>> version you have already left behind ;-) Classical problem in 
>>>>> version control. I have the (preliminary and “naive”) 
>>>>> Windows-changes on a separate branch called “crossplatform” so 
>>>>> that you can inspect them.
>>>>>
>>>>> The problem is the following: for filesystem access Windows is 
>>>>> actually rather flexible in that it understands both “slash” and 
>>>>> “backslash” as directory-separators, it can even tolerate paths, 
>>>>> where bsl and sl are mixed. But there is a but: If you do 
>>>>> str_replace operations they’ll compare literal strings, and then 
>>>>> no “smart handling” occurs, after all it’s php and not Windows. 
>>>>> And there are more hidden difficulties. The web-servers 
>>>>> configuration (httpd.conf) contains the “document_root” 
>>>>> configuration in hybrid unix-notation, something like 
>>>>> “c:/Users/schue/Sites”. Nothing wrong with that and it’s even 
>>>>> required. But when php queries the file-system, as in getcwd(), 
>>>>> the return-value will be a string with clean Windows syntax, e.g. 
>>>>> C:\Users\Schue\Sites\bolprocessor\php\. Now if you subtract one 
>>>>> from the other with str_replace, it will fail, because the 
>>>>> doc_root syntax has slashes, while the other has backslashes. 
>>>>> Therefore many of your str_replace based operations fail. I tried 
>>>>> the following:
>>>>>
>>>>> If we don’t use document root, it is actually easier to locate the 
>>>>> various folders - we even get more flexible because we don’t need 
>>>>> to care where in the web-server filetree the user stores the bp 
>>>>> folder. So we also don’t need to account for $path_to_bp. We start 
>>>>> from bolprocessor/php with getcwd() and query two paths upwards 
>>>>> getting path-names by a php-function confusingly called 
>>>>> “dirname()” which actually returns the parent directory (of a file 
>>>>> or a directory) (!). This should sound quite interesting for you, 
>>>>> because you have some quite complicated algorithms to “move up” a 
>>>>> directory, and alas they also break on Windows because you depend 
>>>>> on a literal “slash”.
>>>>>
>>>>> So far I’ve tried to remove the dependency on the variable $root 
>>>>> which causes problems in every invocation on Windows, and I’ve 
>>>>> tried to clean up around those spots places where I saw that 
>>>>> dependency on a literal “slash” was likely to break things. As I 
>>>>> said not every slash will break things, but it can be tricky to 
>>>>> predict which one will break and which one not. Anyways php also 
>>>>> provides a smart keyword “DIRECORY_SEPARATOR” that will return a 
>>>>> string slash on Unix and a string backslash on Windows. It looks 
>>>>> quite clumsy in the code, but it can help…
>>>>>
>>>>> I couldn’t think through all the code, basically I went with 
>>>>> project wide search through your code and did something about all 
>>>>> the $root and $path_to_bp variables, after I defined the bottom-up 
>>>>> ones: $bp-php-path, $bp-application-path and $bp-parent-path. The 
>>>>> last one is the closest to $root - but it doesn’t require the 
>>>>> $path_to_bp. I’ve also replace the “home”-folder name by 
>>>>> avariable, so that if somebody needs multiple bp-folders side by 
>>>>> side s/he can give them different names.
>>>>>
>>>>> It’s more of a sketch I guess, I am sure there is much more 
>>>>> detail-filing to do to get it fully clean. It’s a way of doing it 
>>>>> that keeps quite strongly inline with your current logic of doing 
>>>>> things. Occasionally I though functions might be quite useful, for 
>>>>> example when you exlode a path by delimiter and then pick up the 
>>>>> last bit - it’s literally the same thing about 10 times, it could 
>>>>> probably be done at one spot and then called. But unfortunately I 
>>>>> am not sure how to do that in php, and I didn’t want to be too 
>>>>> intrusive.
>>>>>
>>>>> Anyways, my suggestions might be interesting to read, even if you 
>>>>> ultimately do it differently, even more the “php-way”… I am not 
>>>>> sure if you want to look up the diffs in the GitHub repo (you’d 
>>>>> have to go to the branch “crossplatform”) or maybe even “pull” the 
>>>>> load. But I also uploaded a snapshot of the bp-folder 
>>>>> tohttps://bp.bagong.de/archives/bp_php.zip.
>>>>>
>>>>> Best
>>>>> .r.
>>>>>
>>>>>
>>>>>
>>>>>> On 29. Jul 2020, at 14:36, Bernard Bel <ber...@gm... 
>>>>>> <mailto:ber...@gm...><mailto:ber...@gm...>> wrote:
>>>>>>
>>>>>> You are not dreaming: the PHP interface is producing sounds!
>>>>>>
>>>>>> Yet not via the console, indeed. I was wondering how to hear a 
>>>>>> "preview" of MIDI streams handled by sound-object prototypes. I 
>>>>>> discovered a Javascript function "MIDIjs.play" that plays MIDI files:
>>>>>>
>>>>>> https://www.midijs.net/
>>>>>>
>>>>>> However we did not have MIDI files except when they were imported 
>>>>>> (using MIDI Library). We only have time-stamped MIDI codes that 
>>>>>> Bol Processor will send to a MIDI player. The MIDI Library does 
>>>>>> create MIDI files but not from a sequence of MIDI instructions. 
>>>>>> It requires a text description of the MIDI file in a 
>>>>>> poorly-documented format called "MF2T/T2MF". This is the output 
>>>>>> format of its MIDI file to text converter. I could keep it for 
>>>>>> imported MIDI files but for all other objects I implemented the 
>>>>>> creation of a MF2T/T2MF file from time-stamped MIDI codes.
>>>>>>
>>>>>> This was not easy because time-stamped MIDI codes do not contain 
>>>>>> all the information required in a well-formed type-1 MIDI file, 
>>>>>> which is the format required by the text to MIDIfile converter. A 
>>>>>> type-1 MIDI file may contain several tracks, so we guess track 
>>>>>> changes in time-stamped MIDI codes when time goes back (generally 
>>>>>> to 0), and a "NewTrk" instruction is inserted.
>>>>>>
>>>>>> Another problem on which I spent part of the night is to figure 
>>>>>> out the tempo. MIDI files have a header that tells the format, 
>>>>>> number of tracks, and an obscure parameter called "division" 
>>>>>> giving "the time resolution in clicks per quarter note". This 
>>>>>> looks simple but I needed to figure out how this parameter will 
>>>>>> be taken care of so that an imported MIDI file will be played at 
>>>>>> exactly the same speed. I got confused with a variable called 
>>>>>> "Tref" in Bol Processor, which is the period of the metronom used 
>>>>>> to count the number of beats of an object. The problem is that 
>>>>>> Tref is actually a number of "ticks" and not a number of 
>>>>>> milliseconds. To sort it out we need to know the time-resolution. 
>>>>>> Since it was 1 millisecond by default on most sound-objects, I 
>>>>>> wrongly asssumed that Tref was in milliseconds.
>>>>>>
>>>>>> Finally I found the magic equation:
>>>>>> resolution = division / (0.48 * Tref)
>>>>>>
>>>>>> Don't ask me why "0.48"… It works!
>>>>>>
>>>>>> If you use the new PHP interface (now 
>>>>>> onhttps://leti.lt/bolprocessor/) you will see a "Play MIDI file" 
>>>>>> link just below the Csound score of any object in "-mi.abc1". It 
>>>>>> works with the "default player" on your system, so we need to 
>>>>>> check it on Windows and other platforms.
>>>>>>
>>>>>> Then you can try to upload a MIDI file and select a long one to 
>>>>>> check that durations remain correct. In the "ctests.zip" folder I 
>>>>>> added "Christmas_Carols_-_12_Days_Of_Christmas.mid" that will 
>>>>>> give you a 14-second delight! One you have heard the song try to 
>>>>>> modify its duration
>>>>>>
>>>>>> Tring to import this multitrack file in BP2.9.8 does not yield a 
>>>>>> satisfactory result: most data is ignored or modified. Therefore 
>>>>>> we can't rely on BP current methods for importing/exporting MIDI 
>>>>>> files — written by Kumar in 1997. The MIDI file format has been 
>>>>>> upgraded since then.
>>>>>>
>>>>>> Normally we won't need to read/write multitrack MIDI files but 
>>>>>> some users may not be aware of it and they may try to create a 
>>>>>> multitrack sound-object. It will work since the conversion to 
>>>>>> time-stamped MIDI bytes is correct. This will add a new "density" 
>>>>>> to sound-objects! ;-)
>>>>>>
>>>>>> This does not really require an update of the checklist because 
>>>>>> it is a tentative implementation that forced me to study again 
>>>>>> MIDI encoding and the representation of physical time in Bol 
>>>>>> Processor. Understanding time resolution, durations, preroll and 
>>>>>> postroll etc.
>>>>>>
>>>>>>
>>>>>> Bernard
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> bolprocessor-devel mailing list
>>>>>> 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
>>
>> _______________________________________________
>> 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] Windows compatibility of the PHP interface

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

Maybe these quick screenshots give you some hints? I have no idea what they mean. There are many similarities and a few little discrepancies between Wi and Ma ;-) but the actual graph at the end is pixel identical. 

All the best and congratulations to your rapid progress!!!













Hugs!
.r.


> On 30. Jul 2020, at 23:15, Bernard Bel <ber...@gm...> wrote:
> 
> Dear Rainer,
> 
> Your test revealed that there was still a problem: "root" displays both slashes and backslashes!
> 
> I fixed it with these two instructions:
> 
> $root = str_replace("\\",DIRECTORY_SEPARATOR,$root);
> $root = str_replace("/",DIRECTORY_SEPARATOR,$root);
> 
> "A sound-object that contains MIDI codes"... I should just have suggested to open "-mi.abc1" and look at its sound-object prototypes! Each of them will yield an audible MIDI sequence and an image (link at the bottom of the page).
> 
> I spent the evening programming the image. It works great. GD Library is so easy, and I found a tricky fast method to pass on many variables to the image page… The secret is "require_once($image_file);" which includes a php file constructed dynamically by the prototype.php page.
> 
> I uploaded the new version (with the correction on "root").  I still need to do some more work on images to make them look at least as complete as BP2.9.78.
> 
> Have a nice holiday!  I guess that by mid-August we'll have a stronger connection between the interface and the console. We're checking on Mac and you will be able to do the same checks on Windows. ;-)
> 
> 44°C today, it's time to go to mountains — though it reminds me of India :-)
> 
> Bernard
> 
> Rainer Schuetz wrote on 30/07/2020 18:20:
>> Dear Berny,
>> 
>> Wow thanks, that was quick!! You are faster doing all this than I was trying out stuff ;-). Unfortunately I am kind of under a deadline for the weekend and can’t invest substantial time before next week (when you’re in holidays)… Hopefully in August I’ll find some time to try and understand this better. Atm I don’t even understand a sentence like "if you open "prototypes.php" on a sound-object that contains MIDI codes” - let alone be able to act upon it. But hopefully in August that will get better.
>> 
>> So I just had time to push your changes and screenshoot the output of your test in _basic_tasks:
>> 
>> <image.png>
>> 
>> <image.png>
>> 
>> Best!!
>> .r.
>> 
>> 
>>> On 30. Jul 2020, at 17:07, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>> 
>>> I worked on updated PHP files supplied by Rainer this morning and merged them with my latest changes on the "prototypes.php" window.
>>> 
>>> Basically it worked file, except for links requiring absolute paths. For instance the ones opening windows for "output" and "trace" on the "produce.php" window. BP should work if folder "bolprocessor" is not exactly at the root of the web server. To test it, I have a "try" folder at the root, so the actual path to php files is /try/bolprocessor/php/
>>> 
>>> For instance, the link to the output window should be:
>>> 
>>> /try/bolprocessor/test_output/out.sco
>>> 
>>> and not:
>>> 
>>> /bolprocessor/test_output/out.sco
>>> 
>>> To this effect I constructed variable $path_above which is equal to "try" in this case. Not just one folder, it could be a longer path… To this effect I had no other choice than using the $root variable equal to  "/Applications/MAMP/htdocs/"
>>> 
>>> I checked the use of DIRECTORY_SEPARATOR in all files, including "protoptypes.php" in which it was still missing in several places. Now, if you open "prototypes.php" on a sound-object that contains MIDI codes, you'll get a link, near the bottom of the page, to listen to them. This also needs to be verified on Windows.
>>> 
>>> Finally, the "IMAGE" link at the bottom of the sound-object prototype should open a window with some graphics and texts. I am now working on its content.
>>> 
>>> The new version has been pushed to my repertory (https://leti.lt/bolprocessor/ <https://leti.lt/bolprocessor/>). The main changes should be called "Windows compatibility". I modified some parameters for object durations and their proper rendering as MIDI files, but that's only a cleaning up of code. I might even revise that part once we can load back a "-mi" file to BP2.9.8.  I know Anthony is working hard — fixing my old bugs! — and compatibility will be achieved soon. I am aware that has taken care of ensuring that command-line options have a priority over settings in the "-se" files.
>>> 
>>> Bernard
>>> 
>>> Rainer Schuetz wrote on 30/07/2020 03:56:
>>>> Dear Bernard (eh, I need to remember to call you Berny!),
>>>> 
>>>> I thought I have to show some responsibility for Windows, as I pushed it and you even wrote the checklist. I took a slightly deeper look into it… It’s unfortunately quite time consuming for me, as for one I am very slow with this kind of stuff, and also I need to learn by doing. So I am far from having gotten through your checklist, and we are getting to this unfortunate state, where I bump into problems while you already happily move on to more interesting stuff. And now there is a Windows version where a bit more works than before - but the changes are based on a version you have already left behind ;-) Classical problem in version control. I have the (preliminary and “naive”) Windows-changes on a separate branch called “crossplatform” so that you can inspect them.
>>>> 
>>>> The problem is the following: for filesystem access Windows is actually rather flexible in that it understands both “slash” and “backslash” as directory-separators, it can even tolerate paths, where bsl and sl are mixed. But there is a but: If you do str_replace operations they’ll compare literal strings, and then no “smart handling” occurs, after all it’s php and not Windows. And there are more hidden difficulties. The web-servers configuration (httpd.conf) contains the “document_root” configuration in hybrid unix-notation, something like “c:/Users/schue/Sites”. Nothing wrong with that and it’s even required. But when php queries the file-system, as in getcwd(), the return-value will be a string with clean Windows syntax, e.g. C:\Users\Schue\Sites\bolprocessor\php\. Now if you subtract one from the other with str_replace, it will fail, because the doc_root syntax has slashes, while the other has backslashes. Therefore many of your str_replace based operations fail. I tried the following:
>>>> 
>>>> If we don’t use document root, it is actually easier to locate the various folders - we even get more flexible because we don’t need to care where in the web-server filetree the user stores the bp folder. So we also don’t need to account for $path_to_bp. We start from bolprocessor/php with getcwd() and query two paths upwards getting path-names by a php-function confusingly called “dirname()” which actually returns the parent directory (of a file or a directory) (!). This should sound quite interesting for you, because you have some quite complicated algorithms to “move up” a directory, and alas they also break on Windows because you depend on a literal “slash”.
>>>> 
>>>> So far I’ve tried to remove the dependency on the variable $root which causes problems in every invocation on Windows, and I’ve tried to clean up around those spots places where I saw that dependency on a literal “slash” was likely to break things. As I said not every slash will break things, but it can be tricky to predict which one will break and which one not. Anyways php also provides a smart keyword “DIRECORY_SEPARATOR” that will return a string slash on Unix and a string backslash on Windows. It looks quite clumsy in the code, but it can help…
>>>> 
>>>> I couldn’t think through all the code, basically I went with project wide search through your code and did something about all the $root and $path_to_bp variables, after I defined the bottom-up ones: $bp-php-path, $bp-application-path and $bp-parent-path. The last one is the closest to $root - but it doesn’t require the $path_to_bp. I’ve also replace the “home”-folder name by a  variable, so that if somebody needs multiple bp-folders side by side s/he can give them different names.
>>>> 
>>>> It’s more of a sketch I guess, I am sure there is much more detail-filing to do to get it fully clean. It’s a way of doing it that keeps quite strongly inline with your current logic of doing things. Occasionally I though functions might be quite useful, for example when you exlode a path by delimiter and then pick up the last bit - it’s literally the same thing about 10 times, it could probably be done at one spot and then called. But unfortunately I am not sure how to do that in php, and I didn’t want to be too intrusive.
>>>> 
>>>> Anyways, my suggestions might be interesting to read, even if you ultimately do it differently, even more the “php-way”… I am not sure if you want to look up the diffs in the GitHub repo (you’d have to go to the branch “crossplatform”) or maybe even “pull” the load. But I also uploaded a snapshot of the bp-folder to https://bp.bagong.de/archives/bp_php.zip <https://bp.bagong.de/archives/bp_php.zip>.
>>>> 
>>>> Best
>>>> .r.
>>>> 
>>>> 
>>>> 
>>>>> On 29. Jul 2020, at 14:36, Bernard Bel <ber...@gm... <mailto:ber...@gm...> <mailto:ber...@gm... <mailto:ber...@gm...>>> wrote:
>>>>> 
>>>>> You are not dreaming: the PHP interface is producing sounds!
>>>>> 
>>>>> Yet not via the console, indeed. I was wondering how to hear a "preview" of MIDI streams handled by sound-object prototypes. I discovered a Javascript function "MIDIjs.play" that plays MIDI files:
>>>>> 
>>>>> https://www.midijs.net/ <https://www.midijs.net/>
>>>>> 
>>>>> However we did not have MIDI files except when they were imported (using MIDI Library). We only have time-stamped MIDI codes that Bol Processor will send to a MIDI player. The MIDI Library does create MIDI files but not from a sequence of MIDI instructions. It requires a text description of the MIDI file in a poorly-documented format called "MF2T/T2MF". This is the output format of its MIDI file to text converter. I could keep it for imported MIDI files but for all other objects I implemented the creation of a MF2T/T2MF file from time-stamped MIDI codes.
>>>>> 
>>>>> This was not easy because time-stamped MIDI codes do not contain all the information required in a well-formed type-1 MIDI file, which is the format required by the text to MIDIfile converter. A type-1 MIDI file may contain several tracks, so we guess track changes in time-stamped MIDI codes when time goes back (generally to 0), and a "NewTrk" instruction is inserted.
>>>>> 
>>>>> Another problem on which I spent part of the night is to figure out the tempo. MIDI files have a header that tells the format, number of tracks, and an obscure parameter called "division" giving "the time resolution in clicks per quarter note". This looks simple but I needed to figure out how this parameter will be taken care of so that an imported MIDI file will be played at exactly the same speed. I got confused with a variable called "Tref" in Bol Processor, which is the period of the metronom used to count the number of beats of an object. The problem is that Tref is actually a number of "ticks" and not a number of milliseconds. To sort it out we need to know the time-resolution. Since it was 1 millisecond by default on most sound-objects, I wrongly asssumed that Tref was in milliseconds.
>>>>> 
>>>>> Finally I found the magic equation:
>>>>> resolution = division / (0.48 * Tref)
>>>>> 
>>>>> Don't ask me why "0.48"… It works!
>>>>> 
>>>>> If you use the new PHP interface (now on https://leti.lt/bolprocessor/ <https://leti.lt/bolprocessor/>) you will see a "Play MIDI file" link just below the Csound score of any object in "-mi.abc1". It works with the "default player" on your system, so we need to check it on Windows and other platforms.
>>>>> 
>>>>> Then you can try to upload a MIDI file and select a long one to check that durations remain correct. In the "ctests.zip" folder I added "Christmas_Carols_-_12_Days_Of_Christmas.mid" that will give you a 14-second delight! One you have heard the song try to modify its duration
>>>>> 
>>>>> Tring to import this multitrack file in BP2.9.8 does not yield a satisfactory result: most data is ignored or modified. Therefore we can't rely on BP current methods for importing/exporting MIDI files — written by Kumar in 1997. The MIDI file format has been upgraded since then.
>>>>> 
>>>>> Normally we won't need to read/write multitrack MIDI files but some users may not be aware of it and they may try to create a multitrack sound-object. It will work since the conversion to time-stamped MIDI bytes is correct. This will add a new "density" to sound-objects! ;-)
>>>>> 
>>>>> This does not really require an update of the checklist because it is a tentative implementation that forced me to study again MIDI encoding and the representation of physical time in Bol Processor. Understanding time resolution, durations, preroll and postroll etc.
>>>>> 
>>>>> 
>>>>> Bernard
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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>
> 
> _______________________________________________
> 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] Windows compatibility of the PHP interface

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

> On 30. Jul 2020, at 23:15, Bernard Bel <ber...@gm...> wrote:
> 
> Your test revealed that there was still a problem: "root" displays both slashes and backslashes!

Haha, yea, that’s why I removed it in the first place ;-) But never mind, this should work too, although I am pretty sure php has an idiomatical way of avoiding too much “slash” explicitness… But I don’t have the time to work it out atm…

Have fun with GD, I am happy to keep committing your snapshots, it only takes me 5 mins.

And then: happy holidays - I hear in France *everybody* is on holidays in August!!! Hopefully no “second wave”. In Germany numbers are rising, but not dramatically yet. Funny that mountains remind you of India - that’s not the typical association. But as a matter of fact I also have mountain associations with India. As a small kid (hahaha, I can now say "50 year ago" to impress people, although I feel like 30), but back to the thread: as a small kid I lived in India for 3 years, almost in the southern tip: in Ootacamund in the Nilgiris… An incredibly beautiful place… My father worked there as a consultant in a potato farming project. Quite funny, a German working on potatoes in India… I am sure they thought he knew everything ;-)

Best!
.r.

Re: [bp-dev] Windows compatibility of the PHP interface

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

Dear Rainer,

Your test revealed that there was still a problem: "root" displays both 
slashes and backslashes!

I fixed it with these two instructions:

$root = str_replace("\\",DIRECTORY_SEPARATOR,$root);
$root = str_replace("/",DIRECTORY_SEPARATOR,$root);

"A sound-object that contains MIDI codes"... I should just have 
suggested to open "-mi.abc1" and look at its sound-object prototypes! 
Each of them will yield an audible MIDI sequence and an image (link at 
the bottom of the page).

I spent the evening programming the image. It works great. GD Library is 
so easy, and I found a tricky fast method to pass on many variables to 
the image page… The secret is "require_once($image_file);" which 
includes a php file constructed dynamically by the prototype.php page.

I uploaded the new version (with the correction on "root").  I still 
need to do some more work on images to make them look at least as 
complete as BP2.9.78.

Have a nice holiday!  I guess that by mid-August we'll have a stronger 
connection between the interface and the console. We're checking on Mac 
and you will be able to do the same checks on Windows. ;-)

44°C today, it's time to go to mountains — though it reminds me of India :-)

Bernard

Rainer Schuetz wrote on 30/07/2020 18:20:
> Dear Berny,
>
> Wow thanks, that was quick!! You are faster doing all this than I was 
> trying out stuff ;-). Unfortunately I am kind of under a deadline for 
> the weekend and can’t invest substantial time before next week (when 
> you’re in holidays)… Hopefully in August I’ll find some time to try 
> and understand this better. Atm I don’t even understand a sentence 
> like "if you open "prototypes.php" on a sound-object that contains 
> MIDI codes” - let alone be able to act upon it. But hopefully in 
> August that will get better.
>
> So I just had time to push your changes and screenshoot the output of 
> your test in _basic_tasks:
>
>
>
> Best!!
> .r.
>
>
>> On 30. Jul 2020, at 17:07, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> I worked on updated PHP files supplied by Rainer this morning and 
>> merged them with my latest changes on the "prototypes.php" window.
>>
>> Basically it worked file, except for links requiring absolute paths. 
>> For instance the ones opening windows for "output" and "trace" on the 
>> "produce.php" window. BP should work if folder "bolprocessor" is not 
>> exactly at the root of the web server. To test it, I have a "try" 
>> folder at the root, so the actual path to php files is 
>> /try/bolprocessor/php/
>>
>> For instance, the link to the output window should be:
>>
>> /try/bolprocessor/test_output/out.sco
>>
>> and not:
>>
>> /bolprocessor/test_output/out.sco
>>
>> To this effect I constructed variable $path_above which is equal to 
>> "try" in this case. Not just one folder, it could be a longer path… 
>> To this effect I had no other choice than using the $root variable 
>> equal to  "/Applications/MAMP/htdocs/"
>>
>> I checked the use of DIRECTORY_SEPARATOR in all files, including 
>> "protoptypes.php" in which it was still missing in several places. 
>> Now, if you open "prototypes.php" on a sound-object that contains 
>> MIDI codes, you'll get a link, near the bottom of the page, to listen 
>> to them. This also needs to be verified on Windows.
>>
>> Finally, the "IMAGE" link at the bottom of the sound-object prototype 
>> should open a window with some graphics and texts. I am now working 
>> on its content.
>>
>> The new version has been pushed to my repertory 
>> (https://leti.lt/bolprocessor/). The main changes should be called 
>> "Windows compatibility". I modified some parameters for object 
>> durations and their proper rendering as MIDI files, but that's only a 
>> cleaning up of code. I might even revise that part once we can load 
>> back a "-mi" file to BP2.9.8.  I know Anthony is working hard — 
>> fixing my old bugs! — and compatibility will be achieved soon. I am 
>> aware that has taken care of ensuring that command-line options have 
>> a priority over settings in the "-se" files.
>>
>> Bernard
>>
>> Rainer Schuetz wrote on 30/07/2020 03:56:
>>> Dear Bernard (eh, I need to remember to call you Berny!),
>>>
>>> I thought I have to show some responsibility for Windows, as I 
>>> pushed it and you even wrote the checklist. I took a slightly deeper 
>>> look into it… It’s unfortunately quite time consuming for me, as for 
>>> one I am very slow with this kind of stuff, and also I need to learn 
>>> by doing. So I am far from having gotten through your checklist, and 
>>> we are getting to this unfortunate state, where I bump into problems 
>>> while you already happily move on to more interesting stuff. And now 
>>> there is a Windows version where a bit more works than before - but 
>>> the changes are based on a version you have already left behind ;-) 
>>> Classical problem in version control. I have the (preliminary and 
>>> “naive”) Windows-changes on a separate branch called “crossplatform” 
>>> so that you can inspect them.
>>>
>>> The problem is the following: for filesystem access Windows is 
>>> actually rather flexible in that it understands both “slash” and 
>>> “backslash” as directory-separators, it can even tolerate paths, 
>>> where bsl and sl are mixed. But there is a but: If you do 
>>> str_replace operations they’ll compare literal strings, and then no 
>>> “smart handling” occurs, after all it’s php and not Windows. And 
>>> there are more hidden difficulties. The web-servers configuration 
>>> (httpd.conf) contains the “document_root” configuration in hybrid 
>>> unix-notation, something like “c:/Users/schue/Sites”. Nothing wrong 
>>> with that and it’s even required. But when php queries the 
>>> file-system, as in getcwd(), the return-value will be a string with 
>>> clean Windows syntax, e.g. C:\Users\Schue\Sites\bolprocessor\php\. 
>>> Now if you subtract one from the other with str_replace, it will 
>>> fail, because the doc_root syntax has slashes, while the other has 
>>> backslashes. Therefore many of your str_replace based operations 
>>> fail. I tried the following:
>>>
>>> If we don’t use document root, it is actually easier to locate the 
>>> various folders - we even get more flexible because we don’t need to 
>>> care where in the web-server filetree the user stores the bp folder. 
>>> So we also don’t need to account for $path_to_bp. We start from 
>>> bolprocessor/php with getcwd() and query two paths upwards getting 
>>> path-names by a php-function confusingly called “dirname()” which 
>>> actually returns the parent directory (of a file or a directory) 
>>> (!). This should sound quite interesting for you, because you have 
>>> some quite complicated algorithms to “move up” a directory, and alas 
>>> they also break on Windows because you depend on a literal “slash”.
>>>
>>> So far I’ve tried to remove the dependency on the variable $root 
>>> which causes problems in every invocation on Windows, and I’ve tried 
>>> to clean up around those spots places where I saw that dependency on 
>>> a literal “slash” was likely to break things. As I said not every 
>>> slash will break things, but it can be tricky to predict which one 
>>> will break and which one not. Anyways php also provides a smart 
>>> keyword “DIRECORY_SEPARATOR” that will return a string slash on Unix 
>>> and a string backslash on Windows. It looks quite clumsy in the 
>>> code, but it can help…
>>>
>>> I couldn’t think through all the code, basically I went with project 
>>> wide search through your code and did something about all the $root 
>>> and $path_to_bp variables, after I defined the bottom-up ones: 
>>> $bp-php-path, $bp-application-path and $bp-parent-path. The last one 
>>> is the closest to $root - but it doesn’t require the $path_to_bp. 
>>> I’ve also replace the “home”-folder name by a variable, so that if 
>>> somebody needs multiple bp-folders side by side s/he can give them 
>>> different names.
>>>
>>> It’s more of a sketch I guess, I am sure there is much more 
>>> detail-filing to do to get it fully clean. It’s a way of doing it 
>>> that keeps quite strongly inline with your current logic of doing 
>>> things. Occasionally I though functions might be quite useful, for 
>>> example when you exlode a path by delimiter and then pick up the 
>>> last bit - it’s literally the same thing about 10 times, it could 
>>> probably be done at one spot and then called. But unfortunately I am 
>>> not sure how to do that in php, and I didn’t want to be too intrusive.
>>>
>>> Anyways, my suggestions might be interesting to read, even if you 
>>> ultimately do it differently, even more the “php-way”… I am not sure 
>>> if you want to look up the diffs in the GitHub repo (you’d have to 
>>> go to the branch “crossplatform”) or maybe even “pull” the load. But 
>>> I also uploaded a snapshot of the bp-folder to 
>>> https://bp.bagong.de/archives/bp_php.zip.
>>>
>>> Best
>>> .r.
>>>
>>>
>>>
>>>> On 29. Jul 2020, at 14:36, Bernard Bel <ber...@gm... 
>>>> <mailto:ber...@gm...> <mailto:ber...@gm...>> wrote:
>>>>
>>>> You are not dreaming: the PHP interface is producing sounds!
>>>>
>>>> Yet not via the console, indeed. I was wondering how to hear a 
>>>> "preview" of MIDI streams handled by sound-object prototypes. I 
>>>> discovered a Javascript function "MIDIjs.play" that plays MIDI files:
>>>>
>>>> https://www.midijs.net/
>>>>
>>>> However we did not have MIDI files except when they were imported 
>>>> (using MIDI Library). We only have time-stamped MIDI codes that Bol 
>>>> Processor will send to a MIDI player. The MIDI Library does create 
>>>> MIDI files but not from a sequence of MIDI instructions. It 
>>>> requires a text description of the MIDI file in a poorly-documented 
>>>> format called "MF2T/T2MF". This is the output format of its MIDI 
>>>> file to text converter. I could keep it for imported MIDI files but 
>>>> for all other objects I implemented the creation of a MF2T/T2MF 
>>>> file from time-stamped MIDI codes.
>>>>
>>>> This was not easy because time-stamped MIDI codes do not contain 
>>>> all the information required in a well-formed type-1 MIDI file, 
>>>> which is the format required by the text to MIDIfile converter. A 
>>>> type-1 MIDI file may contain several tracks, so we guess track 
>>>> changes in time-stamped MIDI codes when time goes back (generally 
>>>> to 0), and a "NewTrk" instruction is inserted.
>>>>
>>>> Another problem on which I spent part of the night is to figure out 
>>>> the tempo. MIDI files have a header that tells the format, number 
>>>> of tracks, and an obscure parameter called "division" giving "the 
>>>> time resolution in clicks per quarter note". This looks simple but 
>>>> I needed to figure out how this parameter will be taken care of so 
>>>> that an imported MIDI file will be played at exactly the same 
>>>> speed. I got confused with a variable called "Tref" in Bol 
>>>> Processor, which is the period of the metronom used to count the 
>>>> number of beats of an object. The problem is that Tref is actually 
>>>> a number of "ticks" and not a number of milliseconds. To sort it 
>>>> out we need to know the time-resolution. Since it was 1 millisecond 
>>>> by default on most sound-objects, I wrongly asssumed that Tref was 
>>>> in milliseconds.
>>>>
>>>> Finally I found the magic equation:
>>>> resolution = division / (0.48 * Tref)
>>>>
>>>> Don't ask me why "0.48"… It works!
>>>>
>>>> If you use the new PHP interface (now on 
>>>> https://leti.lt/bolprocessor/) you will see a "Play MIDI file" link 
>>>> just below the Csound score of any object in "-mi.abc1". It works 
>>>> with the "default player" on your system, so we need to check it on 
>>>> Windows and other platforms.
>>>>
>>>> Then you can try to upload a MIDI file and select a long one to 
>>>> check that durations remain correct. In the "ctests.zip" folder I 
>>>> added "Christmas_Carols_-_12_Days_Of_Christmas.mid" that will give 
>>>> you a 14-second delight! One you have heard the song try to modify 
>>>> its duration
>>>>
>>>> Tring to import this multitrack file in BP2.9.8 does not yield a 
>>>> satisfactory result: most data is ignored or modified. Therefore we 
>>>> can't rely on BP current methods for importing/exporting MIDI files 
>>>> — written by Kumar in 1997. The MIDI file format has been upgraded 
>>>> since then.
>>>>
>>>> Normally we won't need to read/write multitrack MIDI files but some 
>>>> users may not be aware of it and they may try to create a 
>>>> multitrack sound-object. It will work since the conversion to 
>>>> time-stamped MIDI bytes is correct. This will add a new "density" 
>>>> to sound-objects! ;-)
>>>>
>>>> This does not really require an update of the checklist because it 
>>>> is a tentative implementation that forced me to study again MIDI 
>>>> encoding and the representation of physical time in Bol Processor. 
>>>> Understanding time resolution, durations, preroll and postroll etc.
>>>>
>>>>
>>>> Bernard
>>>>
>>>>
>>>> _______________________________________________
>>>> bolprocessor-devel mailing list
>>>> 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] Windows compatibility of the PHP interface

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

Dear Berny,

Wow thanks, that was quick!! You are faster doing all this than I was trying out stuff ;-). Unfortunately I am kind of under a deadline for the weekend and can’t invest substantial time before next week (when you’re in holidays)… Hopefully in August I’ll find some time to try and understand this better. Atm I don’t even understand a sentence like "if you open "prototypes.php" on a sound-object that contains MIDI codes” - let alone be able to act upon it. But hopefully in August that will get better.

So I just had time to push your changes and screenshoot the output of your test in _basic_tasks:





Best!!
.r.


> On 30. Jul 2020, at 17:07, Bernard Bel <ber...@gm...> wrote:
> 
> I worked on updated PHP files supplied by Rainer this morning and merged them with my latest changes on the "prototypes.php" window.
> 
> Basically it worked file, except for links requiring absolute paths. For instance the ones opening windows for "output" and "trace" on the "produce.php" window. BP should work if folder "bolprocessor" is not exactly at the root of the web server. To test it, I have a "try" folder at the root, so the actual path to php files is /try/bolprocessor/php/
> 
> For instance, the link to the output window should be:
> 
> /try/bolprocessor/test_output/out.sco
> 
> and not:
> 
> /bolprocessor/test_output/out.sco
> 
> To this effect I constructed variable $path_above which is equal to "try" in this case. Not just one folder, it could be a longer path… To this effect I had no other choice than using the $root variable equal to  "/Applications/MAMP/htdocs/"
> 
> I checked the use of DIRECTORY_SEPARATOR in all files, including "protoptypes.php" in which it was still missing in several places. Now, if you open "prototypes.php" on a sound-object that contains MIDI codes, you'll get a link, near the bottom of the page, to listen to them. This also needs to be verified on Windows.
> 
> Finally, the "IMAGE" link at the bottom of the sound-object prototype should open a window with some graphics and texts. I am now working on its content.
> 
> The new version has been pushed to my repertory (https://leti.lt/bolprocessor/). The main changes should be called "Windows compatibility". I modified some parameters for object durations and their proper rendering as MIDI files, but that's only a cleaning up of code. I might even revise that part once we can load back a "-mi" file to BP2.9.8.  I know Anthony is working hard — fixing my old bugs! — and compatibility will be achieved soon. I am aware that has taken care of ensuring that command-line options have a priority over settings in the "-se" files.
> 
> Bernard
> 
> Rainer Schuetz wrote on 30/07/2020 03:56:
>> Dear Bernard (eh, I need to remember to call you Berny!),
>> 
>> I thought I have to show some responsibility for Windows, as I pushed it and you even wrote the checklist. I took a slightly deeper look into it… It’s unfortunately quite time consuming for me, as for one I am very slow with this kind of stuff, and also I need to learn by doing. So I am far from having gotten through your checklist, and we are getting to this unfortunate state, where I bump into problems while you already happily move on to more interesting stuff. And now there is a Windows version where a bit more works than before - but the changes are based on a version you have already left behind ;-) Classical problem in version control. I have the (preliminary and “naive”) Windows-changes on a separate branch called “crossplatform” so that you can inspect them.
>> 
>> The problem is the following: for filesystem access Windows is actually rather flexible in that it understands both “slash” and “backslash” as directory-separators, it can even tolerate paths, where bsl and sl are mixed. But there is a but: If you do str_replace operations they’ll compare literal strings, and then no “smart handling” occurs, after all it’s php and not Windows. And there are more hidden difficulties. The web-servers configuration (httpd.conf) contains the “document_root” configuration in hybrid unix-notation, something like “c:/Users/schue/Sites”. Nothing wrong with that and it’s even required. But when php queries the file-system, as in getcwd(), the return-value will be a string with clean Windows syntax, e.g. C:\Users\Schue\Sites\bolprocessor\php\. Now if you subtract one from the other with str_replace, it will fail, because the doc_root syntax has slashes, while the other has backslashes. Therefore many of your str_replace based operations fail. I tried the following:
>> 
>> If we don’t use document root, it is actually easier to locate the various folders - we even get more flexible because we don’t need to care where in the web-server filetree the user stores the bp folder. So we also don’t need to account for $path_to_bp. We start from bolprocessor/php with getcwd() and query two paths upwards getting path-names by a php-function confusingly called “dirname()” which actually returns the parent directory (of a file or a directory) (!). This should sound quite interesting for you, because you have some quite complicated algorithms to “move up” a directory, and alas they also break on Windows because you depend on a literal “slash”.
>> 
>> So far I’ve tried to remove the dependency on the variable $root which causes problems in every invocation on Windows, and I’ve tried to clean up around those spots places where I saw that dependency on a literal “slash” was likely to break things. As I said not every slash will break things, but it can be tricky to predict which one will break and which one not. Anyways php also provides a smart keyword “DIRECORY_SEPARATOR” that will return a string slash on Unix and a string backslash on Windows. It looks quite clumsy in the code, but it can help…
>> 
>> I couldn’t think through all the code, basically I went with project wide search through your code and did something about all the $root and $path_to_bp variables, after I defined the bottom-up ones: $bp-php-path, $bp-application-path and $bp-parent-path. The last one is the closest to $root - but it doesn’t require the $path_to_bp. I’ve also replace the “home”-folder name by a variable, so that if somebody needs multiple bp-folders side by side s/he can give them different names.
>> 
>> It’s more of a sketch I guess, I am sure there is much more detail-filing to do to get it fully clean. It’s a way of doing it that keeps quite strongly inline with your current logic of doing things. Occasionally I though functions might be quite useful, for example when you exlode a path by delimiter and then pick up the last bit - it’s literally the same thing about 10 times, it could probably be done at one spot and then called. But unfortunately I am not sure how to do that in php, and I didn’t want to be too intrusive.
>> 
>> Anyways, my suggestions might be interesting to read, even if you ultimately do it differently, even more the “php-way”… I am not sure if you want to look up the diffs in the GitHub repo (you’d have to go to the branch “crossplatform”) or maybe even “pull” the load. But I also uploaded a snapshot of the bp-folder to https://bp.bagong.de/archives/bp_php.zip.
>> 
>> Best
>> .r.
>> 
>> 
>> 
>>> On 29. Jul 2020, at 14:36, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>> 
>>> You are not dreaming: the PHP interface is producing sounds!
>>> 
>>> Yet not via the console, indeed. I was wondering how to hear a "preview" of MIDI streams handled by sound-object prototypes. I discovered a Javascript function "MIDIjs.play" that plays MIDI files:
>>> 
>>> https://www.midijs.net/
>>> 
>>> However we did not have MIDI files except when they were imported (using MIDI Library). We only have time-stamped MIDI codes that Bol Processor will send to a MIDI player. The MIDI Library does create MIDI files but not from a sequence of MIDI instructions. It requires a text description of the MIDI file in a poorly-documented format called "MF2T/T2MF". This is the output format of its MIDI file to text converter. I could keep it for imported MIDI files but for all other objects I implemented the creation of a MF2T/T2MF file from time-stamped MIDI codes.
>>> 
>>> This was not easy because time-stamped MIDI codes do not contain all the information required in a well-formed type-1 MIDI file, which is the format required by the text to MIDIfile converter. A type-1 MIDI file may contain several tracks, so we guess track changes in time-stamped MIDI codes when time goes back (generally to 0), and a "NewTrk" instruction is inserted.
>>> 
>>> Another problem on which I spent part of the night is to figure out the tempo. MIDI files have a header that tells the format, number of tracks, and an obscure parameter called "division" giving "the time resolution in clicks per quarter note". This looks simple but I needed to figure out how this parameter will be taken care of so that an imported MIDI file will be played at exactly the same speed. I got confused with a variable called "Tref" in Bol Processor, which is the period of the metronom used to count the number of beats of an object. The problem is that Tref is actually a number of "ticks" and not a number of milliseconds. To sort it out we need to know the time-resolution. Since it was 1 millisecond by default on most sound-objects, I wrongly asssumed that Tref was in milliseconds.
>>> 
>>> Finally I found the magic equation:
>>> resolution = division / (0.48 * Tref)
>>> 
>>> Don't ask me why "0.48"… It works!
>>> 
>>> If you use the new PHP interface (now on https://leti.lt/bolprocessor/) you will see a "Play MIDI file" link just below the Csound score of any object in "-mi.abc1". It works with the "default player" on your system, so we need to check it on Windows and other platforms.
>>> 
>>> Then you can try to upload a MIDI file and select a long one to check that durations remain correct. In the "ctests.zip" folder I added "Christmas_Carols_-_12_Days_Of_Christmas.mid" that will give you a 14-second delight! One you have heard the song try to modify its duration
>>> 
>>> Tring to import this multitrack file in BP2.9.8 does not yield a satisfactory result: most data is ignored or modified. Therefore we can't rely on BP current methods for importing/exporting MIDI files — written by Kumar in 1997. The MIDI file format has been upgraded since then.
>>> 
>>> Normally we won't need to read/write multitrack MIDI files but some users may not be aware of it and they may try to create a multitrack sound-object. It will work since the conversion to time-stamped MIDI bytes is correct. This will add a new "density" to sound-objects! ;-)
>>> 
>>> This does not really require an update of the checklist because it is a tentative implementation that forced me to study again MIDI encoding and the representation of physical time in Bol Processor. Understanding time resolution, durations, preroll and postroll etc.
>>> 
>>> 
>>> Bernard
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Windows compatibility of the PHP interface

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

I worked on updated PHP files supplied by Rainer this morning and merged 
them with my latest changes on the "prototypes.php" window.

Basically it worked file, except for links requiring absolute paths. For 
instance the ones opening windows for "output" and "trace" on the 
"produce.php" window. BP should work if folder "bolprocessor" is not 
exactly at the root of the web server. To test it, I have a "try" folder 
at the root, so the actual path to php files is /try/bolprocessor/php/

For instance, the link to the output window should be:

/try/bolprocessor/test_output/out.sco

and not:

/bolprocessor/test_output/out.sco

To this effect I constructed variable $path_above which is equal to 
"try" in this case. Not just one folder, it could be a longer path… To 
this effect I had no other choice than using the $root variable equal to 
  "/Applications/MAMP/htdocs/"

I checked the use of DIRECTORY_SEPARATOR in all files, including 
"protoptypes.php" in which it was still missing in several places. Now, 
if you open "prototypes.php" on a sound-object that contains MIDI codes, 
you'll get a link, near the bottom of the page, to listen to them. This 
also needs to be verified on Windows.

Finally, the "IMAGE" link at the bottom of the sound-object prototype 
should open a window with some graphics and texts. I am now working on 
its content.

The new version has been pushed to my repertory 
(https://leti.lt/bolprocessor/). The main changes should be called 
"Windows compatibility". I modified some parameters for object durations 
and their proper rendering as MIDI files, but that's only a cleaning up 
of code. I might even revise that part once we can load back a "-mi" 
file to BP2.9.8.  I know Anthony is working hard — fixing my old bugs! — 
and compatibility will be achieved soon. I am aware that has taken care 
of ensuring that command-line options have a priority over settings in 
the "-se" files.

Bernard

Rainer Schuetz wrote on 30/07/2020 03:56:
> Dear Bernard (eh, I need to remember to call you Berny!),
>
> I thought I have to show some responsibility for Windows, as I pushed 
> it and you even wrote the checklist. I took a slightly deeper look 
> into it… It’s unfortunately quite time consuming for me, as for one I 
> am very slow with this kind of stuff, and also I need to learn by 
> doing. So I am far from having gotten through your checklist, and we 
> are getting to this unfortunate state, where I bump into problems 
> while you already happily move on to more interesting stuff. And now 
> there is a Windows version where a bit more works than before - but 
> the changes are based on a version you have already left behind ;-) 
> Classical problem in version control. I have the (preliminary and 
> “naive”) Windows-changes on a separate branch called “crossplatform” 
> so that you can inspect them.
>
> The problem is the following: for filesystem access Windows is 
> actually rather flexible in that it understands both “slash” and 
> “backslash” as directory-separators, it can even tolerate paths, where 
> bsl and sl are mixed. But there is a but: If you do str_replace 
> operations they’ll compare literal strings, and then no “smart 
> handling” occurs, after all it’s php and not Windows. And there are 
> more hidden difficulties. The web-servers configuration (httpd.conf) 
> contains the “document_root” configuration in hybrid unix-notation, 
> something like “c:/Users/schue/Sites”. Nothing wrong with that and 
> it’s even required. But when php queries the file-system, as in 
> getcwd(), the return-value will be a string with clean Windows syntax, 
> e.g. C:\Users\Schue\Sites\bolprocessor\php\. Now if you subtract one 
> from the other with str_replace, it will fail, because the doc_root 
> syntax has slashes, while the other has backslashes. Therefore many of 
> your str_replace based operations fail. I tried the following:
>
> If we don’t use document root, it is actually easier to locate the 
> various folders - we even get more flexible because we don’t need to 
> care where in the web-server filetree the user stores the bp folder. 
> So we also don’t need to account for $path_to_bp. We start from 
> bolprocessor/php with getcwd() and query two paths upwards getting 
> path-names by a php-function confusingly called “dirname()” which 
> actually returns the parent directory (of a file or a directory) (!). 
> This should sound quite interesting for you, because you have some 
> quite complicated algorithms to “move up” a directory, and alas they 
> also break on Windows because you depend on a literal “slash”.
>
> So far I’ve tried to remove the dependency on the variable $root which 
> causes problems in every invocation on Windows, and I’ve tried to 
> clean up around those spots places where I saw that dependency on a 
> literal “slash” was likely to break things. As I said not every slash 
> will break things, but it can be tricky to predict which one will 
> break and which one not. Anyways php also provides a smart keyword 
> “DIRECORY_SEPARATOR” that will return a string slash on Unix and a 
> string backslash on Windows. It looks quite clumsy in the code, but it 
> can help…
>
> I couldn’t think through all the code, basically I went with project 
> wide search through your code and did something about all the $root 
> and $path_to_bp variables, after I defined the bottom-up ones: 
> $bp-php-path, $bp-application-path and $bp-parent-path. The last one 
> is the closest to $root - but it doesn’t require the $path_to_bp. I’ve 
> also replace the “home”-folder name by a variable, so that if somebody 
> needs multiple bp-folders side by side s/he can give them different names.
>
> It’s more of a sketch I guess, I am sure there is much more 
> detail-filing to do to get it fully clean. It’s a way of doing it that 
> keeps quite strongly inline with your current logic of doing things. 
> Occasionally I though functions might be quite useful, for example 
> when you exlode a path by delimiter and then pick up the last bit - 
> it’s literally the same thing about 10 times, it could probably be 
> done at one spot and then called. But unfortunately I am not sure how 
> to do that in php, and I didn’t want to be too intrusive.
>
> Anyways, my suggestions might be interesting to read, even if you 
> ultimately do it differently, even more the “php-way”… I am not sure 
> if you want to look up the diffs in the GitHub repo (you’d have to go 
> to the branch “crossplatform”) or maybe even “pull” the load. But I 
> also uploaded a snapshot of the bp-folder to 
> https://bp.bagong.de/archives/bp_php.zip.
>
> Best
> .r.
>
>
>
>> On 29. Jul 2020, at 14:36, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> You are not dreaming: the PHP interface is producing sounds!
>>
>> Yet not via the console, indeed. I was wondering how to hear a 
>> "preview" of MIDI streams handled by sound-object prototypes. I 
>> discovered a Javascript function "MIDIjs.play" that plays MIDI files:
>>
>> https://www.midijs.net/
>>
>> However we did not have MIDI files except when they were imported 
>> (using MIDI Library). We only have time-stamped MIDI codes that Bol 
>> Processor will send to a MIDI player. The MIDI Library does create 
>> MIDI files but not from a sequence of MIDI instructions. It requires 
>> a text description of the MIDI file in a poorly-documented format 
>> called "MF2T/T2MF". This is the output format of its MIDI file to 
>> text converter. I could keep it for imported MIDI files but for all 
>> other objects I implemented the creation of a MF2T/T2MF file from 
>> time-stamped MIDI codes.
>>
>> This was not easy because time-stamped MIDI codes do not contain all 
>> the information required in a well-formed type-1 MIDI file, which is 
>> the format required by the text to MIDIfile converter. A type-1 MIDI 
>> file may contain several tracks, so we guess track changes in 
>> time-stamped MIDI codes when time goes back (generally to 0), and a 
>> "NewTrk" instruction is inserted.
>>
>> Another problem on which I spent part of the night is to figure out 
>> the tempo. MIDI files have a header that tells the format, number of 
>> tracks, and an obscure parameter called "division" giving "the time 
>> resolution in clicks per quarter note". This looks simple but I 
>> needed to figure out how this parameter will be taken care of so that 
>> an imported MIDI file will be played at exactly the same speed. I got 
>> confused with a variable called "Tref" in Bol Processor, which is the 
>> period of the metronom used to count the number of beats of an 
>> object. The problem is that Tref is actually a number of "ticks" and 
>> not a number of milliseconds. To sort it out we need to know the 
>> time-resolution. Since it was 1 millisecond by default on most 
>> sound-objects, I wrongly asssumed that Tref was in milliseconds.
>>
>> Finally I found the magic equation:
>> resolution = division / (0.48 * Tref)
>>
>> Don't ask me why "0.48"… It works!
>>
>> If you use the new PHP interface (now on 
>> https://leti.lt/bolprocessor/) you will see a "Play MIDI file" link 
>> just below the Csound score of any object in "-mi.abc1". It works 
>> with the "default player" on your system, so we need to check it on 
>> Windows and other platforms.
>>
>> Then you can try to upload a MIDI file and select a long one to check 
>> that durations remain correct. In the "ctests.zip" folder I added 
>> "Christmas_Carols_-_12_Days_Of_Christmas.mid" that will give you a 
>> 14-second delight! One you have heard the song try to modify its duration
>>
>> Tring to import this multitrack file in BP2.9.8 does not yield a 
>> satisfactory result: most data is ignored or modified. Therefore we 
>> can't rely on BP current methods for importing/exporting MIDI files — 
>> written by Kumar in 1997. The MIDI file format has been upgraded 
>> since then.
>>
>> Normally we won't need to read/write multitrack MIDI files but some 
>> users may not be aware of it and they may try to create a multitrack 
>> sound-object. It will work since the conversion to time-stamped MIDI 
>> bytes is correct. This will add a new "density" to sound-objects! ;-)
>>
>> This does not really require an update of the checklist because it is 
>> a tentative implementation that forced me to study again MIDI 
>> encoding and the representation of physical time in Bol Processor. 
>> Understanding time resolution, durations, preroll and postroll etc.
>>
>>
>> Bernard
>>
>>
>> _______________________________________________
>> 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] Sounds on the PHP interface

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

Dear Rainer,

This is wonderful work!

I downloaded your zip folder and looked at changesn looking at your 
explanations. Using “DIRECTORY_SEPARATOR” is certainly the way to go, 
and I see that you simplified path construction algorithms. Function 
“dirname()” is also welcome!

Meanwhile - up to this morning - I had modied "prototypes.php" and maybe 
"_basic_tasks.php" to fix errors on timings. But I will compare versions 
to include your updates. This I am going to do in priority, so the 
fully-compatible version should be available today.

Bernard

Rainer Schuetz wrote on 30/07/2020 03:56:
> Dear Bernard (eh, I need to remember to call you Berny!),
>
> I thought I have to show some responsibility for Windows, as I pushed 
> it and you even wrote the checklist. I took a slightly deeper look 
> into it… It’s unfortunately quite time consuming for me, as for one I 
> am very slow with this kind of stuff, and also I need to learn by 
> doing. So I am far from having gotten through your checklist, and we 
> are getting to this unfortunate state, where I bump into problems 
> while you already happily move on to more interesting stuff. And now 
> there is a Windows version where a bit more works than before - but 
> the changes are based on a version you have already left behind ;-) 
> Classical problem in version control. I have the (preliminary and 
> “naive”) Windows-changes on a separate branch called “crossplatform” 
> so that you can inspect them.
>
> The problem is the following: for filesystem access Windows is 
> actually rather flexible in that it understands both “slash” and 
> “backslash” as directory-separators, it can even tolerate paths, where 
> bsl and sl are mixed. But there is a but: If you do str_replace 
> operations they’ll compare literal strings, and then no “smart 
> handling” occurs, after all it’s php and not Windows. And there are 
> more hidden difficulties. The web-servers configuration (httpd.conf) 
> contains the “document_root” configuration in hybrid unix-notation, 
> something like “c:/Users/schue/Sites”. Nothing wrong with that and 
> it’s even required. But when php queries the file-system, as in 
> getcwd(), the return-value will be a string with clean Windows syntax, 
> e.g. C:\Users\Schue\Sites\bolprocessor\php\. Now if you subtract one 
> from the other with str_replace, it will fail, because the doc_root 
> syntax has slashes, while the other has backslashes. Therefore many of 
> your str_replace based operations fail. I tried the following:
>
> If we don’t use document root, it is actually easier to locate the 
> various folders - we even get more flexible because we don’t need to 
> care where in the web-server filetree the user stores the bp folder. 
> So we also don’t need to account for $path_to_bp. We start from 
> bolprocessor/php with getcwd() and query two paths upwards getting 
> path-names by a php-function confusingly called “dirname()” which 
> actually returns the parent directory (of a file or a directory) (!). 
> This should sound quite interesting for you, because you have some 
> quite complicated algorithms to “move up” a directory, and alas they 
> also break on Windows because you depend on a literal “slash”.
>
> So far I’ve tried to remove the dependency on the variable $root which 
> causes problems in every invocation on Windows, and I’ve tried to 
> clean up around those spots places where I saw that dependency on a 
> literal “slash” was likely to break things. As I said not every slash 
> will break things, but it can be tricky to predict which one will 
> break and which one not. Anyways php also provides a smart keyword 
> “DIRECORY_SEPARATOR” that will return a string slash on Unix and a 
> string backslash on Windows. It looks quite clumsy in the code, but it 
> can help…
>
> I couldn’t think through all the code, basically I went with project 
> wide search through your code and did something about all the $root 
> and $path_to_bp variables, after I defined the bottom-up ones: 
> $bp-php-path, $bp-application-path and $bp-parent-path. The last one 
> is the closest to $root - but it doesn’t require the $path_to_bp. I’ve 
> also replace the “home”-folder name by a variable, so that if somebody 
> needs multiple bp-folders side by side s/he can give them different names.
>
> It’s more of a sketch I guess, I am sure there is much more 
> detail-filing to do to get it fully clean. It’s a way of doing it that 
> keeps quite strongly inline with your current logic of doing things. 
> Occasionally I though functions might be quite useful, for example 
> when you exlode a path by delimiter and then pick up the last bit - 
> it’s literally the same thing about 10 times, it could probably be 
> done at one spot and then called. But unfortunately I am not sure how 
> to do that in php, and I didn’t want to be too intrusive.
>
> Anyways, my suggestions might be interesting to read, even if you 
> ultimately do it differently, even more the “php-way”… I am not sure 
> if you want to look up the diffs in the GitHub repo (you’d have to go 
> to the branch “crossplatform”) or maybe even “pull” the load. But I 
> also uploaded a snapshot of the bp-folder to 
> https://bp.bagong.de/archives/bp_php.zip.
>
> Best
> .r.
>
>
>
>> On 29. Jul 2020, at 14:36, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> You are not dreaming: the PHP interface is producing sounds!
>>
>> Yet not via the console, indeed. I was wondering how to hear a 
>> "preview" of MIDI streams handled by sound-object prototypes. I 
>> discovered a Javascript function "MIDIjs.play" that plays MIDI files:
>>
>> https://www.midijs.net/
>>
>> However we did not have MIDI files except when they were imported 
>> (using MIDI Library). We only have time-stamped MIDI codes that Bol 
>> Processor will send to a MIDI player. The MIDI Library does create 
>> MIDI files but not from a sequence of MIDI instructions. It requires 
>> a text description of the MIDI file in a poorly-documented format 
>> called "MF2T/T2MF". This is the output format of its MIDI file to 
>> text converter. I could keep it for imported MIDI files but for all 
>> other objects I implemented the creation of a MF2T/T2MF file from 
>> time-stamped MIDI codes.
>>
>> This was not easy because time-stamped MIDI codes do not contain all 
>> the information required in a well-formed type-1 MIDI file, which is 
>> the format required by the text to MIDIfile converter. A type-1 MIDI 
>> file may contain several tracks, so we guess track changes in 
>> time-stamped MIDI codes when time goes back (generally to 0), and a 
>> "NewTrk" instruction is inserted.
>>
>> Another problem on which I spent part of the night is to figure out 
>> the tempo. MIDI files have a header that tells the format, number of 
>> tracks, and an obscure parameter called "division" giving "the time 
>> resolution in clicks per quarter note". This looks simple but I 
>> needed to figure out how this parameter will be taken care of so that 
>> an imported MIDI file will be played at exactly the same speed. I got 
>> confused with a variable called "Tref" in Bol Processor, which is the 
>> period of the metronom used to count the number of beats of an 
>> object. The problem is that Tref is actually a number of "ticks" and 
>> not a number of milliseconds. To sort it out we need to know the 
>> time-resolution. Since it was 1 millisecond by default on most 
>> sound-objects, I wrongly asssumed that Tref was in milliseconds.
>>
>> Finally I found the magic equation:
>> resolution = division / (0.48 * Tref)
>>
>> Don't ask me why "0.48"… It works!
>>
>> If you use the new PHP interface (now on 
>> https://leti.lt/bolprocessor/) you will see a "Play MIDI file" link 
>> just below the Csound score of any object in "-mi.abc1". It works 
>> with the "default player" on your system, so we need to check it on 
>> Windows and other platforms.
>>
>> Then you can try to upload a MIDI file and select a long one to check 
>> that durations remain correct. In the "ctests.zip" folder I added 
>> "Christmas_Carols_-_12_Days_Of_Christmas.mid" that will give you a 
>> 14-second delight! One you have heard the song try to modify its duration
>>
>> Tring to import this multitrack file in BP2.9.8 does not yield a 
>> satisfactory result: most data is ignored or modified. Therefore we 
>> can't rely on BP current methods for importing/exporting MIDI files — 
>> written by Kumar in 1997. The MIDI file format has been upgraded 
>> since then.
>>
>> Normally we won't need to read/write multitrack MIDI files but some 
>> users may not be aware of it and they may try to create a multitrack 
>> sound-object. It will work since the conversion to time-stamped MIDI 
>> bytes is correct. This will add a new "density" to sound-objects! ;-)
>>
>> This does not really require an update of the checklist because it is 
>> a tentative implementation that forced me to study again MIDI 
>> encoding and the representation of physical time in Bol Processor. 
>> Understanding time resolution, durations, preroll and postroll etc.
>>
>>
>> Bernard
>>
>>
>> _______________________________________________
>> 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] Sounds on the PHP interface

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

Dear Bernard (eh, I need to remember to call you Berny!),

I thought I have to show some responsibility for Windows, as I pushed it and you even wrote the checklist. I took a slightly deeper look into it… It’s unfortunately quite time consuming for me, as for one I am very slow with this kind of stuff, and also I need to learn by doing. So I am far from having gotten through your checklist, and we are getting to this unfortunate state, where I bump into problems while you already happily move on to more interesting stuff. And now there is a Windows version where a bit more works than before - but the changes are based on a version you have already left behind ;-) Classical problem in version control. I have the (preliminary and “naive”) Windows-changes on a separate branch called “crossplatform” so that you can inspect them.

The problem is the following: for filesystem access Windows is actually rather flexible in that it understands both “slash” and “backslash” as directory-separators, it can even tolerate paths, where bsl and sl are mixed. But there is a but: If you do str_replace operations they’ll compare literal strings, and then no “smart handling” occurs, after all it’s php and not Windows. And there are more hidden difficulties. The web-servers configuration (httpd.conf) contains the “document_root” configuration in hybrid unix-notation, something like “c:/Users/schue/Sites”. Nothing wrong with that and it’s even required. But when php queries the file-system, as in getcwd(), the return-value will be a string with clean Windows syntax, e.g. C:\Users\Schue\Sites\bolprocessor\php\. Now if you subtract one from the other with str_replace, it will fail, because the doc_root syntax has slashes, while the other has backslashes. Therefore many of your str_replace based operations fail. I tried the following:

If we don’t use document root, it is actually easier to locate the various folders - we even get more flexible because we don’t need to care where in the web-server filetree the user stores the bp folder. So we also don’t need to account for $path_to_bp. We start from bolprocessor/php with getcwd() and query two paths upwards getting path-names by a php-function confusingly called “dirname()” which actually returns the parent directory (of a file or a directory) (!). This should sound quite interesting for you, because you have some quite complicated algorithms to “move up” a directory, and alas they also break on Windows because you depend on a literal “slash”. 

So far I’ve tried to remove the dependency on the variable $root which causes problems in every invocation on Windows, and I’ve tried to clean up around those spots places where I saw that dependency on a literal “slash” was likely to break things. As I said not every slash will break things, but it can be tricky to predict which one will break and which one not. Anyways php also provides a smart keyword “DIRECORY_SEPARATOR” that will return a string slash on Unix and a string backslash on Windows. It looks quite clumsy in the code, but it can help…

I couldn’t think through all the code, basically I went with project wide search through your code and did something about all the $root and $path_to_bp variables, after I defined the bottom-up ones: $bp-php-path, $bp-application-path and $bp-parent-path. The last one is the closest to $root - but it doesn’t require the $path_to_bp. I’ve also replace the “home”-folder name by a variable, so that if somebody needs multiple bp-folders side by side s/he can give them different names.

It’s more of a sketch I guess, I am sure there is much more detail-filing to do to get it fully clean. It’s a way of doing it that keeps quite strongly inline with your current logic of doing things. Occasionally I though functions might be quite useful, for example when you exlode a path by delimiter and then pick up the last bit - it’s literally the same thing about 10 times, it could probably be done at one spot and then called. But unfortunately I am not sure how to do that in php, and I didn’t want to be too intrusive. 

Anyways, my suggestions might be interesting to read, even if you ultimately do it differently, even more the “php-way”… I am not sure if you want to look up the diffs in the GitHub repo (you’d have to go to the branch “crossplatform”) or maybe even “pull” the load. But I also uploaded a snapshot of the bp-folder to https://bp.bagong.de/archives/bp_php.zip.

Best
.r.




> On 29. Jul 2020, at 14:36, Bernard Bel <ber...@gm...> wrote:
> 
> You are not dreaming: the PHP interface is producing sounds!
> 
> Yet not via the console, indeed. I was wondering how to hear a "preview" of MIDI streams handled by sound-object prototypes. I discovered a Javascript function "MIDIjs.play" that plays MIDI files:
> 
> https://www.midijs.net/
> 
> However we did not have MIDI files except when they were imported (using MIDI Library). We only have time-stamped MIDI codes that Bol Processor will send to a MIDI player. The MIDI Library does create MIDI files but not from a sequence of MIDI instructions. It requires a text description of the MIDI file in a poorly-documented format called "MF2T/T2MF". This is the output format of its MIDI file to text converter. I could keep it for imported MIDI files but for all other objects I implemented the creation of a MF2T/T2MF file from time-stamped MIDI codes.
> 
> This was not easy because time-stamped MIDI codes do not contain all the information required in a well-formed type-1 MIDI file, which is the format required by the text to MIDIfile converter. A type-1 MIDI file may contain several tracks, so we guess track changes in time-stamped MIDI codes when time goes back (generally to 0), and a "NewTrk" instruction is inserted.
> 
> Another problem on which I spent part of the night is to figure out the tempo. MIDI files have a header that tells the format, number of tracks, and an obscure parameter called "division" giving "the time resolution in clicks per quarter note". This looks simple but I needed to figure out how this parameter will be taken care of so that an imported MIDI file will be played at exactly the same speed. I got confused with a variable called "Tref" in Bol Processor, which is the period of the metronom used to count the number of beats of an object. The problem is that Tref is actually a number of "ticks" and not a number of milliseconds. To sort it out we need to know the time-resolution. Since it was 1 millisecond by default on most sound-objects, I wrongly asssumed that Tref was in milliseconds.
> 
> Finally I found the magic equation:
> resolution = division / (0.48 * Tref)
> 
> Don't ask me why "0.48"… It works!
> 
> If you use the new PHP interface (now on https://leti.lt/bolprocessor/) you will see a "Play MIDI file" link just below the Csound score of any object in "-mi.abc1". It works with the "default player" on your system, so we need to check it on Windows and other platforms.
> 
> Then you can try to upload a MIDI file and select a long one to check that durations remain correct. In the "ctests.zip" folder I added "Christmas_Carols_-_12_Days_Of_Christmas.mid" that will give you a 14-second delight! One you have heard the song try to modify its duration
> 
> Tring to import this multitrack file in BP2.9.8 does not yield a satisfactory result: most data is ignored or modified. Therefore we can't rely on BP current methods for importing/exporting MIDI files — written by Kumar in 1997. The MIDI file format has been upgraded since then.
> 
> Normally we won't need to read/write multitrack MIDI files but some users may not be aware of it and they may try to create a multitrack sound-object. It will work since the conversion to time-stamped MIDI bytes is correct. This will add a new "density" to sound-objects! ;-)
> 
> This does not really require an update of the checklist because it is a tentative implementation that forced me to study again MIDI encoding and the representation of physical time in Bol Processor. Understanding time resolution, durations, preroll and postroll etc.
> 
> 
> Bernard
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Graphics on PHP interface

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

A preview of graphics on sound-object prototype pages. Look at the 
attached picture and try it for good on my latest version 
(https://leti.lt/bolprocessor/)…

If you see the rectangles and texts it means that GD library is 
installed on your web server. I bet this will be the case at least with 
MAMP installations.

Now I need to learn the syntax and construct the entire image!

The cool thing, at least on Mac, is that the image is sized to fit 
exactly its frame. There is a zoom/unzoom on images. Increasing the 
window size also increases the image size, and it becomes scrollable. 
It's exactly as it should be with no need of programming!

The bad thing is that all parameters need to be passed to the new 
window, using GET statements, unless we use session variables which 
would be a bad idea… Every window is independent. You can examine 
several sound-objects side by side if the screen is large enough (or in 3D!)

Bernard

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

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

Back to the project of running BP1 in Apple II emulation…

I have been able to buy a 5 1/4" floppy disk unit in good shape for only 
50 euros. My aim is now to borrow an Apple II form a fan user and copy 
the disks to new supports. Then I would send these copies to Anthony by 
Fedex in a carefully sealed package.

The friend to whom I had given my IIc has disposed of it… (He's still my 
friend!) A second-hand IIc is sold about 400 to 800 euros on eBay, this 
would be too much!

However I discovered a Facebook group "Apple II France" and I am sending 
them a request for borrowing a machine for, say, 1/2 hour to copy the 
floppies. They seem to be very active, using oscilloscopes and soldering 
irons to repare their machines - like in the old good days. If one of 
them lives in a reachable area, I will take the next step of 
duplication, using the recent disk unit.

Bernard

[bp-dev] Sounds on the PHP interface

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

You are not dreaming: the PHP interface is producing sounds!

Yet not via the console, indeed. I was wondering how to hear a "preview" 
of MIDI streams handled by sound-object prototypes. I discovered a 
Javascript function "MIDIjs.play" that plays MIDI files:

https://www.midijs.net/

However we did not have MIDI files except when they were imported (using 
MIDI Library). We only have time-stamped MIDI codes that Bol Processor 
will send to a MIDI player. The MIDI Library does create MIDI files but 
not from a sequence of MIDI instructions. It requires a text description 
of the MIDI file in a poorly-documented format called "MF2T/T2MF". This 
is the output format of its MIDI file to text converter. I could keep it 
for imported MIDI files but for all other objects I implemented the 
creation of a MF2T/T2MF file from time-stamped MIDI codes.

This was not easy because time-stamped MIDI codes do not contain all the 
information required in a well-formed type-1 MIDI file, which is the 
format required by the text to MIDIfile converter. A type-1 MIDI file 
may contain several tracks, so we guess track changes in time-stamped 
MIDI codes when time goes back (generally to 0), and a "NewTrk" 
instruction is inserted.

Another problem on which I spent part of the night is to figure out the 
tempo. MIDI files have a header that tells the format, number of tracks, 
and an obscure parameter called "division" giving "the time resolution 
in clicks per quarter note". This looks simple but I needed to figure 
out how this parameter will be taken care of so that an imported MIDI 
file will be played at exactly the same speed. I got confused with a 
variable called "Tref" in Bol Processor, which is the period of the 
metronom used to count the number of beats of an object. The problem is 
that Tref is actually a number of "ticks" and not a number of 
milliseconds. To sort it out we need to know the time-resolution. Since 
it was 1 millisecond by default on most sound-objects, I wrongly 
asssumed that Tref was in milliseconds.

Finally I found the magic equation:
resolution = division / (0.48 * Tref)

Don't ask me why "0.48"… It works!

If you use the new PHP interface (now on https://leti.lt/bolprocessor/) 
you will see a "Play MIDI file" link just below the Csound score of any 
object in "-mi.abc1". It works with the "default player" on your system, 
so we need to check it on Windows and other platforms.

Then you can try to upload a MIDI file and select a long one to check 
that durations remain correct. In the "ctests.zip" folder I added 
"Christmas_Carols_-_12_Days_Of_Christmas.mid" that will give you a 
14-second delight! One you have heard the song try to modify its duration

Tring to import this multitrack file in BP2.9.8 does not yield a 
satisfactory result: most data is ignored or modified. Therefore we 
can't rely on BP current methods for importing/exporting MIDI files — 
written by Kumar in 1997. The MIDI file format has been upgraded since then.

Normally we won't need to read/write multitrack MIDI files but some 
users may not be aware of it and they may try to create a multitrack 
sound-object. It will work since the conversion to time-stamped MIDI 
bytes is correct. This will add a new "density" to sound-objects! ;-)

This does not really require an update of the checklist because it is a 
tentative implementation that forced me to study again MIDI encoding and 
the representation of physical time in Bol Processor. Understanding time 
resolution, durations, preroll and postroll etc.


Bernard

Re: [bp-dev] Graphics on PHP interface

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

> It is difficult to expect that Bol Processor will some day require features available in ImageMagick and not in GD. My imagination suggests that the next serious graphic output should be 3D with objects floating in space, or even 4D including time-travel. ;-)

The 4D feature should get highest priority, I put in 4 plusses with 4 different fake-identity accounts. Just had a discussion about real-world internet-based live interaction in ensemble musicking. Alas, reality and the promises diverge so greatly - but backwards time travel could make up for all the latency problems. I bit of AI to compensate for jitter, and we’re ready to go. So please move that up on your todo list, right after you’ve cleaned the windscreen, I’d say ;-)

Best
.r.

Re: [bp-dev] Graphics on PHP interface

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

You are right Rainer!

At last I ran phpinfo() on my MAMP (default) installation. It shows that 
GD is installed:

'./configure' '--with-apxs2=/Applications/MAMP/Library/bin/apxs' 
'--with-gd' '--with-jpeg-dir=/Applications/MAMP/Library' 
'--with-png-dir=/Applications/MAMP/Library' '--with-zlib' 
'--with-zlib-dir=/Applications/MAMP/Library' 
'--with-freetype-dir=/Applications/MAMP/Library' 
'--prefix=/Applications/MAMP/bin/php/php7.1.32' 
'--exec-prefix=/Applications/MAMP/bin/php/php7.1.32' 
'--sysconfdir=/Applications/MAMP/bin/php/php7.1.32/conf' 
'--with-config-file-path=/Applications/MAMP/bin/php/php7.1.32/conf' 
'--enable-ftp' '--enable-gd-native-ttf' 
'--with-bz2=/Applications/MAMP/Library' '--with-ldap' 
'--with-mysqli=mysqlnd' '--enable-mbstring=all' 
'--with-curl=/Applications/MAMP/Library' '--enable-sockets' 
'--enable-bcmath' 
'--with-imap=shared,/Applications/MAMP/Library/lib/imap-2007f' 
'--with-imap-ssl=/Applications/MAMP/Library' '--enable-soap' 
'--with-kerberos' '--enable-calendar' 
'--with-pgsql=shared,/Applications/MAMP/Library/pg' '--enable-exif' 
'--with-libxml-dir=/Applications/MAMP/Library' 
'--with-gettext=shared,/Applications/MAMP/Library' 
'--with-xsl=/Applications/MAMP/Library' '--with-pdo-mysql=mysqlnd' 
'--with-pdo-pgsql=shared,/Applications/MAMP/Library/pg' 
'--with-mcrypt=shared,/Applications/MAMP/Library' 
'--with-openssl=/Applications/MAMP/Library' '--enable-zip' 
'--with-iconv=/Applications/MAMP/Library' '--enable-opcache' 
'--enable-intl' '--with-tidy=shared' 
'--with-icu-dir=/Applications/MAMP/Library' '--enable-wddx' 
'--with-libexpat-dir=/Applications/MAMP/Library' '--with-readline' 
'--with-mhash' '--with-iconv-dir=/Applications/MAMP/Library' 
'--with-xmlrpc' 'YACC=/Applications/MAMP/Library/bin/bison'

It is difficult to expect that Bol Processor will some day require 
features available in ImageMagick and not in GD. My imagination suggests 
that the next serious graphic output should be 3D with objects floating 
in space, or even 4D including time-travel. ;-)

The argument that we shouldn't oblige users to install a package that is 
not supported by a default installation of PHP definitely makes the 
decision.

At first I was feeling anxious that GD might be a "depleted" method that 
some day will be abandoned, just like QuickDraw with Apple. Should it 
happen, let us hope there will be code converters and maybe even 
compatibility with current instructions. All we need in the current BP 
is to draw (colored) lines, dotted lines, rectangles, filled rectangles, 
and write text. We could almost do it on an Apple II :-)

So, I'll make a start with GD and let you know!

GD is also compaible with C, so code translation will become easy. All 
you need to do when a graphic comes is send an instruction like 
window.open() creating a window with 2 scrollbars, then execute the 
graphic procedure. This should be multiplatform like window.open() in 
Javascript…

I like to tell Anthony that things will get easy! Because I noticed the 
commits he pushed last night: the type of annoying bug fixes that no 
user will acknowledge because they don't yield a visible effect! Much 
like a car mechanics has spent a day looking for a spare part knowing 
that their client is going to complain that they have not "even" cleaned 
the windscreen! ;-)

Bernard

Rainer Schuetz wrote on 28/07/2020 18:00:
> The info on that site that IM is somewhat better is likely outdated in terms of image-processing quality, and the fact that IM supports so many file-formats might not be relevant? I am surprised GD is not “just there” in you MAMP-install - have you looked? It came with both of mine installs. The advantage of that would be that no configuration/download etc is required at all (I bet the download functionality is a MAMP-pro function;-)) I wonder how similar the APIs are, many CMSes just support either...
> 
> Best
> .r.
> 
>> On 28. Jul 2020, at 17:50, Bernard Bel<ber...@gm...>  wrote:
>>
>> I started looking for a graphics library using the same instructions in C and PHP. The "GD library" was the first one I had noticed. But MAMP offers a direct installation of ImageMagick = namely "Imagick" under PHP:
>>
>> https://en.wikipedia.org/wiki/ImageMagick
>>
>> Comparing the two options there are probably equivalent for the usage we anticipate: drawing lines and rectangles! There is a comparison on that page dating back to May 2020:
>>
>> https://blog.runcloud.io/imagemagick/
>>
>> So, I am following the path of ImageMagick unless there is a good reason to prefer GD…
>>
>> Bernard
>>

Re: [bp-dev] Graphics on PHP interface -> ImageMagick

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

I would expect either library to be fine.  Good idea to find something that works equally well in C or PHP! :-)

Anthony

On Jul 28, 2020 12:39 PM, Bernard Bel <ber...@gm...> wrote:

> I tried ImageMagick. It works beautfully and "draw" instructions are 
> documented there:
>
> https://www.php.net/manual/fr/class.imagickdraw.php
>
> --------
>
> I started looking for a graphics library using the same instructions in 
> C and PHP. The "GD library" was the first one I had noticed. But MAMP 
> offers a direct installation of ImageMagick = namely "Imagick" under PHP:
>
> https://en.wikipedia.org/wiki/ImageMagick
>
> Comparing the two options there are probably equivalent for the usage we 
> anticipate: drawing lines and rectangles! There is a comparison on that 
> page dating back to May 2020:
>
> https://blog.runcloud.io/imagemagick/
>
> So, I am following the path of ImageMagick unless there is a good reason 
> to prefer GD…
>
> Bernard
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] Graphics on PHP interface -> ImageMagick

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

I tried ImageMagick. It works beautfully and "draw" instructions are 
documented there:

https://www.php.net/manual/fr/class.imagickdraw.php

--------

I started looking for a graphics library using the same instructions in 
C and PHP. The "GD library" was the first one I had noticed. But MAMP 
offers a direct installation of ImageMagick = namely "Imagick" under PHP:

https://en.wikipedia.org/wiki/ImageMagick

Comparing the two options there are probably equivalent for the usage we 
anticipate: drawing lines and rectangles! There is a comparison on that 
page dating back to May 2020:

https://blog.runcloud.io/imagemagick/

So, I am following the path of ImageMagick unless there is a good reason 
to prefer GD…

Bernard

Re: [bp-dev] Graphics on PHP interface

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

The info on that site that IM is somewhat better is likely outdated in terms of image-processing quality, and the fact that IM supports so many file-formats might not be relevant? I am surprised GD is not “just there” in you MAMP-install - have you looked? It came with both of mine installs. The advantage of that would be that no configuration/download etc is required at all (I bet the download functionality is a MAMP-pro function ;-)) I wonder how similar the APIs are, many CMSes just support either...

Best
.r.

> On 28. Jul 2020, at 17:50, Bernard Bel <ber...@gm...> wrote:
> 
> I started looking for a graphics library using the same instructions in C and PHP. The "GD library" was the first one I had noticed. But MAMP offers a direct installation of ImageMagick = namely "Imagick" under PHP:
> 
> https://en.wikipedia.org/wiki/ImageMagick
> 
> Comparing the two options there are probably equivalent for the usage we anticipate: drawing lines and rectangles! There is a comparison on that page dating back to May 2020:
> 
> https://blog.runcloud.io/imagemagick/
> 
> So, I am following the path of ImageMagick unless there is a good reason to prefer GD…
> 
> Bernard
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel