You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(11) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(11) |
Feb
|
Mar
(1) |
Apr
(11) |
May
(1) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(5) |
Nov
(25) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(10) |
| 2010 |
Jan
(12) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(15) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(181) |
Aug
(71) |
Sep
(42) |
Oct
(106) |
Nov
(43) |
Dec
(3) |
| 2021 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2025 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bernard B. <ber...@gm...> - 2020-10-18 07:31:22
|
Excellent idea! I am going to implement it and push the new version.
The PHP interface needs to read the file and find "canvas.width" and
"canvas.height" to create a pop-up window with a size fitting the image,
if possible, so that scrolling is not necessary when images are small
(see attached image). Larger images may be displayed with scrollbars on
a pop-up with 1200 px width and 600 px height. So, I am implementing the
solution you sent me as example.
I am less convinced by storing several images on a single file. Images
may generate very large code. For instance, my browsers refuse to
display the Nadaka composition in "objects" mode because it contains too
many statements — drawing pivots, writing names etc. Things will get
worse if several images are packed in a single file. For this reason the
console writes several files if necessary at the moment. These will be
found by the iinterface and links displayed in a table with no space
limitation.
I have not yet tried the making of several images, and the console
deactivates "Improvize" which would trigger non-stop improvisation. It
may only be used in real-time MIDI. Due to the making of images as
CANVAS files read by the interface at a later stage, we won't be able to
show unending sequences of images on the same window, as in BP2.9.8 with
"-gr.Mozart".
Anthony Kozar wrote on 18/10/2020 04:27:
> I don't know if this email will display correctly for you since the
> content includes HTML tags and scripts.
>
> On 10/17/20, 7:20 PM, Bernard Bel wrote:
>> In fact the console could also write the temporary image file with its
>> unknown values, then read and copy it to the final file once the values
>> have been calculated. So the prototype.php script won't be required to
>> finalize the file. I will do it quickly if you think it's worth!
>
> No need. I may have a better solution. Could you write the
> JavaScript like this instead?
>
> <script>
> function drawImage1(ctx) {
> // This image was created by Bol Processor BP3
> ctx.scale(0.5,0.5);
> ctx.lineWidth = 1;
> ctx.font = "56px arial";
> ctx.lineWidth = 1;
> ctx.beginPath();
> ...
> }
>
> // WRITE THIS PART AT THE END WHEN THE WIDTH AND HEIGHT ARE KNOWN
> window.onload = function() {
> const canvas = document.querySelector('.myCanvas');
> const width = canvas.width = 8736;
> const height = canvas.height = 404;
> const ctx = canvas.getContext('2d');
> drawImage1(ctx);
> };
> </script>
>
> (I was going to suggest that you use the Canvas scale() function to
> make the graphics smaller but I see that you already found it. :)
>
> Another suggestion that I have is to enclose the canvas in a DIV tag
> with a fixed width so that it gets its own scroll bar, like this:
>
> <div class="canvasWrapper">
> <canvas class="myCanvas">
> <p>Your browser does not support CANVAS… :-(</p>
> </canvas>
> </div>
>
> And add this to the <style> tag:
>
> .canvasWrapper {
> width: 100%;
> overflow-x: scroll;
> }
>
> This makes it so that the canvas scrolls by itself which will be
> useful if additional content is added to the HTML such as a header
> labels, links, and/or additional canvas images.
>
> Rather than writing multiple images out to separate files, would you
> want to combine them all in one file? Something like this?
>
> <body>
> <h1>Image 1</h1>
> <div class="canvasWrapper">
> <canvas id="myCanvas-1">
> <p>Your browser does not support CANVAS… :-(</p>
> </canvas>
> </div>
> <script>
> function drawImage1(ctx) { ... }
> </script>
>
> <h1>Image 2</h1>
> <div class="canvasWrapper">
> <canvas id="myCanvas-2">
> <p>Your browser does not support CANVAS… :-(</p>
> </canvas>
> </div>
> <script>
> function drawImage2(ctx) { ... }
> </script>
>
> ......
>
> <script>
> window.onload = function() {
> canvas = document.querySelector('#myCanvas-1');
> canvas.width = 8736;
> canvas.height = 404;
> ctx = canvas.getContext('2d');
> drawImage1(ctx);
>
> canvas = document.querySelector('#myCanvas-2');
> canvas.width = 3000;
> canvas.height = 300;
> ctx = canvas.getContext('2d');
> drawImage2(ctx);
>
> ...
> };
> </script>
> </body>
>
>
> I've attached a modified HTML image with some of these changes.
> Interested to know what you think of these possibilities.
>
> Anthony
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
|
|
From: Anthony K. <mai...@an...> - 2020-10-18 02:34:56
|
I don't know if this email will display correctly for you since the
content includes HTML tags and scripts.
On 10/17/20, 7:20 PM, Bernard Bel wrote:
> In fact the console could also write the temporary image file with its
> unknown values, then read and copy it to the final file once the values
> have been calculated. So the prototype.php script won't be required to
> finalize the file. I will do it quickly if you think it's worth!
No need. I may have a better solution. Could you write the JavaScript
like this instead?
<script>
function drawImage1(ctx) {
// This image was created by Bol Processor BP3
ctx.scale(0.5,0.5);
ctx.lineWidth = 1;
ctx.font = "56px arial";
ctx.lineWidth = 1;
ctx.beginPath();
...
}
// WRITE THIS PART AT THE END WHEN THE WIDTH AND HEIGHT ARE KNOWN
window.onload = function() {
const canvas = document.querySelector('.myCanvas');
const width = canvas.width = 8736;
const height = canvas.height = 404;
const ctx = canvas.getContext('2d');
drawImage1(ctx);
};
</script>
(I was going to suggest that you use the Canvas scale() function to make
the graphics smaller but I see that you already found it. :)
Another suggestion that I have is to enclose the canvas in a DIV tag
with a fixed width so that it gets its own scroll bar, like this:
<div class="canvasWrapper">
<canvas class="myCanvas">
<p>Your browser does not support CANVAS… :-(</p>
</canvas>
</div>
And add this to the <style> tag:
.canvasWrapper {
width: 100%;
overflow-x: scroll;
}
This makes it so that the canvas scrolls by itself which will be useful
if additional content is added to the HTML such as a header labels,
links, and/or additional canvas images.
Rather than writing multiple images out to separate files, would you
want to combine them all in one file? Something like this?
<body>
<h1>Image 1</h1>
<div class="canvasWrapper">
<canvas id="myCanvas-1">
<p>Your browser does not support CANVAS… :-(</p>
</canvas>
</div>
<script>
function drawImage1(ctx) { ... }
</script>
<h1>Image 2</h1>
<div class="canvasWrapper">
<canvas id="myCanvas-2">
<p>Your browser does not support CANVAS… :-(</p>
</canvas>
</div>
<script>
function drawImage2(ctx) { ... }
</script>
......
<script>
window.onload = function() {
canvas = document.querySelector('#myCanvas-1');
canvas.width = 8736;
canvas.height = 404;
ctx = canvas.getContext('2d');
drawImage1(ctx);
canvas = document.querySelector('#myCanvas-2');
canvas.width = 3000;
canvas.height = 300;
ctx = canvas.getContext('2d');
drawImage2(ctx);
...
};
</script>
</body>
I've attached a modified HTML image with some of these changes.
Interested to know what you think of these possibilities.
Anthony
|
|
From: Bernard B. <ber...@gm...> - 2020-10-17 23:21:01
|
In fact the console could also write the temporary image file with its
unknown values, then read and copy it to the final file once the values
have been calculated. So the prototype.php script won't be required to
finalize the file. I will do it quickly if you think it's worth!
Bernard
Anthony Kozar wrote on 17/10/2020 21:01:
> Dear Bernard,
>
> Thanks for all of this work! Having -mi files working will be awesome!
>
> I've checked out your branch of the code. It compiles fine but when I
> try to test creating an HTML image file, I get these warnings on the
> console:
>
> ‘CANVAS_header.txt’ is missing!
> ‘CANVAS_footer.txt’ is missing!
>
> Have you committed these files yet?
>
> I created temporary header and footer files containing these lines:
>
> ---- HEADER ----\n
>
> ---- FOOTER ----\n
>
> But now I get a crash during CreateImageFile():
>
> Creating image file: NadakaPOc5SSSOc4PGRSOc3NO_image_1.html
> Current working dir:
> /Volumes/iMacSystem/Users/anthony/Projects/BP3_graphics_branch/bolprocessor
> bp(65929,0x7fff77df7000) malloc: *** error for object 0x7fff54d44ee0:
> pointer being realloc'd was not allocated
> *** set a breakpoint in malloc_error_break to debug
> Abort trap: 6
>
> I haven't traced the error yet, but my guess is that it happens while
> reading the file "CANVAS_header.txt". Probably in this code:
>
> else {
> while((number = getline(&someline,&length,thisfile)) != -1) {
> fputs(someline,imagePtr);
> }
> fclose(thisfile);
> fputs(word,imagePtr);
> }
>
> The variable someline is uninitialized. The error message suggests that
> a buffer allocated with malloc() should be passed. I'm not sure where
> the getline() function is coming from.
>
> This is the commandline that I am using:
>
> ./bp produce -d --midiout Nadaka.mid -gr data/-gr.Nadaka1 -se
> data/-se.hamsad --traceout Nadaka.txt
>
> Thanks!
>
> Anthony
>
> On 10/17/20, 1:11 PM, Bernard Bel wrote:
>> Dear all,
>>
>> The updated console and its PHP interface are now able to use
>> sound-objects in the production of Csound files, MIDI files, BP data and
>> graphics displayed as "objects" or "pianoroll".
>>
>> I still need to check all situations of time constraints, but the ones I
>> have noticed on trials already looked adequate...
>>
>> This required many changes in the code and the addition of many tracing
>> messages activated by global variables.
>>
>> The real headache was (and still is) that due to changes in space
>> management we end up with a little memory leakage. I spent the whole day
>> tracing it. There is a "Find_leak" variable that activates these
>> messages everywhere. It is not a critical issue because memory leaks
>> occur at the end of the process, once the console is about to end its
>> job. Still, we'll need to fix it when programming recurring processes,
>> i.e. "non-stop improvize".
>>
>> I believe that the "graphics-for-BP3" branch could be merged at this
>> stage because graphics will only require minor adjustments which may be
>> implemented later. We feel impatient to hear sounds! ;-)
>>
>> One important point: the interface now looks for the name of the "-mi"
>> file in the alphabet if it does not find it on top of the grammar. So,
>> the "-mi" file is always specified in the command. Therefore it would
>> not help much to reproduce this process on the console.
>>
>> Bernard
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
|
|
From: Bernard B. <ber...@gm...> - 2020-10-17 21:37:56
|
Dear Anthony, Everything you mention is "normal". The CANVAS header and footer are part of the PHP distribution: https://github.com/bolprocessor/php-frontend/tree/master/php So, they should be placed in the "php" folder. CANVAS_header contains identifiers THE_TITLE, THE_WIDTH and THE_HEIGHT that will be replaced by values calculated by the console and inserted into the image file: WMAX=... => that will set the value of THE_WIDTH HMAX=... => that will set the value of THE_HEIGHT So, you can't just create an image with command line and display it as it is. You need its interpretation by prototype.php. Indeed, the console could keep the image code in memory and replace THE_WIDTH and THE_HEIGHT by their final values once it has completed the calculation. I have done this way because it is less expensive to write code to the file (in imagePtr) as soon as it has been created. getline() is a standard C procedure that reads one line from "thisfile" and puts it in "someline", which is declared as char[200]. I hope it makes it clear ;-) Bernard Anthony Kozar wrote on 17/10/2020 21:01: > Dear Bernard, > > Thanks for all of this work! Having -mi files working will be awesome! > > I've checked out your branch of the code. It compiles fine but when I > try to test creating an HTML image file, I get these warnings on the > console: > > ‘CANVAS_header.txt’ is missing! > ‘CANVAS_footer.txt’ is missing! > > Have you committed these files yet? > > I created temporary header and footer files containing these lines: > > ---- HEADER ----\n > > ---- FOOTER ----\n > > But now I get a crash during CreateImageFile(): > > Creating image file: NadakaPOc5SSSOc4PGRSOc3NO_image_1.html > Current working dir: > /Volumes/iMacSystem/Users/anthony/Projects/BP3_graphics_branch/bolprocessor > > bp(65929,0x7fff77df7000) malloc: *** error for object 0x7fff54d44ee0: > pointer being realloc'd was not allocated > *** set a breakpoint in malloc_error_break to debug > Abort trap: 6 > > I haven't traced the error yet, but my guess is that it happens while > reading the file "CANVAS_header.txt". Probably in this code: > > else { > while((number = getline(&someline,&length,thisfile)) != -1) { > fputs(someline,imagePtr); > } > fclose(thisfile); > fputs(word,imagePtr); > } > > The variable someline is uninitialized. The error message suggests > that a buffer allocated with malloc() should be passed. I'm not sure > where the getline() function is coming from. > > This is the commandline that I am using: > > ./bp produce -d --midiout Nadaka.mid -gr data/-gr.Nadaka1 -se > data/-se.hamsad --traceout Nadaka.txt > > Thanks! > > Anthony > > On 10/17/20, 1:11 PM, Bernard Bel wrote: >> Dear all, >> >> The updated console and its PHP interface are now able to use >> sound-objects in the production of Csound files, MIDI files, BP data and >> graphics displayed as "objects" or "pianoroll". >> >> I still need to check all situations of time constraints, but the ones I >> have noticed on trials already looked adequate... >> >> This required many changes in the code and the addition of many tracing >> messages activated by global variables. >> >> The real headache was (and still is) that due to changes in space >> management we end up with a little memory leakage. I spent the whole day >> tracing it. There is a "Find_leak" variable that activates these >> messages everywhere. It is not a critical issue because memory leaks >> occur at the end of the process, once the console is about to end its >> job. Still, we'll need to fix it when programming recurring processes, >> i.e. "non-stop improvize". >> >> I believe that the "graphics-for-BP3" branch could be merged at this >> stage because graphics will only require minor adjustments which may be >> implemented later. We feel impatient to hear sounds! ;-) >> >> One important point: the interface now looks for the name of the "-mi" >> file in the alphabet if it does not find it on top of the grammar. So, >> the "-mi" file is always specified in the command. Therefore it would >> not help much to reproduce this process on the console. >> >> Bernard > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Anthony K. <mai...@an...> - 2020-10-17 19:02:03
|
Dear Bernard,
Thanks for all of this work! Having -mi files working will be awesome!
I've checked out your branch of the code. It compiles fine but when I
try to test creating an HTML image file, I get these warnings on the
console:
‘CANVAS_header.txt’ is missing!
‘CANVAS_footer.txt’ is missing!
Have you committed these files yet?
I created temporary header and footer files containing these lines:
---- HEADER ----\n
---- FOOTER ----\n
But now I get a crash during CreateImageFile():
Creating image file: NadakaPOc5SSSOc4PGRSOc3NO_image_1.html
Current working dir:
/Volumes/iMacSystem/Users/anthony/Projects/BP3_graphics_branch/bolprocessor
bp(65929,0x7fff77df7000) malloc: *** error for object 0x7fff54d44ee0:
pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
I haven't traced the error yet, but my guess is that it happens while
reading the file "CANVAS_header.txt". Probably in this code:
else {
while((number = getline(&someline,&length,thisfile)) != -1) {
fputs(someline,imagePtr);
}
fclose(thisfile);
fputs(word,imagePtr);
}
The variable someline is uninitialized. The error message suggests that
a buffer allocated with malloc() should be passed. I'm not sure where
the getline() function is coming from.
This is the commandline that I am using:
./bp produce -d --midiout Nadaka.mid -gr data/-gr.Nadaka1 -se
data/-se.hamsad --traceout Nadaka.txt
Thanks!
Anthony
On 10/17/20, 1:11 PM, Bernard Bel wrote:
> Dear all,
>
> The updated console and its PHP interface are now able to use
> sound-objects in the production of Csound files, MIDI files, BP data and
> graphics displayed as "objects" or "pianoroll".
>
> I still need to check all situations of time constraints, but the ones I
> have noticed on trials already looked adequate...
>
> This required many changes in the code and the addition of many tracing
> messages activated by global variables.
>
> The real headache was (and still is) that due to changes in space
> management we end up with a little memory leakage. I spent the whole day
> tracing it. There is a "Find_leak" variable that activates these
> messages everywhere. It is not a critical issue because memory leaks
> occur at the end of the process, once the console is about to end its
> job. Still, we'll need to fix it when programming recurring processes,
> i.e. "non-stop improvize".
>
> I believe that the "graphics-for-BP3" branch could be merged at this
> stage because graphics will only require minor adjustments which may be
> implemented later. We feel impatient to hear sounds! ;-)
>
> One important point: the interface now looks for the name of the "-mi"
> file in the alphabet if it does not find it on top of the grammar. So,
> the "-mi" file is always specified in the command. Therefore it would
> not help much to reproduce this process on the console.
>
> Bernard
|
|
From: Bernard B. <ber...@gm...> - 2020-10-17 17:12:06
|
Dear all, The updated console and its PHP interface are now able to use sound-objects in the production of Csound files, MIDI files, BP data and graphics displayed as "objects" or "pianoroll". I still need to check all situations of time constraints, but the ones I have noticed on trials already looked adequate... This required many changes in the code and the addition of many tracing messages activated by global variables. The real headache was (and still is) that due to changes in space management we end up with a little memory leakage. I spent the whole day tracing it. There is a "Find_leak" variable that activates these messages everywhere. It is not a critical issue because memory leaks occur at the end of the process, once the console is about to end its job. Still, we'll need to fix it when programming recurring processes, i.e. "non-stop improvize". I believe that the "graphics-for-BP3" branch could be merged at this stage because graphics will only require minor adjustments which may be implemented later. We feel impatient to hear sounds! ;-) One important point: the interface now looks for the name of the "-mi" file in the alphabet if it does not find it on top of the grammar. So, the "-mi" file is always specified in the command. Therefore it would not help much to reproduce this process on the console. Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-10-17 06:21:24
|
Dear Anthony,
I worked overnight on loading sound-objeect prototype files. Almost
completed! So, wait for a few more hours before merging the branches!
Bernard
Anthony Kozar wrote on
16/10/2020 12:46:
Fantastic!!! ^_^
I started to look at your code yesterday. I take another look
this weekend and see about merging the two branches. I will probably add
a commandline option for specifying the graphics file name, if that's
alright. Something like --graphicsout would be consistent with the other
output options.
Thanks for this new code! The images look amazing. :-)
Anthony
|
|
From: Bernard B. <ber...@gm...> - 2020-10-16 17:09:48
|
Tonight I will do some work on the same branch to check the production of several images and try to read « -mi » prototype files... Bernard Bel > Le 16 oct. 2020 à 15:32, Bernard Bel <ber...@gm...> a écrit : > > Dear Anthony, > > It is true that vector graphics look nicer than BP2.9.8 images, to say the least… > > The drawback is that very complicated items produce large CANVAS scripts which the web browser may not be able to display. This probably depends on available RAM for the window. Intricate images wouldn't be so useful, unless that can be zoomed in/out like roadmaps. We'll try later! > > After merging the branches (if relevant) you could activate the loading of sound-object prototypes so that I check the graphic display of sound-objects. > > You will see many "tracing" messages in the code activated by global flags. These can be deleted once all conditions have been checked. The same with apparently obsolete code which might give an idea how things were handled in the past… > > The MakeSound() procedure looks misnamed at first. It produces in a single pass "sound" in the form of MIDI real-time messages, MIDI file code, Csound code and pianoroll display. It deals with the final output at the level of "physical time" whereas upper stages of "polymetric expansion" and "building phase diagram" were based on symbolic time. You seemed to be surprized to see the mixture in such a complex procedure but it makes sense : although it could be called several times with an argument indicating which output is expected, for a very large structure several calls would jjust add up computation time… > > It gets exciting to develop things immediately yielding visible results! But I am aware that you still need to work "under the car" for the implementation of real MIDI ! ;-) Full support for this painful step! > > Bernard > > > Anthony Kozar wrote on 16/10/2020 12:46: >> Fantastic!!! ^_^ >> >> I started to look at your code yesterday. I take another look this weekend and see about merging the two branches. I will probably add a commandline option for specifying the graphics file name, if that's alright. Something like --graphicsout would be consistent with the other output options. >> >> Thanks for this new code! The images look amazing. :-) >> >> Anthony >> >>> On Oct 16, 2020 6:28 AM, Bernard Bel <ber...@gm...> wrote: >>> >>> Dear all, >>> >>> I have completed graphic routines on the console and checked them in >>> "objects" and "pianoroll" display modes for simple notes and >>> time-patterns. The display of sound-objects will be checked/fixed once >>> the console is able to load sound-object prototypes. This will also make >>> it possible to create several images in the same command. >>> >>> At this point I am tempted to stop working on branch "graphics-for-BP3" >>> and suggest to merge it with "BP3-develop". The reason is that we might >>> otherwise need to deal with conflicts because of changes in the >>> Makesound() procedure that have implications on real-time MIDI. >>> >>> Graphic display requires the PHP interface to create a window and >>> interpret CANVAS code. The latest version of the interface adjusts >>> window sizes to image sizes. >>> >>> It is possible to create graphic with a command line such as: >>> >>> ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d >>> --csoundout ../my_output/out.sco --traceout >>> ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e.txt --seed 15524 >>> >>> Note that this command is asking for a trace and providing the path and >>> name of the trace file. (The name contains the session ID.) >>> >>> Sending a command without trace: >>> >>> ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d >>> --csoundout ../my_output/out.sco --seed 15524 >>> >>> will end up with "Segmentation fault: 11". >>> >>> The reason is that the console needs a location for the image file, so >>> it uses the path of the trace to locate the image, ending up with: >>> >>> ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e_image_1.html >>> >>> To use graphic routines without a trace we will need a new option >>> specifying a path and the beginning of name(s) for the image file(s). >>> Names will automatically end with "image_1", "image_2" etc. Anyway, if a >>> full name is provided the machine could append it with "_1", "_2" etc. >>> >>> Currently, the console picks up in the settings file the type of image: >>> "objects" or "pianoroll". In case no settings file is available, this >>> option could also be provided in the command line. This is less critical >>> because the default type of an image is set to "pianoroll" if the item >>> contains only simple notes and "objects" in case sound-objects have been >>> found. Still, the two options are possible and interesting if the item >>> contains simple notes and time-patterns, see for instance the attached >>> images. So it would be fair to have a command option forcing the image >>> type. I will also check the display of sound-objects in pianoroll based >>> on notes contained in these objects. >>> >>> I checked all these procedures with several web browsers on Mac and I >>> hope they will work identically in a Windows environment… ;-) >>> >>> 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 > |
|
From: Bernard B. <ber...@gm...> - 2020-10-16 13:32:38
|
Dear Anthony, It is true that vector graphics look nicer than BP2.9.8 images, to say the least… The drawback is that very complicated items produce large CANVAS scripts which the web browser may not be able to display. This probably depends on available RAM for the window. Intricate images wouldn't be so useful, unless that can be zoomed in/out like roadmaps. We'll try later! After merging the branches (if relevant) you could activate the loading of sound-object prototypes so that I check the graphic display of sound-objects. You will see many "tracing" messages in the code activated by global flags. These can be deleted once all conditions have been checked. The same with apparently obsolete code which might give an idea how things were handled in the past… The MakeSound() procedure looks misnamed at first. It produces in a single pass "sound" in the form of MIDI real-time messages, MIDI file code, Csound code and pianoroll display. It deals with the final output at the level of "physical time" whereas upper stages of "polymetric expansion" and "building phase diagram" were based on symbolic time. You seemed to be surprized to see the mixture in such a complex procedure but it makes sense : although it could be called several times with an argument indicating which output is expected, for a very large structure several calls would jjust add up computation time… It gets exciting to develop things immediately yielding visible results! But I am aware that you still need to work "under the car" for the implementation of real MIDI ! ;-) Full support for this painful step! Bernard Anthony Kozar wrote on 16/10/2020 12:46: > Fantastic!!! ^_^ > > I started to look at your code yesterday. I take another look this weekend and see about merging the two branches. I will probably add a commandline option for specifying the graphics file name, if that's alright. Something like --graphicsout would be consistent with the other output options. > > Thanks for this new code! The images look amazing. :-) > > Anthony > > On Oct 16, 2020 6:28 AM, Bernard Bel <ber...@gm...> wrote: > >> Dear all, >> >> I have completed graphic routines on the console and checked them in >> "objects" and "pianoroll" display modes for simple notes and >> time-patterns. The display of sound-objects will be checked/fixed once >> the console is able to load sound-object prototypes. This will also make >> it possible to create several images in the same command. >> >> At this point I am tempted to stop working on branch "graphics-for-BP3" >> and suggest to merge it with "BP3-develop". The reason is that we might >> otherwise need to deal with conflicts because of changes in the >> Makesound() procedure that have implications on real-time MIDI. >> >> Graphic display requires the PHP interface to create a window and >> interpret CANVAS code. The latest version of the interface adjusts >> window sizes to image sizes. >> >> It is possible to create graphic with a command line such as: >> >> ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d >> --csoundout ../my_output/out.sco --traceout >> ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e.txt --seed 15524 >> >> Note that this command is asking for a trace and providing the path and >> name of the trace file. (The name contains the session ID.) >> >> Sending a command without trace: >> >> ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d >> --csoundout ../my_output/out.sco --seed 15524 >> >> will end up with "Segmentation fault: 11". >> >> The reason is that the console needs a location for the image file, so >> it uses the path of the trace to locate the image, ending up with: >> >> ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e_image_1.html >> >> To use graphic routines without a trace we will need a new option >> specifying a path and the beginning of name(s) for the image file(s). >> Names will automatically end with "image_1", "image_2" etc. Anyway, if a >> full name is provided the machine could append it with "_1", "_2" etc. >> >> Currently, the console picks up in the settings file the type of image: >> "objects" or "pianoroll". In case no settings file is available, this >> option could also be provided in the command line. This is less critical >> because the default type of an image is set to "pianoroll" if the item >> contains only simple notes and "objects" in case sound-objects have been >> found. Still, the two options are possible and interesting if the item >> contains simple notes and time-patterns, see for instance the attached >> images. So it would be fair to have a command option forcing the image >> type. I will also check the display of sound-objects in pianoroll based >> on notes contained in these objects. >> >> I checked all these procedures with several web browsers on Mac and I >> hope they will work identically in a Windows environment… ;-) >> >> 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 |
|
From: Anthony K. <mai...@an...> - 2020-10-16 10:47:06
|
Fantastic!!! ^_^ I started to look at your code yesterday. I take another look this weekend and see about merging the two branches. I will probably add a commandline option for specifying the graphics file name, if that's alright. Something like --graphicsout would be consistent with the other output options. Thanks for this new code! The images look amazing. :-) Anthony On Oct 16, 2020 6:28 AM, Bernard Bel <ber...@gm...> wrote: > Dear all, > > I have completed graphic routines on the console and checked them in > "objects" and "pianoroll" display modes for simple notes and > time-patterns. The display of sound-objects will be checked/fixed once > the console is able to load sound-object prototypes. This will also make > it possible to create several images in the same command. > > At this point I am tempted to stop working on branch "graphics-for-BP3" > and suggest to merge it with "BP3-develop". The reason is that we might > otherwise need to deal with conflicts because of changes in the > Makesound() procedure that have implications on real-time MIDI. > > Graphic display requires the PHP interface to create a window and > interpret CANVAS code. The latest version of the interface adjusts > window sizes to image sizes. > > It is possible to create graphic with a command line such as: > > ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d > --csoundout ../my_output/out.sco --traceout > ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e.txt --seed 15524 > > Note that this command is asking for a trace and providing the path and > name of the trace file. (The name contains the session ID.) > > Sending a command without trace: > > ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d > --csoundout ../my_output/out.sco --seed 15524 > > will end up with "Segmentation fault: 11". > > The reason is that the console needs a location for the image file, so > it uses the path of the trace to locate the image, ending up with: > > ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e_image_1.html > > To use graphic routines without a trace we will need a new option > specifying a path and the beginning of name(s) for the image file(s). > Names will automatically end with "image_1", "image_2" etc. Anyway, if a > full name is provided the machine could append it with "_1", "_2" etc. > > Currently, the console picks up in the settings file the type of image: > "objects" or "pianoroll". In case no settings file is available, this > option could also be provided in the command line. This is less critical > because the default type of an image is set to "pianoroll" if the item > contains only simple notes and "objects" in case sound-objects have been > found. Still, the two options are possible and interesting if the item > contains simple notes and time-patterns, see for instance the attached > images. So it would be fair to have a command option forcing the image > type. I will also check the display of sound-objects in pianoroll based > on notes contained in these objects. > > I checked all these procedures with several web browsers on Mac and I > hope they will work identically in a Windows environment… ;-) > > Bernard > > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Bernard B. <ber...@gm...> - 2020-10-16 10:29:01
|
Dear all, I have completed graphic routines on the console and checked them in "objects" and "pianoroll" display modes for simple notes and time-patterns. The display of sound-objects will be checked/fixed once the console is able to load sound-object prototypes. This will also make it possible to create several images in the same command. At this point I am tempted to stop working on branch "graphics-for-BP3" and suggest to merge it with "BP3-develop". The reason is that we might otherwise need to deal with conflicts because of changes in the Makesound() procedure that have implications on real-time MIDI. Graphic display requires the PHP interface to create a window and interpret CANVAS code. The latest version of the interface adjusts window sizes to image sizes. It is possible to create graphic with a command line such as: ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d --csoundout ../my_output/out.sco --traceout ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e.txt --seed 15524 Note that this command is asking for a trace and providing the path and name of the trace file. (The name contains the session ID.) Sending a command without trace: ../bp produce -gr ../ctests/-gr.NotReich -se ../ctests/-se.NotReich -d --csoundout ../my_output/out.sco --seed 15524 will end up with "Segmentation fault: 11". The reason is that the console needs a location for the image file, so it uses the path of the trace to locate the image, ending up with: ../temp_bolprocessor/trace_7556e342225455a131e76b9dc226390e_image_1.html To use graphic routines without a trace we will need a new option specifying a path and the beginning of name(s) for the image file(s). Names will automatically end with "image_1", "image_2" etc. Anyway, if a full name is provided the machine could append it with "_1", "_2" etc. Currently, the console picks up in the settings file the type of image: "objects" or "pianoroll". In case no settings file is available, this option could also be provided in the command line. This is less critical because the default type of an image is set to "pianoroll" if the item contains only simple notes and "objects" in case sound-objects have been found. Still, the two options are possible and interesting if the item contains simple notes and time-patterns, see for instance the attached images. So it would be fair to have a command option forcing the image type. I will also check the display of sound-objects in pianoroll based on notes contained in these objects. I checked all these procedures with several web browsers on Mac and I hope they will work identically in a Windows environment… ;-) Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-10-15 16:16:09
|
Dear all, I worked several days and nights to revise code for Csound and MIDIfile output of items displayed as "objects" or "pianoroll" in both striated and smooth time, including time-patterns… The result has been pushed to the "graphics-for-BP3" branch. The grammar I have used for checking all this is "-gr.tryTimePatterns" which I am enclosing along with its settings. I will update the "ctests" folder and push it to GitHub. I will also push small changes in the PHP interface. Understanding smooth versus striated time is easy if you look at both included images. Striated time produces metronomic tempo, ignoring all time-patterns, whereas smooth time allows time-patterns to structure duration ratios. This idea and these terms are borrowed from Pierre Boulez but they cover many musical styles, including the "alap" in the beginning of North-Indian raga exposure. Very strangely, this grammar did produce a perfect graphic output with BP2.9.8 but I had to reprogram the entire process on BP3! This was a very enjoyable headache, understanding again the algorithm behind the scene… I must work on a documentation of all these algorithms. I even starting believing that Anthony used an old version of BP2 when creating the BP3 console! To make sure, I did a DiffMerge of the main files. No way, they are identical as far as data processing is concerned. If I can't sleep another night I will try to figure out the reason of this change… Fixing MIDI file output for items displayed in pianoroll (via the MakeSound() procedure) paved the way for real-time MIDI because it constructs MIDI events with the same data. Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-10-12 13:51:12
|
Dear all,
Graphic output is now working in both modes: "pianoroll" for simple
notes and "sound-objects" for mixed data. The difference is shown on the
attached pictures representing the same item
{_legato(20) C4 D4 E4,_staccato(10) F#5 G3}
produced by grammar -gr.tryGraphics (attached with its settings file).
(Legato is not applied to E4 because it is the last note in the
sequence. This is a feature!)
The display reproduces exactly that of BP2. At present, "sound-objects"
mode is only able to display simple notes because sound-object prototype
files are not yet recognized. But I have tried more details, tricking
the code to display extra features: pivots etc.
There are still problems with smooth time, and I also plan to check that
we can produce a set of pictures when producing substitutions (the SUB
grammars). This takes time. Programming the graphic output is easier
than verifying flags in the whole process and adjusting its flow to the
console environment. I see that Anthony has achieved many corrections to
make it accept various options.
The current version displays plenty of debugging messages which are
still needed to verify all cases. I committed the C code to the
"graphics-for-BP3" branch.
Anthony, I will try to work on the loading of sound-object prototype
files if you wish so. I feel more confident with the code. ;-)
Bernard
|
|
From: Bernard B. <ber...@gm...> - 2020-10-11 10:18:08
|
Dear Anthony, This has become clear again! I am using a multipurpose code editor for both PHP and C development, connecting multiple files with search even in regular expressionss (my current fancy). I always had a hard time working on different editors because of colors and automatic syntax checking. This is a reason (on top of laziness) for not having installed Xcode.;-) My editor was set up for using UTF-8 whenever possible. "Possible" means when no code is problematic. For instance if I open "MIDIstubs.c" (and most files) in the version you uploaded in August, it is displayed as UTF-8… but it is also saved as UTF-8 if I modify it. Files with "problematic code" (such as "-BP2.h") are announced as "ISO Latin" because the editor does not see the difference with MacOS and they are saved again in the same original format (except perhaps CRLFs instead of CRs). For this reason I was able to compile and link files even though I had made some changes in non-UTF8 files. I have just checked "-BP2.h" which I had tried to render UTF-8. The only change is a "…" character in a comment of line 456. I was worried having saved again a couple of files (such as "Zouleb.c") without changing their contents, just for the sake of making them UTF-8. But my comparison program DiffMerge tells that contents are identical despite the different encoding. And I guess GitHub reacts in the same way because it did not include "Zouleb.c" in its push. For "SaveLoads3.c" I returned to the August version. I had only opened it for finding a variable in loading the LoadSettings(). So, I hope there have been no disasters due to file encodings! Since I modified "MakeSound.c" for creating pianorolls it may interfere with your own changes for real-time MIDI. Logically changes can be merged. Are we going to see any conflict? At what point should we transfer changes from one branch to the one it came from? At present I will only need to work on "Graphic.c" and "-BP2proto.h". I could also store new prototypes on top of "Graphic.c". This means no risk of conflictual edits. ;-) Bernard Anthony Kozar wrote on 10/10/2020 08:42: > Dear Bernard, > > All source code files should be opened and saved with the Mac OS Roman > encoding. If you use my Xcode project to work on the code, it should be > configured to treat the source files that way. Some files may not > contain any non-ASCII characters, but it will be safest to treat them as > Mac OS Roman for now. > > The files cannot all be converted to UTF-8 yet for exactly the reason > you discovered: non-ASCII characters in UTF-8 cannot be stored in a > single char and make illegal character constants. > > Converting -BP2.h worked because the non-ASCII characters are in > comments only. But I think it will be confusing if we convert some > files and not others. I'd like to convert them all at once after I've > been able to revise the code to handle UTF-8 input files. > > Thanks, > > Anthony > > > On 10/10/20, 1:10 AM, Bernard Bel wrote: >> Dear Anthony, >> >> You probably discussed this earlier… >> >> Some source files such as -BP2main.h, SaveLoads3.c, CompileGrammar.c, >> CompileProcs.c, Compute.c, Dialogs.c, DisplayArg.c, DisplayThings.c, >> Encode.c, FillPhaseDiagram.c, Glossary.c, Inits.c, Interface1.c, >> Interface2.c, MenuCommands.c, MIDIstuff.c, Misc.c, OMS.c, Polymetric.c, >> Print.c, Processes.c, SaveLoads1.c, Schedule.c, ScriptUtils.c, >> SetObjectFeatures.c, StringLists.h, Strings.c, TimeSet.c (and maybe >> more) are not encoded UTF-8. >> >> Among these, Dialogs.c, Interface1.c, MenuCommands.c, OMS.c, Print.c, >> Processes.c, Schedule.c, ScriptUtils.c are not part of the binding. >> >> My editor displays (and saves) these files as ISO Latin 1. >> >> Trying to recode some of them to UTF-8 yields compilation errors such as: >> >> source/BP2/SaveLoads3.c:1115:15: error: character too large for >> enclosing character literal type >> if(((oldc != 'Â' || !bindlines) && (c == '\n' || c == '\r')) || >> c == '\0' >> ^ >> source/BP2/SaveLoads3.c:1135:21: error: character too large for >> enclosing character literal type >> if(strip && ((c == 'Â' && !bindlines) || c == '\r')) is++; >> >> I guess it has an incidence on reading files because this unwanted >> character appears in ReadOne(). >> >> Nonetheless I recoded -BP2.h and it did compile/link. I leave the >> question open of trying to recode all useful files, but this question >> may already have been answered. >> >> Bernard > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Bernard B. <ber...@gm...> - 2020-10-11 09:40:11
|
Dear all,
Graphic output is now working in BP3 for pianoroll. See an attached
picture of the rendering of -gr.notReich.
I implemented generic functions in "Graphic.c" so that it would be easy
to implement a different process. CANVAS creates a javascript in a HTML
page. The resulting image is automatically displayed when opening the
image file, provided that the browser supports HTML5.
Using javascript has the advantage that the drawing is done on the
client's browser, thereby saving processor time on the server. In
addition, the production is a relatively small text file (see attached
"pianoroll.html", 216K) instead of a heavy high-resolution picture. For
instance, GD graphics would produce a raster PNG or JPEG image.
There is still a problem: the image is displayed in its real size which
is about 400% too large. You need to zoom-out, but this will also
zoom-out pages in the background. I hope to find a method for
disconnecting zooming on the pop-up window from zooming its parent… If
you know a method just send me the modified "pianoroll.html".
I cheched the graphic output on Chrome, Firefox, Safari, Opera and Brave
on a Mac. Windows tests would be welcome!
I committed changes to the console (branch "graphics-for-BP3") and the
interface ("php-frontend/master").
This solution reproduces colors and layout of BP2. Later we may think
about more advanced features, if required. For the time being I will
work on the display of sound-objects.
I had a hard time remembering correct management of strings in C… As
much as dealing with strange behaviour. For instance,
fopen("filename","r") creates a duplicate file if "filename" already
exists in the same folder! This I fixed in the PHP interface.
The graphic procedure is set up for saving several pictures if for
instance the console is instructed to create several items. It will also
be useful for displaying step-by-step changes in the time-setting
algorithm. A good point is that each image created does not delete the
former one (as it was the case in BP2). A bad point is that it results
in many files created when for instance the console is asked to do
continuous improvization!
Bernard
|
|
From: Anthony K. <mai...@an...> - 2020-10-10 06:42:36
|
Dear Bernard, All source code files should be opened and saved with the Mac OS Roman encoding. If you use my Xcode project to work on the code, it should be configured to treat the source files that way. Some files may not contain any non-ASCII characters, but it will be safest to treat them as Mac OS Roman for now. The files cannot all be converted to UTF-8 yet for exactly the reason you discovered: non-ASCII characters in UTF-8 cannot be stored in a single char and make illegal character constants. Converting -BP2.h worked because the non-ASCII characters are in comments only. But I think it will be confusing if we convert some files and not others. I'd like to convert them all at once after I've been able to revise the code to handle UTF-8 input files. Thanks, Anthony On 10/10/20, 1:10 AM, Bernard Bel wrote: > Dear Anthony, > > You probably discussed this earlier… > > Some source files such as -BP2main.h, SaveLoads3.c, CompileGrammar.c, > CompileProcs.c, Compute.c, Dialogs.c, DisplayArg.c, DisplayThings.c, > Encode.c, FillPhaseDiagram.c, Glossary.c, Inits.c, Interface1.c, > Interface2.c, MenuCommands.c, MIDIstuff.c, Misc.c, OMS.c, Polymetric.c, > Print.c, Processes.c, SaveLoads1.c, Schedule.c, ScriptUtils.c, > SetObjectFeatures.c, StringLists.h, Strings.c, TimeSet.c (and maybe > more) are not encoded UTF-8. > > Among these, Dialogs.c, Interface1.c, MenuCommands.c, OMS.c, Print.c, > Processes.c, Schedule.c, ScriptUtils.c are not part of the binding. > > My editor displays (and saves) these files as ISO Latin 1. > > Trying to recode some of them to UTF-8 yields compilation errors such as: > > source/BP2/SaveLoads3.c:1115:15: error: character too large for > enclosing character literal type > if(((oldc != 'Â' || !bindlines) && (c == '\n' || c == '\r')) || > c == '\0' > ^ > source/BP2/SaveLoads3.c:1135:21: error: character too large for > enclosing character literal type > if(strip && ((c == 'Â' && !bindlines) || c == '\r')) is++; > > I guess it has an incidence on reading files because this unwanted > character appears in ReadOne(). > > Nonetheless I recoded -BP2.h and it did compile/link. I leave the > question open of trying to recode all useful files, but this question > may already have been answered. > > Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-10-10 05:11:14
|
Dear Anthony,
You probably discussed this earlier…
Some source files such as -BP2main.h, SaveLoads3.c, CompileGrammar.c,
CompileProcs.c, Compute.c, Dialogs.c, DisplayArg.c, DisplayThings.c,
Encode.c, FillPhaseDiagram.c, Glossary.c, Inits.c, Interface1.c,
Interface2.c, MenuCommands.c, MIDIstuff.c, Misc.c, OMS.c, Polymetric.c,
Print.c, Processes.c, SaveLoads1.c, Schedule.c, ScriptUtils.c,
SetObjectFeatures.c, StringLists.h, Strings.c, TimeSet.c (and maybe
more) are not encoded UTF-8.
Among these, Dialogs.c, Interface1.c, MenuCommands.c, OMS.c, Print.c,
Processes.c, Schedule.c, ScriptUtils.c are not part of the binding.
My editor displays (and saves) these files as ISO Latin 1.
Trying to recode some of them to UTF-8 yields compilation errors such as:
source/BP2/SaveLoads3.c:1115:15: error: character too large for
enclosing character literal type
if(((oldc != 'Â' || !bindlines) && (c == '\n' || c == '\r')) ||
c == '\0'
^
source/BP2/SaveLoads3.c:1135:21: error: character too large for
enclosing character literal type
if(strip && ((c == 'Â' && !bindlines) || c == '\r')) is++;
I guess it has an incidence on reading files because this unwanted
character appears in ReadOne().
Nonetheless I recoded -BP2.h and it did compile/link. I leave the
question open of trying to recode all useful files, but this question
may already have been answered.
Bernard
|
|
From: Rainer S. <rs...@ba...> - 2020-10-09 11:37:58
|
> On 9. Oct 2020, at 13:20, Anthony Kozar <mai...@an...> wrote: > > For -gr.Mozart: Adding the --french option or loading -se.Mozart should make the errors go away. Ah, it does! But wouldn't --austrian have made more sense? ;-) just kidding ;-) Best .r. |
|
From: Anthony K. <mai...@an...> - 2020-10-09 11:20:25
|
Great! THANKS SO MUCH, Rainer!! You're an awesome asset to this
project. ^_^
For -gr.Mozart: Adding the --french option or loading -se.Mozart should
make the errors go away.
Anthony
On 10/9/20, 7:02 AM, Rainer Schuetz wrote:
> With pleasure ;-)
>
> -gr.Mozart returns 158 errors, but that's the same on MacOS, they're all
> the same, like:
>
> Variable must start with uppercase character or '|'. Can't make sense of
> "fa3"
> May be unknown terminal symbol, time-pattern or incorrect note convention?
> *** Error code 15: argument syntax in gram#18 rule 1
> ??? gram#18[1] T1 --> {fa3 re3 sol3,fa5 re5 sol5}
> So it looks like it's solved. Very cool!
> Thank you very much!
> .r.
|
|
From: Rainer S. <rs...@ba...> - 2020-10-09 11:19:28
|
> On 9. Oct 2020, at 13:13, Anthony Kozar <mai...@an...> wrote: > > (IIRC, Xcode 7.3 is best for 10.11, but I installed Xcode 8.2 before I knew that and stuck with it). Older Xcode versions can still be downloaded if you get an (free) Apple Developer account. If you don't find them, I have the Xcode 7.3.1 .dmg, I could upload for you... (I kept them for my virtual machines, as it looked for a while that Apple was "disappearing" older versions of their stuff - unfortunately I didn't think of homebrew). Best .r. |
|
From: Anthony K. <mai...@an...> - 2020-10-09 11:13:59
|
Good. All of those warnings can really be distracting on the commandline. I've thought about disabling them in the Makefile too but I haven't spent the time to figure out how. (I know -Wall turns all warnings on...) Someday, I plan to work on eliminating the 1000+ warnings but I'd like to find a way to automate some of that work. I use Xcode for most of my work on BP3. It is MUCH easier to navigate and search the code that way. You might also like to use the Git support that is built-in to Xcode. I sent you some instructions for setting up Xcode with BP a long time ago (summer 2019?). I could find them and send them again if you wish. (IIRC, Xcode 7.3 is best for 10.11, but I installed Xcode 8.2 before I knew that and stuck with it). Anthony P.S. You will still see lots of Pascal strings and other Mac Classic / Carbon types in the code. I created a compatibility layer (in MissingMacTypes.h and elsewhere) to make the porting easier. On 10/9/20, 6:50 AM, Bernard Bel wrote: > Problem solved: I still get the warnings but no error in compilation and > linking. So I can move on creating graphics ;-) > > Bernard > > -------- > > Dear Anthony, > > I started working on branch "graphics-for-BP3" and did a commit of my > recent modifications. > > I edited Graphic.c so that DrawItem() would simply return(OK). > Then reactivated the call of DrawItem() in PlayThings.c > Then updated the Makefile to include Graphic.c > > I am getting compilation errors in Graphic.c, as expected because of > obsolete code. However, it gets worse when I try to modify a definition > in -BP2.proto.h. Even if I only add a space in -BP2.proto.h and save it > again, plenty of warning errors show up, starting with: > > macbookpro-bernard:bolprocessor bernardbel$ make > gcc -c -I source/BP2 -include source/prefix/PrefixANSIDebug.h > source/BP2/Arithmetic.c -o source/BP2/Arithmetic.o > source/BP2/Arithmetic.c:43:1: warning: type specifier missing, defaults > to 'int' [-Wimplicit-int] > Equal(double accuracy,double p,double q,double r,double s,int* p_overflow) > ^ > source/BP2/Arithmetic.c:70:1: warning: type specifier missing, defaults > to 'int' [-Wimplicit-int] > Add(double p,double q,double r,double s, > ^ > source/BP2/Arithmetic.c:108:1: warning: type specifier missing, defaults > to 'int' [-Wimplicit-int] > Substract(double p,double q,double r,double s,double *p_P,double *p_Q, > > etc. > > In fact all files get compilation warnings even though -BP2.proto.h > hasn't changed… Probably I should use an option hiding all warnings. I > understand the warnings: I never declared the type of a function when it > is "int". > > The version I am working on has been committed to "graphics-for-BP3". > > I also have difficulty with Pascal strings, for instance c2pstrcpy() is > no longer recognized, but I guess no Pascal string might be used in the > final code even though I noticed many "Str255" in -BP2.proto.h… > > Bernard > (Learning again C!) |
|
From: Rainer S. <rs...@ba...> - 2020-10-09 11:02:26
|
> A new debug version of ConsoleMain.c is attached. Would you mind trying this version too, Rainer?
With pleasure ;-)
This is -gr.NotReich with line breaks returned to CRLF:
Bol Processor console app
Version 2.999... (Oct 9 2020)
This is a beta version for evaluation...
Reading grammar file -gr.NotReich...
Length of file: 749
BP2 Console completed initialization.
Random seed = 14017
Compiling alphabet...
Looking for time patterns...
Compiling subgrammar #1...
Compiling subgrammar #2...
Errors: 0
Producing item(s)...
Computing item...
Subgrammar 1/2
Subgrammar 2/2
Buffer limit expanded to 1500
Buffer limit expanded to 2250
Buffer limit expanded to 3375
Buffer limit expanded to 5062
_chan(1) _vel(50) _volumecont _volume(80){1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5},_vel(60) C2}{{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5},_vel(60) C2}{{{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5},_vel(60)
...
-,_vel(40) - F3 G3,A#5,- D5} _volume(80){1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5}{1,C4 -,_vel(40) - F3 G3,A#5,- D5} _volume(0)
New project memory use: 60913 [leaked: 0]
This session used 90 Kbytes maximum. 335 handles created and released. [0 bytes leaked]
-----
-gr.Mozart returns 158 errors, but that's the same on MacOS, they're all the same, like:
Variable must start with uppercase character or '|'. Can't make sense of "fa3"
May be unknown terminal symbol, time-pattern or incorrect note convention?
*** Error code 15: argument syntax in gram#18 rule 1
??? gram#18[1] T1 --> {fa3 re3 sol3,fa5 re5 sol5}
------
-gr.Drum returns
Bol Processor console app
Version 2.999... (Oct 9 2020)
This is a beta version for evaluation...
Reading grammar file -gr.drum...
Length of file: 272
BP2 Console completed initialization.
Random seed = 14876
Compiling alphabet...
Looking for time patterns...
Compiling subgrammar #1...
Errors: 0
Producing item(s)...
Computing item...
{_chan(1) _vel(120) _staccato(96) C8 - - -,_chan(1) _vel(120) _staccato(96) - C7 C7 C7,_chan(1) _vel(120) _staccato(92) E7 E7 E7 E7 E7 E7 E7 E7}
New project memory use: 60436 [leaked: 0]
This session used 70 Kbytes maximum. 118 handles created and released. [0 bytes leaked]
So it looks like it's solved. Very cool!
Thank you very much!
.r.
|
|
From: Anthony K. <mai...@an...> - 2020-10-09 10:59:11
|
Dear Bernard, Outputting an HTML file with embedded JavaScript sounds perfect! I'm glad that you tried the HTML5 canvas element. Many GUI frameworks these days have built-in support for displaying HTML pages. If they also support JavaScript and the canvas element then other interfaces to BP3 should be able to display the same graphics. And for users working with just a text editor and a terminal, they just have to open the output file in a web browser. So, a near universal solution! :) (And I've done a little canvas programming myself...) Best regards, Anthony On 10/8/20, 9:02 AM, Bernard Bel wrote: > Dear Anthony, > > No need to link BP3 to any library… The idea is to export a text file > containing instructions for drawing the picture. Sorry for your > sleepless night! ;-) > > I had a quick look at OpenGL (deprecated on iOS), Vulkan, WebGL, FPIC, > Direct3D… and finally decided to check CANVAS because its code is > directly readable by (all?) browsers on (all?) systems: > > https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Drawing_graphics > > Great! All we need to produce is a text file in the style of the > attached test-image.html. The image is described in javascript. After > all, it's similar to your PPMDRAW. I like the simple syntax because, if > necessary, it could easily be translated to other dialects such as GD. > Indeed, we are drawing 2D, no animation, but there is also a scope for > 3D which might get interesting in the future. :-) > > PHP could even take care of creating the header and perhaps calculate > the window size adapted to the image size. > > I have put an IMAGE link on the Grammar window that displays the image > on a pop-up window (see attached screen image). > > I pushed the version of the interface because it is vital to make sure > that this device is compatible with different browsers and systems… > before I invest in writing the code. > > I agree that it would be nice to be able to display the picture directly > from the console, with I guess conditional compilations to use the > proper libraries. However, the easiest way might be to include code > converting CANVAS to PDF, PostScript or whatever is possible. Here we go: > > https://konvajs.org/docs/sandbox/Canvas_to_PDF.html > https://stackoverflow.com/questions/8571294/method-to-convert-html5-canvas-to-svg > > Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-10-09 10:51:11
|
Problem solved: I still get the warnings but no error in compilation and linking. So I can move on creating graphics ;-) Bernard -------- Dear Anthony, I started working on branch "graphics-for-BP3" and did a commit of my recent modifications. I edited Graphic.c so that DrawItem() would simply return(OK). Then reactivated the call of DrawItem() in PlayThings.c Then updated the Makefile to include Graphic.c I am getting compilation errors in Graphic.c, as expected because of obsolete code. However, it gets worse when I try to modify a definition in -BP2.proto.h. Even if I only add a space in -BP2.proto.h and save it again, plenty of warning errors show up, starting with: macbookpro-bernard:bolprocessor bernardbel$ make gcc -c -I source/BP2 -include source/prefix/PrefixANSIDebug.h source/BP2/Arithmetic.c -o source/BP2/Arithmetic.o source/BP2/Arithmetic.c:43:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] Equal(double accuracy,double p,double q,double r,double s,int* p_overflow) ^ source/BP2/Arithmetic.c:70:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] Add(double p,double q,double r,double s, ^ source/BP2/Arithmetic.c:108:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] Substract(double p,double q,double r,double s,double *p_P,double *p_Q, etc. In fact all files get compilation warnings even though -BP2.proto.h hasn't changed… Probably I should use an option hiding all warnings. I understand the warnings: I never declared the type of a function when it is "int". The version I am working on has been committed to "graphics-for-BP3". I also have difficulty with Pascal strings, for instance c2pstrcpy() is no longer recognized, but I guess no Pascal string might be used in the final code even though I noticed many "Str255" in -BP2.proto.h… Bernard (Learning again C!) |
|
From: Anthony K. <mai...@an...> - 2020-10-09 10:40:08
|
Thanks very much, Rainer! :)
I think this does clear up what is happening. The buffer that BP3 reads
from these files contains linefeeds ("a") but no carriage returns ("d").
But clearly, you found that the files contain both. So, fread() must
convert CRLF to LF on Windows when the file is opened in text mode,
which is different than my book on C describes.
I had assumed (incorrectly) that fread() would always return the same
number of bytes read as requested unless an error or early end of file
occurred. (My assumption appears correct on Unix-like systems...)
Opening the file in binary mode should suppress the automatic conversion
and then fread() *should* work the way that I expect. To be extra safe,
I will also call the ferror() and feof() functions to determine whether
BP3 should give up on reading the file.
A new debug version of ConsoleMain.c is attached. Would you mind trying
this version too, Rainer?
I'm glad that you thought of line breaks because that might not have
been my first thought otherwise. BP3 definitely needs to be able to
read files with any type of line endings on all platforms, so I want to
know if it can't! ;) BP3 *should* already be tolerant of CRLFs in input
data. The problem here was that my error checking code was faulty.
And actually, I don't think all of the CRLFs were added by Git. On my
Mac, a number of the files in bp3-ctests that were saved with the PHP
interface appear "double-spaced" in TextWrangler. I discovered thru
this exercise that the reason is that those files contain mixed line
endings. The first two lines in the affected files end with just LF but
later lines end with CRLF. I'll try to commit corrections for this issue.
Thanks for the help discovering and fixing this bug!
Anthony
On 10/9/20, 3:24 AM, Rainer Schuetz wrote:
> I am using the grammars in the ctests-folder as on Github, so I guess
> it's enough to give you the name? (*while* writing this I realize
> that *git* in some configurations does line-break conversion (and
> I've only been using ctests from git since I did these tests)! I'll
> check that later. But generally speaking, on Windows you couldn't
> make assumptions as to what kind of line-breks a source file
> contains...)
> Duh, SORRY, writing while doing: it's solved! I opened -gr.NotReich
> in the editor, saw it contained CRLF-linebreaks (created by git!). I
> saved the file with LF-linebreaks, and reran bp on it, and it works:
> I swear I was just guessing when speculating about the line-break problem!
>
> What git does in default configurations on Windows: on pull it
> converts all line-endings to CRLF and on push it reconverts them to LF.
> That helps to avoid problems with old-style text editors on Windows.
> Modern editors handle the CRLF/LF-problem on "intelligently". There are
> two ways to go ahead from here: I could configure git not to do that
> conversion in the ctests repo - or you could adjust bp (I hope it's not
> too difficult). I think the later is preferable, as such an
> auto-conversion could happen in many situation without the user even
> realizing it (some editors do it by default on Windows). But let me know
> what you chose for now, and I'll adjust.
>
> Thanks for your help!
>
> Best
> .r.
|
