denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Source directory


From: Éloi Rivard
Subject: Re: [Denemo-devel] Source directory
Date: Fri, 28 Feb 2014 20:51:28 +0100

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

command:
barline.c  bookmarks.c  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  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  kbd-custom.c  keyboard.c  keymapio.c  main.c              parseinstruments.h  prefops.h  utils.c
binreloc.h  external.c      http.c      instrumentname.c  instruments.xml   kbd-custom.h  keyboard.h  keymapio.h  parseinstruments.c  prefops.c           twoints.h  utils.h

generated:
entries.h  register_commands.h  scheme_cb.h  scheme.h  xml.fragment

io:
audiofile.c  exportabc.c  exportlilypond.c  exportmidi.c  exportxml.c  file.c  guidedimportmidi.c  importmidi.c  importmusicxml.c  importxml.c  print.c  processstaffname.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  processstaffname.h  screenshot.h

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

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

ui:
clefdialog.c  help.c  kbd-interface.c  keysigdialog.c  mousing.c  mwidthdialog.c  palettes.h        palettestorage.h  playbackprops.h  scorelayout.c  scoreprops.c       texteditors.c  timedialog.c       view.c
dialogs.h     help.h  kbd-interface.h  keysigdialog.h  mousing.h  palettes.c      palettestorage.c  playbackprops.c   prefdialog.c     scorelayout.h  staffpropdialog.c  texteditors.h  tomeasuredialog.c  view.h
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. »

reply via email to

[Prev in Thread] Current Thread [Next in Thread]