No description
- Python 99.8%
- Shell 0.2%
|
|
||
|---|---|---|
| .gitlab/issue_templates | Delete broken issue template folder | |
| adr | Update language-design.md | |
| archive | Upload New File | |
| fonts | testing vfom | |
| tests | Add rule for stems | |
| .commit-message-template | Add slur | |
| .gitignore | __VE__ -> __ve__ | |
| __init__.py | testing vfom | |
| cfg.py | Decrement right padding from non-times if needed | |
| cmn.py | Add rest class | |
| CMN_README.md | Add rule for stems | |
| engine.py | Add rest class | |
| fontinstprep.ff | testing vfom | |
| pre-push | Bug notehead vertical pos rule | |
| README.md | Update README.md | |
| requirements.txt | Add slur | |
| score.py | Add rest class | |
Satie
Dependencies
- Python 3.5 or higher
Thinking in Rules
How to thinkg when I'm about to add new rules to a table
Generally how defining new rules happens is as follows:
- Understand what is the rule about, what is it it's doing, to which object it applies?
- Understand at which moment in the engraving process should the rule be applied (i.e. be added/unsafeadded to the rule table)
- Make a rule predicate func which returns true when called with some object as arg (this is called then on each obj in the score), to find out to which objs our rule should be applied.
- Make the actual engraving func which is applied to that object
SVG measurements
are by default (if not correct them) in pixels only.
Coordinate Movement of Objects
When you move an object's y coordinate
- incrementing (+) is to the bottom
- decrementing (-) is to the top
When moving an object's x coordinate
- incrementing (+) is to the right
- decrementing (-) is to the left
API's Pitfalls (just for the record, some common mistakes I did while working with the API)
- When creating forms (e.g. a horizontal form), it's origin (xy coord) is placed in the middle of it's height (i.e. half way down of it's top edge). Moving the y for instance, of course moves the top and bottom of the whole form as well, which can end with wrong results if you are setting y by somehow using references to it's top/bottom. I did this mistake while replacing the hform of final bar in a rule:
obj.y = obj.current_ref_glyph_top() - StaffLines.THICKNESS * 0.5in order to place the obj's (FinalBarline) thin and thick at once. This resulted in a longer hform because the current_ref_glyph_top is (?) static...