tapper-develop Mailing List for Tapper

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

    Just to make sure I didn't foobar the mail list

DLP

Hello Everyone:

Well, you've all been very patient.  But I finally have a new file
release up on sourceforge (sort of).  I say "Sort of" because
sourceforge seems to be having some trouble right now.  I can't get it
to serve up any web pages.  It just hangs there saying "stalled".

However, At some point in the very near future you will see version
0.01G

This version has MANY major improvements.  The main one being the
addition a fully functional fretboard object and fingering objects.  The
main place you can see these is in the color dialog.  All the attributes
of the fretboard object can have their colors changed by Rex's color
dialog.  I put a major chord in the color box so you could see some
fingerings.  You'll notice that you can even select teh active and
non-active colors as well as see the interval names.

Also, there is a mockup of the diagram panel on the main screen that
uses a couple of fretboard objects.

The fact that the fretboard works means that the following objects:
Formula, Fingering, FingeringSet, Interval, Note, GridColors, Tuning,
FretDot, and FretDotSet all work.  THAT means that we've opened up a lot
of development oppurtunities.

1.  We can now build some sort of gui to create new chord and scale
formulas.
2.  We can work on the process of building chord and scale fingerings
from a tuning and formula object.
3.  We can start on the ear training and flash card sections.
4.  We can even work on MIDI implementation.

This really opens a lot of options.  I know everyone has been waiting
for me to get this work done and I'm sorry it took so long. I took a
sick day off today and finally finished it. :-)

So I'm pretty happy about it.  Go ahead and download it and let me know
what you think.

Thanks

Greg
A.K.A. Dru Lee Parsec

Quick Status:  I'm working on teaching the fingering objects how to draw themselves.  I
figure another night should do it.  I'll let you know when there's another code
release.

Thanks

Greg

I've got the Frets, Dots, and Strings painting really well.  I got the
background problem fixed as well.  I still have the fingerings to do as
well as the fret numbers below the grid.

I also have the Fretboard showing up in the color dialog, but I don't
have Rex's color dialog actually changing the colors yet.

I'm going to have to break for the evening and probably for the weekend
(I might have some time Sunday morning to hack).

I'm not going to put up a file release yet because the FretBoard class
is really only half way done and it won't be much use to anyone yet.

Also, I added a com.tapper.tools directory as a place to put little
support programs.  Right now I have a GridTest program that just
displays the FretBoard.  I'll modify the "ant jar" target so it excludes
that directory from the jar target.  But, any development support
program you need should be put there.

Thanks.  Hope to have more info on Sunday.

Greg

Hi y'all:

I was able to get some time to work on the grid class today (The object that
displays the frets and strings).  I've got the frets and strings showing up but for
some reason I can't get the background to paint anything other than grey.  (I tried
setOpaque(true) and no difference).

Also the line widths are too thin.  I'll need to figure out how to get those set
thicker.

Lastly, I'll need to make the frets and fingerings appear.

It's coming along nicely.  I'm learning about Java2D programming at the same time
that I'm writing this so it's going a bit slower than I had hoped. Also, I'm going
to be swamped with work this weekend (I'm starting a new consulting gig AND I have
to finish a lot of work on the house before the appraiser comes on Monday AND we're
having guest over on Sunday.

I know we're all waiting for this class to be finished before we can move on so I'll
do what I can to complete it.  Thanks for being patient. :-)

Greg

P.S.  It just happens that I need to learn about Java and XML for work.  And we were
just talking about integrating XML as our property files.  Cool!

I just realized that I forgot to upload the chord and scale data for the
NewTap.exe program so the Windows versin won't work yet.

I'll put that up tonight.

Greg

I sent a similar message to this last night but I still don't see it in the
archives.  Let's try again:

Basically the Tapper website is now a kinder gentler web site without all
the "too hip" Acid Trip backgrounds.

It's much easier to read.

I have time scheduled on Thursday evening (tomorrow) to write some more
code.
I'm going to concentrate on getting the grid working and then perhaps a
quick and dirty tool that we can use to build basic chord/scale formulas
just so we can test the grid and our algorithms.

I'll let you folks know what I was able to do when I put up the next code
release.

Greg

Hello everyone:

0.01f is now in the file release section of the sourceforge web site.  Many
changes have happened:

The package names are now set to the new paradigm.  They are:
com.tapper.xxx

The main class is now com.tapper.gui.Tapper

Many new classes have been introduced to support Sean and Wayne in their efforts:

Note (already in current build): Has a MIDI note number and a note name
(like C# or Fb).

Interval : a distance between a note and the root note. Also knows the
interval name i.e. root, M3rd, 7th, etc.

Formula : a collection of intervals that has a name and knows if it's a
chord or scale.  So, a major triad would have a set of intervals of a root, M3rd
and a 5th.

Fingering: The positionof a SINGLE finger.  Has a Note, a string and
fret number, and an interval (so it knows which position it is within
the formula.

FingeringBlock: A collection of fingerings which could be a chord or
scale. It also has a Key name, a Formula, and the high and low frets.
It would get it's name from the Formula object.

Also, the create tuning dialog box has some new stuff in it.  I havn't made any of
these new
features serialize yet.  In any case, since we changed the package names the old
tunings.ser won't
serialize anyway.  If you create a tuning for testing purposes reailze that it
will certainly change.
Maybe as soon as tomorrow.  But once I get the last few features in the tuning
dialog box that should
lock down the serialization of the Tuning object.

Thanks for all the help and input.  I'll be able to get more done this week than
last week.
I'm looking forward to coding again.

Greg

I thought I had lost an executable copy of the original Tapper.  Plus, the
original was compiled in MSVC version 1.5 which will no longer even install on
Windows 98.  Since I don't have a modern Microsoft Visual Studio on my system
I can't re-load, re-compile, and see the old code work.

Well, I discovered that I had a version that I had re-named NewTap.exe  It
works great (in Windows only)  It has a lot of the features that we're trying
to re-build.  However, the biggest change is that ONLY 10 string standard
tuning is supported in this version of Tapper. (it was, remember, only a
demo).  But MIDI is fully supported, and a lot of chords and scales are
supported. (chords are supported as triads only).

So if you want to see teh original Tapper and play with it on Windows then at
last we have a working copy!

Have fun.

Greg

Sean Wrote:
if I screw up, Greg is to blame

***********
Greg Responds:

Gotta admit, that made me laugh out loud. :-)
Sean's a great guy.  And Lisa's a great woman and they make a great team.

Sean: I'm going to write some of the support classes today.  I'll put up a
build sometime today (saturday).
If you want help with the grid let me know.

Also, here's an idea.  What if I write the grid just so we can get the grid up
and running BUT I also need the Grid to be able to display fret numbers at the
bottom and intervals at the right side.  (Sounds like yet another BorderLayout
doesn't it?) You can do that part.

Something like this:

|---|---|---|---|---|
|-X-|---|---|---|---| 5th
|---|-X-|---|---|---| 3rd
|---|---|---|-X-|---| Root
|---|---|---|---|---|
  5   6   7   8   9

The fret numbers would be in BorderLayout.SOUTH and the interval names would be
in BorderLayout.East but we could turn them off if we don't want them (Like in
the color dialog for example).

What do ya think? or would you like to tackle the grid yourself?  Either way is
fine, I'm just offering my help.

Greg

Hey, this is Sean. Quick personal intro before I give my $.02.
I recently graduated from San Diego State in May.  For about 6 months prior 
to that I was an intern at a small software company in San Diego, where Greg 
was my boss.  He taught me java from the ground up.  I only knew some basic 
concepts and syntax before meeting him.  (if I screw up, Greg is to blame 
j/k :))  Java is my favorite language to code in.

I'm currently a developer working for Computer Associates in the Seattle 
area.  My group develops the Advanced Help Desk option for the TNG Unicenter 
Suite.  (almost as big and just as bad as our neighbor in Redmond, WA) I 
probably spend about 1/2 my job working on java stuff now.  The rest is a 
mix of everything from HTML to proprietary scripting languages.  I am a huge 
Linux/Free Unix enthusiast and constantly find new uses for those OSes.  
(BSD makes a much nicer firewall IMHO).  If anyone needs a secondary DNS or 
just Linux help, I'll be glad to help.  My website is http://yunt.net

Back to Tapper:
If distributing an executable binary is really important, why can't we just 
compile Tapper for a handful of platforms?  It might even make it faster :()

Also, ant is a really cool tool and it's working great with the this 
project.  Is there some actual instructional documentation?  The jakarta-ant 
site left a whole lot to be desired.  I'd like to learn the tool better and 
use on some other projects.

Weekend is near, so hopefully I'll be get off my arse and write some code.  
I have Greg's latest ideas for the playing grid and frets.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

[I sent Wayne e-mail on this already, but I thought I'd repeat it here for
everyone else benifit as well]
First of all, Welcome, we're all glad to have you.  Maybe we should all
write a quick "Howdy, this is who I am " note to the mailing list???

**1)  May I propose that as a goal all intermediate representations be in
XML?

I really like this idea.  My favorite text editor is Jext and the source
code for Jext saves all of it's parameters in XML.  They go so far as to
put every single bit of text in every menu, window, and dialog in an XML
object so if Romain (the lead programmer) wants to make a French version
(which he might, he lives in Lyons France) he would simply change the XML
files.

I havn't done XML parsing but I'd like to learn.  I see that Javasoft has
released jaxp.jar which is an XML parser.  I havn't had any time to look
into it though.

If you want to make your objects save themselves in XML then go right
ahead.  I've got my tuning objects saves as serialized objects but I could
learn the jaxp API and change it to XML objects.

**2) When scale and chord dictionaries are developed, then they can be =
make available via the web.

Wow awesome idea.  I made a comment to myself in the code somewhere that we
should be allowed to have users "merge" in their chords and scales.  But
doing it via the web makes perfect sense.  I think sourceforge provides an
anonymous ftp site.  We could use that as the "library".

NEW FEATURE IDEA:  I've always assumed that we would save chord formulas.
i.e. a Major triad will be root, Major 3rd, 5th.  or the 0, 4th, and 7th
note of the chromatic scale.  (0,4,7 is a better representation for our
algorithm).  Then Tapper would run it's engine and compute a bunch of chord
and scale positions based on the key and the formula.

WHAT IF: we also allowed the user to place the dots on neck to show one of
his "Favorite Fingerings".  People could upload their "Favorite Fingerings"
and we allowed people to choose from a "Favorite Fingerings" list?  Folks
could upload and download these fingerings via the web or ftp.

**3) Microsoft, et al.  Even though we will be providing source code,
Visual J++ can compile Java into executables which we can supply to
others.

AAARRGGHH He said the "M" word on my mailing list!!  ;-)

I guess it wouldn't be too hard to provide an executable with each
"official" release, but I'm not sure if J++ supports java 1.3.  I know
there are certain parts of Java (RMI for one) that J++ does not support.
If it's an easy thing to do then let's go ahead and do it when we're ready.
If it's a pain then I don't think it's worth it.  Just IMHO YMMV.

**4) We will be supporting the Stick bass, Stick 8 and NS/Stick, I =
presume?

The Tuning object can have either 1or 2 TuningBlock objects.  The
TuningBlock object can have up to 8 strings, but this is an arbitrary
number that I used because 8 seemed to fit into the Create Tuning dialog
box easily.  But I'm going to change that dialog box anyway.  I'm not happy
with the way the create a tuning process flows.  I think my GUI has bad
Feng Shui.

BTW: I got Rex's code for the color selector dialog box last night.  I'll
make a build and put it up on the file section as soon as I have a free
hour at home.  (The house painting job is ALMOST done.  I'll have free time
again!)  I have lots' of changes I want to do.  For one, I want to change
the package names while we're still early in the process.  I also need to
add 2 check boxes to the tuning dialog box (and all the serialized objects)
for "Allow Open Strings?" and "Allow Barre Chords?".  I'd sure like to
build a bunch of those little "support" classes that Sean and Wayne need.
All I need is time.  If it wasn't for this darn job . . .  ;-)

Keep tapping.
Greg

Hello,

After talking with Greg, I'm in.  Here are a couple of thoughts I have, =
perhaps to spark a discussion:

1)  May I propose that as a goal all intermediate representations be in =
XML?  There may be others, such as the original Tapper format, but I =
think it would have to be supported.  I recommend that a user's =
preferences be stored as XML rather than the other format (whose name =
escapes me) simply because it can handle hierarchical structures.

2) When scale and chord dictionaries are developed, then they can be =
make available via the web.  The application should be web-aware: this =
could be as simple as adding an FTP client to up- and download from a =
site, or as complex as HTTP streaming from a web server. I favor the =
former, but may see the need for the latter at some time.

3) Microsoft, et al.  Even though we will be providing source code, =
Visual J++ can compile Java into executables which we can supply to =
others.  I have no personal experience with Visual J++, but it would =
seem that it would be an advantage to users who don't want to have to =
install the JRE.

4) We will be supporting the Stick bass, Stick 8 and NS/Stick, I =
presume?  So we would have to support single courses of 8 strings as two =
courses of 6 or 10.

As for me, I am a Sun Certified Developer for Java.  Since I became =
certified, though, I've been working on a lot of Microsoft C++ and VB =
projects and my Java's starting to show some rust.  This is an =
excellent, well-timed project for me.  Thanks for allowing me to =
participate.

Wayne Wylupski

I wrote: In mode 2 the fingering object paints itself as an
appropriate string.  ie: R, m2, M2, m3, M3, 4, aug4, 5, m6, 6, m7, 7, R,
m9, 9, and so on.

I meant to say : In mode 2 the fingering object paints itself as an
appropriate INTERVAL NAME.  ie: R, m2, M2, m3, M3, 4, aug4, 5, m6, 6, m7, 7, R,

m9, 9, and so on.

Hi Sean:

I have a slightly (OK, significantly) different idea.

Each Grid object takes a TuningBlock Object so it knows how many strings
there are. No instrument I know of has a tuning with a gap between the
strings of more than a 5th (7 frets)  (Certainly no player other than Allan
Holdsworth has hands that can span more than 7 frets) so if we show a 7 or
8 fret span then that should be enough.  However, we would also like to be
able to show an entire neck so let's not limit our grid.  Instead we'll
have a method where we can set the number of frets to be shown.

Since we know how many strings there are and we know how wide the Grid
object is we can figure out the spacing between the strings (Notice how
generic this is all staying, there's no mention of the exact number of
strings) Once we know the spacing we can easily calculate the width of the
grid.  That's how wide the frets should be drawn.  Then we draw the strings
horizontally.

There is a missing class that we still need.  We need a fingering class
that has a Note object in it, but it also has a string and fret number and
an interval name (Root, 2nd, Major 3rd, flat 7th etc).  The grid needs to
take a collection of these fingering objects.  This fingering object should
prbably also have a lowest and higest fret (of that fingering) so we know
how to number the frets and how to place the fret markers (But never show
less than 5 frets, even if a chord can be fingered on only one fret ).
Since we already know the vertical and horizontal locations of the frets
and strings we can easily compute how to center a dot on the string within
a fret.  Notice that we are NOT making the frets progressivly closer
together as they would on a real instrument.  We'll just keep the frets at
an equal spacing.  That spacing is determined by the size of the panel

If the grid has the position of the upper right corner (or whatever corner
Java 2D uses as the origin), the offset of each string from that corner,
and the offset of each fret from that corner, we can easily place them on
the grid. Since we know the spacing of the strings and frets we can compute
how big the fingering dot (or text) needs to be.

Now, each of these fingering objects also knows how to paint itself.  A
fingering object would have 2 modes.  Mode 1 is the dot mode, mode 2 is the
interval node.  In mode 1 the fingering object paints it's self as a dot
unless it's the root of the chord or scale in which case it paints itself
as a circle.  In mode 2 the fingering object paints itself as an
appropriate string.  ie: R, m2, M2, m3, M3, 4, aug4, 5, m6, 6, m7, 7, R,
m9, 9, and so on.

In either mode if the fingering is "active" (which means we are currently
playing it's MIDI note) then it paints itself in the "active fingering"
color.

So, the paint method will compute the size of the grid object and computer
the spacing for the frets and strings.  It gets the lowest and highest
frets from the fingering collection object and draws the frets and fret
markers.  (I'll build you a fret position class).  Then it draws the
strings.  Then it goes through each note in the fingering block collection
and places that note on the grid using the appropriate mode of drawing.
The only thing the fingering block will need to place itself correctly is
the upper left corner position and the string spacing and fret spacing.
Since the fingering object knows it's on the 3rd string and 5th fret it
will place itself correctly.

This is close to how I coded the original Tapper (actually, this design is
more object oriented than the original)   If having the original C++ code
is any help I could put it up on the web site.

This design isn't final.  Go ahead and beat it up and debate me on it.  I
think it's a good design but if you find some flaws I havn't seen then
that's great, we'll just make it that much better.

Greg

P.S.  Here's the requred classes

Note (done)
FingeringNote (not done)
Fingering (not done, this is a collection of Fingering notes with Key and
ChordScale objects)
FretDotPattern (not done, this shows which frets have fret dots, which fret
has a double dot, and if they are big dots or small dots)
GridColor (done)
GridSomethingOrOther (this is whatever the name of the actual GRID will be.
I couldn't think up a good name off the top of my head right now)
Tuning (done)
TuningBlock (done)
ChordScale( not done, the formula for a particular chord or scale)
Key (not done)

I guess I better get working on these support classes.  :-)

Regarding fret/grid:

It would be too sloppy to adjust colors for all the various finger positions 
using simple paint and graphics.  To make life much simpler, I have a rough 
plan:

The entire neck is a collection of visual fret objects.  Each fret object is 
a collection of positions (one for each string).  Each position has a 
set/get for color and note etc.

Here's a lame ASCII drawing to explain:

------------- <- fret object (guitar)
|E|A|D|G|B|E| <- each letter is a member position of the fret obj.
-------------

The entire neck is made a several fret objects stacked together:

-------------
| | | | | | |
-------------
| | | | | | | <- get the idea?
-------------
| | | | | | |
-------------

*idea*
Using some clever init method, I'm hoping all of the note values can be 
derived using some algorithm and then applied to the appropriate fret 
position.  The fret constructor could take the low string's note as a 
parameter and increment each new position in 5ths (stick in 4ths?) - it'll 
get worked out.

It might look ugly at first, but to start off, this could be a series of 
squares, squished together that can change colors :)

After thought:  If it's not any harder, I think a 3D rendering would be 
prefered, since the user could rotate the neck orientation - look down for 
stick, look up for guitar etc.

-Sean

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Sean wrote:

Here's a sure solution, use 'net.sourceforge.tapper.*'

net.sourceforge.tapper.main (tapper.java lives there)
net.sourceforge.tapper.actions
net.sourceforge.tapper.util
net.sourceforge.tapper.gui
net.sourceforge.tapper.tunings
net.sourceforge.tapper.dialogs

**************************

I really like this BUT I think we should just put tapper.java in the gui
package since the only thing we have there is Tapper.java, TapperMenu and
TapperToolBar.

However, net.sourceforge is a lot to type for people who arn't using Linux
and can't just type cd ne[tab]sou[tab]

but SF.NET is already used so we can't abbreviate it that way.

So, if there are no objections, I'll switch it to that.

Greg

I've added a chart of the MIDI note values to the web site at
http://tapper.sourceforge.net

The old Tapper was written in C++ for Micrsoft Visual C version 1.5 (that was a
long time ago).  It turns out that I can't even get MSVC 1.5 to load on Windows
98 (It was originally a Windows 3.1 program) so I have no way of even compiling
the code of the old product.

This means I can't run it which means I can't get any more screen shots.

Oh well, The old tapper is officially dead.  Long live Java Tapper!!

Greg

Tapper version 01D is now available on the file releases section of sourceforge.
There is a link on the source code page of the Tapper web page that will take you
there directly.

We have a new target in our ant build.xml file called "jar" simply type:

ant jar

and you'll build tapper.jar To run this file cd to the jar directory and type:

java -jar tapper.jar

Remember, if you make changes in the source tree those changes won't show up in
the jar until you run "ant jar" again.  I would suggest using "java
com.gregb.tapper.Tapper" while testing to make sure you're running from the lib
tree.  When you're done developing for the day then run ant jar to have a nice
tight single file.

In this release there's not that much new.  We have a GridColors class to hold
all the colors in the display grid (which I havn't written yet) and there is a
User/Color Setup menu item now.  Also, the basic tabbed frame is mocked up.

Sean, we need to talk about how we're going to build that GridDisplay.  Rex is
going to work on the color dialog box.  We also have a new developer who is not
only a Java certified programmer but is also a Stick Player.

Welcome Wayne Wylupski !

Wayne and I talked about having him work on the "Build new Chord/Scale" dialog
box.

GOALS:  This week I'm going to try to setup a CVS tree on sourceforge.  If I get
this done then I'll let everyone know and I'll write a set of instructions on how
to set up jCVS to link to the CVS tree securly.  This way everyone will have
access to the latest source code.

Thanks everyone.  I have a feeling things are really going to start happening
soon.  Me?  I have to spend all day painting (Still painting, when will it be
done!!??)  Actually, I think I will be done house painting today, so I can start
working on Tapper again.

However, I also just took on a pretty big consulting job for a company that is
doing some pretty amazing things with java in embedded systems.  Can't say
anything else about it other than it's cool.  So I'm a busy guy, but I'm not
going to let this project die,  I'll certainly continue writing code. (heck I
couldn't sleep last night so I wrote code a 1:00 am until I was tired).

In the mean time.  Could everyone e-mail me their sourceforge user names soI can
add you to the developer's list?  Thanks:

Dru...@us...

Thanks guys.

Greg Brouelette

Tapper version 0.01C is available both at Tapper.sourceforge.net on teh source
code page and at the http://sourceforge.net/projects/tapper/ site under the
"Files Release" link.

Tuning serialization seems to work.  Read the notes in a previous e-mail about
the class structure and usage of the new classes.

Have fun.

Dru Lee Parsec A.K.A. Greg

P.S.  The create tuning dialog WILL change.

Package naming should be more generic. com.xxx <-- xxx should be a personal 
identifier, not necessarily your product. If you're going to change all the 
package names anyway, I suggest using .org - since this is an 'open' 
project.

org.samba.client.gui <-- looks organized and concise

Oh darn, looks as if tapper.org is an actual domain name, as is .com and 
.net.  :(

BTW: there is also a gregb.com registered.

Couldn't you easily grep through the source tree and replace all 'gregb' 
with 'somename'?  Whatever you choose, it should be unique.

Here's a sure solution, use 'net.sourceforge.tapper.*'

net.sourceforge.tapper.main (tapper.java lives there)
net.sourceforge.tapper.actions
net.sourceforge.tapper.util
net.sourceforge.tapper.gui
net.sourceforge.tapper.tunings
net.sourceforge.tapper.dialogs

Looks like I've made a circular argument here.  :()

-Sean

----Original Message Follows----
From: tap...@li...
Reply-To: tap...@li...
To: tap...@li...
Subject: Tapper-develop digest, Vol 1 #5 - 1 msg
Date: Sat, 14 Oct 2000 12:32:41 -0700

Send Tapper-develop mailing list submissions to
	tap...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.sourceforge.net/mailman/listinfo/tapper-develop
or, via email, send a message with subject or body 'help' to
	tap...@li...

You can reach the person managing the list at
	tap...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tapper-develop digest..."

Today's Topics:

   1. Package name change.  What do you think? (Greg Brouelette)

--__--__--

Message: 1
Date: Fri, 13 Oct 2000 17:48:46 -0700
From: Greg Brouelette <gbr...@ho...>
To: tap...@li...
Subject: [Tapper-develop] Package name change.  What do you think?

I'm thinking that I want to get rid of the gregb mid-level package name.

I think the new package name structure could be: com.tapper. with gui, util,
tunings, etc under that.  However, we also have a 3rd level tapper directory
called "tapper" and a main class called "Tapper" so the main class would 
then
become :

com.tapper.tapper.Tapper

Which doesn't make me dance.

So, what if I moved the classes in the com.greb.tapper package into the
com.gregb.gui package?  It would then become com.tapper.gui and the main 
class
will then become com.tapper.gui.Tapper

OR

Should we eliminate the mid level package name all together?

Let's debate.

GB

--__--__--

_______________________________________________
Tapper-develop mailing list
Tap...@li...
http://lists.sourceforge.net/mailman/listinfo/tapper-develop

End of Tapper-develop Digest_______________________________________________
Tapper-develop mailing list
Tap...@li...
http://lists.sourceforge.net/mailman/listinfo/tapper-develop

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

I'm thinking that I want to get rid of the gregb mid-level package name.

I think the new package name structure could be: com.tapper. with gui, util,
tunings, etc under that.  However, we also have a 3rd level tapper directory
called "tapper" and a main class called "Tapper" so the main class would then
become :

com.tapper.tapper.Tapper

Which doesn't make me dance.

So, what if I moved the classes in the com.greb.tapper package into the
com.gregb.gui package?  It would then become com.tapper.gui and the main class
will then become com.tapper.gui.Tapper

OR

Should we eliminate the mid level package name all together?

Let's debate.

GB

I fixed the bugs in Serialization today.  I'll upload the code to the web
page and files section tonight.

Here's what we have so far:

The User/Select Tuning menu will bring up a dialog box with a combo box
full of tunings.
The dialog also has Create, Edit, and Delete buttons.  These all work.
There is a flag in the Tuning Object that can be set that says "You may not
delete this".  I havn't used it yet.
Do we want any of the tunings to be permanent?

When you build a tuning and click OK or Apply the tuning will be created
and added to the tuning list.
When the program is shut down the list of tunings will be serialized to a
file called tunings.ser.
When the program is started those objects will be de-serialized from
tunings.ser and re-built back
into the list (my test show that this all works).

There are 2 static methods in Tapper that you will find usefull.

Tapper.getTuningList(); will return a com.gregb.util.SortedVector with the
current list of all the tunings.
You probably won't need this but it's nice to have access to.

Tapper.getCurrentTuning() will return a com.gregb.tunings.Tuning object
which is the currently selected tuning.
WARNING. There may not be any tunings selected in which case this will
return a null.  Watch for that and handle
that situation in your own code.  In other words it is possible for the
user to delete all the tunings and then click OK.

Also, what should happen if the user opens this dialog box.  Clicks
"Delete" (which will immediately delete the tuning)
and then clicks "Cancel".  I'll think about this but I'd like your input.
I won't worry about fixing it tonight though.  I mainly
want to get out another code release so you guys can start writing code to
fit this release.

CLASS STRUCTURE:

The list of tunings is a sorted vector (from com.gregb.utils) which is a
collection of tuning objects.

A Tuning object has a name and at least one (and no more than 2)
TuningBlock objects.

Each TuningBlock object has a name, a number of strings, a maximum number
of frets. and an arrrayList
of Note objects which is the same size as the number of strings.

Each Note object has a MIDI value and it knows how to display it's note
name (C#, Fb, G, etc.)

The EditCreateDialog has two TuningPanel objects.  These TuningPanel
objects display a
TuningBlock.  They can also be edited and will return a new TuningBlock
that represents the current
state of the GUI.

Easy as pi.

I should have the new code out by 9:00 pm Pacific Standard Time tonight Oct
12th

Dru Lee Parsec A.K.A. GB

Sean, I can see your posting.  So far it's just you and me buddy.

GB  A.K.A. DLP

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct (26)	Nov (1)	Dec
2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)

tapper-develop Mailing List for Tapper

tapper-develop — Mailing list for Tapper Developers