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