Beatbox code optimization question

[chipwich]

Ok. I've posted another Picaxe-08M project on site at <A href='http://www.medcosm.com/picaxe_beatbox.htm' Target=_Blank>External Web Link</a> . This is a device which can repeat a rhythm which is tapped on input pads. Pretty simple and very inexpensive (a $5 beatbox!) but surprisingly, I haven't seen anything like this.

So the question here, is that I've squeezed and resqueezed the code to fit the features you see. Unfortunately, software powerdown was eliminated in order to make the UI a bit nicer. But I'd like to put it back in. I think approx 18 bytes are needed.

Any thoughts on how to optimize this code further? Can the bit packing routines be performed more efficiently?

I know there is alot of brain power on this forum. Thanks for your suggestions.

 

[hippy]

You should be able to optimise your SaveSample and GetSample routines ...<code><pre><font size=2 face='Courier'>SaveSample:
LOOKUP smpPack(1,4,16,64),smpMultiplier
smpVal=tmpB5*smpMultiplier|smpVal
endSaveSample: </font></pre></code> Or even make smpPack the multiplier rather than an index ...<code><pre><font size=2 face='Courier'>SaveSample:
smpPack=smpPack*4
IF smpPack = 0 THEN
smpPack = 1
END IF
smpVal=tmpB5*smpPack|smpVal
endSaveSample: </font></pre></code> Also, if you can shift smpVal rather than shifting the sample, you can get<code><pre><font size=2 face='Courier'> smpVal=smpVal*4|tmpB5 </font></pre></code> which will save even more, but that's a bit more code rejigging.

A larger rewrite could be, not to fill each byte as you go along, but cycle through all storage bytes, setting the top two bits the first time, next two bits the second time, etc etc. Not sure if that will gain you anything or not. As is often the case it's a try it and see, even though it can sometimes mean a huge re-write for little or no end gain, and sometimes a worse outcome :-(

Edited by - hippy on 03/04/2007 18:55:01

 

[chipwich]

Thanks Hippy. Your solution freed up 40+ bytes!

The powerdown mode turned out to take much more memory than I originally thought since the LDR touch pads think they're activated at night and the device needed watchdogs on record and playback mode to powerdown if left unattended. But ultimately powerdown fit in memory and the new code is posted on site. It's amazing how programs always seems to take 254 bytes in a 08M!

Now it would be nice to have sounds other than just a beep, but I suspect interpreted basic is probably a bit too slow to pull this off. Any suggestions about creating interesting sounds with the picaxe?

 

[chipwich]

One other question for those familiar with the Picaxe internals:

It seems like the timing is ever so slightly different between the first playback loop and those which follow (though I haven't checked this on a scope). Is there any sort of &quot;garbage collection&quot; or background processing which would lead to timing variations during program execution? Thanks.

 

[hippy]

No garbage collection and the only background activities would be if you've enabled PWMOUT which won't affect execution timing or SERVO which can, but should be consistent over a longer period and wouldn't just affect single loops.

Loop timings around processing operations are rarely repeatable, quite simply because it can take longer to process bigger numbers than smaller ones. Zero times 1 is ( should be ) quicker that $FFFF times $FFFF.

The only way to get accurate loop times is to synchronise to internal or external clock ticks, or by determining the amount of time needed to add per loop to make them more consistent. The later will usually only be approximate though.

 

[chipwich]

Is there a way to sync to the internal clock of the 08M to eliminate the error associated with software dependent timing loops?