DIYstompboxes.com

I get sucked in by shiny things every so often.

The AD75019 crosspoint switch that got mentioned and I picked up on has done so. It looks like a good solution to making an any-order programmable switch setup for a pedal board.

I got carried away with it and did some trial layouts. Looks like the chip itself is, as expected, trivial compared to the mess of wiring needed for the jacks. I set the jacks part of it up as a modularly expandable array, an input jack and two loops, and output jack and three loops, and a section of five loops, so you can have a five-pedal router, or a ten or 15 by inserting one or two five-loop sections.

The odd arithmetic is because one in and one out of the 16x16 cross point array is taken by the input jack and output jack, so only 15 ins/outs are available for pedals. The switching chip is a tiny wart on the wiring and PCBs for the jacks. A 15-loops setup will be as much as 30 inches wide. Possibly this can be cut a bit by using vertically stacked jacks, but those are hard to deal with in setup, I think.

The tougher questions then becomes how a user will interact with this mass of switching. I don't like menus and scroll bars for controllers. I'm still working on how to let the guitarist see what he's doing. A 16x16 crossbar switch is a seriously capable setup. Any one of the inputs can be connected to any one *or up to all* of the outputs at any time. So can the other inputs. It's entirely possible to tell this thing to do things with signal routing that you do NOT want it to do.

So some kind of processor needs involved to read what the guitarist says, then interpret that into a sane routing setup inside the crossbar that does what a human would expect it to do. I'm actually thinking of hexadecimal (0-9, A-B-C-D-E-F) loop names rearranged on a screen showing the actual routing order and which one(s) are on in a set of loops. It gets tricky because there is no longer any physical connection between the order of the footswitches and the order of the effects in the chain, nor to which effects are on at any time. There's probably a two-beers limit on using this in a sane way.

Hmmm. Display is a REAL problem. I may have been right: the right display is an old, otherwise useless laptop.

The fundamentals of working this (IMHO) require that the user needs to see a definitive display that tells him what set of stuff is playing. There are two situations that need covered, one a quick-and-dirty one while playing and another which may need to be more detailed while programming the unit.

On stage, you want one stomp to give you one set of pedals active and a rearrangement of those. You also want one visual indication that you got what you wanted when you stomped. And audio indication is OK when engaging a distortion from clean, maybe, but for subtler rearrangements and selections, that is (IMHO) not quick and effective enough for on-stage operation.

Yeah, sure, you can do the MIDI banks/programs number thing. Sucks (IMHO). The objective of music is not to make the musician memorize letters and numbers in so far as it can be helped. If the difficulty of displaying which pedal is on in a fixed order of pedals is N, the difficulty of displaying which pedals are on and which order they're in is at least N²; worse, the nonblocking crossbar offers you the possibility to do combinations and selections of sets of pedals (I/Os) in parallel/series/mixed. That is maybe N³ difficult.

Maybe text is the way. Perhaps you could just call your newly minted selection/rearrangement/series/parallel combination "Mellow Atomic Laser Blast" or something.

I'm currently chasing using a setup using 2" high 16 segment LED displays on the top of the unit. But velcro-ing a laptop to it is about the same cost and more flexible.  :icon_lol:

I was thinking something way dumbed down from that. One wide rectangle, 15 loops, in and out, with each loop have a dual sevens digit number display number display. The only interaction would be the up or down button next to the display. No bypassing footswitches, no loops within loops, just straight up a row of 15 loops. Set in the back of the board, rather than the front so the user would still use the bypass switches of the pedals themselves. I think the days of the LoopMaster-esq true bypass strips are over (or maybe everyone already has one).

Them simply rearrange you're pedals as you want with the number system. I'd the board reads 1 - 15, they are in the order you want them in. If you want that wah fourth in chain instead of first, push the button until 4 comes up on it's display.

Perhaps using the chip in this way isn't taking advantage of all the possibilities.

It's a reasonable idea. It's another variation of the number-per-loop thing. It is actually kind of my current favorite turned inside-out.

I was thinking that each loop would be a fixed number, right to left of 1 to 15 (Hexadecimal "F"). You'd set up the thing so that each footswitch would bring up one of 15 (or "N") possible rearrangements of those loops, and the display would show something like "8237A41" for one footswitch, then when you pressed another footswitch it would change to maybe "4B31" and another footswitch could be "F2AC57681347". Gibberish, yes. But as a name for one "program" it's highly recognizable to the guy who set it up. And for tinkering and setup, you could recognize that '4B31' was the fourth pedal from the right, the B-th (i.e. 11th) pedal from the right, the third pedal from the right and the first pedal from the right. A simple string of pedals in order from left to right is "123456789ABCDEF" if all pedals are in.

The problem with all of this is having to make a guess which form of displaying the information is better for the variety of human minds reviewing it as they punch footswitchs in the middle of the song. And humans being humans, some will like raspberry and hate avocado, while others will prefer chicken with garlic sauce. And once you've decided how to accommodate the humans, it has to then be buildable, and then it has to be buildable at a reasonable price and difficulty.

Pesky humans.   :icon_biggrin:

> thinking of hexadecimal (0-9, A-B-C-D-E-F) loop names rearranged on a screen
> The objective of music is not to make the musician memorize letters....

Every Good Boy Does Fine?

Hex-code initially (or just A-0); then ask user for "names". Muff, HardOn, Phazer, etc. There is a compromise between a fully descriptive name "Roland BOSS Special Edition distortion pedal with next-generation technology" and display space "Roland BO"; let the user work it out.

> the right display is an old, otherwise useless laptop.

I'm having bad luck with not-so-old laptops. While I have one working flaptop pushing 10 years, others have failed in 3. (FAILED, not just user-garbled, which happens a lot.)

Also think a pack-up nightly gig will be harder on a laptop than "normal" laptop life. When I laptop just to laptop, I carry it carefully. Gigging, it gets thrown in a bag in the truck and then the trap-set falls over on it.

And MS/Apple ecosystems are about forcing you to new versions, which sometimes break old code. I am very peeved at Win7 because real-simple DOS apps are just shut-out, and some XP programs fall-down.

Raspberry Pi with its linux. Old unix code usually just works, and new code should just-work for many years. RaspPi is flash-drive and fan-free, mechanical wear-out is nil. Cost is small. Various displays are possible, from 2-line LCD to 84-inch TV. Display configuration will be a problem as long as we are on X-windows from 1980, but change may happen in our lifetime.

There is a sound-path program JACK for unix (and others). http://www.jackaudio.org/ For software interconnect (virtual pipes), and JACK itself is a daemon, there are various user-interfaces available. I have not explored it. However many musicians use it post-processing (maybe live?), so there is community support. The several interfaces may suggest what works for users. The fact that it is poking a hardware matrix instead of data-streams doesn't really change the interface issues.

> A 15-loops setup will be as much as 30 inches wide.

Studio patchbays have a large number of 1/4" jacks in small or very-small space. Yes, they are tight and can be a pain to re-patch; also to navigate. And the archetypal telco plug/jack is not the Switchcraft cheap copy, so may not be best even if you can afford the startlingly high prices and can find a configuration without excess frills.

You could sell (extra profit) dual-1/4"-to-1/8"-stereo cables; Fit pedals one end, compact at the other. But I hate affordable 1/8" plugs (had a synth-ful) and also special cables.

Raspberry Pi

https://www.adafruit.com/categories/105

Raspberry Pi 2 - Model B - ARMv7 with 1G RAM $39.95
Raspberry Pi Model B+ 512MB RAM $29.95
PiTFT - Assembled 320x240 2.8" TFT+Touchscreen for Raspberry Pi $34.95
HDMI 7" 800x480 Display Backpack - With Touchscreen $89.95
Adafruit Blue&White 16x2 LCD+Keypad Kit for Raspberry Pi  $19.95
5V 1A (1000mA) USB port power supply - UL Listed  $5.95
And much more......

$30 gets a camera. Point it at pedalboard. Snag images for pretty display. Watch player's finger point "here" "here" and make that connection. (Much ambiguity processing needed....)

Well into $100 for "display" on a $14 matrix. However your box and jacks will force a high price. Interface makes/breaks the idea. (If it frustrates me, I'll go back to hand-patching.)

What's the goal?
Making a looper that allow the user to change the position of each loop on the chain? And with a user friendly interface?

If that so, i think these things..
- it is really necesary that all of the loops are movable? Do you think of someone that uses 15 pedals and needs 15x15 combinations? will this guy ever going to use 1% of those combinations? Like putting the reverb before the distortion and compression is something attractive to users?

What about a looper separated in blocks..you have 12 loops, and you separate them in 3 blocks, first, middle and last.. So for each loop program, you assign the parameter "position" for each loop..so instead of scrolling  12 times for each loop, you select if it goes first, middle or last..the order inside each position block is given by the natural position of the loop..visually you could see in what position block each loop is by a 3 color led..and just a number for each program.

If 15x15 combinations are needed, the simplest, most friendly interface is the dot matrix, where x is the loop number, and y is the loop position..

Quote from: dschwartz on November 27, 2015, 09:34:52 PM
What's the goal?
Making a looper that allow the user to change the position of each loop on the chain? And with a user friendly interface?

What goal??  :icon_lol:  I was just distracted by a Shiny Thing.

> distracted by a Shiny Thing.

While I was writing that, a new shiny thing appeared: a $7 Rasp Pi.

Sold-out in 12 hours, but is clearly going to be a stock-thing.

Doesn't help with the high cost of jackery and panel space.

I replaced the single jacks with vertical stacked pairs and got the total length down to about 17", so it would be simpler, but still it's a lot of space. Not to mention the sheer thickness of 32 phone-plug cords in and out of it.    :icon_eek:

And once again, by the time you pay for the box, the switches and the jacks, the electronics may as well be free.

Quote from: R.G.

And once again, by the time you pay for the box, the switches and the jacks, the electronics may as well be free.

If someone wanted to build a whole number of effects into one big box, you'd save the jacks and cables but then it would be a whole different beast

> vertical stacked pairs and got the total length down to about 17", .... 32 phone-plug

The traditional fill for 17" rack, double-stack 1/4" telco, is 48 (2 rows of 24).

(http://c1.zzounds.com/media/quality,85/patchl1-5a5c1d68db5b2b25309ba3d3554fab6d.jpg)

This may not be possible with our usual guitar-amp jacks.

Telco jacks were *designed* to fit close. (There was a time that every telephone customer had a jack on an operator's panel.)

This would pretty much be a no-go for anyone who uses those HOSA pancake cables.

Seriously, folks. The jacks and wires are not the problem. The user interface is the problem.

Yes it is, anyway I like these ones from Amphenol
https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcTjUx-ATTZrdxVmdueogIufmysac0Y9263pX6gNxNQ0RHQxJpPB

I mean, the user interface is the problem.

For simplicity and as few knobs as possible, what about one of those rotary encoders with a built-in push button?

Hold down stomp switch for a loop to go into program mode for that selection, then cycle through the loops with the encoder and press it on the selections you want active on that preset. A long press on the rotary encoder button could put it in manual, on-off operation on each loop.

I'd  go for a touchscreen interface looking like a visual representation of a pedalboard. User can simply move any pedal to a different location and other pedals would move out of the way, patching would re route automatically and rules could be put in place to prevent stupid loops. Tap to turn pedal on and off.
This part, I can do. Prog would output the required sequence in any format required but Interfacing with the switching circuit however, is rocket science as I don't understand what's required.
And. The cost has gone up yet again with the addition of a tablet or at least a pi & touchscreen

So, one of these....

(https://reverb-res.cloudinary.com/image/upload/a_exif,c_limit,f_auto,fl_progressive,h_620,q_75,w_620/v1426871115/u89dizaggqlhs2l72utl.jpg)

into one of these...

(http://www.dorkbotpdx.org/files/images/AD75019.jpg)

OK, a bit of a simplistic view, but I'm digging it.

R.G., if it helps, I can email you the complete manual for the AM-16, which includes the schematics for it (too heavy for gallery upload, 7+ megs pdf). I also have the bin file for the eprom on file. It might give you some insight as to how this 16x16 matrix was set up back in the day.

Personally, I love my AM-16's but the buffers could be much better.

Quote from: stallik on November 29, 2015, 05:16:01 AM
I'd  go for a touchscreen interface looking like a visual representation of a pedalboard. User can simply move any pedal to a different location and other pedals would move out of the way, patching would re route automatically and rules could be put in place to prevent stupid loops. Tap to turn pedal on and off.
This part, I can do. Prog would output the required sequence in any format required but Interfacing with the switching circuit however, is rocket science as I don't understand what's required.
And. The cost has gone up yet again with the addition of a tablet or at least a pi & touchscreen

Yeah, I was trying to find a way around that, something that's more palatable to DIY hackers that have only a meter, a soldering iron and a stone axe.  :icon_lol: But it may be that the optimum interface is something like a Raspberry Pi and a touchscreen, which is what I think you meant. I didn't do a complete rundown, but it looks like touchscreens for RPs are in the US$80 and up range, the RP itself is US$35-50 depending on supplier, so the UI, before programming, costs something like $125 by the time you actually get it running.

I have messed a bit with using LED character displays, something like a 14 or 16 segment display per loop. It's far less capable than a touchscreen. The parts cost runs up there too. Per-channel cost is about $2.50 for the display, $1.00 for the drivers, another $0.50 for the miscellaney, so you're up at ~~US$64 and up even using the cheapo setup.

Both of which merely confirm that conveying both on/off status and order for 15 loops (one is needed for the box in/our) is complicated if you don't make the user do the heavy mental work of remembering that a Bank 6 Preset 3 is the sound they set up back in the studio when they were prepping for the gig, and two beers ago.   :icon_lol:

Like Einstein said: everything should be as simple as possible - but no simpler. There is a limit to how simple you can complex setups for people if they're to be self sufficient with the tools.

Quote from: digi2t on November 29, 2015, 11:22:41 AM
So, one of these....
...
into one of these...
...
OK, a bit of a simplistic view, but I'm digging it.

Pretty much right. The single-chip crossbar makes the actual switching easy. But it won't easily replace the three multi-digit LED displays, dot matrix display, and multiplicity of up/down/sideways and other buttons on the front.

QuoteR.G., if it helps, I can email you the complete manual for the AM-16, which includes the schematics for it (too heavy for gallery upload, 7+ megs pdf). I also have the bin file for the eprom on file. It might give you some insight as to how this 16x16 matrix was set up back in the day.

Thanks, but I don't know what I'd ever do with it. Hold on to it for now. That unit does this kind of task, but differently in both the matrix switch and user interface. In fact, it's an example of the user interface I don't want to do. I've been working with computers since 1974, and I still don't like forcing the user to match the machine instead of otherwise. People should be free to think and conceptualize, machines should do the heavy lifting to let them think.

+1 for the touch screen and a graphical user interface.
A possible candidate for the job could be the STM32F7 discovery board (http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?icmp=pf261641_pron_pr-massmarket_jun2015&sc=stm32f7discovery-pr).
Hardware wise it'd be a complete system with a 4.3" TFT capacitive touch display, built in programmer/debugger, nice form factor for easy mounting on the front panel and a bunch of standard 0.1" pin headers on the back to hook it up with the rest of the circuit. Cost: ~$50-60.
(http://www.st.com/st-web-ui/static/active/en/fragment/product_related/rpn_information/board_photo/stm32f746g-disco.jpg)
All the work would be shifted to the software side. Looks like the Ad75019 could be driven via SPI, with a short PCLK pulse at the end of the packed instead of the usual !CS line.
The whole board with the AD chip could be designed as an Arduino shield plugged into the STM32F7 discovery (shorter SPI bus) and then use something like IDC connectors and ribbon cables to carry the audio signals.  Or even go further and make it modular, group the loops in sets of ie. four, use one pin on the IDC connector to detect if the cable is plugged in and reconfigure the GUI to match the number of available loops. This way the user could build a simpler version with less loops or expand it later on etc.

You could cut out the cost of the interface by installing a Bluetooth or wireless card and getting users to download the control app to their existing tablet. Cheaper and, to many, modern and hi tec

Quote from: free electron on November 29, 2015, 01:14:55 PM
A possible candidate for the job could be the STM32F7 discovery board.

Ah. Thanks for that. I'm living in what amounts to my version of a designer's paradise. All my professional life, the problem has been how to do the pick and shovel work to get the communications and interface parts of what I wanted to do done. I'm glad that the touchpad with programming at a reasonable price has finally dropped down to where it's a usable, integratable tool. Looks good. My only gripe is that a 4.3" touchscreen may as well be invisible to me from a standing height, as my onboard optical sensors continue to degrade from lifetime overuse.    >:(  So it's OK for young bucks that can see fleas from 30 yards. Maybe that's enough.  :icon_wink:

QuoteAll the work would be shifted to the software side. Looks like the Ad75019 could be driven via SPI...
Or even go further and make it modular, group the loops in sets of ie. four, use one pin on the IDC connector to detect if the cable is plugged in and reconfigure the GUI to match the number of available loops. This way the user could build a simpler version with less loops or expand it later on etc.

From a quick perusal of the docos, I think I'd go ahead and spend the $1-2 for PIC as a hardware simplifier, rather than trying to do bit banging in the STM32F7. Sometimes a little hardware can make software vastly simpler. And more modular, as we'll get to in a minute.

I have a working setup with a low-end PIC spitting out the settings for the crossbar, as well figuring out what the settings ought to be. This turns out to be simple in concept but needs filtering from the raw human input to keep the crossbar running in a sane way. Table look up and local logic for some ancillary functions makes sense. The PIC can manage the sensing of the footswitches and send filtered versions to the screen to help with programming and switching as well.

Another avenue is simply pasting the PIC to a wireless RF, WiFi or Bluetooth module to let it cry for help from any number of devices. That makes it independent of the specific screen, and implementable if you have an already existing laptop or pad that's otherwise useless, as several of my earlier laptops are now. One of my earlier laptops won't run anything past XP (or linux/BSD/etc) and is dedicated to being my "intelligent oscilloscope". Another is about to be co-opted into the controller for a CNC router I recently picked up.

And I can see the screens. Big help.    :icon_lol:

> cycle through the loops with the encoder and press it

I may be very wrong, but I think if the first unit *can* go to 15 different places, the second unit to 14 different places...

There's about 1.3^12 or say 1,300,000,000,000 possible combinations.

I don't think a list of the possible matrix settings is any help.

Also scrolling through lists drives me mad. Take the burden off the hardware and dump it on the user.

> User can simply move any pedal to a different location and other pedals would move out of the way

That's the guts of IMHO the "only" way this could work on stage, even rehearsal.

I've made an animated GIF. You should see a moving finger. (If not, try opening the image in new window, or different browser.)

(http://oi65.tinypic.com/303id83.jpg)
http://oi65.tinypic.com/303id83.jpg

A picture of the Chain, plus a pile of available pedals.

(In hindsight I see that "Remove" can simply be dragging the unwanted pedal back to the Idle pile. Or just off-the-chain, where it would snap-back to Idle pile.) (There's probably a cleverer way to do Replace or Insert too.)

Of course this is initial setup. For most acts, you would pre-set several/many/many-many patches and name them "Stairway.." "Am. Woman" "Down By.." "Gnarly" "E. Slide" "Hendrix". And on stage you might not have the patch setup screen, just your top-dozen patches and "more" to select from hundreds or thousands of patches.

That's another point. You have 567 patches saved and your Pi's little mind goes blank. It needs a SAVE file format, to dump to thumb-drive or, in today's world, upload to a Cloud for quick recovery.

Nice animation. I was thinking of a single space where a doubleclick turns off the unwanted effect but actually, your idea is clearer. Saving files is easy. File would only contain patch name and effect name/loop number/loop position x15. If you wanted to add pics, then add an entry for the pic number and the pics themselves.
There are 15 loops. The possible variations are irrelevant as far as the software goes, it's just the above info for each loop. The software just has to send the right details to the switching circuitry so that it can do its magic

I prefer to go the stone axe route.  The input and each pedal output is assigned to a busbar and each busbar can be selected for each pedal input by a rotary switch and you can get 12-position or even 24-position switches and they can have rotation blocked to the number of pedals you use.  So the preamp input is connected by a switch to the guitar output busbar, the wah pedal is connected by a switch to the preamp etc., but any pedal can be connected in any order and pedals can be left out and one switch is saved for the amplifier input.  Equip the rotary switches with yellow chickenhead knobs and even R.G. can read them from twenty feet away.

hey, that might be a good name - Stone Axe Router.

R.G., I have a question that is far far away from what is being discussed, but I think it matters.

I'm assuming you did not put an external all-bypass switch or relay to bypass the AD75019 when no loop is engaged. If you didn't (and even if you did), how do you cope with the limited headroom of such a solid-state solution? I mean, a hot TS9 or booster, intended to overload the grid of some lovely 12AX7 lady, will in fact overload the AD75019 with awful results.

I've been toying with the idea of using the MT8816 (8x16) for some time now for a usable audio matrix, but reading its poor specs made me give up precisely due to these concerns. Is the AD75019 any better?

Bear in mind that I've only seen the datasheet, never touched a real chip, but the datasheet says it will swing over +/-10V with +/-12V supplies. That's another thing that attracted me to the chip and one reason I've spent this much time on it. It's unlikely to be the limiter of the dynamic range if this it true. Even if it's running from +/-9V from a DC supply and a charge converter, that's twice the signal range of any 9V pedal.

Yeah, yeah, you could run into issues with an 18V powered pedal, or a 24V powered pedal, or the unattenuated output of a tube preamp, and it wouldn't do well to switch speaker outputs or 120Vac power, but I think it's OK for switching pedals.  :icon_lol:

... until proven otherwise. Someday I'll buy one.

Quote from: amptramp on November 29, 2015, 06:26:10 PM
I prefer to go the stone axe route.  The input and each pedal output is assigned to a busbar and each busbar can be selected for each pedal input by a rotary switch and you can get 12-position or even 24-position switches and they can have rotation blocked to the number of pedals you use.  So the preamp input is connected by a switch to the guitar output busbar, the wah pedal is connected by a switch to the preamp etc., but any pedal can be connected in any order and pedals can be left out and one switch is saved for the amplifier input.  Equip the rotary switches with yellow chickenhead knobs and even R.G. can read them from twenty feet away.

hey, that might be a good name - Stone Axe Router.

That's actually what the first design of a pedalboard router was on geofex, back in 2000. See http://www.geofex.com/article_folders/fxswitchr/fxswitchr.htm (http://www.geofex.com/article_folders/fxswitchr/fxswitchr.htm), pictures 3, 4, 5, and 6.

And chickenhead knobs I can see from 20 feet away are truly huge.    :icon_biggrin:

The LCD on the STM32F7 board is about the size of a modern smart phone. Unfortunately the viewing angle is not that great. Here is it compared to a standard 1590BB box:

(http://i.imgur.com/sWOpLhk.jpg)

Concept wise, i'd tend to use a separate config screen, where you can place all the loops and a huge preset number + it's name displayed in normal use mode. Or even go a full "nerd" route and use the resistor color code to show the preset number ;)
In edit mode you have to be closer to the LCD anyway to be able to use the touch screen.

Btw, there is a new 5$ Raspberry Pi zero with a HDMI output, also worth considering.

I suspect that the best way to do this is to hook up a local controller to run the footswitches and the crossbar, and then to work a Bluetooth or Wifi link module for communications, and generate an application programming interface so that the setup can be run by whomever and whatever is on the other end of the link. There are so very many communicating devices in the world now that choosing one and only one is probably a losing proposition.

Second rule of engineering: if you don't which of several or many options to do, make it selectable or adjustable.

Sadly, because the world is slowly learning that every hackable link will be hacked, it will mean that authentication and encryption protocols will need to be generated so you have some hope of it not being interfered with.

Current status is two PCBs. One is input PCB and output jack PCB. The input PCB contains the input jack, three loops, and the output as a break-off part, as well as the crossbar and three 12-pin connector spaces. This board by itself implements a three-loop crossbar looper and has a few wires to interface with a controller uC. The uC reads any number of footswitches and sorts out what to tell the crossbar to do as a result of the last footswitch press. Number of footswitches is not logically connected to the number of loops, other than that you can't choose more "patches" than the number of loops can do.

The second PCB is four loops and a connector. The connector can plug a 12-position ribbon cable into one of the connectors on the input PCB. This adds four loops when you do it. So you get a three-loop setup which is marginal, but possibly useful, and then a seven, an 11, or a fifteen loop setup by adding one, two or three four-loop PCBs to the setup. All of the four-loops are identical. 

I'll probably add some jumper blocks so the controller can know how many loops are installed and make sense of how many loops to tell the crossbar to do. There's one other PCB to do, the controller and its connection to N footswitches and a communications module.

Hmmm. Maybe I ought to include a USB or ethernet connector option as well as Bluetooth or Wifi. Or split the footswitches from the crossbar so you could put the footswitch unit out on stage and the looper itself back by the amps. Depends on whether you're doing bedroom use or stage use, I guess.

So very many options.  :icon_biggrin:

Nice! I like the modular expandable approach.
Bluetooth is more local (limited range= less hackable?) and doesn't need all that WiFi infrastructure around. Cypress makes a nice ~10$ certified modules, actually it's a small ARM Cortex M0+ with a bluetooth link built in:
http://www.cypress.com/documentation/development-kitsboards/cy8ckit-142-psoc-4-ble-module
Could even replace the main controller, has a plenty IOs and an UART header to add more comm modules.

I think recording studios could be potentially interested in such device. Ability to quickly rewire pedals, store the settings, assign them to different audio projects within the DAW... that sounds very tempting!

Consider leveraging the node-red user interface.

http://nodered.org/

It already has a concept of linking together functional blocks.  If you can write your own module definitions to involve the concept of connecting things on a crosspoint switch I don't see why it wouldn't work.

The UI is all served up over a regular network connection to your browser.  So the UI could be rendered on any thing like a laptop, Chromebook, iPad, etc. without modification. This would steer you towards Wi-Fi.

If this thing were actually connected to the internet, your tech could trigger patch changes by sending tweets from her mobile phone. Engage the boost pedal when your favorite team scores a goal or the value of your stock portfolio exceeds some limit.  You could send your patch changes to "the cloud" for "big data analysis".   And it can certainly run on a Pi!

Quote from: Digital Larry on December 12, 2015, 10:39:16 AM
Consider leveraging the node-red user interface.

http://nodered.org/

It already has a concept of linking together functional blocks.  If you can write your own module definitions to involve the concept of connecting things on a crosspoint switch I don't see why it wouldn't work.

Nice! Thanks. I'll go have a look.

I don't know - I think you may be overthinking the interface.  A row of LED indicators for each loop, as wide as the number of positions you have.  So, if you want sixteen positions for sixteen loops, a grid of LED's 16X16.  The rows (or columns, if you prefer) represent each pedal, and the LED which is lit tells you it's position in the chain. 

Gabriel

I do overthink a lot of things, so it's entirely possible. Although I personally would get lost with a 16x16 LED grid after applying the two-beers rule.  :icon_biggrin: Other folks might do a lot better.

And no one has popped up to question whether any of N effects in any of N! combinations and permutations is a good thing to do at all, or to call me on whether it makes sense for a guitar player to go flipping effect order on the fly on stage anyway. I'm a little disappointed Mark.  :icon_lol:

It is true that changing some effect orders makes sense and does change the tone a bit. However, in actual practice, there are only a few (compared to numbers like 16 factorial) order combinations that make musical sense, and this is probably best determined back at the practice room. Leaveing certain things out of an ordered chain, or using bypass and insertions to effectively choose one of a few possible parallel choices is probably a better scheme.

I've intimated this a little before in this thread, but a non-blocking crossbar can do things that are probably best left undone, bringing back the old adage that just because you can do something doesn't mean you should do it. Or it doesn't mean I should do it. Other people can probably do a better job of keeping things straight than I can.

I suppose we'll see. I had to put the layouts aside for the moment, as real life has re-intruded on the fun stuff, but I already did what I consider the easy part, a board to use the 16x16 crossbar to do a 15-loops package hooked to phone jacks. Boards would take a week or two, but then you'd have to figure out how to read a batch of footswitches, the number of which is not logically related to the number of loops at all, and then have something feed a serial bit stream to the switch to make it work.

Just as we used to say back in the programming center: no problem, it's just a simple matter of programming to get it to work.

Well, the thing that most interests me about this would be for the wet side of the wet/dry/wet rig I've been working on forever.  For me, it would ONLY be for time based effects (reverb, delay, chorus, etc., in case anyone looking in on a topic this obscure doesn't know that).  I could maybe see it being of use to, for instance, move a distortion before or after a tremolo (changing the volume, verses changing the amount of gain), but I'm not too worried about that.

Hatredman pointed me to this thread, though, because of a question I asked on the digital board.  For me, the appeal would be to have input and output busses switched to send and return loops, which gives you not only the ability to swap order, but also to put things in either series or parallel.  It basically halves the number of I/O's to 8X8 (you need to switch both the inputs and the outputs), and if you want to run stereo (I do!), you'd really need two of these chips (pricey! - but then I was thinking of using 128 opto-transistors!)  (The idea here is to have the pedals run 100% wet, and each input buss sums the previous output buss with the dry signal, and then you have a mix buss which mixes all of the output busses.  It's complicated, I know, but it makes feedback loops much harder.  You can also have two or three series strings in parallel by skipping busses.  I'm pretty sure I'm explaining this badly, but I can see it clearly in my head!)

This begs the question, though - from the data sheet, it does say you can assign any and all inputs to any and all outputs, which I take to mean you can assign multiple outputs to an input (GOOD!  You would need this for parallel operation), but that means you need to sum those inputs some how.  Can you just have a summing resistor on each input, and a buffer on each output?  or is there a problem trying to sum things inside the chip?

I did a quick look on Mouser, though, and there are much smaller chips (8x8, for instance) if someone really though 16x16 was too big. 

At any rate, here is kind of the idea I was having - make of it what you will.  I think input and output busses makes it a lot more versatile.

(https://c2.staticflickr.com/6/5807/23064412353_4ce3d9ef9e_b.jpg) (https://c2.staticflickr.com/6/5807/23064412353_1202587881_o.jpg)


Gabriel

Quote from: R.G. on December 13, 2015, 01:02:54 AM
I do overthink a lot of things, so it's entirely possible. Although I personally would get lost with a 16x16 LED grid after applying the two-beers rule.  :icon_biggrin: Other folks might do a lot better.

Color code the LEDs - blue for position one, red for position two, purple for three.  Or, use RGB LED's, and give each loop a color - the order of colors tells you the order of effects.  Then, you just need 16 LEDs.


Gabriel

Same idea, using the AD75019:


(https://c2.staticflickr.com/6/5648/23692858736_11f45de1a3_b.jpg) (https://c2.staticflickr.com/6/5648/23692858736_91eaa70f0f_o.jpg)


(This was put together VERY quickly - nothing tested, nothing in any way built to scale or rendered with texture, as it were.)


Gabriel

I don't make it around here much any more, but I'm glad I stumbled into this thread. I was working on something like this about two years ago but ran into the following problems...

• Not enough time to do it (biggest issue).
• Older Mitel MT88XX (http://www.microsemi.com/products/switches/analog-cross-point-switches/analog-cross-point-switches) chip (retired by Mitel, but still made by Microsemi) that only had discrete address lines, not serial interface (cheaper, though). Not really a big issue with GPIO port manipulation.
• Complexity of user interface. Was thinking of a novel preset recall system, but how do you remember onstage that "preset 12" is this specific, complex effects path?
• I thought it might have to be a drag-and-drop touch screen app, too. Or maybe an offline editor for presets stored in the pedal.
• I was looking at a lot fewer loops, but had a couple of other routing ideas. Still, the number of permutations was overwhelming. I think user research to determine what are the most usable configurations could help reign it in.

I will keep an eye on the thread. If this gets broken up into smaller tasks that other people could help out with in a team effort, I might be able to contribute (but likely not until after the holidays). I was working with a Teensy 3.1 (https://www.pjrc.com/teensy/teensy31.html) and Arduino IDE originally, but could also work on other platforms.

-- T. G. --

Quote from: G. Hoffman on December 13, 2015, 03:08:28 AM
Well, the thing that most interests me about this would be for the wet side of the wet/dry/wet rig ...  You can also have two or three series strings in parallel by skipping busses.  I'm pretty sure I'm explaining this badly, but I can see it clearly in my head!)

No, the explanation is clear enough. Ought to work if you can iron out how to control it.

QuoteThis begs the question, though - from the data sheet, it does say you can assign any and all inputs to any and all outputs, which I take to mean you can assign multiple outputs to an input (GOOD!  You would need this for parallel operation), but that means you need to sum those inputs some how.  Can you just have a summing resistor on each input, and a buffer on each output?  or is there a problem trying to sum things inside the chip?

I don't know how well summing inside the chip would work. They're fairly low resistance analog switches, so there's likely not to be so much summing as fighting. Resistor summing into a mixer would make sense.

Quote
At any rate, here is kind of the idea I was having - make of it what you will.  I think input and output busses makes it a lot more versatile.

Looks reasonable.

Quote from: tommy.genes on December 13, 2015, 12:17:50 PM
...

• Older Mitel MT88XX (http://www.microsemi.com/products/switches/analog-cross-point-switches/analog-cross-point-switches) chip (retired by Mitel, but still made by Microsemi) that only had discrete address lines, not serial interface (cheaper, though). Not really a big issue with GPIO port manipulation.
• Complexity of user interface. Was thinking of a novel preset recall system, but how do you remember onstage that "preset 12" is this specific, complex effects path?
• I thought it might have to be a drag-and-drop touch screen app, too. Or maybe an offline editor for presets stored in the pedal.
• I was looking at a lot fewer loops, but had a couple of other routing ideas. Still, the number of permutations was overwhelming. I think user research to determine what are the most usable configurations could help reign it in.

I did a similar thing with the MT88xx stuff way back when. It worked, but as you say, it was pestiferous to use.

I'm recently enamored of using an otherwise useless old laptop as a dedicated (and very capable!) peripheral. So drag and drop interfaces are probably OK to consider. So are the newly cheap touchscreens and controllers.

On the fewer loops-front, the straw design I have so far has boards to implement an in/out (which one of the 16 pairs) and three in/out loops with spaced phone jacks, and then an x4 board with four in/out phone jack loops. You could build it as an X3 (not all that fun, but maybe for some people), an X7, an X11 and an X15 loop setup by adding X4 boards to the basic in/out/X3. I put the connectors for ribbon cables on the X3 and X4 boards so you could simply widen it by plugging in a 12-position IDC cable - although soldering would be more reliable.    :icon_biggrin:  the X7 or X11 systems are probably where most of the systems would be used.

I noted that one of the side effects of a nonblocking crossbar with truly independent accesses is that you don't have to implement loops in any position particularly. The three optional X4 boards can all go to dedicated loops, and one pin on the connector can ground a pin on the interface to the controller so that the attached controller can sense how many and which loop boards are added and insert that into the programming interface without having to mess about with installing things in any particular order to any particular in/out set on the AD75019. Again - A Simple Matter Of Programming.  :icon_lol:

Quote from: R.G. on December 13, 2015, 02:59:38 PM
No, the explanation is clear enough. Ought to work if you can iron out how to control it.

Control is actually not something I'm worried about.  The Liquid Foot+ I'm using (a 12+) can use one switch to sequentially send MIDI commands, and you can set up different CC# commands to be mutually exclusive.  It's expensive, but it actually makes this kind of thing pretty straight forward.  For the most part, I'll have a switch for each device, and you press once for buss pair 1, twice for buss pair 2, etc.  I can even give each position a different colored indicator.  It's a bit more complicated for devices which are MIDI controlled, since I'll also need to send patch changes, but again, I can just set up a page of buttons for a particular effect.  Also, the way I want to set it up, it is pretty hard to do anything disastrous. 

And after all, the idea with all this MIDI stuff is to set up your sounds in the rehearsal room, and by the time you get to the stage to be pretty well programmed.

Quote from: R.G. on December 13, 2015, 02:59:38 PM
I don't know how well summing inside the chip would work. They're fairly low resistance analog switches, so there's likely not to be so much summing as fighting. Resistor summing into a mixer would make sense.

Ah, yes, well, I had intended to put a mix resistor on the return jack.  I kind of figured, given the use I have in mind for it (the wet side of a wet/dry/wet rig), everything going into it will probably have a pretty solid output gain stage (a Timeline, a Boss DD-20, etc.), so I could probably skip the input buffer.  It wouldn't be too hard to put one in, of course.


Gabriel

OK, so I bought a couple of these chips (OUCH! expensive!), and as soon as I'm done with the project on my bench I'm going to start experimenting with this thing.  I found the data sheet's description of the data input confusing, so the first thing is to play around with that, but then I'm going to try building something up on the big bread board, and this is what I've got in mind.


(https://c2.staticflickr.com/6/5765/23938619895_3f51b719d5_c.jpg) (https://c2.staticflickr.com/6/5765/23938619895_6579aaf827_o.jpg)


The values are a bit hard to read, for which I apologize, but most of those values are not really set.  Oh, and a lot of thanks to R.G. for the starting point on a lot of the blocks, particularly the transformer isolated outputs!  But, if anyone has input, I'd sure appreciate it!  (For now, I'm just going to send serial data from my PC - I'll worry about the microcontroller stuff when I've got a better idea how everything else is working.)


Gabriel

I've been dreaming up something like this for awhile now. I was planning on have 4 parallel out puts from the chip. My main hang up was how to digitally controll the the mixer
side of things. Seems most people around here don't like digi pots. I'm confused on what the benefit is to have the busses routed back in the chip and not just mix down to the outputs?

I can route things either series OR parallel, by assigning them to different locations.  For instance, if I'm using to rhythmic delays (say, a quarter note and a dotted eighth), I don't really want them feeding each other, so put them both in the same "location," and it keeps the sound a bit tighter.  But if I'm doing ambient swells, I WANT the delays to clash, so I want them in series.  Just one example of the versatility I'm after.   

Digital pots are prone to digital noise, but you can isolate them with a opto-resistor.  Just create a voltage divider with another resistor (or, if you prefer, use two optos).   I've got a tested schematic on the PC - I'll try to post sometime when I'm not on my phone.

Ok anouther question, can you not route the main/dry input to multiple loops/pedals in the chip? Or would you have to have the same # of dry inputs as out puts? By out puts I mean parallel outs from chip to a mixer curcuit, then to the actual out put. I was just going to buy the new boss es8 till I realized it could only do 2 parallel chains. Witch means that if you have stereo pedals then there are none left over for a overdrive.

You could switch the dry signal in and out through the switch, but I'm trying to make it both versatile and simple to use, so while I am planning to make the dry signal switchable on the front panel when I actually make the thing, but the way I am thinking of setting up is with the dry signal switch off for the last pair of busses, so I can (for instance) put a pre-delay on a reverb by putting the delay in the seventh location, and the reverb in the last location.



Gabriel

Just to clarify, can the matrix split the dry signal(any input at that matter)? So if I have one dry input to the matrix, can I send it to multiple out puts?

Might be of interest:

http://www.dorkbotpdx.org/blog/paul/ad75019_crosspoint_analog_switch

http://www.synthdiy.com/files/2011/45-ciarcia.pdf

Quote from: Thewoodguy on December 26, 2015, 11:29:15 AM
Just to clarify, can the matrix split the dry signal(any input at that matter)? So if I have one dry input to the matrix, can I send it to multiple out puts?

Well, I don't know that I would say anything "is", since this is very much an early stage project, but yeah.  You have eight locations, and each one has and input buss and an output buss.  You have eight loops, and each loop can be placed in a location.  If you place two loops in the same location, they are in parallel.  If you place two loops in consecutive locations, they are in series.  If you skip a location, then you're back to parallel, but you can make multiple (well, up to three) series strings which are in parallel with each other. 


Gabriel

Quote from: Hatredman on December 26, 2015, 03:17:15 PM
Might be of interest:

http://www.dorkbotpdx.org/blog/paul/ad75019_crosspoint_analog_switch

http://www.synthdiy.com/files/2011/45-ciarcia.pdf

Cool - Thanks!


Gabriel

I just did a sketch of the signal flow I was think about. I'm wondering if I need buffers on all the loops? I'm hoping to just have one that I can place anywhere in the chain.
https://www.dropbox.com/s/hp2f9f5u6inzrtv/20151227_164615.jpg?dl=0

Quote from: Hatredman on December 26, 2015, 03:17:15 PM
Might be of interest:

http://www.dorkbotpdx.org/blog/paul/ad75019_crosspoint_analog_switch

http://www.synthdiy.com/files/2011/45-ciarcia.pdf

I love that this article is over 20 years old

If you are going to run loops in parallel, you are going to need to mix those signals.  And switching a mix amp in and out is just one more thing to think about, one more complicating issue.  But for what I'm using it for, the buffers aren't a problem.


Gabriel

Quote from: G. Hoffman on December 27, 2015, 08:14:10 PM
If you are going to run loops in parallel, you are going to need to mix those signals.  And switching a mix amp in and out is just one more thing to think about, one more complicating issue.  But for what I'm using it for, the buffers aren't a problem.


Gabriel

I'm not following you, the switching of the mixer is done in the chip is it not? If I have a parallel mixer like in my drawing, all I have to do is route a chain to a out put. So... on my drawing I have 4 outputs from the matrix. If I want all my loops in series it would look like this, Input/loop1/L2.....output 1. If I want parallel loops, input/loop1/L2/Output1 and input/loop3/Output2.  Then you would have a mixer to mix your 4 outputs. If there is nothing routed to a output then it is switched off.
Does that make sense, or I'm I thinking the matrix can do something it can't?

Quote from: Thewoodguy on December 27, 2015, 09:00:33 PM
I'm not following you, the switching of the mixer is done in the chip is it not? If I have a parallel mixer like in my drawing, all I have to do is route a chain to a out put. So... on my drawing I have 4 outputs from the matrix. If I want all my loops in series it would look like this, Input/loop1/L2.....output 1. If I want parallel loops, input/loop1/L2/Output1 and input/loop3/Output2.  Then you would have a mixer to mix your 4 outputs. If there is nothing routed to a output then it is switched off.
Does that make sense, or I'm I thinking the matrix can do something it can't?

Take the red pill, Neo.  The matrix is real.  And watch for the guy with the sunglasses - he can replicate.

Quote from: amptramp on December 27, 2015, 09:53:33 PM

Quote from: Thewoodguy on December 27, 2015, 09:00:33 PM
I'm not following you, the switching of the mixer is done in the chip is it not? If I have a parallel mixer like in my drawing, all I have to do is route a chain to a out put. So... on my drawing I have 4 outputs from the matrix. If I want all my loops in series it would look like this, Input/loop1/L2.....output 1. If I want parallel loops, input/loop1/L2/Output1 and input/loop3/Output2.  Then you would have a mixer to mix your 4 outputs. If there is nothing routed to a output then it is switched off.
Does that make sense, or I'm I thinking the matrix can do something it can't?

Take the red pill, Neo.  The matrix is real.  And watch for the guy with the sunglasses - he can replicate.

I really wish I have watched those movies so I could know what you are saying. Haha. I can only assume you are telling me I don't have a clue? Probably true, just trying to learn

Quote from: amptramp on December 27, 2015, 09:53:33 PM

Take the red pill, Neo.  The matrix is real.  And watch for the guy with the sunglasses - he can replicate.

Not helpful.         They ALL wore sunglasses! 8)

Quote from: Thewoodguy on December 27, 2015, 09:00:33 PM
I'm not following you, the switching of the mixer is done in the chip is it not? If I have a parallel mixer like in my drawing, all I have to do is route a chain to a out put. So... on my drawing I have 4 outputs from the matrix. If I want all my loops in series it would look like this, Input/loop1/L2.....output 1. If I want parallel loops, input/loop1/L2/Output1 and input/loop3/Output2.  Then you would have a mixer to mix your 4 outputs. If there is nothing routed to a output then it is switched off.
Does that make sense, or I'm I thinking the matrix can do something it can't?

Ah, I think I get it.  I guess that would work (kind of blind leading the blind here - where did our adult supervision go??).  Seems complicated to me, in that you have to assign each loop both an input and an output, which is exactly what I'm trying to avoid, but hey, if it works for you, you can program it, and you've got a way to control it, go for it!


Gabriel

Quote from: G. Hoffman on December 24, 2015, 12:26:14 AMOh, and a lot of thanks to R.G. for the starting point on a lot of the blocks, particularly the transformer isolated outputs!

Wait, WHAT?

I totally missed that one.

It certainly does not hurt, electronically speaking, to have all those transformers isolating the sends.

But it DEFINETLY will hurt your wallet. Do we really need all those?

"Really need" is hard to call. Isolation is always welcome when there are lots of things which have separate power supplies and then have their signal grounds connected.

In a moderately benign setting you might get away with a servo-ed ground setup, using one opamp per output to remove the ground offsets.

Quote from: Hatredman on December 31, 2015, 04:51:09 PM

Quote from: G. Hoffman on December 24, 2015, 12:26:14 AMOh, and a lot of thanks to R.G. for the starting point on a lot of the blocks, particularly the transformer isolated outputs!

Wait, WHAT?

I totally missed that one.

It certainly does not hurt, electronically speaking, to have all those transformers isolating the sends.

But it DEFINETLY will hurt your wallet. Do we really need all those?

Well, for this I kind of threw everything at it, with the idea of making it kind of bullet-proof.  But the transformers in question are actually pretty cheap - less than $4 a pop.  Not too bad when you are already using a $30 switching chip!  Once I've actually breadboarded it and (hopefully) got it working, I'll probably try to figure out what I actually need.


Gabriel

Even though, there is a bunch of them. I have a problem with transformers. They pick up hum, distort, have limited BW, are heavy and claim a lot of PCB real estate.

So my question remains: are all of them really needed?

Yeah I would have to think that is a bit over kill

Keep in mind there are always ways around audio transformers for isolation.

You can go linear optoisolated or use RF modulation and demodulation, both of which can maintain bass performance down to or near DC.  PLL chips like the NE565 are good building blocks for an FM modulator / demodulator system.  They can be coupled by RF transformers or capacitors.  $4 transformers are going to sound like audio strangled through $4 transformers unless you happened to get a great deal on decent audio quality transformers, but the usual 600 ohm: 600 ohm audio coupling transformer cuts off above the low E string guitar frequencies and rolls off in the low harmonics of the high E string frequencies.  Decent transformers are also heavy - if you get good ones, you will have to wheel this thing around on a pallet truck.

Quote from: amptramp on January 01, 2016, 12:25:02 PM
$4 transformers are going to sound like audio strangled through $4 transformers unless you happened to get a great deal on decent audio quality transformers, but the usual 600 ohm: 600 ohm audio coupling transformer cuts off above the low E string guitar frequencies and rolls off in the low harmonics of the high E string frequencies.

Insert a big asterisk here. $4 audio transformers are going to sound like $4 transformers when used all by themselves. The limits on audio passband are almost always primary inductance and leakage inductance, with a nod to inter-wire and inter-winding capacitance. In a small, cheap audio transformer, inductance is usually the big issue, and it limits low frequency response.

To come up with better frequency response from the cheapest isolation trannies I could find, I used Xicon's $2.50 audio types. These are rated at 300Hz to 3kHz. A little measurement on them showed that the ones I got went from about 240Hz to 28kHz at -6db. There was a hump at 22kHz. The low frequency problem is classical: the primary inductance siphons off signal current from the signal source that doesn't get into the M-field in the core. For the rated source impedance, this happens at the point where the inductive reactance is equal to the source impedance. If you're living with a passive primary drive, you're stuck there.

But if you have active primary drive, you can just lower the source impedance by driving the primary with an active buffer. An opamp will do this nicely, and I got to a low frequency rolloff of about 60Hz doing this. Another scheme is to use an amplifier with a matched low frequency hump that counters the tranformer's rolloff, just boosting the low frequency content to make up for what is lost. Either of these only work until the core starts hitting saturation, but saturation is usually not an issue so much with the 1" cube stuff and guitar or line level signals. It's worth noting that this same trick, drive the lows harder to make up for low frequency rolloff, has been used to equalize woofers to much lower than their normal low frequency rolloff.  Lower source impedance has the advantage that you don't have to know the transformer's characteristics to compensate for them.

It's a trick, but it does work within its limits. Opamps are far cheaper than fancier transformers.

I'm going to order a one this week and start programing it first. Then mess with that stuff. Ahhh programming see you guys in 2 years haha

> optoisolated or use RF modulation

Less-radical techniques include differential amplifiers.

Input diff-amps are will known. Output ground-sensing amps are also possible, as R.G. mentions (http://www.diystompboxes.com/smfforum/index.php?topic=112598.msg1043069#msg1043069). .

These are problematic here because they rely on "matched" resistances, including source resistances. In guitar-land impedances are high and we we never know their real values, so we have to buffer.

> Do we really need all those?

"Sometimes"!

Consider three different cases.

1) You take/get signal from a remote location, possibly on another power system. Ground potential differences can be 100V or more. This is (should be!!) super-rare in stage-work, even up to stadium gigs, but stuff happens. It is a constant problem in long-line work, radio broadcast audio feeds and telephony in general.

2) Everything is on the "same supply" but ground and neutral are crossed. Any power load causes ~~1V AC ground difference between box "ground". This is fairly harmless to humans but clobbers audio with hum.

3) Power supply is properly connected. Ideally "ground" has ZERO current, thus zero voltage difference. However "zero" is only constrained to "safe leakage". Many-many boxes throw milli-Amps of leakage to ground. Safe to us, but 10mA times 0.1 Ohm grounding conductor resistance is 1 milliVolt of hum. As low-level guitar can be 20mV, 1mV of hum is significant, very annoying.

Working solutions backward:

3) Good diff-amp implementation can put the ground-difference 100:1 down, which may get you from "annoying" to "hardly audible". (However poor diff-amp may give less than 10:1 reduction.)

2) For Line Level signals peaking over 1 Volt, and not-large power current in grounding conductor, a good diff-amp can get hum down to "tolerable" for lower-fidelity work. In practices no diff-amp is really satisfactory, and transformers (or opto- or RF) are needed.

3) When ground differences exceed a few Volts, there is also a Safety issue for the operators on both ends. Transformers (or equiv) are required.

Note a common thread: ground differences due to ground here being different from ground over there. The First Defense for most such trouble is to put ALL your stuff on ONE power-strip. (A good one, where the ground holes grip tight and are really connected to each other.) Often you need no further gimmickry. Sometimes there's low hum and 50-cent diff-amps mitigate this.

1:1 transformers output transformers at opamp impedances can have *extreme* frequency response. Like 5Hz-400KHz. If you don't expose them to >100V ground differences. Transformers *tightly* bound to an opamp can have response much better than the $3 specs say, as R.G. (and others) have proved: make the opamp work to fight transformer flaws.

Input transformers from high source impedances are a much tougher problem.

> Do we really need all those?

Do we even want ALL those? Early audio was simple: if the butcher understood your order, all was fine. But when talking movies got fancy, and an audio path might extend through a dozen or more transformers, innocent engineers had to admit there was a problem on transients (tap-dancing was a craze). Improved transformers were much better and many-iron paths became common in fine audio. However the improvements are not cheap.

So as a rough scale-out rule-of-thumb, figure that twice as many transformers should cost at least FOUR times as much, because with twice as many in the chain each one has to be twice as good to maintain tolerable degradation. That's ideal; in today's market there is a long jump from Cheap to Good. The next step up from $3 may be $20.

That says, roughly: if a $3 part is good enough for an A/B/Y path, a 15x15 matrix with potentially 15+15 transformers in one over-wrought path needs $2,700 of transformers. This alone suggests reserving transformers for the interconnects where they are really needed.

Quote from: PRR on January 01, 2016, 05:06:08 PM
> optoisolated or use RF modulation

This alone suggests reserving transformers for the interconnects where they are really needed.

Interconnects?

Quote from: R.G. on January 01, 2016, 01:21:37 PM

Quote from: amptramp on January 01, 2016, 12:25:02 PM
$4 transformers are going to sound like audio strangled through $4 transformers unless you happened to get a great deal on decent audio quality transformers, but the usual 600 ohm: 600 ohm audio coupling transformer cuts off above the low E string guitar frequencies and rolls off in the low harmonics of the high E string frequencies.

Insert a big asterisk here. $4 audio transformers are going to sound like $4 transformers when used all by themselves. The limits on audio passband are almost always primary inductance and leakage inductance, with a nod to inter-wire and inter-winding capacitance. In a small, cheap audio transformer, inductance is usually the big issue, and it limits low frequency response.

To come up with better frequency response from the cheapest isolation trannies I could find, I used Xicon's $2.50 audio types. These are rated at 300Hz to 3kHz. A little measurement on them showed that the ones I got went from about 240Hz to 28kHz at -6db. There was a hump at 22kHz. The low frequency problem is classical: the primary inductance siphons off signal current from the signal source that doesn't get into the M-field in the core. For the rated source impedance, this happens at the point where the inductive reactance is equal to the source impedance. If you're living with a passive primary drive, you're stuck there.

But if you have active primary drive, you can just lower the source impedance by driving the primary with an active buffer. An opamp will do this nicely, and I got to a low frequency rolloff of about 60Hz doing this. Another scheme is to use an amplifier with a matched low frequency hump that counters the tranformer's rolloff, just boosting the low frequency content to make up for what is lost. Either of these only work until the core starts hitting saturation, but saturation is usually not an issue so much with the 1" cube stuff and guitar or line level signals. It's worth noting that this same trick, drive the lows harder to make up for low frequency rolloff, has been used to equalize woofers to much lower than their normal low frequency rolloff.  Lower source impedance has the advantage that you don't have to know the transformer's characteristics to compensate for them.

It's a trick, but it does work within its limits. Opamps are far cheaper than fancier transformers.

The basic block for these, as I'm sure RG noticed, came from the transformer isolated ABY box on GeoFX.  I've used them as simple transformer isolated spliters before on guitar with very good results, and I just dropped the same block in here, but with only one output, instead of two.  They really do sound surprisingly good, given the cheap transformers (which have gone up a bit in cost since RG wrote the article!), and I really like the certainty of transformer isolation when you have as many opportunities for ground loops as exist in a switcher like this. 

Gabriel

Quote from: PRR on January 01, 2016, 05:06:08 PM
1) You take/get signal from a remote location, possibly on another power system. Ground potential differences can be 100V or more. This is (should be!!) super-rare in stage-work, even up to stadium gigs, but stuff happens. It is a constant problem in long-line work, radio broadcast audio feeds and telephony in general.

2) Everything is on the "same supply" but ground and neutral are crossed. Any power load causes ~~1V AC ground difference between box "ground". This is fairly harmless to humans but clobbers audio with hum.

3) Power supply is properly connected. Ideally "ground" has ZERO current, thus zero voltage difference. However "zero" is only constrained to "safe leakage". Many-many boxes throw milli-Amps of leakage to ground. Safe to us, but 10mA times 0.1 Ohm grounding conductor resistance is 1 milliVolt of hum. As low-level guitar can be 20mV, 1mV of hum is significant, very annoying.

Power is never an issue at stadium gigs - because you bring your own power supply.  You take three phase from the venue (or, if you're having a good day, you have your own generator!), and use your own power distribution.  Separate power distros for lights, sound, and video.  It makes life really easy, unless the lighting guy wants to run his DMX line to front of house through the audio snake!!!!!

But that's the world I come from - running lights and sound in high end corporate and music venues.  Transformers are EVERYWHERE.  Granted, usually more expensive transformers, but not always.  I've killed a lot of ground loops with a $30 in-line Shure isolation transformer.  Saved my butt on a regular basis.  For a mono version of this, you're looking at 9 transformers on the sends and the output.  If you design your ground returns right on the circuit board, everything else SHOULD be fairly easy to keep quiet, but when you start messing with the outside world....

Still, if you really don't want them, just jumper across the footprints.  The op-amp driver will be plenty capable of driving any pedal you'll ever have.  Personally, I like a bit of belt and suspenders.


Gabriel

Has anybody looked at how the boss es8 is built? It would seem that it uses one of these matrix switches. I would like to open one of those up to see how they use it.
Gabriel, do you know what your price for parts on this project is up to?

Quote from: Thewoodguy on January 02, 2016, 10:52:45 AM
Has anybody looked at how the boss es8 is built? It would seem that it uses one of these matrix switches. I would like to open one of those up to see how they use it.
Gabriel, do you know what your price for parts on this project is up to?

Not exactly - most of it was stuff I have on hand already (I like to buy in bulk!).  I think the main cost is always going to be the AD75019 - at almost $30 a chip, well...

I figure, even making it with mostly SMD parts (I love SMD boards, myself!), it's going to be a pretty big board, though, so I'm thinking of making it pretty modular, and MAYBE even using a board edge connector to separate input/output boards.  In my head (which is the only place the mechanical design lives yet), it is a lot like a fully modular console - along the lines of an SSL, Neve, or API in the studio world, or the really high end Yamaha (PM4K, etc.) or Midas (XL4, etc.) analog consoles in the live world.  That way, all the repeated stuff can be made in higher quantities, and you only need to make the ones you really need.


Gabriel

Quote from: Thewoodguy on January 02, 2016, 10:52:45 AM
Has anybody looked at how the boss es8 is built? It would seem that it uses one of these matrix switches. I would like to open one of those up to see how they use it.
Gabriel, do you know what your price for parts on this project is up to?

Oh, and I'm not sure about the Boss, but I'm pretty convinced the FAMC Liquid Router is using this chip.  For $1,400 and a 6-26 week wait.  (Probably worth it, to be fair, as he does really nice work - I'm a big fan of my Liquid Foot controller - but damn pricey, and not real easy to control.)


Gabriel

Just looked in to that liquid switch. Really curious if he did that with just one 16x16. The info isn't very good on what you can do with it. It would seem he is doing summing inside the chip, seeing it has 16 loops. Unless he is using multiple/bigger chip. On the "editing" video he has, he is doing all kinds of parellel loops and crazy stuff. I would never spend 1400 on that but would love to have it!

Quote from: Thewoodguy on January 02, 2016, 04:27:05 PM
Just looked in to that liquid switch. Really curious if he did that with just one 16x16. The info isn't very good on what you can do with it. It would seem he is doing summing inside the chip, seeing it has 16 loops. Unless he is using multiple/bigger chip. On the "editing" video he has, he is doing all kinds of parellel loops and crazy stuff. I would never spend 1400 on that but would love to have it!

Well, I've never tried the Liquid Router, but the build quality of my Liquid Foot is top notch, which tends to give me a pretty good feeling about him (and I pulled it apart before I ever started using it - as one does).  His documentation isn't always great, but his forum is good, he tries REALLY hard to be responsive to any problems people have, and when people have good ideas for software updates, he incorporates them as possible. 


Gabriel

Quote from: PRR on January 01, 2016, 05:06:08 PMThis alone suggests reserving transformers for the interconnects where they are really needed.

My point exactly.

I can see it being needed at the amp outputs of the matrix, because a faulty ground on the backline can kill you.

But on the loop sends and returns, where you will not connect to the venue's systems but only to your own pedals, maybe it's overkill. On those spots maybe a ground lift switch would be cheaper and less cumbersome than a transformer.

Quote from: Hatredman on January 02, 2016, 11:05:59 PM

Quote from: PRR on January 01, 2016, 05:06:08 PMThis alone suggests reserving transformers for the interconnects where they are really needed.

My point exactly.

I can see it being needed at the amp outputs of the matrix, because a faulty ground on the backline can kill you.

But on the loop sends and returns, where you will not connect to the venue's systems but only to your own pedals, maybe it's overkill. On those spots maybe a ground lift switch would be cheaper and less cumbersome than a transformer.

Ok thanks for the clarification. But if we are going to go that far, wouldn't we be telling everyone they need them on the out put of any pedal?

(https://c2.staticflickr.com/2/1632/23900240300_59aaa8cace_z.jpg)


Bench clean, lets get started!

(I would have started a week ago, but my amp started acting up, so I had to fix that first.)



Gabriel

Keep us updated! Wish my work bench was clean like that

What socket did you get? That's one thing I'm looking for right now

Quote from: Thewoodguy on January 05, 2016, 03:10:43 PM
Keep us updated! Wish my work bench was clean like that

An hour earlier, it wasn't!  But I just finished my last project over the weekend, so it seemed like a good time.


Gabriel

It's just a generic smd socket, which I soldered onto a Schmartboard.   It was a bit of a pain to solder, but I got there in the end.

Gab. What micro controller are you planning on using?

Quote from: Thewoodguy on January 06, 2016, 10:22:29 AM
Gab. What micro controller are you planning on using?

I haven't really thought about it yet - right now I just want to see how the chip actually works, as I find the data sheet less than informative. 

Mostly, I've always used PIC16F's, and I've got a bunch of those around, so I'll probably find the smallest one I've got with both UART and SPI built in, and use that.  I'm pretty sure I've got some 28 pin 16F882 or 16F886.  I've used the 16F887 a fair bit, and they're the same data sheet, so I know it reasonably well.

I've got an Arduino, but that would mean learning a whole new thing for a project where, to be honest, the micro doesn't have a whole lot to do - receive MIDI, send out SPI, and turn on some LEDs.  Unless someone wants to do that part for me.....


Gabriel

   

Digital pots are prone to digital noise, but you can isolate them with a opto-resistor.  Just create a voltage divider with another resistor (or, if you prefer, use two optos).   I've got a tested schematic on the PC - I'll try to post sometime when I'm not on my phone.
[/quote]

Did you find this for me? [emoji4]

Quote from: Thewoodguy on January 07, 2016, 11:17:23 PM
   

Digital pots are prone to digital noise, but you can isolate them with a opto-resistor.  Just create a voltage divider with another resistor (or, if you prefer, use two optos).   I've got a tested schematic on the PC - I'll try to post sometime when I'm not on my phone.

Did you find this for me? [emoji4]
[/quote]


(https://c2.staticflickr.com/2/1458/23615571694_9b50d6edc0_z.jpg) (https://c2.staticflickr.com/2/1458/23615571694_854a3307fd_o.jpg)

(Click for a legible version.)

For the data input, the +5V goes to Pot A, the ground goes to Pot B, and pin 3 goes to the wiper.  This is actually set up to use two opto's, and two digi-pots, but you could do almost as well by replacing LD 1 with, say, a 1k resistor.  You'll loose a bit at the top of the range, but probably not enough to matter, and you can make it up on the output amplifier.


Gabriel

> (Click for a legible version.)

If U1B is wired as an earth-input amplifier, what does LD2 bring to the party?

Quote from: PRR on January 08, 2016, 11:53:47 PM
> (Click for a legible version.)

If U1B is wired as an earth-input amplifier, what does LD2 bring to the party?

LD2 is hooked up to a digital pot.  It isolates the signal from any digital noise that might get through.


Gabriel

Input of U1B is about 1 Ohm.

LD2 is unlikely to get below 100 Ohms.

Quote from: PRR on January 09, 2016, 12:45:59 AM
Input of U1B is about 1 Ohm.

LD2 is unlikely to get below 100 Ohms.

You're going to have to explain that one to me.  I'll admit, the input and output amps are taken from a Tremulus Lune, but the way I see it the input of U1B is mostly from R17, and will depend on where that is set - or am I missing something. 

I can say for sure it works as intended - i.e., MIDI control of the signals output level.  Of course, that's with both opto's in place. 

[/quote]


I can say for sure it works as intended - i.e., MIDI control of the signals output level.  Of course, that's with both opto's in place.
[/quote]
Are you using that as a midi controlled volume then?

Quote from: G. Hoffman on January 10, 2016, 04:54:50 PM

Quote from: PRR on January 09, 2016, 12:45:59 AM
Input of U1B is about 1 Ohm.

LD2 is unlikely to get below 100 Ohms.

You're going to have to explain that one to me.  I'll admit, the input and output amps are taken from a Tremulus Lune, but the way I see it the input of U1B is mostly from R17, and will depend on where that is set - or am I missing something. 

I can say for sure it works as intended - i.e., MIDI control of the signals output level.  Of course, that's with both opto's in place.

Quote from: Thewoodguy on January 12, 2016, 07:24:12 PM

You're going to have to explain that one to me.  I'll admit, the input and output amps are taken from a Tremulus Lune, but the way I see it the input of U1B is mostly from R17, and will depend on where that is set - or am I missing something. 

I can say for sure it works as intended - i.e., MIDI control of the signals output level.  Of course, that's with both opto's in place.

Yeah - the pot is from a Highly Liquid MPA - they don't sell the MPA's anymore, but have open sourced the code and the boards, so you can get the boards made and build them yourself fairly easily, assuming you have a way to program a PIC.  The boards are kind of big, in that they are through hole and not very tightly packed, so the boards are a bit pricey (from OSH Park, about $40 for three boards - yikes! - but no coding required!)


Gabriel

Quote from: G. Hoffman on January 10, 2016, 04:54:50 PM

Quote from: PRR on January 09, 2016, 12:45:59 AM
Input of U1B is about 1 Ohm.

LD2 is unlikely to get below 100 Ohms.

You're going to have to explain that one to me.  I'll admit, the input and output amps are taken from a Tremulus Lune, but the way I see it the input impedence of U1B is mostly from R17, and will depend on where that is set - or am I missing something. 

I can say for sure it works as intended - i.e., MIDI control of the signals output level.  Of course, that's with both opto's in place.

Quote from: G. Hoffman on January 07, 2016, 11:51:19 PM

(https://c2.staticflickr.com/2/1458/23615571694_9b50d6edc0_z.jpg) (https://c2.staticflickr.com/2/1458/23615571694_854a3307fd_o.jpg)

(Click for a legible version.)

For the data input, the +5V goes to Pot A, the ground goes to Pot B, and pin 3 goes to the wiper.  This is actually set up to use two opto's, and two digi-pots, but you could do almost as well by replacing LD 1 with, say, a 1k resistor.  You'll loose a bit at the top of the range, but probably not enough to matter, and you can make it up on the output amplifier.


Gabriel

Hint1: inverting opamp gain stage vs non inverting one. Basic opamp stuff. It looks like you are trying to use a typical voltage divider (3 terminal pot simulated by the LDs) and feed its wiper directly into the -IN of the opamp, which is a virtual ground point.
Hint2: biasing problems. Your opamp stages are referenced to Vbias, yet there is R23 biased to GND, serving actually no purpose (i'd put it before the C6 to keep that terminal at GND). LD2 is also referenced to GND instead of Vbias. LD2 brings actually nothing in terms of gain control. The AC signal gain of the U1B is determined by the R17/R13 ratio.

Quote from: PRR on January 08, 2016, 11:53:47 PM
...what does LD2 bring to the party?

makes the U1B's output DC bias dance? ;)

DC Bias Dance is a good band name. Or not.

Quote from: free electron on January 13, 2016, 05:04:49 AM

Hint1: inverting opamp gain stage vs non inverting one. Basic opamp stuff. It looks like you are trying to use a typical voltage divider (3 terminal pot simulated by the LDs) and feed its wiper directly into the -IN of the opamp, which is a virtual ground point.
Hint2: biasing problems. Your opamp stages are referenced to Vbias, yet there is R23 biased to GND, serving actually no purpose (i'd put it before the C6 to keep that terminal at GND). LD2 is also referenced to GND instead of Vbias. LD2 brings actually nothing in terms of gain control. The AC signal gain of the U1B is determined by the R17/R13 ratio.

Got it.  So, get rid of LD2 if I make another one!


Gabriel

Still reading the data sheet, but I may have found a MUCH easier solution!


The AD8113 (http://www.analog.com/media/en/technical-documentation/data-sheets/AD8113.pdf). 

Pros:

• Output buffers built in
• Parallel data input - I can run it directly off of a logic pin out from one of several MIDI cards - NO PROGAMING REQUIRED!!!
• Easier (for me) package (QFP instead of PLCC)
• It's supposed to have less crosstalk

Cons:

• Almost 50% more expensive
• I/O is not bidirectional

That's all I can think of so far, though I only just printed out the data sheet, but I think this could make this thing a LOT easier to make.  You just send it MIDI data!  It will take 10 MIDI logic outs, so the open source MPA (which I have) isn't quite going to work (or it would take two...), but there are other options out there.


Gabriel

Nevermind - it's a 16 to one switch - it can't do parallel routing.


Gabriel

Gain of 2.

If you patched to cascade all 16 channels, gain would be 96dB!)

Their hack for unity gain is ugly.
_______________________

It IS 16 to 16. The decode has 256 outputs (+16 for enable). It is a crossbar where any intersection can have a cross-connect.

Quote from: PRR on January 15, 2016, 01:58:28 AM
Gain of 2.

If you patched to cascade all 16 channels, gain would be 96dB!)

Their hack for unity gain is ugly.
_______________________

It IS 16 to 16. The decode has 256 outputs (+16 for enable). It is a crossbar where any intersection can have a cross-connect.

The AD8114 is a gain of 1, but still has the 16 to 1 switch, so no parallel routing, and is only +-5V analog rails. 

Which sucks.  Parallel data is so much easier to develop.


Gabriel

I'm with PRR. That AD8113 looks like it'd do parallel routing to me. Plus it also says up to +/-12V for audio applications. +/-5V is for video, so presumably the slew rate isn't fast enough for the higher voltage at video frequencies. But that's no problem for us.

It says "16x16" and "crosspoint switch matrix" all over the datasheet. What did you mean about it being 16-to-1?

(Thinking I'm missing something of what you're intending here)

Tom

Quote from: ElectricDruid on January 15, 2016, 06:31:18 AM
I'm with PRR. That AD8113 looks like it'd do parallel routing to me. Plus it also says up to +/-12V for audio applications. +/-5V is for video, so presumably the slew rate isn't fast enough for the higher voltage at video frequencies. But that's no problem for us.

It says "16x16" and "crosspoint switch matrix" all over the datasheet. What did you mean about it being 16-to-1?

(Thinking I'm missing something of what you're intending here)

Tom

Each output can only have one input.  First sentence of page 14 in the datasheet, "16 outputs, each of which can be connected to any ONE of 16 inputs."   Compare that with the Product Description of the AD75019, "Any or all of the X terminals may be programmed to connect to any or all of the Y terminals."  At least for what I have in mind, that's a deal breaker.  (I may not be great at a lot of electronics, but I GET complicated switching matrices.  This one doesn't do what I need.)

But think about the parallel logic - four pins for sixteen switches, so any time you switch on an input, you turn off that outputs connection to the other inputs.   I'm not sure if an input can be connected to multiple outputs, but the outputs are strictly one input per.   Or at least, that's how I read the datasheet. 

The +-5V device is the AD8114, which is a unity gain device.  The only one in the line designed for +-12V is the 8113, but as Paul said, gain of 2. 


Gabriel

Yeah the only thing holding me back from messing around with this is the lack of info for the code. Data sheet is terrible.

Eh gads!   The AD8114 is also $100 a piece!!!

> can be connected to any ONE of 16 inputs

Ah. You want mixing also. Misunderstood.

So, I've run into a rather frustrating problem -

I've programmed a 12F629 to output a changing control signal when ever a button is pushed. 

The problem is, what it is outputting (according to the PICkit 2 logic analyzer) isn't what is programmed, nor for that matter what the program shows when I simulate the program in MPLab X. 

So, for the data signal, the data pin needs to go high before the Serial clock pin goes high, and it must stay high until the clock pin goes low.  When all 256 bits have been transmitted, you pulse the Pclk pin.  (The Pclk needs to pulse within 5ms of the last bit being sent.)  And that is what I've programmed, and that is how it simulates, but when I actually run the program the data pin goes high correctly, but it goes low when the Sclk pin goes high, so it clocks as a zero. 

Now, I can turn all of the switches ON by pulling the data pin high on the 75019 through a 10k resistor, so I'm pretty confident I've got the clocks right, but I can't for the life of me figure out why the data pin isn't staying high!!!


Gabriel

Shot in the dark, have you turned off the comparator if the pic's got one?

Quote from: slacker on January 21, 2016, 03:22:56 AM
Shot in the dark, have you turned off the comparator if the pic's got one?

That might be it, but I've made it work by simply writing the data bit over again as I'm writing the Sclk bit.  It's kind of ugly, but it dealt with the important part, which was seeing if I understand the way the data works.  Which I'm still not sure about, but I HAVE at least managed to write data to the switch.  I've got to try setting specific switches, next, so I can see if I have ANY clue how it works!

But that's for tomorrow, as tonight, I have to sleep at least a little bit!


Gabriel

Glad you are making progress!

OK, trying to do more on a bread board was getting confusing, so I'm making a development board - basically, it has all the digital circuitry, and the AD75019, but NOT any of the analog audio stuff - no buffers, mixers, etc.  Here's the schematic (click for an almost legible version!):


(https://c2.staticflickr.com/2/1657/24188378059_b93588e5e6_z.jpg) (https://c2.staticflickr.com/2/1657/24188378059_05cd914547_o.jpg)


The LED matrix is for indication, the "Extra Switches" are for some relays I want to use, and the MIDI thru's are just there because I had extra outputs on the 75HC14.  I decided to go with a PIC16F887 so I didn't have to share to many pins, and so I could leave some room for expansion, should anyone ever want to do anything more than I do with this thing.  For instance, I'm just using the LED matrix for indication, but I had three extra pins, and it worked out they are on the SPI pins, so if someone wanted to add an LCD or something, they could do so.  The 887 also has lots of EEPROM, if someone wanted to implement a way to store patches.  I'm also pretty sure the programming will end up being pretty easy to adapt to either my "8 loops and 8 locations" design, or a "15 loops" design. 

I've designed the board (the interactive router the CERN guys added to KiCAD is a real time saver!), but if anyone has any comments on the schematic, I'd love to hear it.  This is really intended just as a firmware development board, so some of the oddities have to do with that intent (for instance, when it comes time for the final release, I won't have to swap pins 6 & 7 on port B for RC0 and RC1, but I want to be able to use my PICkit for debugging, so I need to leave RB6 & RB7 to the debugger.)

If I can find that MIDI recieve object file I wrote, once upon a time, I might actually get this thing done in a few months.  Probably not, but maybe!


Gabriel

Quote from: G. Hoffman on January 21, 2016, 03:11:25 AM
The problem is, what it is outputting isn't what is programmed

Unfortunately, it almost certainly *is* what is programmed, although it's interesting that the sim doesn't think so. However, I trust the chip more than the sim. The computer always does what it's told. In 35 years, I've only had two examples where that was not the case. One was a hardware bug on the 6502 to do with pages not wrapping correctly, and the other was more recently with the PIC 16F1788, which was released with significant bugs in the silicon.

Paste the code and we could have a look?

Tom

Quote from: ElectricDruid on January 24, 2016, 06:49:50 AM
, and the other was more recently with the PIC 16F1788, which was released with significant bugs in the silicon.

Paste the code and we could have a look?

Tom

How many hairs did you lose figuring THAT one out?   Sounds unbelievably frustrating. 

It was a throw away bit of code - I needed to populate the data registers with semi random data, so I put a "1" in the first register, then rotated it left to populate the rest.  It should have changed every time I pushed the button, because the wrap around had a remainder, but it didn't change.  I got all the other issues worked out. 

If I remember, I'll post the code, but I've already kind of moved on, and as I said, it was a bit of a throw away. 


Gabriel

I was going to try to come up with two versions of this program, one for my 8 loops/8 locations design, and one for the 15 loops/15 outputs idea that R.G. originally came up with, but I'm not sure that's going to be possible.

See, with my idea, you only need 8 MIDI cc#'s - one for each loop, and you assign it to the location based on the value of the cc#.  Since each loop can only be assigned to one location (though the locations can take any number of loops), the MIDI implementation is pretty easy.  There are only about 72 possible switch configurations, including everything off, and it only really needs 8 data registers.

For R.G.'s design, there are over a million configurations, and I'd need a CC# for each switch (256!!!!), which is more than are available.  It only needs 32 data registers, which isn't a problem, but since you want to be able to have more than one active on each column and each row, I can't think of a cleaver way to implement the MIDI CC#s.  You can't just use one CC# for each column, because then you've only got one row at a time, and even some complex system of a different switch group for each CC# value doesn't work, because you've only got 7 bits to work with and it needs a 16 bit word!  If someone else has a cleaver way to implement the MIDI part of it, let me know, but I for one am flummoxed on that one.

But my design does seem to be coming along pretty well.  Unfortunately, I'm getting hit with a bout of insomnia, and my dad is going in for a (relatively minor, but still...) brain surgery on Thursday, so I think I'm going to have to slow down for a while. 

I've got a first pass at the main loop written (the LED matrix, which is pretty simple), and I've started to write the MIDI interrupt sub-routine.  It's interrupting alright, and context saving is happening as it should (at least, in the MPLAB software simulator, which may be misleading me!), but I've no idea if I've got the USART set up right yet.  I need some hardware for that, and only just ordered the development board I designed for this project today, so I probably won't see it until the end of next week. 


Gabriel

If you want it to be only series configurations, the 15 loops version is easy to implement, by the way.  Is that what you had in mind, R.G.?

Yeah I was thinking of doing the order switching part of the looper. Save The the loop order as part of a preset. Then just recall presets with a PC. I would put it in with the foot controller, so each preset could also send out midi comands for all my other midi gear. Basically just like the boss es8 but with more parellel options

With that said if you can store different orders as presets. you could recall those presets with a program change then use the same CC to turn on and off each loop. You could do a whole bunch of coding to have just a couple cc to move a loop up or down the chain then a save to save that order. Personally I wouldn't want to do all of that with a foot controller. Better done on a screen of some sort

Well, I'm not very concerned with the user interface - I'm planning to just figure out the MIDI implementation, and let someone else take it from there.  For what I want, a foot controller should work great. 

Not sure about using patch changes.  I'm still not sure how much program memory I'm going to need, but with 32 data registers per patch, and only 256 bytes of eeprom,  you would need to either write to the program memory, or to add an external eeprom.

External eeprom was what I was thinking

OK, so the PICbaud calculator I have is telling me something completely different from what the data sheet seems to be telling me!!!


The calculator is telling me BRGH = 0, SPBRG = 7.

BUT, when I calculate it using the formula from the data sheet {SPBRG=(Fosc/Baud/64)-1}, I get {SPBRG=(4000000/31250/64)-1=1.  That's with BRGH off.

I'm going to go with what I calculated, but I wish Microchip had a convenient tool for this crap.


Gabriel

Take the blue pill, Neo, you're not ready for the matrix.

Still haven't tried anything on the hardware, but it is all simulating properly.  I've got the transmission of data to the AD79015 all set up (not sure if the order of the data is right, but that can be cleaned up later easily enough), and the main loop is good.  I've started on the MIDI reception, but I'm not done with that yet. 

Now, send any good thoughts you might have, I have to go wait for my dad to get out of his brain surgery.  It's considered routine, the surgeon is supposed to be the best, and all that, but it is still brain surgery!


Gabriel

It's not rocket science!!

Seriously, my thoughts will be with your dad, with hopes for a sweet outcome.

Quote from: PRR on January 28, 2016, 07:52:52 PM
It's not rocket science!!

Seriously, my thoughts will be with your dad, with hopes for a sweet outcome.

Everything went well, so now we just have to see about the outcome.  Fingers crossed. 


Gabriel

OK, I think I've got it.  It sims right, at least, though I still don't have the hardware to try it on.

It's got a few .asm files, all relocatable.  Happy to hear comments.  I'll put the code in separate posts.

I'm using the newest MPLAB X.  If you are not used to relocatable code, some of this might look odd (it did to me, at first, but is nice!)

Non-commercial open source license, and all that.

;**********************************************************************
;                                                                     *
;                                                                     *
;**********************************************************************
;                                                                     *
;    Filename:      AD79015_16F887_Main.asm                           *
;    Date:          14 January, 2016                                  *
;    File Version:  0.1                                               *
;                                                                     *
;    Author:        Gabriel Hoffman                                   *
;    Company:                                                         *
;                                                                     *
;                                                                     *
;**********************************************************************
;                                                                     *
;    Files required: P16F877.INC                                      *
;                                                                     *
;                                                                     *
;                                                                     *
;**********************************************************************
;                                                                     *
;Notes:     The Disco 8 is a eight location, eight loop, any order,   *
;   series/parallel effects switcher.  It is based on an Analog       *
;   Devices AD79015, controlled by a PIC16F887.  Each loop can be     *
;   assigned by to any single location by MIDI CC# command.  Each     *
;   loop has it's own CC#:                                            *
;                                                                     *
; loop 1 =   CC#0x00                                   *
; loop 2 =   CC#0x01                                   *
; loop 3 =   CC#0x02                                   *
; loop 4 =   CC#0x03                                   *
; loop 5 =   CC#0x04                                   *
; loop 6 =   CC#0x05                                   *
; loop 7 =   CC#0x06                                   *
; loop 8 =   CC#0x07                                   *
;                                                                     *
;   Each loop is assigned to a location by the data byte as follows:  *
;                                                                     *
; at 0, the loop is unassigned       *
;               at 1, the loop is assigned to location 1              *
;               at 2, the loop is assigned to location 2       *
;               at 3, the loop is assigned to location 3              *
;               at 4, the loop is assigned to location 4       *
;               at 5, the loop is assigned to location 5              *
;               at 6, the loop is assigned to location 6              *
;               at 7, the loop is assigned to location 7              *
;               at 8, the loop is assigned to location 8       *
;                                                                     *
;   The AD79015 uses syncronous serial communication.  The 16F887     *
;   transmits the 32 bytes (256 bits) on the DATA pin (RE1) with a    *
;   serial clock (RE2).  This is followed, within 5ms, by a positive  *
;   pulse of the PClk pin (RE0) to shift the data into the latches.   *
;                                                                     *
;                                                                     *
;   There are two 74HC574 latches used to control sixteen relays,     *
;   which are used to control the dry signal input to each location,  *
;   and to control the each location's output to the final output     *
;   buss.  The switches each has it's own CC#, from 0x08 - 0x17.  Any *
;   value higher than 0 turns the switch ON.                          *
;                                                                     *
;                                                                     *
;   There is an LED matrix, 8 rows high, by 8 columns wide, which     *
;   indicates which loop is in which location.  The main loop of the  *
;   program maintains the LED matrix.  PortD remains low until that   *
;   string's data is set up in PortA.  A low bit in PortA turns the   *
;   LED on.                                                                     *
;                                                                     *
;                                                                     *
;                                                                     *
;**********************************************************************

    list        p=16F887, r=dec
;Processor is PIC16F887 (p=16F887)
;Default Radix is Decimal (r=dec)
    #include    <p16f887.inc>   ; processor specific variable definitions

    errorlevel -302
    errorlevel -312
   
;*******************************************************************************
;     External routines        *
;*******************************************************************************   
    extern delay10
    extern MIDI_setup
    extern get_MIDI
    extern ser_AD79015
    extern set_SW
   
;*******************************************************************************
;     External variables        *
;*******************************************************************************
   
    extern   midi_status
    extern   midi_data_1
    extern   midi_data_2
    extern   data_reg
    extern   shift_reg
    extern   count_2
    extern   count_3
   
   
; '__CONFIG' directive is used to embed configuration data within .asm file.
; The labels following the directive are located in the respective .inc file.
; See respective data sheet for additional information on configuration word.

    __CONFIG    _CONFIG1, _DEBUG_ON & _LVP_OFF & _FCMEN_OFF & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & _MCLRE_ON & _PWRTE_OFF & _WDT_OFF & _INTRC_OSC_NOCLKOUT
    __CONFIG    _CONFIG2, _WRT_OFF & _BOR21V

   
   
   
;***** VARIABLE DEFINITIONS ******************************************

INT_VAR     UDATA_SHR   
w_temp RES     1     ; variable used for context saving
status_temp RES     1     ; variable used for context saving
temp_data RES 1

TEMP_VAR    UDATA           ; explicit address specified is not required
pclath_temp RES     1     ; variable used for context saving
fsr_temp RES 1



COUNT_VAR   UDATA

count_1 RES 1     ; LED matrix count

;*******************************************************************************
RESET_VECTOR     CODE    0x0000 ; processor reset vector
    nop
    goto    start              ; go to beginning of program

;*******************************************************************************
; Interrupt, context save, restoration, and return from interrupt       *
;*******************************************************************************
   
INTERRUPT_VECTOR    CODE    0X0004
    movwf   w_temp ;Copy W to TEMP register
    swapf   STATUS,W ;Swap status to be saved into W
;Swaps are used because they do not affect the status bits
    movwf   status_temp ;Save status to bank zero STATUS_TEMP register
    movf    PCLATH,W
    banksel pclath_temp ;save PCLATH context
    movwf   pclath_temp
    movf    FSR,W ;save FSR context
    movwf   fsr_temp
   
    btfsc   PIR1,RCIF
    pagesel get_MIDI
    call    get_MIDI
    pagesel set_SW
    call    set_SW
    pagesel ser_AD79015
    call    ser_AD79015
    pagesel $
   
   
   
    banksel pclath_temp
    movf    fsr_temp,w
    movwf   FSR
    movf    pclath_temp,w
    movwf   PCLATH
    swapf   status_temp,W ;Swap STATUS_TEMP register into W
;(sets bank to original state)
    movwf   STATUS ;Move W into STATUS register
    swapf   w_temp,F ;Swap W_TEMP
    swapf   w_temp,W ;Swap W_TEMP into W
    retfie

MAIN_PROG       CODE

start
    banksel    INTCON
    clrf    INTCON      ;disable interrupts
    banksel    OSCCON      ;bank 1
    movlw   b'01100000' ;8MHz Internal Oscillator
    movwf   OSCCON
;   btfss   OSCCON,HTS  ;is oscillator stable?
;   goto    $-1     ;no, check again
    banksel    ANSEL       ;yes, bank 3
    movlw   b'00000000' ;all ports digital I/O
    movwf   ANSEL
    movwf   ANSELH
    banksel    PORTA       ;bank 0
    clrf    PORTA       ;initialize all ports
    clrf    PORTB
    clrf    PORTC
    clrf    PORTD
    clrf    PORTE
    banksel    TRISA       ;bank 1
    movlw    b'00000000' ;ports A, B and E outputs
    movwf    TRISA
    movwf    TRISB
    movwf    TRISE
    movlw    b'10000000' ;ports C and D inputs
    movwf    TRISC
    movlw    b'00000000'
    movwf    TRISD
   
    pagesel MIDI_setup
    call    MIDI_setup
    pagesel $
   
    banksel INTCON       ;bank 0
    bsf     INTCON,GIE     ;Turn on global interrupts
    bsf     INTCON,PEIE     ;Turn on peripheral interrupts
   
       
       
       
; remaining code goes here

       
;**********************************************************************
;     MAIN LOOP       *
; This maintains the LED matrix.        *
;**********************************************************************
       
       
main_loop
    banksel midi_data_1
    movf    midi_data_1,W
    movwf   shift_reg
    banksel PORTA
    movlw   0
    movwf   PORTD
    movlw   0xff
    movwf   PORTA
    movlw   b'00000001'
    movwf   temp_data
    movlw   8
    movwf   count_1
    bankisel data_reg
    movlw   data_reg
    movwf   FSR
main_loop1       
    movf    INDF,W
    movwf   PORTA
    incf    FSR,F
    movf    temp_data,W
    rlf     temp_data,F
    bcf     temp_data,0
    movwf   PORTD
    movlw   .1
    decfsz  count_1,F
    goto    main_loop1
    goto    main_loop
   
   


   
   
   

   
   
   
   


   
   
   
   

    END                       ; directive 'end of program'


Incoming MIDI Control Change messages



;*******************************************************************************
;   MIDI inturupt routine                                                      *
;   This is designed to store the incomming MIDI data to three data registers, *
;   to be sent back to the main program.  It uses the PIC16F887, and the EUSART*
;   module.                                                                    *
;   The SETUP routine is used to set the SFR's for MIDI reception.             *
;              Baud rate =                                                                 *
;                                                                              *
;                                                                              *
;                                                                              *
;*******************************************************************************
   
   #include    <p16f887.inc>   ; processor specific variable definitions
   
   constant MIDI_Ch = .7
   
   
    errorlevel -302
    errorlevel -312
   
   global   MIDI_setup
   global   get_MIDI
   global   midi_status
   global   midi_data_1
   global   midi_data_2
   
    UDATA
midi_status RES 1     ; MIDI Data register - Status byte
midi_data_1 RES 1     ; MIDI Data register - Data Byte 1
midi_data_2 RES 1     ; MIDI Data register - Data Byte 2
MIDI_temp_data RES 1     ; Store data while working on it.
   
   




;*******************************************************************************
; MAIN PROGRAM
;*******************************************************************************

    CODE                      ; let linker place main program

MIDI_setup
    banksel TRISC ;EUSART SETUP
    bsf     TRISC,7 ;EUSART input
    banksel SPBRG ;set up EUSART for MIDI
    movlw   1 ;BAUD=31,250/sec
    movwf   SPBRG
    clrf    SPBRGH ;
    bcf     TXSTA,BRGH ;turn off BRGH bit
    banksel BAUDCTL
    bcf     BAUDCTL,BRG16 ;turn off BRG16 bot
    banksel TXSTA
    bcf     TXSTA,SYNC
    banksel RCSTA
    bsf     RCSTA,SPEN
    bcf     RCSTA,RX9 ;8 bit standard
    bsf     RCSTA,CREN
    banksel PIE1
    bsf     PIE1,RCIE
    return   
   
   
   
get_MIDI

    banksel RCREG
    movf    RCREG,W
    movwf   MIDI_temp_data
    movlw   b'10110000' ;check status, is it CC#, and MIDI Channel?
    addlw   MIDI_Ch
    subwf   MIDI_temp_data,W
    BTFSS   STATUS,Z
    return ;ignore message if wrong channel   
    movf    MIDI_temp_data,W
    movwf   midi_status ;move to status byte
    btfss   PIR1,RCIF ;check for new byte
    goto    $-1
    movf    RCREG,W ;move first data byte to register
    movwf   midi_data_1
    btfss   PIR1,RCIF ;check for last byte
    goto    $-1
    movf    RCREG,W ;move second data byte to register
    movwf   midi_data_2
    return
   
   
    END

Sending data to the AD79015



   
   
   #include    <p16f887.inc>   ; processor specific variable definitions
   
   global   ser_AD79015
   global   data_reg
   global   shift_reg
   global   count_2
   global   count_3

;************Pin Assignments****************************************************
   
    #define P_Clk PORTE,0
    #define S_Data PORTE,1
    #define S_Clk PORTE,2
    #define Extra_Clk1  PORTC,2
    #define Extra_Clk2  PORTC,6

   
;************Variables**********************************************************   

SW_DATA_VAR UDATA
data_reg RES .8     ; 32 bytes to store the data
shift_reg RES 1     ; the transmision and shift register for the 79015 data
count_2 RES 1     ; These registers are used to count down the 79015 serial data
count_3 RES 1     ; 1 counts down the bits per byte, 2 the bytes per packet   

   
   
SW_AD79015 CODE


ser_AD79015     ;sends data to the AD79015
    bankisel data_reg    
    movlw   data_reg
    movwf   FSR
    movlw   .8     ;set the limits of the switch loop
    movwf   count_2     ;outer loop

SW_loop_1
    movlw   .8     ;limits of the data register
    movwf   count_3     ;inner loop
    movf    INDF,W     ;put data in the Shift Register
    movwf   shift_reg
    incf    FSR,F     ;move to next data register
SW_loop_2
    btfsc   shift_reg,0
    goto    set_bit
    bcf     S_Data     ;clear Data bit for 0, then clock    
    call    clock_bit
    rlf     shift_reg,F
    decfsz  count_3,F
    goto    SW_loop_2
    call    SW_empty
    decfsz  count_2,F     ;check if we're done with the first half
    goto    SW_loop_1
    goto    SW_loop_4
set_bit
    bsf     S_Data     ;set Data bit for 1, then clock
    call    clock_bit
    rlf     shift_reg,F
    decfsz  count_3,F
    goto    SW_loop_2
    call    SW_empty
    decfsz  count_2,F     ;check if we're done with the first half
    goto    SW_loop_1
    goto    SW_loop_4

SW_loop_4
    bankisel data_reg    
    movlw   data_reg
    movwf   FSR
    movlw   .8     ;set the limits of the switch loop
    movwf   count_2     ;outer loop
SW_loop_4a
    call    SW_empty
    movlw   .8     ;limits of the data register
    movwf   count_3     ;inner loop
    movf    INDF,W     ;put data in the Shift Register
    movwf   shift_reg
    incf    FSR,F     ;move to next data register
SW_loop_4b
    btfsc   shift_reg,0
    goto    set_bit1
    bcf     S_Data     ;clear Data bit for 0, then clock    
    call    clock_bit
    rlf     shift_reg,F
    decfsz  count_3,F
    goto    SW_loop_4b
    decfsz  count_2,F     ;check if we're done with the first half
    goto    SW_loop_4a
    bsf     P_Clk
    nop
    nop
    nop
    nop
    bcf     P_Clk
    nop
    nop
    nop
    return
set_bit1
    bsf     S_Data     ;set Data bit for 1, then clock
    call    clock_bit
    rlf     shift_reg,F
    decfsz  count_3,F
    goto    SW_loop_4b
    decfsz  count_2,F     ;check if we're done with the first half
    goto    SW_loop_4a
    bsf     P_Clk
    nop
    nop
    nop
    nop
    bcf     P_Clk
    nop
    nop
    nop
    return
   
clock_bit   
    bsf     S_Clk
    nop
    bcf     S_Clk
    return   
   
SW_empty ;sends zeros to unused switches
    movlw   .8     ;limits of the data register
    movwf   count_3     ;inner loop
SW_loop_3a
    bcf     S_Data     ;clear Data bit for 0, then clock
    bsf     S_Clk    
    call    clock_bit
    decfsz  count_3,F
    goto    SW_loop_3a
    return   

    END

This is to interpret the incoming MIDI data and set the data registers prior to actually sending the data to the AD79015.  Frustratingly, I had to put the lookup table at an absolute address, because the linker kept putting it at like, 0xf8 on the page, and when it went to look up, it would jump back to the interrupt service routine!!!!! 


   #include    <p16f887.inc>   ; processor specific variable definitions
   
    global  set_SW
   
   
    extern  midi_status
    extern  midi_data_1
    extern  midi_data_2
    extern  data_reg

SW_INTERP CODE                  ; let linker place program

set_SW
movf    midi_data_1,W   ;is this a valid CC#
andlw   b'11111000' ;get rid of some bits
btfss   STATUS,Z
goto clear ;no
movf    midi_data_1,W   ;yes!
addlw   data_reg
movwf   FSR ;where's the data going?
movf    midi_data_2,W
pagesel lookup
call lookup
pagesel $
movwf   INDF
banksel midi_status
clear   clrf    midi_status
clrf    midi_data_1
clrf    midi_data_2
return

   
   
   
   
LOOKUP_SEC  CODE    0x0800
lookup
   
    andlw   b'00001111'     ;make sure the cc# data 2 doesn't take us off the lookup table
    addwf   PCL,1     ;convert cc# data2 to switch bit
    retlw   b'00000001'
    retlw   b'00000010'
    retlw   b'00000100'
    retlw   b'00001000'
    retlw   b'00010000'
    retlw   b'00100000'
    retlw   b'01000000'
    retlw   b'10000000'
    retlw   b'10000000'
    retlw   b'10000000'
    retlw   b'10000000'
    retlw   b'10000000'
    retlw   b'10000000'
    retlw   b'10000000'
    retlw   b'10000000'
    retlw   b'10000000'   
    END

This is NOT the final program.  There are things I just haven't bothered with - this only has one MIDI channel (7), and I haven't implemented the extra switches yet.  Those are both relatively easy, though, and I'll deal with them when I've made sure this is all working. 

Also, the AD79015 loop is ugly right now.  I branched the wrong way, and I've got one part of the code written twice because of it.  I should go back and rewrite it, and perhaps I will, but not tonight!

And if I'm honest, I hate the way I've done the MIDI loop.  I'm just leaving the thing dead for better than 400 instruction cycles while I wait for the MIDI data to come in.  There has to be a better way to do this!!!!  (It works fine, but is inelegant.  Which is about the best I can expect, given my limited programming skills, but still.)


Gabriel

Quote from: G. Hoffman on February 03, 2016, 12:59:26 AM
And if I'm honest, I hate the way I've done the MIDI loop.  I'm just leaving the thing dead for better than 400 instruction cycles while I wait for the MIDI data to come in.  There has to be a better way to do this!!!!

You need to treat each byte individually. Enter the interupt. Look at each byte, work out what it is, then act accordingly.Exit the interrupt.

In your case, if it was a status byte, it'd store it in midi_status. If it's the first data byte, it'd store it in midi_data_1, and increment a "data bytes received" counter. If it's the second data byte, store it in midi_data_2, and then call the routine. If a new status byte comes in before all the data bytes have arrived, store the status byte and reset the data bytes counter to zero.

You could add some "potential problem filtering" before that stage too. Like check whether the incoming byte is MIDI Realtime (0xF8 or above) and just exit the interrupt straight away. That way, your code will ignore MIDI Clock and Sequencer Start/Stop/Continue commands.

One problem with the way you've done it is that unfinished/broken/lost midi bytes will leave the code hanging until another message comes in, whereupon it'll be out of sync and won't work. Not every midi message is three bytes, and even if they were, bytes sometimes go missing.

HTH,
Tom

Quote from: ElectricDruid on February 04, 2016, 07:12:17 PM

Quote from: G. Hoffman on February 03, 2016, 12:59:26 AM
And if I'm honest, I hate the way I've done the MIDI loop.  I'm just leaving the thing dead for better than 400 instruction cycles while I wait for the MIDI data to come in.  There has to be a better way to do this!!!!

You need to treat each byte individually. Enter the interupt. Look at each byte, work out what it is, then act accordingly.Exit the interrupt.

In your case, if it was a status byte, it'd store it in midi_status. If it's the first data byte, it'd store it in midi_data_1, and increment a "data bytes received" counter. If it's the second data byte, store it in midi_data_2, and then call the routine. If a new status byte comes in before all the data bytes have arrived, store the status byte and reset the data bytes counter to zero.

You could add some "potential problem filtering" before that stage too. Like check whether the incoming byte is MIDI Realtime (0xF8 or above) and just exit the interrupt straight away. That way, your code will ignore MIDI Clock and Sequencer Start/Stop/Continue commands.

One problem with the way you've done it is that unfinished/broken/lost midi bytes will leave the code hanging until another message comes in, whereupon it'll be out of sync and won't work. Not every midi message is three bytes, and even if they were, bytes sometimes go missing.

HTH,
Tom

Yeah.  I kind of rushed through all this.

Good point about the real time messages and such.  I'm going to be using MIDI clock in the rig this will go in, so, YEAH!


Gabriel

What I really want to do is put together a MIDI routine that will receive and store any kind of MIDI message, so I can use it for any MIDI projects I might want to do in the future.  But then I sat down to write this, and just went, "screw it, ignore anything I don't need right now!"


Gabriel

How's this look for some pseudo-code for a (near) universal MIDI receive routine?  By checking the two Mess variables (Mess_type, and Mess_status) you can decide in your main loop if you need to service the incoming MIDI messages.  It throws out anything in the real time or system common ranges (0xF0 and above), so no system exclusive messages, and no MIDI clock or MTC either.


MIDI message routine

;variables
MIDI_temp
Note_off
Note_off_velo
Note_on
Note_on_velo
After
After_press
CC_1
CC_2
Prog_change
Chan_Touch
PItch
Pitch_2
Chan_mode
Chan_mode_2
Mess_Type        ;what kind of message are we receiving?
            ;bit7=Channel Mode
            ;bit6=Pitch Bend
            ;bit5=Channel Aftertouch
            ;bit4=Program Change
            ;bit3=CC
            ;bit2=Polyphonic Aftertouch
            ;bit1=Note on
            ;bit0=Note off

Mess_status        ;bit2=message complete
            ;bit1=second byte received
            ;bit0=status byte received

;Retrieve MIDI data from RCREG, place in MIDI_temp
;ignore System Common and System Real-Time messages
;is it a status byte?  Is it the right channel?
;yes, what type? Set bit in Mess_type, and reset Mess_status
;no, what type is incoming (check Mess_Type) go to (the right place)

(the right place) ;repeated for different Message types
;how many bits have been received? (check Mess_ status)
;place byte
;set Mess_Status byte, as appropriate
RETFIE


I think these guys are reading this topic. They've just implemented "loops in arbitrary order" with an update on their firmware. If you read the manual and look at the illustrations, their "G2 relay matrix" seems to be exactly the AD75019.

http://www.thegigrig.co.uk

Quote from: Hatredman on February 05, 2016, 09:00:31 PM
I think these guys are reading this topic. They've just implemented "loops in arbitrary order" with an update on their firmware. If you read the manual and look at the illustrations, their "G2 relay matrix" seems to be exactly the AD75019.

http://www.thegigrig.co.uk

Yeah, I saw that.  But the thing is, I can think of at least three other units out there right now which I'm 90% certain are using this chip, or at least one very similar.  The Boss ES-8, the Liquid Router A16, and the Sound Sculpture Switchblade systems.  I'm reasonably certain they got the idea from them!  And given they CAN do it with a software patch, I'd bet they've been planning it since their initial designs.


Gabriel

OK, a better MIDI receive routine.  I had to make a couple changes in other parts, but I like this routine for receiving MIDI - it can take any MIDI Message other than real time and sys-ex messages, and returns to the main routine between bytes!  As of yet, it is still dependent on a 4MhZ FOSC, but I'm going to try to come up with a formula so you can use it with any FOSC.  I haven't fully tested it with any other messages, so still some testing to do, but so far, so good.  And so far, I'm only testing it with the Sim, of course.  I should have the hardware early next week, though.


;*******************************************************************************
;  This is a better MIDI receive routine.  It takes any MIDI Message below 0xF0*
;and sends it back in a dedicated register.  Other routines can determine if   *
;there is data to be read by interogating Mess_Type and Mess_status registers. *
;*******************************************************************************    
   
   #include    <p16f887.inc>   ; processor specific variable definitions

errorlevel -302
errorlevel -312    
   

Global     Note_off   
Global     Note_on    
Global     After    
Global     CC    
Global     Prog_change
Global     Chan_Touch 
Global     Pitch    
Global     Mess_Type   
Global     Mess_status
Global     MIDI_setup
Global     get_MIDI

constant MIDI_Ch     = .7
constant Note0     = b'10000000'
constant Note1     = b'10010000'
constant Poly_touch     = b'10100000'
constant CC_stat     = b'10110000'
constant PC_stat     = b'11000000'
constant chan_touch_stat    = b'11010000'
constant pitch_stat     = b'11100000'

;variables
   
MIDI_data   UDATA    

MIDI_temp   RES 1
MIDI_temp2  RES 1
Note_off    RES 2
Note_on     RES 2
After     RES 2
CC     RES 2
Prog_change RES 1
Chan_Touch  RES 1
Pitch     RES 2
Mess_Type   RES 1 ;what kind of message are we receiving?
;bit6=Pitch Bend
;bit5=Channel Aftertouch
;bit4=Program Change
;bit3=CC
;bit2=Polyphonic Aftertouch
;bit1=Note on
;bit0=Note off

Mess_status RES 1     ;bit2=message complete
    ;bit1=second byte received
    ;bit0=status byte received

   
   

MAIN_PROG CODE                 

MIDI_setup
    banksel TRISC ;EUSART SETUP
    bsf     TRISC,7 ;EUSART input
    banksel SPBRG ;set up EUSART for MIDI
    movlw   1 ;BAUD=31,250/sec
    movwf   SPBRG
    clrf    SPBRGH
    bcf     TXSTA,BRGH ;turn off BRGH bit
    banksel BAUDCTL
    bcf     BAUDCTL,BRG16 ;turn off BRG16 bot
    banksel TXSTA
    bcf     TXSTA,SYNC
    banksel RCSTA
    bsf     RCSTA,SPEN
    bcf     RCSTA,RX9 ;8 bit standard
    bsf     RCSTA,CREN
    banksel PIE1
    bsf     PIE1,RCIE
    return   

   
get_MIDI
    banksel RCREG     ;Retrieve MIDI data from RCREG, place in MIDI_temp
    movf    RCREG,W
    movwf   MIDI_temp
    movf    MIDI_temp,W     ;ignore System Common and System Real-Time messages
    andlw   b'11110000'
    movwf   MIDI_temp2
    sublw   b'11110000'
    btfsc   STATUS,Z
    return
    btfss   MIDI_temp,7     ;is it a status byte?  Is it the right channel?
    goto    data_byte
    movf    MIDI_temp,W
    andlw   b'00001111'
    sublw   MIDI_Ch
    btfss   STATUS,Z    
    return
    movf    MIDI_temp2,W    ;yes, what type?
    sublw   Note0     ;note off
    btfsc   STATUS,Z
    goto    Note00
    movf    MIDI_temp2,W
    sublw   Note1     ;note on
    btfsc   STATUS,Z
    goto    Note11
    movf    MIDI_temp2,W
    sublw   Poly_touch     ;Polyphonic aftertouch
    btfsc   STATUS,Z
    goto    Poly_touch2
    movf    MIDI_temp2,W
    sublw   CC_stat     ;Control Change
    btfsc   STATUS,Z
    goto    CC_STATUS
    movf    MIDI_temp2,W
    sublw   PC_stat     ;Program Change
    btfsc   STATUS,Z
    goto    PC_STATUS    
    movf    MIDI_temp2,W
    sublw   chan_touch_stat ;Channel Aftertouch
    btfsc   STATUS,Z
    goto    chan_status
    movf    MIDI_temp2,w
    sublw   pitch_stat     ;Pitch Change
    btfsc   STATUS,Z
    goto    pitch_status
    return
   
   
   
;*********************status byte routines**************************************   
Note00
    bsf Mess_Type,0 ;Set bit in Mess_type, and set Mess_status
    bsf Mess_status,0
    return
   
Note11   
    bsf Mess_Type,1
    bsf Mess_status,0
    return
   
Poly_touch2   
    bsf Mess_Type,2
    bsf Mess_status,0
    return
   
CC_STATUS   
    bsf Mess_Type,3
    bsf Mess_status,0
    return
   
PC_STATUS   
    bsf Mess_Type,4
    bsf Mess_status,0
    return
   
chan_status   
    bsf Mess_Type,5
    bsf Mess_status,0
    return
   
pitch_status
    bsf Mess_Type,6
    bsf Mess_status,0
    return
   
data_byte
    ;what kind of message are we receiving?
    ;bit6=Pitch Bend
    ;bit5=Channel Aftertouch
    ;bit4=Program Change
    ;bit3=CC
    ;bit2=Polyphonic Aftertouch
    ;bit1=Note on
    ;bit0=Note off
    btfsc   Mess_Type,0     ;what type is incoming (check Mess_Type)
    goto    Note0_data     ;go to the right place.
    btfsc   Mess_Type,1
    goto    Note1_data
    btfsc   Mess_Type,2
    goto    Poly_touch_data
    btfsc   Mess_Type,3
    goto    CC_data
    btfsc   Mess_Type,4
    goto    PC_data
    btfsc   Mess_Type,5
    goto    Chan_touch_data
    btfsc   Mess_Type,6
    goto    Pitch_data
    return

   
;*************************Data bytes********************************************   
    ;how many bits have been received? (check Mess_ status)
    ;place byte
    ;set Mess_Status byte, as appropriate
    ;bit2=message complete
    ;bit1=second byte received
    ;bit0=status byte received
Note0_data
    btfsc   Mess_status,1
    goto    Note0_data2
    movf    MIDI_temp,W
    movwf   Note_off
    bsf     Mess_status,1
    return   
Note0_data2   
    movf    MIDI_temp,W
    movwf   Note_off+1
    bsf     Mess_status,2
    return
Note1_data
    btfsc   Mess_status,1
    goto    Note1_data2
    movf    MIDI_temp,W
    movwf   Note_on
    bsf     Mess_status,1
    return
Note1_data2   
    movf    MIDI_temp,W
    movwf   Note_on+1
    bsf     Mess_status,2
    return
Poly_touch_data
    btfsc   Mess_status,1
    goto    Poly_touch_data2
    movf    MIDI_temp,W
    movwf   After
    bsf     Mess_status,1
    return
Poly_touch_data2
    movf    MIDI_temp,W
    movwf   After+1
    bsf     Mess_status,2
    return
CC_data
    btfsc   Mess_status,1
    goto    CC_data2
    movf    MIDI_temp,W
    movwf   CC
    bsf     Mess_status,1
    return
CC_data2 
    movf    MIDI_temp,W
    movwf   CC+1
    bsf     Mess_status,2
    return
PC_data
    movf    MIDI_temp,W
    movwf   Prog_change
    bsf     Mess_status,1
    bsf     Mess_status,2
    return
Chan_touch_data
    movf    MIDI_temp,W
    movwf   Chan_Touch
    bsf     Mess_status,1
    bsf     Mess_status,2
    return
Pitch_data
    btfsc   Mess_status,1
    goto    Pitch_data2
    movf    MIDI_temp,W
    movwf   Pitch
    bsf     Mess_status,1
    return
Pitch_data2
    movf    MIDI_temp,W
    movwf   Pitch+1
    bsf     Mess_status,2
    return
   
    END


Gabriel

(https://c2.staticflickr.com/2/1536/24905602525_fd77b7f399_z.jpg)

HARDWARE!!!


Time to do some soldering.


Gabriel

So, here is a good piece of advice - don't try to hand solder surface mount PLCC sockets!!!!!!!


Freaking sucks.  I wrecked one of the boards removing a socket that was misaligned.  I normally LIKE soldering surface mount, but these sockets are really tough, and I wrecked my last one, so now I'm waiting.  Definitely use through hole PLCC sockets, in the future.


Gabriel

Quote from: G. Hoffman on February 06, 2016, 03:19:23 AM
OK, a better MIDI receive routine.  I had to make a couple changes in other parts, but I like this routine for receiving MIDI - it can take any MIDI Message other than real time and sys-ex messages, and returns to the main routine between bytes!  As of yet, it is still dependent on a 4MhZ FOSC, but I'm going to try to come up with a formula so you can use it with any FOSC.  I haven't fully tested it with any other messages, so still some testing to do, but so far, so good.  And so far, I'm only testing it with the Sim, of course.  I should have the hardware early next week, though.

That is massively improved! Now you're getting somewhere!

One thing that I can see straight away, though - the Sysex exclusion won't work. It'll throw away the "Start Sysex" and "End Sysex" bytes, but I can't see any flag that tells it to ignore the data in-between. You code will try to interpret Sysex data as if it were standard MIDI.

HTH,
Tom

Quote from: ElectricDruid on February 11, 2016, 04:30:52 AM

Quote from: G. Hoffman on February 06, 2016, 03:19:23 AM
OK, a better MIDI receive routine.  I had to make a couple changes in other parts, but I like this routine for receiving MIDI - it can take any MIDI Message other than real time and sys-ex messages, and returns to the main routine between bytes!  As of yet, it is still dependent on a 4MhZ FOSC, but I'm going to try to come up with a formula so you can use it with any FOSC.  I haven't fully tested it with any other messages, so still some testing to do, but so far, so good.  And so far, I'm only testing it with the Sim, of course.  I should have the hardware early next week, though.

That is massively improved! Now you're getting somewhere!

One thing that I can see straight away, though - the Sysex exclusion won't work. It'll throw away the "Start Sysex" and "End Sysex" bytes, but I can't see any flag that tells it to ignore the data in-between. You code will try to interpret Sysex data as if it were standard MIDI.

HTH,
Tom

Well, I gotta mess something up.  I'm finding it a lot easier than the last time I messed with programming, but I'm still very minimally skilled at this stuff. 

Perhaps, if there is nothing in the MIDI status byte, incoming gets ignored?   Maybe not.  I'm not sure - can sys ex interrupt other messages?  If so, I suppose I could use one of the spare bits to ignore everything until the sys ex closing byte is read. 


Gabriel

Anyone have a Mnemonic for Vss and Vdd?

A flippen QFP, too, so it is SOOOOOO easy to fix!


Gabriel

So, just a quick update - I've got the software pretty well squared away.  There is something funny happening between the data registers and the serial data to the AD75019 - it works, but every now and then, some of the data doesn't seem right.  I may just be reading the data sheet wrong, but I don't think so - switches are being turned on in a funny order in just a few situations. 

Also, the MIDI routine misfired once when I "abused" it.  I'm only going to use it with MIDI clock, and not MTC, and certainly never both, but I thought, "why not see what happens," and when I was throwing BOTH MTC and MIDI clock at it, and scrolling through CC#s at the same time, it misfired.  I'm pretty sure the problem was to do with MTC coming in while it was in the middle of processing a CC#, and the MTC data byte getting confused with one of the CC# data bytes.  I haven't been able to recreate it, and even if I could I'm not sure how I'd trace the problem.  Given I don't ever intend to use this thing with MTC, I'm not going to worry about it for the moment.


Gabriel

MIDI time code bytes aren't too bad to deal with. They're one of the things that definitely *can* interrupt anything. Even in the middle of a another typical MIDI message like a three-byte Note On. I can't remember whether Sysex can appear in the middle of other things or not. I always throw away the MIDI "active sense" byte, which can also turn up anywhere.

Anyway, since MTC can appear anywhere, *and*, significantly, only consists of single byte messages, it's best dealt with separately. I've usually had a buffer for "standard" MIDI messages, but dealt with MTC bytes in the interrupt routine and never put them into the buffer. That way, they get dealt with as quickly as possible, and they get removed from the MIDI stream which makes it easier to parse the remaining messages.

HTH,
Tom

MIDI clock has only one byte, so that's easy to throw away.  I was thinking the problem was with MIDI Time Code, which is two bytes, but according to the official spec it is not a real time message, and should be used on a dedicated MIDI port to get rid of jitter, so I'm pretty sure I'll never run into any problems with it. 

How is it going hoffman? Still working on this?

Crap. I've just read up on the AD75019 chip. There goes my spare time for the next year.  :icon_evil:

Quote from: Harold on April 01, 2016, 04:32:57 PM
Crap. I've just read up on the AD75019 chip. There goes my spare time for the next year.  :icon_evil:

And the race is on! ;)

The AD75019 chip and a PLCC44 to DIP44 socket is on it's way from China, and I've already created an outline of the code for my Arduino. I've decided to only store the engaged loops in order in two unsigned longs, so that will take 8 bytes per patch instead of 32. I may have to rethink that, as it's a bit hacky: I can only use the 1-9 digits (not 0, because '0123' will be truncated to '123'), and it's divided into a block of 9, and a block of 6 loops to store the full 15 loops.

With 1024 bytes available, I have more than enough space to store a few patches; but if I decide to be able to name the loops, that might prove too small. I could always get myself a Teensy; which I believe sports 2KiB flash ...

Anyway: I'm still thinking about the possibilities of this chip, whether or not I should add buffers to each in/output, or DC-protection caps, etc. But I like it already!  8)

Quote from: Thewoodguy on March 30, 2016, 10:39:46 PM
How is it going hoffman? Still working on this?

I've got code that is stable and only needs a few small tweaks (PIC16F887, which feels like overkill, but I'm using all the pins!), but haven't had time to bread board any of the analog circuitry.  I'm trying to get my AC30 finished - right now I just need to double check all the nodes, but an AC30 has a lot of nodes.  Then I've got this banjo neck I've got to set and finish, and a bunch of guitars to finish finishing.  Then there are all the little projects around the shop.  And new CAD/CAM to learn, and a CNC to rebuild (AGAIN!).

But I hope to find some more time once the AC30 is off the bench.



Gabriel

Oh so close, like this other thread:

http://www.diystompboxes.com/smfforum/index.php?topic=43104.0 (http://www.diystompboxes.com/smfforum/index.php?topic=43104.0)

Still this is a cool project too.  Like the one I did 20 years ago for the Ciarcia project, though I just re-purposed the switching end for something similar for a set of amps.

My software is "ready" too, and I've already started on the buffers and wiring ;)

But I am moving next week; and I have to repair my Sovtek MIG50. And build a garden shack. And paint some walls. Etc.

Oddly, I've actually been doing some layout work on this one this week.  Just some initial work on some of the basic bits - voltage regulators, relays, and the MIDI input stuff, none of the really important stuff - but I've been working on it while watching the Olympic athletics (go and watch the women's 10,000m race; I'm pretty sure it is the greatest race ever run!  8 women set nation records, and 18 set personal bests!!!!  It's amazing.)


Gabriel

Hey guys thinking of diving into this! Using an arduino as a controller, harold how far you got now?

Sent from my A0001 using Tapatalk

Quote from: craigmillard on October 29, 2016, 01:12:53 PM
Hey guys thinking of diving into this! Using an arduino as a controller, harold how far you got now?

It's nearing it's first 2-loop test!  8)

I might just do that tomorrow night ...

Quote from: Harold on October 29, 2016, 05:12:47 PM

Quote from: craigmillard on October 29, 2016, 01:12:53 PM
Hey guys thinking of diving into this! Using an arduino as a controller, harold how far you got now?

It's nearing it's first 2-loop test!  8)

I might just do that tomorrow night ...

This was a little too ambitious ;) I got as far as wiring two loops on my board. My power supply isn't ready, so I have to breadboard a voltage inverter to get the -12V needed for the buffers and AD-chip. I'll try to complete this test setup next week as I'm really anxious of the results too!

(https://lh3.googleusercontent.com/2XI0aozBV9tbIfCxx98I5EkmEimGtTe_MeRXg8bptzuOLgEMv4m2M30woIxtCJPA0sFcEgOYE8v1Sw=w1278-h959-no)

Looking good! Its the buffers im struggling to get my head around..

How are you setting up the buffers? You going to buffer in and out? What about summing effects if paralleled?

Quote from: craigmillard on October 31, 2016, 05:56:50 AM
Looking good! Its the buffers im struggling to get my head around..

How are you setting up the buffers? You going to buffer in and out? What about summing effects if paralleled?

I haven't worked out parallel returns yet, let's get the serial looping working first!

Guitar > buffer > (AD75019 > FX send jack > [external effect] > FX return jack > buffer > AD75019) * number of loops.

So I'm buffering all return signals, not the sends. Since the AD-chip is sending buffered returns, parallel sends should be no problem. Parallel returns could be sufficient to join in the switch matrix after buffering, but it's probably best to buffer the joined signal before sending that out again. The latter probably requires too much pins on the AD-chip and will limit the number of loops drastically, so I have to think that one through.

Yer thats similar to what i have in my head. Im also thinking about a second guitar input that is unbuffered fir first in chain, fuzz etc woudl take up an extra input but would be usefull..

Also thinking stereo outs so 2 pins used as dedicated outputs which are buffered maybe? That still leaves 14 loops!

As for parallel a join at the buffer should be acceptable id say. maybe each return has a cap and resistor in series which connects to the buffer on the output? something like: http://www.robertkeeley.com/manuals/Keeley_Parallel_Mixer.pdf

Not sure what could be done about the phasing of effects though...

Quote from: craigmillard on October 31, 2016, 10:42:20 AMNot sure what could be done about the phasing of effects though...

I've thought about that too. You could lead parallel signals through multiple loops before joining the other signal. That way you could send it through a phase inverter, HPF, etc.

I plan to build two units: one to experiment with, and one to use asap (which won't be any time soon! ;)).

Slight change of plans as my Orange/Matamp got delivered today! 8)

So much to do, so little time ...

I figured out a while back, I really had pretty much all the sub assembles for this already, except for the exact input and output buffers I want to use - but even there, I have something pretty close.  And of course, I have the development board I've shown here before (at least, I believe I have), so really it's just finding the time to sit down and build up the boards, and wiring all the bits together to test it.  I'm hoping to get to it as soon as possible.


Gabriel

Quote from: G. Hoffman on November 08, 2016, 01:56:40 AM
I figured out a while back, I really had pretty much all the sub assembles for this already, except for the exact input and output buffers I want to use - but even there, I have something pretty close.  And of course, I have the development board I've shown here before (at least, I believe I have), so really it's just finding the time to sit down and build up the boards, and wiring all the bits together to test it.  I'm hoping to get to it as soon as possible

Gabriel, that's exactly what I'm facing now!  ;D

I tested the AD-chip with an ULN2803 that lit up LEDs, the buffers are yet untested, the power supply is a make shift on breadboard, and the whole assembly with wires running about; and it's probably one big antenna.

I got as far as it's "ready to test" and then I decided I was too tired ;)

Quote from: Harold on November 08, 2016, 03:15:22 AM

Quote from: G. Hoffman on November 08, 2016, 01:56:40 AM
I figured out a while back, I really had pretty much all the sub assembles for this already, except for the exact input and output buffers I want to use - but even there, I have something pretty close.  And of course, I have the development board I've shown here before (at least, I believe I have), so really it's just finding the time to sit down and build up the boards, and wiring all the bits together to test it.  I'm hoping to get to it as soon as possible

Gabriel, that's exactly what I'm facing now!  ;D

I tested the AD-chip with an ULN2803 that lit up LEDs, the buffers are yet untested, the power supply is a make shift on breadboard, and the whole assembly with wires running about; and it's probably one big antenna.

I got as far as it's "ready to test" and then I decided I was too tired ;)

Yeah, I'll have to design a PS, but for now it will run on the bench supply. 

I've kind of been distracted by, well, life, and also the Deluxe Reverb transformers I had sitting in a drawer.  Mostly life, though.  It's been a shitty year.


Gabriel

Hi All,

I've been reading this thread for some time and now I'm starting to gather some parts to do some experimenting with crosspoint matrix switches. Regarding buffering.... what would be the lowest parts count/simpler buffer system? Can I use a CD4069 to build 6 buffers?

Mat

Quote from: potul on November 17, 2016, 01:17:49 PM
Hi All,

I've been reading this thread for some time and now I'm starting to gather some parts to do some experimenting with crosspoint matrix switches. Regarding buffering.... what would be the lowest parts count/simpler buffer system? Can I use a CD4069 to build 6 buffers?

Mat

I'm pretty sure that's a logic buffer, and not really appropriate for analog signals.  AMZ FX has a page about basic buffer designs - http://www.muzique.com/lab/buffers.htm (http://www.muzique.com/lab/buffers.htm).


Gabriel

I was thinking on usign it as an opamp, the same way we do for distortion pedals.
The CD4069 I have are unbuffered (I think)

Mat

Quote from: potul on November 17, 2016, 01:17:49 PM
Hi All,

I've been reading this thread for some time and now I'm starting to gather some parts to do some experimenting with crosspoint matrix switches. Regarding buffering.... what would be the lowest parts count/simpler buffer system? Can I use a CD4069 to build 6 buffers?

Mat

I just made one of these and need to make another: http://www.muzique.com/news/jfet-buffer-on-stripboard/ (http://www.muzique.com/news/jfet-buffer-on-stripboard/)

Low part count jfet buffer. Same thing, but different values and more compact vero layout. http://s76.photobucket.com/user/IvIark_2006/media/Layouts/Vero/JFETBuffer.png.html (http://s76.photobucket.com/user/IvIark_2006/media/Layouts/Vero/JFETBuffer.png.html)

I'm about to build a single chassis pedalboard that has a number of pedals built in (I have 12 built so far). I think if I were going to do something like this, I'd integrate it into that pedalboard. I'd probably use a 2-digit LED and use a microcontroller to handle the logic. I imagine I'd want it to work something like this:

You'd have an up-down buttons to set the digits on the LED. They'd indicate which "program" you wanted. A program would be a mix of inputs and outputs in a specific order.
So you'd go to the program # you want to create a setup for. There'd be a "Set Program" button that you'd press and it would turn off all the pedals. You'd then go through and active the pedals in the order you want them. The microcontroller would track the order. Then click the "Set Program" button again and that would store the pedal assignments and order.

Simply set the program number and it would active the pedals for that program in that order.

Not too far off from like a Floor Pod or something like that.

> Can I use a CD4069 to build 6 buffers?

Yes, that is the minimum hex "audio" buffer I know. But CMOS hisses, also distorts some. You need 2 caps and 2 to 4 resistors per buffer (unless you are clever/lucky and don't mind pops when switching). Six transistors is hardly more to build. Three TL072 is only a few more pins and worlds cleaner.

Thanks PRR,

this is exaclty the kind of info I was looking for. PRobably TL072/74 is the way to go.
In fact, I just realized that because I need 8 buffers, I would need two CD4069. Moving to two TL074 doesn't look much more pin counts.

I will start playing without buffers and when I have the concept working I will decide what buffer architecture to implement.

Thanks again!

Hey, just wanted to mention that I'm also thinking about changing my design from hardware switches to the AD75019. I've ordered a couple as samples from AD and I'm thinking about the board design in the meantime. The thread has been a huge help!

Cheers.

I still have a box with my test-setup somewhere ;)

Once I finish all my other projects, this will happen again! The demand of it is somewhat diminished since I bought a Boss MS-3 ...  8)

I was planning to build a project based on a switch matrix. I bought all my components and even did all the programming and simulation in arduino, but it's still waiting in a drawer. I did not have the time to put my hands on it... I have a huge backlog of projects at the moment.

I finally realized that all I really want is to put my delays in parallel (try it - SOOOO much delay, and it never gets muddy or looses definition - I love it), and everything else can easily be in the same series order all the time.  Plus, I had to start working 50 hours a week, and lost the time I needed for this project.

Gabriel

Hi guys,

Just thought I'd leave this here. I've used this board in two different setups (one floorboard, one rack) during live gigs for over two years. The only (initial) hiccup I have had with it was a stupid bad soldering connection in the floorbord. Otherwise they have been running fine. Both setups use a combination of builtin effects (gate/dist/...) and external effects (delays/ehx synth9/...).

I'm using hard-coded loopconfigurations, controlled by switches or MIDI. So that means I haven't put any thinking in a UI to change the config!

The pcb has an on-board mixer. It has no buffering, except for the input and (stereo) outputs. Should work with well-behaving pedals. It has worked for me  ;)

The connect() and update() functions are an idea I found somewhere on the net, the #defines for easier configuration are my additions.
Please note, labeling peculiarity: 'OUT' on the PCB means output of the AD75019, needs to go to the IN of the effect. Same for IN.

[edit] Forgot to add: there's some caveats left and right. If you decide to build something using this as a starting point, make sure you understand everything, or get in touch with me to make sure. [/edit]

(https://i.postimg.cc/qzrjVmtf/skema.png) (https://postimg.cc/qzrjVmtf)

(https://i.postimg.cc/ygSvBtXK/bestukking.png) (https://postimg.cc/ygSvBtXK)

(https://i.postimg.cc/4nVB0Cxb/labeling.png) (https://postimg.cc/4nVB0Cxb)

Eagle files:
https://possob.xs4all.nl/heskamp/public/ad75019_switcher1.0.brd
https://possob.xs4all.nl/heskamp/public/ad75019_switcher1.0.sch

Basic code to configure stuff:


///////////////////////////////////////////////////////////////////////
//
//   AD75019 Switch Matrix Control
//
///////////////////////////////////////////////////////////////////////

/* The first bit loaded via SIN, the serial data input, controls the switch
at the intersection of row Y15 and column X15. The next bits control the
remaining columns (down to X0) of row Y15, and are followed by the bits
for row Y14, and so on down to the data for the switch at the intersec-
tion of row Y0 and column X0. The shift register is dynamic, so
there is a minimum clock rate, specified as 20 kHz. */

// AD75019 connections
#define SCLK_PIN 13 // = SCK  = PB5 = atmega pin 19
#define SIN_PIN 11 // = MOSI = PB3 = atmega pin 17
#define PCLK_PIN 9  // = OC1A = PB1 = atmega pin 15

#define MAXPROGRAMS 8
#define NUMPROGRAMS 5 // rhythm/delay/delay+boost/special/mute

// ************ AD75019 connection definitions. Board/hardware dependent. *******

// First nibble is the input of the effect, they are connected to the Y's.
// Second nibble is the output of the effect, connected to the X.

// The first six definitions are fixed 'effects' on the board. Make sure
// that 'output only' are not used as input, and 'input only' are not used as output,
// since the other nibble of the definition is not defined! (Hm, that sounded weird) 
#define INNPUT    0x00 // The input to the Switcheroo, it's an 'effect output' only.
#define OUT_L     0x0b // OUT_L is an 'effect input' FIXME: labeling schematic. PCB is ok.
#define OUT_R     0x09 // Same for OUT_R
#define GND       0x20 // This is an 'effect output' only, can be used to ground
                       // the input of unused effects.
#define MIXER1    0x0e // Two-in-one opamp mixer block on the PCB.
#define MIXER2    0x0f // The other mixer input.
#define MIXER_OUT 0x10 // The output of the mixer.

// The rest are the connections to the headers
// If there's a need for more headers, they can be soldered to the
// AD75019 socket on the bottom of the PCB and then defined here.
#define CONN_5 0x58
#define CONN_6 0x73
#define CONN_7 0x92
#define CONN_8 0xb5
#define CONN_9 0xd4
#define CONN_A 0xf7
#define CONN_B 0xe6
#define CONN_C 0xa1
#define CONN_D 0x6c

// ************ Effect connection definitions **************************
//
// Defines what effect is connected to which header, so composing the
// programs becomes easier.
#define GATE     CONN_5
#define POST     CONN_6
#define DELAY    CONN_9
#define BOOST    CONN_7
#define HM2      CONN_8
#define SPECIAL  CONN_A
#define FEEDBCK  CONN_B
#define TAILS    CONN_C
#define FV1_FBCK CONN_D

// Globals
uint16_t      programs[NUMPROGRAMS][16];
int           activeprogram=0; // Rhythm

void connect_all() {
  memset(programs, 0, sizeof(programs)); // Empty the program memory

  // default rhythm
  connect(0, INNPUT,    HM2);
  connect(0, HM2,       GATE);
  connect(0, GATE,      MIXER1);
  connect(0, DELAY,     MIXER2);
  connect(0, MIXER_OUT, OUT_L);
  connect(0, GND,       DELAY);
  connect(0, GND,       BOOST);
  connect(0, FV1_FBCK,  TAILS);
  connect(0, TAILS,     FV1_FBCK);
 
  // delay
  connect(1, INNPUT,    HM2);
  connect(1, HM2,       GATE);
  connect(1, GATE,      DELAY);
  connect(1, GND,       MIXER1);
  connect(1, DELAY,     MIXER2);
  connect(1, MIXER_OUT, OUT_L);
  connect(1, GND,       BOOST);
  connect(1, FV1_FBCK,  FEEDBCK);
  connect(1, FEEDBCK,   FV1_FBCK);

  // delay+boost
  connect(2, INNPUT,    HM2);
  connect(2, HM2,       GATE);
  connect(2, GATE,      DELAY);
  connect(2, DELAY,     BOOST);
  connect(2, GND,       MIXER1);
  connect(2, BOOST,     MIXER2);
  connect(2, MIXER_OUT, OUT_L);
  connect(2, FV1_FBCK,  FEEDBCK);
  connect(2, FEEDBCK,   FV1_FBCK);

  // special
  connect(3, INNPUT,    HM2);
  connect(3, HM2,       GATE);
  connect(3, GATE,      SPECIAL);
  connect(3, SPECIAL,   OUT_L);
 
  // mute
  connect(4, GND,       HM2);
  connect(4, GND,       GATE);
  connect(4, GND,       MIXER1);
  connect(4, GND,       DELAY);
  connect(4, GND,       MIXER2);
  connect(4, GND,       OUT_L);
}

// Connects the output of effect 'from' to the input of effect 'to', in program 'program'
void connect(uint8_t program, uint8_t from, uint8_t to) {
  uint8_t x, y;
  // Find out correct Y and X from the effect- and hardwaredefinitions
  y = to & 0x0f;                // Lower nibble needed: mask out higher nibble
  x = from >> 4;                // Higher nibble needed: shift down to lower nibble
  programs[program][y] |= 1<<x; // Then set this bit in the program.
}

void update(uint8_t newprogram) {
  uint8_t i;
  uint16_t n, mask;
  // Clock in from highest bits to lowest
  for (i=16;--i<255;) { // Stops when uint8_t flips over
    n = programs[newprogram][i];
    for (mask = 0x8000; mask; mask >>= 1) {
      // Mask goes from bit 15 to bit 0.
      digitalWrite(SIN_PIN, (n & mask) ? HIGH : LOW);
      asm("nop"); asm("nop");
      digitalWrite(SCLK_PIN, HIGH);       
      asm("nop"); asm("nop"); asm("nop"); asm("nop");
      asm("nop"); asm("nop"); asm("nop"); asm("nop");
      digitalWrite(SCLK_PIN, LOW);         
      asm("nop"); asm("nop"); asm("nop"); asm("nop");
    }
  }
  asm("nop"); asm("nop"); asm("nop"); asm("nop");
  asm("nop"); asm("nop"); asm("nop"); asm("nop");
  digitalWrite(PCLK_PIN, LOW);               
  asm("nop"); asm("nop"); asm("nop"); asm("nop");
  asm("nop"); asm("nop"); asm("nop"); asm("nop");
  digitalWrite(PCLK_PIN, HIGH);                   
}

void setup() {
  pinMode(SCLK_PIN, OUTPUT);
  pinMode(SIN_PIN, OUTPUT);
  digitalWrite(PCLK_PIN, HIGH);
  pinMode(PCLK_PIN, OUTPUT);
  connect_all();         // Build programs
  update(activeprogram); // Set switches to default
}

void loop() {

}