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-09-23 08:08:48
|
Dear all, I completed the PHP interface for editing Timebases and updated the documentation accordingly: https://bolprocessor.org/misc/BP3/CheckList.html The superposition of tick cycles with MIDI files produced by Bol Processor works fine on the interface. Therefore, implementing it in the ‘BP3’ version — as done in BP2 under OMS — might not be necessary. This implementation would require complicated programming. So, it could be left on the shelf… While writing the documentation, I fixed a few problems in the MIDI file import. Therefore it would be wise to commit this new version with the comment "Fixing MIDI file import". Bernard Bel |
|
From: Rainer S. <rs...@ba...> - 2020-09-21 17:30:14
|
> On 21. Sep 2020, at 15:36, Bernard Bel <ber...@gm...> wrote: > > PS. Rainer, you can post to GIThub the new version of https://bolprocessor.org/misc/BP3/bolprocessor_php.zip <https://bolprocessor.org/misc/BP3/bolprocessor_php.zip> > with the comment "Editing Csound instruments". Thank you in advance! Done! Thanks! .r. |
|
From: Bernard B. <ber...@gm...> - 2020-09-21 13:36:18
|
Dear all, I completed the PHP interface for editing Csound instrument files and updated the documentation accordingly: https://bolprocessor.org/misc/BP3/CheckList.html No emergency to implement the loading of "-cs" files! I will still take time studying more documentation and documenting the Timebase editing. Dealing with Csound instruments forced me to study the old documentation and remember main features : chapter 17 of https://bolprocessor.org/reference-manual-bp2-9-8/ Notably, I understand that "tables" stored in the "-cs" Csound instrument file are not used for creating Csound scores. Their content is ignored by BP and inserted at the top of each score. Therefore they could be kept in memory as a string to be inserted where necessary. I also remembered that BP does nothing with the Csound orchestra file. Its name is saved in the "-cs" Csound instrument file as a reminder that this is the orchestra matching the output. I have a problem here. "-da.tryCsoundObjects" uses "BP2test.orc" provided in the package, whose arguments are used as by default when producing Csound scores in the absence of Csound instruments. However, "-gr.tryCsound" calls "-cs.tryCsound" declaring "tryCsound.orc" as the correct orchestra file. But I haven't found a trace of "tryCsound.orc"… It's an instrument with 13 arguments because many parameters are controlled. It is quite possible that I never designed it, being illiterate in Csound! ;-) I remember checking the proper combination of Csound structures by looking at the result on Csound scores. I've spent several months on these algorithms because of the difficuulty of matching Csound features with BP time model. So, I hope that Csound wizzards will program comprehensive items and instruments up to the stage of sound production… Bernard PS. Rainer, you can post to GIThub the new version of https://bolprocessor.org/misc/BP3/bolprocessor_php.zip with the comment "Editing Csound instruments". Thank you in advance! |
|
From: Bernard B. <ber...@gm...> - 2020-09-19 16:11:00
|
Hello, I moved all files previously accessible in https://leti.lt/bolprocessor/ to a new location: https://bolprocessor.org/misc/BP3/ ... or http://bp3.tech/misc/BP3/ :-) The old location contains a "ReadMe.html" file telling about the move. This is part of the process of hosting interface files and documentation on bolprocessor.org. Usage of this interface (and links for downloading the current version) are published on: https://bolprocessor.org/misc/BP3/CheckList.html This is indeed much more accurate than the previous version (a "checklist"). It includes explanations about the programming of the interface. I will need these once I have forgotten most points! I would like to make this accessible to any designer or potential user of BP3. Even though the package is incomplete, exploring its content might trigger relevant questions and suggestions. It might also help to increase the team of programmers. There is already a link to this document on the website — look for 'BP3' in the menu. I you agree with this idea I will put the same link on this page: https://bolprocessor.org/towards-a-multiplatform-bol-processor/ I will also post a message to the Users forum. By the way, I have been reading old documentation in greater detail, which reminded me of a particular problem for interpolating values: https://bolprocessor.org/csound-argument-mapping/ Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-09-19 15:20:45
|
Right, this is approximately the price OVH is charging. They made it clear from the start. This makes it possible to "block" a domain at a fair price during one year, and decide afterwards whether it's worth keeping it… ;-) Bernard Rainer Schuetz wrote on 19/09/2020 16:02: > > >> On 19. Sep 2020, at 15:21, Bernard Bel <ber...@gm... >> <mailto:ber...@gm...>> wrote: >> >> They charged less than 3 euros :-) > > Per year, right? That’s very good - but hopefully not just for the > first year! Sometimes they lure you into a tl-domain with a cheap > price for the first year, and once you’re bound to the name, the price > rises and rises… > > I use Porkbun (“an oddly satisfying experience” ;-) ) for two or three > domains, and they are fair enough to post renewal-fee right away. For > example .design comes at 4.60 $ first year, and extends at 34.94... > > Best > .r. > > > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Rainer S. <rs...@ba...> - 2020-09-19 14:03:20
|
> On 19. Sep 2020, at 15:21, Bernard Bel <ber...@gm...> wrote: > > They charged less than 3 euros :-) Per year, right? That’s very good - but hopefully not just for the first year! Sometimes they lure you into a tl-domain with a cheap price for the first year, and once you’re bound to the name, the price rises and rises… I use Porkbun (“an oddly satisfying experience” ;-) ) for two or three domains, and they are fair enough to post renewal-fee right away. For example .design comes at 4.60 $ first year, and extends at 34.94... Best .r. |
|
From: Bernard B. <ber...@gm...> - 2020-09-19 13:22:01
|
Dear Rainer, True, the issue is a name-space. Apparently these chaps only booked "bp3.com". Whois.net indicates that bp3.org is registered by "Moniker" (http://www.moniker.com) although it is not used. My OVH hostting service advised a few "bp3" variants and I picked up the most technical one: "bp3.tech" They charged less than 3 euros :-) Once it is activated I will bind it to "bolprocessor.org" After all, we only needed a "bp3" url to justify the acronym of the forthcoming version. ;-) So, welcome to "bp3" baby still gestating ;-) Bernard Rainer Schuetz wrote on 19/09/2020 11:27: > >> On 18. Sep 2020, at 16:55, Bernard Bel <ber...@gm...> wrote: >> >> Logically we would expect the forthcoming version of Bol Processor to be called "BP3". However this might create a confusion and possible trouble with these people: >> >> https://www.bp-3.com/ > A namespace is needed! Or skip to 4 right away (one star for cli and one for cross platform) - than let those name-ursurpers deal with it in the future ;-) > > I am also fine, but on a quest to fill me in on programming fundamentals, that draws me into all kind of unexpected directions with deeper than hoped for involvement ;-) > > Best > .r. |
|
From: Rainer S. <rs...@ba...> - 2020-09-19 09:27:54
|
> On 18. Sep 2020, at 16:55, Bernard Bel <ber...@gm...> wrote: > > Logically we would expect the forthcoming version of Bol Processor to be called "BP3". However this might create a confusion and possible trouble with these people: > > https://www.bp-3.com/ A namespace is needed! Or skip to 4 right away (one star for cli and one for cross platform) - than let those name-ursurpers deal with it in the future ;-) I am also fine, but on a quest to fill me in on programming fundamentals, that draws me into all kind of unexpected directions with deeper than hoped for involvement ;-) Best .r. |
|
From: Bernard B. <ber...@gm...> - 2020-09-18 14:55:48
|
Logically we would expect the forthcoming version of Bol Processor to be called "BP3". However this might create a confusion and possible trouble with these people: https://www.bp-3.com/ It's hard to know whether they are doing anything else than running a website… No legal information about their… company? Any idea for a new name maintaining the continuity of the project? Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-09-18 14:17:16
|
Dear Anthony, I admit having felt some anxiety, yet not about delaying the "delivery" of BP3. Periods of silence are opportunities to update documentation and rethink aspects of a project which has never been bound to deadlines. I am only more sensitive than usual to the well-being of friends in remote places. We live in an isolated village but it also has its own dramatic news: recently a cluster of infection took our aged mayor and his wife to the intensive care unit… So, let me wish rabbit holes will never get too rough in your life! ;-) It is true that I came close to the old interface for implementing Csound interaction. I am enclosing two "cs" files saved by the PHP interface. These are identical to the ones used by BP2, except line endings. So, you may use them to verify their loading in the console. LoadCsoundInstruments() (in SaveLoads1.c) should be easy to adapt, removing all interface calls. The only trouble might be the loading of "tables" copied to a window called "wCsoundTables" (image attached). The documentation (https://bolprocessor.org/misc/docs/) reminded me that these tables are needed to produce wave-forms, ramps, etc. By default, BP2 uses a simple table producing a sinewave signal (with GEN10): f1 0 256 10 1 So, to start with, you could take it as fixed data. Anyway, I realize having forgotten the little I knew about Csound. Fortunatley, the old documentation is explanatory. I had anticipated I would need a refresher's course! :-) I am moving to the new site much of the material earlier stored on SourceForge. It takes time deleting or updating links etc., but many "spare parts" of this documentation could be recycled for the new version we envisage to build. I also try to illustrate examples in greater detail and upload MP3 renderings. I have no idea of a format that would be most suitable to this effect. Currently I am creating Wordpress posts/pages and sometimes even pasting the old HTML to these pages. I'll send you details of ftp access whenever you need to upload or edit some of the content. Keep well and don't worry about time passing! :-) Bernard Anthony Kozar wrote on 18/09/2020 14:20: > Wow, this sounds great! And it looks so much like the BP2 interface :) > > I'm sorry that I have been so quiet for the last 3 weeks or so. I > have been "chasing too many rabbits" and frequently falling down their > rabbit holes. I haven't made any progress on BP3 during this time > either. > > I will hopefully be able to respond to all of the recent posts soon. > > Anthony > > On 9/17/20, 11:20 AM, Bernard Bel wrote: >> Dear all, >> >> I have completed the editor of Csound instruments on the PHP interface. >> The new code has been uploaded as usual. >> >> It would be great to allow the console to read “-cs” files so that the >> complete interaction becomes possible — following the previous BP2 >> standard. >> >> The attached image shows the editing of an instrument named >> "Harpsichord". The basis setting is a mapping of MIDI controls "volume", >> "pitchbend" etc. to Csound parameters that used by the Orchestra. There >> is a simple default orchestra file called "BP2test.orc" in the BP2 >> package. Any orchestra file can indeed be used provided that arguments >> match its algorithm. >> >> At the bottom of the page is the list of additional "parameters" for >> this instrument. These are not mapped to MIDI controllers. It is >> possible to create an unlimited number of parameters, unlike BP2 that >> would only accept 6 of them because of interface limitations. Now, each >> parameter is edited on a separate tag. I am showing for instance >> "blurb". >> >> I will work on updating the documentation on this Csound interface. This >> will facilitate future discussions for improving the model on BP3… >> >> I contacted the admin of the Csound project on GitHub to insert a >> mention of Bol Processor as a "related project": >> https://csound.com/projects.html >> >> The person in charge (Joachim Heinz) replied favorably for a brief >> presentation, but I was unsuccessful sending him attached files because >> these were rejected by the forum. Trying again! >> >> I hope that you are all in good shape and that my messages still reach >> the list! ;-) >> >> Bernard > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Anthony K. <mai...@an...> - 2020-09-18 12:28:47
|
Wow, this sounds great! And it looks so much like the BP2 interface :) I'm sorry that I have been so quiet for the last 3 weeks or so. I have been "chasing too many rabbits" and frequently falling down their rabbit holes. I haven't made any progress on BP3 during this time either. I will hopefully be able to respond to all of the recent posts soon. Anthony On 9/17/20, 11:20 AM, Bernard Bel wrote: > Dear all, > > I have completed the editor of Csound instruments on the PHP interface. > The new code has been uploaded as usual. > > It would be great to allow the console to read “-cs” files so that the > complete interaction becomes possible — following the previous BP2 standard. > > The attached image shows the editing of an instrument named > "Harpsichord". The basis setting is a mapping of MIDI controls "volume", > "pitchbend" etc. to Csound parameters that used by the Orchestra. There > is a simple default orchestra file called "BP2test.orc" in the BP2 > package. Any orchestra file can indeed be used provided that arguments > match its algorithm. > > At the bottom of the page is the list of additional "parameters" for > this instrument. These are not mapped to MIDI controllers. It is > possible to create an unlimited number of parameters, unlike BP2 that > would only accept 6 of them because of interface limitations. Now, each > parameter is edited on a separate tag. I am showing for instance "blurb". > > I will work on updating the documentation on this Csound interface. This > will facilitate future discussions for improving the model on BP3… > > I contacted the admin of the Csound project on GitHub to insert a > mention of Bol Processor as a "related project": > https://csound.com/projects.html > > The person in charge (Joachim Heinz) replied favorably for a brief > presentation, but I was unsuccessful sending him attached files because > these were rejected by the forum. Trying again! > > I hope that you are all in good shape and that my messages still reach > the list! ;-) > > Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-09-17 15:20:29
|
Dear all, I have completed the editor of Csound instruments on the PHP interface. The new code has been uploaded as usual. It would be great to allow the console to read “-cs” files so that the complete interaction becomes possible — following the previous BP2 standard. The attached image shows the editing of an instrument named "Harpsichord". The basis setting is a mapping of MIDI controls "volume", "pitchbend" etc. to Csound parameters that used by the Orchestra. There is a simple default orchestra file called "BP2test.orc" in the BP2 package. Any orchestra file can indeed be used provided that arguments match its algorithm. At the bottom of the page is the list of additional "parameters" for this instrument. These are not mapped to MIDI controllers. It is possible to create an unlimited number of parameters, unlike BP2 that would only accept 6 of them because of interface limitations. Now, each parameter is edited on a separate tag. I am showing for instance "blurb". I will work on updating the documentation on this Csound interface. This will facilitate future discussions for improving the model on BP3… I contacted the admin of the Csound project on GitHub to insert a mention of Bol Processor as a "related project": https://csound.com/projects.html The person in charge (Joachim Heinz) replied favorably for a brief presentation, but I was unsuccessful sending him attached files because these were rejected by the forum. Trying again! I hope that you are all in good shape and that my messages still reach the list! ;-) Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-09-08 15:03:49
|
Last news: After installing a brand new keyboard, BP1 worked fine. In fact the ctrl key was presumably defective, forcing ctrl-C to quit the editor… In grammar Q2.7 I could even reconstruct the 20 templates. Bernard -------- I have completed another article showing BP1 in its real musical context. This wasn't difficult because of the availability of a "realistic" example in our 1992 publication. https://bolprocessor.org/bp1-in-real-musical-context/ Running the program was uneasy. Maybe because of a lack of memory, given the sizes of the grammar and data set. I am not certain that the emulator provided as much RAM as the physical Apple IIe… Sometimes I type ctrl-C in the first grammar rule and it quits the grammar instead of producing variations. In addition, I was not able to reconstruct templates. Maybe I have forgotten the right procedure! Anyway, the videos prove that all this is possible :-) All corrections and comments welcome ! Bernard Bel |
|
From: Bernard B. <ber...@gm...> - 2020-09-08 05:23:43
|
Dear Anthony, From the commits on 26-29 August I understand that you've been working on CoreMidi. We'll need an interface page to select input/output devices and set up MIDI input/output filters. So far these parameters have been stored in the startup file (as shown on the attached image): 52) Input device 53) Output ID and OMS output name 111) MIDI output filter 124) MIDI input filter Probably it will be easier to ignore these old parameters and create a page specific to MIDI parameters. I imagine a call of the console "GetMIDIparams" that will return the current MIDI settings and another one "SendMIDIparams" sending back the selected devices and filter values. We had an encoding for MIDI filters that would store all options as a single integer. This seems a good way for communicating with the console. Keeping the same convention does not really matter because we haven't saved examples in which special filters were required. The default MIDI filters (attached picture) were "receive everything" and "transmit nothing". If we allow transmitting NoteOn/NoteOff, for instance, we get disturbing echos when sending notes to the synthesizer… Still, transmitting certain MIDI messages might be necessary when BP is part of a larger "MIDI network" of sound devices: for instance, it receives messages from a rhythm box, some of which are used for synchronizing events, while all messages are transmitted to a drum machine. I guess this part of the implementation is hard and boring! Once it is done I will take over with the graphic output. ;-) Bernard Anthony Kozar wrote on 23/08/2020 23:05: > Midishare (from Grame) is still around. A new package for OS X El > Capitan was posted about two years ago. It is not clear to me whether > this package has any code changes compared to the previous release for > Mac OS X but the libraries in it are Universal binaries for i386 and > x86_64. While there has been activity in the Git repository as recent > as 2016, the last Windows and Linux releases appear to be from 2013 and > 2006 respectively. > > http://midishare.sourceforge.net/ > > The JACK Audio Connection Kit is cross-platform and appears to have some > support for real-time MIDI even though it is primarily a tool for > routing audio signals. The JACK project appears to be pretty active. > > https://jackaudio.org/ > > Overall, I am guessing that PortMidi will be the easiest to distribute > with BP so that BP users don't have to install anything extra. But I'm > really not that familiar with any of these libraries. > > Anthony > > > On 8/19/20, 11:20 PM, Bernard Bel wrote: >> It has a drawback: "RtMidi does not provide timing functionality (i.e., >> output messages are sent immediately)." >> >> In the tutorial (http://www.music.mcgill.ca/~gary/rtmidi/), time spacing >> between events is created by a "sleep" function which is >> platform-dependent. My objection is that it will cumulate errors. >> However, developers might have found tricks to avoid error cumulation — >> unless they estimate that it is not so important. >> >> One of the reasons for insisting on time accuracy is that several BPs >> improvizing together would need to stay perfectly synchronized (without >> sending specific MIDI messages for their synchonization). >> >> Bernard >> >> >> Rainer Schuetz wrote on 20/08/2020 00:36: >>> You might want to have a look at RtMidi for comparison: >>> >>> https://github.com/thestk/rtmidi >>> >>> There are Portaudio and Portmidi, and RtAudio and RtMidi… The later seem >>> to be a result of some lack of responsiveness of the team behind the >>> “portXYs”. I can’t make a judgement at all but I know that projects that >>> still have a choice, tend to prefer the RtXY’s for the community >>> responsiveness, and the codebase is much more recent. >>> >>> Best >>> .r. > > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Bernard B. <ber...@gm...> - 2020-09-05 19:08:24
|
I worked today completing the sets of examples and tutorials of BP2: https://bolprocessor.org/examples/ https://bolprocessor.org/tutorials/ I am gradually transfering to the blog material I had presented in various conferences and seminars. It seems useful to display grammars along with comments and sound output… Bernard Bel |
|
From: Bernard B. <ber...@gm...> - 2020-09-04 11:38:47
|
Having almost completed the overview of old good BP1 (with minor technical issues) I started working on a documented display of examples of BP2: https://bolprocessor.org/examples/ (Anthony: the display of categories makes use of "Content Views" and "Safe Redirect Manager" to avoid the display of full contents of papers…) The first set of examples is dedicated to Harm Visser's contributions in 1998. The aim is to illustrate the advantage of "pencil and paper" composition over complicated graphic interfaces which were en vogue in the late 1990s. At least it highlights the diversity of work environments of composers even when they make an extensive use of computers. Bernard Bel |
|
From: Bernard B. <ber...@gm...> - 2020-09-02 20:29:26
|
I have completed another article showing BP1 in its real musical context. This wasn't difficult because of the availability of a "realistic" example in our 1992 publication. https://bolprocessor.org/bp1-in-real-musical-context/ Running the program was uneasy. Maybe because of a lack of memory, given the sizes of the grammar and data set. I am not certain that the emulator provided as much RAM as the physical Apple IIe… Sometimes I type ctrl-C in the first grammar rule and it quits the grammar instead of producing variations. In addition, I was not able to reconstruct templates. Maybe I have forgotten the right procedure! Anyway, the videos prove that all this is possible :-) All corrections and comments welcome ! Bernard Bel |
|
From: Bernard B. <ber...@gm...> - 2020-09-01 12:58:10
|
I completed the article on "installing BP1", adding some background information and links for readers who might have landed from another planet… Reading again our paper on BP1 applied to the study of q‘aida improvisation (https://halshs.archives-ouvertes.fr/halshs-00004506) I remember the importance of early features of BP1, such as pattern grammars (using a smart editor than could never be reproduced on the Mac version), wildcards, negative context etc. These are available in BP2 but we have very few examples of their use. Grammars and data analyzed in our 1992 paper are convincing examples but reading them requires investing time to get familiar with the musical context. Nonetheless, I am confident that we can publish an article on the website taking grammar "Q2.7" (from disk BP-JULY87.DSK) which is the first one described in our paper. The aim would be to demonstrate: 1) Producing variations with the grammar; 2) Analyzing data examples with the grammar (where templates are used); 3) Assigning weights to grammar rules from a set of (correct) examples — our first attempt of "machine learning". The same can be done using BP2 since all algorithms have been reproduced. Trying them on BP1 might give new ideas about their proper implementation in the next version. Bernard Bel --------- Hello BP1 fan club! I started documenting the installation and basic operation of BP1 in its Apple II emulation: https://bolprocessor.org/installing-bp1/ It is actually very easy to install but I wanted to describe the process in detail. A trial with LinApple on Linux would be welcome… I had done the test on Windows in Marseille. Don't hesitate to comment, suggest clarifications and fix language mistakes! (Anthony can edit the post directly.) I start remembering how it worked ;-) The next publication will be an explanation of its use, preferably using musical examples which had been well documented and mentioned in publications. For this reason I selected material dating to 1988, our latest work on this machine… Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-08-30 12:27:13
|
Hello BP1 fan club! I started documenting the installation and basic operation of BP1 in its Apple II emulation: https://bolprocessor.org/installing-bp1/ It is actually very easy to install but I wanted to describe the process in detail. A trial with LinApple on Linux would be welcome… I had done the test on Windows in Marseille. Don't hesitate to comment, suggest clarifications and fix language mistakes! (Anthony can edit the post directly.) I start remembering how it worked ;-) The next publication will be an explanation of its use, preferably using musical examples which had been well documented and mentioned in publications. For this reason I selected material dating to 1988, our latest work on this machine… Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-08-30 12:06:51
|
Hello BP1 fan club! I started documenting the installation and basic operation of BP1 in its Apple II emulation: https://bolprocessor.org/installing-bp1/ It is actually very easy to install but I wanted to describe the process in detail. A trial with LinApple on Linux would be welcome… I had done the test on Windows in Marseille. Don't hesitate to comment, suggest clarifications and fix language mistakes! (Anthony can edit the post directly.) I start remembering how it worked ;-) The next publication will be an explanation of its use, preferably using musical examples which had been well documented and mentioned in publications. For this reason I selected material dating to 1988, our latest work on this machine… Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-08-29 13:03:30
|
My floppies had been stored in ordinary cardboard boxes, yet in a very temperate and dry climate. I was only keeping them to show that they had existed — to people who did not care. They are still in the same boxes as I don't dare to dispose of them. ;-) The welcome and menu pages of BP1 are in Applesoft BASIC. Probably compiled, even though speed did not matter. Pure 6502 code is used every time you select a command. Therefore, the code was fragmented in several units, the titles of which appear on top of the source code, as I could see in BigMac. For instance there is a source file "BI.S" that BigMac will load if you ask for "BI". It took me time to remember that the "S" extension should not be included. Somewhere on the BP1 source disk there is a compiled BASIC program that I designed for picking up 6502 source code and creating a "flowchart" of the program structure printed on (many) pages. This rarely helped me to fix bugs but it was fun. Philippe, who helped me to transfer disk, told me that he has a piece of software (under Windows) that compiles 6502 code for several environments, including for instance Commodore 64 which actually accepted 6510, a more advanced language. If you recompile you may try to design a MIDI output!!! :-) It would be fun to recompile BP1 and run it on a virtual machine with more memory space, as this was my limit. Memory management on BP1 was sophisticated with a (recursive) automatic "garbage collection" procedure that moved blocks to maintain memory space compactedness. This anticipated "handles" on the Mac! Bernard Anthony Kozar wrote on 29/08/2020 13:06: > Bernard, > > Awesome! Thanks! :) > > You did have very good luck with your floppies. I should try reading > some of mine. They have been in storage in my attic though which can > get up to 100°F in the summer. :( > > I'm glad that you copied the BP1 source disk. I'm interested in > looking at the code. (I was surprised that BP1 seems to be a > combination of BASIC and 6502 assembly. I thought it was all assembly > code). > > I purchased the Opus ][ software collection so I now have a complete > suite of Apple II development tools. Most of the tools in that > collection are only for the IIgs but there is a version of the ORCA/M > assembler included for the Apple //e. It will be interesting to see > if the BP1 code is compatible with ORCA/M or if it needs to be ported. > > I used ORCA/C tonight to compile my first C programs on the IIgs. ^_^ > > Lots of fun stuff to explore now... > > Anthony > > > On 8/28/20, 3:56 PM, Bernard Bel wrote: >> I went again to Marseille on Thursday and transfered all my Apple II >> diskettes to DSK disk images, among which more data for BP1. You will >> find them here: >> >> https://bolprocessor.org/misc/BP1/ >> >> The program disk is named "BP-PRG.DSK". Data/grammar files are >> "BELFAST.DSK", "BP-JULY87.DSK", "BP-OCT88.DSK" and "BP-BB.DSK". >> >> The disk "BPSOURCES.DSK" contains all source files in 6502 machine >> language. If you are tempted to recompile BP1 you can download >> "BIGMAC.DSK" and then remind me how to edit/compile this code… ;-) I >> have forgotten the procedures that kept me busy for several years! >> >> Both Philippe M and I were amazed that these floppy disks dating back to >> 35 years were still perfectly readable. But his equipment (an Apple IIc) >> is also in perfect shape… >> >> To-morrow I will start writing an article on how to set up the emulator >> and run BP1. Later, Jim Kippen will figure out a demo making sense with >> this musical material (tabla composition/improvisation). >> >> Bernard > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Anthony K. <mai...@an...> - 2020-08-29 11:06:41
|
Bernard, Awesome! Thanks! :) You did have very good luck with your floppies. I should try reading some of mine. They have been in storage in my attic though which can get up to 100°F in the summer. :( I'm glad that you copied the BP1 source disk. I'm interested in looking at the code. (I was surprised that BP1 seems to be a combination of BASIC and 6502 assembly. I thought it was all assembly code). I purchased the Opus ][ software collection so I now have a complete suite of Apple II development tools. Most of the tools in that collection are only for the IIgs but there is a version of the ORCA/M assembler included for the Apple //e. It will be interesting to see if the BP1 code is compatible with ORCA/M or if it needs to be ported. I used ORCA/C tonight to compile my first C programs on the IIgs. ^_^ Lots of fun stuff to explore now... Anthony On 8/28/20, 3:56 PM, Bernard Bel wrote: > I went again to Marseille on Thursday and transfered all my Apple II > diskettes to DSK disk images, among which more data for BP1. You will > find them here: > > https://bolprocessor.org/misc/BP1/ > > The program disk is named "BP-PRG.DSK". Data/grammar files are > "BELFAST.DSK", "BP-JULY87.DSK", "BP-OCT88.DSK" and "BP-BB.DSK". > > The disk "BPSOURCES.DSK" contains all source files in 6502 machine > language. If you are tempted to recompile BP1 you can download > "BIGMAC.DSK" and then remind me how to edit/compile this code… ;-) I > have forgotten the procedures that kept me busy for several years! > > Both Philippe M and I were amazed that these floppy disks dating back to > 35 years were still perfectly readable. But his equipment (an Apple IIc) > is also in perfect shape… > > To-morrow I will start writing an article on how to set up the emulator > and run BP1. Later, Jim Kippen will figure out a demo making sense with > this musical material (tabla composition/improvisation). > > Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-08-28 19:56:21
|
I went again to Marseille on Thursday and transfered all my Apple II diskettes to DSK disk images, among which more data for BP1. You will find them here: https://bolprocessor.org/misc/BP1/ The program disk is named "BP-PRG.DSK". Data/grammar files are "BELFAST.DSK", "BP-JULY87.DSK", "BP-OCT88.DSK" and "BP-BB.DSK". The disk "BPSOURCES.DSK" contains all source files in 6502 machine language. If you are tempted to recompile BP1 you can download "BIGMAC.DSK" and then remind me how to edit/compile this code… ;-) I have forgotten the procedures that kept me busy for several years! Both Philippe M and I were amazed that these floppy disks dating back to 35 years were still perfectly readable. But his equipment (an Apple IIc) is also in perfect shape… To-morrow I will start writing an article on how to set up the emulator and run BP1. Later, Jim Kippen will figure out a demo making sense with this musical material (tabla composition/improvisation). Bernard |
|
From: Bernard B. <ber...@gm...> - 2020-08-27 14:13:10
|
I went on checking all examples of command-lines handled by the new version of the console. The PHP interface was updated accordingly and its new version uploaded to https://leti.lt/bolprocessor Some comments : ../bp64 templates -gr.checktemplates --traceout trace.txt In the PHP environment the "-traceout" option is automatically appended to the command, so "trace.txt" does not need to be specified because the interface is using the trace file created in the session. The editor looks for a "TEMPLATES:" statement in the grammar. If it is there, a button "CHECK TEMPLATES" is created. It would take time explaning what these templates are used. They are required for analysing items via a grammar instead of creating them. This is the "modus tollens" process of the expert system in contrast with "modus ponens" that produces musical items. It was explained in our earlier publications on modelling tabla improvization. I will create a simple tutorial to explain the method in the context of emulating the BP1 version on Apple II… > # the next two commands will generate some compilation errors > ../bp64 compile symbols.bpgr > ../bp64 compile symbols.bpgr --traceout trace.txt In fact they don't, in the PHP interface environment, because the grammar contains "-ho.:symbols.bpho" and the interface automatically inserts the option calling the alphabet. Again, I agree with Anthony that restoring the ability to auto-load related files would be a good idea instead of expecting that the interface will do the job. In both cases it is assumed that related files are found in the same folder as their calling file. In case they are not, the console could search for them higher in the tree structure. ../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout trace.txt --show-production ../bp64 produce symbols.bpgr symbols.bpho -o out.txt --traceout trace.txt --trace-production "-o out.txt" means that the output file must be set to "BP data file", otherwise the console will complain that no sound-object prototypes file is available for playing 'a', 'b', 'c' etc. "show-production" and "trace-production" are not set by the PHP interface. To activate these options we need a settings file. Thus, for instance, we write "-se.:symbols.bpse" at the top of grammar "symbols.bpgr". After saving it, a button EDIT ‘symbols.pbse’ appears at the bottom of the grammar page. Cliking the button prompts a dialog suggesting the creation of "symbols.pbse". The file is created with default options based on a template stored in the "php" folder. Once "symbols.pbse" has been created, options "show-production" or/and "trace-production" can be activated, yielding traces that will be visible in the Trace window. In fact, "trace-production" also forces "show-production". Evidently, "Step-by-step produce" does nothing else than "trace-production". This option was meant to display steps of production waiting for a key press after each step. ../bp64 produce produce-all.bpgr ../bp64 produce-all produce-all.bpgr The PHP interface does not call "produce-all" because the "produce all items" option is found in "produce-all.bpse" and the interface tells the console to read "produce-all.bpse". ../bp64 produce produce-all.bpgr -d --midiout out.mid The "--midiout" option is set by choosing a MIDI file for the output. ../bp64 produce produce-all.bpgr -d --midiout out-type-0.mid --seed 0 --midiformat 0 ../bp64 produce produce-all.bpgr -d --midiout out-type-1.mid --seed 0 --midiformat 1 ../bp64 produce produce-all.bpgr -d --midiout out-type-2.mid --seed 0 --midiformat 2 The format of the MIDI file is set by "produce-all.bpse". The "seed for randomization" is also picked up in "produce-all.bpse". ../bp64 compile -gr.Nadaka --traceout Nadaka-errors.txt Since "-gr.Nadaka" calls "-se.Nadaka" which contains the note convention, no error will be found in the compilation or production. ../bp64 produce -gr.Nadaka -se.hamsad --midiout Nadaka.mid "-se.hamsad" is not necessary on the interface because "-gr.Nadaka" calls "-se.Nadaka" which provides the note convention. "--midiout" is automatically set by choosing a MIDI file as the output format. Checking all these commands helped me to fix details in the interface. For example, "produce-all.bpgr" would write "Fb" instead of "E". I discovered that the Settings page was not correctly interpreting modifications of the names of notes… I also decided that the "extension format" — e.g. "produce-all.bpgr" instead of "-gr.produce-all" — should be proposed as the default format for Bol Processor files. Thus, for instance on Mac, the Finder can be instructed that "bpgr" is an extension for Bol Processor, which later will launch the new integrated interface. Indeed both name formats are taken care of, including a mixed format: "-gr.produce-all.bpgr". Previously I had claimed that the "prefix" format had been inherited from BP1 on the Apple II, but this is wrong as I can see on the emulation… I probably had chosen it to facilitate alphabetic sorting associated with file types instead of file names. But removing prefixes has the advantage of bringing together files of different types belonging to the same "project". Bernard Bel ------ Anthony Kozar wrote on 19/08/2020 22:40: > Bernard, > > I'm glad that things are working for you. > > I can still restore the ability to auto-load related files. The console > program may not always know where to find them, but it can at least try > a) the path given (if any) for the file that contains the reference, and > b) the current directory. > > I've added these two items to the To Do List file: > > - identify input files with prefixes even when they are preceded by a path > > - restore the feature that looks for names of related files in the input > files and auto-loads them > > Anthony > > > On 8/19/20, 1:27 PM, Bernard Bel wrote: >> Dear Anthony. >> >> I did a quick check and everything worked. >> >> It compiled. Then, after modifying the interface, I forced the console >> to read the settings file and get the note convention. It also worked. >> >> I still need to check other options. >> >> It is now clear that instructions such as >> >> -or.Nadaka >> -se.hamsad >> >> on top of the grammar are ignored by the console and must be read by the >> interface to add the options to the command line. This is logocal >> because the console cannot guess the full path. >> >> Compilations also worked and used note conventions found in the settings. >> >> This was a minimum test but I am uplaoding the revised PHP files. >> >> Bernard > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
|
From: Bernard B. <ber...@gm...> - 2020-08-24 16:46:47
|
Whichever system you try, it might be safe to create a function that can be called for sending a MIDI message, indirectly calling the one supplied by the package. This will make things easier in case the package is changed… Bernard Anthony Kozar wrote on 23/08/2020 23:05: > Midishare (from Grame) is still around. A new package for OS X El > Capitan was posted about two years ago. It is not clear to me whether > this package has any code changes compared to the previous release for > Mac OS X but the libraries in it are Universal binaries for i386 and > x86_64. While there has been activity in the Git repository as recent > as 2016, the last Windows and Linux releases appear to be from 2013 > and 2006 respectively. > > http://midishare.sourceforge.net/ > > The JACK Audio Connection Kit is cross-platform and appears to have > some support for real-time MIDI even though it is primarily a tool for > routing audio signals. The JACK project appears to be pretty active. > > https://jackaudio.org/ > > Overall, I am guessing that PortMidi will be the easiest to distribute > with BP so that BP users don't have to install anything extra. But > I'm really not that familiar with any of these libraries. > > Anthony > > > On 8/19/20, 11:20 PM, Bernard Bel wrote: >> It has a drawback: "RtMidi does not provide timing functionality (i.e., >> output messages are sent immediately)." >> >> In the tutorial (http://www.music.mcgill.ca/~gary/rtmidi/), time spacing >> between events is created by a "sleep" function which is >> platform-dependent. My objection is that it will cumulate errors. >> However, developers might have found tricks to avoid error cumulation — >> unless they estimate that it is not so important. >> >> One of the reasons for insisting on time accuracy is that several BPs >> improvizing together would need to stay perfectly synchronized (without >> sending specific MIDI messages for their synchonization). >> >> Bernard >> >> >> Rainer Schuetz wrote on 20/08/2020 00:36: >>> You might want to have a look at RtMidi for comparison: >>> >>> https://github.com/thestk/rtmidi >>> >>> There are Portaudio and Portmidi, and RtAudio and RtMidi… The later >>> seem >>> to be a result of some lack of responsiveness of the team behind the >>> “portXYs”. I can’t make a judgement at all but I know that projects >>> that >>> still have a choice, tend to prefer the RtXY’s for the community >>> responsiveness, and the codebase is much more recent. >>> >>> Best >>> .r. > > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
