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

since there are many avr with usb, why the monome creators used a ftdi chip? did tk ever cosidered to implement those chips in mbhp? regarding gm5: did the creators write dedicated driver? is there a standard tool like ez-usb for cypress? what happens if i connect two gm5 to a computer? and what happens in i try to connect two (or more) usb modules (cypress based) to a single computer? i'm curios about the case in wich i build many usb midiboxes and i intend to use all these with a single computer...

what avr model is used for the gm5?

count me for a kit including the 8 pic. thanks

hi cimo where did you find those joysticks with pushbuttons?

email sent!!

can someone tell me where can i find thos 144 character lcd's like the ones you can see in novation remote zero sl?? thanx

i'm very happy to see the touchsensors work extremely well in my boxes. i have some questions for Thorsten and for everyone could answer... 1- is it possible to make touchsensors with ain inputs, i mean some kind of proximity sensor without the use of qprox chips. if not, what qprox model can i directly interface to ain with no modifications on code? 2- is it possible to make an ain input sensible to the proximity of magnets? i woul like to build a sensor-based pitchwheel or joystick (no pot, no mechanicals) 3- if i do not use fingers\bodycapacity to control a touchsensor of a qprox, what other materials can be used to control the sensing fields of touchsens.

http://almost.fablab.googlepages.com/lsensor.pdf http://forums.linear1.org/index.php/topic,469.0.html http://projects.dimension-x.net/technology-and-projects/ledsensors

as i know... each color is sensible to his frequency or higher freq. i made the most stupid test in the human history: i measured the current sent by a common led that is exposed to the light. i used a common yellow led as reciver and a ultra bright white led as emitter. the voltage goes form 0.001 0.002 under no exposition (the only light is the light of my room, the main light is on...) to 1,4 1,5v under exposition to white led light.

i don't think that led sensing arrays can be used for professional music applications. the only realistic application for led sensors could be an economic alternative to buttons. small surfaces with many of led based buttons could be useful in studio, and relatively easy to realize, and most durable than mechanic buttons\switches. transparent sheets could be used to wiev the button functions probably te fact that led sensord can be used only in dark ambients is not true... probably xy pads with a decent detail (64x64??) could be built but the fact that images cannot be wieved while the matrix is in "sensing mode" makes many intereasting things imppossible to obtain: virtual controllers like sliders or rotary enc, seq... so, without viuals this is almost usless the possibility to use uv leds in combination with visible light leds is tooooooooo complex and the results could be unsuccessiful.ì, because of the slight different position of visible and uv leds. the hope to realize the multitouch led dream is to have composite leds with uv send\recive and visible light (red ) . and these thing do not exist, do they? but there is a remote possibility of succes with bicolor or rgb leds... in the case of a bicolor led the green diode will be used as senson when red is used as emitter and viceversa but probably each color is sensible only to his own light