> > 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 ?
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. 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". > > > 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 ? So, now it would look lik this: [azmeuk@herbi ~/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 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 slurs.ct > calculatepositions.c 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 > > 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 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 texteditors.c timedialog.c view.h > dialogs.h help.h kbd-interface.h keysigdialog.h mousing.h > moveviewport.h palettes.c palettestorage.c playbackprops.c > prefdialog.c staffpropdialog.c texteditors.h tomeasuredialog.c > [azmeuk@herbi ~/dev/denemo/src] > Is it better ?
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
