Monday, August 31, 2009

- Saving point collection of each element as a property on the element, solving storage and array tracking headaches.
- Finding element without known line closest to a known element proving quite difficult to do in an efficient manner. High risk of getting stuck on local maxima.
- Algorithm almost works... bed time

Sunday, August 30, 2009

- Lines now change their colour (bars, lines in staves, brace etc).
- Grouping stuff that intersects with line staves.
- Need to group things which lie outside of lines but are associated with things inside lines (notes/beams with stems etc). Probably a good time to refine my object model a little.
- Chaining through stems and then beams/notes works well.
- Will assume that anything that intersects with something now in a line is also in that line. Works pretty well..
- Trying to group left-overs by how close they are to other stuff already grouped. This will need to be an iterative operation starting with the best candidates and progressively working outwards as things are grouped.
- Grouping stuff at top and bottom of pages.
- How do I measure the minimum distance between two weird shapes? It is possible to convert a StreamGeometry to a series of points (in a long string) which somewhat match its shape. I guess I'll then have to do a lot of comparisons between points of shapes. Inefficient, but I care more about accuracy for the moment.
- Actually, it's just too slow fkn. Perhaps I'll use eight points from an elipse that fits within the bounds of an element. I'll use higher accuracy for things which appear to be phrase marks.
- Turns out google calculator defaults to radians for trigonometry... I'd forgotten about those.
- Using a few points from a fitted elipse is fast enough. Will (hopefully) finish grouping tomorrow.

Saturday, August 29, 2009

Had perhaps one too many beers... sometimes makes my code more interesting.

- Setting phrase types (not yet categorising into phrase, slur or tie though).
- Ready to divide stuff into lines. Will colour elements based on line (alternating colours for lines) and user can click on elements to switch them between line above or below.
- Fixed small misalignment of split glyph runs. Now to fix big misalignments.. (I think due to substring starting with or after space).
- Looks like all glyph runs are being split and replaced correctly.
- I might need to do something special for dots since they can be characters in strings or a note dot etc. Done.
- Todo: improve element click detection (later).
- Found a couple of beams between grace note stems not being detected properly. Grace noteheads are detected correctly, but the first stem isn't. Fixed, apparently stems can be shorter than I anticipated (less than 2 spaces high).
- Todo: if a Path is set as a notehead by the user, rerun stem/beam detection (later).
- Time to finish detection of phrases etc and group stuff into lines (but I'm not sure which to do first..).
- Actually, time for a chat over beers.

Friday, August 28, 2009

- It turns out that the geometry collection of the geometry of a glyph run may not be of the same length as the glyph run string since spaces (etc) aren't represented. Ugh. For now I'll assume that glyphs not in my main glyph list (such as spaces) aren't in the geometry. Seems to be working so far.
- Coords of glyph geometries not quite lining up properly yet...
- I think I found the cause, bed time now.

Thursday, August 27, 2009

- Displaying character being processed (as well as highlighting full string on score).
- Finding it difficult to debug some behaviour which might actually be correct due to the matching data changing each run and the sheer volume of information processing. I think it's working ok..

Wednesday, August 26, 2009

- Working on splitting all string instances before assigning their purposes.
- Need to display character being processed in long string when prompting user for type.

Sunday, August 23, 2009

- Fixed bug causing grace note slash detection to fail in Op72 #1. Need to split all string instances and do something about dots (which can be musical notation or in regular text).

Saturday, August 22, 2009

- Found width and height of glyph within run.
- Attempting to break up glyph run into separate elements. Finding the absolute position of glyphs within run is probably the main problem.
- The Geometry of a GlyphRun is a GeometryGroup, and each child Geometry represents a character with a distinct bounds Rect. I can create a single char GlyphRun copying properties from the original run, then set its XY offset to the difference between its Geometry Location and the Location of the Geometry of the original char.
- Looks like it works. If a glyph is not a char, all glyph runs containing that glyph need to be broken up into two or three pieces. The original Element needs to be removed and replacement Elements added. Done, but stuff isn't quite working right..
- Need to dump template bitmaps to disk to debug, split all glyph strings with positive matches and (possibly related) work out why grace note slash is detected as grace tail.

Friday, August 21, 2009

- Moved glyph list to user control and using on main score view and in modal dialog. Putting dialog down left side of main window. It's not immediately obvious that it is there and waiting for the user, but they'll learn...
- Glyphs that only appear in multi-char strings aren't going through image parsing since it should be a safe assumption that they are just characters rather than music elements. Bad assumption :/. I'll detect all glyphs and perhaps be a little more strict on glyphs that only appear in multi-char glyph runs.
- Saving template for single glyph in run turning out to be a bit of a bastard. User can't specify which char they want within a run and it's hard to get specific size of glyph in glyph run. Good job for tomorrow.

Thursday, August 20, 2009

- Working on breaking glyph runs (strings) of musical elements which are longer than one character into single char glyph runs. For example, in some instances a note and its dot or a clef and the key signature are grouped in a single glyph run. They need to be separate elements.
- After glyphs are matched, the user will be prompted to confirm that all glyphs are correct. After confirmation, glyph runs will be broken down and the rest of the score detection will begin.
- The prompt window could be modal if I use the current glyph type list view thingy inside a modal dialog. The user doesn't need to interact directly with the score and the operation shouldn't take long.

Wednesday, August 19, 2009

- Fixed detection of one beam. It turns out that ordering potential beams by their bounding rectangle Y position descending (bottom to top) is just different enough from ordering by bounding rect bottom Y desc to bugger my algorithm.
- Another 2.5 hours of debugging later, beams are all good including joins of broken beams under/over rests.

Monday, August 17, 2009

- Improved bar finding/joining algorithm. Some duplicated composite elements were surviving and new algorithm ignored those that were bars.
- Tracked down and patched up duplicate/composite culling hole (requires multiple passes scattered around other processing jobs which get increasingly strict).
- Started debugging couple of broken bars in Op90 (one to do with rest in beam run). Probably due to tolerances out a bit.
- Working on allowing user to select score elements and set types.
- Kinda fixed bringIntoView problem by requesting a larger rectangle (padding). Perhaps I could fix it properly if offsets are the cause of the problem.
- Generics plus events can do some very cool stuff.
- Need to be able to remove template if user makes a mistake. Maybe later. (Did a little bit now).
- Not finding bars in Minute Waltz.
- Setting glyph type changes type of all glyphs.
- Glyphs not in single length strings not getting matched. Matching done on element instance rather than glyph. Could be done on single glyph but would need to extract glyph size from string.
- Made a mistake with templates, app handled it well.
- User can now select score elements and set types. Refactored detection stuff further.
- Need to rationalise font storage.

Saturday, August 15, 2009

Mmm, chocolate for breakfast.

- Continuing on with multiple templates.
- Finished some good refactoring of matching algorithms including multiple passes.
- Improved error reporting of database actions.
- Fucken VS holding on to stale data when showing tables. Fuck.
- Multiple positive templates done.
- Most element types rebuilt.

Way past lunch time..

- Will use negative templates by removing all positive matches of same type that do not have significantly better match scores. Done.
- Detection now getting very good.
- Some unknown paths on Etude Rev and a couple of dodgy beams to check. Need to allow user to select paths from score and set type.

Time to go drink beer.
- Finding curve (phrase etc) orientation by finding line between start and end points and the average of the other points in the curve. Orientation is given by whether average point is above or below line (assuming line is never vertical). Done.
- Still a bit difficult to confidently mark curve as phrase etc without matching it to notes. Difficult to match it to notes without things grouped into lines and notes in chords.
- Need option to ignore an instance of a glyph without ignoring all glyphs of that type.
- Perhaps it's time to break things into lines. Gonna be a bitch.
- Having the user confirm that element types are correct before breaking into lines will help. Most element types found above or below lines have enough info to determine which line they belong to (as opposed to unknown shapes).
- Discovered that semibreve and minim rests can be by themselves with ledger line built in... another couple of new types.
- Finishing type detection would make line division easier and needs to be done.. perhaps I'll just do that... ugh.
- Multiple positive/negative templates means database breakage. Seems a good place to start.
- Renaming columns in SqlCe database a bastard. ElementTemplate table and mapped class created, ElementType table updated.
- Do I include min/max sizes for types in element type or each template for a type? Each template I think..
- Tweaked database reading/writing. Column names are retrieved for a table and select/insert/update queries generated using column names and reflection. Class properties must match column names for it to work (probably a good thing). Statements are cached for each class, but parameters must be get/set using reflection each time. Performance is fine for now, could be improved later.
- Adding multiple templates per type into the mix is a bit of work... bed time.

Thursday, August 13, 2009

- If an element type hasn't been defined, the user isn't prompted unless it is a similar size to existing types (a side effect from another process). We don't want to prompt the user for everything because of slurs etc. A second pass after beams/slurs etc are detected could work.
- A new pass for each new element should result in the minimum number of user prompts.
- Detecting phrases etc underway. Checking that geometry contains a curve (maybe no line) and that start point equals end point. Yet to check that element spans a couple of notes or a note near stave end. Not having elements grouped by line may make this difficult, but finding curve orientation and having note stem direction will help.
- Full beam pieces that aren't the top/bottom beam are being detected as half beams. Fixed; rejigged beam finding algorithm, handling upright and upside-down stems in separate passes. Beam top must be very close to top of upright stem (reverse for upside down stems) and additional beam pieces (semiquavers etc) are compared to previously found pieces. This requires that stems are processed left to right and beams top to bottom for upright stems, bottom to top for upside down stems. Beam detection solid, not interferring with semibreve/minim rest detection.
- Beam section between two stems is broken in two pieces below rest within set of beamed notes. Now detecting and joining pieces. It might be broken if there are consecutive rests between two stems in a beam.

Tuesday, August 11, 2009

- Starting to fix fill on duplicated elements (my algorithm to combine elements must be dodgy).
- Turns out that some elements have pen objects that shouldn't (and possibly fill objects too). Fixed. Score looks nicer and some detection anomalies are now fixed, but I might need to reset detection templates.
- Some combined elements now not filled properly. Fixed.
- Beam detection failing in all cases in one score. Looks like it probably never worked, beam pieces have five points in path rather than four. Fortunately two points are the same so a fix should be easy enough. Fixed. Problem included some scores placing beams on top of stems and others placing beams between stems. Ugh.

Monday, August 10, 2009

New todos:
- Show image of selected element separately from score when selection looks ambiguous,
- Join beam pieces (maybe can assume a beam section has no more than two pieces, but it could have more if there are consecutive rests within a beamed run),
- Some full beams are being detected as short beams.


- Stems on minims not found. Fixed.
- We have already detected staves before searching for most other stuff including beams and semibreve/minim rests. I'll make detection check that a rest hangs off or sits on a stave line before declaring it a rest. Done (and not prompting user for new element type fkn).

Sunday, August 9, 2009

More todos:
- Zoom and next/prev page controls.
- Top left and bottom right almost-transparent dots to fix min size and position of score.
- Showing/hiding individual element types.
- Need to allow user to easily select elements. Could check if user clicks within an element using high cost intersection and if not, check within bounding box, then within inflated bounding box. Elements should be ordered smallest to largest for bounding box test.
- Stems on minims not being found.. detection order back the front.
- Finding lots of semiquaver beams as semibreve rests. Second page of Op 72 has runs of demisemiquavers causing some beam detection problems.

Home time.

Saturday, August 8, 2009

Current todos:
- Visibility filter for element types,
- Multiple positive templates,
- Negative templates,
- Fix fill on some elements, particularly phrases, slurs and ties. The fill currently gets a bit mangled when combining duplicate elements,
- Fix 'bringIntoView',
- If user changes character value by certain amount (288 - ascii value), prompt if they want to do so for the rest of the font,
- 'Character' button on ElementTypeDialog. Maybe colour ok and 'ok no save' buttons red and green,
- Lunch,
- Save score data (either after auto parsing has finished or when user has finished bulk of changes.. probably the former),
- Break score up into lines,
- Store fonts in db,
- Start adding musical context to elements.

- Lunch eaten.
- Starting work on filter. Hijacking Glyph type list since it's now replaced by the ElementTypeDialog. GlyphTypeHolder now has a Show bool.
- Added Show/Hide All checkbox, updated GlyphTypeHolder DataTemplate, hooked up bindings.

Friday, August 7, 2009

- Continuing on with new element type dialog. Done.
- Will start element type filter to show/hide all elements of particular types. Also need to start saving negative templates and multiple positive templates.

My feet are cold.