Giter Site home page Giter Site logo

abjad / abjad Goto Github PK

View Code? Open in Web Editor NEW
230.0 15.0 41.0 371.03 MB

Abjad is a Python API for building LilyPond files. Use Abjad to make PDFs of music notation.

Home Page: https://abjad.github.io

License: GNU General Public License v3.0

Python 98.06% Makefile 0.07% LilyPond 1.82% Scheme 0.04%
python lilypond music-notation music-composition

abjad's Introduction

Abjad 3.19

Abjad helps composers build up complex pieces of music notation in iterative and incremental ways. Use Abjad to create a symbolic representation of all the notes, rests, chords, tuplets, beams and slurs in any score. Because Abjad extends the Python programming language, you can use Abjad to make systematic changes to music as you work. Because Abjad wraps the LilyPond music notation package, you can use Abjad to control the typographic detail of symbols on the page.

image

image

image

image


Abjad's documentation is available here: https://abjad.github.io

Abjad's install instructions are tested on macOS and Linux.

Abjad requires Python 3.10 or later:

~$ python --version
Python 3.11.0

Abjad requires LilyPond 2.23.6 or later.

Make sure LilyPond is installed: http://lilypond.org/development.html

Make sure LilyPond is callable from the commandline:

$ lilypond --version
GNU LilyPond 2.23.80 (running Guile 2.2)

Create a Python 3 virtual environment for Abjad: https://docs.python.org/3/tutorial/venv.html

Activate the virtual environment and then use pip to install Abjad:

~$ python -m pip install abjad

Start Python, import Abjad, start making music notation:

~$ python
>>> import abjad
>>> note = abjad.Note("c'4")
>>> abjad.show(note)

image


Join the Abjad community: https://abjad.github.io/appendices/community.html

abjad's People

Contributors

80aff123-9163-4f3e-a93d-4a2f35af9be1 avatar adorsk avatar ajyoon avatar delucis avatar gregoryrevans avatar jdavancens avatar jefftrevino avatar jgarte avatar josiah-wolf-oberholtzer avatar kitefishlabs avatar kureta avatar leforestier avatar mscuthbert avatar nivlekp avatar odub avatar quesebifurcan avatar schoettl avatar tiagoantao avatar trevorbaca avatar tymbalodeon avatar victoradan avatar yannickjadoul avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

abjad's Issues

Extend show( ) and friends to print excessive format time

From [email protected] on October 03, 2009 11:36:06

Right now show( ) and friends will tell you if LilyPond rendering time
exceeds the number of seconds passed to the optional lilytime keyword
argument (which defaults to 10 seconds).

Tight loops and other inefficient implementation errors can result in
reasonable LilyPond rendering time but an unreasonable amount of time on
the part of Abjad formatting the argument to show( ) in the first place.

Solution is to implement a new optional keyword for show( ) and friends
called formattime that will message the user on excessive Abjad format time.

Original issue: http://code.google.com/p/abjad/issues/detail?id=19

Fix NoteHead behavior when casting between leaves

From [email protected] on October 12, 2009 13:31:59

Compare this normal note ...

note = Note(0, (1, 4))

... with this note created by casting a chord:

chord = Chord([0], (1, 4))
new_note = Note(chord)

There are 32 note format contributors but only 31 new_note format contributors.

note.interfaces.contributors
[, , ,
, , , ,
, , ,
, ,
, , , ,
, , , ,
, , ,
, , ,
, , , ,
, NoteHead(c')]
len(
)
32

new_note.interfaces.contributors
[, , ,
, , , ,
, , ,
, ,
, , , ,
, , , ,
, , ,
, , ,
, , , ,
]
len(
)
31

The new_note notehead does not show up in the list of new_note format
contributors. This is a problem. The new_note notehead should show up in
the list of new_note format contributors.

Original issue: http://code.google.com/p/abjad/issues/detail?id=24

Author scr/devel/renumber-tests script for test-case (re)numbering

From [email protected] on August 22, 2009 06:41:06

It's a pain to renumber the names of test-case functions in the test files.

For example, in breaking chordtools.split( ) into separate
chordtools.split_by_pitch_number( ) and chordtools.split_by_altitude( ), it
was necessary to break tools/chordtools/test/test_chordtools_split.py into
tools/chordtools/test/test_chordtools_split_by_pitch_number.py and
tools/chordtools/test/test_chordtools_split_by_altitude.py. This meant that
the 14 test-cast functions in test_chordtools_split.py had to be divided
between the two new test files and then renamed by hand.

It should be relatively straightforward to write a developer script called
scr/devel/rename-test-cases that can be run on any directory or file
(including the entire Abjad codebase) and that will find, report and
optionally rename test-cases that are numbered out of order.

Of course it is also possible that such a script may already be available
from one of the other project teams using py.test.

Original issue: http://code.google.com/p/abjad/issues/detail?id=12

Make abjad-book handle Python raw strings correctly

From [email protected] on March 07, 2010 09:09:06

This input confuses abjad-book:

%%% BEGIN %%%

markup = Markup(r'This \note "4." is a dotted quarter note.')

%%% END %%%

abjad-book interprets the escaped-n as a newline character, even though the
r-fronted string indicates raw character values in Python.

The workaround is to use fully escaped non-raw strings in the input code:

markup = Markup('This \note "4." is a dotted quarter note.')

Original issue: http://code.google.com/p/abjad/issues/detail?id=32

Implement BarLineSpanner and SpanBarSpanner

From [email protected] on October 12, 2009 12:29:49

The _LeafFormatterSlotsInterface implements a special
_wrap_preceding_measure_barline_reverts( ) method to handle the special way
that LilyPond interprets barlines and spanbars.

Implement BarLinespanner and SpanBarSpanner to allow for spanner-based
overrides of the LilyPond BarLine and SpanBar grobs. Then teach
_LeafFormatterSlotsInterface about these two new spanners.

Original issue: http://code.google.com/p/abjad/issues/detail?id=23

abjad.tools.iterate.naive* refactoring: use a subrange to generalize the code

From [email protected] on November 17, 2009 20:45:44

I have rewritten these two functions to be more generalized and not have to
maintain an internal counter object ('total') like the old code used. This
code has two pieces:

  1. a generator that iterates (forward or backward) over object expr and
    yields elements of the given class type
  2. a subrange generator that, in effect, yields the elements
    iter[start:stop] for any iterator iter (but does not support negative
    indices, as doing so could be difficult/inefficient for a general iterator
    object)

The 'subrange' generator is common to both files and might be a candidate
for a good utility class in tools.iterate.

I ran the doctests, however the tests for naive_backward_in didnt make
sense (do they pass?). For example, the second test yields a Note(b',8),
but that note isnt even in the original Staff. So, either my understanding
is too basic or the doctest is not correct.

Attachment: iterate_naive_patch

Original issue: http://code.google.com/p/abjad/issues/detail?id=29

Document inherited attributes in Sphinx

From [email protected] on June 22, 2009 08:06:25

Sphinx does not currently document inherited attributes.

For example, the base _Component class implements public splice( ) and
splice_left( ) methods, both of which currently carry minimal doc strings.
When we look at the API page that Sphinx generates for the base _Component
class, we see the doc strings for both splice( ) and splice_left( ); this
is good. However, when we look at the API pages that Sphinx generates for
the classes like Container, Note, Rest, Chord, and so on, we see no
indication of splice( ), splice_left( ) or any of the other public methods
implemented on _Component directly.

This is a problem for two reasons.

First, users looking at the API entries for Note, Rest, Chord and so on
will be unaware that splice( ), splice_left( ) and a number of other
methods are available in the public interfaces of these classes.

Second, we need doc coverage statistics to manage code completeness,
especially before making and posting public builds of the system. (That is,
I think we should have a minimal standard that 100% of the attributes in
the public interface of the system carry at least some type of doc string
prior to release.) Happily, Sphinx provides just such an affordance in the
form of a documentation coverage build:

sphinx-build -b coverage . _build/coverage

However, looking at the Python-based part of the output ...

vi _build/coverage/python.txt

... lists splice( ), splice_left( ) and so on as undocumented in Note,
Rest, Chord, etc.::

abjad.chord.chord

Classes:

  • Chord -- missing methods:
    • splice
    • splice_left

abjad.container.container

Classes:

  • Container -- missing methods:
    • splice
    • splice_left

Which makes the output of Sphinx's coverage build unusable as a project
metric for documentation.

Best would be if there's a way to teach Sphinx to copy doc strings from
parent classes.

Original issue: http://code.google.com/p/abjad/issues/detail?id=3

Fix abjad-book handling of input lines with special characters

From [email protected] on December 07, 2010 16:35:59

Doc input to abjad-book like this ...

voice_1 = Voice(r"e''4 f''4 g''4 g''4 f''4 e''4 d''4 d''4 \fermata") abjad> staff = Staff([voice_1, voice_2])

... will output like this ...

voice_1 = Voice(r"e''4 f''4 g''4 g''4 f''4 e''4 d''4 d''4 ermata")
abjad> staff = Staff([voice_1, voice_2])

... which shows two problems.

First, the ...

abjad>

... prompt is missing from the first output line.

Second, the \f is missing from the first output line.

Original issue: http://code.google.com/p/abjad/issues/detail?id=44

Optimize format-time behavior with big spanners

From [email protected] on October 03, 2009 13:53:15

Here is profiling information for music with no spanner:

staff_1 = Staff(construct.run(100))
check.profile('staff_1.format', num_lines = 30, strip_dirs = False)

450242 function calls (415842 primitive calls) in 0.657 CPU seconds

Here is profiling information for the same music with a single spanner:

staff_2 = Staff(construct.run(100))
spanner = Spanner(staff_2[:])
check.profile('staff_2.format', num_lines = 30, strip_dirs = False)
3781843 function calls (3747441 primitive calls) in 3.739 CPU seconds

Notice that this is a difference between .45 million function calls and
3.78 million function calls. That is, the spanned version makes 8 times as
many function calls as the unspanned version.

Running the same examples with 200 notes instead of 100 notes gives the
following profiling information:

unspanned with 200 notes: 1.2 million function calls
spanned with 200 notes: 26.2 million function calls

That is, the number of function calls grows exponentially for spanned
music. This will not be a problem for spanners that span only a handful of
components. But if your score contains spanners that span hundreds of
components, then you will notice a tremendous slow-down at format time.

Original issue: http://code.google.com/p/abjad/issues/detail?id=20

Rename all spanners to end in -Spanner

From [email protected] on October 01, 2009 08:13:22

Rename the following:

Beam to BeamSpanner
BeamComplex to BeamComplexSpanner
BeamComplexDurated to BeamComplexDuratedSpanner
Bracket to BracketSpanner
Crescendo to CrescendoSpanner
Decrescendo to DecrescendoSpanner
Glissando to GlissandoSpanner
Hairpin to HairpinSpanner
Instrument to InstrumentSpanner
MetricGrid to MeterSpanner
Octavation to OctavationSpanner
Override to OverrideSpanner
PianoPedal to PianoPedalSpanner
SpacingSpanner is OK
Spanner is OK
Tempo to TempoSpanner
TempoProportional to TempoProportionalSpanner
Text to TextSpanner
Tie to TieSpanner
Trill to TrillSpanner

Original issue: http://code.google.com/p/abjad/issues/detail?id=18

divide_scalar_by_ratio optimization: Calculate constant factor outside of list comprehension

From [email protected] on November 17, 2009 16:06:07

Index: abjad/tools/mathtools/divide_scalar_by_ratio.py

--- abjad/tools/mathtools/divide_scalar_by_ratio.py ( revision 2810 )
+++ abjad/tools/mathtools/divide_scalar_by_ratio.py (working copy)
@@ -27,4 +27,5 @@
if not isinstance(scalar, (int, float, long, Rational)):
raise TypeError

  • return [scalar * p / sum(ratio) for p in ratio]
  • factor = scalar / sum(ratio)
  • return [p * factor for p in ratio]

Original issue: http://code.google.com/p/abjad/issues/detail?id=26

Extend abjad-book to work with LaTeX \input and \include commands

From [email protected] on March 06, 2010 15:57:32

The following input to abjad-book does not work:

%%% BEGIN %%%

\documentclass[12pt]{article}
\begin{document}

This is text.

\input{abjadstuff}

This is more text.

\end{document}

%%% END %%%

It should be possible to externalize large sections of Abjad code in
external files, such as abjadstuff.tex in the example above. But abjad-book
does not currently work in this situation.

Original issue: http://code.google.com/p/abjad/issues/detail?id=31

Abjad doc build scripts generate Sphinx v.1.0.4 warnings

From [email protected] on October 12, 2010 12:18:39

Running make-abjad-api with Sphinx v.1.0.4 generates many errors of the following form:

/Users/trevorbaca/Documents/abjad/trunk/abjad/docs/chapters/api/tools/verticalitytools/label_vertical_moments_in_expr_with_pitch_numbers.rst:2: WARNING: duplicate object description of abjad.tools.verticalitytools.label_vertical_moments_in_expr_with_pitch_numbers, other instance in /Users/trevorbaca/Documents/abjad/trunk/abjad/docs/chapters/api/tools/verticalitytools/label_vertical_moments_in_expr_with_pitch_numbers.rst, use :noindex: for one of them

These warnings were not generated under Sphinx v.1.0.1.

These warnings do not prevent the docs from building successfully.

But the Abjad doc building scripts headed by make-abjad-api should be cleaned-up to avoid these warnings.

Original issue: http://code.google.com/p/abjad/issues/detail?id=39

tools.mathtools.divisors: optimization to make O(n^0.5) rather than O(n)

From [email protected] on November 17, 2009 16:59:30

Here is an optimization that is 50% faster on "for x in range(10,20):
divisors(x)" than the original version, mainly because it's an O(n^0.5)
rather than O(n) operation. If the pollution of the 'sqrt' function is an
issue, that can be fixed.

Index: abjad/tools/mathtools/divisors.py

--- abjad/tools/mathtools/divisors.py ( revision 2810 )
+++ abjad/tools/mathtools/divisors.py (working copy)
@@ -1,3 +1,4 @@
+from math import sqrt
def divisors(n):
'''Return a list of the integer divisors of n in increasing order::

@@ -36,10 +37,17 @@
if n <= 0:
raise ValueError

  • result = [ ]
  • for i in range(1, n + 1):
  •  quotient = float(n) / i
    
  •  if quotient == int(quotient):
    
  •     result.append(i)
    
  • Find all divisors from 1 to sqrt(n)

  • divisors = [ 1 ]
  • for i in range(2, int(sqrt(n)) + 1):
  •  if n &#37; i == 0:
    
  •     divisors.append(i)
    
  • codivisors = [ n / i for i in reversed(divisors) ]
  • If the number is a perfect square, we dont want the sqrt in the list

twice

  • if divisors[-1] == codivisors[0]:
  •  divisors.pop()
    
  • divisors.extend(codivisors)
  • return result
  • return divisors

Original issue: http://code.google.com/p/abjad/issues/detail?id=27

Optimize source tree layout

From [email protected] on October 01, 2009 08:07:34

Right now the first level of the source tree looks like this:

init.py comments hairpin numbering spanbar
init.pyc component harmonic octavation spanner
accidental container history offset staff
articulations context instrument override staffgroup
barline core interfaces parentage stem
barnumber crescendo layout pianopedal templates
beam debug leaf pitch tempo
book decrescendo lily rational text
bracket demos markup receipt thread
brackets directives measure rest tie
breaks documentation meter scm tools
cfg dots metricgrid score tremolo
checks dynamics navigator scr trill
chord exceptions note skip tuplet
clef glissando notecolumn slur update
cluster grace notehead spacing voice

I think that the source tree will better model the runtime usage of
system objects if we instead organized something like this:

init.py
init.py
book
cfg
components
core
demos
documentation
exceptions
interfaces
rational
scm
spanners
scr
templates
tools

This new layout would take us from a relatively wide and shallow source
tree (which is what we have now) to a relatively narrower and deeper
source. This would be the case primarily because the components/,
interfaces/ and spanners/ diretories would each contain many
subdirectories. (Also, that's one of the things that makes it clear that
components, interfaces, spanners and tools are the most important elements
in the entire system.)

The driving motivation behind the new layout is to finally fix almost all
less-than-elegant interpackage dependencies in the system. There are still
some points of weirdness in, for example, the way the import statements
work at the top of some of the source files, due to the appearance of
circular imports in a couple of cases (if we try to clean up some of the
remaining imports).

The change will definitely break absolutely everything at the beginning. So
the way to make the change is to take a weekend morning and make a
completely separate working copy, try to the make the changes, iteratively
run the tests, and then check back in when everything is working. Do not
try to make any other changes, no matter how minor, when making this change.

Original issue: http://code.google.com/p/abjad/issues/detail?id=17

LilyPond BarLine overrides must cross Abjad measure boundaries at format time

From [email protected] on June 27, 2009 12:19:51

Consider the Abjad code that generates the following four measures.

staff = Staff(RigidMeasure((1, 8), [Note(0, (1, 8))]) * 4)
staff.formatter.number.measures = 'comment'

\new Staff {
% start measure 1
\time 1/8
c'8
% stop measure 1
% start measure 2
\time 1/8
c'8
% stop measure 2
% start measure 3
\time 1/8
c'8
% stop measure 3
% start measure 4
\time 1/8
c'8
% stop measure 4
}

Now change only the second barline to a double bar. And then try to
override the color of the double bar to red.

staff[1].barline.kind = '||'
staff[1].barline.color = 'red'
staff[1].barline.promote('color', 'Staff')

\new Staff {
% start measure 1
\time 1/8
c'8
% stop measure 1
% start measure 2
\override Staff.BarLine #'color = #red
\time 1/8
c'8
\bar "||"
\revert Staff.BarLine #'color
% stop measure 2
% start measure 3
\time 1/8
c'8
% stop measure 3
% start measure 4
\time 1/8
c'8
% stop measure 4
}

Everything here is completely correct, as far as the current implementation
of the system goes. But LilyPond renders the FIRST barline as red rather
than the SECOND barline as red. So we wind up with a red single bar and a
black double bar. See png.

What's going on here has to do with the a model conflict between the Abjad
idea of the containerized measure and LilyPond's rules for when to
instantiate a new barline. We can understand the details by paying
attention to the lexical arrangement of NOTE and override commands.

Specifically, LilyPond interprets the first leaf, sees that a moment equal
to 1/8 has passed, and now knows that it is time to draw a barline.
However, PRIOR TO drawing the first barline, LilyPond reads more input and
finds the red \override command. LilyPond interprets the red \override AND
ONLY THEN draws the first barline. This means that the first barline comes
out red.

LilyPond then read the next leaf, sees that another 1/8 has passed, knows
that it's time to draw the next barline, interprets the double bar ||
directive AND ALSO interprets the color \revert. Lily then draws the second
barline. The second barline comes out as a black double bar.


I can think of a couple of solutions. But they mostly involve doing fairly
tedious things with the way the formatting system moves things into and
out of slots at format time.

Any suggestions?

(Incidentally, the workaround until the model fixes this problem is to use
the directives interface attached to either a measure or the last note in
each measure.)

Attachment: barline-overrides.png

Original issue: http://code.google.com/p/abjad/issues/detail?id=4

Alphabetize overrides lexically, not according to system source

From [email protected] on September 29, 2009 13:43:58

Abjad currently prints the following score overrides in the order given below:

  \override TimeSignature #'stencil = ##f
  \override NoteColumn #'ignore-collision = ##t
  \override SpacingSpanner #'strict-grace-spacing = ##t
  \override SpacingSpanner #'strict-note-spacing = ##t
  \override SpacingSpanner #'uniform-stretching = ##t
  proportionalNotationDuration = #(ly:make-moment 1 16)

The reason for this is that the TimeSignature override comes from the
MeterInterface, the NoteColumn override comes from the NoteColumnInterface
and the remaining overrides come from the SpacingInterface. This means that
Abjad orders overrides alphabetically according to the source of the
override within Abjad
, ie, the three different interfaces listed here.

Better will be to organize the overrides strictly lexically like this:

  \override NoteColumn #'ignore-collision = ##t
  \override SpacingSpanner #'strict-grace-spacing = ##t
  \override SpacingSpanner #'strict-note-spacing = ##t
  \override SpacingSpanner #'uniform-stretching = ##t
  \override TimeSignature #'stencil = ##f
  proportionalNotationDuration = #(ly:make-moment 1 16)

The reason being that Abjad system element names -- like MeterInterface --
are more likely to change than the underlying LilyPond code. Weak coupling
suggests this ordering.

Original issue: http://code.google.com/p/abjad/issues/detail?id=15

Abbreviate spanner contents at prompt

From [email protected] on May 21, 2009 09:11:26

Given the following spanner definition

abjad> t = Staff(Note(0, (1, 4)) * 400)
abjad> p = Tempo(t[:])

it is currently unmanageable to ask for

abjad> p

because the spanner's repr implementation blindly pushes all spanner
contents.

Better would be some sort of smart abbreviation. Something like

Tempo(c'4, c'4, c'4, ... [396] ..., c'4, c'4, c'4)

instead.

Original issue: http://code.google.com/p/abjad/issues/detail?id=1

Add Sphinx :property: interpreted text role

From [email protected] on June 22, 2009 07:34:45

Sphinx provides :class: and :func: interpreted text roles. Abjad implements
many read-only properties using the Python @Property decorator. To document
Abjad properties correctly in Sphinx we need to add a :property:
interpreted text role similar to the :class: and :func: roles.

The :property: interpreted text role should inherit all formatting
attributes of the existing :func: role but without appending the ( ) empty
pair of parentheses after the name of the property.

Original issue: http://code.google.com/p/abjad/issues/detail?id=2

Eliminate meter redundancy

From [email protected] on September 30, 2009 08:31:29

Three time signatures appear in the following example.

staff = Staff(RigidMeasure((2, 8), construct.scale(2)) * 3)
\new Staff {
{
\time 2/8
c'8
d'8
}
{
\time 2/8
c'8
d'8
}
{
\time 2/8
c'8
d'8
}
}

This has been the behavior in Abjad since the beginning.

However, LilyPond will render each of these measures with a time signature.
This is contrary to conventional engraving practice. So Abjad should change
to format the meter for only the first of these three measures.

This change will be easy to implement as a look-behind type of change at
format-time using iterate.measure_prev( ). However, this change will
probably break a very large number of tests.

Original issue: http://code.google.com/p/abjad/issues/detail?id=16

Display Abjad version and build number (revision) at start-up

From [email protected] on July 19, 2010 12:03:39

Abjad starts up silently. When updating to a different version of Abjad it will be helpful to see the Abjad version (1.1.2, 1.1.2, 1.2.x, etc.) and also the revision number ( r3232 , r3233 , etc.). For example:

Desktop$ abj
Abjad 1.1.2 ( r3232 )

Python implements currently this behavior:

Desktop$ python
Python 2.6.1 ( r261 :67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

The relevant code should be added in the Abjad initializer at abjad/init.py

Original issue: http://code.google.com/p/abjad/issues/detail?id=35

Implement generalized ScoreStructureWrapper

From [email protected] on December 27, 2010 13:12:24

The following is an enhancement and not a fix.

Background:

Tie chains (not TieSpanner instances, but tie chains) should be a custom class; currently tie chains are simply a tuple of components governed by a single TieSpanner.

There would also be advantages to having both the proper and improper parentage of a component modeled by a custom class. Proper and improper parentages are currently a tuple of components, somewhat analogously to tie chains.

VerticalMoment is currently a custom class.

Enhancement: all three (or four) such classes -- VerticalMoment, TieChain, (Im)ProperParentage -- model the same sort of thing. That is, a type of relationship obtaining in an arbitrarily complex score at a given moment in the development of the score. All these could inherit from a custom ScoreStructureWrapper class.

Original issue: http://code.google.com/p/abjad/issues/detail?id=45

abjad-book interpreter capture

From [email protected] on September 29, 2009 09:47:11

abjad-book currently does not capture (or format) responses from the Python
interpreter. For example, abjad-book processes the following block ...

my_list = [1, 2, 3] list

... to produce this two-line output ...

abjad> my_list = [1, 2, 3]
abjad> my_list

... instead of this better three-line output:

abjad> my_list = [1, 2, 3]
abjad> my_list
[1, 2, 3]

This enhancement to abjad-book would make writing documentation easier.

Original issue: http://code.google.com/p/abjad/issues/detail?id=14

Implement redo( ) io tool

From [email protected] on October 03, 2009 16:22:15

Right now we have ly( ), pdf( ) and log( ) that open the last generated
.ly, .pdf and log files, respectively. These are good. We should add a
redo( ) io tool that recompiles the last .ly file. This will allow you to
use ly( ) to see (and possibly tweak) the last .ly file and then return to
the Abjad interpreter and recompile with redo( ).

Original issue: http://code.google.com/p/abjad/issues/detail?id=21

Extend RigidMeasure with meter-invariant contents management methods

From [email protected] on August 04, 2009 18:39:55

Current implementation of RigidMeasure is 'smart'. That is, current
implementation of RigidMeasure makes meter changes as contents move into
and out of the measure:

abjad> t = RigidMeasure((3, 8), construct.scale(3))
abjad> t
RigidMeasure(3/8, [c'8, d'8, e'8])
abjad> t.pop( )
Note(e', 8)
abjad> t
RigidMeasure(2/8, [c'8, d'8])

This makes sense.

But it also makes sense to extend RigidMeasure into yet another measure
type that will keep meter absolutely invariant as measure contents changes,
raising UnderfullMeasureError or OverfullMeasureError only at format time.

Original issue: http://code.google.com/p/abjad/issues/detail?id=11

Implement rich comparators on note, rest, chord and skip

From [email protected] on October 15, 2010 11:21:13

Right now note, rest, chord and skip implement eq and ne but do not implement gt, ge, lt or le.

Rest and skip should implement gt, ge, lt, le in terms of multiplied duration, written duration and lilypond multiplier, in that order.

Note should implement gt, ge, lt, le in terms of pitch, multiplied duration, written duration and lilypond multiplier, in that order.

Chord should implement gt, ge, lt, le in terms of pitches, multiplied duration, written duration and lilypond multiplier, in that order.

Original issue: http://code.google.com/p/abjad/issues/detail?id=40

Test doc string examples

From [email protected] on November 18, 2009 16:13:41

Doc string examples are not currently tested. This isn't an enormous
problem because py.test tests more than 2500 dedicated tests that exist
outside of the doc strings. However, Sphinx picks up the doc strings at
API build-time. So it's a matter of doc quality control that we should test
the doc string examples.

Possible ways to do this:

  1. with Sphinx.
  2. with one of the Python doctest tools.
  3. with the Abjad scr/devel/make-abjad-api script.
  4. with the Abjad scr/abjad-book script.
  5. with some custom still to be written.

Original issue: http://code.google.com/p/abjad/issues/detail?id=30

Document abjad-book dependencies

From [email protected] on March 08, 2010 09:22:30

abjad-book depends on the Linux 'pdfcrop' utility: http://pdfcrop.sourceforge.net/ The Linux 'pdfcrop' utility in turn depends on the Linux 'poster' utility:

ftp.kde.org/pub/kde/printing/

Note that 'poster' sources from the link above must still be compiled after
download.

Both dependencies should either be documented or, preferably, handled on
installation of Abjad.

Original issue: http://code.google.com/p/abjad/issues/detail?id=34

Consider overriding _Component.__copy__ and _Component.__deepcopy__

From [email protected] on August 12, 2010 15:52:55

Consider ...

abjad> iottools.profile_expr('Note(0, (1, 4))')

     3003 function calls (2976 primitive calls) in 0.009 CPU seconds

... BUT ...

abjad> iotools.profile_expr('Note(0, (1, 4)) * 100')

     2436053 function calls (2022727 primitive calls) in 4.044 CPU seconds

... meaning that copy and deepcopy based on, for example, component skeleton logic should be about 10 times faster than Python standard copy and deepcopy.

Original issue: http://code.google.com/p/abjad/issues/detail?id=37

Do not load interfaces into global Abjad namespace at start-up

From [email protected] on July 27, 2009 10:15:53

Recent commits turned private _AccidentalInterface into public
AccidentalInterface. This is good because AccidentalInterface will now be
documented in the public API whereas private _AccidentalInterface would not
be documented in the public API.

However this change from privately name interfaces to publicly named
interfaces had the consequence of causing all public interfaces to load
into the global Abjad namespace at start-up.

For example:

abjad> len(dir( ))
195
abjad> [x for x in dir( ) if 'Interface' in x]
['AccidentalInterface', 'ArticulationsInterface', 'BarLineInterface',
'BarNumberInterface', 'BeamInterface', 'BracketsInterface',
'BreaksInterface', 'ClefInterface', 'ClusterInterface', 'DotsInterface',
'DynamicsInterface', 'GlissandoInterface', 'GraceInterface',
'HarmonicInterface', 'HistoryInterface', 'InstrumentInterface',
'InterfaceAggregator', 'MarkupInterface', 'MeterInterface',
'NoteColumnInterface', 'NoteHeadInterface', 'NumberingInterface',
'OffsetInterface', 'OffsetProlatedInterface', 'PianoPedalInterface',
'RestInterface', 'ScoreInterface', 'SlurInterface', 'SpacingInterface',
'SpanBarInterface', 'StaffInterface', 'StemInterface', 'TempoInterface',
'TextInterface', 'ThreadInterface', 'TieInterface', 'TremoloInterface',
'TrillInterface', 'TupletBracketInterface', 'TupletNumberInterface',
'UserDirectivesInterface', 'VoiceInterface']

The import tools should change to no longer load any name ending with the
string 'Interface'.

Original issue: http://code.google.com/p/abjad/issues/detail?id=7

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.