|
From: Rainer S. <rs...@ba...> - 2020-07-30 16:21:02
|
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 |
