On Thu, 2009-09-24 at 10:21 -0500, Jeremiah Benham wrote:
On Wed, 2009-09-23 at 10:12 +0100, Richard Shann wrote:
Another point about the passing strings convention: I dislike those
NULL separated strings appearing in the scripts. On the other
hand, a
haphazard collection of different types of parameters, which would
then
require a whole apparatus of documentation seems unattractive.
Anybody any thoughts on this?
Strings are fine with me. Is space separation fine? Like
(d-OutputMIDI "0x90" "0x3c" "0x40")
I think we are better with "0x90 0x3c 0x40"
Incidentally, we should reserve (d-Something...) to mean a procedure
not
to be found in denemo.scm, init.scm etc, that is, a command
(even though some would never appear in menus).
I think some midi messages are 4 byte. I am not sure which ones off
the
top of my head though. I think we can start with three and if there
is a
demand for 4 byte we can add that. Perhaps d-OutputMIDI can take an
optional 4th byte.
for d-PlayNote we could do (d-PlayNote "0x3c"). This would use the
selected staffs channel/volume etc.. If the user wanted to change
that
they would use a different script to change the staff properties.
So if
they wanted to play a note on every channel they would do something
like.
(d-StaffPropertiesMidiChannel "2")
(d-PlayNote "0x3c")
This can be placed in a loop or whatever. We can also have maybe a
more
complicated (d-PlayNote "notenum" "duration").
I also wonder if it would be better for complicated things like
StaffProperties if we used regex or something that way it looks like
this:
(d-StafProperties "midi_channel=1 midi_volume=127")
Then all the other values are left alone. Perhaps something like:
(d-StaffProperties "help")
can list variables to set.
This is the real nitty gritty: at the moment we write
(d-StaffProperties "prop1=value\0prop2=value...")
where there is no way of discovering the names prop1 etc (they are
hardwired into the callback of the StaffProperties command).
This last we can fix, I think, at least with a bit of macho macro work
in the GET_PARAM stuff (in utils.h); essentially responding to the
"help" string by returning the list of parameter names (which already
appear as the macro arguments).
However we still have those NULLs separating the strings. Again, with
more work on the macros we could make them detect the type of the
param
passed, so that commands could take a list argument. The list would
be a
list of strings "prop1=value". Again, that just requires a bit a macho
macro work in utils.h, we could keep the present code for backward
compatibility.
I think that is the way to go.
Sorry I am just kind of brainstorming here.
Thanks
Richard
Jeremiah
Richard
_______________________________________________
Denemo-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/denemo-devel
_______________________________________________
Denemo-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/denemo-devel