|
From: Bernard B. <ber...@gm...> - 2020-07-30 06:44:31
|
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 |
