Re: [Denemo-devel] directives.

[Richard Shann]

On Thu, 2009-12-24 at 13:55 +0300, alex stone wrote:
> With a willingness to contribute to the denemo project i'm trying to
> get my non coding head around Directives.
> 
> I have a question at this point.
> 
> Can a directive (read set of directives) take more than 1 user input
> directive in the same set?
At the moment there are only a few pretty simple ways of taking data
from the user. I suggest using one of them, despite clunkiness, in the
sure & certain knowledge that we can expand the set to anything we want.
But until we have some scripts in use that look to clunky, no-one will
be tempted to write support for nicer input (it is not that it is
difficult, but until we have concrete examples needing it, I don't
expect it to happen).
so:

> 
> Use Case.
> 
> I'd like to build a script that enables me to input, if chosen,
> channel, bank, patch, and type of CC message. (Volume=CC7,
> Expression=CC11, etc)
> 
> When i move the cursor to a note, at which i would add these values
> for types of data, i'll need to manipulate the value of each element,
> in one pass, as follows;
> 
> Channel <n> (represented as a channel value between 1-16)
> 
> then i would move to
> 
> Bank LSB <n> (represented as a midi integer between 0-127)
> 
> then i would move to
> 
> Patch <n> (represented as a midi integer between 0-127)
> 
> then i would move to
> 
> Midi CCtype (represented as a midi integer between 0-127)
> 
> then i would move to
> 
> the midi CC type value (represented as a midi integer between 0-127)

The clunky way is
(define channel (d-GetUserInput "Channel Selection" "Give Channel (0-127): " 
"0"))
and then two more of these getting bank and patch.
> 
> 
> 
> Can the above be written as a single directive 
a directive is what you are going to create in the course of your script
(indeed you may be going to create several). I think the question
intended was "Can the above be written as a single procedure?" which
really means, do we have a command like (d-GetUserInput ...) that takes
a set of names, prompts, initial values (ranges, types ...) and returns
a list of values. And the answer is not yet. They won't turn up until we
have a clunky way of doing something really useful.
As long as you put the little sequence of (d-GetUserInput...)s together
(in a procedure even) it will be trivial to upgrade when a non-clunky
input procedure arrives.

Richard