avogra

cliché

I didnt look too much into details there. but anyway, as soon as you have a core you can try out whatever you want and then use it for the pedal box :) btw., it really helps to have a lcd for the beginning. and i just discovered, that pedal box isnt using the standard 18f452 pic. i hope you saw it too? just that you can switch to pedalbox later. good luck and have fun with the parts :) Alex

horray!!! *dancing the it's-working-dance* :D yesterday i finished everything, i really need. my core now translates the odd velocity response of my stage-piano to sensible values and catches most buttons from its control-surface. those are used for preset-changes, midi-channel switching and effects on/off. most buttons on the stage-piano send a really ugly mixture of BS+PC, CC and sysex-messages. unfortunately, i cant ignore those, as other buttons send the exactly same sysex-msgs only. the code is quite a patchwork :P 10 of those buttons are then used to send the BS+PC msgs, my expander wants to see. pressing multiple times allows access to higher presets. another 2 buttons allow to change the midi-channel (resp. patch on the expander), notes and damper-CC are sent on. when a note-on is received, the box remembers the channel for each key. note-offs are then sent on the same channel. same for damper. that way i can play e.g. a chord, hold it (or use damper) and change the channel. while playing the new patch, the chord will sustain until i release keys (or damper). the 2 remaining buttons are used for all-sounds-off and toggling an effect on the expander (sysex-msg). quite trivial, but gives me a whole bunch of new options :) ultimately, i came to the conclusion, that already now, i won't need the floorboard anymore 8) next thing will be a propper housing. then, im thinking about using ordinary buttons and a DIN instead of the ugly button-processing. and somehow a lcd feels like a must, although i dont really need it :) so all together, nothing special in here. most of it is not even reusable, but it's already doing a great job for me! cu, Alex

Hi Coma, have you already discovered the "Pedal box"? that might be exactly what you want. it took me some time to understand what it can do and what is the difference between pedal box and pedal board. pedal box seems to be quite similar to this LG-Module, although they differ in features. best you see and read yourself ;) ah, welcome aboard btw :D (somehow strange to say that, as im registered for just 2 weeks myself :) ) Cheers, Alex

unsubscribe

an error there could also explain, why the PSUs dont like you ;)

hey Thorsten, thanks for the input! your suggestion for improving the table-search is quite obvious, now that you showed me :) this is definitely a go. you're right with the breaks. i have them in the sysex-parser, just forgot them in the example ^^ it's just 20 minutes, that i came up with another option myself: hash-functions. if i find a function, that creates a unique byte out of my 24 message-sets, i could populate a simple byte array with 24 entries in MPROC_Init. then, when i receive a set, calculate the hash thereof and search it in the byte array. still your solution might be even faster. although, if i use the right hash-function, i could also do a sorted table... hmmm :) this might be very interesting for the sysex-parser too, it's only 10 messages to find. but might be tricky, to find a function there... if i don't, i might still think of your search as an alternative. is certainly better to read, and maybe not too slow... arrgg, i should get some more coding practice, instead of evaluating air castles. best thing will be, i do all of them and then decide on one :) Cheers, Alex

hey, i'm scratching my head about the following for some time: my keyboard sends bs+pc on ch 0 when i press one out of 24 instrument buttons. i want to identify the button pressed and forward an individual message to the midi-out. unfortunately those messages are not in any order but arbitrary sets from the gx-standard (i suppose), so i can't ignore the bs and apply some offset to the pc to get a button-number. at the moment i can think of 2 solutions to parse those incoming messages, but i'm not very pleased with both of them: Option 1: straight forward - compare incoming sets to a table of known sets -have a table, where each button is represented by its bs(msb) + bs(lsb) + pc -store incoming bs+pc in a temporary struct-variable -when pc was received, compare the set in the variable with each set in the table. the index of the table-entry that matches the variable, gives me the button number. Option 2: a finite-state machine (did this already for incoming sysex-messages): example code for 2 buttons: // BS-MSB BS-LSB PC // button1 0x00 0x70 0x01 // button2 0x00 0x44 0x05 unsigned char state; // 0xFF = set complete, 0xFE = unknown set unsigned char last_state; unsigned char button_pressed; void process_messages(unsigned char msg_type, unsigned char value) { // msg_type 0x00=BS-MSB, 0x20=BS-LSB, 0xC0=PC last_state=state; switch state { case 0: //no bytes received so far switch value { case 0x00: state=1; } case 1: //0x00 received switch value { case 0x70: state=2; break; case 0x44: state=3; } case 2: //0x00 0x70 received switch value { case 0x01: button_pressed=1; state=0xFF; } case 3: //0x00 0x44 received switch value { case 0x05: button_pressed=2; state=0xFF; } } if (state == 0xFF) //button recognized, do something with it do_something(button_pressed); if (last_state == state) //state didn't change -> unknown set state = 0xFE; if (msg_type == 0xC0) //set completed -> start over state = 0; } Option 1 means, that in worst case, the programm has to do 24x3=72 table-lookups. i read those are really slow. as my app isn't doing too much at the moment, this might be a minor issue, but i don't like to start out that unefficient :) Option 2 lacks overview, as the actual sets are spread over many cases, also the code really explodes, if i do this for all the 24 buttons. At the same time the function becomes quite complex (regarding execution paths). in the sdcc manual i read, that complexity shouldnt be more than 10, which i go far beyond. so this option seems to drop out completely. Do you have any other ideas, how to do this? or maybe a way, to improve my options? As i mentioned, i'm using option 2 for parsing sysex messages and it works (30 states). but i feel, it's really ugly and it is hard to read out the messages or add new ones. so any ideas here are very welcome too :) Thanks! Alex

ok, got it :) when reading through the post once more, i realised, sdcc didn't even try to compile a midi_process.o, so added this to the makefile and everythings fine now. i thought, i had read somewhere, that the latest release looked after this automatically. but suppose i got something wrong there. Cheers, Alex

Thanks for the welcome :) @lylehaze: thnx for the hint. i did something similar in *cough* basic, that generates a file, ready for copy n paste. right now, im somewhat stuck in ashaming (?) C-Basics :( The velocity translation works perfect. What i did next, is a very basic sysex-parser. but i don't get it to compile. seems to have to do with my includes: the function sysex_parse() is in the file midi_process.c, functions are declared in midi_process.h . the .h-file is included in the main.c when i also #include midi_process.c , it compiles fine. Someone have a look? I stripped the code down to the basics and moved the function call into Init(void) for shortness, so don't be puzzeled, what's its purpose there :) also attached complete files in test.rar Console output first: CD: C:\Eigene Dateien\MIOS\test\ Current directory: C:\Eigene Dateien\MIOS\test make Process started >>> rm -rf _output/* rm -rf _output rm -rf *.cod *.map *.lst rm -rf *.hex mkdir -p _output sh C:\Programme\MIOS_base\bin/mios-gpasm -c -p p18f452 -I./src -I C:\Programme\MIOS_base/include/asm -I C:\Programme\MIOS_base/include/share -I C:\Programme\MIOS_base/modules/app_lcd/dummy -DDEBUG_MODE=0 -DSTACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f -I C:\Programme\MIOS_base/modules/mios_wrapper C:\Programme\MIOS_base/modules/mios_wrapper/mios_wrapper.asm -o _output/mios_wrapper.o sh C:\Programme\MIOS_base\bin/mios-gpasm -c -p p18f452 -I./src -I C:\Programme\MIOS_base/include/asm -I C:\Programme\MIOS_base/include/share -I C:\Programme\MIOS_base/modules/app_lcd/dummy -DDEBUG_MODE=0 C:\Programme\MIOS_base/modules/app_lcd/dummy/app_lcd.asm -o _output/app_lcd.o sh C:\Programme\MIOS_base\bin/mios-sdcc -c -mpic16 -p18f452 --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -I./src -I C:\Programme\MIOS_base/include/c -I C:\Programme\MIOS_base/include/share -DDEBUG_MODE=0 main.c -o _output/main.o C:\Programme\MIOS_base\bin/mios-gpasm modifies _output/main.asm, result in _output/main__mios-gpasm-tmp.asm gplink -s C:\Programme\MIOS_base/etc/lkr/p18f452.lkr -m -o project.hex C:\Programme\MIOS_base/lib/libsdcc.lib C:\Programme\MIOS_base/lib/pic18f452.lib _output/mios_wrapper.o _output/app_lcd.o _output/main.o error: missing definition for symbol "_parse_sysex", required by "_output/main.o" make: *** [project.hex] Error 1 <<< Process finished. ================ READY ================ /edit: removed remaining code, as error had nothing to do with it i would be glad if you could help me out! Thnx & Cheers :) Alex test.rar test.rar

Hey everyone! after half a year lurking around ucapps and the forum, i finally ordered a bare core from mike's and got into things :) I didn't believe that anything would work the first time. but - praise to great tutorials for a great platform! - voltages where correct, nothing smelled suspiciously when trying with the pic plugged in, and when looking carefully, i even noticed the stiffed in led flickering a little :) i wasn't prepared to be so happy about a led :) when i arrived at my pc (200km away -.-) with already set-up toolchain, the next moment of excitement was waiting for me: will it talk to me??? and jepp, it did periodically :) uploading mios was just a hop. so its coding time for my first c-app! what i'm after: main intention is a velocity converter to take care of the odd velocity-curve of my yamaha P80. next issue is teaching my floorboard to talk sysex. up to now, thats all i need. although a 3-port merger would be nice, and maybe some knobs n buttons to supplement or even replace the floorboard, and... hm i'm not even lightly scratching the possibilities of mios, d'oh! but better get into things step-by-step, so back to the velocity converter, which really gave me headaches. it should be really simple, but as my even little C-skills are quite rusted, it took me 3 hours to figure out how to implement a basic translation-table. at least it works now :) lets see how i will cope with the sysex stuff :-P so far, many many thanks to Thorsten and everyone else for the fun, that mbhp and mios have already given to me! awesome work!! cu, Alex