position vs note

[joneric.w...@gmail.com]

I've been looking at the power tab parser c++ code and have a few
questions.

1. What does a position represent, and how is it different from a
note?
2. I don't understand why position has its own set of simple flags and
complex types, and note has its own different
set. Does position represent a chord or rest, whereas a note is
simply a single note?

[Dummy]

Yes.

A note is an individual note.
A position is a group of notes, or a rest in a voice/melody.

A tremolo bar symbol is applied to the position. (effects all the
notes in the group)
A bend/slide symbol is applied to only a single note in the group.

Brad

On Jun 17, 5:54 pm, "joneric_wennerst...@yahool.com"

[joneric.w...@gmail.com]

Thanks very much brad.
I was wondering if it were possible, to ask you a question or two
about the power tab 1.70 file format.
They are very detailed questions, for instance, about serializing
arrays.
I've converted your power tab parser from c++ to java, and now I'm
starting to debug my code.
There seems however, to be "extra" bytes in actual .ptb files that I
haven't accounted for and can't figure out :-)

If you're agreeable to it, would it be better to e-mail directly,
rather than clutter the forums with my questions, or would you rather
just use the forums?

Thanks.
joneric

[Dummy]

Just use the forums. Someone else may have similar questions, or learn
something new.

Brad

On Jun 22, 12:42 pm, "joneric_wennerst...@yahool.com"

[joneric.w...@gmail.com]

Thanks for offering to answer my questions.
I've managed to figure out some of it over the weekend.
The c++ code uses serialization to write out instances of some
classes.
This causes the following information to be written to the ptb file:

1. 4 bytes: marker - FF FF 01 00
2. 2 bytes: length of serialized class name
3. name of serialized class (ex: CGuitar, CChordDiagram, etc)

This info precedes the actual serialized data.
What I'm having problems with is that between each instance of the
serialized class in the .ptb file,
there seem to be random bytes of data. For example, after each
GuitarIn data, there are two bytes which contain 0D 80,
except if its the last GuitarIn, then there is only a single byte
after it.

So, you would have something like the following:
<GuitarIn 0 data> 0D 80 <GuitarIn 1 data> 0D 80 <GuitarIn 2 data> 0D
80 <GuitarIn 3 data> etc.

I've found similar problems with all the classes.
CFloatingText had 3 miscellaneous bytes after it.

These "miscellaneous" bytes vary in length depending on the class and
whether it is the last instance of the class.

So, my question is whether there is a pattern to these "miscellaneous"
bytes, and what is their meaning?

Currently, I'm having to write some kluge code in order to skip over
these "miscellaneous" bytes to get the file pointer back in synch and
pointing to the next piece of data within the .ptb file.

Since you used c++ serialization, I think these details are hidden
from you, so you likely will not know the answer to this, and I'll
just have to make due and keep my kluge code.
But, on the off chance that you have some knowlege of these
"miscellaneous" bytes, I thought I'd ask.

Thanks for any help
Joneric

[Dummy]

All of this stuff is the cause of the built-in MFC serialization
routine, which has been ported to the wxWidgets classes. It's overkill
for what is needed in PT, but I only had about 6 months of c++
experience at the time and didn't know any better.

The reason why all this extra data is being written can be seen in a
simple example. Suppose you have three classes, Cat, Dog and Mouse,
each derived from a base class Animal. You have a list of Animal
objects that will be serialized. Because the list may be made up of
different types of Animals, you need to save the class information for
each Animal. In the case of the Microsoft code, they store the name of
the class once (the first time), and then use a reference to that data
for each successive object of that class that's saved.

As I mentioned earlier, this is overkill in PT, since we know each
list contains the same type of objects. (i.e. all CTempoMarkers, all
CDynamics, or in the case of the above example, it would be a list of
all Dogs, or all Cats). It could have been written as a count value
followed by each class' data.

You can get an idea as to what's happening in the PowerTabOutputStream
WriteObject/WriteClassInformation functions.

Here's what's happening when an object is written using the
WriteObject function:

1) If the pointer to the object is Null, write the "Null tag". This
should never happen in PT as no object would ever be Null - it's there
for completeness.

2) If the pointer to the object already exists in the object map,
write out the index of the object. This should never happen in PT as
each pointer to an object should be unique. This is used in the event
that you have the same pointer stored multiple times in the same list.

3) If the pointer to the object doesn't exist in the object map, map
it in the event that the pointer is stored multiple times in the list
(ala 2) and write the class information/data for the object by calling
WriteClassInformation. This is the only condition you have to worry
about since 1 and 2 should never occur.

Here's what's happening in the WriteClassInformation function:

1) If the object's class information has not been written to the file

a) The "new class tag" is written. This is "FF FF".
b) The schema version is written. This is "00 01". This field is
irrevelant in PT, since schema only works under certain conditions,
which of course I found out after the fact. This value should always
be 1. The true "schema version" in the .ptb file is the version number
found in the header.
c) The length of the class name is written.
d) The name of the class is written.

i.e. The first time a CMouse object is written to file, MFC would
write:

FF FF 01 00 06 00 "CMouse" in hex

FF FF = "This is a class that hasn't been written yet"
01 00 = version 1 of the class
06 00 = class name is 6 bytes long
CMouse = name of the class

2) If the object's class information has already been written

a) The "class info previously written flag" (0x8000) is OR'd with the
"write index" of the class.

The "write index" of each class is simple the order in which each
class is written to the file. In the Animal example, if the order was
Cat, Dog, Mouse, Cat would be index "1", Dog index "2", Mouse index
"3". If the order was Mouse, Cat, Dog, Mouse would be "1", Cat "2" and
Dog "3".

i.e.

01 80 = this is a previously written class, with index "1" (aka the
first class that wrote it's class info to file)
0d 80 = this is a previously written class, with index "13" (aka the
13th class that wrote it's class info to file)

Brad

On Jun 25, 12:38 pm, "joneric_wennerst...@yahool.com"

[joneric.w...@gmail.com]

Thanks very much.
That was way more information than I could have expected.
I sort of figured out the first part of the serialization after
looking at a few .ptb files.
Thanks very much for the rest of the info.
It definitely helps and it'll help my java code be more readable since
I can put comments in about these bytes that are part of MFC's
serialization.

I'm making pretty good progress on the java version of the ptb file
reader, and should have it finished in about two weeks or so,
depending
on how much free time I have.

Thanks again for all your help.
I think I have enough information to finish it up.

So far I've got the header, dynamic, tempo markers, chord diagrams,
guitars, guitar ins, floating text, font settings and tunings classes
all working.
So, now I'm on to the the core of the .ptb file, namely, the systems.
This is what I'll be working on over the next two weeks.

Thanks again for the help.

joneric

[joneric.w...@gmail.com]

Here's a simple and quick question for you.

What you are calling a "system" in the power tab parser c++ code is
actually the same thing as a "section" in the power tab editor.
Is that correct?

In the editor, the menu choices across the very top have "Section".
Is "system" left over terminology from an earlier version of power tab
editor?
Or is it the other way around, and "Section" is from a previous
version and "System" is what you want to use going forward?

In the .ptb files, I see the class name "CSection" and not "CSystem".

Just like to know so that I can use the correct terminology.

Thanks.

joneric

On Jun 25, 8:51 pm, Dummy <dummy...@power-tab.net> wrote:

[joneric.w...@gmail.com]

I posted a reply yesterday, but I don't see it in the forums today, so
I don't know if it got "lost", so I'll repost it just in case.

Thanks for the info on the serialization.
This stuff is a real pain to deal with.

I think there is a little more to it, as I am seeing varying
"serialization separator" bytes with lengths other than two and other
than "0xXX 80".
CFloatingText seems to have three bytes between data, and one byte
after the last instance.
If it weren't for this serialization stuff, I think I'd have finished
the java ptb file reader by now.

Anyway, thanks very much for the help.
Hopefully I'll sort it out and get the code to work :-)

Here's my next question though.
In the power tab gui editor, the menus along the very top of the
application has a menu choice called "Section".
In the .ptb file, there are instances of a class called "CSection".
However, in the c++ code, you refer to these as "System"s.
Is the term "System" just some terminology left over from an earlier
version of PTE, and "Section" is the new term to use?
Or vice versa?
I want to be consistent and use the same term you do going forward.

Thanks again.

joneric

On Jun 25, 8:51 pm, Dummy <dummy...@power-tab.net> wrote:

[Dummy]

System is the correct term in music terminology, so I renamed the
class in the parser. It still needs to be saved as CSection within the
file. There are a couple of other classes that were renamed as well.

You have to watch out for the list counts and string lengths - they're
not always the same size. Check out the WriteCount and
WriteMFCStringLength functions in the project to see how they're
saved.

In PT, the serialization tags should always be 2 bytes + 2 bytes +
length + name the first time the object is written, and 2 bytes for a
reference pointer the 2nd to nth time written.

Brad

On Jun 27, 10:42 am, "joneric_wennerst...@yahool.com"

[joneric.w...@gmail.com]

I think I've got it all working except for one last question about
beams in positions.
>From the code, it seems that a position can have more than one beam
set.
for example, a position can have a beamStart and a beamFractionalLeft.
I just want to make sure I have this right.

This is the last issue I'm having, and once I get it cleared up, I
think I should be able to post an alpha release
of my java ptb file reader. I need to do some more testing and add
some better error handling, but it basically works.
Thanks for all the help.

[Dummy]

beam start = the first of a group of beamed items
beam fractional left = beam that draws from left to right, but only
half way across

i.e.

If you had a 16th note, followed by an 8th dotted in 4/4 time beamed
together, the 16th is the start of the beam group, and has a
fractional left beam. You can get the visual by entering it into PTE.

Brad

On Jul 7, 1:34 am, "joneric_wennerst...@yahool.com"

> ...
>
> read more »

[joneric.w...@gmail.com]

I've been trying my java ptb file reader on several different ptb
files during the course of my testing.
I've found concrete examples where the second byte of the MFC
serialization bytes is 0x80.

Below is a list of transcribed songs by other PTE users and the
serialization bytes I've found in them.

found 0x83 in night ranger's "don't tell me you love me"
found 0x82 in dio's "holy diver"
found 0x81 and 0x84 in kix's don't close your eyes"

It's entirely possible that my java ptb reader code is wrong, although
I don't think so since these errors occur very far down in the file
(like file offset 7000, etc.)
Its seems unlikely that my code would get that far it it got out of
synch while reading in the ptb file.
It seems more likely that the second serialization byte is allowed to
be something other than 0x80.

Just an FYI for others.

On Jun 25, 8:51 pm, Dummy <dummy...@power-tab.net> wrote:

[joneric.w...@gmail.com]

I have a question about tunings.

I've been running my java ptb file parser on numerous .ptb files.
Every once in a while, I'll come across a .ptb file which has a tuning
with no name.
I've tried to reproduce this in the PTE 1.70, but I've been unable to
do so.

It seems that if you create a new tuning, or load a tuning from the
dictionary, the tuning always has a name.
My guess is that perhaps this was perhaps not the case in a previous
version of PTE, and tunings without names were allowed.

So, my question is:
Am I correct in that all tunings in PTE 1.70 must have names?

On Jul 9, 1:33 pm, "joneric_wennerst...@yahoo.com"

[Dummy]

Are these files v1.7 or older versions? If they're 1.7, you can run
the batch test in the parser. It loads a file, saves it to memory, and
then does a byte by byte comparison of the two to ensure they match.

Brad

On Jul 9, 4:33 pm, "joneric_wennerst...@yahoo.com"

[Dummy]

There's nothing in the code that stops it from being an empty string,
so I guess it is possible for the name to be empty, even though the
tuning dictionary will prevent it.

Brad

On Jul 11, 10:21 am, "joneric_wennerst...@yahoo.com"

[joneric.w...@gmail.com]

Here's a few things to note that are "bugs":

1. Tunings can have blank names
Although PTE version 1.70 prevents this from happening, older
versions apparently did, so the PTE 1.70 version of these songs may
contain tunings with blank names.
2. Bend durations
Although the note.h file specifies the duration <= 8, the PTE
editor has a "bug" in that the duration saved in the file is actually
one more than the duration a user chooses.
For example, if I go into the PTE editor and select a bend, say
Release (gradual), and choose "Bend over current note + the next" and
select 8, the value stored in the ptb
file is 9. Thus, the value for MAX_BEND_DURATION should be 9, and
not 8.
3. Although note.cpp states that the value of MAX_FRET_NUMBER is 24,
the PTE editor has a "bug" in that it allows users to enter fret
numbers up to and including 29.
So, MAX_FRET_NUMBER should really be changed to 29.

> ...
>
> read more »

[joneric.w...@gmail.com]

A few minor questions:

1. Is there any significance to a complex note attribute type 0 (not
used)?
I guess my question is why does it exist?
I ran across this in only one ptb file, but it was there, so I'm
asking about how to handle it.
Is it an error?

2. In PTE 1.7, you can select an initial volume for a guitar.
The allowed values are:
NotSet(255, "not set"), fff(104) ff(91), f(78), mf(65), mp(52),
p(39), pp(26), ppp(13), off(0)

However, I've encountered 2 or 3 ptb files that have volumes of
64, 62, etc.
Is this because of previous versions of PTE that had a different
gui interface and allowed different volumes?

On Jul 12, 12:02 pm, "joneric_wennerst...@yahoo.com"

> ...
>
> read more »

[joneric.w...@gmail.com]

I think I've found a bug in the c++ ptb file reader\writer code.
It is in the note.cpp file, in the Note::IsValidBend() mathod,
regarding gradualRelease bends.
The check on line 557 says:

returnValue = ((bentPitch == 0) && (releasePitch <= 11) && (duration >
0) && (drawStartPoint >= midPoint) && (drawEndPoint <
drawStartPoint));

I believe this is incorrect.
I think that the bent pitch and release pitch checks have been
switched, and it should instead be:

returnValue = ((bentPitch <= 11) && (releasePitch == 0) && (duration >
0) && (drawStartPoint >= midPoint) && (drawEndPoint <
drawStartPoint));

I've run across numerous files where the first version was correct and
also across numerous files where the second case was true.
So I don't know which version to put in the code.

On Jul 13, 8:22 am, "joneric_wennerst...@yahoo.com"

> ...
>
> read more »

[Dummy]

There is a bug related to the release bends, but I can't remember the
exact extent of it. I thought I had written a KB article about it, but
I can't find it. I'll have to search my e-mails.

Brad

On Jul 15, 10:32 am, "joneric_wennerst...@yahoo.com"

> ...
>
> read more »

[Dummy]

1. Complex symbols are stored in a simple fixed size array. notSet is
used to indicate the element is not being used and it should never be
written to file. If there is/was a bug that's causing it, the solution
is simple enough - simply ignore the item.

2. Quickly looking at the v1.7 code, it doesn't look like it's
possible to have something other than the values in the list. The
simple fix is to round up to the nearest item. off = 0, 1-13 = ppp,
14-26 = pp, etc.

I'll fix the bugs in the parser, thanks for the info. I'll wait until
you've officially finished your work, as you may yet find more
problems.

Brad

On Jul 13, 11:22 am, "joneric_wennerst...@yahoo.com"

> ...
>
> read more »

[joneric.w...@gmail.com]

I think I've finished the ptb reader part.
I was able to successfully read in 600 .ptb files.

Thanks for all your help, especially the information on MFC
serialization.