Re: [Denemo-devel] Source directory

[Richard Shann]

On Sun, 2014-03-02 at 15:09 +0100, Éloi Rivard wrote:
>         
>         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.
> If some features are used in several "software bricks", maybe we can
> move them to "core" as they are a bit abstract. What piece of code do
> you mean ? 
I think it might be ringbuffer.* perhaps also jackutil.* and
eventqueue.* I'm not too clear on this stuff as I didn't write it.

> 
> 
>         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.
> 
> 
> Ok, maybe this one should be split.
> 
> 
>         >          kbd-custom.c  keyboard.c  keymapio.c
>         
>         these are to do with keyboard shortcuts, and belong with
>         keyresponses.c,h I would think
>  
> I think "command" should only contains functions that edit the score,
> shortcuts management would probably be a core thing
> 
>         >         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) 
> 
> 
> Maybe "file" would fit better then, as sources here deals with file
> import and export.

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.

> 
> 
> processstaffname.c is some sort of staffops.c I think.
>  
>         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.
> 
> 
> There is also a lot of features in denemo that is not directly related
> to the user inteface (audio management, file management, scheme
> things, etc.) Good software architectures generally separate (even
> sometimes isolate) their ui interface. Functions that edit the model
> (the partition in our case) should generally be separated from
> functions that dialogs with the user (dialogs etc.), even if they
> "communicate".

yes, as usual the problem here is that many of those things called
"dialog" are also the code that constructs the data and also accesses
the data (so the insert a time signature dialog code is also being used
to query a time signature object); for clarity the different aspects
need splitting up and then they can be assigned to different
directories.


>  
> 
>         
>         >           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
>         
>         
> "ui" does not fit here ? You though about "core" instead ?

yes.

> 
>  
> 
> 
> So, now it would look lik this:
> 
>         address@hidden ~/dev/denemo/src]$ ls *
>         instruments.xml  Makefile.am  Makefile.in  pathconfig.h
>         README.md
>         
>         audio:
>         alsabackend.c  audiointerface.c  dummybackend.h  fluid.c
>         instrumentname.h  jackutil.c  midi.h              pitchentry.c
>         pitchrecog.h  portaudiobackend.c  portaudioutil.h
>         portmidiutil.c  ringbuffer.h
>         alsabackend.h  audiointerface.h  eventqueue.c    fluid.h
>         jackbackend.c     jackutil.h  parseinstruments.c  pitchentry.h
>         playback.c    portaudiobackend.h  portmidibackend.c
>         portmidiutil.h
>         audio.h        dummybackend.c    eventqueue.h
>         instrumentname.c  jackbackend.h     midi.c
>         parseinstruments.h  pitchrecog.c  playback.h
>         portaudioutil.c     portmidibackend.h  ringbuffer.c
>         
>         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

>          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.

>           slurs.ct
>         calculatepositions.c

you have the header for this in core. The calculations are just being
done for the display so they could go there, although they are not being
done during the draw callback on the scorearea widget... 

>           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.

>         
>         generated:
>         entries.h  register_commands.h  scheme_cb.h  scheme.h
>         xml.fragment
>         
>         input:
>         audiocapture.c  audiocapture.h  sourceaudio.c  sourceaudio.h
>         source.c  source.h
>         
>         scripting:
>         lilydirectives.c  lilydirectives.h

these two are not scripting, just that since their introduction most
work has been scripted and so it seems they always get used by scripts.
They are just objects like CHORDs STEMDIRs, TUPOPENs etc... this puts
them in your "command" section above, once you have gathered all the
things like measureops, scoreops ... together - all things that
create/edit the actual denemo music data.

>           scheme-callbacks.c  scheme-callbacks.h  scheme-identifiers.c
>         scheme-identifiers.h
>         
>         ui:
>         clefdialog.c  help.c  kbd-interface.c  keysigdialog.c
>         mousing.c  moveviewport.c  mwidthdialog.c  palettes.h
>         palettestorage.h  playbackprops.h  scoreprops.c
scoreprops.c is (IIRC) like measureops, chordops ...
>                texteditors.c  timedialog.c       view.h
>         dialogs.h     help.h  kbd-interface.h  keysigdialog.h
>         mousing.h  moveviewport.h  palettes.c      palettestorage.c
as before
>           playbackprops.c   prefdialog.c     staffpropdialog.c
>         texteditors.h  tomeasuredialog.c
>         address@hidden ~/dev/denemo/src]
> 
> 
> Is it better ? 

:)

Richard