The Music Suite
music-suite.github.io
music-suite.github.io
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...
Another different visual representation is that of shakuhachi music: 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
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.
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.
I mainly use it for single melody lines (albeit with complex ornamentation), but have done a few multi-part pieces. I can send you a sample when I'm not on my phone. The only downside is that it's hard to see the relationship between hhe parts--afaik you can't interleave them. But the actual typesetting works great.
It's definitely worth a try, especially if you have a technical background. (Oh! Another cool feature: it has its own version of cascading style sheets, which provides a really nice separation between content and piesentation.)
Of particular note is the file https://github.com/overtone/overtone/blob/master/src/overton... which is an absolute work of art.
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)
(Not being sarcastic. It's an interesting distinction.)
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/
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 (video: 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) just made a release of their Common Lisp software for predictive modelling of musical structure.
> 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.
melody = scat
chord = pcat
I'm excited to use this, though, and will definitely be reassigning those names to something else at the top of every file.
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)
p2 = delay (1/4) $$ [p1]
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.
let p1 = scat [c..c']^/4
p2 = delay (1/4) p1
p3 = delay (3/4) p1
in (accent . legato) (p1 </> p2 </> p3)
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).
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.
accent . legato $ foldl1 (</>) (delay <$> [0, 1/4, 3/4] <*> [scat [c..c']^/4])EDIT: Never mind, looks like Euterpea has actually seen some development (and improved documentation) since I last used it.
(will examine closely later)
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.
Please offer an example audio rendering in a media format which is more generally supported, thank you.