Re: [Guidolib-devel] Proposal for Locking down staff & system positions

[Henry F. <gui...@he...>]

Thanks, Dominique, for the reply.

I am a former software engineer now piano & composition teacher.  Occasionally, I make time for iOS development to support teaching music (www.MusicFlashClass.com).  

As far as I can tell, there is no open source library for music notation that is suitable for music teaching apps.  I’m thinking of apps that include:
- flash cards
- touch response to elements of the music
- highlighting of elements
- playback and follow the music
- left to right scrolling

An app like this would open up countless opportunities for games, drilling, teaching, etc.

I was exploring Guido for this, and I had worked up some minor tweaks to demonstrate some possibilities before being pulled into a lengthy update for MusicFlashClass (iOS 8 broke it).

The specific desires that I can think of off of the top of my head are:

1) predictable positions for staves and possibly measure lengths, so that they do not bounce up and down as the (ledger) notes change on successive cards
2) if possible, position information on elements within the music notation, so that a user can touch a note or an accidental, or a 
3) if possible, the ability to color individual notes/elements
4) the ability to create an “infinitely” long work that can scroll from left to right as it is being performed
5) predictable positions for chord elements, so that they don’t bounce left and right as accidentals/etc. are added

In reading the code, #1 looked fairly easy, and I had prototyped something that was an extension of the existing language (I’d have to return to the code and examples to see what).  If I recall, Guido already allowed fixed distance between staves, so it was not a difficult extension to add fixed left and top margins.

If I recall, #2 looked like it might be possible if the code were willing to navigate the internal guido data hierarchy or there was function support for this feature.  I think if the user could embed tags into the ASCII code for different elements, then this kind of information could be looked up by adding a function to search for the tag and return the position info.  

#3 looked to be straightforward with an extension of the language, but I’d not given thought to what that would look like.  I have a faint recollection of doing this by implementing tags, and then using a function to modify the color of that element and then re-render the music. 

#4 - I’m not sure how that would be done, unless it were done in no left/right margin pages that simulated segments, and there was a flag that could be set to treat the “new page” for each segment differently than standard notation, so a new clef wouldn’t show up, etc.

#5 I’d not yet explored.  I suspect that that would be annoying to implement.

By no means would this be an ideal implementation of a library for app development.  That is because it would be the reshaping of a page layout application into a somewhat different model.  However, it didn’t look impossible.

For Music Flash Class, I rolled my own notation code for very simple needs: only one or more whole note for each single measure, key signatures, and accidentals.  No time signature, no more than one measure per card.  For iOS 8 I made everything vector by using PaintCode to generate code to render each element.  (This proved much easier than dealing with fonts.)  However, the limitations of what I can draw without significant effort to re-invent the wheel of music notation limit the kinds of things that I’d love to be able to do.

Because I had to rewrite much of Music Flash Class for iOS 8, and now that I’m starting a master’s in composition, I don’t have any time to dive back into Guido changes.  However, if any of this is something you wanted to explore, I’d love to offer you my two cents.

Thanks again for maintaining this project!

Cheers,
Henry




> On Sep 7, 2014, at 7:35 PM, Henry Flurry <gui...@he...> wrote:
> 
> I am exploring ways to lock down where staves are drawn on a “page” so that apps that use guido can know that the staff on an image is being drawn in the same place each time.
> 
> Following up on this, I’m thinking that we could add new parameters to lock down the x,y position of systems, so that they don’t shift with extended bounding boxes.
> 
> Here are some observations:
> 
> - You can lock down the distance between staves within a system by applying a dy to the upper staff of a pair of staves to be locked together.  A dy would need to be applied to each upper of a pair of staves to lock down all staves within a complete system.  (See staff2.gmn)
> 
> - Thus, it seems like the only thing we need to deal with is the position of each system.
> 
> - \systemFormat has a dx, but it only applies to the first system.
> 
> - it appears that each system is always at the left margin, except for when systemFormat has a dx set, which offsets JUST the first system.
> 
> - As an aside, in the code, “dy" on \newSystem is actually read, but it’s internally stored value (mSystemDistance) appears to be intentionally or unintentionally overwritten before it can be used.
> 
> What I propose:
> 
> TWO parameters:  One to lock the distance between successive systems, and one to lock the top left of the first system.
> 
> Some ideas:
> 
> #1)
> \systemFormat<dy=3cm, lockfirst=yes> ← each successive system starts 3cm after the previous, and the first system is locked to the margin.
> 
> PROS: keeps system layout information in \systemFormat; CONS: \systemFormat’s “dy” applies to multiple systems, while its “dx” only applies to the first system; lockfirst is a new parameter.
> 
> #2)
> \systemFormat<dy=1.1cm,dy=.5cm> …. \staff<4,dy=1.8cm> … ← the FIRST system is .5 cm down and 1.1 cm to the right from the top left margin, and the last staff of the system (labeled "4" in this case) says that the next staff (i.e., first staff of the next system) is 1.8cm down.
> 
> PROS: More consistent with existing use of “dy” and “dx” for both \systemFormat & \staff.  CONS: Moves some system layout info to the staff level.
> 
> Currently, my thinking is that option #2 would be less confusing to folks.
> 
> I would be willing to take a stab at implementing this.
> 
> Thoughts?
> 
> Cheers,
> Henry
> 
> 
> 
> On Sep 6, 2014, at 8:31 PM, Henry Flurry <gui...@he...> wrote:
> 
>> I’m hoping to use GuidoLib for iOS apps.  Part of this depends upon the ability to create predictable images from GuidoLib.  So far, I’m generating text and interpreting it instead of making calls to the library for the elements.
>> 
>> Two issues have come up:
>> 
>> If in \staffFormat I set the staff size large, for instance if I’m trying to fill an image, the layout messes up.  Notes get crunched to the right side, etc.  I think I can get around this by using smaller “pages” and scaling it up, but I’ve not explored that yet.
>> 
>> Also, I would like to be able to place the staff at a known x,y, with a known width.  I have tried setting page margins to the page size in \pageFormat, high ledger lines will push the staff down.  Is it possible to get the staff at a known position and not have ledger lines adjust its vertical position?
>> 
>> Thanks!
>> Henry Flurry
>> 
> 
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel