At 11:53 AM -0700 7/4/10, Michael Mossey wrote:
Wondering if I could get some suggestions for coding this problem.
A musical document (or score) consists primarily of a list of
measures. A measure consists primarily of lists of items. We'll
consider only one kind of item: a note. Items have a
erik flister wrote:
Michael Mossey wrote:
Regarding my use of Rational, it's because I'm representing
*notated* durations or positions in time, which are always fractions
of integers. Suppose I give the command to my program to play via
midi everything from bar 1 beat 1
Wondering if I could get some suggestions for coding this problem.
A musical document (or score) consists primarily of a list of measures. A
measure consists primarily of lists of items. We'll consider only one
kind of item: a note. Items have a location within the measure. A note's
location
On Sun, 4 Jul 2010, Michael Mossey wrote:
I can solve a simpler problem which is
-- Given a note with tieNext set, and a list of notes, find
-- the end Loc of the last note in the chain. Only notes
-- with the same pitch as 'firstNote' are considered when looking
-- for the chain of notes.
The thing that is hard for me to understand is how, in a functional
paradigm, to update the entire Doc by chasing down every tie and making
all necessary updates.
This looks like one of graph algorithms.
Notes are nodes, ties are arcs. Measures, etc are parts of node label.
soundedEnd
Henning Thielemann wrote:
On Sun, 4 Jul 2010, Michael Mossey wrote:
I can solve a simpler problem which is
computeSoundedEnd :: Item - [Item] - Loc
computeSoundedEnd firstNote notes = compSndEnd (pitch firstNote) notes
You will certainly not be able to make use of foldl or foldr, but you
Serguey Zefirov wrote:
The thing that is hard for me to understand is how, in a functional
paradigm, to update the entire Doc by chasing down every tie and making
all necessary updates.
This looks like one of graph algorithms.
Notes are nodes, ties are arcs. Measures, etc are parts of node
On Sun, 4 Jul 2010, Michael Mossey wrote:
Serguey Zefirov wrote:
The thing that is hard for me to understand is how, in a functional
paradigm, to update the entire Doc by chasing down every tie and making
all necessary updates.
This looks like one of graph algorithms.
Notes are nodes, ties
If you add Rest as an alternative constructor to Item you should be
able to attribute Items with their duration rather than their onset
position. For most processing this would simplify things.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Sun, 4 Jul 2010, Stephen Tetley wrote:
If you add Rest as an alternative constructor to Item you should be
able to attribute Items with their duration rather than their onset
position. For most processing this would simplify things.
This is also the way, Haskore organizes its data, but
Actually, it would be wise to parametrize Item with computed
attributes so that you can clearly distinguish between documents where
soundedEnd is set from documents where it is not.
Ah, this sounds like something I am looking for... parameterizing Item with
the computed attributes. But I am
Hi Stephen,
Thanks for thinking about this. The problem, though, is that notes can
overlap in time. MusicXML solves this by having not just Note and Rest, but
Backup and Forward which indicate the current position should be moved
before interpreting the following data. I'm trying to make it
Henning Thielemann wrote:
On Sun, 4 Jul 2010, Michael Mossey wrote:
Henning Thielemann wrote:
On Sun, 4 Jul 2010, Michael Mossey wrote:
I can solve a simpler problem which is
computeSoundedEnd :: Item - [Item] - Loc
computeSoundedEnd firstNote notes = compSndEnd (pitch firstNote) notes
On 4 July 2010 21:34, Michael Mossey m...@alumni.caltech.edu wrote:
Hi Stephen,
Thanks for thinking about this. The problem, though, is that notes can
overlap in time.
True - Haskore solves this with the Par operator allowing parallel
musical lines.
ABC and LilyPond have voice overlays - bars
ties are a presentation-level issue, the underlying (sound) representation
is a single note. i suggest
Doc = [Note]
where Notes have fields for their measure location and duration. then
there's no issue with overlapping notes, and start/end times are easy to
calculate. ties can be calculated
erik flister wrote:
ties are a presentation-level issue, the underlying (sound)
representation is a single note. i suggest
Doc = [Note]
where Notes have fields for their measure location and duration. then
there's no issue with overlapping notes, and start/end times are easy to
erik flister wrote:
I am dealing with ties because I am converting a MusicXML document
into a more natural form for my purposes. The initial form of the
document will have tied notes (as it comes that way from MusicXML),
and I want to convert that into a form that makes it
erik flister wrote:
That's what I want to do. I'm asking about a good way to write the
algorithm that traverses the notes and reconstructs the document
with the correct duration in each note.
why isn't this as simple as
Erik,
I'm learning from your code examples, but I
I don't understand how this turned into an argument about simplicity. I
never said it was complex.
i wasn't arguing, just confused about what you were asking cuz i didn't see
what wasn't straightforward. so i addressed the straightforward
interpretation in order to ask what that was
19 matches
Mail list logo
