How are pitch bends notated?

For well over a year, I have been asked to add pitch bends to my music engine Pently. How are pitch bends typically notated in a musical score?

As a child, I took piano lessons and played trumpet in the school concert band. The piano is a discrete-pitch instrument. So are most instruments in a concert band, which use keys or valves to select a pitch. Only a fretless instrument is capable of a continuous pitch slide from one note to another. These include voice, fretless string instruments, and slide wind instruments such as the trombone or slide whistle. I really wasn't exposed to a lot of music heavily exploiting this while growing up, other than as a variant realization of grace notes. So the music theory that grew in my head over these years didn't have much to say about pitch bends.

A pitch can be represented in one of three ways:

1. Period: Time between repeats of the waveform
2. Frequency: Repeats of the waveform per unit time, reciprocal of pitch
3. Log frequency: Logarithm of the ratio between the frequency of the waveform and that of the first note of the scale. This most closely matches human perception of pitch.

Most of classical music theory is based on relationships in the log frequency domain. Equal temperament measures intervals in "semitones", a logarithm to the base twelfth root of two. For example, an octave (2:1 frequency ratio) is 12 semitones, and a perfect fifth (3:2 frequency ratio) is 7 semitones.

But synthesizers don't directly use log frequency. Instead, they use either period or frequency. Like string instruments, classic square wave based synths (e.g. AY-3-8910, SN76489, Atari TIA, 2A03, VRC6, and Game Boy PSG) use period, as do some samplers (Amiga and Nintendo DS). FM chips (e.g. YM2612) and other samplers (e.g. Sony S-DSP) use frequency instead, sometimes with a power-of-2 prescaler to set the octave.

Because my experience before designing Pently was for discrete-pitch instruments, I designed Pently to use discrete pitch. But later, I ran into issues with video game music composers who rejected Pently for not having the portamento and vibrato effects. I figured out a way to make vibrato whose depth in log frequency is the same at any pitch, using an algorithm that would be easy to adapt to either a period synth or a frequency synth and with the oscillation frequency fixed at 4 to 5 Hz, which I found most typical in instrumental music.

But portamento is a different beast entirely, as it involves two different pitches. Try to slide the period linearly, as most Amiga-style trackers do, and it'll sound faster at high pitches because there each period step is larger in log-frequency space. Try to slide the frequency linearly, and it'll sound faster at low pitches because there each frequency step is larger in log-frequency space. Sliding the log frequency is difficult on an 8-bit processor, as many music engines operate using a lookup table from log frequency to period or frequency, with one entry per semitone. For a pitch bend of less than an octave, a linear period or frequency slide is unlikely to matter. But the composer who requested this feature has a habit of using bends that are both very slow (a semitone over the course of a quarter note) and very fast (multiple octaves in a sixteenth note), and a multi-octave bend sounds noticeably different when done as period, frequency, or log frequency.

So I was hoping to look for inspiration from musical notation for strings, trombone, or voice to see how they approach pitch bend.

If you fail to understand anything in this question, let me know the first thing you failed to understand, and I will try to explain further or draw and attach an illustration.

A few things I remember from music theory and band:
wikipedia:Glissando
wikipedia:wikipedia:Slide (musical ornament)

I don't know if any of these help...

There isn't really a standard notation. The glissando as a wiggly line like in the article lidnariq linked is well known enough-- have seen it in lots of trombone parts in classical scores. It's a bit ambiguous though, since it originally comes from harp or keyboards where you're dragging your hand along the strings/keys producing a series of discrete notes. (Kind of a holdover from the 19th century.)

Some really pedantic ones put the word mark "gliss." over the squiggly line (or even just over a phrase ligature). Some use very atrocious notation like a series of small chromatic notes despite it being a continuous slide. I don't recommend that. I'd also ignore the funny marks you see in that "slide" article that was linked. They're quite archaic and not well known unless you study Baroque music (17-18th century), which that article is narrowly about despite its generic seeming title.


On many modern scores I've seen just a straight line instead of the squiggly line, which looks nicer and cleaner, IMO. Usually it applies to scores for instruments with an inherent slide, like trombone, slide guitar, etc.

I'd generally recommend just doing that (straight line) if it's an instrument where slides are common, but if it's an instrument where they're less common or you think it's ambiguous you might put a clarifying mark like "(slide)" over the first one in the piece?


The definitive guide to music notation is this book by Gardner Read: Music Notation: A Manual of Modern Practice

If you have interest in the topic I'd highly recommend that book. It's very well written, and is a very comprehensive survey of good ideas for musical notation.

Might also be worth noting, lilypond does it with \glissando, which produces a straight line.

Somewhat related, I used lilypond to make a score for a saxophone transcrption, and then later wrote an NES program to play it back. I used lilypond's glissando feature, but I added a custom \glissin to notate a bend into a note from below (common in this particular piece), and increased the thickness of the lines: coltrane.ly

One more note about precision. Gliss marks are not normally used in a precise way. If the notation seems a bit "loose" it's because most of the time the application of the slide is left for the human performer to interpret.

While a precise slide should have a start and end note that the slide goes between, there are lots of occasions where a precise starting pitch or timing isn't needed (e.g. pitch bend into a note). For a precise starting pitch but imprecise timing, you can use a small note ("grace" note) to start the slide, like in the example I gave above. If a start or end pitch doesn't need to be specified, the gliss mark might terminate at a vague location. (Often trombone "fall" marks are sort of a curve line with a rough or tapered end to indicate the vagueness of its end.)

Precise timing is more difficult to express, i.e. if there are two notes with a gliss between, when does the gliss start and stop? In a lot of cases precision is not expected, but where it is, I've seen a convention that the gliss should last the entire length of the note preceding the gliss mark (starting immediately at the start of that note) and finish on the note following it. If you want to end on a pitch but also end the tone at the same time, you could place a small note before a rest, and gliss to that. If you need a held pitch before starting the gliss, make two notes and tie them, then start the gliss from a second one (i.e. holds for the duration of first note, then begins gliss from second one) that goes to a third note where the gliss ends.

Imprecise pitch effects get used a lot in Jazz, see this article under "Effect Articulations" for some examples, though there is a bit of variety between various pulishers here. The examples in the article are fairly common and understood, but there's alternative ways to do everything.

(I keep saying "small note" instead of "grace note" because there's some for whom it means a very specific thing.)

(Also, sorry for 3 posts. I'm a trombone player with a degree in music, so it's kind of in my sphere of interest.)

As for the technical hurdles for implementing logarithmic frequency slides, maybe this article titled A 9-bit pitch technique by lft might inspire some solution. The basic premise is working with a 48 step per octave scale.

In guitar tabs, slides are done like this.

5/7 (slide from 5th fret to 7th)
3\1 (slide from 3rd fret to 1st)

5~~~ (vibrato)

A bend is done like this
5b6 (bend 5th fret equivalent to the next fret, ie. 1/2)
5\4/5 (start 5th fret, tremolo bar dip down to 4 and back)

I've also seen...
5^ (slight bend up and back down)

Edit, I suppose b would be confusing, since it's also used for flat notes.

Also..
< volume swell
> volume fade

There is several approaches :

1) Do not handle the logarithmic aspect at all. Just compute the pitch value written to hw registers, and interpolate from those and/or just add constant values to those modifying pitch/period directly. Many early sound engine does this, for instance in Battletoads & Double Dragon at the end of Level 3 you can observe a sound effect which is a pitch sliding down for a long period of time, it goes lower and lower at a slower and slower pace, simply because some constant is being added to the square waves pitch. Also all Squaresoft SNES SPC sounds functions like that. I do not know other engines because I haven't reverse engineered them, but I suspect many works like that.

2) Use a pitch system internally with a precision lower than a note. For instance, a precision of 32 points per semitone is nice to have, allowing to have 384 points per octave. Have a period table of those 384 points, and shift the values left and right to reach other octaves. My sound engines works like that, but also the one of Just Breed on the NES, which I reverse engineered its sound engine.

One big problem with this solution when applied to the NES platform is that vibratos of small amplitude becomes problematic at higher pitches (i.e. lower periods), as the hw period register is less precise than the 32 point per semitones used internally, leading to a weird effect I cannot describe in english. Actually this is a problem with all solutions anyway, but it's particularly notable here.

3) Same a 2, but use a regular pitch table having only points for notes, i.e. a normal pitch table. Use linear interpolation between two notes, then the pitch slide becomes linear on a global scope, but logarithmic between two adjacent notes. I doubt anyone would notice the difference. The note table can be either one octave or all octaves - it doesn't matter at this point. I do not know of any sound engine using this technique, but I'll probably use it whenever I'll ever write any new sound enigne, as it allows saving ROM for a pitch table of 384 semitoes, and the loss of precision is negligible.

Actually a trumpeter can reach at least one semitone of pitch just by moving its lips. Vibrato is indeed possible to have in a trumpet, but is difficult to perform at the higher and lower range of the instrument.

It's relatively easy to produce vibrato on a trumpet just by gently moving the trumpet back and forth while playing it.

But doing it that way is wrong, at least I have been taugth. Don't ask why, the guy who was my professor back then told the only 2 proper ways to do it were with the lips and with the air, I never managed to do the 2nd way so if I want to do a vibrato I do it with lips, it's actually pretty simple.

Huh. Never heard that, though I only took a little bit of trumpet.

It seems like you have two questions:
X. how can I get an exponential curve on my period when shifting cheaply?

4) do like the sweep unit in the APU does, and shift the current period right N bits to add to it, thereby getting free exponential curve like you want, as d/dp ~ p.

Or perhaps use a table by octave number with your slide speed. In *some* manner make [ab]use of the fact that an octave change changes the frequency/period by a factor of 2, which is a cheap operation.

Y. how is a pitch-bend notated?
I didn't know, but I did find some handy-looking answers searching.
http://www.frankgambale.com/guitar_notation_legend.pdf is the best set of visual answers I found. https://musescore.org/en/node/17458 says that they're generally notated as glissandos or slurs.

Thanks rainwarrior for the trombone player's perspective.


That's what I'd do on an SPC700, which can multiply Y by A. But multiplication is quite a bit slower on a 6502.


That's similar to what I'm doing for vibrato: multiplying the current period by an approximate sinusoid, shifting right N bits, and then adding that to the note's period. But to put that into practice for portamento, I'd need to know whether a shift amount like that has enough resolution to cover all musically useful portamento speeds, especially whether I'd need to also make it proportional to the scale distance from the starting pich to the ending pitch.


Thanks. Mostly I was looking for notation as a way of estimating what sort of data I'm expected to include in a digital representation of a bend in a score so that the player can interpret that data.

Yeah, it's probably not the best technique, but I've known players that do it. (example)

As far as I know there is no notation for pitch bend. If there isn't one then it can be made up; in order to do so, figure out what is Italian words for pitch bend (I guess "portamento" is probably the closest word, which is known in English as well specifically for this purpose) and then that is the notation. Perhaps combine it with the glissando notation; and then the words specify that it is a continuous pitch slide. (I don't expect it help much with designing Pently, but it can help if you want to notate it I suppose. Figuring out best way to make the bend seem more difficult.)

The connection between an ornament's notation and its representation in Pently is that if I can see what different composers have notated as to their intent with this ornament, specifically how it differs from the discrete grace notes that are already supported, I can design the representation to match the most common intents.

Some MOD formats implement linear pitch (logarithmic frequencies) as discrete steps, I think commonly 64 per semitone? You could implement something similar with a table of 12 note frequencies * 20 divisions of the semitone, and apply octaves through bit-shift operations. This would make linear pitch slides very simple, though granular, but I wouldn't expect the granularity to be a significant problem.

If you're talking about tool/UI notation as well, most musical editors I've seen generally treat a pitch slide as an effect applied to a note that otherwise appears "flat". MIDI piano roll editors will often just show a note as a straight horizontal bar, and a pitch bend would be an effect applied to the channel (visible on a separate control track below the note field, sometimes). With MOD trackers similarly you just play a note and then apply pitch changes in the effect column. I mentioned with lilypond how you just write \glissando between two notes for that, etc, which seems fine for text-based input.

PXTone does a piano roll, but I think it actually notates pitch bends with a bent note bar to show where it ends, which is pretty cool. (I don't have it installed or I'd take a picture.)

With formats such as MOD/IT/XM/S3M, there are two common kind of portamento which can be "Amiga portamento" (meaning working with period values) or "linear portamento" (meaning working with a logarithmic scale). There are then commands which apply portamento up or down by a specified speed. AmigaMML (which compiles into MOD/XM) supports two methods of specifying portamento, which are command envelopes (which are almost direct MOD/XM commands), and auto-portamento (only for XM with linear slides) which are indicated with a slash between notes (but I don't know if any other program does something similar to the way AmigaMML does it).

Who cares ? Multiplication is still possible on a 6502. If, after having designed the sound engine, it really turns out to be too slow, you can always optimize it using tables later. You can also do the (a+b)^2 - a^2 - b^2 trick, which makes some types of multiplication very fast on the 6502.

Also for the pitch table granularity trick, I think 21 pitches values per semitones could be a useful values as it prevents the octave table to be more than 255 entries. It is not as intuitive as using a power of 2 though.

Developers of games that aren't turn-based care.


So is floating-point math; see Applesoft BASIC. But not everything that's possible is wise, especially in an application with a real-time constraint.


I have done the math, and two 8-bit-by-8-bit multiplications without tables for each of the three pitched channels (pulse 1, pulse 2, and triangle) would add over 10 scanlines' worth of cycles to the cycle budget. In an engine targeted at NSFs and stand-alone music ROMs, such as FamiTracker's own engine, I could get away with fairly complex arithmetic. But Pently is targeted at real-time games. If I were to make a rule "portamento is permitted in menus and in turn-based games, just not in-game during real-time games", that would just turn into "Could you make portamento faster? The game for which I requested the feature is real-time."


When a music engine is on the order of 1.5K, and you're trying to squeeze it into your NROM or CNROM project or into the fixed bank of your UNROM, MMC1, or MMC3 project (so that you can put the songs and patterns into the switchable bank), a 1K quarter square table would nearly double it just for one effect. There's a set of flags for turning off each of several ROM-intensive effects at build time.

Nor do I want to have to maintain three or more different portamento implementations in the long term, one for each point on the time-space tradeoff curve:

1. Amiga-style period-space portamento, which is likely to sound significantly different if you transpose the music, play on NTSC vs. PAL, or reuse a piece of music on a different platform to which I plan to port Pently in the future, and is likely to break even more if you try to combine it with vibrato or arpeggio
2. Space-intensive portamento
3. Time-intensive portamento

What about linear slides (of period, I guess) from semitone to semitone, but re-indexing to the master tuning table as it crosses a threshold? (maybe one or two semitones, depending)

That could work.

I guess my real concern is how to express how fast the slide is.

In particular, the problem is the extreme dynamic range expected of a portamento effect. Some compositions using portamento want a rate of multiple semitones per frame, while others might be as slow as one semitone per second.

Pitch bend in MIDI sends the equivalent of one update per frame. Ex yy zz sets the pitch bend for channel x+1 to z*128+y, where that value ranges from 0 (minimum) through 8192 (centered) to 16383 (maximum). The range from minimum to maximum is implementation-defined, but PC-based MIDI implementations appear to default to a range of four semitones (center plus or minus two), and some synths allow changing the range using "registered parameter" control messages. But this representation is probably too data-dense for NES use, much like the rest of the MIDI and Standard MIDI File formats.

Trackers offer three models for pitch bend, all of which add or subtract a particular amount per frame as long as the effect is in operation. All support the period model; XM and IT also support a logarithmic model with 16 units per semitone.

1. Open-loop portamento
   1xx (MOD, XM, FTM), Fxx (S3M, IT): Slide up. Add x units per frame to period.
   2xx (MOD, XM, FTM), Exx (S3M, IT): Slide down. Subtract x units per frame from period.
   E1x (XM), EFx (S3M, IT): One-shot slide up. Add x units per row to period.
   E2x (XM), FFx (S3M, IT): One-shot slide down. Subtract x units per row from period.
2. Portamento to target
   3xx (MOD, XM, FTM), Gxx (S3M, IT): Change period by x units per frame toward the current note.
   5xy (MOD, XM), Lxy (S3M, IT): Continue previous portamento to target while adding x - y units to channel volume per frame.
3. Portamento by interval
   Qxy (FTM): Add y semitones to current note, then do 3zz where z = 2*x+1.
   Rxy (FTM): Subtract y semitones from current note, then do 3zz where z = 2*x+1.

I had planned to support only the portamento to target model, with the portamento by interval simulated by using a grace note followed by the target note, and the open-loop model as portamento by an arbitrary large interval.

XM also supports "glissando", which quantizes slides to semitones, controlled by effects E30 and E31.