Can't Create Chord with Cram Expression

[tmountain]

🐞 Bug report 🐞

Co-mingling a cram expression with a chord doesn't seem to work.

Description

If you want to lead out of a chord with a swing-type melody, you could potentially accomplish this by mixing a cram expression with a chord; however, this produces an error:

alda> piano: o4 d1/f/a/c/{>f4. e4}4
ERROR: <no file>:1:20 Unexpected start of cram expression `{` in chord

Steps to Reproduce

1. Type the code above into the REPL.

Yes.

Yes, see above.

No.

Expected Behavior

I'd expect the melody to play alongside the chord.

Actual Behavior

Syntax error.

Environment

Operating system and version:

macOS

Alda version:

$ alda version

alda 2.2.1

$ alda-player info
alda-player 2.2.1
log path: /Users/traviswhitton/Library/Caches/alda/logs

Health check:

$ alda doctor
OK  Parse source code
OK  Generate score model
OK  Ensure that there are no stale player processes
OK  Find an open port
OK  Send and receive OSC messages
OK  Locate alda-player executable on PATH
OK  Check alda-player version
OK  Spawn a player process
OK  Ping player process
OK  Play score
OK  Export score as MIDI
OK  Locate player logs
OK  Player logs show the ping was received
OK  Shut down player process
OK  Spawn a player on an unknown port
OK  Discover the player
OK  Ping the player
OK  Shut the player down
OK  Start a REPL server
nREPL server started on port 61220 on host localhost - nrepl://localhost:61220
OK  Find the REPL server
OK  Interact with the REPL server
OK  Shut down the REPL server

[daveyarwood]

Hi, thanks for reporting this!

I think the challenging thing here is that a chord is represented as a structure that includes 2 or more notes. Octave and other attribute changes are also allowed, e.g.:

piano:
  o4 c1/e/g/>c
  o4 (ff) c1 / (mf) e / (mp) g / > (p) c

And rests are also allowed, in order to support entwining a melody with a chord, as described here:

piano:
  c1/e/g/r4 b e g

This works because the next note/rest following a chord is placed after the shortest note/rest in the chord.

But I don't know if I want to allow things like cram expressions or event sequences (which are conceptually similar to cram expressions) to be allowed as part of a chord, because it would make the idea of a chord in Alda a little too complex. I like that at the moment, (even though we also technically allow rests and attribute changes), we can conceptualize a chord in Alda as essentially "2 or more notes, played at the same time."

---

I can think of a couple of workarounds that I think would be equivalent to your example:

1. You could put the chord and the melody in separate voices:

   piano:
   V1: o4 d1/f/a/c
   V2: o5 {f4. e4}4

2. You could calculate the length of the melodic notes as hypothetical standard music notation lengths:

   piano: o4 d1/f/a/c/>f10. e10

In this case, it's a "dotted 10th note" followed by a "10th note." (Real musicians would look at you funny if you started talking about "10th notes", but mathematically, they make as much sense as 8th notes or any other fraction you can think of!)

[tmountain]

Hi,

Thanks for the quick reply. I actually think expressing the chords and melody as separate voices is okay, as it separates concerns (harmony vs melody); however, it is counter intuitive as a guitarist, as I frequently co-mingle melodic lines with shell chords in a single performance. This doesn't cause a problem at the moment, as your solution allows me to express my idea using Alda; however, I'm wondering if it might cause confusion when exporting to MusicXML is finished, as I might want to write (and listen to) a series of lines in a swing rhythm, and look at that on a single staff.

Honestly, if there were just a simple way to specify that the player should swing eighth notes, it would eliminate the need for using cram notation (and simplify Alda notation as well). Clearly, the playback engine can support this since cram notation provides the desired result: {f4. e4}4. Maybe some kind of macro expansion when in swing mode would help solve it.

Anyway, this program is really really cool. I'm loving using it to prototype little harmonic/melodic ideas, and it really fills a great niche. Being able to produce written notation would be a god send. Closing the issue, as you've solved my issue. Thank you!

[daveyarwood]

I'm interested in adding "swing" support if we can, but I think it might be challenging because Alda doesn't have any notion of where the downbeats are -- see my comments here. It might be possible to work around that for the common case, because it would be a useful feature for sure.

[daveyarwood]

I think perhaps the "Alda way" (for now, at least) is to use non-standard note lengths. You can get a 2/3 swing (i.e. triplet quarter+eighth) feel by using 6th and 12th notes:

piano: c6 d12 e6 f12 g6 a12 b6 > c12

But I understand that this is cumbersome when, as a jazz musician, you want to think in terms of eighth notes:

piano: c8 d e f g a b > c

(and that's a lot easier / faster to write, too)

[tmountain]

A few thoughts.

1) I understand the issue with knowing where the downbeats are; however, I think you can leave that to the transcriber. Meaning--just assume that they want pairs of eighth notes to be treated like {c4. d4}4 without having to write that. Assuming that the composition starts on the one beat, they can add pairs of eight notes (and rests, etc) in a way that their composition flows with rhythm of the song.

2) Regarding using non-standard note lengths, I'll be honest. I hate that. In my mind, a project like Alda exists to bridge the gap between musician and programmer. Changing note values to non-standard lengths feels like "reinventing" music, and I think that's a bridge too far. Swinging eighth notes is a very standard thing, and it's well understood across the world. I wouldn't drive towards a solution that deviates from what a musician would typically expect.

That said, I really appreciate the thought you guys are putting into trying to help solve this problem, so consider point #2 to be friendly constructive criticism.

[daveyarwood]

I appreciate your perspective on that, and I agree! I'll keep thinking about ways that we could implement swinging as a first-class feature.