polosid

i wonder what is the very minimum configuration for the core, when a dout nly has to be controlled...

ok, i added this connections 6 to 1kohm to 5v 18 to 10k to 5v 20 to 10k to 5v and it works....

i need to control only one dout module.. i connected only the pins 1,11,12, 13,14(crystal) 31,32 pin 19,21,22 to the dout and midi in at pin 26 my pic works on a common pcb, but not on my vectorboard!!! all the connections to the pic and to the optocoupler are right, the power level is ok... what am i missing?

i added all the bypass caps and still all the leds are bright at power on. it happens in 3 different midiboxes but i repeat, sometimes at power on all the leds are normally off...

the connection to the core is correct, becuse the machine works correctly... the problem is at power on. another fact is that i'm using ultra bright leds, and some of those (60 leds for this project) now are fired... i'm using 74hc595, without any bypass cap... what are htc? do i have to use 100uF for the bypass caps? what exactly these caps do?

i'm using a mb64 firmware to control some leds via midi... it's an artistic project. i noticed that sometimes when i turn on the system all the leds get bright. it happens even on another mb64(a complete midi controller). so i turn off and on again untill the panel is powered with all the leds off... is it an electrical problem? is it related to the multiplexers? do i have to add some capacitors somewhere? i need my system to start working at power on with all the leds off!!

no no... i don't need to control each led individually. the leds are connected all together in a cluster...

what can i use to drive groups of 16 or more leds from a single dout pin? i don't want to use relays with mechanical parts. is there an alternative?

you're right... but i intend to realize percussive pads... i think that when you tap on the fsr sensors you get a short pulse to read, that is pretty similar to piezo pulses... that's why i asked if someone wrote some code that i ould use as base... i would like to have 16 pads but i also know that multiplexing adds latency. what is the best hardware configuration to read 16 ain with the highest rate? i think i'll start from the c-examples i'm sure i'll need help though

hello i'm new to programming... is there some code examples that do in mios something similar to what the Edrum does? i intend to use fsr instead of piezos, but i think that the software side is the same...

mmmhh.. i tried to touch ground and ain input(unmuxed) directly with my hands and nothing happens... if the fingers are slightly wet i can se variation but only of few values... what i need is to control the complete excursion (0-127) of a cc by touching electrodes and skin

i want to build a midibox based controller that can work like the Skinstrument http://www.daanbrinkmann.nl/?p=25 the controller will generate only midi cc data and the sounds will be sithesized by a pc with various softwares. can i use ground and ain-in connections for the electrodes? will it work? will it be safe for the health? could someone give me some ideas, links or inspiration?

you're right. but i have a last question. yoy sayd that ftdi chips are difficult to solder. but what is the difference with the fm chips or the cypress or the gm5 itself? i saw the picture on the ploytec site and it seems that they use the smd version of the avr or there is such an intermediate format?

i was just curious, seppoman. the questions i made regard general usb handling in diy projects, and are not strictly related to gm5 or to mios. of course i'm happy about gm5 "as-is" i only underlined that in a "monome like" solution you can freely handle midi, osc, qwerty or mouse control with less worry for mcu programming. i'm curious about the solutions in this direction

mmmhh... so there is no need to modify the driver, in cubase\nuendo i'll se many midi ports as many usb modules i connect to the pc. right? i just plug a second module and it will be recognized.. regarding the general concept: if i actually build a midibox with usb it's like building two machines in one: a midi-usb interface and a classic midibox controller. in the monome project (if i understand) midi (or osc) data is generated by a software (the driver that recives serial signals from the hardware device) this solution transfers "complexity" from the mcu to the driver. don't you think that all the pic-usb problems could be solved using such a configuration? so there re no midi issues at all before the driver anyway i'll join monome forum to get more infos