stryd_one

Ouch. Get a pre-nup, kids.

I fear dj3nk is correct. BTW, doesn't the rectifier have a small voltage drop also? Not as much as the vreg, but still a volt or so?

LMAO! See, another grammatically correct utilisation of the word... But heck it still sounds weird!

That suggests that the problem may be with your core... Have you tried different core modules? Does the LCD function correctly? Did you use the same IC's this time? Have you tried changing the TL074's around?

Ahem! We obey copyright law around here!

Ahem, I was trying to avoid blaming anyone's playing style ;)

[me=stryd_one]puts them next to his waldorf....[/me] Nearly? Exactly! ;)

3-0... mmmm, bubblesome. Don't get gear envy dudes: It ain't what you rock, it's the way you rock it / So drop the top sh*t / till bloodshots pop out of their sockets / :o - Some unknown MC ;)

Totally. every time you do an 'if', it processes the input accordingly. #define SOFTPOT_MIN 13 if (MIOS_AIN_Pin7bitGet(pin) <= SOFTPOT_MIN) { ... } else { ... } Just a thought.....Keeps it portable.

Cool toy :) Uncool price. Ouch. And ahh... I wonder about the 'professional' tag a bit hehehehhe

eh? eh? *click click* LOL

Edit: I can't help but wonder though guys... Are you sure it's not just that the black keys are shorter = leverage difference?

Hi QBAS :) I think it would be a shame to lose the standalone midi capability of the keyboard and rely upon a PC. Some ideas I had: Have an algorithm calculate the velocity rather than a table. As we know, doing arithmetic on PIC is not superfast ;) , but if we have a good algorithm then it is quite easy to hardcode... As an illustration of what I mean; if you wanted to do a division... you could have a 'divide 16bit X, by 16bit Y' algorithm, but if you know that Y will always be 160, then you can make a special algorithm that only does 'divide 16bit X, by 160'. This would be much faster. There are plenty of good examples of this theory at the piclist site ;) Have the ability to upload velocity curves via sysex, which would allow a great deal of flexibility, and also is inclusive of the pd environment (you could output the raw data in a sysex stream as you said, and use that input to create the curve in PD... But it also allows it to work with anything that'll send sysex. Have a feature where you can set the output velocity for a given key-movement-speed... So like, you would go into the menu, and select velocity=10, and hit the key as hard as you think it should be for velocity=10...same for 20, 30, 40, etc... then interpolate the values (heading into the algorithm idea again) to create a curve... or link an incoming CC to the same, so you roll the modwheel up, while repeatedly pressing a key harder and harder each time. Each time you hit the key, you sample the speed of that, and the CC value, interpolate, and booyah, you got a curve. Combine the above. For EG, you could upload/create a single velocity curve for all keys, and then process the keys with an algorithm that modifies the black keys output velocity in a desirable manner. I dunno, I could spew ideas all day... My point is, I think it would be better to solve the non-realtime velocity curve setting problem, than to avoid it and move to pd. It's such an excellent app man, one of the most ambitious IMO, don't give up on it yet :D

Yeh, sweet. Our new limit looks like... a whole bank :) LOL typedef union { struct { unsigned ALL:8; }; struct { unsigned test1:1; unsigned test2:1; unsigned test3:1; unsigned test4:1; unsigned test5:1; unsigned test6:1; unsigned test7:1; unsigned test8:1; unsigned test9:1; unsigned test10:1; unsigned test11:1; unsigned test12:1; unsigned test13:1; unsigned test14:1; unsigned test15:1; unsigned test16:1; unsigned test17:1; unsigned test18:1; unsigned test19:1; unsigned test20:1; unsigned test21:1; unsigned test22:1; unsigned test23:1; unsigned test24:1; unsigned test25:1; unsigned test26:1; unsigned test27:1; unsigned test28:1; unsigned test29:1; unsigned test30:1; unsigned test31:1; unsigned test32:1; unsigned test33:1; unsigned test34:1; unsigned test35:1; unsigned test36:1; unsigned test37:1; unsigned test38:1; unsigned test39:1; unsigned test40:1; unsigned test41:1; unsigned test42:1; unsigned test43:1; unsigned test44:1; unsigned test45:1; unsigned test46:1; unsigned test47:1; unsigned test48:1; unsigned test49:1; unsigned test50:1; unsigned test51:1; unsigned test52:1; unsigned test53:1; unsigned test54:1; unsigned test55:1; unsigned test56:1; unsigned test57:1; unsigned test58:1; unsigned test59:1; unsigned test60:1; unsigned test61:1; unsigned test62:1; unsigned test63:1; unsigned test64:1; unsigned test65:1; unsigned test66:1; unsigned test67:1; unsigned test68:1; unsigned test69:1; }; } testbits_t; testbits_t mybitfield; void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { if (evnt0 == 0x92) { mybitfield.test6 = 0; mybitfield.test15 = 0; mybitfield.test55 = 0; }; if (evnt0 == 0x93) { mybitfield.test6 = 1; mybitfield.test15 = 1; mybitfield.test55 = 1; }; if (evnt0 == 0x91) { if (mybitfield.test55) { MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(0x55); MIOS_MIDI_TxBufferPut(0x7f); }; if (mybitfield.test15) { MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(0x15); MIOS_MIDI_TxBufferPut(0x7f); }; if (mybitfield.test6) { MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(0x06); MIOS_MIDI_TxBufferPut(0x7f); }; }; } It's ugly, but it works!: udata_main_0 udata 0x000080 data 0x000009 _mybitfield 0x000080 data extern _output\main.asm ; Starting pCode block S_main__MPROC_NotifyReceivedEvnt code _MPROC_NotifyReceivedEvnt: ; .line 143; main.c void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVWF r0x00 ; .line 147; main.c if (evnt0 == 0x92) { MOVF r0x00, W XORLW 0x92 BNZ _00126_DS_ _00146_DS_: BANKSEL _mybitfield ; .line 150; main.c mybitfield.test6 = 0; BCF _mybitfield, 5, B ; removed redundant BANKSEL ; .line 151; main.c mybitfield.test15 = 0; BCF (_mybitfield + 1), 6, B ; removed redundant BANKSEL ; .line 152; main.c mybitfield.test55 = 0; BCF (_mybitfield + 6), 6, B _00126_DS_: ; .line 157; main.c if (evnt0 == 0x93) { MOVF r0x00, W XORLW 0x93 BNZ _00128_DS_ _00148_DS_: BANKSEL _mybitfield ; .line 160; main.c mybitfield.test6 = 1; BSF _mybitfield, 5, B ; removed redundant BANKSEL ; .line 161; main.c mybitfield.test15 = 1; BSF (_mybitfield + 1), 6, B ; removed redundant BANKSEL ; .line 162; main.c mybitfield.test55 = 1; BSF (_mybitfield + 6), 6, B _00128_DS_: ; .line 168; main.c if (evnt0 == 0x91) { MOVF r0x00, W XORLW 0x91 BNZ _00137_DS_ _00150_DS_: BANKSEL (_mybitfield + 6) ; .line 172; main.c if (mybitfield.test55) { BTFSS (_mybitfield + 6), 6, B BRA _00130_DS_ ; .line 173; main.c MIOS_MIDI_TxBufferPut(0x90); MOVLW 0x90 CALL _MIOS_MIDI_TxBufferPut ; .line 174; main.c MIOS_MIDI_TxBufferPut(0x55); MOVLW 0x55 CALL _MIOS_MIDI_TxBufferPut ; .line 175; main.c MIOS_MIDI_TxBufferPut(0x7f); MOVLW 0x7f CALL _MIOS_MIDI_TxBufferPut _00130_DS_: BANKSEL (_mybitfield + 1) ; .line 178; main.c if (mybitfield.test15) { BTFSS (_mybitfield + 1), 6, B BRA _00132_DS_ ; .line 179; main.c MIOS_MIDI_TxBufferPut(0x90); MOVLW 0x90 CALL _MIOS_MIDI_TxBufferPut ; .line 180; main.c MIOS_MIDI_TxBufferPut(0x15); MOVLW 0x15 CALL _MIOS_MIDI_TxBufferPut ; .line 181; main.c MIOS_MIDI_TxBufferPut(0x7f); MOVLW 0x7f CALL _MIOS_MIDI_TxBufferPut _00132_DS_: BANKSEL _mybitfield ; .line 184; main.c if (mybitfield.test6) { BTFSS _mybitfield, 5, B BRA _00137_DS_ ; .line 185; main.c MIOS_MIDI_TxBufferPut(0x90); MOVLW 0x90 CALL _MIOS_MIDI_TxBufferPut ; .line 186; main.c MIOS_MIDI_TxBufferPut(0x06); MOVLW 0x06 CALL _MIOS_MIDI_TxBufferPut ; .line 187; main.c MIOS_MIDI_TxBufferPut(0x7f); MOVLW 0x7f CALL _MIOS_MIDI_TxBufferPut _00137_DS_: MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN So why a whole bank? cause it does the arithmetic pre-assembly, and optimises out any banksels. I don't see why it couldn't access like (_mybitfield + 20) hahah. Something of note: typedef union { struct { unsigned ALL:8; }; struct { unsigned test1:1; unsigned test2:1; unsigned test3:1; unsigned test4:1; ......... This works. If you make it ALL:69, it says that each field has a 16 bit max. So ALL:16 is good, ALL:17 bad. But the rest is happy :) Edit: I chose 69 because I wanted to go higher than 64, and that's how it pasted out. I am not a pervert. Well, I am. But that's not why I chose 69. :D

Wilba: nope sorry ;D Audiocommander: Thanks man! nILS: Thanks ! All: this is happening. nILS is a bit of a web code guru so he's getting things started for us! Yay! HTMnILS! (or is it XMnILS?)

Efficient for the coder (you), but not for the chip ;) ASM is generally a great deal lighter. Nah you can use C in ISRs. of course, you need to make those as fast as possible, so ASM is preferable... but you can always write the code in C, and once the concept is proven, inline some ASM (__ASM etc) in it's place. Yes, but it would probably be better to use the original ASM in an include file, as with the C scan matrix examples by TK. Much easier to rewrite that way, too :) Well short answer is; yes. Medium answer is; Yes, but you can wrap C around it/use ASM within a C app, inline (__ASM) or by #include Long answer; In a perfect world, your C compiler would be so perfect that it would optimise the output ASM so well that there would be no difference. In the real world, the ASM that the compiler generates is not too hot. For it to be 5-15 times slower than hand-written ASM is not uncommon. However, if you write the C in a certain way, you can make the compiler output some pretty darned clean ASM. In my experience (which doesn't mean it's the rule) that means knowing the compiler's habits, which is a matter of trial and error. A great example is in array accesses. Structure your data in the right way, and manipulate it in the right way, and sometimes optimising with ASM is hardly necessary. Go at it hap-hazard, and expect slow big crappy ASM to be generated. It might not even work. That said, coding in C is way easier and way faster. Generally I have found (and been advised by others - I should have taken their advice in the first place) that the best way is the middle-road. Write your code in C because it's faster to prototype it. If you find areas that need optimisation, either rewrite the C more cleanly, or go ASM. In your case, the optimised ASM is already there, so I'd just #include it and work on making the necessary variables and functions exposed to C, and then write my mods in C. If your mods turn out to be too heavy, then you can always optimise them to ASM too, and you'll basically have a C app that just includes a bunch of ASM, which is about as good as pure ASM. 'Course, if you're an ASM guru and just learning C... I'd just go straight to ASM.

I totally did miss that! I read the "64ms" and thought "where'd he get *that* from? TK would never let it get that slow!", and thought it must have been a mis-conversion ;D Thx Tilt!

Heya guys, I had an idea, I'd like to know that you think... I refer to the Function Reference a LOT. Maybe (surely) it's due to my shoddy memory (my brain, not my PC) but perhaps you do too. I thought about doing a quick-reference with minimal information so that it would be small enough to print on one page, but I abandoned that idea because sometimes I want that extra info... Also, I thought about merging the ASM and C references, because you often need both when mixing ASM and C. But I didn't want to make things over-complex. In the end what I was thinking, was that it would be good to have a page with 'fold-out' tables with the information, for both C and ASM, so that you only select what you want to see... Either by clicking something to show a certain type of information for all functions in the page (IE, show all the descriptions, and/or show all of the examples) or by clicking something on a specific function (IE, show the ASM input variables for the MIOS_MIDI_TxBufferPut function) I want to keep any coding client-side (so it works when stored locally) but that should be about it. Now, making all the necessary groups up, won't be a walk in the park - it's not hard but it's time consuming... So basically I've decided that it is only worth my time to do this, if you guys can make some use of it too... So, should I do it? Would you use it? Or are you happy with what you've got now? I'm also interested in other ideas that might make it a bit easier to use, or any criticisms of the idea... So feel free to weigh in. ... Any thoughts?

BTW that is still cracking me up :) I have a great flick here called 'Bushisms', it's a compilation of ohmage-level foulups. Worth a watch! Totally dude. Using ohmage to me is kinda like saying "One thousand mega bytes". It makes sense and all, but in the real world, we say "a gig". Using the former makes us all silently think "who's the n00b?" ;D Yeh I can relate to that strangeness too... Cause, well 'voltage' just sounds right. And 'amperage' sometimes. But I don't think I've ever used 'ohmage'. It sounds like a french cheese, or something you pay to the Gods. Seriously the word "Ohmage" just sounds funny to me. What's more, it seems I'm not alone on this. A search of the forum finds several hits for the word amperage, but (aside from yourself taking the mick) only one hit for ohmage: Note the grammatically correct use of the term hahah... Also google: Results 1 - 100 of about 78,200,000 for voltage Results 1 - 100 of about 1,760,000 for amperage Results 1 - 100 of about 25,100 for ohmage That's a BIG difference! LOL! Yeh, my knowledge on that subject is this: I know there's a difference... And I have no idea what the WHACK it is :) OMG I almost got ontopic at the end there! :-X

Feed the watchdog. He's always hungry. ;) Seriously though, if you have to feed the watchdog, that must be a verrrry long LED function you have in the init. I'd recommend pasting the code as nilly said... if you're feeling shy, feel free to drop by the chat, and your code won't be out there for all to see... But of course, make sure you drop by here and post the solution afterwards, for future reference :)

Ahhh midibox, the home of cool toys, crazy dudes, and broken English. We love it.

I'm not sure about faders but I do know that alps is a good brand... Finding the perfect mix of price and quality is a tricky thing which can only really be solved by looking around a lot ... As for the connections, you can find the diagrams/schematics on the ucapps.de site :)

I haven't yet, but I suspect they will be almost unlimited... The output ASM is pretty simple, it just uses for EG: BTFSC (_bitfield) ,6 for bit 6 or BTFSC (_bitfield +1) ,4 for bit 12 That's from memory... I'll test it with some really silly big bitfields tomorrow night, and paste the code.

My post has been updated ;) Edit: thanks for the effort babnILSfish So kartoshka, how do you wire it then, if not R = R ?

Well, a lot of us use those threads as reference points, especially a good newbie doing a search to find out info. Several of them are linked from wiki articles too... If I put this info in one thread, they may miss it, so it's in the threads where it was said that the limit was 8 bit, as an update to the existing doco. Sorry for the annoyance, but it's important, for future reference :)