gzifcak

yeah yeah yeah. but it was a particularly stealthy bridge, and i had no suspicion that it would be in that area.

yes. i've been using it with a synth for about 10 minutes with no problems. i'm psyched! today was really my last chance to make it work before i go on tour. thanks so much to everyone who offered so many suggestions! case closed! greg

whoa! i think i got it! there was a bridge from a trace connected to the pull-up resistor to another trace nearby. it was hard to catch because it was at a solder joint and looked like it was supposed to be connected. let me test it for a while and make sure it's fixed. thanks thorsten for drawing my attention to the pull-up resistor!

i reheated the joints, and i'm not getting a fast stream of notes anymore, but i get a combination of note-on, note-off, and various CC messages when i turn a pot. is this normal? still getting the same behavior with my modified app. also when i send the sysex for my app, i get a bunch of note offs when it starts sending, then it calms down and sends the checksums. i wonder if it's my pic socket? no, just bypassed it for the pull-up resistor, no change.

just tried project.hex from that zip, and i get runaway note-ons. it's not a midi feedback loop, as it happens even with the midi input disconnected. is this a clue? pullup resistor is firmly in place.

my ini file has: [sNAPSHOT_AT_POWERON] disabled [AUTO_SNAPSHOT] disabled in fact, here is my entire ini file. let me know if there is a problem: [TYPE] midibox64 [bANKNAME] "SFB Example " [CONNECTED_POTS] 16 [GLOBAL_MIDI_CHANNEL] 0 [MORPH_BANK] 1 [MORPH_POT_GLOBAL] 0 [MORPH_POT_G1] 0 [MORPH_POT_G2] 0 [MORPH_POT_G3] 0 [MORPH_POT_G4] 0 [sNAPSHOT_AT_POWERON] disabled [AUTO_SNAPSHOT] disabled [MIDI_MERGER] enabled [POT_BEHAVIOUR] normal [sEND_PC_ON_BANKCHANGE] disabled [RECEIVE_PC_FOR_BANKCHANGE] disabled ################################################################################ [POTS] # Pot Row 1 1 = B0 00 [00-7F] "CC # 0" DEC| 2 = B0 01 [00-7F] "CC # 1" DEC| 3 = B0 02 [00-7F] "CC # 2" DEC| 4 = B0 03 [00-7F] "CC # 3" DEC| 5 = B0 04 [00-7F] "CC # 4" DEC| 6 = B0 05 [00-7F] "CC # 5" DEC| 7 = B0 06 [00-7F] "CC # 6" DEC| 8 = B0 07 [00-7F] "CC # 7" DEC| 9 = B0 08 [00-7F] "CC # 8" DEC| 10 = B0 09 [00-7F] "CC # 9" DEC| 11 = B0 0A [00-7F] "CC #10" DEC| 12 = B0 0B [00-7F] "CC #11" DEC| 13 = B0 0C [00-7F] "CC #12" DEC| 14 = B0 0D [00-7F] "CC #13" DEC| 15 = B0 0E [00-7F] "CC #14" DEC| 16 = B0 0F [00-7F] "CC #15" DEC|

i cleared the window, but it may well have gone further. i don't have a button, or an lcd. just 16 pots. is there some hardware section i need to configure if i don't have a button? or maybe i'm having a software configuration issue?

i just noticed something: once a pot starts glitching, it looks like it might switch from changing the values of a single CC, to scrolling through CCs with a value of zero: am i interpreting this correctly? does this offer any insight? thanks, greg

well, i disconnected the power jack from the chassis, and also made sure no other ground is touching the chassis. the midibox is sitting on a wooden table hooked up to a laptop running on a battery. still same exact behavior.

hi! thanks for the tips. i do have a power jack mounted on the metal chassis, and there probably is a path between that and the pot ground. i'll disconnect that and see what happens. i have tried the midibox plugged into a nord micromodular, and i can hear that it exhibits the same behavior. all unused inputs are tied to ground. thanks!

another observation: when a pot is glitching, the speed of the turn makes a difference. if i turn the pot slowly, i get almost all glitch messages, with a few correct messages in between chunks of zeros. if i turn the pot faster, i can squeeze more correct messages in between the chunks of zeros. so the glitch appears to be active for some sort of non-random period?

looks like it's not the multiplexers. i'm stumped. maybe i'll try running a separate vdd line to each pot.

could i have a bad multiplexer? i'm only using 2 so maybe i'll swap them out and see what happens.

ah, thanks, that definitely makes sense. so i've gone over all the vdd connections and reheated to make sure they're good joints (definitely as solid as any i've made in years of analog diy). i'm still getting the same behavior. i monitored the voltage across the pots with a meter as i turned the pots, and it stays rock solid. i get the zeros some times for a few seconds, definitely long enough to register on a meter if that was happening. any other ideas?

no, it's the same. turning pots sometimes causes data assigned to other pots to be sent, usually with a value of zero. maybe i didn't mention that sometimes it's the same pot's data that is all zeros. it seems like it will work fine, and then something happens to make the inputs clamp to ground or something, but only while the pots are turning. it's almost like a lowpass filtered square wave LFO with a pseudo random rate is being mixed in with the pot data, through an AND processor. at least that's how i would synthesize it.