Use __slots__ for simple objects that are used often about music21 HOT 6 CLOSED

Another caveat:

If any parent class of a class with slots does not also implement slots, then slots has no effect on the child class.

Luckily, a number of the classes listed above don't inherit from Music21Object (which we're not talking about slotting anytime soon). For example, DurationUnit is a good candidate for slots. But, I'm going to have to add slots to its parent class - DurationCommon - in order for this to work. Probably not a big deal, but we'll experiment and see how it goes.

from music21.

Right! I tried to exempt things that inherit from Music21Object for that reason. Another performance-oriented goal would be to eventually make Pitch not a Music21Object. We did that for maximum flexibility, because sometimes Pitches need to be placed on a Staff (like in a scale) in such a way to imply that they really have no duration, but I think that the overhead is high enough that we can make a Note subclass for these cases.

from music21.

Awesome. We're on the same page.

Slotting Pitch is a good eventual goal... I'm guessing there's on average one or more pitches per element in any given stream (since most elements are going to be notes and chords rather than anything else), so that could save a lot of memory. And if folks really want to put pitches into a stream at this or that offset, they might as well use notes in the first place!

from music21.

The Music21 Way (tm) -- not really trademarked -- has always been to model the conception of music that musicians have and then try to find a way to encode it/display it/etc. later. This has given us a lot of flexibility (for instance, there's no enforcement that Voices go in Measures; it could be vice-versa) and in general it's been a good thing. With Pitches, Chris and I thought, well, Pitches are different from notes in that they don't have a defined duration, but they can be put on a staff, like a note can; there's just no way to perform them until a duration is assigned to them. So the pitch.Pitch object is a music21object, since only m21objs can be placed on staves. But m21objects need to have a duration, so we give them a ZeroDuration object. Thus, if you call ".show('text')" on a scale or a twelve-tone row, you will see the pitches in order -- they all are at offset 0.0:

>>> from music21 import *
>>> s = serial.getHistoricalRowByName('RowSchoenbergOp25')
>>> s.show('t')
{0.0} <music21.pitch.Pitch E>
{0.0} <music21.pitch.Pitch F>
{0.0} <music21.pitch.Pitch G>
{0.0} <music21.pitch.Pitch C#>
{0.0} <music21.pitch.Pitch F#>
{0.0} <music21.pitch.Pitch E->
{0.0} <music21.pitch.Pitch G#>
{0.0} <music21.pitch.Pitch D>
{0.0} <music21.pitch.Pitch B>
{0.0} <music21.pitch.Pitch C>
{0.0} <music21.pitch.Pitch A>
{0.0} <music21.pitch.Pitch B->

I like this feature, but not enough to let it slow down the entire system, so its time may be up. We can always specify whether we want a list of pitches or a stream of notes for 12-tone-rows, scales, etc. We can also set up a Note subclass that by default is stemless and has zero duration. There are ways around this. We already speed up Pitch creation by making its .duration object a reference to the parent Note's Duration object.

This should be very low priority though, because I don't like denying people the right to store additional attributes on Pitch, so we should only do it if everything else doesn't give us the speedup we want.

from music21.

SpannerStorage is a Stream, so that will have to be skipped for now. Otherwise, all other classes are done.

from music21.

Closing issue. Looks good.

from music21.