lylehaze

At the risk of going too far off-topic, most digital pots require all connected signals to be between the supply rails of the chip. In the case of the chips you mentioned, this means the audio signals have to stay between 0 and +5 volts. Since an audio signal is AC, this means you'll have to add a DC offset before the digipot, then block the DC offset afterwards to get back to an AC signal. This is an often overlooked restriction on analog pots. You can find all of this in the device datasheet. LyleHaze

Well, yes. As I suggested above. PGA2311 can be used in the MBMixer A single PGA chip(or as many as you want) can be connected directly to a PIC core to give a really high quality volume control in 0.5 dB steps. No PWM, averaging caps or VCAs needed. All it does need is positive and negative 5 volt supplies, and the software that has been posted here. Whatever path you choose, I hope you have fun with it. LyleHaze

Basically I would like to utilise one of an FCB-1010's expression pedals to remotely control volume of an analog signal. I would be hoping for a compact solution that needs at least a midi-in, audio in & out (both 1/4"). A nice to have would be some method of selecting the midi channel in which to receive the continuous controller input. The Good News: There is a project here called "MBMixer", based on the PIC core, that can do exactly what you want. The design is tested, the software is here online... I'm too tired to look it up, but Google "MidiBox Mixer" and you'll find it. The bad news: The boards have never been produced in any quantity, so you'll have to hand-wire or design your own PCB to make it work. If you choose to hand-wire one, the PGA2311 is available in a DIP package, and will work fine with the software. In addition to that chip, you will need a Bipolar (plus and minus) 5 volt regulated supply, and you should consider an op-amp input buffer (very simple once you have the supply). The sound quality is very good, I have been using my mixer daily for years now. My first design was hand wired, the current design uses circuit boards. A newer revision was made, but never produced or released. If you decide to go in this direction, I will gladly offer my personal E-Mail address and support you with information along the way. LyleHaze edit: after reviewing the light dimmer kit you linked to.. it looks like that kit can convert knobs/foot pedals into MIDI messages, and can also convert MIDI messages into a variable voltage output, but I do not see any circuitry that would provide audio volume controls. Perhaps if you added a VCA for each audio channel, but otherwise I think you'll be missing part of what you asked for.

OK, a few more things.. I forgot to say, "Welcome!" I like the idea of separate keys on keyboard mapped to each program change. It's just easier to do that and it's more reliable for the end user. So here's another idea: Build a basic core with only MIDI IN, MIDI OUT, and two jacks for standard, cheap foot switches (like a hold pedal). These are both digital inputs, and since there's only two, you don't even need a DIN board. When foot switch One is pressed, the MIDIBox will send out whatever program changes are associated with whatever key gets pressed on the keyboard. When foot switch two is pressed, the user presses a key, then enters a program change, and these are stored in the core memory. During performances, only foots witch one is present, so there's no chance of accidentally re-programming your toy. When no foot switches are pressed, the MIDIBox does nothing. Just ideas.. it's late. LyleHaze

Sounds like it should be possible, if I understand your (rather clear) description. A few suggestions for your consideration: Use two keys, one for "forward" and the other "reverse", in case you accidentally over-advance during live performance. Have some kind of visual feedback of if and when it changes.. either LEDs or a LCD display. Also, "press one button" could easily be replaced with "press one key" if there are a few that are not being used for the performance. Whether a key or button, Google the term "switch debouncing" and give it some thought. To avoid the whole sequencing issue, if you can afford a key for each patch change, you could re-map an entire octave (or as much as you want) to program changes. Sounds like a fun, simple project. LyleHaze

If multiple cores sounds attractive, there's an idea that might help: If you pick up a GM5 board, even just the little one (not necessarily the 5X5 big board) you could connect up to 5 individual cores to that, and still have just a single USB cable to link them all to the host computer. (downside) is that the cores would not be talking to each other, just to the host computer. Also, I would NOT try to power everything from one USB cable.. (might work, but I wouldn't bet reliability on it) Still, it's not a bad place to start, maybe. Have Fun, LyleHaze

Good stuff, but I'll offer two thoughts on this: I lean more to assembler than C, but as a rule I find that assuming what the default base might be is dangerous. 0x0C will always be evaluated as the same value, but I know in ASM at least, the "default" base can be changed, and so the value of "12" might NOT always give the same value. In MPASM you can specify a value as decimal by putting a period in front of it, so ".12" will ALWAYS be the same, no matter what the default base is. I understand that you're playing in "C", but it might be worthwhile to look up how to declare a decimal base with each number to prevent it EVER being read the wrong way, by yourself or the next guy. Oh, and the other thing, either ".12" or "0x0C" will give you patch 13, not patch 12, assuming your patches are numbered starting from 1. (That 1 can be in binary, octal, decimal, or hex) Have a great day, LyleHaze:cool:

Step one: Click this LINK Step Two: Scroll down to "Documentation" Step Three: Read the owners manual.

I believe we found 2 problems in one statement.. But first, a word from our lawyers: I do not have a DOUT board in front of me, so I cannot test ANYTHING. I do not work for SmashTV, nor can I speak for him. I do not have a ULN2803 chip in front of me, just a datasheet (which you should have in front of you, as well) I am not responsible for anything I say in this forum.. In the end it's all up to you and all your fault. :) If anything I suggest results in a thermonuclear explosion, we never met. With all that said, I am a competent technician, programmer, and circuit board designer, so you can probably believe what I'm telling you, or at least try to verify it by reading the datasheet yourself. To start, you'll need to see a datasheet for a ULN2803a chip. Use google for this, and open it in another tab so you can switch back and forth from this discussion. Now if you look at the _LOGICAL_ diagram, it looks like each output is just the opposite (or inversion) of each input.. If you put in a HIGH signal, you'll get a LOW signal out. That is indicated by each buffer (triangle) having a little circle(inverter) on the output. There are also a couple diodes on each output, we'll get back to those later. Now, on to the schematic diagram of a single channel: Please notice that except for one of the diodes on output, there is no positive connection here. the input signal is referenced to ground, and the output is "sunk" to ground(NPN transistor there) when the output should be low. This is often called an "open collector" output. (google that if you care) Back to our reality: Since the signal that drives the input is coming from a chip on the DOUT board, the ULN Gnd and the Vs from the DOUT must be connected. Since the whole purpose of this chip is to provide a high current switch to GND, the ULN Gnd and the relay power supply Ground MUST be connected. So yes, based on this, You must connect the DOUT Vs, the 12 volt relay power supply GND, and ALL the ULN pin 9s together. While you're there, you should also connect all the ULN pin 10s to the relay power + line, for those output protection diodes. Does this mean there's a flaw in Smash's board design? I think the board was designed for resistors there, and the "extra" holes at pins 9 and 10 were to ALLOW a ULN to be inserted, but it's up to you to connect them as you need. That's what it looks like, anyway. BUT don't take my word for it! Study up, read the datasheet, google anything you're not sure of, or even invite Smash to read what we have talked about here. He's a real busy guy, but anything is possible. :) Or just try it, the worst you could do is blow up the Kitchen. Good Luck, and please report back with your findings! LyleHaze P.S. Practice safe science, use a fuse.

Thanks for posting more info.. more is usually better. :) If I were a betting man, I'd guess your grounds are not all connected It looks like pins 9 and 10 of each ULN need to be manually connected to GND and the positive power supply for your relays. Since the LED tests you have tried seem to pass, I think you may have a power supply connection issue. Note that the ground from the relay power supply(supplies?) MUST be firmly connected to PIN 9 of all ULNs AND to the core ground as well. Pin 10 of each ULN should be connected to the relay positive supply, NOT to the 5 volt core supply. Good Luck! LyleHaze

I can offer a suggestion or two.. You mentioned that you have 10 or 12 channels not firing out of 64. I think you probably mean 10 or 12 notes, as regular MIDI only supports a maximum of 16 channels per port. I know it sounds like a unimportant detail, but details count when trying to describe a problem to others. Based on your comments, the DOUT modules seem to be working.. can you draw a diagram showing how your ULN's, relays, DOUT connections, and power supply all connect together? even if you just detail a single note or two, that might give clues we need.. and do you have the tech details for the relays? like how much current they draw, and whether the load they are switching is powered from the same supply? Basic troubleshooting ideas: I think the regular DOUT module has outputs in groups of 8.. so can you take a single group of 8 relays and plug them in one at a time to each of the DOUT connectors? Will the relays work fine when they aren't loaded, but work less reliably when they are switching loads? What is powering the whole thing? You're not using the core regulator to supply power to the relays are you? Which core are you using? Good luck with your troubleshooting! LyleHaze

Note that this device is single-ended, and requires that all signals are between zero and Vdd. So all audio signals will have to be offset by some positive voltage, such that the most positive voltage is below VDD, and the most negative never falls below zero volts.

The XML mixer was buried deep in the miscellaneous pile. It's an early rev, and NOT as good as a real control surface, but valuable for testing and prototyping, at least. Not my proudest work, but usable. Making knob images of Cartman, Stan, and Kenny was fun. :) LyleHaze

It's all good. I don't want to "take over" your project, but I'll toss out a few ideas for you to consider. One of the unusual advantages of my mixer design is the separation of the audio handling from the controls. This offers a few cool tricks: In a live music application, the mixer can be placed backstage, and the controls located a long distance away. This gives a much easier setup, as the "snake" connecting them can be as small as a pair of MIDI cables, or better, a single CAN cable. This is much better than running all the audio up to the booth to be mixed and run back down to the stage. It also offers the advantage of allowing multiple points of control, each one being a hardware device (MB64e?), a software board like my Java XML mixer, or even a sequencer that might be linked to a bigger system. Of course, all the controls respond to remote commands so you can see what's really happening. There's a hardware cause too. The PGA update cannot be interrupted, and it already takes just a bit longer than a MIDI byte time, so I do not recommend using the same Core8 for the PGAs and a user interface. Things work better if you separate them onto different cores. Everything mentioned above is already complete. what comes next is one of the things I am working on: If you want to separate the controls from the mix deck, I suggest a simple integrator circuit on each channel input, with the resulting analog voltage being read by a PIC and transmitted. this will allow you to see the levels from any/all of the remote sites. I already wrote the display code into the XML mixer, and breadboarded a hardware circuit, but have not finished it out yet. It will create a lot of MIDI traffic. I have been watching MBNet with interest, as CAN is looking better all the time! (Great for long distance fast comms) Regarding the 8 bit resolution: MIDI supports 14 bit resolution, though most control surfaces only use 7 bits. There is no reason the whole MBMix program cannot be re-written for 14 bits of control sensitivity completely in software. The PGA chips support 0.5dB resolution.. and even at 7 bit, the combination of multiple controls results in a higher res than that. Let me say again: I don't want to take over your project. This is a DIY community. I released my code so that anyone can take it anywhere they want. Oh, re-writing MBMix for Core32 should not be a problem at all, except that I don't have a Core32, and I have very little time too. The actual program logic is very simple, and the math is too. I WILL support anyone who wants to re-write it for the Core32 in C. I lost a fingertip a few weeks ago, so I have to keep my typing in short spells. (Ouch!) Maybe better after I get all the stitches out. Have Fun, LyleHaze

Wow, I just booted into Chrome OS for the first time.. let's see how well I can post. :) Timing: Anyone who has followed my mixer project knows that things move very slowly.. So don't worry about a thing. If you need me in a hurry, just e-mail to my nick at gmail.. that account is checked at least once a day no matter what. The sound quality of the 4311.. there are a few answers I can give you. Please forgive me if I say too much, better that than not enough: As far as I know, I am the only person on the list who has actually heard my mixer. I am very "picky" about sound quality, but I'm not one of those audiophiles that spends $300 on gold speaker cables.. So it may be hard for you to decide what my opinion is worth. While static, with no levels changing, the sound quality is well beyond my ability to find fault. It really sounds transparent. When the level is jumped directly from one level to another (not quite possible with faders) the change is quite abrupt (as expected) and also excellent. While slowly fading.. the step size is as low as 0.5 dB, and there is no noticeable "zipper noise" across MOST of the range, but since the level goes through a log conversion, the steps get bigger at one end of the scale. I am considering re-writing the math to change this. The only time I hear "noise" in my audio is while dumping SysEx to re-flash the PIC.. I can hear each burst in the background. More details: the PCB layout and grounding techniques will affect sound quality more than anything else.. Version 1 was hand-wired, and sounded pretty damn good. Ver2 are the pics shown in the WIKI with the boards stacked. The "latest" Ver 3 boards have been layed out, but not fabbed yet. So if someone tells you they have heard my mixer, they are probably not quite telling the truth. "Even when cascaded"?? Two possible meanings: The digital controls are cascaded from chip to chip. This will have no effect on sound quality. The Audio path (By the way, is ALL ANALOG) is NOT cascaded in my mixer. This is one of the "unique" qualities of doing it the way I did. Allow me to explain. Assuming a "Full Audio" mixer configuration, each single input is handled by a single PGA4311 chip. the controls available APPEAR to be cascaded.. You'll have an input gain(expression), a main level control, a PAN control, and two available effects loops, each with an effects level AND a pre/post fader switch. Finally, a "master" level will affect the left and right channels across the board... Now, in a "classic" analog mixer, there would be a fader or pot for each of those controls, all cascaded however the designer intended.. and in MY mixer, the controls will APPEAR to work the same way. but in reality, the each of the four channels of the PGA chip will feed the signal DIRECTLY into Left, Right, FX1, and FX2. So all the "magic" happens in the software, combining all the various control values into a final result for each PGA channel. Result, the audio will pass through ONE PGA fader for each output stage(s). I hope that made sense, since it's one of the "cool" advantages of my design. Enough about sound quality. I am very satisfied with it, and I look forward to getting other peoples ears involved. Amp quality? The op-amps I use are simple and clean. No frills, no advertising, just a clean signal. :) Scared of SMT chips? The PGAs are easy enough to solder, but 2 channel versions are also available in DIP form if you want to experiment. you'll just need twice as many to get the job done, no changes in software. Want to play? Somewhere in there is a JAVA program that will let you design an on-screen mixing console with any knobs/buttons/graphics you wish and completely configurable MIDI options too. Whichever way you go, it might be handy for testing. :) I'll write more later, but I'm tired right now. LyleHaze P.S. Chrome OS is cool.. not quite ready for prime-time, but I didn't even install it on the HD, I just made a bootable USB flash drive.

My project has been quiet for a long time, but it IS in active service every day, and the "new" board design has not been abandoned. I would be happy to offer any info that you want. Perhaps this would be a good time for me to flowchart the math array that I wrote in PIC assembler, for the purpose of public discussion and perhaps even a C translation. I have also forked the project into a smaller, simpler device that "dead mixes" four stereo pairs with no individual levels, but then gives a PGA level control on the summed stereo output. This smaller variant has two target purposes: Folks with multiple computers and a single set of speakers, and cheap people that want to use a $30 set of 2.1 computer speakers instead of spending a few hundred on a fancy "Home Theater" set.. Oh, did I mention it is controlled by a TV remote? I DID keep the UART open for MIDI,USB, or Bluetooth stuff too. Anyway, I'll be around the house a lot for the next three days (That's unusual for me) so if there's any questions I can answer, I'll try to check in every few hours. LyleHaze

An awesome accomplishment!! Just out of curiosity, you mentioned a low data rate. How does it compare to the "normal" MIDI rate of 31250 baud? I suspect your "low" rate is significantly faster than regular MIDI. LyleHaze

Hawkeye is correct.. The "Host" takes on a bigger part of the transfer responsibility, it's a lot more than just a simple converter. There is a new standard called "USB on the Go" that allows devices to talk directly without a host in between, but we have not seen much with that yet. Another issue is driver compatibility. There is a "standard" driver for MIDI devices, but many devices come with their own private drivers. Some (like Roland/Edirol) have a switch on the interface that lets you choose one or the other. It should be a lot simpler, but sometimes it's just not. Using USB ports means that a PC user won't need a MIDI interface, but that assumes you want to connect to a PC and not between other types of musical gear. LyleHaze

Yeah, like he said.. Testing and troubleshooting are a big part of the project. And the easiest way to get it right is to first test your PC MIDI interface, then test two standard MIDI cables, then you can test and program each core individually, with the fair assumption that your interface and cables are good. It is well worth the cost of connectors to do this right. LyleHaze

OK, so I really shouldn't jump in so late in a conversation.. but I have a single observation. Based on the above quote from the first post, there may be a grounding problem after all. J1 of the (pic) core does NOT have a ground connection. It only feeds a bridge rectifier. If you are feeding DC to power the core, and you need both boards to have the same ground, it seems a better idea to connect the incoming DC to the + and - corners of the bridge, instead of using J1. If I'm wrong, please correct me.. but if I understand that quote correctly, there will always be a 1 diode drop between the two grounds, which may cause funny problems. Good Luck, LyleHaze

Designing your own interface is a tall order. Getting it working right is even tougher. If I needed the connections you are looking for, I would try to find a fast serial interface that is widely supported, has a robust physical layer, included error detection and collision management.. Sounds a lot like CAN bus. I believe there was some CAN work on the midibox already.. search around and see what you can find. Have Fun, LyleHaze

The download page is at http://www.ucapps.de/mios_download.html Please read the README.TXT carefully If all this is still too complicated, you might be better off just getting a pre-programmed chip from one of the shops that carry them. Then you can just build the core and program everything by MIDI Have Fun, LyleHaze

Unfortunately, I am at work now so I cannot attach "HappyBDay.mid" Still the good wishes are there. LyleHaze

That's great news.. Sometimes the troubleshooting will get frustrating.. but it's nice to see a light at the end of the tunnel. Have Fun, LyleHaze

That sounds right!