Re: [Denemo-devel] Source directory

[Richard Shann]

On Sat, 2014-03-01 at 14:08 +0100, Éloi Rivard wrote:
> You can see it in the "subdirs" branch if you want.
> 
> 
> 
> 2014-02-28 20:51 GMT+01:00 Éloi Rivard <address@hidden>:
>         I made a try at home, tell me if there is something you think
>         is not in the right place:
>         
>         address@hidden ~/dev/denemo/src]$ ls *
>         Makefile.am  Makefile.in  pathconfig.h
>         
>         audio:
>         alsabackend.c  audiointerface.c  dummybackend.h  fluid.c
>         jackbackend.h  midi.c        pitchentry.h  playback.c
>         portaudiobackend.h  portmidibackend.c  portmidiutil.h
>         alsabackend.h  audiointerface.h  eventqueue.c    fluid.h
>         jackutil.c     midi.h        pitchrecog.c  playback.h
>         portaudioutil.c     portmidibackend.h  ringbuffer.c
>         audio.h        dummybackend.c    eventqueue.h    jackbackend.c
>         jackutil.h     pitchentry.c  pitchrecog.h  portaudiobackend.c
>         portaudioutil.h     portmidiutil.c     ringbuffer.h

I think there is a problem here: completely different things are in this
directory. One activity is to do with playing a score back, for which
"audio" is quite a good overall name. The other is getting input from
the user from microphone or MIDI controller, audio_in and midi_in.
I think they both share some queueing software which has been stolen
from the JACK project, and so, rather confusingly, has the name jack_
attached to it, even though it applies to systems that are not using
JACK.
midi.c in particular will present a problem. In part it has stuff to do
with MIDI controller input. And in part it has stuff to do with
playback. It may even have bits used by midi import from file.

>         
>         command:
>         barline.c 
>          bookmarks.c

       barline.c and bookmarks.c are obsolete code AFAIK


>           changenotehead.c  chordops.c  commandfuncs.c  contexts.c
>         dynamic.c  fakechord.c  figure.c  graceops.c  keyresponses.c
>         lyric.c  measureops.c  objops.c  scoreops.c  selectops.c
>         staffops.c  tupletops.c
>         barline.h  bookmarks.h  changenotehead.h  chordops.h
>         commandfuncs.h  contexts.h  dynamic.h

dynamic.h and c are obsolete AFAIK

>           fakechord.h  figure.h  graceops.h  keyresponses.h  lyric.h
>         measureops.h  objops.h  scoreops.h  selectops.h  staffops.h
>         tupletops.h
>         
>         core:
>         binreloc.c  denemo_types.c  external.h  http.h
>         instrumentname.h 

instrumentname.h is a playback thing

>          kbd-custom.c  keyboard.c  keymapio.c

these are to do with keyboard shortcuts, and belong with
keyresponses.c,h I would think

>           main.c              parseinstruments.h 
parseinstruments.h is also a playback thing I think - possibly some of
the instrumentname stuff is obsolete, we are getting instrument names
from  the installed soundfont

>          prefops.h  utils.c
>         binreloc.h  external.c      http.c      instrumentname.c
>         instruments.xml 

see previous comment


>           kbd-custom.h  keyboard.h  keymapio.h

see above

>           parseinstruments.c  prefops.c           twoints.h  utils.h
>         
>         generated:
>         entries.h  register_commands.h  scheme_cb.h  scheme.h
>         xml.fragment
>         
>         io:

This name (for Input/Output) would apply to the things listed as "audio"
above, as well as keyresponses.c (which are keyboard input things)

>         audiofile.c  exportabc.c  exportlilypond.c  exportmidi.c
>         exportxml.c  file.c  guidedimportmidi.c  importmidi.c
>         importmusicxml.c  importxml.c  print.c  processstaffname.c 

processstaffname.c is some sort of staffops.c I think.

>          screenshot.c  xmldefs.h

xmldefs.h are some utilities for many of the users of the libxml2
library

>         audiofile.h  exportabc.h  exportlilypond.h  exportmidi.h
>         exportxml.h  file.h  guidedimportmidi.h  importmidi.h
>         importmusicxml.h  importxml.h  print.h  processstaffname.h
>         screenshot.h

screenshot.* are to do with capturing source material and storing in a
Denemo score.

>         
>         render:
>         accwidths.h           displayanimation.c  drawbarline.c
>         drawcursor.c     drawfigure.c    drawkey.c      drawnotes.c
>         drawtimesig.c  hairpin.h       notewidths.h  slurs.c
>         calculatepositions.c  displayanimation.h  draw.c
>         drawdynamic.c    draw.h          drawlilydir.c
>         drawselection.c  drawtuplets.c  moveviewport.c  printview.c
>         slurs.h
>         calculatepositions.h  drawaccidentals.c   drawclefs.c
>         drawfakechord.c  drawingprims.h  drawlyric.c    drawstemdir.c
>         hairpin.c      moveviewport.h  printview.h

I am not sure moveviewport.h belongs here - it is controlling the
display widget, not drawing inside it.


>         
>         scripting:
>         lilydirectives.c  lilydirectives.h  scheme-callbacks.c
>         scheme-callbacks.h  scheme-identifiers.c  scheme-identifiers.h
>         
>         source:
>         audiocapture.c  audiocapture.h  sourceaudio.c  sourceaudio.h
>         source.c  source.h

pitchrecog.c and some stuff in midi.c belong here


>         
>         ui:

I think you have picked up many of these because they have dialog in
their name. Denemo is a ui, a user-interface, so it is difficult to
exclude things from this directory.

>         clefdialog.c  help.c  kbd-interface.c  keysigdialog.c
>         mousing.c  mwidthdialog.c  palettes.h        palettestorage.h
>         playbackprops.h  scorelayout.c

scorelayout.c (IIRC) is to do with making changes to the LilyPond
typesetting at the structural level (e.g. moving lyrics above staffs
instead of below).

>           scoreprops.c
>                texteditors.c
>           timedialog.c       view.c
>         dialogs.h     help.h  kbd-interface.h  keysigdialog.h
>         mousing.h  palettes.c      palettestorage.c

palettestorage.c is (IIRC) to do with saving the user's palette
preferences

>           playbackprops.c   prefdialog.c     scorelayout.h
>         staffpropdialog.c  texteditors.h  tomeasuredialog.c  view.h

HTH

Richard


>         address@hidden ~/dev/denemo/src]$ 
>         
>         
>         
>         2014-02-28 11:16 GMT+01:00 Éloi Rivard <address@hidden>:
>         
>                 Well, drawing the display is one category for sure.
>                 And "backends" is
>                 
>                         not a good name for something that has to do
>                         with playing - the main
>                         sort of backend in Denemo is not listed - the
>                         creation of the finished
>                         score for printing, printview.c I guess. 
>                         
>                         There are also the sourceaudio and
>                         source-something-I-forget-what that
>                         open things you are using to create the score
>                         from - a pdf of a
>                         manuscript, or an audio or midi track.
>                         
>                         And then there is the stuff (also "sources" of
>                         a sort) for getting MIDI
>                         in and Audio In.
>                         
>                         
>                 Then why not:
>                 
>                 src/
>                  - generated/ This one already exists
>                  - import/ Sources related to file import (midi,
>                 musicxml, .denemo)
>                  - export/ Sources related to file export (lilypond,
>                 midi, xml, tab, pdf, png etc.)
>                 
>                  - audio/ Sources related to audio backends (alsa,
>                 portmidi, portaudio, fluidsynth, jack etc.)
>                 
>                  - ui/ Sources related to dialogs (command center,
>                 preferences, dialogs, palettes etc.)
>                  - scripting/ Sources related to scheme and scheme
>                 callbacks
>                  - core/ Others general sources (utils, main, commands
>                 loading etc.)
>                 
>                  - render/ Sources related to printing (printview.c
>                 etc.)
>                 
>                  - source/ Sources related to music import (audio,
>                 midi, pdf, etc.)
>                 
>                  
>                 
>                         
>                         >What do you think ?
>                         
>                         
>                         Well, unless I learnt some new commands, it
>                         would slow up my work. When
>                         I want to find which file has a function
>                         definition in it I type grep
>                         functionname src/*.h (there is a horrible
>                         drawingprims.h which defeats
>                         this :( ) and then I only have one place where
>                         I need to open the file
>                         from. Are you using some IDE to do this sort
>                         of thing? If you *do* have
>                         an IDE then I guess you never know where the
>                         files are anyway (?)
>                         
>                         
>                 Well I use Anjuta sometimes, Gedit some other times.
>                 What is your text editors ? Do you know ctags ?
>                 
>                 You also may want to play with a few grep options.
>                 Grep can recursively search in a directory (-R) and
>                 filter some file names (--include). For example, if
>                 you want to search "print" in .h files, just type:
>                 
>                  grep -R --include *.h print src
>                 
>                 You also may create an alias for this to go faster.
>                 
>                 Would your work still be slowed with that command ?
>                 
>                 
>                         Perhaps first might be rationalizing the
>                         distribution of code in the
>                         files - commandfuncs.c is the worst offender,
>                         whoever created that was
>                         thinking of organizing in the opposite way to
>                         the person who created
>                         staffops.c measureops.c, lilydirectives.c etc.
>                         And I think view.c still
>                         contains all the code to do with creating and
>                         following rhythmic
>                         patterns (my fault that). And utils.c is
>                         another howler - at one time,
>                         early on, it was being used for common
>                         elements of the display-drawing
>                         code, but it more properly has stuff that
>                         various other departments of
>                         the code might use.
>                 
>                 
>                 I believe that dividing sources in several
>                 subdirectories is a good start actually. Directories
>                 reflect the architecture of the program. It would be
>                 easy to know that something is wrong if you find some
>                 "scripting" functions in the "import" directory for
>                 instance.
>                 
>         
>         
>         
>         -- 
>         Éloi Rivard - address@hidden
>                 
>         « On perd plus à être indécis qu'à se tromper. »
>         
> 
> 
> 
> -- 
> Éloi Rivard - address@hidden
>         
> « On perd plus à être indécis qu'à se tromper. »
>