Hi Keith,
Thanks for answering!
After reading your reply I became aware that I didn't mention that the way of
triggering the Braille output should be similar to the way midi export is done,
for example in the form of a \braille tag.
I might be wrong, but I don't think creating a separate Brail
On Nov 13, 2013, at 12:11 AM, Keith OHara wrote:
> Mike Solomon mikesolomon.org> writes:
>
>> out/lexer.cc:32:25: error: prototype for
>> 'size_t yyFlexLexer::LexerInput(char*, size_t)'
>> does not match any in class 'yyFlexLexer'
>> out/lexer.cc:6460:8: note: in expansion of macro 'yyFlexLexer
Mike Solomon mikesolomon.org> writes:
> out/lexer.cc:32:25: error: prototype for
> 'size_t yyFlexLexer::LexerInput(char*, size_t)'
> does not match any in class 'yyFlexLexer'
> out/lexer.cc:6460:8: note: in expansion of macro 'yyFlexLexer'
> size_t yyFlexLexer::LexerInput( char* buf, size_t max_
2013/11/12 :
> So this patch leaves open questions, and people might give themselves
> answers consistent with the current behavior. Overriding those answers
> later with a convert-ly rule seems unfeasible: this is really a bit too
> invasive and complex to change using convert-ly.
>
> The curren
2013/11/12 :
> It still would not be fun in connection with TabStaff, not repeating
> string numbers and stuff, and such repetition is really not feasible.
I don't understand what you mean here.
> Of course the problem is that we have to make a decision what to
> support:
>
> a) we don't commit
Hey all,
Compiling LilyPond with g++ on mac os x, I get the following errors:
out/lexer.cc: At global scope:
out/lexer.cc:32:25: error: prototype for 'size_t yyFlexLexer::LexerInput(char*,
size_t)' does not match any in class 'yyFlexLexer'
#define yyFlexLexer yyFlexLexer
On 2013/11/12 15:35:42, benko.pal wrote:
On 2013/11/12 10:23:56, dak wrote:
> a) we don't commit ourselves either way: it is undefined what a pure
duration
> after an intervening chord will do.
>
> b) just single pitches, no chords: that's what this patch proposes.
>
> c) also chords: this patc
On 2013/11/12 10:23:56, dak wrote:
a) we don't commit ourselves either way: it is undefined what a pure
duration
after an intervening chord will do.
b) just single pitches, no chords: that's what this patch proposes.
c) also chords: this patch needs more work, supporting code must be
wri
Some more thoughts about the chord issue: I agree that it sounds
somewhat icky to have repetition not extend to chords, in particular
when having a music function with a body like
#{ #music 4 4. 8 #}
and calling it with either \rhythm c or \rhythm , it will be quite
a nuisance that the first works
