stryd_one

I had that same idea a while back... Where are you gonna get the lettering to use as a stencil for labels? There's no way you could cut lettering that small practically... What kind of paint are you going to use? Most spraypaint is kinda translucent, so it won't block the backlighting. Of course you can do a few layers of paint but then you need very thick stencil material.... I'd be interested to see how you're planning on getting around this stuff! :)

17 hours! Fixed! :D

I have an offer on two, and drbunsen is local to me... You want in buddy?

Thanks Seppo :)

Sounds like maybe you've got DOUT problems... I hate to say it but that birdsnest of cables may have something te do with it. Neat cabling isn't just cosmetic, it helps a clean signal. Otherwise it's lookin good :) Did you make that case yourself?

Ouch!! Well fortunately my lab is about a metre from my kitchen, and I iced it immediately - so it's fading already :) But I have a floating point thumb, with a nice little decimal point ;) OMG yeh! I made the mistake of forgetting about it and used my cigarette lighter once. OW. Do not do that.

This concept kinda got named MBFX back in the day but obviously it could be oscs etc, which aren't really FX at all. Not sure what poly- / multi is about? Who's working on that DAC? I thought seppo was using the TLV?

Which there aren't. Ah well!

I wanna outright disrespect that damn 255b limit, I'm gonna smack it in the face >:( hehehehe I could maybe have a separate array for each track but it's gonna make code large and difficult I think... I'm also stuck figuring out precedence of the note off buffers, as in, which one of the buffers should be emptied early, if all the buffers are full. Do I do first in, last in, shortest time remaining (could be hard to keep track of)...Any thoughts? :'( woe is me.

Fortunately not :) I *think* you could use pointer to the array?

Huh? What's that?

http://sourceforge.net/tracker/index.php?func=detail&aid=1692042&group_id=599&atid=100599 Worst. Bug Report. Ever. ;)

NICE!!

WTF!?!? I have noticed that SDCC is real picky about where you declare stuff.... Maybe it won't let you declare once the funciton has begun? Hmmm... Hey, whatever works! ;) Glad it's behaving ;D

Heheheh yet true. I am cursed with a shocking power of recall so I'm trying to make a habit of commenting all the way. It probably won't help ;) Nested structs are all good :) In fact it's handling nested arrays of structs of nested arrays of structs nicely :) It's tricky though.... 2.5.0 doesn't handle it sometimes, and 2.6.0 has a bug The latest nightlies have given me this: "input buffer overflow, can't enlarge buffer because scanner uses REJECT" I'd recommend SDCC 2.6.0 build r4359, if I could find it... I'm kicking myself for not keeping a copy :( Maybe I should report the bug? I don't think I could give them much more detail than that though...

Thanks for checking it man :) I don't seem to be getting the login issue anymore, and the html is definitely right, the target for both links is _blank. I already tried everything but a reboot, must be about time.... I *heart* windoze

Thanks for the tips man. actually that's what I thought, but it's almost all done using POSTDECx ... apparrently sdcc figured that much out :D Actually I have to say that so far I am rather impressed with SDCC's job. The ASM coming out of it seems really not too bad at all. I have noticed that with code where the results should be the same, the way you lay out the C code, can have quite a significant bearing on the output ASM... But once you've seen it done a few times it's not hard to get used to. It seems to like it if your code is broken down into constituents, kinda like writing ASM with ease, rather than writing in a way that takes full advantage of the relaxed methods that come with the higher level language that it is... C is interesting. ;D I have a feeling that this is because I was forcing things where SDCC is supposed to automate them. I think I used too firm a hand :-\ Once I just made room for it and stepped off, it seems to be OK. But I'm still uneasy.... Once I have the note offs working I'm gonna hardcode useful values into every step and clock, record the output and see if I get zeros... Which will be obvious because they'll cause the track to lose it and start spewing midi and crash java ;D This is gonna take awhile :( At least it's a good excuse to do a demo ;) Edit: There's this little voice in my head trying to remind me that one of the memory access methods, banked or indirect, is faster than the other.. any hints guys?

This is a really interesting concept man. Sounds like musical lego made from homemade bricks ;D I think it oughta be in the User Projects forum if you feel like documenting it on the wiki too :)

Wow when I screw up I reallllly screw up! Sorry man.. WTF is going on here... Problem is that I rarely deal with signed values at the binary level, I have to do some homework here... I have just read the datasheet and the only mention of signed arithmetic is a two's complement system. wikipedia says: So if I can believe that, this should work: USER_ENC_NotifyChange extern _ENC_NotifyChange ;; inverting the incrementer: ;; incrementer = (NOT incrementer) + 1 ;; aka 2s complement comf MIOS_PARAMETER2, W addlw 1 movwf MIOS_PARAMETER2 ;; continue... lfsr FSR0, STACK_HEAD ; initialize stack lfsr FSR2, STACK_HEAD movff MIOS_PARAMETER2, POSTDEC0 ;; put encoder number back in WREG movf MIOS_PARAMETER1, W goto _ENC_NotifyChange I still think that this change should be done within the application, in C, in which case we could try the same trick... ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an encoder has been moved // incrementer is positive when encoder has been turned clockwise, else // it is negative ///////////////////////////////////////////////////////////////////////////// void ENC_NotifyChange(unsigned char encoder, char incrementer) __wparam { incrementer = (!incrementer)+1 //invert encoder direction by 2's complement unsigned int value; // encoder 0 is used to control the BPM if( encoder == 0 ) { value = (unsigned int)MCLOCK_BPMGet() - 48; if( MIOS_HLP_16bitAddSaturate(incrementer, &value, 255 - 48) ) { MCLOCK_BPMSet((unsigned char)value + 48); app_flags.DISPLAY_UPDATE_REQ = 1; } } }

Hey guys has anyone else been prompted to login over and over today or is it just me? Also while I'm at it.. TwinX, the two buttons up the top, the wiki one opens in a new window, but the ucapps one now opens in this frame... Would you mind making the ucapps one open in a new window again? TIA bro.

Poor TK is gonna come back from his holiday to find 100 bugs you spotted :( hehehe If you are in a big rush to get any of this stuff fixed let me know, but I haven't had a chance to look over much of v3 so it might be that it would be faster to wait for TK anyway hehehe

LOL ;D

Just wrapping up the note off handling now :) <Ramblings of a tormented developer> Wasted a day discovering an interesting behaviour, maybe someone could shed some light on this for me... (Developers take note: this could help you one day) I've got this really big struct, for the clocking system, so I have to merge two banks in the linker. I end up merging them all into one. 1 // DATABANK NAME=gpr0 START=0x080 END=0x0FF // DATABANK NAME=gpr1 START=0x100 END=0x1FF // DATABANK NAME=gpr2 START=0x200 END=0x2FF DATABANK NAME=gpr START=0x080 END=0x2FF I use the udata pragma mark to force the struct to be stored in that bank. 2 #pragma udata gpr mclk extern volatile mclk_t mclk; I then make another big struct, for the tracks and steps. I write a function that uses that struct. My function is not working. Grrrr. I bugshoot for ages (like 6 hours) until I discover that the first step of the first track is ALWAYS 0! I try a few things, and by accident find that the declaration of the struct seems to have an effect on the data stored in it. namely I changed from this: typedef struct _track { unsigned char frststep; //First Step 5bit (Number of the step to play first) unsigned char laststep; //Last Step 5bit (Number of the step to play last) To this: (With the two top lines swapped) typedef struct _track { unsigned char laststep; //Last Step 5bit (Number of the step to play last) unsigned char frststep; //First Step 5bit (Number of the step to play first) And now the frststep value is correct but the laststep value is always 0. WTF, right? So I start thinking maybe something has gone awry in the allocation of the RAM, so I check the map file and.... gpr udata 0x000080 data 0x00007f udata_main_0 udata 0x0000ff data 0x000102 The gpr is the clock struct I forced in there. The udata_main_0 is the track struct, which has been allocated it's ram by the compiler. I then noticed... The compiler had simply gone for the next available byte in the one and only bank availabe -my track struct was beginning at 0x0FF ....right at the END of one of the 256b blocks. No matter what variable I put in that first byte, it would always be zero. I currently have changed it to this: DATABANK NAME=gpr0 START=0x080 END=0x1FF DATABANK NAME=gpr12 START=0x200 END=0x2FF With no sections, and no pragma markers in the code. It maps out like this: udata_main_1 udata 0x000080 data 0x000102 udata_mulint_0 udata 0x000182 data 0x000002 udata_mulint_1 udata 0x000184 data 0x000002 udata_mulint_2 udata 0x000186 data 0x000002 udata_vxclocks_0 udata 0x000188 data 0x000001 udata_vxclocks_1 udata 0x000189 data 0x000001 udata_vxclocks_2 udata 0x00018a data 0x000001 udata_vxclocks_3 udata 0x00018b data 0x000001 udata_vxclocks_4 udata 0x00018c data 0x000001 udata_vxclocks_5 udata 0x00018d data 0x000001 udata_vxclocks_6 udata 0x00018e data 0x000001 udata_vxclocks_7 udata 0x00018f data 0x000001 udata_vxclocks_8 udata 0x000190 data 0x000001 udata_main_0 udata 0x000200 data 0x00007f udata_main_0 is the clock struct, and udata_main_1 is the tracks. notice that small variables used throughout the app now fill the spaces between the banks. This got rid of my 'always zero' variable right at the top of the first track, so that I could continue coding, but I do fear that the 256b boundares between banks can not be crossed successfully, and that one I enable all the tracks and clocks, the annoying feature might rear it's head again... I hope someone can make sense of all that for me!! You can imagine that it was not an easy one to track down, especially when you're like me and more inclined to blame your newbie-ass C code than linker issues. If I could know enough to avoid it in the future that would be really reassuring! Notes: 1) Mistake #1 2) Mistake #2 </justshootmenowmun,justeasy>

NVIS (Quick, change the subject hehehe)

Hhehehe I think it's interesting that we've taken a completely different approach - you built hardware first, then software - I'm the other way around :) What kind of format are the songs? Is it linear or step based or..??