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 <[email protected]>: > 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 - [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
