stryd_one

Wrong kind of FM But I guess if you were a total freak you could synthesise a data stream, in which case the correct answer to your question is: How many operators are you using? What waveform? It depends on the patch. I will revert to my old question: Why? Just build the damn thing already! Enough talk... Build one and try it! Or... buy my LCDs and I'll tell you all about how it sounds :D And if you're talking about digital data transmission then I don't think I need to draw those pix after all ;)

Ahh the all too rare MBFM. Good effort, especially from a "novice", because there's not so much documentation on the FM. Look forward to hearing it when you make some patches or songs :)

You and the rest of us!

Filed under 'interesting toys' :)

Yep!!

Colours also work. The marquee/move/scrolling tag can earn you a ban though. ;D

Yeh I'm pretty sure the opto is dead, but the PIC pin doesn't look so hot at the moment either :/ We'll know soon :)

Which means: This is interesting but I am personally way too busy right now :( Anyone? PS Zossen what is that board? Just out of curiosity...

Heheh, mine is a stack of paper about 3 ft high. Hard to get it to stick to the wall ;D I like your lab cimo - looks not uberexpensive but definitely functional

Sounds like the opto is screwey, but you skipped a few tests; typically, the ones we need to see. So I'll try again: Come back with ALL the results of ALL of the tests Why does that request invariably get ignored? Is it something about the way I asked?

search the wiki for the word detent ;) "Normal" around here is to remove the detents. SmashTV is not a "they"; he's a "him", and he's our friend, not Farnell ;)

Ooooh there's external filtering for the three frequency bands. Tasteful. Unfortunately the crossover frequencies are fixed :( Can you actually find the chips available as a stocked item?

2 bit. If you're not going to buy the recommended parts, then you should buy something with the same specs, and if you're unsure, you might be better to just get the recommended parts ;)

The problem here is not how fast the signals are generated, but how fast they are processed by the PIC....

They're all interconnected, so that's cool The core needs 5V to operate, but that must be regulated, and the regulators on your core module require a few extra volts to operate. Feed it 9V and you should be sorted.

octave &= 0x7F; That'll keep it 7bit :)

I'd go for 9V, just to be sure. We love when people do their own research, it makes it so easy to help :) There's a similar schematic on the wiki here, and someone tried it unsuccessfully recently. Don't let that put you off, but I should mention it. It was never determined why it didn't work. Correct. That is a maximum rating, it will only put out what the core draws in, so that's just extra headroom. I dunno... that's a 24V swing, so I think you'll get a lower maximum amperage per pole, but I think bipolar ratings are done for the full swing from pole to pole anyway. In Parallel, but beware of ground loops. Seppo will probably come and fill in the blanks in my post soon :)

Heh, I think I was warning you that this might happen, when we first chatted about this :) Rather than mod MIOS, it's probably better to adjust the timer in your app... It's strange that it didn't work though. In all honesty, I never use AINs (I don't even bother soldering the jumper on most of the time) so I might not be the best person for advice. Alternately, you could use the touchsensor pin (J14/PORDT:RD4) and a DIN... That's what I'd do. Or maybe just a bit of good old fashioned optimising might get the code fast enough again? If you've got an oscilloscope, this is where it can come in really handy. (This is one of my favourite tricks I learned from TK) Just set a pin high at the beginning of a function, and set it low at the end, and connect the scope to the pin, and you can tell exactly how long your function runs. Also, you can take a look in the _output\ directory and see the ASM that your app creates. You might want to sit down for that, it's rarely pretty ;) It's a pretty straightforward bunch of code in C, but it fleshes out pretty well in the output. There are two things that jump out at me pinval = MIOS_AIN_Pin7bitGet(pin); you can grab the MSB from MIOS_PARAMETER2 and shift it right like pinval = MIOS_PARAMETER2 >> 1; pinval &= 0x7f //mask out the top bit. This may be obsolete, check the output. Saves you resampling the ain. That'll speed up the AIN_Notifychange i think. The other thing is the BIG tick function: S_main__Tick code 0x00330e program 0x000204 S_main__AIN_NotifyChange code 0x00361e program 0x0000ac Notifychange is big enough, but the tick function worked out kinda large, considering the C is not that big really. You might benefit from a trick I've been employing lately to help with some array accesses. You've done a lot of operations on your global variables, and it leaves a banksel command in there every time. Bit of a bummer seeing as they're all in the same bank. Preferably, the optmiser will sort that out, but it's missed quite a few. Access RAM would be perfect, but you have to be careful about how you use it, because it's very limited... but you can leave it to the compiler anyway, by using temporary registers for your working. Instead of doing like this: void Tick(void) __wparam { int direction = 0; if (dostuff){ .... SNIP! .......... } dostuff=0; } if (oldsensor1 != sensor1 || oldsensor2 != sensor2){ // if edge transition if (oldsensor1 == 0 && oldsensor2 == 0){ if (sensor1==1 && sensor2 == 0){direction=1;} // 00->10 RIGHT else if (sensor1==0 && sensor2 == 1){ direction=-1;} // 00->01 LEFT else if (sensor1==1 && sensor2 == 1){ direction=0;} // 00->11 ERROR } ...... ETC Try this: void Tick(void) __wparam { unsigned char tmpsensor1,tmpsensor2,tmpoldsensor1,tmpoldsensor2; int tmpsensordirection, tmpoldsensordirection; tmpsensor1=sensor1; tmpsensor2=sensor2; tmpoldsensor1=oldsensor1; tmpoldsensor2=oldsensor2; tmpsensordirection=sensordirection; tmpoldsensordirection=oldsensordirection; \\ I know that looks ugly but sometimes SDCC gets funny about initialising them when you declare them (Like this next line). Go figure. int direction = 0; if (dostuff){ .... SNIP! .......... } dostuff=0; } if (tmpoldsensor1 != tmpsensor1 || tmpoldsensor2 != tmpsensor2){ // if edge transition if (tmpoldsensor1 == 0 && tmpoldsensor2 == 0){ if (tmpsensor1==1 && tmpsensor2 == 0){tmpdirection=1;} // 00->10 RIGHT else if (tmpsensor1==0 && tmpsensor2 == 1){ tmpdirection=-1;} // 00->01 LEFT ...... ETC \\Then set your global variables on the way out sensor1=tmpsensor1; sensor2=tmpsensor2; oldsensor1=tmpoldsensor1; oldsensor2=tmpoldsensor2; sensordirection=tmpsensordirection; oldsensordirection=tmpoldsensordirection; Or something like that. I haven't analysed the code much and this was written in the browser so don't trust anything you see ;) But it may be worth a try. If there's some way you can think of, to reduce the amount of comparisons and IF statements, then I'd go for it for sure. Random thought: If you want signed chars, declare them that way - SDCC has been known to change it's default from signed to unsigned and back ;)

Oh you sent me one? It's not here yet, but thanks! ;D

AKA: A bunch of noise and crud and reboots. Did you do the midi troubleshooting guide? It's on ucapps.de, scroll down to the bottom of the menu on the left... Come back with ALL the results of ALL of the tests and we'll have a good chance of fixing this :) (it sounds like maybe you did this already but it's not really clear) My guess: dodgy midi interface or dodgy optocoupler.

It really depends. Most often, you don't need to tag... but sometimes it's a good idea, where you find a post (yours or someone else's) that has good information (solutions/documentation) that you feel could be linked to other, similar posts - and those posts should have the same tag(s) in them, too. But, if you "get it wrong", then we'll fix em up eventually anyway :) Don't worry too much about it!

I *think* I can trade 8 of my white on black for 8 of your grey on black :)

= FR777 ;)

My guess is that they are different because the precompiled version was made with an older version of SDCC. I compiled it on my PC for you and the checksums are the same... Looks good.

It is compiling correctly, and the instructions for changing to 256 measures are above, written in neither french nor english, but C and ASM.... Go for it! ;)