|
From: Rainer S. <rs...@ba...> - 2020-07-30 01:56:25
|
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 |
