The Chord Catalog--can you generate it using Max?
All:
I recently came across The Chord Catalog while reading an issue of "I Care if You Listen" a webzine produced by: Thomas Deneuville who referenced it in an interview with Samuel Vriezen, a performer/composer seeking "crowd funding" for a recording featuring the chord catalog (http://www.icareifyoulisten.com/?s=tom+johson). Vriezen explains The Chord Catalog in an informative video posted on vimeo (http://vimeo.com/50888732) and youtube (http://www.youtube.com/watch?v=95UAX8gUyHM).
(see score download from Tom Johnson's website: http://www.editions75.com/FreeScores/TheChordCatalogue.pdf)
I have created a Max patch that generates The Chord Catalog, but am interested if any other forum members have thought about doing the same or would be interested in doing so.
At the end of February 2014 (2/28/2014) viable solutions to the catalog will be performed on disc Klavier during a "soundwalk" event that is part of our Festival of New Music this year.
Please upload your patch!
Thanks to all for reading.
Your patch didn't post.
I'm curious to know what would be the rationale behind generating more than one max patch, if your accomplishes what it needs to do?
typically I enjoy mental exercises on the max forum, but this seems like quite a big system to build...
Nah, not so complicated. You are light years beyond me in the Max world and it didn't take me too long to make a patch that generates all 8000+ chords grouped by note-count that plays them in sequence. I had already messed with 12 note variations before. The only odd thing is his use of 13 notes - but hammering out permutations is still far easier than working out the combinatorics. Weeding out redundant forms to form cyclic equivalence groups, etc. is far more challenging.
I'm more inclined to follow Michael Keith's lead as laid out in From Polychords to Polya.. exploring the minimal number of unique combinations rather than just enumerating everything.
I will gladly share my patch (when I get back to my computer) but it's still not clear if the OP forgot to include the patch he mentioned or just wants everyone else to share but him. :/ It's also not clear what is meant by "solutions to the catalogue" being performed...
found some piano tunes, interesting pieces.
but whats the theory behind them? is it a strictly algo concept? (i.e. what is the order of the chords beeing played? from low to high?)
and if not, whats the point of maxmspifying it?
hm, i guess i am supposed to build an mathematical expression which can translate 1-n directly to all possible chords in an octave (or any other possible range) as a list of integers now.
hmmmm...
saw the videos now, pretty fun. but i tend to implement something which is more flexible and allows thousand of different rulesets and not only one.
-110
Dear Wetterberg:
Thank you for your comments. In my original request, I seek to gather from the forum max patch solutions that all accomplish the same goal--that of producing The Chord Catalog.
Patches that can generate the catalog will be used to perform it during a soundwalk event that is part of our New Music Festival this year. A performance of a patch will/can consist of either MIDI output, or a numerical listing of possible 'chords'. The over-arching theme this year is: Artists and Audiences in the Information Age. Personally I would argue that the Max/MSP forum is both a group of artists, who use Max/MSP, and an 'audience' of sorts who often act to assist others in solving technical problems, or post patches that can be of use to other users (I do not mean to be too reductive here).
I have a patch that generates the Chord Catalog, but what I am seeking are other solutions that produce the same end. In this sense the 'elegance' of the solution is as important as the output it generates.
Thanks all very much for your replies!
Maybe if he had studied pitch-class set theory it would have been a much shorter piece! :-)
hm, i guess i am supposed to build an mathematical expression which can translate 1-n directly to all possible chords in an octave (or any other possible range) as a list of integers now.
Enumerate all 13-bit lists and send them to zl.sub 1 with a grouped output. Vexpr for MIDI offset. Done.
i would like to do it in realtime, on a per-event basis. a loadbang-uzi to some 80,000 lists is nothing what i would like to perform at startup.
also, i am not sure if i got the progession system explained in the video right. plus i´d like to perform different walks through the collection, by different rules.
I think this thread would attract more interest if there was clarification about the context and nature of how these patches plan to be used. There is certainly a spirit of sharing on this forum, but it seems a bit unusual to simply to collect other people's work and then present it publicly in a different context. Would people be acknowledged for their contributions? Will there be a recording of the performance? And if I may ask the OP, why won't you share your patch? It's not uncommon for students to come on the forum attempting to get other people to do their homework. I'm not saying that is the case, but it kinda has that flavor.
Also, it's still not clear why multiple patches of the same enumeration of chords would be necessary. At 200bpm it would take 40 minutes to play each patch. And what is the relevance of elegant Max programming when a Disklavier is only concerned with note data?
Anyway, I hope you don't take this in the wrong way. I'm took the time to write this because find it all very interesting and I am personally involved in similar work with chords, scales and rhythms. I have patches that will play all possible chords in various binary sequences, gray code sequences (which I find to be the most musical) and of course the weighted binomial arrangement of The Chord Catalogue. But I suppose I'm interested in something more mutual in terms of sharing. Perhaps you might consider that. Either way, all the best with your project and the upcoming event!
i am not sure if i got the progession system explained in the video right.
It's all binomial. The 13th row of pascal's triangle has the total number of chords for each n-note chord group. The diagonals contain the number of chords in the "walking" patterns within each group. More simply, the sequence is the formal binary arrangement (counting from 0 to 8192) sorted by weight (number of 1's). So it's really just a matter of filtering the enumerated lists.
And I agree re: custom sequences... lots of interesting ways to push 1's and 0's around....
lets play our old game: you start with the patch, and later i optimize it.
i´d love to have the whole thing generated by inputs of 1, 2, 3, 4, 5 ... this is the easiest way to be able to play variations of it in realtime.
can you make up the math for it?
lets play our old game: you start with the patch, and later i optimize it.
Isn't that the game where you try to make a patch and can't get it working.. then I make one that works and you optimize it. ;)
OK.. so here is a patch that takes 1,2,3,4,5... generates chord sets of n-notes in the same weighted binary order as the chord catalogue and indexes them in a coll. It's fast enough to generate new chord groups while playing. You can also generate all the chords with a single bang but it takes a second or so.
could you upload or mail that pls, i need to redo it in proper max 4 language and i only have /patchtocanvas here, which does not let me see into [p padding] for example.
That bit list converter is a deconstruction of an external abstraction I made to convert any positive integer (0 to 2147483647) to a bit list with args for padding length (to 31 bits) and MSB. I also made one that converts back to decimal. They are my little gems.. mostly because they use expr instead of a bunch of logic objects that slow it down and limit input range.
Here's an attachment of the patch I pasted.
Thanks all for the replies and observations!
As I mentioned in the initial post patches would be performed during a "soundwalk" event. The idea being that submitted patches (or portions thereof) would be performed at intervals between other performances on the program. The event is a part of a larger festival themed "Artists and Audiences in the Information Age." In short, the intent was to connect the audience of the Max forum with the audience of our event through submissions of "the chord catalog;" the idea seemed novel even though each performance would ostensibly be the same.
It seems that within the Max architecture there would be multiple ways to execute the sequence. I came to Max as a musician with less formalized education in programming and mathematics, so maybe I was naive here. No intent to offend! Thanks all for your replies.
So this is actually rather a strange 'call for submissions' rather than asking for help??
the intent was to connect the audience of the Max forum with the audience of our event through submissions of “the chord catalog”
Perhaps you can help me understand what exactly is being presented to the "audience of the Max forum". It doesn't seem like you are relating to the Max forum like an audience all but rather using the forum to cull performance material for a separate audience.
I came to Max as a musician with less formalized education in programming and mathematics, so maybe I was naive here.
Then it makes even less sense that you haven't posted anything.
Are you worried that people are going to steal your ideas? I understand the concern, but if that's the case, it's unusual that you would ask others to contribute performance pieces without any mention of acknowledging the source. I just ask that my modest little creation not be presented as someone else's work - whether it's a homework assignment or a performance piece.
If there is any video of the event, it would be really cool see an excerpt of these patches being played on the Disklavier. Maybe you could upload it to youtube?
okay, as it seems it is not much more than making chords out of a set of binary number symbols, just in a certain order, which is due to their origin (geometry?).
however, the name of the "chord catalog" and its related history (some guy in the fiftes made this minimal piece from it) might be worth to steal and take the name for a new 110 module.
what is a bit disgusting about the math here is that it seems to create a 8/16 beat scheme, at least thats what i hear when it is played fast, i thought it would be a bit more chaotic.
can it be that there is a bug in your math? values 32, 128, and 1024 do not play!
and here is proposal to replace your code between the padding and making a chord list:
"0 0 1 1 0 0 1 1 0 1 0 0 1"
|
[vexpr $i1*$i2] (where $i2 is "60 61 62 63 64 65 66 67 68 69 70 71 72" - or anything else you like(!))
|
"0 0 62 63 0 0 66 67 0 69 0 0 72"
|
[zl sect] (to both inlets)
[zl sort]
[zl slice 1] (right outlet)
|
"62 63 66 67 69 72"
this will work for all chords except the last one which consists of all 13 notes
however, thanks for sharing, i was able to make a realtime derivate from it and now i´d like to discuss the further options.
we basically have two axis where modifications could be made:
- one could change the order of the input values (linear, in cycles of 8 steps, or in cycles of steps of multiples of 2)
- one could use different notes (see above [vexpr $i1*$i2]), for example only white keys, or only note numbers belonging to D major, a series of overtones or any scale you like, or just reverse the chromatic scale and start from top.
a third thing one could do is to implement self control. for example one could play the chords as arpeggios, and trigger input step #65 from some arpeggio effect´s "last note finished" flag.
or what about multiplying the whole thing with its own output ... step #3 gives you the chord "60 61" ... we could play it, and then trigger certain steps from it, which are related to the decimal numbers 60 and 61 in a way.
-110
btw, your approach where you use a database seems to have advantages when trying to modulate.
i was just asking myself how the fupp i could play all chords sorted by their number of keys in realtime. :D
-110
metamax would you be able to do the symbols generation on a tertiary basis?
route 0 should be faster than zl slice 1, when i think about it.
;D
okay, as it seems it is not much more than making chords out of a set of binary number symbols, just in a certain order, which is due to their origin (geometry?).
The order of the chord catalogue is what I would call "weighted binary". It's a form of binomial expansion. Think of it as a two-part sort. First enumerate 0-8191 in binary form, then sort the chords by the number of notes (1's). The number of chords in each group corresponds to the binomial coefficients of a given power. In this case, it's 2^13 so it's the 13th row of pascal's triangle... 1, 13, 78, 286, 715, 1287, 1716, 1716, 1287, 715, 286, 78, 13, 1 That is to say, one "silent chord" of 0 notes, 13 single note "chords", 78 2-note chords, 286 3-note chords, ... finishing with one 13-note chord - of which 14 are technically not considered chords.
But that isn't the simplest way to enumerate all possible chords. Straightforward 0-8191 in binary is much easier - but then it's not "catalogued" by the number of notes. The chord lengths will vary from chord to chord.
what is a bit disgusting about the math here is that it seems to create a 8/16 beat scheme, at least thats what i hear when it is played fast, i thought it would be a bit more chaotic.
Well, there's no need to force a temporal context from a tonal pattern. There are lots of ways to combine unique rhythmic sequences with tonal patterns.
can it be that there is a bug in your math? values 32, 128, and 1024 do not play!
I haven't found any bugs. :) The "# notes" input enumerates chords of a given note count. If you enter "2", there will only be 78 indexed chords in the coll... hence 128 and 1024 won't play anything. If you bang out all of the chords, then any number from 0-8191 will output a value.
here is proposal to replace your code between the padding and making a chord list:
I opted to store the raw bits because of other work I am doing. You could also apply your method to the queried bits just prior to MIDI output.
however, thanks for sharing, i was able to make a realtime derivate from it and now i´d like to discuss the further options.
I’m inclined to approach it with further boolean techniques (because of other work I’m doing). The interesting thing about binomial coefficients is they correspond to levels in an n-dimensional hypercube where each vertex has n connections with a single bit of difference. iow, each chord is connected to 13 other chords that are 1 note different. Now I know what you're thinking.. what the fuck am I going to do with a 13-dimensional hypercube?
You can unfold higher dimensional hypercubes into a series of lower dimensional structures with (relatively) simple operations… like unfolding a regular 3-cube into a bunch of squares. What’s cool about this is that the elements of each unfolded sublattice have common qualities. Simply put, it’s a way of grouping pretty much anything in terms of similarity/difference.
I have already done this in contexts as varied as rhythm, color, luminance, tone, etc. Just to give you an idea of the possible variety… a 13-cube enfolds a single 13-dimensional lattice, 26 12-dimensional lattices, 312 11-dimensional lattices, (2288, 11440, 41184, 109824, 219648, 329472, 366080, 292864, 159744, 53248)… and 8192 0 dimensional lattices (nodes).
Specifically, I’m interested in a type of lattice known by the rather banal name “fibonacci cube”. These have all the properties described above, except strings with consecutive 1’s are not allowed - which is uniquely relevant to forming pleasant sounding chords. Most of the chords generated in the chord catalogue are composed of one or more semitones which can sound like shite in many situations.
metamax would you be able to do the symbols generation on a tertiary basis?
Enumerating ternary numbers is no problem. I have a patch that will convert any positive decimal integer to any radix. It's similar to the binary conversion but it's based on mod n, rather than &.
But what's the third variable? Binary is note on and off.
hence 128 and 1024 won’t play anything
128 should output a single E and 1024 a single G as result. but instead of a "64" it is silence what i get between "60 61 62 63" and "60 64".
what do you think about ignoring the binominal origin of this self similar series of integers, and rebuilding the math using +, - and logic only.
wouldnt that be the perfect level where you can easily change the rules to get different series?
three dimensions ... i was thinking about 2 for "play" and 1 for "play at half volume"
I see what you're saying. Well I chose to index the bit strings with a straight integer sequence so that a simple count will iterate the chords in order. You are talking about indexing the bits with their decimal equivalent.
If you want to use bindecs you can use 'goto' and 'next' to sequence the chords or use a translator coll to convert a standard count to the binary decimal sequence. See the attachment.
As far as ternary enumeration... that interesting. You could enumerate in base 3 and then convert the 2's to changeable args for variable velocity options. But keep in mind that ternary enumeration of 13 notes would mean 4,782,969 chords.... so ymmv. I can upload my radix converter if you want it.
Another possibility is to stick with binary and simply select which notes to vary.. and then substitute those notes with changeable args. See attachment.
variable note velocity:
-
chord enumeration w/alternate indexing:
-
what do you think about ignoring the binominal origin of this self similar series of integers, and rebuilding the math using +, – and logic only.
I'm game.. but my method is the simplest way I know. Considering the nature of the sequence, I'd be curious to see your approach.
wouldnt that be the perfect level where you can easily change the rules to get different series?
I have several libraries designed to sort, push, parse, weave, change and otherwise screw around with 1's and 0's - so my preference is to stick with bit lists at the lower level. But I'm still curious about the alternatives.
You have mail btw. news@...
Well I chose to index the bit strings with a straight integer sequence so that a simple count will iterate the chords in order. You are talking about indexing the bits with their decimal equivalent.
no, i am using nothing but your code. input is 1-8000, output is (at first) a 13 bit binary.
but the result for 32, 128, and 1024 is wrong. they are supposed to output
step 32 = 0 0 0 0 1 0 0 0 0 0 0 0 0
step 128 = 0 0 0 0 0 0 1 0 0 0 0 0 0
step 1024 = 0 0 0 0 0 0 0 0 1 0 0 0 0
but they give me only zeros. does it work for you? i cant check now.
straight ints as input trigger is perfectly in my scheme, thats how most of my stuff works.
-110
I don't know what you mean by "input is 1-8000" or "output is "at first" a 13 bit binary. There is no input of 1-8000 and there are no outputs that aren't 13-bits. ?!
The patch has two sections. The left section generates sequences. The right section plays them.
There are only two possibilities to generate sequences. You can bang "all of 'em" for all 8192 patterns (indexed 0-8191). Or, you can input 0-13 in the number box labeled "# notes" which will output a sequence that only includes chords with that number of notes. That's it. In all cases, you are limited to the total number of chords that are output. ex. input 2 into "# notes" box and you will be limited to 0-77 input into the "manual" box.
step 32 = 0 0 0 0 1 0 0 0 0 0 0 0 0
step 128 = 0 0 0 0 0 0 1 0 0 0 0 0 0
step 1024 = 0 0 0 0 0 0 0 0 1 0 0 0 0
I assume you mean:
step 32 = 0 0 0 0 0 1 0 0 0 0 0 0 0
step 128 = 0 0 0 0 0 0 0 1 0 0 0 0 0
step 1024 = 0 0 0 0 0 0 0 0 0 0 1 0 0
But again.. the indices are NOT decimal equivalents of the strings.
If you bang "all of 'em" the following integer input into the number box labeled "manual" will output the following lists:
32 = 0 0 0 1 0 0 1 0 0 0 0 0 0
128 = 1 0 1 0 0 0 0 1 0 0 0 0 0
1024 = 0 0 0 1 0 0 0 0 1 0 1 0 1
Those are the 33rd, 129th and 1025th elements of the complete sequence that begins with 0... each with a decimal equivalent of 576, 5152 and 533, respectively.
Maybe something didn't get connected when you were converting my patch to Max 2.0 ;)
see patch.
it is basically your code, except that i am not using a database-coll but ask for the calculation of the result when needed.
pls replace jmc.sort with zl sort
it seems to work perfectly except that these 3 steps i mentioned above produce silence instead of the correct chord. all other 8189 steps produce a chord output.
-110
p.s. this is the version for cobol. i can upgrade it to atari OS in case you are that modern.
Hey I like that...
But you do realize that's not the chord catalogue... That's just a straight enumeration of all binary values. The chord catalogue is weighted - so you would need to use something like zl.sub and a gate to filter lists with n notes.
Other than that, yeah, that's my code but it ain't my code that's causing the problem. :)
You are using the binary decimal values to index the bit lists... LSB sets the highest note and the MSB, the lowest note. As the index increases and the powers double, the highest note becomes the next value in the applied scale filter list. As those LSB's move to the right, the offset on the kslider needs to be adjusted (see my original sub patch bits2notes)... or they won't be visible. Or just use an 88 key kslider.
Are you you not hearing the note or just not seeing it? I can hear them... so I don't know if you are checking the audio or it's just visual. If it's the audio, those notes will play if you send the makenote values to noteout.
That said, there is one note that won't play if you use your 'major' and 'white keys only' lists. 4096. That's because you are multiplying two lists of different lengths. 4096 is the 13th element of the bit list but there are only 12 notes in your filters, so it gets snipped. Make sure you have 13 notes in your scale filters if the source is 13 bit. (I personally prefer 12 bits to do this kind of stuff... I only adjusted to 13 for the context of this thread.)
btw.. I noticed a couple of typos.. the triads in your list are minor, not major. And note 104 is a rogue blue note. It should be 103.
I still think that sticking with bit lists is more flexible, including the scale filters. You can always add an offset to the bits in scalar mode and set them to any key you want (within a single octave) or use iter and pass the list through a changing function for custom notes of any value. If you think about it, scales and chords aren't notes. They are patterns of difference.. intervals... which is why I find bits to be superior.
Thanks for sharing.. your patch sparked some great ideas. I have a big ass list of 2047 scales.. all in 12-bit list format.. I need to make some patches that output note values through multiple octaves (rather than just a single octave offset of the semitones) Also, something that will take a bit list and output the notes for different arpeggios through multiple octaves.
But you do realize that’s not the chord catalogue
no i didnt. can you fix it to match the original, so that i can see the difference? i´d like to start from the original and not from some rubbish which was born because i am to dumb to copy.
4096 is the 13th element of the bit list but there are only 12 notes in your filters
right, that is another error i made. the OP was asking for 13, but in fact i want 12 like in the original.
Are you you not hearing the note or just not seeing it?
dont see it and i dont hear it. will check again what happens.
I still think that sticking with bit lists is more flexible, including the scale filters
i dont get that. isnt what i did just another way to do the same as you did?
and i must use a list, because there is no scalarmode in 4.1. :)
scales
in case you mean tuning scales, my scales are in "note format" (as opposed to Hz)
Well I wouldn't call the binary sequence "rubbish". I consider it the true mother form. It just doest have the weighting of the so-called chord catalogue.
The only difference between the two is the additional sorting by the number of 1's. It's the same order of your patch except all the chords with 1 note are played first, then all the chords with 2 notes, 3, 4,.. etc. That's why I used coll and iterated the entire binary sequence multiple times over. Each time uzi 8192 is banged, the chords of a given note count are added to the coll. It could be done faster with a single big bang with gate 14 controlled by the right outlet of zl.sub 1... but that means more colls.
I suppose I can mess with your patch but really... I can't keep track of what you can and can't view. WTF are you doing with Max 4.1? Seriously. Is it some kind of minimalist thing? Are you into antiques and old cars? Are you in prison or living on the street? Help me understand.
Here are a couple of pics of the different sequences for visual reference. Bonus points if you can figure out how to generate the graycode sequences. :)
okay, looking at the video again i now accept that i was a bad idea to leave out half your example patch. that i changed the algorithm seems to be the reason why i get a different result.
but back to the more interesting part: the missing chord.
so you are saying that you get an output from my patch when you input "128" ?
so you are saying that you get an output from my patch when you input “128″ ?
Yup. The only 'missing' chord is 4096 and that's only if the chord list doesn't have 13 elements...
Here is your patch with the gating I originally set up. But notice the gaps in the playback as it skips chords that don't match the target size. That's why I used colls. Of course, that may not be entirely undesirable. I got some rhythmic insight listening to the pattern of gaps...
this is weird. are you in 64 bit mode?
Nope.. 32-bit. 6.1.6 OS X 10.9.1
Through MIDI.. haven't tried DSP.
and you are sure that #32 will output something?
i tell you what i see.
it is already your [expr int(log10($f1)/log10(2))] – [+ 1] which is giving an output of "4", with the result that the last number of "0 0 0 0 1" is cut off by the zl group.
can it be that it would be better to not do int() inside the expression?
[expr log10($f1)/log10(2)] is outputting a float of "5." - which is correct and produces the right chord (0 0 0 0 1, a single E) for step #32.
please doublecheck if #32 really works for you, because in that case we should investigate why max v.6 expr is working differently from v.5 and v.4.
that log10() expression internally probably produces a 64-bit value of something 4.999999ish, which end up as 5.xx when sent to the 32 bit max runtime.
-110
32 works. It plays 79 69 or 65 depending on the list used to process the notes.
log10($f1)/log10(2)+1 = log10(32)/log10(2)+1 = log2(32)+1 = 6
int() merely truncates it for the uzi & zl group args. I suppose it isn't necessary because uzi and zl group will truncate it anyway, but I don't see how it hurts.
0 0 0 0 1 is either binary 1 or 16 depending on the MSB, not 32.
32 is either 1 0 0 0 0 0 or in this case, 0 0 0 0 0 1 since the MSB is on the right (so the the bits begin on the left which is the root of the chord).
I don't know what is happening internally, but google also returns 6 for [log10(32)/log10(2)+1]... not to mention that regardless of mantissa issues, it should never return 4....
so. but of course there is an easier way to generate those binary numbers, and that is converting decimal numbers to binary in list form. there are probably even better and more cpu friendly objects than my old abstraction.
see how easy life can be without log20(), which seems to be incompatible with 110 anyway.
Ya know.. I think it would be interesting to compare the performance of our bit conversion patches. :)
Of course, they both need to take any positive long integer, have custom zero padding and choice of MSB. The decimal reconversion patch needs to take any bit list up to 31 bits with selectable MSB.
Feel free to post yours.. I couldn't really see it hidden inside that object.
Bear in mind, I'm new at this. I only learned what a bang was this past summer. So I need all the help I can get.
Ya know.. I think it would be interesting to compare the performance of our bit conversion patches.
great minds think likewise.
mine also sucks cpu. it is a bunch of %2 and /2, all in a series for up to 16 outputs. but i am sure that if i limit it to 12 or 13 outputs, it could be faster than yours.
yes i iknow, at the cost of functionality. maybe. lets see.
custom zero padding ...
possible but difficult. but dont forget, in my version it could at least be turned off when not needed.
sorting by chord length to make "the chord catalog" ...
easy. just take the cross total of the list and you have the number of notes.
you could also save by not uzing it 8 times, but rather only once, then measure cross total and sort using a gate. the gate could go to 12 colls, or maybe you can even use "insert".
custom MSB/LSB ...
gate 2 & zl rev. done.
31 bits ...
i have only made versions for 8 and 16.
in case you didnt notice: i have added a new picture at post 281324.
-110
this should be faster: http://www.maxobjects.com/?v=objects&id_objet=2967&requested=binary&operateur=AND&id_plateforme=0&id_format=0
but third party stuff is generally bubu.
-110