lmuse-developer

Dear ladies and gentlemen,
flo software productions proudly presents
*drum roll*
the first preview of the score editor :)
link: http://home.arcor.de/michael.jung11/scoresnap20110327.tar.gz
what works? and features
* rendering and displaying a score
* scrolling
* editing notes via drag and drop: you can alter the pitch, the
begin and the length
* automatically redraw when the song changes
* moderate or low cpu usage; runs fluently on my 1.6GHz machine
(single core)
* pretty extensible and abstract design
what needs to be done?
* allowing multiple parts/tracks be drawn into one score,
distingushable by color
* integration into muse
* code-cleaning
* fixing some bugs i haven't found yet
you might wonder why i use createAppropriateEventList; well, this makes
it really easy for me to extend the program, to do my own quantizing, to
implement key changes before muse even knows about them, and to do the
"many tracks into one score" thing
and this allows other projects reuse my rendering algo easily; they only
need to adapt the createAppropriateEventList function
feel free to read through the comments and maybe fix stuff, or make
suggestions, etc :)
please do not let the archive get to any non-muse-developer, as there
are open licensing questions
and redirect muse's output to /dev/null, otherwise you'll get an awful
load of debug messages which really slow down everything
any feedback is welcome
Greetings
flo

...and it runs fine, only tried viewing but it certainly looks like a
good start. :) Good job!
would be good to move it to it's own editor and bind it to a menu
option so we could check it in.
I guess the licensing issue has to be resolved before, it's the font
being GPLv3, right? Does the license apply when it's used this way,
anyone have a clear understandning?
Regards,
Robert
2011/3/27 Robert Jonsson <spamatica@...>:
> Hey, nice! currently compiling :)
>
> 2011/3/27 Florian Jung <florian.a.jung@...>:
>> Dear ladies and gentlemen,
>>
>> flo software productions proudly presents
>> *drum roll*
>> the first preview of the score editor :)
>>
>> link: http://home.arcor.de/michael.jung11/scoresnap20110327.tar.gz
>>
>>
>> what works? and features
>>
>> rendering and displaying a score
>> scrolling
>> editing notes via drag and drop: you can alter the pitch, the begin and the
>> length
>> automatically redraw when the song changes
>> moderate or low cpu usage; runs fluently on my 1.6GHz machine (single core)
>> pretty extensible and abstract design
>>
>> what needs to be done?
>>
>> allowing multiple parts/tracks be drawn into one score, distingushable by
>> color
>> integration into muse
>> code-cleaning
>> fixing some bugs i haven't found yet
>>
>> you might wonder why i use createAppropriateEventList; well, this makes it
>> really easy for me to extend the program, to do my own quantizing, to
>> implement key changes before muse even knows about them, and to do the "many
>> tracks into one score" thing
>> and this allows other projects reuse my rendering algo easily; they only
>> need to adapt the createAppropriateEventList function
>>
>>
>> feel free to read through the comments and maybe fix stuff, or make
>> suggestions, etc :)
>>
>> please do not let the archive get to any non-muse-developer, as there are
>> open licensing questions
>>
>> and redirect muse's output to /dev/null, otherwise you'll get an awful load
>> of debug messages which really slow down everything
>>
>> any feedback is welcome
>>
>> Greetings
>> flo
>>
>>
>> ------------------------------------------------------------------------------
>> Enable your software for Intel(R) Active Management Technology to meet the
>> growing manageability and security demands of your customers. Businesses
>> are taking advantage of Intel(R) vPro (TM) technology - will your software
>> be a part of the solution? Download the Intel(R) Manageability Checker
>> today! http://p.sf.net/sfu/intel-dev2devmar
>> _______________________________________________
>> Lmuse-developer mailing list
>> Lmuse-developer@...
>> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>>
>>
>

Am 27.03.2011 21:36, schrieb Robert Jonsson:
> ...and it runs fine, only tried viewing but it certainly looks like a
> good start. :) Good job!
>
>
thanks :)
try editing: click on a note, hold the button, and move
move up/downwards for changing pitch
move left/right for changing duration or begin;
when the note is tied: if you click on the first note, you'll change
beginning, clicking on the last will change duration
when the note is not tied: if you click on the left half of the note
head: change begin tick, right: duration
> would be good to move it to it's own editor and bind it to a menu
> option so we could check it in.
>
it cannot be checked in right now; there are lots of segfaults, because
i haven't implemented all that muse-specific signaling stuff. try open a
song, open the score viewer, and open another song. it will segfault.
but it would be cool if anyone could move my code to its own editor,
with all the menu bindings neccessary; shouldn't be a big deal for
someone who knows how to do this
thanks for the positive feedback
flo

On 03/28/2011 06:51 AM, Florian Jung wrote:
> try open a
> song, open the score viewer, and open another song. it will segfault.
>
actually muse can do that all by itself without your score editor flo ;)
... although a lot less frequently than it did. does it happen everytime
you load a new song ?
g.

Hi Florian,
I added a placeholder for the score scoreedit.cpp/h.
I noticed that your current implementation does not follow the current
editor pattern with a canvas class, I suppose the scoreeditor does not
benefit from it's features?
Anyway, try and move your code to these.
As for checking it in, that it is not finished and will crash at
certain points is not crucial for checking in. It is a separate
feature and as I understand it won't affect stability unless it is
open.
We're coming up on a beta release, if we have something checked in
before that we may remove the menu choice for the release but apart
from that I'm fine with adding it. Haven't looked at the code, will
try to do that too.
Regards,
Robert
2011/3/27 Florian Jung <florian.a.jung@...>:
> Am 27.03.2011 21:36, schrieb Robert Jonsson:
>> ...and it runs fine, only tried viewing but it certainly looks like a
>> good start. :) Good job!
>>
>>
> thanks :)
> try editing: click on a note, hold the button, and move
> move up/downwards for changing pitch
> move left/right for changing duration or begin;
>
> when the note is tied: if you click on the first note, you'll change
> beginning, clicking on the last will change duration
> when the note is not tied: if you click on the left half of the note
> head: change begin tick, right: duration
>> would be good to move it to it's own editor and bind it to a menu
>> option so we could check it in.
>>
> it cannot be checked in right now; there are lots of segfaults, because
> i haven't implemented all that muse-specific signaling stuff. try open a
> song, open the score viewer, and open another song. it will segfault.
>
> but it would be cool if anyone could move my code to its own editor,
> with all the menu bindings neccessary; shouldn't be a big deal for
> someone who knows how to do this
>
> thanks for the positive feedback
> flo
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>

2011/3/27 Robert Jonsson <spamatica@...>:
> I guess the licensing issue has to be resolved before, it's the font
> being GPLv3, right? Does the license apply when it's used this way,
> anyone have a clear understandning?
So I checked and the Feta font exists in lilypond 2.8.x too. It's the
same font right?
And that version of lilypond is GPL2. Shouldn't that mean that the
font is GPL2 compatible?
Regards,
Robert

Am 28.03.2011 13:41, schrieb Robert Jonsson:
> 2011/3/27 Robert Jonsson<spamatica@...>:
>
>> I guess the licensing issue has to be resolved before, it's the font
>> being GPLv3, right? Does the license apply when it's used this way,
>> anyone have a clear understandning?
>>
> So I checked and the Feta font exists in lilypond 2.8.x too. It's the
> same font right?
> And that version of lilypond is GPL2. Shouldn't that mean that the
> font is GPL2 compatible?
>
i don't know if it changed; but i don't think it has changed much, if at all
i think that's correct. i suggest we use that font, ask the lilypond
devs if we may use it, and if not, they'll tell us, won't they?
greetings
flo

and to the list
---------- Forwarded message ----------
From: Robert Jonsson <spamatica@...>
Date: 2011/3/28
Subject: Re: [Lmuse-developer] font licensing stuff
To: Florian Jung <florian.a.jung@...>
2011/3/28 Florian Jung <florian.a.jung@...>:
>> So I checked and the Feta font exists in lilypond 2.8.x too. It's the
>> same font right?
>> And that version of lilypond is GPL2. Shouldn't that mean that the
>> font is GPL2 compatible?
>>
> i don't know if it changed; but i don't think it has changed much, if at all
> i think that's correct. i suggest we use that font, ask the lilypond
> devs if we may use it, and if not, they'll tell us, won't they?
Yes that sounds like the preferrable way to do it, will you ask them?
Regards,
Robert

Am 27.03.2011 23:50, schrieb Robert Jonsson:
> I noticed that your current implementation does not follow the current
> editor pattern with a canvas class, I suppose the scoreeditor does not
> benefit from it's features?
>
correct, it doesn't benefit
> Anyway, try and move your code to these.
>
why? i have thought through this initially, and i came to the conclusion
that i cannot benefit from it at all, but it will be pretty hard to
integrate my code into the existing system.
the problems are:
* canvas uses CItems, which contain information about their
rectangles, which isn't needed
* my Items (called FloItems atm) need information about score line,
accidentials, shift, stems etc, which CItems hasn't
* canvas offers lots of functions i don't need, like moving groups
of notes
* canvas does not offer lots of functions i need, like processing
the FloItems
i really think that reinventing the wheel is unneccessary, but only if a
wheel fits into that place. and in my case, i don't think the
"canvas-wheel" fits.
if you have reasons why a Canvas is better, please tell me :)
> As for checking it in, that it is not finished and will crash at
> certain points is not crucial for checking in. It is a separate
> feature and as I understand it won't affect stability unless it is
> open.
>
okay, if that's no problem...
thanks for your score template; however, "right click on a part" ->
"score editor" entry is missing; in the "edit" menu it's there ;)
Am 27.03.2011 22:50, schrieb Geoff Beasley:
> On 03/28/2011 06:51 AM, Florian Jung wrote:
>> try open a
>> song, open the score viewer, and open another song. it will segfault.
>>
> actually muse can do that all by itself without your score editor flo
> ;) ... although a lot less frequently than it did. does it happen
> everytime you load a new song ?
heh, yeah, there are some segfaults :)
yes, i think that problem is reproducable.
i don't have much experience with svn (i only have used git so far); is
there a way to maintain a local repository, or something like that?
in git, i would create a new branch, do my programming there and
eventually merge it with the master again
the goal of this is that my (unstable) development versions don't get
into the (at least more) stable master tree, but are still under version
control. so if suddenly some code keeps segfaulting, i can use the last
archived version.
can i do this locally on my machine somehow? or would i need to get
write access to the main repo? or to my own part of it, dunno what svn
can do..?
greetings
flo

Hi Florian,
2011/3/28 Florian Jung <florian.a.jung@...>:
> Am 27.03.2011 23:50, schrieb Robert Jonsson:
>
> I noticed that your current implementation does not follow the current
> editor pattern with a canvas class, I suppose the scoreeditor does not
> benefit from it's features?
>
>
> correct, it doesn't benefit
>
> Anyway, try and move your code to these.
>
>
> why?
Sorry, I was unclear. If you already know what you need I have no
objection about the design.
I only meant that it would be good if you could take over the
ScoreEdit class in the scoreedit.* files (they are just dummy copies
of the pianoroll files) so we can have the PianoRoll in parallell :)
<..>
>
> thanks for your score template; however, "right click on a part" -> "score
> editor" entry is missing; in the "edit" menu it's there ;)
Yes, I ran out of energy, I'll fix it later unless you want to get
your feet wet and try to find it yourself ;-)
> i don't have much experience with svn (i only have used git so far); is
> there a way to maintain a local repository, or something like that?
> in git, i would create a new branch, do my programming there and eventually
> merge it with the master again
> the goal of this is that my (unstable) development versions don't get into
> the (at least more) stable master tree, but are still under version control.
> so if suddenly some code keeps segfaulting, i can use the last archived
> version.
>
> can i do this locally on my machine somehow? or would i need to get write
> access to the main repo? or to my own part of it, dunno what svn can do..?
Interesting that you have Git experience. I have been thinking on and
off if we should move (again), this time to Git. Orcan, you were
leaning in this direction too, right?
Svn does, to my knowledge, not support private/local branching as I
understand git does. The only way is to have full repo access.
Regards,
Robert

Hi
i noticed that my parse_note_len function has two severe bugs; one is
easy to be fixed, the second is not.
the problem is, that my function only works with 4/4-measures. if you
look at foo[], you'll see that it's designed for 4/4.
the basic way how the foo[] array works, is, that it contains how
emphasized a beat is (in 64th-beats); a low number means "very
emphasized", higher numbers mean "less emphasized".
a 4/4 measure can be described as 1 2 3 2 (in 4th-beats). think of "TA
(ka) ta (ka)": loud - quiet - in between - quiet again
however, when using other measures like 3/4 or 6/8, foo[] must change
3/4: 1 3 2 3 2 3 "TA (ka) ta (ka) ta (ka)" (in 8th-beat. don't confuse
these "ka"s with the above)
6/8: 1 3 3 2 3 3 "TA (ka) (ka) ta (ka) (ka)" (in 8th beat as well. you
see the difference to the 3/4?)
problem is, i can specify such foo[] arrays for 4/4, 3/4 and 6/8 measures
however, i cannot specify them for "exotic" measures like 5/4, 7/4, 9/4,
5/8 etc.
what do you think should i do which suck measures?
a) simply treat them as over-long 4/4-measures ("TA (ka) ta (ka) ta (ka)
ta (ka) ta (ka)", note the last "ta (ka)") this would result in a whole
rest plus a quarter rest in a 5/4 measure
b) treat them as over-long 1/4-measures ("TA ka TA ka TA ka TA ka TA
ka"). this would result in five quarter rests in a 5/4 measure
c) treat 5/4 and 7/4 like a), but treat 9/4 as over-long 6/4-measure?
(TA ka ka TA ka ka TA ka ka)
does anyone know of a mathematical model i can use for calculating these
note emphasis?
Greetings
flo

On Mon, Mar 28, 2011 at 4:13 PM, Florian Jung <florian.a.jung@...> wrote:
> does anyone know of a mathematical model i can use for calculating these
> note emphasis?
3, 6, 9 and 12-beat signatures are ternary (groups of three). There's
no mathematical rule for signatures like 5. It is usually subdivided
as 2+3 or 3+2, depending on the composer's design, so ideally it
should be a user-defined option.