Re: [Denemo-devel] Jackmidi Status?

[Richard Shann]

On Thu, 2009-09-24 at 15:59 -0500, Jeremiah Benham wrote:
> 
> 
> 
> On Sep 24, 2009, at 11:52 AM, Richard Shann <address@hidden>  
> wrote:
> 
> > 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"
> 
> Should we maintain space seperation?
yes - the code parsing this (for midibytes) allows whitespace in fact.
It also allows you to use decimal numbers - it uses strtol(3?)


> 
> > and we could take a leaf out
> > of the format of the midibytes string so that $ refers to the current
> > channel and %%% refers to the curent volume - the logic of this is
> >
> >      * the channel being a single hex nibble
> >      * the volume is to be thought of as three decimal digits, 0-127
> 
> Why is the volume in decimal? Is that to make it more human readable? 
yes
>  
> If so why don't we make the pitch also a decimal. So instead of 3c it  
> would be 60.
you can already do that (again referring to the parser for midibytes in
calls such as (d-DirectivePut-chord-midibytes "mytag" "0x9$ 60 %%%")
which will do NOTEON with pitch 60 on current channel at current
volume).

> 
> >
> > (it makes it quick and easy to substitute in MIDI generation).
> > then you can write "0x9$ 0x3c %%%" to mean noteon 0x3c at current
> > volume on current channel.
> 
> Actually i think you mean set volume/channel to script parameter.
No, we don't have any such thing as a "script parameter", the notation
is supposed to look familiar - be easy to remember - that's all. The $
and %%% are just arbitrary symbols which I chose so they can
conveniently be substituted in the C code by the channel and volume
before being attacked by strtol to get out an actual 3 byte midi
message.
So the proc PlayNote would be

(define (PlayNote pitch) (d-OutputMIDI (string-append "0x9$ " pitch " %%%")))

which would be called as

(PlayNote "60")

or (PlayNote "0x3C") if people wished.

(the define above is E&OE - I haven't checked the syntax!)


richard



>  If  
> the argument us left blank it should default to current volume/channel.
> 
> > Which is what you would script into a
> > DenemoDirective midibytes field. Of course, this can then all be  
> > hidden
> > inside
> > (PlayNote "0x3c")
> 
> If everything is on one set of quoted than the size of the string can  
> determine outcome of an if/else. If length of string == 2 default to  
> staffs channel/volume. If string == 6 then use the script parameters,  
> this is assuming it is all hex. Putting a decimal will create a size  
> of 6-9 depending on how many digits are used.
> 
> I must go now
> Jeremiah
> 
> >
> > 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