On Feb 12, 2014 10:47 AM, "Bric" <[email protected]> wrote: > > On 02/12/2014 07:52 AM, Richard Shann wrote: >> >> On Wed, 2014-02-12 at 06:20 -0500, Bric wrote: >>> >>> I figured I should move this out to a new thread. (WAS: "duration, >>> rhythm, metronome, etc., for MIDI-input?") >>> >>> I compiled denemo version 1.1.2, seemingly OK. After updating my glib >>> (downloaded glib 2.39.4 source, compiled and installed it) >>> >>> But then there were issues big and small(er): >>> >>> (1) Denemo is segfault-ing when edit preferences, although, on first >>> run, I think it was NOT segfault-ing. I was able to uncheck "Highlight >>> the cursor", click OK, and it didn't segfault at that point. >> >> at which point does it segfault? > > > When I invoke the Edit -> Preferences dialog and click "OK". It happens when I don't change anything and click "OK". It also happens when I change something and click "OK". In the latter case, the change I make is effected (apparently, just before segfault-ing) and is seen in the next session. >
I experience the same thing with the mac build. > > >>> (BTW: >>> Hallelujah! end of forced scroll animation! BIG BIG help. >> >> well, it sounds like you haven't fixed the drawing problem on your >> machine - how does it get on running gimp for instance? Just out of curiosity... Do you have hardware graphic acceleration? I believe the command to find out is: glxinfo It will say so in the first few lines of output. Jeremiah > > > I don't think I made myself understood. I am jumping for joy over NOT HAVING the animation, finally. I am happy! no need to change anything in this respect, now :-). It's NOT animating anymore -- neither the cursor, nor the scroller. Thank you for that accommodation! > > (I omitted the words "This is a..." in "This is a BIG BIG help") > > > >> >>> Thanks) >>> >>> (2) Contrary to what I was told in previous threads about copying my >>> .denemo-xxx/actions/actions/Default.commands and >>> .denemo-xxx/actions/Default.shortcuts : copying just >>> "Default.shortcuts" is not enough to preserve all the laboriously >>> developed shortcuts. One must apparently copy the Default.commands file >>> as well. In a previous thread Richard or someone else warns against >>> copying over "Default.commands", saying that would mess up the command >>> set. But if I don't copy it over I lose my shortcuts! >> >> You should not need to do this any more. When you started the new >> version (provided you had not externally created a directory >> called .denemo-1.1.2 before launching the new Denemo) you get a dialog >> offering to keep your settings. > > > I'll tinker with that some more. I'm sort of confused; let me experiment and report back. > > >> What you can do in your circumstance is to copy Default.commands from >> the new distribution and Default.shortcuts from your >> old .denemo-xxx/actions directory. That should make all the commands >> available while keeping your shortcuts. >> >>> (3) Typeset music failing to render a file that is rendered fine by my >>> old (current) denemo 1.0.9 >> >> This is usually caused by old LilyPond syntax that Denemo used to add >> for default beaming that 1.0.9 added to files by default. Execute the >> Score->Typesetter->Use Normal Beam Endings command to fix this. (If you >> haven't got Default.commands from the distribution, you will need to get >> that first as that menu is changed since 1.0.9 I suspect). > > > Hmm... I do have the "Use Normal Beam Endings" command in the menu, I click on it, it SEEMS to help (the error watermark seems to go away), i edit the score, see my edits rendered in the typeset window, I save the file, close denemo, re-open denemo and -- Oops! -- the typeset error message is back. I've done this cycle, like, four times. Same result. > > >> >>> (4) More of a warning than issue, really: Denemo xml files tend not be >>> backwards-compatible. So, when I opened in 1.1.2 a pre-existing >>> *.denemo file generated/saved in 1.0.9, and FOOLISHLY re-saved it in >>> 1.1.2, I couldn't open it in 1.0.9 anymore. Fortunately, apparently, >>> all I had to do was change the line >>> >>> <score xmlns="http://denemo.org/xmlns/Denemo"; version="7"> >>> >>> to >>> >>> <score xmlns="http://denemo.org/xmlns/Denemo"; version="6"> >>> >>> and that appears to have fixed the problem, this particular time. >> >> That would not work in general, but may give you something useful. >> Software generally isn't written to open yet-to-be-invented file >> formats, for obvious reasons, so 1.0.9 will not read the newer 1.1.2 >> format. >> > > Like I said, this is more of a warning (to me and to others, I guess)... I realize denemo is hardly at fault here... except maybe there could be a courtesy, fool-proof pop-up warning alerting that "If you are to save the current, older-version file", you won't be able to open it in the older versions of denemo. " > > I simply lost focus and forgot about this phenomenon. (An alert would have reminded me) > > > > _______________________________________________ > Denemo-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/denemo-devel
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
