Polyphony [Feature request]

[irisyupingren]

I ran a few experiments and the results look pretty good. Let's go for the fun polyphony part? :smile:

[irisyupingren]

Voice I:

---\                ---/ 
     ---\      ---/
          ---/

Voice II:

          ---\
    ---/       ---\
---/                ---

Calculate the area given different zoom.

A measure of how much contrary motions (counterpoint-y) there are in the details of the pieces.

[irisyupingren]

Wiki page created and I wrote a short description. But sorry I couldn't fixed the completeOneLine and completeLineWith functions. Shall we give the Double and Point some names in the comments?

[VictorCMiraldo]

I found a way to generalize this to n voices in 3D space, but we have to solve some not-so-easy multivariable integrals symbolically to get numbers out.

Assume we have n voices, each with its own f_n(x) "graph". Now, we actually put them in a regular polygon with n sides. Suppose n is three, then we can define a family of triangles:

tri x == (f_0 x) cis 0 , (f_1 x) cis (pi / 3) , (f_2 x) cis (2pi/3)

Now, if we take two triangles t_0 == tri x_n and t_1 == tri x_n+1 we actually have created a frustum. We can decompose it in several components and symbolically compute its integral

[VictorCMiraldo]

This opens up a bunch of questions and will be a significant amount of work.

@irisyupingren , maybe its better to make some validation framework first and make sure the numbers we are getting make any sense. You can use QuickCheck to generate random notes and write a few tests

[irisyupingren]

The graph idea sounds great! Positioning the notes on polygon could be less intuitive than putting two notes on a line and it will be harder to interpret the numbers though. But I'd say we should try this!

Where would be the bottleneck you think?

For the tests, are we talking about using a simple function to calculate the random test cases and "Freeze" the values so we know when we make changes the computation still holds? Or are we talking about computing a few cases by hand first and then check our programmes with these values? In this case, it might make more sense to use a few musically simple cases (like the ones I made for notesMass and dimPitches) instead of quickcheck?

[VictorCMiraldo]

The graph idea sounds great! Positioning the notes on polygon could be less intuitive than putting two notes on a line and it will be harder to interpret the numbers though. But I'd say we should try this!

No, every voice will still remain on a line. It is the combination of voices that will take place of the diagonals of an extruded n-gon. There is no difference whatsoever in the numbers.

Where would be the bottleneck you think?

Solving the symbolic integral by hand. I don't know how to do that.

For the tests, are we talking about using a simple function to calculate the random test cases and "Freeze" the values so we know when we make changes the computation still holds? Or are we talking about computing a few cases by hand first and then check our programmes with these values? In this case, it might make more sense to use a few musically simple cases (like the ones I made for notesMass and dimPitches) instead of quickcheck?

No, nothing is done by hand. I'm talking about generating a datatype like:

data MusicSkeleton 
  = Random
  | Fixed MusicPattern

data MusicPattern
  = IonianUp | IonianDown | BluesAlternating | ...

synthesize :: [MusicSkeleton] -> [Measure]
synthesize = ...

So we can generate a list of MusicSkeleton with quickcheck, call it x. Then we run our tool on the result of synthesize x. Later, we correlate the patterns found by fragem with the elements on the list and make sure that fragem does not find too many patterns in the Random bits.