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.

well, i've just re-checked and resoldered my connections i don't know how many times, and even rewired the connections between the ain and the core, and still no luck. it will be fine for a good 15 turns of a pot, then all of a sudden it'll start sending zeros whenever i move it. looks like the SRIO app is for the din/out. i'm almost tempted to buy the doepfer pocket electronic kit and swap it out with the midibox boards.

thanks! are these the inputs or the connections to the core? i'll go over both right now.

ok, got it running in the chat, thanks to bugfight. it's definitely more stable with the 10k pots, but my old problem still exists to some degree: -turning one pot occasionally sends data for another pot. -after hooking it to a synth, i can hear that this behavior often results in parameters randomly resetting to zero -turning a single pot often sends values that jump around for that CC. usually i can wipe smoothly from 0-127 with no glitches, but often the parameter seems to reset itself to 0. -no data is ever sent unless a pot is being turned. so it definitely seems to be the analog ins that are hooked up to the pots, and not the other ains. further ideas? thanks, greg

just tried it. it only lets me browse for hex files, but i typed in the path and sent it. no dice. it says upload process complete, but no change in the midibox (non)behavior. thanks

i can't figure out how. when i go to sysex send/receive, it shows me a little window that says ***TODO***. does that mean it's not implemented yet? thanks

well, i don't get any random data when uploading the mios. i get all the normal checksum responses and mios studio says it's completed successfully. it's just when uploading apps, i get no response from the midibox. i think the 1k pots were the cause of the problem i was having before, but now i'm just not seeing anything come out of the box after the startup upload request. i've uploaded mios numerous times and tried uploading many different midibox64 apps with midi-ox. i'm sure the settings in midi-ox match the instructions for uploading.

ok, found a wiring problem; i had my + and gnd wires going to one set of 8 pots twice, instead of once to each set. so i guess the ungrounded pots were causing the streams of data. but now that i've fixed the wiring, i'm still not getting anything, after uploading the mios successfully and sending applications (the midibox does not respond to the application uploads). i get the upload request on power up, but then nothing at all. voltage is what it should be at the regulator and at the pots. ideas?

when i re-upload mios, mios studio gets the right response messages, but then i get no messages when i upload an app, and no data from the pots. any ideas? thanks

...and now i'm getting nothing but the startup sysex message. hmmm.

ok, i installed the 10k pots. my resistance looks good, but i'm getting tons of midi data shooting out of the midibox: TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT 0003EBED 1 -- 90 4D 00 1 F 5 Note Off 0003EBEE 1 -- 90 4E 00 1 F# 5 Note Off 0003EBEF 1 -- 9F 4F 00 16 G 5 Note Off 0003EBF7 1 -- B0 5B 00 1 --- CC: Reverb Depth 0003EBF8 1 -- B1 5B 00 2 --- CC: Reverb Depth 0003EBF8 1 -- B2 5B 00 3 --- CC: Reverb Depth 0003EBF9 1 -- B3 5B 00 4 --- CC: Reverb Depth 0003EBFA 1 -- B4 5B 00 5 --- CC: Reverb Depth 0003EBFB 1 -- B5 5B 00 6 --- CC: Reverb Depth 0003EBFC 1 -- B6 5B 00 7 --- CC: Reverb Depth 0003EBFD 1 -- B7 5B 00 8 --- CC: Reverb Depth 0003EBFE 1 -- B8 5B 00 9 --- CC: Reverb Depth 0003EBFF 1 -- B9 5B 00 10 --- CC: Reverb Depth 0003EC00 1 -- BA 5B 05 11 --- CC: Reverb Depth 0003EC01 1 -- BB 5B 04 12 --- CC: Reverb Depth 0003EC01 1 -- BC 5B 03 13 --- CC: Reverb Depth 0003EC02 1 -- BD 5B 01 14 --- CC: Reverb Depth 0003EC03 1 -- BE 5B 08 15 --- CC: Reverb Depth 0003EC04 1 -- BF 5B 00 16 --- CC: Reverb Depth 0003EC05 1 -- B0 5D 00 1 --- CC: Chorus Depth 0003EC06 1 -- B1 5D 00 2 --- CC: Chorus Depth 0003EC07 1 -- B2 5D 00 3 --- CC: Chorus Depth 0003EC08 1 -- B3 5D 00 4 --- CC: Chorus Depth 0003EC09 1 -- B4 5D 00 5 --- CC: Chorus Depth 0003EC0A 1 -- B5 5D 00 6 --- CC: Chorus Depth 0003EC0B 1 -- B6 5D 00 7 --- CC: Chorus Depth 0003EC0C 1 -- B7 5D 00 8 --- CC: Chorus Depth 0003EC0D 1 -- B8 5D 00 9 --- CC: Chorus Depth 0003EC0E 1 -- B9 5D 00 10 --- CC: Chorus Depth 0003EC0F 1 -- BA 5D 00 11 --- CC: Chorus Depth 0003EC10 1 -- BB 5D 00 12 --- CC: Chorus Depth 0003EC11 1 -- BC 5D 00 13 --- CC: Chorus Depth 0003EC13 1 -- BD 5D 00 14 --- CC: Chorus Depth 0003EC13 1 -- BE 5D 00 15 --- CC: Chorus Depth 0003EC14 1 -- BF 5D 00 16 --- CC: Chorus Depth 0003EC15 1 -- B0 4A 00 1 --- CC: Brightness 0003EC16 1 -- B1 4A 00 2 --- CC: Brightness 0003EC17 1 -- B2 4A 00 3 --- CC: Brightness 0003EC18 1 -- B3 4A 00 4 --- CC: Brightness 0003EC19 1 -- B4 4A 00 5 --- CC: Brightness any ideas? does this mean i have a bad pot? all the unused inputs are grounded. thanks, greg