[postgis-users] PostGIS as a solution for non-geographic x-y or temporal data ?

[Lee R]

On Thursday, August 28, 2014 3:59:59 AM UTC-4, Rémi Cura wrote:
>
> 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.
> This introduces problems because your tone space is not flat (like 
> [1,88]). Therefore you may want to models this using a third dimension.
>
> However you can somehow only use 2D and introduce this octave knowledge in 
> your distance/measure functions.
>
 

>  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
> , 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). 
>
 
Those are all good points that you raise. The enharmonic matter (octaves 
being somewhat alike) inheres extra information where enharmonic matters 
arise. 

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. 

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. 

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. 

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.

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... 

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).
>
 
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? 

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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20140829/30f7acad/attachment-0001.html>