When clicking in Start Page, on link open books a gtk-warning message is displayed on the console.
See issue #50

Tracing the code, it is something that happens before control arrives to LenMus code, so it might be something related to wxWidgets. Needs investigation

I've recently packaged lenmus in nixos and noticed that some pngs fail to open and even throw exceptions.
For instance, when opening Music Reading Level 1, cc-by-sa.png fails to open and the following error shows:
Line 0. Error loading image. Non-standard unknown exception
in the shell, the following also appears:

(lenmus:23951): Gtk-WARNING **: Unable to show 'Open the music books': Operation not supported
Non-standard unknown exception (catch in ImageReader::load_image)

The strange thing is that it only happens with some images: In the same book, under The Tempo and Metronome page, the metronome_image.png image loads fine.

Anyhow, it's probably related to the package or some dependency. But I figured I'd report it just-in-case this is a known issue or something similar.

LenMus help files contains an embedded copy of two JavaScript libraries:

• locale/en/help/_static/jquery.js
• locale/en/help/_static/underscore.js

These JavaScript code is now available in their own packages:

• libjs-jquery
• libjs-underscore

It is necessary to change this by depending on these packages and modifying and modifying the HTML header of help pages.

The libjs-jquery package contains /usr/share/doc/libjs-jquery/README.Debian which explains how to use the provided jQuery in your web site. Basically, all it takes is:

See:
http://stackoverflow.com/questions/26704564/how-to-use-libjs-jquery-debian-package-in-a-project

¿What to do for Windows or other platforms?

As per subject.
I took the liberty of nicking this one:

from the official website and scaled it down for a few resolutions, but a svg one would be the ideal thing here.

Is it available?

Lintian complains about distributing these standard fonts:

usr/share/lenmus/5.4.1/res/fonts/LiberationSans-Bold.ttf also in ttf-liberation
usr/share/lenmus/5.4.1/res/fonts/LiberationSans-BoldItalic.ttf also in ttf-liberation
usr/share/lenmus/5.4.1/res/fonts/LiberationSans-Italic.ttf also in ttf-liberation
usr/share/lenmus/5.4.1/res/fonts/LiberationSans-Regular.ttf also in ttf-liberation
usr/share/lenmus/5.4.1/res/fonts/LiberationSerif-Bold.ttf also in ttf-liberation
usr/share/lenmus/5.4.1/res/fonts/LiberationSerif-BoldItalic.ttf also in ttf-liberation
usr/share/lenmus/5.4.1/res/fonts/LiberationSerif-Italic.ttf also in ttf-liberation
usr/share/lenmus/5.4.1/res/fonts/LiberationSerif-Regular.ttf also in ttf-liberation

I agree that this must be avoided but for now it is necessary. It is something imposed by lomse library that should be fixed but until them must be maintained in lenmus. Perhaps for now the solution is to create a package (lenmus-fonts) just to distribute these fonts and the one mentioned in issue #49

The problem is that Lomse requires these fonts and as Lomse is platform independent, the fonts are distributed with Lomse. To avoid this:

• the user application (e.g. lenmus) should inform lomse about font paths. In Linux we can use FontConfig library for finding a font (https://www.freedesktop.org/wiki/Software/fontconfig/)
• But, in any case, for platforms different from linux, Liberation fonts could be not present and a fallback mechanism in lomse will be necessary for replacing a font for another. And this would be a lot of platform dependent code.

As, finally, there is no way to avoid platform dependent code in lomse, we could package this code in platform dependent lomse modules:

• for dealing with fonts
• for dealing with sound (see comments in issue #9)

• Finish syllabus
• Finish lesson 5
• Review and finish lesson 2
• lessons 3, 4

From this point, go lesson by lesson

It was requested, time ago, that exercises be displayed in full screen mode. Can be usefull for projecting exercises in class or when using small screens

The following source files refer to the GFDL:

langtool/locale/es/GeneralExercises_es.po 
langtool/locale/es/L2_MusicReading_es.po 
langtool/locale/eu/GeneralExercises_eu.po 
langtool/locale/eu/L1_MusicReading_eu.po 
langtool/locale/eu/L2_MusicReading_eu.po 
langtool/locale/eu/TheoryHarmony_eu.po 
langtool/locale/fr/GeneralExercises_fr.po 
langtool/locale/fr/L2_MusicReading_fr.po 
langtool/locale/gl_ES/GeneralExercises_gl_ES.po 
langtool/locale/gl_ES/L2_MusicReading_gl_ES.po 
langtool/locale/it/GeneralExercises_it.po 
langtool/locale/it/L2_MusicReading_it.po 
langtool/locale/nl/GeneralExercises_nl.po 
langtool/locale/nl/L2_MusicReading_nl.po 
langtool/locale/zh_CN/L2_MusicReading_zh_CN.po 

But they use a non-official text for the "no invariant sections" part. The non-official used text is:
"with no invariant sections, with no front-cover texts, and with no back-cover texts"

Lintian asks to always use (case insensitive):
"with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts."

It could be interesting to have a man page for lenmus

Lintian give a warning for this:
W: lenmus: binary-without-manpage usr/bin/lenmus

Different versions of Phonascus. Not necessarily with the same format and interface. Not necessarily with the same code base. But all using the same codebase:

• Mac OS X
• Tablets and smartphones
• Possible HTML5 web version

Mac version

We have to get a version for Apple (Mac OS X computers). This, in principle, is quick and easy, since the current software is ready. You just have to compile it on that platform and solve specific problems that may arise. But from my experience in other migrations, it will take more than a month of work as unexpected issues will arise.

Version for tablets / smartphones

Users are moving to tablets and smartphones. Often students come to class with a tablet and the number of users buying PCs is decreasing. But there is no Android version of LenMus and it is urgent to prepare it. A version for tablets will help to evaluate and solve problems and functionalities for data input or via touch stylus.

• Handwriting recognition, to write scores. Integration with handwriting recognition software. Ability to write scores and texts with pencil on a touchscreen.
• Touch keyboard. Exercises playing with the hand on a keyboard or virtual mast.

The tablet version is a hard work that will take many months, as the framework used in LenMus (wxWidgets, http://www.wxwidgets.org/) does not yet support tablets. Therefore, we should move to Qt (http://qt-project.org/).

HTML5 version

Would facilitate access to exercises in web pages. The first step could be writing a renderer for Lomse that generates SVG. It should not be difficult.

In Linux LenMus installation and defaults must follow the XDG Base Directory Specification
(http://standards.freedesktop.org/basedir-spec/latest/).

We must improve and maintain the packages generation and to develop a Windows installer.

It is necessary to promote LenMus in Debian, so that LenMus become a standard package in Debian. This would open the door for standard inclusion in other distros. And this could also generate interest to attract more developers. See #4.

Basically we have to work on Debian (.deb) and Red Hat (.rpm) packages. And automate the process of generating these packages to systematically generate them when LenMus repositories are updated. It would be nice if someone with good knowledge in making Linux packages for the most common distributions could join the project.

When a version for Apple is ready, it will be necessary to prepare also an installer for that platform.

And we must maintain the Windows version and enhance the installer.

• Many people have demanded the possibility of generating sound via virtual instruments (VST plug-ins).
• Management of audio streams, for integration with other systems: JACK interface.

Currently, MIDI output is just a direct connection to the graphic card. The problem is that, in consumer PCs, generated sound quality is not good enough for more advanced ear training exercises. In addition, teachers who are musicians, often have a very educated and sensitive ear for the quality of sound and dislike the sound created this way.

My thoughts:

After some analysis, I have come to two conclusions:

1. I think the best approach is to include a JACK interface in LenMus. JACK (http://jackaudio.org/) is the de facto standard for interconnection audio applications and systems in the Linux world, and it is also available for MS Windows. By providing this support in LenMus, users can redirect the generated MIDI flow to any other application or device, allowing the use of MIDI software synthesizers capable of generating better quality of sound, or to send MIDI you to other better sources of sound, perhaps hardware.
2. An interface for VST virtual instruments could be studied and programmed. But not sure if it is worth the work because VST is a proprietary specification from Steinberg and only distribute the SDK for Windows and Apple. Moreover, there is free software for using VST devices with JACK input. Therefore, if LenMus could offer a JACK interface the development of a VST interface would not be required. A direct VST interface would be useful mainly for Windows users who do not want to install JACK. My conclusion is to discard the development of an VST interface.

In conclusion, developing a JACK interface will solve the problem.

This is a task that can be completed in short time and that, practically, it does not requires any knowledge about LenMus internals.

• enable/disable tabs: page selector must hide items that cannot be selected for current toolbox configuration.
• change note duration numbers to that of Finale & MuseScore.
• remove tool group for selecting note or rest.
• Document: "How EditInterface mode is selected and changed" in lenmus/trunk/docs/en/hacking/toolbox.txt.
• colors for tabs
• problem with GIMP generated png images: http://trac.wxwidgets.org/ticket/3019

Hello, first of all thank you for taking the time to develop LenMus in your free time. Some time ago I have requested LenMus Phonascus to be added to the repositories of my main operating system, Solus: https://dev.solus-project.com/T1074
Currently, the issue is on hold due to technical issues in getting it to build. Do you already know when you will be able to release the next version?

Not confirmed. I think it is already fixed but I have to check.

It was caused because Lomse throws an exception but it is not handled in LenMus
See: DocumentWindow::display_document(const string& filename, int viewType)

This task originated with issue #33.

After some tests to create an script using 'aspell' check speller, I found it is not a simple task. It is easy to create a simple script but the output from the script is just a list of misspelled words and the name of the file in which these words are found. But:

• To get the line, the file must be processed line by line.
• And the list of misspelled words contains a lot of keywords used in scores written in LDP or MusicXML. Preparing a useful script would imply a lot of work to create a user dictionary for filtering out all these keyworks.

As once a lesson is written it is rarely modified, it is more practical to check spelling on a file each time the file is modified.

Nevertheless, as part of quality assurance procedures, it would be nice to have an script that could raise a red flag when spelling errors in a .pot file. This will help to locate the file in which the error is present and fix it before committing the file.

With the move to Git, revision number is useless and can be provided by git. So move to this:

{major}.{minor}.{patch}-{sha1 hash} (i.e. 5.4.28-af23e47).

SHA1 hash will not be normally displayed.

It would be nice to get LenMus to be an standard package in Debian.

Include FluidSynth as a library and use it to produce sound from midi events. This will avoid having to use an external synthesizer (i.e. Timidity), which in turn will create less problems to users

Feedback, by email, from Jim Broderick (2015/Feb)

I found numerous erroneous examples in the text (v5.3):

• the chord progression I-VII-VI-V7 contains parallel 5ths between the bass and alto and the bass and soprano. In SATB style parallel 5ths and octaves are forbidden, among other things.
• example labeled II6/4 to V, that should be labeled I6/4 to V, or conforming to the more current way of expressing it V64-53.

In v5.4 exercises:

• many of the voicings contain improper doubling, direct octaves, etc.
• The voice leading of the cadential six-four is such that all of the upper voices should move in a downward motion-consider the 6-5 and 4-3 motion as a resolving suspended figure.
• Suspensions always resolve downward. I noticed an example of that did not move in this manner.

When playing with others you must learn to deal with errors. For practicing with LenMus, the program plays an score and I play my instrument. But if LenMus playback is always on tempo and well measured, I can not practice to deal with errors.

An option for introducing random errors of different nature could make the playback more realistic and more useful for practice.

The first time edition is enabled, the frame around the document is shifted.

• Add cover page to score wizard for choosing:
  a) Create just empty staff
  b) Chose instruments
  c) Chose a template for common ensembles
• Templates with groups of instruments

• Only one tile printed
• Black margins at left and bottom

But "menu > debug > Print preview" displays it correctly!

REMEMBER: For print tests, you can print to pdf file to avoid using paper

Not confirmed. Might be an occasional bug?

• Analysis of voice / signal in real time:
  • To evaluate student answers the system should be able to analyze, in real time, rhythm and / or pitch of the played music or the audio captured while singing a melody by the student. Would allow for exercises on singing in tune or music sight reading with the instrument.
  • Also to tune the instrument (diapason).
  • For automatic tracking of a score as is it is played by the student
• Input via MIDI, to write scores or to give answers to play exercises.
• Voice output (read scores / sing scores):
  • Playing back a score using MIDI commands is a relatively simple task. But to automatically solfege a score new techniques for speech synthesis are required. I know of no software that provides this functionality.

• Optimize website for smartphones (done. jun/2019)

• Someone to take responsibility for social networks
• Social management:
  • Presence in social networks
  • Management and web forums
• Promotion
  • Youtube videos. They also serve as tutorials use. Users can collaborate and send their videos.

I'm invoking cmake with -DCMAKE_USE_LOMSE_SOURCES=OFF but then I'm greeted with:

CMake Warning at CMakeLists.txt:317 (find_package):
  By not providing "FindLomse.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Lomse", but
  CMake did not find one.

  Could not find a package configuration file provided by "Lomse" (requested
  version 0.14) with any of the following names:

    LomseConfig.cmake
    lomse-config.cmake

Since neither lomse nor lenmus create or supply those files, I've had to patch CMakeLists.txt to use pkgconfig instead.

Am I doing something wrong?

Things needed for releasing the exercise:

• Edit Tools for rhythmic dictation
  • Disable ToolBox when edition is disabled
  • It should be always possible to replace a specific toolbox (i.e. rhythm dictation) by the main one
    (a button on toolbox title?)
• Generate problems:
  • define level 1 syllabus
  • define melody fragments, keys, time signatures
  • algorithm for deciding how many measures
  • algorithm for deciding how many fragments and assigning measures
    to fragments
  • implement any new requirement in Composer
• Other issues:
  • virtual keyboard?
  • mark clef, key and time signature as non-editable
  • In rhythm dictation (percussion clef), noteheads must be cross
  • cursor must skip non-editable objects
  • backerase generates two paint events: cursor back and delete note
  • config:
    • max num times play problem is allowed
    • midi instrument for playing problem score
    • number of measures (or fragments)
    • first measure initially displayed
    • context type
  • dialog for options
  • video to explain exercise and ToolBox use

There are several exercises that users have already sugessted and are not difficult to make. In general, to set up a new exercise is simple and fast (every exercise usually requires about two weeks, unless the exercise requires new infrastructure), but for coding a new exercise some knowledge of LenMus 'internals' is required. Therefore, this type of work is more suitable for potential developers who want to collaborate with LenMus, is it serves as training and serves to make contact and learn the inner workings.

• Exercises of rhythmic and melodic dictation. The exercise is already coded. But requires modifications to the composer of scores. (issues #24 & #23)
• Exercise of tuning. The idea is to present the student two successive tones and manipulate a control to make them the same pitch. When you think they are equal, hit the reply button and the program tells the deviation (in cents) between them. Preliminary tests using midi bend events have already taken place and is viable. Now it's just a question of start coding.

Later, when the editor is available, it wopuld be possible to address much more complex exercises, such as harmony exercises.

Other types of exercises:

• Exercises requiring to write scores (i.e. harmony exercises)
• Exercises to choose an answer

Current implementation is the Greedy Diff algorithm. Pending issues and improvements:

• Implement the optimizations described in original paper (linear space refinement)
• Improve method for displaying errors and corrections. Current method is just coloring the differences.

The score composer is an old piece of code. It is based on predefined melody fragments that are combined to generate a melody with as many measures as required. The fragments are strings, with notes and rest in LDP format. The current algorithm is used only to create scores for music reading exercises. But there are new needs:

• To generate scores with anacrux start.
• To generate scores oriented to melodic dictation.

Current algorithm is oriented to rhythm more than to harmony. It works in tow phases: first, it generates the rhythmic structure and in second phase it, basically, assigns pitch to the notes, according to a given chord progression. The algorithm should be improved for generating specific sequences of intervals, for creating scores better suited for melodic dictation.

It is caused by not including parameter k_no_draw in the three lines marked as //BUG_001.

But when including it a new problem happens: the view is not updated despite the fact that the bitmap is redrawn and copied to the DC. The curious thing is that the same sequence of intructions originated by any other action, does update the window! See log below.

After a couple of hours trying to find the cause, I give up.

This are the events from the log::

lenmus_document_canvas.cpp, line 1632. DEBUG: [lenmus::DocumentWindow::scroll_line]  ==> DOES NOT UPDATE WINDOW
lomse_interactor.cpp, line 718. DEBUG: [lomse::Interactor::new_viewport] 
lomse_graphic_view.cpp, line 157. DEBUG: [lomse::GraphicView::new_viewport] x=-23, y=-38
lenmus_document_canvas.cpp, line 1496. DEBUG: [lenmus::DocumentWindow::adjust_scrollbars] 
lenmus_document_canvas.cpp, line 1467. DEBUG: [lenmus::DocumentWindow::determine_scroll_space_size] 
lenmus_document_canvas.cpp, line 586. DEBUG: [lenmus::DocumentWindow::on_paint] 
lenmus_document_canvas.cpp, line 793. DEBUG: [lenmus::DocumentWindow::update_rendering_buffer] 
lomse_interactor.cpp, line 675. DEBUG: [lomse::Interactor::redraw_bitmap] 
lomse_graphic_view.cpp, line 180. DEBUG: [lomse::GraphicView::redraw_bitmap] 
lomse_graphic_view.cpp, line 248. DEBUG: [lomse::GraphicView::draw_all] 
lomse_graphic_view.cpp, line 337. DEBUG: [lomse::GraphicView::draw_graphic_model] 
lomse_graphic_view.cpp, line 390. DEBUG: [lomse::GraphicView::draw_all_visual_effects] 
lomse_overlays_generator.cpp, line 95. DEBUG: [lomse::OverlaysGenerator::update_all_visual_effects] efecto:0xa995808, 
lenmus_document_canvas.cpp, line 306. DEBUG: [lenmus::DocumentWindow::copy_buffer_on_dc] 
lenmus_document_canvas.cpp, line 331. DEBUG: [lenmus::DocumentWindow::copy_buffer_on_dc] gm=74.0 vf=14.0 render=88.0 paint=29.0 ms 

lomse_interactor.cpp, line 907. DEBUG: [lomse::Interactor::zoom_out]   ==> BUT THIS DOES UPDATE WINDOW
lomse_graphic_view.cpp, line 578. DEBUG: [lomse::GraphicView::zoom_out] 
lenmus_document_canvas.cpp, line 1496. DEBUG: [lenmus::DocumentWindow::adjust_scrollbars] 
lenmus_document_canvas.cpp, line 1467. DEBUG: [lenmus::DocumentWindow::determine_scroll_space_size] 
lenmus_document_canvas.cpp, line 586. DEBUG: [lenmus::DocumentWindow::on_paint] 
lenmus_document_canvas.cpp, line 793. DEBUG: [lenmus::DocumentWindow::update_rendering_buffer] 
lomse_interactor.cpp, line 675. DEBUG: [lomse::Interactor::redraw_bitmap] 
lomse_graphic_view.cpp, line 180. DEBUG: [lomse::GraphicView::redraw_bitmap] 
lomse_graphic_view.cpp, line 248. DEBUG: [lomse::GraphicView::draw_all] 
lomse_graphic_view.cpp, line 337. DEBUG: [lomse::GraphicView::draw_graphic_model] 
lomse_graphic_view.cpp, line 390. DEBUG: [lomse::GraphicView::draw_all_visual_effects] 
lomse_overlays_generator.cpp, line 95. DEBUG: [lomse::OverlaysGenerator::update_all_visual_effects] efecto:0xa995808, 
lenmus_document_canvas.cpp, line 306. DEBUG: [lenmus::DocumentWindow::copy_buffer_on_dc] 
lenmus_document_canvas.cpp, line 331. DEBUG: [lenmus::DocumentWindow::copy_buffer_on_dc] gm=85.0 vf=4.0 render=89.0 paint=20.0 ms 

It seems that it is necessary to explicitly select a source format, by putting the format in debian/source/format.

It seems that we should move the source format to "3.0 (quilt)" (for packages with a separate upstream tarball):

• Implications?
• What to change?

If there are reasons for not moving to 3.0 then:

• we should create the source/format file and put "1.0" in it to be explicit about the source package version.
• we should inform the dpkg maintainers at [email protected]. They are interested in hearing the (technical) reasons why the new formats do not suit us.

Refer to the dpkg-source(1) manual page and https://wiki.debian.org/Projects/DebSrc3.0 for details.

LenMus program handles plurals by having two different strings (i.e. "1 sharp" and "%d sharps"). Both strings are in PO files as two different, non-related strings. But after your question I've been reading and I have discovered that although my approach is ok, it is not ok how my program decides between both strings. Currently, the singular string will be used for n==1 and the plural for n>1. This corresponds to gettext rule "Plural-Forms: nplurals=2; plural=n != 1;"

Although this works for many languages I've learn that this is going to fail for Russian! . This link is very illustrative and explains how to proceed (I will have to review my code!):

http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-forms.html

Lintian complains about including this font:

usr/share/lenmus/5.4.1/res/fonts/Bravura.otf

This font is required by Lomse. A temporal solution could be to create a lenmus-font package with all the fonts required by lomse. See issue #48

• Direct modification of IM must be forbidden.
• Using edition commands forces to atomic updates. Facilities to inhibit updates until all related commands issued?

Context:
Bug 80201 shows that LenMus exercises violates some design rules (see document "drafts/presentation/How is renderization triggered.txt")

I try to compile lenmus on fedora 24 (gcc version 6.1.1).
During compilation, I meet the following error:

[  3%] Building CXX object CMakeFiles/lenmus.dir/src/app/lenmus_canvas.cpp.o
[  3%] Building CXX object CMakeFiles/lenmus.dir/src/app/lenmus_command_event_handler.cpp.o
/home/collette/repositories/lenmus/src/app/lenmus_command_event_handler.cpp: Dans la fonction membre ‘void lenmus::CommandEventHandler::process_command_event(lomse::SpEventCommand)’:
/home/collette/repositories/lenmus/src/app/lenmus_command_event_handler.cpp:401:77: erreur : no matching function for call to ‘static_pointer_cast(lomse::SpEventCommand&)’
                     boost::static_pointer_cast<EventControlPointMoved>(event) );
                                                                             ^
In file included from /usr/include/boost/shared_ptr.hpp:17:0,
                 from /home/collette/repositories/lenmus/lomse/trunk/include/lomse_ldp_elements.h:40,
                 from /home/collette/repositories/lenmus/lomse/trunk/include/lomse_ldp_factory.h:38,
                 from /home/collette/repositories/lenmus/lomse/trunk/include/lomse_injectors.h:33,
                 from /home/collette/repositories/lenmus/lomse/trunk/include/lomse_interactor.h:34,
                 from /home/collette/repositories/lenmus/include/lenmus_tool_group.h:25,
                 from /home/collette/repositories/lenmus/include/lenmus_tool_box.h:26,
                 from /home/collette/repositories/lenmus/include/lenmus_command_event_handler.h:26,
                 from /home/collette/repositories/lenmus/src/app/lenmus_command_event_handler.cpp:22:
/usr/include/boost/smart_ptr/shared_ptr.hpp:828:42: note : candidate: template<class T, class U> boost::shared_ptr<X> boost::static_pointer_cast(const boost::shared_ptr<U>&)
 template<class T, class U> shared_ptr<T> static_pointer_cast( shared_ptr<U> const & r ) BOOST_NOEXCEPT
                                          ^~~~~~~~~~~~~~~~~~~
/usr/include/boost/smart_ptr/shared_ptr.hpp:828:42: note :   template argument deduction/substitution failed:
/home/collette/repositories/lenmus/src/app/lenmus_command_event_handler.cpp:401:77: note :   ‘lomse::SpEventCommand {aka std::shared_ptr<lomse::EventCommand>}’ is not derived from ‘const boost::shared_ptr<U>’
                     boost::static_pointer_cast<EventControlPointMoved>(event) );
                                                                             ^
CMakeFiles/lenmus.dir/build.make:182 : la recette pour la cible « CMakeFiles/lenmus.dir/src/app/lenmus_command_event_handler.cpp.o » a échouée
make[2]: *** [CMakeFiles/lenmus.dir/src/app/lenmus_command_event_handler.cpp.o] Erreur 1
CMakeFiles/Makefile2:99 : la recette pour la cible « CMakeFiles/lenmus.dir/all » a échouée

Lintian complains about including the following files in source package:

xrc/wxrc.exe
packages/wxMidi/lib/pm/pm_dll.dll
packages/wxMidi/lib/pm/pm_dll.exp
packages/wxMidi/lib/pmd/pm_dll.dll
packages/wxMidi/lib/pmd/pm_dll.exp
packages/wxSQLite3/sqlite3/lib/sqlite3.dll
packages/wxSQLite3/sqlite3/lib/sqlite3.exp

Lintian is right. Investigate how the source package is created and fix this.

For better control and options of play back, it would be nice to have a Play Panel from
which to have full control of play back: loops, tempo, volume, start measure, end measure, etc.:

• User should be able to:
  • set measure/bar by entering the numbers
  • set time (h:mm:ss) by entering the numbers
  • set tempo by entering the numbers
  • set volume by entering the numbers
  • select a range of notes and play them in loop

The Play Panel settings must be saved in the score, as metadata (issue #13), so that next time the score is open the play back options are properly set (tempo, loop, volume, etc.)

Near the botton of 6. Time signatures it says "But remember that rhythm is something natural that exists by itsel in the music."

Lintian complains about the amount of shared data (over 4MB, or over 2MB and more than 50% of the package, in /usr/share).

Solution:
Analyse shared data and decide if ignore this or create a new package for shared data.

Error explanation (lintian)

The package has a significant amount of architecture-independent data (over 4MB, or over 2MB and more than 50% of the package) in /usr/share but is an architecture-dependent package. This is wasteful of mirror space and bandwidth since it means distributing multiple copies of this data, one for each architecture.

If the data in /usr/share is not architecture-independent, this is a Policy violation that should be fixed by moving the data elsewhere (usually /usr/lib).

Better explanation

https://www.debian.org/doc/manuals/developers-reference/ch06.html#bpp-archindepdata

6.7.5. Architecture-independent data

It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package.

However, if the size of the data is considerable, consider splitting it out into a separate, architecture-independent package (_all.deb). By doing this, you avoid needless duplication of the same data into eleven or more .debs, one per each architecture. While this adds some extra overhead into the Packages files, it saves a lot of disk space on Debian mirrors. Separating out architecture-independent data also reduces processing time of lintian (see Section A.2, “Package lint tools”) when run over the entire Debian archive.

See attached gdb backtrace.
lenmus_backtrace.txt

That's probably not nearly enough information, but please tell me if I need to run other
tests or compile with special switches.

Fixing this is simple? Just adding a file in debian directory pointing to lenmus repo at GitHub?

See:
https://wiki.debian.org/debian/watch

Some relevant settings in the GUI for an score (auxiliary windows that are open --Play Panel, Mixer Panel -- and their settings) should be saved in the score, as metadata, so that the next time the score is open these auxiliary windows and their settings be available.

• Instrument group is neither supported in LDP 2.0 nor in Lomse.
• Perhaps new LDP definition, similar to that of MusicXML? Groups are fully supported since PR#49 for sources in MusicXML and LMD.

The following templates fail:

brass_quintet.lms
brass_trio.lms
choir_SATB.lms
choir_SATB_piano.lms
choir_SSA.lms
choir_SSA_piano.lms
string_quartet.lms
woodwind_quintet.lms
woodwind_trio.lms

• Design the layout. Probably need to have SVG paths (lenmus/lomse#12).
• Investigate how to control volume

• Determine real tempo by taps on spacebar: take average instead of measuring just from previous tap.
• Add visual effects? Similar to GTick?, Graphical metronome?

Lintian says that the source tarball contains prebuilt Sphinx documentation, in particular in files:

locale/en/help/
locale/es/help/

Lintian says that this is usually left by mistake when generating the tarball without first cleaning the source directory. It is preferable to rebuild documentation directly from source.

Investigate this issue:

• Should source tarball include pre-build documentation?
  • Probably yes, unless it can be easily build. In any case, it is useless and a waist of resources to rebuild documentation each time the package is built (i.e. Travis)
  • And by consistency, the same criteria should be applied to eBooks, or to icons generated from SVG code. Everything that is built from other sources must be removed from a source tarball? Crazy. I vote for including pre-built documentation as well as pre-built eBooks, unless documentation and eBooks are moved to other packages.
• Can use CMake for generating this documentation from sources? How?