> Has anyone figured out the coordinate system for the mfc-rect? I
it's the usual (unless you're on a Mac ;-) coordinate system: (0,0) is
the top-left corrner of the screen, y increases towards the bottom of
the screen.
> figured out the systems are RECT (50,y,800,y). The positions and other
the rect components are (x,y,width,height)
Width is pretty much a constant (although I wouldn't assume it is),
the others vary according to how much stuff there is in the system.
The position of most of the other elements is not saved in the PTB
file, but it can be computed based on the many XXXSpacing attributes
and the content of the system.
--
Simone Tellini
http://www.tellini.org
But, I think it's a little more complicated than that. The the width
and height is what I'm having issues with. The coordinate of x is
always dependent on the font height of the musical notation, the chord
names, and rhythm slashes . (which the parser doesn't calculate) I
cannot always depend on "x" being every 250 logical units, etc. I am
having the same issue with the position RECT.
On Aug 15, 6:34 am, Simone Tellini <simone.tell...@gmail.com> wrote:
>
> But, I think it's a little more complicated than that. The the width
> and height is what I'm having issues with. The coordinate of x is
width and height of what? systems? positions?
Systems are the easy ones: system->GetRect() gives you the exact
location and size of the rectangle containing the whole system.
The x of the positions derives from system->GetPositionSpacing(),
which you can consider as their width. To get the first x, you need
to consider if there's a clef at the start of the system, make room
for time and key signatures, etc...
> always dependent on the font height of the musical notation, the chord
> names, and rhythm slashes . (which the parser doesn't calculate) I
> cannot always depend on "x" being every 250 logical units, etc. I am
as I said, the coordinates of most of the elements must be computed
based on what's in the tab. You need to take your time to think how
to put all the elements together: see how the pieces relate to one
another, what hints you can get from the information in the tab and
figure out a layout algorithm that can places everything where it
needs to be.
It's not easy and it takes quite some time: begin playing with only a
subset of the elements (for instance, try doing only the tablature
first, which is the easiest part), then increase the complexity
little by little.
Brad said that writing the drawing code starting from the parser is a
"fairly comprehensive task". He did mean it ;-)