|
From: Bernard B. <ber...@gm...> - 2020-07-28 14:17:13
|
Dear Anthony, There is no emergency, each of us should set his own agenda according to what is inspiring at the moment rather than fixing priorities on a huge to-do list. ;-) I worked on the prototypes editor because I expected it to be a boring task… Ssometimes I do boring tasks just to feel the relief of them! The first two weeks of August I will be travelling, visiting friends and sleeping in forests most of the time with no Internet connection. After this we will have other activities until the last week of August, so it will be difficult for me to focus on long developments. I will certainly read exchanges and figure out plenty of new tasks. For this reason I felt happy to document what has been done so far on the interface. You remind me of "bp --help"… I added a link at the top of interface pages. Regarding playing items and start strings, I believe it can be made more straightforward. Indeed you can have many options for doing similar things, so that's not a problem. In all cases we supply the console with a text file containing "BP data". It may be a file containing several items along with headers declaring the alphabet file which in turn will declare a "-mi" sound-object file. Since a sound-object file requires the declaration of its objects in an alphabet file, it is not useful to declare it in the data file, or this declaration should be ignored. A BP data file may also contain a single polymetric structure that would be reduced to a single sound-object when the Play command is called from the object editor. In this case, the interface creates a dummy alphabet file containing the name of its "-mi" file and the names of its sound-objects. So, the call only mentions the data file and the alphabet file. The console will pick up the name of the "-mi" file and load it. (This is what BP2.9.8 does, so it should not require extra programming.) If the BP data file contains variables, the console will recognize them because it won't find them in the alphabet. In this case it will need a grammar file to derive the expression. In all cases, the expression is always taken as a "start string". There is no specific status for a start string. Whatever is eaten by the grammar could be called a start string… This is where I believe that your syntax might be redundant. In all cases, if we include a grammar file in the Play command, the grammar will be loaded and compiled although it may only be used when the string of data (the "start string") contains variables. I don't think there is a need for a "--use-grammar" option: either the grammar is supplied or it isn't. If it is supplied, BP will try to apply it to whatever it is prompted to play. In the end, if some variables cannot be derived because either they don't occur in the grammar or no rule was applicable, they should simply be ignored. This is what BP2.9.8 does. In the "-gr.nadaka" grammar, for instance, the item ends up with: ga4 _ _ _ _ 4 G _ _ _ _ _ _ _ in which "G" is a variable that could not be derived. Well, the piece ends up with a silence of 4 beats… As the output sounded correct we never noticed the error. So, the minimum Play command we need is: Play datafile alphabetfile (grammarfile) We probably will need to add -pclock and --qclock because no "-se" file is there to supply them. Indeed, if there are several items in the datafile it will be good to have the option of playing a declared number of them. Data piped from other commands would be a great achievement! Bernard Anthony Kozar wrote on 28/07/2020 12:30: > Yes, these features are on the "to do" list. You can see most of what > I have planned from the command "bp --help". I have been planning for > the 'play' command to work on data files though. E.g. > > bp play -da.someitems [output options] > > would play the first item in the file -da.someitems. > > bp play-item 5 -da.someitems [output options] > > would play the fifth item. > > bp play-all -da.someitems [output options] > > would play all items, of course. I've also been considering the idea > of being able to read data items from standard input so that BP > console could be used to process data piped from another command: > > ./my-script | bp play --read-stdin -e --csoundout - | csound -i ... > > (I haven't decided on any particular syntax yet). > > If grammar derivation is needed, then the -s, --start, or -S options > will allow one to specify a start string, either on the command line > or in a file. > > bp produce -gr.mygrammar -s "X Y X" [output options] > > bp produce -gr.mygrammar -S startstr.txt [output options] > > Will this command line syntax work for you? I'm open to suggestions > for changes. One issue I see with the above is that an interface to > BP console would need to know whether the selection to be played > contains variables or not. We could probably solve that by providing > options to the "play" command like "--use-grammar" and "--no-grammar" > (or "--derive" and "--no-derive"?) Either way, shorter options like > -G and -g might be nice too. > > I'm sorry that I haven't been able to make any significant progress in > the past week. There have been a few too many other things popping > up. I hope this week will be better. > > Anthony > > > On 7/27/20, 10:05 AM, Bernard Bel wrote: >> Dear Anthony, >> >> We will need a "play" command reproducing the behaviour of "Play >> selection" on BP2.9.8. The difference will be that instead of capturing >> a selection from the Finder it will pick up the same from a "startup" >> file. > >> Later we may need to play startup expressions containing variables >> (among which "S"). In this case the command will be: >> >> path_to_bp/bp play --startup path_to_startup/startup.txt -gr >> path_to_grammar/grammarfile -ho path_to_alphabet/alphabetfile -d >> --midiout >> >> Since the alphabet file contains the name of the '-mi' file, BP will >> automatically load the relevant '-mi' file. >> >> When time permits you may include a "--settings" option, although >> normally settings are declared in the grammar file. >> >> Bernard |
