Re: [Denemo-devel] Source directory

[Richard Shann]

On Wed, 2014-03-12 at 17:48 +0100, Éloi Rivard wrote:
> Ok.
> 
> 
> So exportxml and importxml belong in "core".

yes

> 
> Sources related to music file import/and export belong in
> "export" (isn't it too specific, as there is also importmusicxml
> too ?)

"import-export" might be a better name, but they could be separated.
importmidi.c and importmusicxml.c are the only C files that do import
IIRC. LilyPond is imported via a scheme script.


> 
> Sources related to midi input belong in "input"
Is this is MIDI controller input (not to be confused with midi file
import)?? or did I misunderstand above? MIDI controller input is spread
around quite a bit I think...

> 
> Sources related to miscellaneous content that may be linked to a score
> belong in "source".
> 
> 
> Am I right ?

not sure, (see above)

Richard



> 
> 
> 
> 2014-03-05 17:19 GMT+01:00 Richard Shann <address@hidden>:
>         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
>         
>         
>         
>         
>         
>         
> 
> 
> 
> -- 
> Éloi Rivard - address@hidden
>         
> « On perd plus à être indécis qu'à se tromper. »
>