<div dir="ltr">On Thursday, August 28, 2014 3:59:59 AM UTC-4, RĂ©mi Cura wrote:<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr"><div><div><div>What I meant about (time,[-88,88]) --> X,Y is that a tone is very similiar to the same tone one octave up and one octave down.<br></div><div>This introduces problems because your tone space is not flat (like [1,88]). Therefore you may want to models this using a third dimension.<br><br></div><div>However you can somehow only use 2D and introduce this octave knowledge in your distance/measure functions.<br></div></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr"><div><div><div> for the time I wouldn't discretize it (convert to int), because in classical music for instance the tempo is constantly fluctuating during all the play<br>, so if you define time has regularly spaced notes, your going to loose a lot's of knowledge. Moreover, you have nothing to gain by doing this. All PostGis function work on X as a float (double in fact). </div></div></div></div></blockquote><div> </div>Those are all good points that you raise. The enharmonic matter (octaves being somewhat alike) inheres extra information where enharmonic matters arise. <br><br>To encode this in only one vector table might be insurmountably difficult, so it may boil down to keeping several tables of the same opus. <br><br>The matter of quantizing notes & their relative position in a measure is riven with issues (beginning offsets), but it is often done in order to simplify the temporal space. I'm not looking for accuracy in this model but rather simplicity. The point of this particular (sub)system is a pattern matching one, temporal accuracy takes a back seat to tonal harmonics. <br><br>I've been researching other music-geometry schemes, seen mention in at least one where extra dimensions are encoded in a float or decimal column ... e.g. -7.7525 would be a descending fifth (-7.0), a quarter note (0.0025) starting on the 3rd beat (0.75). I'll bet there's a computationally faster method that involves quick roundings &/or modulo calculations, perhaps a method that may not be at all first obvious. <br><br>But it's just as simple a matter in a data warehouse design to include those as extra columns (measure #, beat #, duration). Indeed these add dimensions, but then there are all the SQL tricks to work these type of data (windowing, stored proc tricks, bridge tables ... ). It may boil down to the use of the applied use of truth & cross product lookup tables, in the SQL equivalent of matrix calculations & other transformation functions.<br><br>Another parallel avenue WRT to flexible pattern matching may entail the dynamic programming methods of the Longest Common Substring, its cousin the Levenshtein distance, and its complementary calculation the string cosine match ratio... <br><br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr"><div><div><div>What this modelisation is going to do is exactly what you would obtain if you draw a line between the note on the score (the behavior of what you want is not clear for chords tough).<br></div><div></div></div></div></div></blockquote><div> <br>Yup. That would be considered arcane & bleeding edge stuff. Which is pretty much where I'm at ... :) That is, what kind of polygon would describe a VIm-7b chord? 1st, 2nd, 3rd inversions?  What kind of scheme would make any such object meaningful in any context? <br><br>I suspect I may find myself toying analysis tools to see if a simple musical opus might evince useful patterns, in pursuit of a computational useful vernacular of shapes. </div></div>