Linus Nielsen Feltzing wrote:
> Ray Lambert wrote:
>> Does anyone control what goes in then? Or do you just back things
>> out when someone submits something that isn't popular?
> If someone does that, we seek him up and kill him. :-)
Sounds very effective... ;-)
>> For my own part (regarding my A-B Repeat patch) I've tried to be
>> careful to cross all the t's and dot all the i's but I discovered
>> after posting my latest update that I accidentally broke the
>> simulator. I usually check that before releasing but forgot to this
>> time. I will post a new update soon that fixes this.
> While you do that, also make sure that your LANG entries are last in the
> file. Also make sure that you bump the setting block version number,
> since the repeat setting must be 3 bits instead of 2 (thanks to the new
> "shuffle" repeat mode.
Okay. I'll have to take a look at those shuffle changes.
>> As for the display, I've implemented a graphical marker to show the A
>> & B marks for 'HAVE_LCD_BITMAP' devices.
> I'm not sure how they should look like, but they look like they are one
> pixel too high in my (default) WPS. I had to change the drawing code due
> to the LCD API change, maybe I screwed up somehow...
Is that change more recent than 6/14? If so, I haven't seen it yet; I'll
take a look.
The markers are usually drawn as an arrow head with the A marker pointing
right and B pointing left (if the markers are too close together, only a
vertical bar is drawn). They are drawn on top of the progress bar in XOR
mode so they still make some sense regardless of the song/scroll bar
position. There are no hard-coded positions and only the height is
hard-coded. The routine that does the actual drawing is in abrepeat.c
(where all functional ABR code is). It is called from wps-display.c on
the line following the scrollbar() call. The hard-coded height value
appears in this call and is the same as used in the scrollbar() call. All
other values are the ones calculated locally as the screen is being
laid-out and drawn.
In any case, I'll take a look at it when I update the patch.
>> If all else fails, I've wrapped all of my code in '#ifdef
>> AB_REPEAT_ENABLE' (defined in abrepeat.h) so the feature can just be
>> disabled on devices that aren't yet supported (or which cannot be
> No, you used #if AB_REPEAT_ENABLE. I'd prefer #ifdef, and (temporarily)
> have it in the config-xxx.h files.
Oops, yes, you're correct. I sometimes prefer to use #if instead. It
makes no difference to me though so I'll change them when I update.
I was thinking last night about the inability to add a status icon on the
non-bitmap display devices and an interesting idea occurred me. I
designed my A-B Repeat to work exactly like "Repeat One" mode if no
markers are set. Considering this, perhaps it would be better to simply
add the A-B functionality to Repeat One mode and NOT add a new mode for
ABR? Repeat One would only behave differently if a marker is set. This
would remove the need for certain requirements, such as the status icon,
config file changes, setting block changes, etc. What do you think of
Received on Thu Jul 7 17:47:24 2005