Marcos

Stumbled upon this site and this paper. Talks about generating beats and such using Euclid's algorithm and how it relates to world music:

http://cgm.cs.mcgill.ca/~godfried/publications/banff.pdf

I wanted to implement this in MAXMSP but I have a feeling I will need to just call in some external Java or C code. Below is what I have so far, all you do is select the number of HITS you want in a certain time frame (beats) and hit compute...all it does so far is generate a list of 1's (the hits) followed by 0's (the rests). The real algorithm is supposed to go from there, but I'm not sure how to implement it using MAX objects. Anyone care to look into this? I can easily do any combination by hand, but the whole point would be to automate it and let the user decide all the parameters.

Paper: http://cgm.cs.mcgill.ca/~godfried/publications/banff.pdf

Site with Example and Code: http://ruinwesen.com/blog?id=216

euclidean-algorithm-to-generate-beats-paper-and-starting-patch

http://blog.noizeramp.com/2008/10/26/rhythm-generation-with-an-euclidian-algorithm/

Here is a max/msp implementation that I came up with. I can't guarantee that it is 100% mathematically sound, because like the lisp implementation, its a bit of a hack.

However, I did do a unit test and compared the output of my patch with the results in the paper. Every result of my patch created the same patterns, except many of them needed to be rotated using [zl rotate] for the patterns to start at the same time as the examples in the paper.

Also, keep in mind that the list generation is not instant and probably isn't suited for changing patterns live/on the fly. Data moves to and from several colls to sort everything so I would expect a bit of a delay to create a list, especially if there is a lot of other things going on. 

Here is a max/msp implementation that I came up with. I can't guarantee that it is 100% mathematically sound, because like the lisp implementation, its a bit of a hack. 

However, I did do a unit test and compared the output of my patch with the results in the paper. Every result of my patch created the same patterns, except many of them needed to be rotated using [zl rotate] for the patterns to start at the same time as the examples in the paper. 

Also, keep in mind that the list generation is not instant and probably isn't suited for changing patterns live/on the fly. Data moves to and from several colls to sort everything so I would expect a bit of a delay to create a list, especially if there is a lot of other things going on. 


Also, I just realized that the help file has a sound generator called blip~. Its just a simple thing I put together for testing stuff but if you want the help file work properly just put the attached file in your search path.

Ok. This should have all the files in one zip. I also dropped the print object that was in the patch for testing. 

Thanks I look forward to testing this out and seeing how you did it. I'm mad at myself for not being able to do it, argh! the rotation isn't a problem! I'll let you know how it pans out.

Quote: Nick Inhofe wrote on Wed, 12 November 2008 20:42

----------------------------------------------------

> Ok. This should have all the files in one zip. I also dropped the print object that was in the patch for testing. 

Looks good, still going through it to see how you did everything. In the coll #0 rMerge 1, What does the #0, rMerge and 1 mean/do?

Quote: Nick Inhofe wrote on Wed, 12 November 2008 20:42
----------------------------------------------------
> Ok. This should have all the files in one zip. I also dropped the print object that was in the patch for testing. 
>
>
----------------------------------------------------

Looks good, still going through it to see how you did everything. In the coll #0 rMerge 1, What does the #0, rMerge and 1 mean/do?


#0 is a unique identifier so you can have multiple instances of ndi.bjorkland. Each instance internally shares its data between colls, but that data won't be passed across intances. The 1 after the name just says that the name isn't a textfile to be read. This is covered in the coll reference/help file.

#0 is a unique identifier so you can have multiple instances of ndi.bjorkland. Each instance internally  shares its data between colls, but that data won't be passed across intances.  The 1 after the name just says that the name isn't a textfile to be read. This is covered in the coll reference/help file.


Quote: marcoskohler wrote on Wed, 12 November 2008 15:48

If you see Ruby code you want to try in Max, you can use my Ruby object: 

http://compusition.com/web/software/maxmsp/ajm-objects

(but I had some issues copying directly from my web browser to Max, it was converting some of the characters to garbage. I pasted into a plaintext editor and then copied from there into Max textedit and it was fine.)

Quote: marcoskohler wrote on Wed, 12 November 2008 15:48
----------------------------------------------------
> Another code example:
>
> http://blog.noizeramp.com/2008/10/26/rhythm-generation-with-an-euclidian-algorithm/
----------------------------------------------------

If you see Ruby code you want to try in Max, you can use my Ruby object: http://compusition.com/web/software/maxmsp/ajm-objects

Copy and paste coding is so easy ;)
(but I had some issues copying directly from my web browser to Max, it was converting some of the characters to garbage. I pasted into a plaintext editor and then copied from there into Max textedit and it was fine.)

Thanks guys, will look into the Ruby object. For now I created a patch that uses what Nick made, has 6 tracks (For Ableton's Impulse for example) and lets you select the midi-notes, velocity, etc. If you want to hear how it sounds just in MAXMSP you should send a port "yoursynthdevice" to all the noteouts.

Quote: marcoskohler wrote on Wed, 12 November 2008 22:07

> Thanks guys, will look into the Ruby object. For now I created a patch that uses what Nick made

That was just an FYI for future reference. Since you have something that works, there's no particular reason to use the Ruby version unless you want to mess with the algorithm and find Ruby code easier to work with. Pure max patches are going to be more efficient most of the time.

Quote: marcoskohler wrote on Wed, 12 November 2008 22:07
----------------------------------------------------
> Thanks guys, will look into the Ruby object. For now I created a patch that uses what Nick made

That was just an FYI for future reference. Since you have something that works, there's no particular reason to use the Ruby version unless you want to mess with the algorithm and find Ruby code easier to work with. Pure max patches are going to be more efficient most of the time.


Euclidean Algorithm to Generate Beats (Paper and Starting patch)