Re: [Denemo-devel] Jackmidi Status?

[Jeremiah Benham]

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?

> 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?  
If so why don't we make the pitch also a decimal. So instead of 3c it  
would be 60.

> (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. 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