Conference rdvax::grateful

For the PC disabled, I've also put a PostScript version of the document in
the same area:

	EZWIND::USER$:[LEVY.BG_TREE]TAPE_LIB.PS

  dave

Hi Dave,

I just looked over your spec.  It looks great, but you're missing something.
Flaws - you need another one or two Flaw Types to describe DAT tape dropouts.
This is quite important!  Whenever I play a DAT that has a dropout, I find
myself scribbling on the teeny-weeny tape label stuff like, "diginoise at 
28:00 in IMHBtR, not from my tape" and then I wanna go look for someone's
better copy of 7-31-74 that does not have the dropout!
Diginoise is that chainsaw sound from misstracking.  You might even want to
have 2 varieties - Slight, and Severe.  Slight I'd consider just a brief
dropout or noise, the tape is still listenable.  Severe is, well, severe, and
makes you wanna FF past that part cause you can't bear to hear a beautiful
version of IMHBtRoses ruined so badly.
Actually, diginoise comes in two main varieties - dropouts on YOUR copy of the
tape (you can observe a jump in the Error Count on a deck such as the Panaonic
3700), or dropouts somewhere upstream of your copy, that got propagated.
I thing its a good idea to distinguish between the two,

Also, its possible to have multiple flaws - you can have a PitB with a Slight
dropout, and thats also cut off at the end.

You also need another Flaw for songs that are cut _into_ - missing the first
few seconds.  Presumably you're going to indicate this on the tape labels
using symbols something like:
	/Truckin>	(Truckin cut into, segues into..)
	Spanish Jam> #	(has slight diginoise on my copy)
	He's Gone/  && 	(cut off at end, severe diginoise on prev. copy)

I got the / idea from a few other taper's lists, and I like how it indicates
cuts.  #, && is my idea, but any appropriate symbols that brings hash-noisse
to mind would work.    For an Interruption symbol...hmmm...  % ?

So, when ya gonna finish the software?  I wanna use it!  I'll beta-site it :-)
It might also be good to have a means of reading in existing ascii tapelist
databases.  I surely don't want to retype in hundreds of shows.
Once the data's in, then the user could go thru and fix up entries for missing
minor data fields.  Some way of reading in setlists would be good too.
I don't mind re-editing my Postscript label setlists a little, to hammer 'em
into a form thats readable by the program, but I rilly don't wanna retype 
all those setlists!  thats far worse than retyping shows!  :-)

Name of the tape label .ps file - might wanna have something better than
tape_lab.ps?  label the .ps file with by the show date+Unique ?

 - thanks, Josh

Gee, I was hoping for more internal info, like how are you maintaining 
the lists.  Linked lists, doublely linked, hash tables, that sort of 
stuff, but then that's just me ;-)  Agree with Josh about the tape
label name.  I have, or had (I think I done deleted it, sigh, might be
on tape though ;-) a tape lable generator which basically made the
output postscript file named label.  So it kept overwriting the same
file unless you moved them around a bit.  Not a big problem, but something
to think about.
Questions about some of the fields:  These are optional I know, 
but... Why Owner?  That sounds like something that should be part of
the main data, and need not be entered more than once, unless you 
intend on mixing up your collections.  Song titles:  why the 32 char
limit?  Most can fit, and others can be abbreviated, but it seems restrictive
to me.  Of course it makes it easier to generate the labels that way ;-)
But basically ok.  I just see these general descriptions and then 
start designing it myself in my head.  Already did something like this,
for myself for home, but got bored entering the data ;-)
Is this just a text based thing, or are you designing a GUI to go along
with this? ;-)  And how about the postscript stuff?  Do you have some 
generic calls into a postscript library, or do you plan on hardcoding it
in yourself.  Postscript is like a whole nother language unto itself
and I wouldn't want to have to program in both C and postscript for 
a single course.

PeterT

re: .2 (Josh)

>Flaws

 I'll have to enhance the flaw section to take into account this stuff.

>Name of the tape label .ps file

 Yes...there is probably something better that I can come up with for naming
 the output file.  I figured that, with a system like this, there is no need
 to keep the .ps file around and that a generic filename would be ok.  If
 I get good enough to use standard Windows printing, then I won't even have
 to do this.

>So, when ya gonna finish the software? 

 Sometime this decade. :-)  I'm a beginner at this stuff, so it ain't gonna
 be a usable tool until at least sometime this summer (optimistic).

>It might also be good to have a means of reading in existing ascii tapelist
>databases.

 If the datafile spec is published, then this could be an excercise for the
 end user.  I certainly plan on converting my existing RMS file into this
 tool.

RE: .3 (Peter)

>Gee, I was hoping for more internal info, like how are you maintaining 
>the lists.  Linked lists, doublely linked, hash tables, that sort of 
>stuff, but then that's just me ;-)

 Guidance, please!  I'm a novice programmer (at best).  I don't want to have
 any dependency on a database, so figured that "flat" files would suffice.
 Any suggestions?

>Why Owner?

 My plan is to make the owner something that has a default value (based on
 some user-maintainable data somewhere) but that can be overwritten for the
 purposes of generating labels for tape copies made for others.

>Song titles:  why the 32 char
>limit?  Most can fit, and others can be abbreviated, but it seems restrictive
>to me.  Of course it makes it easier to generate the labels that way ;-)

 Gotta have some way to scale the labels and I figured that 32 characters 
 would fit most anything.  Suggestion?

>Is this just a text based thing, or are you designing a GUI to go along
>with this? ;-) 

 Eventually, it should evolve into a Win32S application.  Initially, it will
 be character cell and should run in a DOS window.

>And how about the postscript stuff?

 I know PostScript enough to do simple things like labels.  Again, if this
 ever evolves to a real Windows app, I can use standard print routines.

Thanks for the input...keep it coming!!

	dave