Re: [Denemo-devel] Source directory

[Richard Shann]

On Wed, 2014-03-05 at 11:55 +0100, Eloi Rivard wrote:
> > I'm not at all convinced that classifying code by whether it is dealing
> > with files on a disk is a good way to go. Files containing stuff derived
> > from the music you have created with Denemo is one thing, files that
> > contain stuff that you want to use to create a music score is quite a
> > different thing.
> 
> You are right, actually dealing with import/export files is not the same
> that just loading a file as a "meta-data" to the score. Maybe a new
> directory is needed here. I am not sure how to call it. Do you think
> that "file" and "meta" are good names ?

"export" I think is good for creating representations of the music in
formats that other programs can use. The name "source" could be ok for
code for reading-in data that the user will use for creating a score. (I
don't think "meta" is good here - that would be some sort of data about
the musical score, e.g. a file containing statistics about the number of
bars, or particular harmonic progressions ...)
>        
> > >         command:
> > >         changenotehead.c  chordops.c  commandfuncs.c  contexts.c
> > >         fakechord.c  figure.c  graceops.c  keyresponses.c  lyric.c
> > >         measureops.c  objops.c  processstaffname.c  scorelayout.c 
> > 
> > scorelayout.c is part of printview.c and exportlilypond.c 
> > also I see chordops.c here, there are also measureops.c scoreops.c IIRC
> 
> scorelayout seem to edit the score directly, thus I think it should be
> kept in "commands", or maybe split

Hmm, this is an example where the simple model breaks down. For most
uses scorelayout.c is just part of the generation of the LilyPond text;
it generates nothing that gets saved to disk in the myname.denemo file
that represents the score. But it also creates a gui for looking at the
structure of the LilyPond text, and if you choose to you can then use it
to add data to the score (that *will* be stored in myname.denemo),
namely, customised score layouts.
*However* I would not expend too much mental effort on this: I would
like to re-write all that stuff as it is not intuitive enough to pick up
and use easily as it is.


> 
> 
> > >          scoreops.c  selectops.c  staffops.c  tupletops.c
> > >         changenotehead.h  chordops.h  commandfuncs.h  contexts.h
> > >         fakechord.h  figure.h  graceops.h  keyresponses.h  lyric.h
> > >         measureops.h  objops.h  processstaffname.h  scorelayout.h
> > >         scoreops.h  selectops.h  staffops.h  tupletops.h
> > >         
> > >         core:
> > >         binreloc.c  binreloc.h  denemo_types.c  external.c  external.h
> > >         http.c  http.h  kbd-custom.c  kbd-custom.h  keyboard.c
> > >         keyboard.h  keymapio.c  keymapio.h  main.c  prefops.c
> > >         prefops.h  twoints.h  utils.c  utils.h  view.c
> > >         
> > >         display:
> > >         accwidths.h           calculatepositions.h  displayanimation.h
> > >         drawbarline.c  drawclefs.c   drawdynamic.c    drawfigure.c
> > >         drawingprims.h  drawlilydir.c  drawnotes.c      drawstemdir.c
> > >         drawtuplets.c  hairpin.h     printview.c
> > 
> > printview has nothing to do with drawing the Denemo display (main
> > window) it handles the typeset display and belongs with exportlilypond.c
> > (badly named) which generates LilyPond syntax.
> 
> Well, maybe a new directory is needed here too. I think "render" might
> be a good name for printview sources.

"printview" gives a better idea of what is there, render would apply to
the Denemo display and indeed the drawing of dialogs etc.

>  How to call the Denemo display ?
> "display" may not be a good name, as it is not only about displaying but
> mainly about editing.
I was using the term only for the drawing of the display. It is true
that you look at the Denemo Display as you edit music (usually) and
technically the Denemo Display has the keyboard focus (so the
key-presses are being received by the GtkDrawingArea widget), but the
code called draw*.[ch] is just to do with drawing into that widget, for
which "display" is not a bad name.

> 
> > >           displayanimation.c    drawaccidentals.c   draw.c
> > >         drawcursor.c  drawfakechord.c  draw.h        drawkey.c
> > >         drawlyric.c    drawselection.c  drawtimesig.c  hairpin.c
> > >         notewidths.h  printview.h  slurs.h
> > >         
> > >         file:
> > >         audiofile.c  exportabc.c  exportlilypond.c  exportmidi.c
> > >         exportxml.c  file.c  guidedimportmidi.c  importmidi.c
> > >         importmusicxml.c  importxml.c  print.c  screenshot.c
> > >         xmldefs.h
> > >         audiofile.h  exportabc.h  exportlilypond.h  exportmidi.h
> > >         exportxml.h  file.h  guidedimportmidi.h  importmidi.h
> > >         importmusicxml.h  importxml.h  print.h  screenshot.h
> > 
> > as I say above, mixing stuff that is used to create a music score with
> > stuff that can be generated from a score once it is created seems a bad
> > idea. So guidedimportmidi and importmidi and screenshot belong in input
> > below. And the (badly named) exportxml.* is our fundamental
> > save-a-project-code for saving in denemo's own format. It doesn't sit
> > nicely along with exported things.
> 
> You wish to separate import and export projects .denemo files (load and
> save actually) from import and export project in other formats
> (musicxml, lilypond, midi etc.) ?
yes
>  I though we could regroup those
> sources that can "load and save music from/to a file, whatever format it
> uses".
we used to do that, but it leads to the expectation that the score can
be recovered from an exported file - e.g. people naively think that a
MIDI file would adequately represent the score.

> 
> This is a good question. Most of users are not computer experts, and
> just do not care about which format is used. They just want to "load or
> save some music". Gimp for instance try to privilege their own project
> format, but Libreoffice let you save documents in whatever format you
> want (without making any difference between load/save and
> import/export).
> 
> How do you see things ?

I think we are a more extreme case than either of those two, and those
two choose the right policy for their cases I think. Gimp needs to make
you aware that if you save as jpeg you will not be able to edit some
text you have in an image, and LibreOffice knows that you will still
have the actual words of your document if you save as .txt
By contrast if you save myname.denemo as MIDI and think you don't need
the myname.denemo any more you are in for a rude shock. You can hear
what it might sound like, but you have a lot of work to recreate a
musical score from the file.

Richard