

The Music Suite - nbouscal
https://music-suite.github.io/docs/ref/

======
muraiki
I'm very interested in learning more about "Include common notation and theory
as a special case" but the documentation for that isn't yet ready, and I also
have only elementary knowledge of Haskell. If this means what I think it
means, this project could be a great boon to anyone working with non-western
music.

For instance, when I first started learning programming my motivation was to
create a program to render Byzantine chant, which has a completely different
visual representation. Here's an example with the byzantine notation above the
western notation (the bottom staff is the ornamentation implied by the
byzantine notation): [http://www.cappellaromana.org/wp-
content/uploads/2014/04/Che...](http://www.cappellaromana.org/wp-
content/uploads/2014/04/Cherubic-Western-Pl-IV_Divine-Liturgy-Music_Cappella-
Romana.pdf)

Another different visual representation is that of shakuhachi music:
[http://www.rileylee.net/shaku_notation.html](http://www.rileylee.net/shaku_notation.html)

If anyone can offer tips on how to approach this problem, I'd be grateful. But
I might have to play with this. The code for my ill-fated attempt for
byzantine chant is here, if anyone is interested:
[https://github.com/muraiki/byzscribe](https://github.com/muraiki/byzscribe)

------
keehun
As a conservatory student and a long time user of LilyPond, it seems very
impractical as a daily musical notation tool after a quick glance at the
syntax.

ie: octavesUp 4 c in The Music Suite vs. c'''' in LilyPond

ie: Handling of staves and parts (as well as notes vertical to each other in
multiple staves) as a horizontal stack in the code is very opposite of how
music notation/engraver needs to think. In LilyPond (and any other music
engraving system), you define each part/line as a separate entity and tell the
system to put them together. Any discrepancies in how they actually stack up
(if one line is not the full duration of a measure at one point) will result
in an error with a debug statement.

However, there seems to be some philosophical difference from LilyPond these
developers are after. Very interesting and will have to follow.

~~~
tsm
c'''' is valid in The Music Suite as well.

That said, I won't be switching from ABC for my day-to-day music writing. I
see The Music Suite as being useful for, e.g., writing a fugue, where the
music can be elegantly expressed programmatically.

~~~
keehun
Ooooo, I never knew about ABC! It looks really concise and easy to use. Does
it scale well to big symphonic scores? (Or if you're not into that kind of a
thing, at least bigger projects than one page melodies of single lines?)

~~~
tsm
Here you go:
[https://gist.github.com/tsmacdonald/4175ff511ae99f862b61](https://gist.github.com/tsmacdonald/4175ff511ae99f862b61)
for the source, and
[https://www.dropbox.com/s/aslypeyw5fdku4u/emperory_germany%2...](https://www.dropbox.com/s/aslypeyw5fdku4u/emperory_germany%20copy.pdf)
for the PDF. It's still a work in progress, so the end is a bit off.

------
JonnieCache
Clojure fans should look at
[http://overtone.github.io/](http://overtone.github.io/) for something
similar.

Of particular note is the file
[https://github.com/overtone/overtone/blob/master/src/overton...](https://github.com/overtone/overtone/blob/master/src/overtone/music/pitch.clj)
which is an absolute work of art.

~~~
baldfat
I don't see this as similar?

overtone = Composing with code (Something Music Suite isn't really doing of
itself

Music-Suite = Creating, processing or analyzing music (Also notating from my
point of view)

~~~
JonnieCache
How do you see composing as different from creating in this context?

(Not being sarcastic. It's an interesting distinction.)

------
cannam
A few tangentially-related things:

If you're generally interested in this subject, a popular toolkit for
computational musicology outside of Haskell is Music21, in Python:
[http://web.mit.edu/music21/](http://web.mit.edu/music21/)

If you're interested in Haskell and music, you might like Renick Bell's
"Conductive" for Haskell-driven live coding music performance:
[http://www.renickbell.net/doku.php?id=conductive](http://www.renickbell.net/doku.php?id=conductive)
(video:
[http://www.youtube.com/watch?v=J5TskLgsdBU](http://www.youtube.com/watch?v=J5TskLgsdBU)
from last year's Linux Audio Conference; he gave another talk and concert this
year but I don't think the videos are available yet)

If you're generally interested in high-level functional language code to
analyse musical intention, the IDyOM project from Marcus Pearce in my own
group ([http://code.soundsoftware.ac.uk/projects/idyom-
project](http://code.soundsoftware.ac.uk/projects/idyom-project)) just made a
release of their Common Lisp software for predictive modelling of musical
structure.

~~~
byproxy
There's also Abjad: [http://abjad.mbrsi.org/](http://abjad.mbrsi.org/)

------
thinkpad20
Very cool stuff! Haskell is indeed great for this kind of thing; perhaps I
will get around to trying it out. A (very minor) issue:

> Actually, scat and pcat used to be called melody and chord back in the days,
> but I figured out that these are names that you actually want to use in your
> own code.

I would have preferred to see `melody` and `chord` over s/pcat because that's
what they're doing. The whole point of a declarative DSL like this is to be
descriptive. When I first saw `scat` I wondered if it was a shorthand for
`staccato`, or perhaps even a reference to scat singing? On the other hand,
not only are `melody` and `chord` very obvious, but they are also general
enough that they are rather unlikely to be used as variable names, except
perhaps as one-offs.

~~~
lachenmayer
There's an easy solution if you prefer to use those:

    
    
        melody = scat
        chord = pcat
    

I think the rationale is that you'd most often want `melody` to refer to the
melody of the whole song rather than some sequence of notes within your
melody.

------
diminish
I took a coursera class on ChucK music programming language. I recommend to
designers and musicians to have a look at it as well.

~~~
meleyal
[https://www.coursera.org/course/chuck101](https://www.coursera.org/course/chuck101)

------
anigbrowl
Pretty nice. I hope future versions will allow some sort of embedded
structures, eg for this segments

    
    
      let
          p1 = scat [c..c']^/4
          p2 = delay (1/4) $ scat [c..c']^/4
          p3 = delay (3/4) $ scat [c..c']^/4
      in (accent . legato) (p1 </> p2 </> p3)
    

I would have expected something like

    
    
          p2 = delay (1/4) $$ [p1] 
    

or somesuch (sorry about the notation, I've never used Haskell - my point is
about the nesting).

I would also love to see ways to define particular scales and modes and then
specify operations within that scale space without necessarily articulating
the individual notes. Of course at that point you're getting into
compositional tooling rather than transcription.

Anyway, nice work and great documentation so far. Also good that there's a
whole bunch of converters.

~~~
roryokane
I don’t know much about Haskell, but I looked up `let`’s documentation, and I
think it already does support embedded structures like you ask for. You can
just write `p2 = delay (1/4) $ p1` (and you can also leave out the `$` because
`p1` is already atomic). I think the site’s example repeats the definition of
`p1` just to make reading the example clearer, not because you are forced to
code like that.

~~~
cstrahan
Some extra background on `$`, for the curious:

Function application in Haskell is expressed like so:

> f x

Where `f` is a function, and `x` is it's argument. Function application is
left associative, so

> f x y

Is equivalent to

> (f x) y

In this case, `(f x)` yields a new function, to which `y` is then applied (see
[http://en.wikipedia.org/wiki/Currying](http://en.wikipedia.org/wiki/Currying)).

The function `$` that you mention is just application:

> f $ x = f x

So, using `$` infix like so

> f $ x

Is equivalent to

> f x

And likewise

> delay (1/4) $ p1

is equivalent to

> (delay (1/4)) p1

with extra parenthesis to make associativity clear.

This begs the question: when is `$` ever a useful function? There are two
cases that come to mind:

1) Precedence. `$` has the lowest precedence of any function, and can thus be
used to omit otherwise necessary parens; this

> f (g x)

is equivalent to

> f $ g x

2) Use in higher order functions. Imagine you have a function `all` that takes
a predicate function `f` and a list of values `xs` and returns `True` if `f x`
returns `True` for all `x` in `xs`. So `all (> 3) [4,5,6]` returns `True`.
But, imagine now that you have a list of predicates and one value: can you
still make use of `all` in this case? Yes, you could do something like this:

> all (\f -> f 42) [even, (> 3), (< 100)]

But that's a little verbose. If we look at `(\f -> f 42)`, all it's doing is
taking a function and immediately applying `42` to it - hey, that sounds like
`$` if it was partially applied to `42`! Here's a simpler version of the
previous expression:

> all ($ 42) [even, (> 3), (< 100)]

So that's pretty much all there is to `$` and why one may omit it in the
original expression.

------
ionforce
What is optimistic version number? The site it is linked to seems to be down
currently.

------
cybjef3657
Abjad is a Python API designed by composers Trevor Baca and Josiah Oberholtzer
that wraps/extends Lilypond:
[http://abjad.mbrsi.org/start_here/abjad/index.html](http://abjad.mbrsi.org/start_here/abjad/index.html)

------
sbrother
This looks really cool and I'm excited to play around with it. I had been
using Euterpea for a while last year
([http://haskell.cs.yale.edu/euterpea/](http://haskell.cs.yale.edu/euterpea/)),
but as far as I can tell that project has gone cold, and it's a huge pain to
get working on an update haskell-platform.

EDIT: Never mind, looks like Euterpea has actually seen some development (and
improved documentation) since I last used it.

------
robinhoodexe
Very nice, I wish it had support for some simple synthetic piano sound. Of
course one can play it easily with MIDI-export, but direct feedback would be
even more nice.

------
abruzzi
Interesting. It would be nice if it has csound .sco export.

------
gtani
Hmm, don't see the connection, if any, to algo's from haskell school of
music's book: [http://haskell.cs.yale.edu/euterpea/haskell-school-of-
music/](http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/)

(will examine closely later)

------
stove
I want something to take a music file (mp3 or otherwise) and spit out sheet
music for it. Possible?

~~~
JonnieCache
There are lots of algos for this. The ones that work well are complex. None of
them work that great on full pieces of complex music with many instruments
playing at once.

The Ableton Live music package has a great one built in, which appears to do
some kind of probabilistic modelling for harmonies. You can send all kinds of
crazy noises into it and the resultant chord progressions become increasingly
avant-garde, but remain musical.

These algorithms often output midi (ableton does) and it seems you could put
that into this Music Suite software and have it spit out notation.

Look in the literature and you will find tons of research on this stuff.

------
noname123
Thanks nbouscal, thanks for posting. Can you explain to me how your Haskell
project is different from VexFlow which a lot of peeps to do HTML5 music
notation rendering.

------
ackalker
The example [listen] link points to a .mid file which some browser setups
don't know how to handle (for instance, my Chromium simply downloads the file
whenever I click the link, then downloads it again when I click the file in
the bottom download bar).

Please offer an example audio rendering in a media format which is more
generally supported, thank you.

------
icesoldier
Reminds me of MML, but more general. I like it.

------
jbrown
Wow, very impressive. Let's see someone do that in Swift. :)

