audiocommander

Hi Thorsten, thank you very much for that super-fast answer! now my app is back @ 5 kB and there's plenty of space left for many, many knobs & sensors ;D ...and I've also learned how it's possible to mix C and ASM code! 8) Thanks again, Cheers Michael

I have a (hopefully not too silly :-[ ) question: I am using some sensors that don't deliver exact 0 - 5V as AIN-Value. For example: a resulting MIDI-value from a sensor/softPot would be typically ranging from ~10 to ~80 instead from 0 to 127. Now I want to implement this formula, that "expands" this value to the maximum range of 0 to 127: unsigned char min = 10; unsigned char max = 80; unsigned char sevenBitValue = ((sevenBitValue - min) * 127.0 / (max - min)); Here comes the problem: If I am using multiplication and division, I am forced to include these sdcc-libs, which increase the codesize from 3 kB to > 10 kB: #include "sdcc/include/float.h" #include "sdcc/lib/_fsmul.c" #include "sdcc/lib/_mullong.c" #include "sdcc/lib/_fsdiv.c" #include "sdcc/lib/_sint2fs.c" #include "sdcc/lib/_fs2uchar.c" #include "sdcc/lib/_fs2ulong.c" #include "sdcc/lib/_slong2fs.c" #include "sdcc/lib/_ulong2fs.c" Is there any possibility to avoid multiplications and / or divisions in this case? Can this be calculated by bit-operators? ??? Thanks for any hint, Michael btw: unfortunately I get a strange linker error if I divide through 127 (integer) instead of 127.0 (float): :o gplink -s m5.lkr -m -o m5.hex _output/mios_wrapper.o _output/pic18f452.o _output/main.o error: missing definition for symbol "__gptrget1", required by "_output/main.o"

Hi goule, thanks for your answer :) I use the sensors for triggering NOTE_ONs. For Example when playing "Pad-Sounds", I use a technique of picking or gently weeping, for "Lead-Sounds" I simply hold my hand above the beam. The distance sensors have the ugly behavior of sending some random data in the low areas (mostly 0, 1 and 2; but every 50th message is a random 15 or sth like that)... While this behavior is not disturbing for Lead-Sounds it is very bad for "picked" Pad-Sounds, because they won't stay (which is exactly what I want to achieve: 1 weep = 1 note or a chord that stays as long as I weep again). Therefore I want to filter out all signals between 0 and (say) 20. Now this is what the gate does (to my understanding) at the beginning, the gateMode is ON (1) a signal will be processed –> the gate is set to OFF (0) and the counter is set to Zero (0) now @ the timer => if the GateCounter (is currently 0) is higher than the timeout (2000) the gate will be enabled again. this is NOT the case. That means, the gateMode remains OFF (0) => so ( @ AIN again ) GATE_MODE[pin] != ON and that means the next signals will be processed until the timeout occurs and the gate is enabled again, whether or not the signal is below the threshold. humm... I'm going to think about it... :-\ But meanwhile here is my code for the pedal: in main.h #define BUTTON_AIN_PEDAL 5 unsigned char ainUsePedal[8] = {0,1,0,0,0,0,0,0}; and in main.h void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { switch(pin) { case BUTTON_AIN_PEDAL: if(pin_value == 1) { // button has been released for(i=0; i<8; i++) { if(ainUsePedal[i]) { // send panic MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xB0 + i); MIOS_MIDI_TxBufferPut(0x7B);   // CC 123: ALL NOTES OFF MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_EndStream(); } } } break; default: // nothing special... break; } } void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { // if usePedal check pedal state if(ainUsePedal[pin]) { if(MIOS_DIN_PinGet(BUTTON_AIN_PEDAL)) { // pedal is +5V => is NOT pressed return; } } } so, the AIN signal will never be processed if the BUTTON_AIN_PEDAL is not pressed (@ pin 5 in my example). Whenever the pedal will be released, an ALL_NOTES_OFF (PANIC) message on the appropriate channel is sent additionally 8) still... pics are coming later... maybe also some codesnippets for expanding and smoothing signals... (if I'll ever find out why my program is behaving so strangely...)  ;)

hey, this is looking very cool 8) I have mine in a marauded IKEA®-clock with a bending "gooseneck" (is that the right word?) – nevertheless I'll post some pics later, too! Right now I am trying to improve your script with a min/max value; I think esp. the min-value is quite important to filter out too low signals coming from nowhere, but the problem is, that I don't know why the comparison between the sevenBitValue ( "MIOS_AIN_Pin7bitGet(pin)" ) won't compare to an unsigned char (eg 20) ?? It is getting even more complicated, because it worked already, then I changed something and now it stopped working ??? Does anyone know what I am doing wrong here? unsigned char sevenBitValue; unsigned char gateMin[8] = {20,20,0,0,0,0,0,0}; void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { // ... some other code here... // get 7-bit value sevenBitValue = MIOS_AIN_Pin7bitGet(pin); // this one is not recognized ?? if(sevenBitValue <= gateMin[pin]) { return; }     // these ones don't work either: // if(sevenBitValue < 20) { sevenBitValue = 0; } // if(sevenBitValue < 0x14) { sevenBitValue = 0x0; } } I'm really stuck ??? What is wrong with these values? Any hint is appreciated! btw: I also added a pedal switch, so that the distance sensor can only send signals if the pedal is pressed – and it sends an ALL_NOTES_OFF signal when released (good for playing sounds 8) I can post the code if anone is interested...

I like the 80 cm best, it has enough "space inbetween" to fine-control something... Since I stumbled upon MidiBox, I used Miditron (http://www.eroktronix.com/) it is quite affordable for its capabilities. The distance sensors work very well with miditron... but I think the strength of MidiBox (the ability to control every bit in the machine) is also its curse... but maybe there's an electronician-pro reading around here and gives us some hints to improve sensor-readings without coding? Nevertheless, your gate is improving things very well... I'm just struggeling a bit with the timer-settings; sometimes my MidiBox is restarting, if I set the timer-init value above 9ms ( MIOS_TIMER_Init(90000 & 0xFF, 90000 >> 8); // 9 ms ) ... ist that right? humm... Regards, Michael

hum... the latest beta (5_1) starts, but the windows are very buggy (there's some issue with the window refreshing, sometimes they dissappear :( ...and I can't say it's sending anything (tested the LCD debug section, but apparently nothing happend... :-\ ...forgot to mention: I'm running Tiger (10.4.3) on a Power PC with Java 1.4.2_09

thanks for that :) I've always a bunch of exotic sensors on my midi-boxes and while experimenting with MIOS I was very disappointed at the beginning, because there were very unstable signals. Then I used to reduce the deadband (knowing this wasn't the best solution), but this gate is working quite beautiful... and came at the right time, before I started to write my own... ;D btw: I've also distance sensors from SHARP, each one ~25 EUR, but I found the two longer-ranged ones more interesting ;) GP2D120 has a range of > 25 cm (datasheet says > 30 cm) GP2D12/GP2D15 has a range of > 60 cm (datasheet says > 80 cm) GP2Y0A02YK has a range of nearly 100 cm (datasheet says > 150 cm)

Hi Thorsten, The *nix makefile must have slipped away before my eyes ??? I just tried calling "Make" in the test-directory and it worked. Dunno, maybe the root of all evil was that I had the SDCC 2.4 for mac -"edition" which did not compile properly... ...and now I got 2.5.4 installed (had no success with 2.5.0) Nevertheless, I learned a lot about makefiles ::) Thanks & regards, Michael

hum ... maybe there's a huge lack of very important information inside my head, but I couldn't do anything with this "OS X"-Makefile. So I converted the existing makefile.bat from the 1.0.c skeleton into a bash-script for os x: #! /bin/bash # MAKEFILE FOR BASH # ASSEMBLING / LINKING SDCC / GPASM / PIC # FOR MIDIBOX ->> www.ucapps.de <<- # setting up main vars PROJECT='project'; # assembling echo '*** BUILDING & LINKING' $PROJECT '************************************************'; echo 'Setting up _output directory...' mkdir _output; echo 'Assembling MIOS SDCC wrapper...' gpasm -c -DSTACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f -I mios_wrapper mios_wrapper/mios_wrapper.asm -o _output/mios_wrapper.o # building echo 'Building the project files...' echo 'Compiling pic18f452.c' sdcc -S -mpic16 -p18F452 --fstack --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -pleave-reset-vector -DDEBUG_MODE=0 pic18f452.c -o _output/pic18f452.asm ./tools/fixasm.pl _output/pic18f452.asm gpasm -c _output/pic18f452.asm -o _output/pic18f452.o # compiling echo 'Compiling main.c' sdcc -S -mpic16 -p18F452 --fstack --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -pleave-reset-vector -DDEBUG_MODE=0 main.c -o _output/main.asm ./tools/fixasm.pl _output/main.asm gpasm -c _output/main.asm -o _output/main.o # linking echo 'Linking '$PROJECT gplink -s project.lkr -m -o $PROJECT.hex _output/*.o # converting echo 'Converting '$PROJECT'.syx to '$PROJECT'.hex' ./tools/hex2syx.pl $PROJECT.hex # done! echo 'Done! ------------------------------------------------------------------------'; here is the same post along with some more instructions I hope this is to some use for someone. If this isn't the 'right' way, please feel free to correct things, at least this is simply working without the need of having VPC and PC-Stuff installed... regards, Michael

;D You might still need a PC for Burning the MBHP-Loader into the Pic, but everything else now works quite fine!! Here is what you need: 1. GPUTILS: someone called bgb has done a precompiled GPUTILS installer. thanks for that! 2. SDCC (latest snapshot – don't use the installer for SDCC 2.40 for Mac, it won't work) If you load the binaries (precompiled versions) install them properly in /usr/local/bin test in the terminal with "sdcc -v". should show the proper version > 2.5 now! I have SDCC v 2.5.4. 3. You might need these additional libraries (I don't know, you might try it without, if something doesn't work, you should look for these dependencies). Maybe you'd like to install Fink and FinkCommander... -> gettext-0.14.5, gputils-0.13.2, libiconv-1.9.2_1, libtool-1.5.22_1 4. call mkmk.pl from the tools subdir to generate the makefile 5. type "make" in the terminal (in the proper directory) --> voilà (hopefully) ;) Michael

Im on OS X; I found some articles about Xcode integration (MacDevCenter), but no PICs, just AVRs :'( I haven't got it to work for PICs, because I am also having trouble with the latest SDCC-release (that one with the PIC18F-support). Doesn't compile with a bunch of errors I'm tired to track down; I think this release will never compile on OSX :( Nevertheless, it works quite fine modifying ASM code with MPLAB-ide in VirtualPC, then calling the hex2syx-Python-Script in Terminal and sending the *.syx-file with "SysEx Librarian". But there's one thing I couldn't get done on my mac: burning the PIC. There's no serial Port and all USB-Adaptors have never worked relyable and / or there were no drivers available. So after all, if you want to burn MIOS into a chip, you'll need a PC. (Don't know if this changes with MBHP-Burner, I used JDM). I hope there's a working SDCC-version soon for OS X, because working with XCode2 would be *Â :DÂ delicious! wonderful! ahh! Just after writing this comment, I found some new articles; maybe these links are of some interest: http://www.1710.co.uk/picosx/ http://forum.microchip.com/tm.asp?m=128288 http://dmxprojects.com/projects_pic.html (PIC Programmer for OS X)