Richard Shann | 4 May 2012 10:35
Favicon

Re: Release 0.9.4 code freeze (was Re: LilyPond import (and MusicXML import - midi import as well?))

I haven't come across any serious bugs in master for the period of the
freeze so we could try for a new release candidate if you have the time
Jeremiah.
Richard

On Thu, 2012-04-26 at 11:22 -0500, Jeremiah Benham wrote:
> On 04/26/2012 10:44 AM, Richard Shann wrote:
> > Jeremiah,
> > Looking at your check-in to denemo/gub a couple of things I notice
> > In evince.py I see this line
> > 10                            #+ ' --with-libintl-prefix=%(system_prefix)s'
> 
> This is commented out. I will try uncommenting it. I am very new to this 
> stuff. Nope, still getting the same error after compiling it now.
> 
> Jeremiah
> >
> > I wonder what the character 's' is doing after the system_prefix??? I
> > guess it has a special meaning as I see in denemo.py you have another
> >
> > + self.system ('cd %(builddir)s/src&&  make lylexer.c')
> >
> > here, I wonder what the reference to make lylexer.c is??? We dropped
> > that file ages ago when we moved to the scheme parser for lilypond.
> > (I guess the %....s is some syntax for a replacement???)
> >
> > Richard
> >
> >
> >
(Continue reading)

Richard Shann | 7 May 2012 16:11
Favicon

Re: Release 0.9.4 code freeze (was Re: LilyPond import (and MusicXML import - midi import as well?))

Jeremiah - I notice you have created a new release candidate in
denemo.org/downloads, is it ready for testing - shall I announce it?
Richard

On Fri, 2012-05-04 at 09:35 +0100, Richard Shann wrote:
> I haven't come across any serious bugs in master for the period of the
> freeze so we could try for a new release candidate if you have the time
> Jeremiah.
> Richard
> 
> 
> On Thu, 2012-04-26 at 11:22 -0500, Jeremiah Benham wrote:
> > On 04/26/2012 10:44 AM, Richard Shann wrote:
> > > Jeremiah,
> > > Looking at your check-in to denemo/gub a couple of things I notice
> > > In evince.py I see this line
> > > 10                            #+ ' --with-libintl-prefix=%(system_prefix)s'
> > 
> > This is commented out. I will try uncommenting it. I am very new to this 
> > stuff. Nope, still getting the same error after compiling it now.
> > 
> > Jeremiah
> > >
> > > I wonder what the character 's' is doing after the system_prefix??? I
> > > guess it has a special meaning as I see in denemo.py you have another
> > >
> > > + self.system ('cd %(builddir)s/src&&  make lylexer.c')
> > >
> > > here, I wonder what the reference to make lylexer.c is??? We dropped
> > > that file ages ago when we moved to the scheme parser for lilypond.
(Continue reading)

Jeremiah Benham | 7 May 2012 19:29

Re: Release 0.9.4 code freeze (was Re: LilyPond import (and MusicXML import - midi import as well?))

Yes. go ahead. Test away.

Jeremiah

Sent from my Samsung smartphone on AT&T

Richard Shann <richard.shann@...> wrote:

>Jeremiah - I notice you have created a new release candidate in
>denemo.org/downloads, is it ready for testing - shall I announce it?
>Richard
>
>
>On Fri, 2012-05-04 at 09:35 +0100, Richard Shann wrote:
>> I haven't come across any serious bugs in master for the period of the
>> freeze so we could try for a new release candidate if you have the time
>> Jeremiah.
>> Richard
>> 
>> 
>> On Thu, 2012-04-26 at 11:22 -0500, Jeremiah Benham wrote:
>> > On 04/26/2012 10:44 AM, Richard Shann wrote:
>> > > Jeremiah,
>> > > Looking at your check-in to denemo/gub a couple of things I notice
>> > > In evince.py I see this line
>> > > 10                            #+ ' --with-libintl-prefix=%(system_prefix)s'
>> > 
>> > This is commented out. I will try uncommenting it. I am very new to this 
>> > stuff. Nope, still getting the same error after compiling it now.
>> > 
(Continue reading)

Éloi Rivard | 8 May 2012 16:49
Picon
Gravatar

Denemo user interface

Hello.
First of all congratulations for making Denemo, gtk wysiwyg partition editor are rare and denemo is the more complete I've seen. I wish Gnome had a reference partition editor, and denemo has the potential to be this, but I've noticed some defects.

I think the main denemo defect is its unfriendly and non-intuitive interface. I don't know the Gnome Human Interface Guidelines by heart, by I could notice several ergonomic aberrations, like:

  • Detachable menus (if you have to see permanently the content of a menu, then the content belong to a tool bar) and floating toolbars (Articulation).
  • The "title" button being the only button on its line. Does "create snippet" and "delete snippet" deserve a whole line too ?
  • The overcrowded preference panels.
  • The unfixed "tempo" and "volume" sliders lenght.
  • Text in buttons where it can be expressive icons (For example Loop).
  • Shortcuts are not aligned on the right in menus, and they are blue.
  • Tiny buttons ( like # ), it's hard to click on it !
Why distinguishing notes from rests ? You could divide the number of buttons with "duration" buttons plus one to toggle rest and note mode. Why is there two note bars ("notes and rest entry" and "Title, button, etc") instead of one ?

I'm sure there are reason behind all those points, but they shocked me at first sight. I made an approximately drawing of how I wish denemo could be.



Here, everything that is often used is displayed on the top tool bars, everything that is occasionally used is displayed on the right tool bars. Menu and hidden windows are strictly reserved for rarely used stuffs. Everything that can be illustrated have an icon.

There are interesting UI ideas in other programs. Gimp (2.8) and Inkscape for instance manage well the large number of tools. Noteworthy is very clean for instance.

Also I think denemo should be translated in order to be used by more people. (More people gets more bug reports :) ). And maybe denemo should get a stronger graphical identity (for instance, the icon look like a 90's program icon :).

I hope my critical are constructive and give you some ideas about design. Also if my English is not clear, don't hesitate to make me explain a point.

Eloi
--
Éloi Rivard - azmeuk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
       
« On perd plus à être indécis qu'à se tromper. »

_______________________________________________
Denemo-devel mailing list
Denemo-devel@...
https://lists.gnu.org/mailman/listinfo/denemo-devel
Richard Shann | 8 May 2012 18:25
Favicon

Re: Denemo user interface

On Tue, 2012-05-08 at 16:49 +0200, Éloi Rivard wrote:
> Hello.
> First of all congratulations for making Denemo, gtk wysiwyg
Denemo is not wysiwyg. It displays the music only well enough to allow
you to see what your music is. The output (ie what you get) is typeset
by LilyPond which takes many minutes to do, which makes wysiwyg
impractical, except for simple music cases, which other programs can do.
>  partition editor are rare and denemo is the more complete I've seen.
> I wish Gnome had a reference partition editor, and denemo has the
> potential to be this, but I've noticed some defects.
> 
> I think the main denemo defect is its unfriendly and non-intuitive
A lot of people feel this way about the interface, and I hope one day
someone will write another one (although I might not like to use it).
>  interface. I don't know the Gnome Human Interface Guidelines by
> heart, by I could notice several ergonomic aberrations, like:
>       * Detachable menus (if you have to see permanently the content
>         of a menu, then the content belong to a tool bar) and floating
>         toolbars (Articulation).
Detachable menus are not permanently on view. I use them occasionally,
if I am doing work in one particular area (say, Voices).

>       * The "title" button being the only button on its line.
That line can be populated with any menu items you like (right-click the
menu item and choose "place command on button bar" - the idea is (or
was) to allow the user to create a series of custom toolbars.

>       *  Does "create snippet" and "delete snippet" deserve a whole
>         line too ?
yes, when you create a snippet it appears as a button on this line, from
where you can use the snippet.
>       * The overcrowded preference panels.
>       * The unfixed "tempo" and "volume" sliders lenght.
>       * Text in buttons where it can be expressive icons (For example
>         Loop).
yes, that might be nice, though I notice that I prefer text to icons,
*especially* when the icons all change when I do an upgrade of the o/s
(that is something that really slows me down, recognizing some new set
of icons that someone has decided is better than the old ones).
>       * Shortcuts are not aligned on the right in menus, and they are
>         blue.
Yes, they are a custom implementation of the short cut mechanism to
allow the user interface more flexibility than the built-in ones permit.
>       * Tiny buttons ( like # ), it's hard to click on it !
Set the font size in the preferences menu (those are not icons, but font
glyphs).
> Why distinguishing notes from rests ? You could divide the number of
> buttons with "duration" buttons plus one to toggle rest and note mode.
> Why is there two note bars ("notes and rest entry" and "Title, button,
> etc") instead of one ?
As I mentioned above I planned to allow as many as you wish - in fact
there is another one already which holds Movement Title etc, but it
doesn't appear until you set something on it.
> 
> I'm sure there are reason behind all those points, but they shocked me
> at first sight. I made an approximately drawing of how I wish denemo
> could be.
Your image shows only a small horizontal area devoted to displaying the
music. This would not be practical for entering large amounts of music
(hundreds of bars of music) as you can only see a little bit at a time
and can lose your place. However, Denemo does have a feature that would
allow such a layout - if you press Esc it takes you to a mode where all
the menus are suppressed, and in this way you can work on the score
taking up as much of the screen as you need.
> 
> Images intégrées 1
> 
> Here, everything that is often used
Different users have different sets of "often used" items. I have the
figured bass items on my toolbar, but nothing for dynamics. That would
not be popular :)
>  is displayed on the top tool bars, everything that is occasionally
> used is displayed on the right tool bars. Menu and hidden windows are
> strictly reserved for rarely used stuffs. Everything that can be
> illustrated have an icon.
> 
> There are interesting UI ideas in other programs. Gimp (2.8) and
> Inkscape for instance manage well the large number of tools.
> Noteworthy is very clean for instance.
> 
> Also I think denemo should be translated
This is a big undertaking.
>  in order to be used by more people. (More people gets more bug
> reports :) ). And maybe denemo should get a stronger graphical
> identity (for instance, the icon look like a 90's program icon :).
> 
> I hope my critical are constructive and give you some ideas about
> design.
Yes, very constructive, thank you. I hope someone with an interest in a
graphical approach to the program will take this up. Denemo has never
been used from the mouse, it is primarily a keyboard program - you enter
music using the numeric keypad and a MIDI keyboard, it is several
hundred times faster than mouse methods.

Richard

>  Also if my English is not clear, don't hesitate to make me explain a
> point.
> 
> Eloi
> -- 
> Éloi Rivard - azmeuk <at> gmail.com
>         
> « On perd plus à être indécis qu'à se tromper. »
> 
> _______________________________________________
> Denemo-devel mailing list
> Denemo-devel <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/denemo-devel

_______________________________________________
Denemo-devel mailing list
Denemo-devel <at> gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel
Éloi Rivard | 9 May 2012 20:19
Picon
Gravatar

Re: Denemo user interface

My thought is that a program should support both mouse and keyboard. I mean, you should be able to use most of the program features why only the mouse, or only the keyboard. Actually the most non-ergonomic action is switching from one to the other. I agree with you about the speed of using the keyboard. But if you imagine you are a new user, it might seems difficult to use keyboard at first sight, while mouse might be more intuitive.

Designing a program with a lot of features, and so UI element, is of course a difficult issue. Inkscape manages it quite well, with its floating windows. So an user can only display tools he needs. That might be a good solution for denemo. Further as screens are now larger than long (16:10…) most of the tools should be displayed on the screen sides.

In the particular case of partition edition, it is unlikely that icons would be integrated in the OS. Like Inkscape or Gimp, Denemo could have its own icons set.
In a lot of GNOME programs you can specify if prefer text, icons, text under icons, text nearby icons etc. (for examle, liferea).

Why translation is that pharaonique ? Looking at the sources I can see that it has already been started.

Thank you for your answer.
Éloi

Le mardi 08 mai 2012 à 17:25 +0100, Richard Shann a écrit :
On Tue, 2012-05-08 at 16:49 +0200, Éloi Rivard wrote: > Hello. > First of all congratulations for making Denemo, gtk wysiwyg Denemo is not wysiwyg. It displays the music only well enough to allow you to see what your music is. The output (ie what you get) is typeset by LilyPond which takes many minutes to do, which makes wysiwyg impractical, except for simple music cases, which other programs can do. > partition editor are rare and denemo is the more complete I've seen. > I wish Gnome had a reference partition editor, and denemo has the > potential to be this, but I've noticed some defects. > > I think the main denemo defect is its unfriendly and non-intuitive A lot of people feel this way about the interface, and I hope one day someone will write another one (although I might not like to use it). > interface. I don't know the Gnome Human Interface Guidelines by > heart, by I could notice several ergonomic aberrations, like: > * Detachable menus (if you have to see permanently the content > of a menu, then the content belong to a tool bar) and floating > toolbars (Articulation). Detachable menus are not permanently on view. I use them occasionally, if I am doing work in one particular area (say, Voices). > * The "title" button being the only button on its line. That line can be populated with any menu items you like (right-click the menu item and choose "place command on button bar" - the idea is (or was) to allow the user to create a series of custom toolbars. > * Does "create snippet" and "delete snippet" deserve a whole > line too ? yes, when you create a snippet it appears as a button on this line, from where you can use the snippet. > * The overcrowded preference panels. > * The unfixed "tempo" and "volume" sliders lenght. > * Text in buttons where it can be expressive icons (For example > Loop). yes, that might be nice, though I notice that I prefer text to icons, *especially* when the icons all change when I do an upgrade of the o/s (that is something that really slows me down, recognizing some new set of icons that someone has decided is better than the old ones). > * Shortcuts are not aligned on the right in menus, and they are > blue. Yes, they are a custom implementation of the short cut mechanism to allow the user interface more flexibility than the built-in ones permit. > * Tiny buttons ( like # ), it's hard to click on it ! Set the font size in the preferences menu (those are not icons, but font glyphs). > Why distinguishing notes from rests ? You could divide the number of > buttons with "duration" buttons plus one to toggle rest and note mode. > Why is there two note bars ("notes and rest entry" and "Title, button, > etc") instead of one ? As I mentioned above I planned to allow as many as you wish - in fact there is another one already which holds Movement Title etc, but it doesn't appear until you set something on it. > > I'm sure there are reason behind all those points, but they shocked me > at first sight. I made an approximately drawing of how I wish denemo > could be. Your image shows only a small horizontal area devoted to displaying the music. This would not be practical for entering large amounts of music (hundreds of bars of music) as you can only see a little bit at a time and can lose your place. However, Denemo does have a feature that would allow such a layout - if you press Esc it takes you to a mode where all the menus are suppressed, and in this way you can work on the score taking up as much of the screen as you need. > > Images intégrées 1 > > Here, everything that is often used Different users have different sets of "often used" items. I have the figured bass items on my toolbar, but nothing for dynamics. That would not be popular :) > is displayed on the top tool bars, everything that is occasionally > used is displayed on the right tool bars. Menu and hidden windows are > strictly reserved for rarely used stuffs. Everything that can be > illustrated have an icon. > > There are interesting UI ideas in other programs. Gimp (2.8) and > Inkscape for instance manage well the large number of tools. > Noteworthy is very clean for instance. > > Also I think denemo should be translated This is a big undertaking. > in order to be used by more people. (More people gets more bug > reports :) ). And maybe denemo should get a stronger graphical > identity (for instance, the icon look like a 90's program icon :). > > I hope my critical are constructive and give you some ideas about > design. Yes, very constructive, thank you. I hope someone with an interest in a graphical approach to the program will take this up. Denemo has never been used from the mouse, it is primarily a keyboard program - you enter music using the numeric keypad and a MIDI keyboard, it is several hundred times faster than mouse methods. Richard > Also if my English is not clear, don't hesitate to make me explain a > point. > > Eloi > -- > Éloi Rivard - azmeuk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > « On perd plus à être indécis qu'à se tromper. » > > _______________________________________________ > Denemo-devel mailing list > Denemo-devel-mXXj517/zsQ@public.gmane.org > https://lists.gnu.org/mailman/listinfo/denemo-devel

_______________________________________________
Denemo-devel mailing list
Denemo-devel@...
https://lists.gnu.org/mailman/listinfo/denemo-devel
Josue Abarca | 9 May 2012 20:41
Favicon

Re: Denemo user interface

On Wed, May 09, 2012 at 08:19:53PM +0200, Éloi Rivard wrote:
> My thought is that a program should support both mouse and keyboard. I
> mean, you should be able to use most of the program features why only
> the mouse, or only the keyboard. Actually the most non-ergonomic action
> is switching from one to the other. I agree with you about the speed of
> using the keyboard. But if you imagine you are a new user, it might
> seems difficult to use keyboard at first sight, while mouse might be
> more intuitive.

...

Well, AFAIK the software is mainly developed by only two people, so
more help is required to do what you propose, they are already doing a
lot of work. Your propose sounds great, and I personally would like to
help, but right now I don't have enough the time to do it.

Cheers,

--

-- 
Josué M. Abarca S.
Vos mereces Software Libre.
PGP key 4096R/70D8FB2A 2009-06-17
Huella de clave = B3ED 4984 F65A 9AE0 6511  DAF4 756B EB4B 70D8 FB2A
Richard Shann | 10 May 2012 10:44
Favicon

Showstopper bug?

Dominic Sacre came on irc #denemo to report problems with playback. He
pointed out that the page_for_time() is not thread-safe.
I felt torn about declaring this a showstopper for the release, as we
have been so long in getting this release out, but threading bugs are so
pernicious that I think we have to put in a fix for this and make
another release candidate. 
Dominic has kindly offered to supply the fix after which I think we
should give a little time to see if it works on our various machines and
then start again with the release.
Richard
Dominic Sacré | 10 May 2012 21:49
Picon
Picon

Re: Showstopper bug?

Hi Richard,

On Thursday 10 May 2012 10:44:20 Richard Shann wrote:
> Dominic Sacre came on irc #denemo to report problems with playback. He
> pointed out that the page_for_time() is not thread-safe.
> I felt torn about declaring this a showstopper for the release, as we
> have been so long in getting this release out, but threading bugs are
> so pernicious that I think we have to put in a fix for this and make
> another release candidate.

I noticed more playback issues. Some of these may be specific to certain 
backends (or combinations thereof), I'll have to do more testing and 
debugging to be sure.

- Sometimes playback just doesn't start. The "playback only works once" 
issue I mentioned before seems to be a common case of this problem, but 
somehow this has become harder for me to (intentionally) reproduce.

- Occasionally playback stops after a few seconds, always at the same 
position in the score.

- The JACK backends cause an xrun every time I stop playback. Every now 
and then, Denemo gets zombified by JACK.

- PortMidi output is completely disabled, due to an unconditional return 
statement in the process_midi() function. If, as the comment in that 
function suggests, the PortAudio backend supports some feature that the 
PortMidi backend doesn't, doesn't this apply to the ALSA and JACK backends 
as well?

All in all, I don't think Denemo in its current state is quite ready for 
release yet. The chance of users stumbling upon one or more of these 
issues is just too high.
If that's ok for you, I'd like to try and fix as many of these bugs before 
the next release candidate. As far as I can tell none of these issues 
existed half a year ago, so it shouldn't be too hard to figure out what 
changed since then, and hopefully I'll have some time to do that this 
weekend.

Dominic
Jeremiah Benham | 11 May 2012 15:34

C-1 adds tie

I notice if I change the prevailing duration using C-1,2,3.. It does change the prevailing duration but it
also adds a tie. This is annoying because I have to hit backspace and the add the note again.

Jeremiah

Sent from my Samsung smartphone on AT&T

Gmane