lilypond-devel
[Top][All Lists]
Advanced

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

T3154 work - round 2 - question.


From: Ian Hulin
Subject: T3154 work - round 2 - question.
Date: Sat, 20 Jul 2013 23:36:08 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

Thanks for replies to the last enquiry, David, I'll try and be a little
more coherent in this one (despite the 30C tempertures here in the UK).

You asked in your reply in the last thread:
"The question is whether it even makes sense trying to go through \midi
or whether one should actually use the (somewhat ill-fittingly named)
\paper block instead."

\midi can be attached to \score blocks, you can have have multiple
\scores in a single \book or top-level, so there's a boundary clash
here, and \paper started life being a block for more general layout
settings than \layout.  I think when you did the original changes to
convert \bookOutputSuffix and \bookOutputFile from using global parser
variables, you had to choose \paper as the least worst fit.  So I think
the variables will need to go into \midi blocks.

However, the it looks like the \midi blocks still need to be stackable
and I've just figured out the way you implemented the things for \paper¸
and I think we could use a set of general procedures/method to handle
output_def stacks, modelled on what you did for \paper.

I.e.
(<blah> could be one of papers, midis, or layouts)
get_<blah> // used by parser to set up an initial output_def (though
get_midi has a potential name clash with a method in Midi_walker::)
These probably need to stay as separate functions for each output_def type.

init_<blah> // initialize the stack using a parser variable
push_<blah> // push an output def onto the stack using the
            // parser variable
pop_<blah>  // push an output def from the stack using the
            // parser variable
set_<blah>  // set the value of the topmost stack item.

An example: (Please excuse the naff formatting courtesy of my mail-client)

void
init_od_stack ( string od_type, Lily_parser *parser)
{
  switch (od_type.c_str())
    {
    case 'paper':
      {
        //init_papers (parser);
        SCM stack_parser_var =
                parser->lexer_->lookup_identifier ("$papers");
        SCM default_parser_var =
                parser->lexer_->lookup_identifier ("$defaultpaper");
        SCM od_property_val = ly_symbol2scm ("is-paper");
      }
      break;
    case 'midi':
      {
        //init_midis (parser);
        SCM stack_parser_var =
                parser->lexer_->lookup_identifier ("$midis");
        SCM default_parser_var =
                parser->lexer_->lookup_identifier ("$defaultmidi");
        SCM od_property_val = ly_symbol2scm ("is-midi");
      }
      break;
    case 'layout':
      {
        //init_layouts (parser);
        SCM stack_parser_var =
                parser->lexer_->lookup_identifier ("$layouts");
        SCM default_parser_var =
                parser->lexer_->lookup_identifier ("$defaultlayout");
        SCM od_property_val = ly_symbol2scm ("is-layout");
      }
      break;
    }
  Output_def *my_output_def =
        ((stack_parser_var == SCM_UNDEFINED)
                || scm_is_null (stack_parser_var))
                  ? 0 : unsmob_output_def (scm_car (stack_parser_var));
  my_output_def =
        my_output_def ? my_output_def
                : unsmob_output_def(default_parser_var);

  my_output_def =
        my_output_def ?
        dynamic_cast<Output_def *> (my_output_def->clone ())
                : new Output_def;
  my_output_def->set_variable (od_property_val, SCM_BOOL_T);
  return my_output_def;
}

WDYT?

In some cases it may make sense to retain separate functions, but it
then becomes a "mere matter" of where to place the calls in parser.yy.
(That may need a "round 3" thread.)

Hope this made sense,

Cheers Ian









reply via email to

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