[postgis-users] PostGIS as a solution for non-geographic x-y or temporal data ?
Lee R
sregdoreel at gmail.com
Fri Aug 29 14:55:05 PDT 2014
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>
More information about the postgis-users
mailing list