denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Jackmidi Status?


From: Richard Shann
Subject: Re: [Denemo-devel] Jackmidi Status?
Date: Thu, 24 Sep 2009 17:52:07 +0100

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" 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
(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. Which is what you would script into a
DenemoDirective midibytes field. Of course, this can then all be hidden
inside
(PlayNote "0x3c")
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
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]