2015-04-26 17:05 GMT+02:00 Richard Shann <[email protected]>: > On Sun, 2015-04-26 at 16:34 +0200, Éloi Rivard wrote: > > Ok thank you for those answers. I will continue my importer then and > > ignores that the midi played is not what I expect. > > > > What do you think of making barlines (and special endings) some denemo > > objects instead of lilypond ones. So when we would play the midi, it > > would just produce the expected sounds without further command ? > > We wouldn't want it to do that in general - it would take twice as long > to listen to a piece that has repeats in the usual case which is > listening to check for mistakes. To listen to a performance you can > always get LilyPond to generate a MIDI file and play that with a MIDI > player. > > > I saw some old pieces of code in relation. > > Yes, I moved away from hard-coding such things as only C programmers > could contribute to it written that way. Instead, by making as much as > possible the input display controlled by Scheme we were able to attract > other users to code things like the dynamics and the tempo changes - > these uses the midbytes field of the Denemo Directives to control the > MIDI output to reflect the changes as well as using the graphic field to > make the display reflect the input. > > To get the hard-wired MIDI code to respond to hard-coded repeat > indications would again require working at the C code (which is my > comfort zone too) and then any further tweaks that user's might want (I > think I covered Da Capo and Dal Segno in d-Performance but not third > time bars) would not get done for lack of scriptability. > > What would be better is to go in the opposite direction, reducing the > amount of built-in stuff (slurs for example, are divided between those > that are built-in and the phrasing slurs which are scheme). Then when > new features are wanted (cresc. .... poco ... a ... poco for example) > they could be done better than at present (where we cannot display > anything between the start point and end point, which we can do for > built-in things like slurs and hairpin crescendi). >
I thinked a bit, and that sounds very weird to me. My believe is that scripts languages should be there to handle features for very ad-hoc cases. But coding new features with a script language, without having any control on it with the native language, well I think it is a very strange design. If think I encounter difficulties with my importer because a lot of things needs to be done with scheme, and paradoxally it lacks some "scriptability". For example the OpenFirstTimeBar command works well, but what if I want to open the second time barline, or the third, or the first and second, or the Xth ? Currently for instance, how to parse every objects in the score to create an exporter for instance, since there are a lot that are lilypond directives inserted with some scheme code ? > > Is d-Performance working in all cases I wonder - I just tested a very > simple example, but I never have occasion to use it myself, so it would > be easy to imagine that with other developments it may have accumulated > bugs. > Would you like to extend it for 3 or more time bars? It would be > possible to extend it to include arbitrary indications which you can > have in the nth-time bar command - you would write the script to include > some scheme data in the data field of the Denemo Directive that would > tell d-Performance where to go to to play the next section. > > Richard > > > > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
