stryd_one

OK obviously I thought that was funnier than you did ;D It really does :) Interference should not be a problem, but I'd probably put it on a PCB to be sure... There've been threads about termination lately too, that could be of interest.

*whack* PS this is not the 'post empty stuff to boost your postcount' thread ;)

:( Well I must admit, there is a lot of good info outside of midibox/ucapps for this... And trial and error is actually kinda good here because the results vary so widely and everyone has a different preference to how they'd work. A maxxed out s2000 is the same as a maxxed out 3200, except only with a 2x20 CLCD (instead of a GLCD on the 3200)... If you use a software editor over scsi, the screen becomes obsolete ;) Avoiding GAS huh? Yeh totally.... Although, the s2000 is surprisingly empty internally.... you could probably hack it up pretty easy into a smaller desktop case... hmmmmm

No, your question was formed well :) But, I don't know the datasheet for the PCA chip from memory... So I'd need to read it, to know how it works, to give you advice on how to use it with MIOS/MBHP. Think about it ;) Bill has covered it now, anyway :)

Wilbizzle ma nizzle ;D

I think you should google for the datasheet so I don't have to ;)

In youtube tags for easy viewing ;)

Lookin good man :) Ply is probably suitable for such a large device. Not all ply is the same though, so make sure you get nice stuff ;)

Damn, wilba... you spoiled the "believe everything you read" vibe in here and noone sent me $50 by western union! That's it, no good luck for any of you ;D

And that makes it more obvious ;)

a) Yes b) You don't need access to them anyway because they're internal to the ASM function c) If you did rewrite it in C (why) you don't have to use FSR2, you could use other vars d) I'd avoid FSR2 because it's used by the wrapper. I had a feeling it was saved but I can't find .. wait.. Re: RAM handling in ISRs e) All of the above

Thats perrty. As far as I can see, no errors.. I made a suggestion then realised it's already there :D

It cracked me up :D

Rare! Chances are, that's somewhat more than a GM card ;) Let me know if you don't want it heheh

Surface mail down under means it goes by sea... Takes months.... I only made that mistake once! ;D

Ack they just did it in .au too! :(

There were three, in my post that you quoted :) http://www.piclist.com/techref/microchip/math/power/index.htm Could be interesting to you... That particular page is floating-point-focussed, but it should demonstrate that there are various ways to do exponents. Of course, it needs to be *quick* to respond to a keypress (we don't want to increase latency) so I think that a table is the way to go - the table should be small because you've only got 127 entries. Then, you could combine the table with a fast and rough write to the table** with a calculation to adjust the black keys, and you're all set. Add a sysex implementation, and you will be able to upload stuff from a pd app (or whatever) as well, so you get the best of both worlds. Regarding the black keys... ... you said something about making it 90%. Of course there are lots of algorithms you could use, but this one is designed to show that you don't have to use a divide function just because you want to divide, and that you can sometimes work backwards to your goal ;) Y = X - (X >> 3) means Y = 87.5% of X Y = X - (X >> 4) means Y = 93.25% of X Where Y is the output velocity and X is the original sensed velocity. You could adjust this by adding or subtracting smaller fractions of the original such as X >> 5 (3.125%). This could be fast because you know you can safely use MULWF without overflow, but of course the more complex you make things, the slower it gets. Re-reading that doepfer manual it sounds like it's feeding that 7b value directly into a scaling algorithm like TK's, where the minimum is always 0 and the maximum is the value you set (100-127). We already know that's a good algorithm ;) In fact, now that I think about it... hahahha.... I just wrote this long post and realized much of it may be pointless ahahaha! ;D I really should engage my brain before I type. :-X You can convert the value as you write it into the table, before it is loaded and in use. That way, your algorithm can be as long and slow as you like, it just means that there will be a longer delay when you write a new custom velocity table or edit one - but it won't effect latency at all :D

I will give you a parts kit. Send $50 to me via western union. If you forward on this post, you will receive good luck for a year.

A) If eBay jumped off a cliff would you do it too? B) We don't care if someone sues eBay and they get shut down. C) BL. :-X D) I'm not a moderator at eBay ;D (just a joke, you guys know from my signature that I don't make rules, only enforce them) But I am serious about B)

Is this an unweighted board by any chance? I don't suppose they happen to mention HOW they apply that factor? ;)

Man that guy makes great projects.

I recently had a guy send me 10 soldering iron tips in a normal paper envelope. The post sorting machine choked on them, and they arrived bent, in a ball of sticky tape with a note from the post office.. Yup, bent. I'd love to see what the machine looks like :D

If by 'normal' you mean spst, that don't work ;) jidis: ucapps.de... midibox extensions... CV input example. Now it's coding time. Enjoy ;)

rutgerv, you forgot to charge for your time. As TK says, it's good at what it does... but ahh, yeh, not my style. and ahh...: I'll let that speak for itself ;)

Welcome to the big debate, gents. I suggest you buy a snack from the bar because you might be here for a while ;) There are LOTS of different implementations. But strictly speaking, the MMA says: This and durisian's trick are consistent with the tuning spec: But if you ignore the MMA... Well, you won't be the first, not by a long shot. If it's good for steinborg.... ;)