Thanks. But Dreamcard won't do that, right? That's what I've got.
I'm not aware of compilations of the kind of data out there that I'd
need. (iTunes, by the way, is completely ignorant dumb about
sidemen.) I can imagine a version of the program that queries Google
to find out who each listed player is . . . but not in this lifetime.
So does this feel unbuildable within Rev? I suppose I could go build
it in Python . . . but we don't yet have a way to put a Rev front end
on a Python program, as far as I know.
Charles
On Sep 24, 2005, at 3:05 PM, Dan Shafer wrote:
Charles....
To me, this screams out for a relational database model. I wouldn't
even begin to attempt it with custom properties; too many levels of
interconnectedness.
I'd build the data management stack of this app as a one-card stack
using SQL queries for the functionality. And with Rev's world-class
Internet connectivity operations, tying it into existing jazz and
musician sites and even sources of album covers and in-depth
information of other kinds should be feasible. Could produce a very
nice, even commercially viable, app.
On Sep 24, 2005, at 11:34 AM, Charles Hartman wrote:
Many years ago I wrote a jazz-record-collection database program
in C -- so many years ago that memory problems raised by sparse
arrays of unpredictable size led me into baroque designs involving
pointers-to-pointers-to-pointers . . . It occurs to me that Rev
would make a nice front-end for this both easy and pretty. But I'm
wondering what the best approach to the data structure(s) would be.
Assume that the basic record (in the database sense) is Album --
so the basic design is one card per Album. Each Album includes a
list of Tunes (besides Artist/Group and Label/Date/EtcData). Each
Tune is associated with one or more Writers, and also with a list
of Players, each of whom is associated with an Instrument. So
we've got at least four fundamental types of data lists -- player,
instrument, tune-title, writer -- and some items that combine
fundamental items in many-to-one relation.
The program would be useful (at least to me) only if it were
possible to search it on any of those criteria. (Show me every
Album including a Tune by Matt Dennis on which Steve Swallow is
playing bass.) Obviously it's necessary to be able to add to each
of the fundamental data lists -- which suggests combox-box menus
-- and it would be important to have a series of defaults (same
players for all tunes on an album, for example) to encourage data-
entry.
Any suggestions about the best approach to the internals of this?
I'm not clear whether, for example, custom properties are up to
the demands of what's essentially a relational database . . .
Thanks for any help in thinking about this.
Charles Hartman
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Shafer, Information Product Consultant and Author
http://www.shafermedia.com
Get my book, "Revolution: Software at the Speed of Thought"
From http://www.shafermediastore.com/tech_main.html
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
