ThinkC digesting MIDI in with C on 68k macs - video

[joevt]

compromise:
active white notes with 33% gray
active black notes with 50% gray

Looks good. I think it can be improved by changing the alignment of the pattern so that each white key is drawn with the same alignment relative to the position of the key.

With the current alignment (relative to the window position), you see that the appearance of hilited white keys repeats every 4 keys. Every two keys has a dividing black line that appears darker then the dividing black line to the left or right. This is the phase problem I mentioned previously. The alignment can be changed using SetPortPenLocation or SetPenState. Choose a pnLoc, relative to the location of the white key, that gives the best appearance of a white key or a black key. The alignment of the pattern in the third or fourth hilted white key seems best - they don't have a corner black pixel at the bottom like the two left or two right hilited white keys do. Or maybe you prefer having the pixel in the corner.

The interior of a white key is 8 pixels which happens to be the width of a pattern. The pattern would look best if the white keys were 1 pixel wider or narrower, so that the left and right edges will have similar appearance but then maybe the keyboard wouldn't fit in your window or the keyboard keys would be too narrow.

Fixed-size 8x8 patterns can only repeat every 2, 4, or 8 pixels vertically and horizontally. The 33% gray pattern repeats vertically every 2 pixels and horizontally every 4 pixels.

Current appearance of the pattern (0 and 1) of a white key with border pixels B:
B 1000 1000 B
B 0010 0010 B

Making the white key one pixel wider makes the pattern more symmetric between the border pixels:
B 0 1000 1000 B
B 0 0010 0010 B

Or one pixel narrower:
B 1000 100 B
B 0010 001 B

 

[Mu0n]

Looks good. I think it can be improved by changing the alignment of the pattern so that each white key is drawn with the same alignment relative to the position of the key.

With the current alignment (relative to the window position), you see that the appearance of hilited white keys repeats every 4 keys. Every two keys has a dividing black line that appears darker then the dividing black line to the left or right. This is the phase problem I mentioned previously. The alignment can be changed using SetPortPenLocation or SetPenState. Choose a pnLoc, relative to the location of the white key, that gives the best appearance of a white key or a black key. The alignment of the pattern in the third or fourth hilted white key seems best - they don't have a corner black pixel at the bottom like the two left or two right hilited white keys do. Or maybe you prefer having the pixel in the corner.

The interior of a white key is 8 pixels which happens to be the width of a pattern. The pattern would look best if the white keys were 1 pixel wider or narrower, so that the left and right edges will have similar appearance but then maybe the keyboard wouldn't fit in your window or the keyboard keys would be too narrow.

Fixed-size 8x8 patterns can only repeat every 2, 4, or 8 pixels vertically and horizontally. The 33% gray pattern repeats vertically every 2 pixels and horizontally every 4 pixels.

Current appearance of the pattern (0 and 1) of a white key with border pixels B:
B 1000 1000 B
B 0010 0010 B

Making the white key one pixel wider makes the pattern more symmetric between the border pixels:
B 0 1000 1000 B
B 0 0010 0010 B

Or one pixel narrower:
B 1000 100 B
B 0010 001 B

I ended up making 4 Patterns instead of just one for white notes.

SetPortPenLocation is not available in my IDE, and trying to affect pnLoc either with SetPenState, or a MoveTo didn't do anything.
I even tried to SetOrigin to each note's top left corner, it just painted the region to the top left of the windows GrafPort.

I just used the note's region's left edge, modulo 4 and used the result to select one of 4 33% gray patterns, each one "RORed" 1 pixel relative to the previous.

 

[Mu0n]

Uh oh.

I have a fresh problem-
When I run it on my hardware Mac Plus, the window loads up, the button graphics finally show up and I immediately get a bomb: Coprocessor not found. This doesn't occur in emulation. This didn't use to happen on the Mac Plus in earlier builds either.

I know it can be various things:

using FPU instructions (I'm not obviously)
stack overflow (this, I will need to investigate - any tips on how to do this effectively?)
getting out of bounds in arrays
anything else?

 

[Mu0n]

Uh oh.

I have a fresh problem-
When I run it on my hardware Mac Plus, the window loads up, the button graphics finally show up and I immediately get a bomb: Coprocessor not found. This doesn't occur in emulation. This didn't use to happen on the Mac Plus in earlier builds either.

I know it can be various things:

using FPU instructions (I'm not obviously)
stack overflow (this, I will need to investigate - any tips on how to do this effectively?)
getting out of bounds in arrays
anything else?

After an hour of snooping, I isolated the faulty code, and it was satisfyingly a recent enough chunk I've been using for less than a week, so it made sense.

PianoStates **ps;
CDEFProcPtr proc;

ps = (PianoStates**)((*cPiano)->contrlData);
HLock((Handle)ps);
HLock((*cPiano)->contrlDefProc);
proc = (CDEFProcPtr)*((*cPiano)->contrlDefProc);



if((lastCmd&0xF0)==0x90)
    {
    (*ps)->noteOn[lastNote] = 1;
    proc(0, cPiano, 100, (long)lastNote);
    }
else if((lastCmd&0xF0)==0x80)
    {
    (*ps)->noteOn[lastNote] = 0;
    proc(0, cPiano, 100, (long)lastNote);
    }

HUnlock((*cPiano)->contrlDefProc);
HUnlock((Handle)ps);

I'm pretty sure the faulty line is a Handle Lock on something that's not a handle (duh!) in the 2nd HLock you see near the top.

for reference, these are the structures I've used here:

typedef pascal long (*CDEFProcPtr)(
   short varCode,
   ControlHandle c,
   short message,
   long param
);

and PianoStates is a shove-it-all-in-one-place data accompanying my piano control CDEF

typedef struct {
    Boolean noteOn[128];
    Pattern blackPat;
    Pattern whitePat;
    Pattern grayPat;
    Pattern actBlackPat;
    Pattern actWhitePat;
    Pattern actWhitePat2;
    Pattern actWhitePat3;
    Pattern actWhitePat4;
    RgnHandle noteRgn[88];
} PianoStates;