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?
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"
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
Brad
On Jun 22, 12:42 pm, "joneric_wennerst...@yahool.com"
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
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"
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
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:
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:
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"
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.
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 »
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:
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"
Brad
On Jul 9, 4:33 pm, "joneric_wennerst...@yahoo.com"
Brad
On Jul 11, 10:21 am, "joneric_wennerst...@yahoo.com"
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 »
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 »
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 »
Brad
On Jul 15, 10:32 am, "joneric_wennerst...@yahoo.com"
> ...
>
> read more »
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 »
Thanks for all your help, especially the information on MFC
serialization.