cage.chordinterp list sizes

Discussions, advice, bug reports and much more about the "cage" environment.
Post Reply
einbahnstrasse
Posts: 16
Joined: Wed Jul 17, 2013 5:42 pm

cage.chordinterp list sizes

Post by einbahnstrasse » Tue Sep 02, 2014 5:37 pm

Hi all,

The cage abstractions are wonderful and are very helpful! One question about cage.chordinterp. When moving between nodes 1 and 2 for example, that is between a chord of 3 pitches and a chord of 4 pitches, most of the interpolating chords comprise 6 pitches. This scenario - where intermediary lists are larger between the origin and destination lists - is fairly common among different chords given in this example and when I use my own data, and seems prevalent whether using smaller or larger chords. At this point I understand the logic of the abstraction, but admittedly my knowledge of convex combinations is sadly lacking. :? Instead of inventing a totally new search-and-destroy-duplicates routine as an add-on, is there any way to incorporate this within the existing logic of this abstraction? That is, to prevent intermediary lists from exceeding the sizes of either the starting or ending list?

Please forgive me if this is something very obvious. I could use a point in the right direction, if anyone wouldn't mind.

Thank you as always,
Louis~

danieleghisi
Site Admin
Posts: 1349
Joined: Fri Dec 03, 2010 1:25 pm

Re: cage.chordinterp list sizes

Post by danieleghisi » Tue Sep 02, 2014 11:57 pm

Hi Louis~

the problem arises when the starting and ending chord have a different number of notes (more precisely a non-multiple number of notes).
We've meditated quite a bit on the possibility of having the algorithm preserving the minimum possible number of notes. However, this would imply an arbitrary choice of some notes to be duplicated. But which ones, and why? Of course there are ways to answer this questions, but it turns out that they are not at all trivial, especially in the case of many chords. In general, indeed, we haven't found an elegant solution to this problem – the most elegant one being, to our opinion, the multiplication of ALL unmatched notes, leading to the middle chords having more notes than the beginning and the final one.

One way to prevent this is to be sure, BEFORE entering the chords in cage.chordinterp, that they have the same number of notes: you might choose yourself the notes to be duplicated, as you wish. In this case, there's going to be no problem.

However, we're absolutely open to hear a good idea about how to solve differently the problem of interpolation between chords having different numbers of notes; if it turns out to be good, we'll most likely incorporate it in the official cage release! ;)

Cheers,
Daniele

einbahnstrasse
Posts: 16
Joined: Wed Jul 17, 2013 5:42 pm

Re: cage.chordinterp list sizes

Post by einbahnstrasse » Mon Sep 15, 2014 5:07 pm

Thanks again as always, Daniele, for your quick and helpful replies. Also I apologize for my delayed response! I will try making the list sizes the same before sending them to cage.chordinterp. That might be the best solution for the time being.

Before my previous post I was able to make cage.chordinterp work with lists of chords that included a symbolic amplitude for each note via sublists of (<cents> <velocity>), but of course this makes it slightly more complicated when thinning out duplicates. One thing I considered was the possibility of not removing duplicates via bach.thin towards the end of the abstraction, but instead using a formula for insertion loss to equally disperse the amplitude of a single partial across as many duplicates as cage.chordinterp generates in the lists coming out of the bach.mcapprox. Initially I set up something small to do this but didn't get as far as implementing it in an iteration yet.

I've also considered eliminating duplicates by comparing successive intermediate lists output by cage.chordinterp: as new "partials" cluster around what had previously been only a single partial in the previous list, duplicates that are farthest away from the nearest partial in the previous list would then be removed. Of course this imposes more choice making when the distance between such cluster notes are equidistant on either side of the previously single partial, and I haven't set out to reconcile that yet either.

If you or anyone viewing this has recommendations on what approach might be best, perhaps one that has worked similarly in the past using OM or other environments, I am open to any and all suggestions.

Thanks again!
Louis~

danieleghisi
Site Admin
Posts: 1349
Joined: Fri Dec 03, 2010 1:25 pm

Re: cage.chordinterp list sizes

Post by danieleghisi » Mon Sep 22, 2014 8:36 pm

Hi Louis~

you might be interested to know that in official cage release cage.chordinterp will have a mode to preserve cardinality, as you asked for.

Cheers,
Daniele

Post Reply