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
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
On Sep 24, 2005, at 11:34 AM, Charles Hartman wrote:
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 . . .
Are you already familiar with SQL and relatio
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 liste
Why do you think you can't build that in Dreamcard? MySQL access is included
and the plug-n for SQLite is inexpensive.
On 9/24/05 6:55 PM, "Charles Hartman" <[EMAIL PROTECTED]> wrote:
> Thanks. But Dreamcard won't do that, right? That's what I've got.
>
> I'm not aware of compilations of the ki
Ah, you're right. I remembered the Oracle limitation, but over-
generalized.
But $149 for the plugin is not what I would call "inexpensive." I
suppose if you start from a RunRev assumption, and have
(remunerative) applications for it, then it is; if you start from a
Dreamcard assumption, n
Charles Hartman wrote:
Ah, you're right. I remembered the Oracle limitation, but over-
generalized.
But $149 for the plugin is not what I would call "inexpensive." I
suppose if you start from a RunRev assumption, and have
(remunerative) applications for it, then it is; if you start from a
Hi Charles -
In the late 90's I wrote what was essentially a relational database in
Metacard (the precursor to Revolution), using custom properties, to
manage data in a medical information application. The data consisted of
about 5000 HTML files that took up about 15mb of space. The indexes
(
On Sep 24, 2005, at 9:23 PM, Alex Tweedly wrote:
Charles Hartman wrote:
Ah, you're right. I remembered the Oracle limitation, but over-
generalized.
But $149 for the plugin is not what I would call "inexpensive." I
suppose if you start from a RunRev assumption, and have
(remunerativ
On 24 Sep 2005, at 21:21, Trevor DeVore wrote:
On Sep 24, 2005, at 11:34 AM, Charles Hartman wrote:
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 .
On 25 Sep 2005, at 05:05, Charles Hartman wrote:
On Sep 24, 2005, at 9:23 PM, Alex Tweedly wrote:
Python I know. SQLite I don't, but I should learn. Do you know of
an OSX pysqlite binary distributable, aside from Darwinports (which
has been messy when I've tried to use it in the past)?
So
Two questions as I snatch a moment to think about this project:
On Sep 24, 2005, at 9:23 PM, Alex Tweedly wrote:
Rev front end, talking over a TCP socket to a Python back end.
Python (plus pysqlite2) for the back end.
I'm out of my depth here (happens fast), but you mention pysqlite,
and S
Charles Hartman wrote:
Two questions as I snatch a moment to think about this project:
On Sep 24, 2005, at 9:23 PM, Alex Tweedly wrote:
Rev front end, talking over a TCP socket to a Python back end.
Python (plus pysqlite2) for the back end.
I'm out of my depth here (happens fast), but you
On 26 Sep 2005, at 03:11, Alex Tweedly wrote:
It would be interesting to have a future version where the data
could be collected as a collaborative effort (like CDDB/freedb
were); although the number of people who want this data may be
relatively small, I wouldn't be surprised if a good por
On Sep 26, 2005, at 6:07 AM, david bovill wrote:
Which makes me think - what is the harm of just using CDDB/freedb
as a backend - does the database not have fields for who performed
on which track?
No, they don't. Non-jazz example: go to CDDB and search on
'Eveningland'. There's the CD, a
On 26 Sep 2005, at 14:08, Charles Hartman wrote:
No, they don't. Non-jazz example: go to CDDB and search on
'Eveningland'. There's the CD, and the group name Hem -- no
personnel. Or search on 'Flute Fever' -- a great 1963 jazz album by
Jeremy Steig. No result -- never transferred to CD. (An
david bovill wrote:
On 26 Sep 2005, at 03:11, Alex Tweedly wrote:
It would be interesting to have a future version where the data
could be collected as a collaborative effort (like CDDB/freedb
were); although the number of people who want this data may be
relatively small, I wouldn't be s
Charles-
Monday, September 26, 2005, 5:08:51 AM, you wrote:
> personnel. Or search on 'Flute Fever' -- a great 1963 jazz album by
> Jeremy Steig. No result -- never transferred to CD. (Anybody got it?
> I'd pay happily for a copy!)
I would swear I've got Flute Fever squirrelled away somewhere. I
Charles --
I see you've already received a lot of advice about implementation tools, so
instead I'll focus on metadata. Maybe the metadata will influence your
choice of tools.
There seem to be several categories of relevant metadata. As I see it, here
are at least some of them:
album data
Thanks for your very thought-provoking response. One little piece:
On Sep 26, 2005, at 7:04 PM, Dick Kriesel wrote:
performance data =
recording
artist
instrument -- examples: guitar, voice
performance category -- examples: solo, lead, backup
This isn't quite right, because ea
Producer? Mixer? Mastering Engineer?
Better go MySQL or other SQL. Many Lynux based ISPs will include it
with your web goodies, and far easier than dealing with setting up a
server. Easy to set up relations, etc.
sqb
Charles --
I see you've already received a lot of advice about implementa
On Sep 26, 2005, at 8:17 PM, Stephen Barncard wrote:
Producer? Mixer? Mastering Engineer?
Me? Semi-pro jazz player, my own producer / mixer / mastering
engineer when I have to be.
Better go MySQL or other SQL. Many Lynux based ISPs will include it
with your web goodies, and far easier
You can use MySQL or altSQLite for this project. If the database is
single-user and resides on the local system, altSQLite may be a
better choice.
I should have mentioned that I'm working in OSX, though I want what
I write to work on Windows and Linux if possible. I take it that
doesn't
But that's *also* a $150 download, if I'm reading right.
Charles Hartman
On Sep 26, 2005, at 8:53 PM, Dan Shafer wrote:
You can use MySQL or altSQLite for this project. If the database is
single-user and resides on the local system, altSQLite may be a
better choice.
I should have menti
On 9/26/05 5:11 PM, "Charles Hartman" <[EMAIL PROTECTED]> wrote:
> Thanks for your very thought-provoking response. One little piece:
>
> On Sep 26, 2005, at 7:04 PM, Dick Kriesel wrote:
>
>> performance data =
>> recording
>> artist
>> instrument -- examples: guitar, voice
>> pe
On Sep 26, 2005, at 8:17 PM, Stephen Barncard wrote:
Producer? Mixer? Mastering Engineer?
Those are Categories not included in your spec proposal. I'm
especially sensitive to the first 2.
As far as me promoting SQL in general, and through an ISP
specifically, is that is the best route I'v
On 27 Sep 2005, at 03:06, Dick Kriesel wrote:
On 9/26/05 5:11 PM, "Charles Hartman"
<[EMAIL PROTECTED]> wrote:
performance data =
recording
artist
instrument -- examples: guitar, voice
performance category -- examples: solo, lead, backup
This isn't quite right, because eac
Charles Hartman wrote
People here have convinced me not to write a whole relational
database manager from scratch (that didn't take much). As far as I
can tell, if I want to do this open-source (except for Dreamcard),
that makes my choices either
MySQL with Dreamcard
or
SQL
On Sep 26, 2005, at 10:55 PM, Stephen Barncard wrote:
On Sep 26, 2005, at 8:17 PM, Stephen Barncard wrote:
Producer? Mixer? Mastering Engineer?
Those are Categories not included in your spec proposal. I'm
especially sensitive to the first 2.
And understandably so. (Sorry -- it took my
On Sep 27, 2005, at 3:44 AM, Alex Tweedly wrote:
[NB - I'd use Trevor's libDatabase along with either 1, 2 or 3 -
looks really nice, esp. for someone who isn't an SQL expert. And it
does work with PostgreSQL, even thought there are a few places
where it only mentions MySQL.]
There are a c
Hi Charles,
Thanks for the SQLite pointer, in any case. But $149 for the plugin
is not what I would call "inexpensive."
You can use the concepts of relational databases without using mySQL.
That is you use some textfields to be the equivalent of a mySQL
database.
Assume that the basic r
Marielle,
That's very helpful -- thanks. This thread has gotten me looking at
MySQL, and I think I'll keep pursuing that, though I believe you that
I don't absolutely need it for this project. (And who knows, I may
manage to populate the thing with more than 1000 tunes . . . in
several ye
On Sep 27, 2005, at 9:44 AM, Trevor DeVore wrote:
that can be a big kink in your port
Which could really clog up shipping, to say nothing of what it might
do to the price of oil.
~~
Dan Shafer, Information Product Consultant and Author
http://www
33 matches
Mail list logo
