lylehaze

In case anyone is interested, http://www.midibox.org/dokuwiki/doku.php?do=show&id=midiboxmixer The project is now online (with a little help from my friends);-) The documents are not static, I'll be editing things around a bit to make it as easy as possible. I welcome any suggestions on how to present the information better. Also, there are some pictures in the end of the hardware section. LyleHaze

I checked the sheet again. There are a lot of different models in the EC12 series, but all of the 3 pin packages that I saw had common in the middle, and A and B on either side. Good Luck, LyleHaze

Sounds about right. Three leads.. A, B, and Common. Phase A will be connected to Common 50% of the time Phase B will be connected to Common 50% of the time Phases A and B are 90 degrees out of phase. So... All three terminals will be shorted together 25% of the time. You can see that pattern on page 5 of the Alps datasheet. If my description matches your encoder, then it appears to be working well. Good Luck, LyleHaze

I could see using a flip-flop on each signal to divide its frequency by two. But you'd need to do each twice for divide by four, then there is the question of whether it would stay syncronized after a power cycle? A small PIC is looking better all the time. Too bad it's not going into a MIDIBox, that would make the change much easier to manage. But you knew that already. Good Luck, Lyle

I can offer a bit of information. I wrote a USB driver for class compatible interfaces, though not for Windows. To qualify as "Class Compatible", and be recognized by the built-in USB MIDI drivers, a device must identify itself as CLASS 0x01 (meaning Audio) and SUBCLASS 0x03 (meaning MIDISTREAMING) Unless both of these match, it will not be handled with the builtin USB MIDI device driver. I don't know much about windows, I avoid it as much as i can, but any decent USB sniffer should be able to give you the class and subclass of any device. Good Luck, LyleHaze

SounDuke, So Far, my own experience with Pics has been that they are pretty tough devices. I'm curious about what killed yours. 2.5 Amps is pretty high. Are you by chance switching an inductive load without proper protection? That might create a problem like you have described. If you can tell us a bit more about your project, we might be able to help solve the problem better. LyleHaze I checked the 18F452 datasheet: Operating voltage (should work properly) max 5.5 volts Absolute maximum (permanent damage at) 7.5 volts I'm willing to bet that you are exceeding something on the absolute maximum page of the datasheet. Possibly voltage, possibly current. Maybe even clamping current. More details will help. Where is all that power going?

I worked on that a bit today. It's about the "polygon" command. There's eagle help in the program, and a bit more in Google if you search "eagle polygon". Have Fun, LyleHaze

This seems like a good place to mention this. I needed to save some money when building my audio mixer. The 2 channel chips are available in DIP or SMD, but the bigger 4 channel chips are SMD only. I decided to try the "SchmartBoard EZ" prototyping boards so I could use the bigger 4 channel chips. Yeah, the "SchmartBoards" are a bit expensive, but they make soldering SMD _REALLY_ Easy. They use a harder/thicker resist layer, and the chip legs fall into the "wells" in between. It's just not possible to get the chip crooked on the board. If you're worried about trying SMD soldering, this is a really good way to start. Highly reccomended. LyleHaze

@stryd_one Check your hotmail. And please, remember that I'm new here. If you have any suggestions, I would LOVE to hear them. Thanks, LyleHaze

I've been busy with the software in the mixer. Channels are now named. Local and remote (MIDI) controls are working great. There's a cool horizonital bargraph to show level and balance settings for each channel, but I doubt it will work with all displays. I need to put Pilos Db display back in as an option. Last night I changed the response from linear to LOG. MUCH nicer feel to the controls now. Oh, and I wrote a little app for my computer that let's me create and send SysEx files to display text on the Core display, just for fun. I have built all the remaining audio buffers, and I've started on the rest of the PGA4311 boards. Now if I can just finish the boards, I'll be ready to take pictures and post everything. If anyone is waiting for the code release, just ask for it. It's definetly far enough along to share if anyone else wants to build an audio mixer. all the while listening to "Back Against the Wall" sounds great. ;-) MIOS Rocks! LyleHaze

I guess the short answer is.. Encoders can ALWAYS be turned up or down. Pots only turn until they reach the end of travel. Because my mixer can be driven with a local encoder, OR a remote console, OR by a sequencer, the use of encoders is pretty much required. Hope it helped. LyleHaze

Encoders are digital devices, Pots are analog. So connecting them is different. More importantly, Pots are absolute devices, i.e. the if you turn it full left, it stays full left until you move it again. Encoders give off signals like "I'm being turned right" or "I'm being turned left". But they have no stops or limits to their motion. Consider an encoder with a LED Ring (to show it's position). You turn the knob, and the LED ring shows you the "current position". If some outside message (like a MIDI CC#7) wants to control the same knob, the LED ring could show the changes, without needing to resort to a motorized pot. If you want the Pot position to change, you'll need to motorize it. So, in this example, it's easier to combine local (the knob) and remote (the MIDI volume command) with an encoder and LED ring, than it would be to buy, build, and operate a motorized pot or slider. Encoders usually ahve a longer usable life, too, as pots tend to get dirty and "scratchy", but that might just be my opinion. LyleHaze

I thought the Cypress AN2131 was pretty hard to get. Have you found a source for that chip? LyleHaze

You mentioned that the problem started when you connected all the boards. If you unplug all the boards the problem will probably go away(give it a few minutes to cool down). Then you could re-connect boards until the problem returns. Of course, never connect or disconnect any boards with the power on. Turn it off to make changes. That should help you to narrow it down a bit. LyleHaze

IC3 gets hot if there's too much current. Something is connected wrong, possibly plugged in backwards. Or you have too much load on the regulator. I'd grab a meter and check voltage and polarity at every chip. Good Luck, LyleHaze

That depends on the size and type of relay, and how many relays you'd like to control. Also, will your core be doing anything else? That will help determine which connectors might be free to do this with. Let's start with the hardware. There are regular relays that are controlled by a coil of wire making a magnetic pull on the contacts. We could drive one of these, but MOST of them (not all) need more than 5 volts to work. Another problem is when you turn it off, the magnetic field "breaks down" and puts an electrical spike on the driving pin, usually doing some damage to the chip or transistor driving the coil. Also, getting enough current to drive the relay will probably require some sort of driver or transistor. So do we get to choose the relay? that could solve some of these problems, but it leaves you with a hard-to-find relay type and size. The easiest way is to get a "Solid State Relay". These can be sized for most AC or DC loads, and they usually have a LED input that takes just a few volts and little current to operate. These things to all the work for you, and they isolate your MIDIBox from the nasty stuff. If you just want a few, you could drive them straight from the MIDIBox, or if you want more you could drive them from a DOUT module. A typical DOUT module has 32 outputs, I think. Multiple modules offer even more outputs to do this with. Where are you from? If you are in the US I can offer some sources for solid state relays, if you tell me what you are driving with them. AC voltage? DC? How many amps of current? Once we answer the hardware questions, driving them from MIOS should be pretty easy. :-) LyleHaze

@Reiner It says that it is "Class Compliant". That means it runs without drivers on Windows and Mac. So it depends on each OS's drivers to operate it. That should be the same as the non-advanced drivers on Edirol stuff, and the same as Behringer and most M-Audio stuff. The "Uno" originally had it's own drivers, and was changed later to the common "Class Compliant" driver, so there's two types of "Uno" out there. (I know because I bought the old one, wish I had waited) Lucky for me, since I have an odd computer that nobody writes drivers for, but we do have a class compatible driver with pretty good support. LyleHaze

Woah.. I may have missed something here. There is a big difference between using "MIDI Thru" to chain things together, and merging incoming messages in software. the "MIDI THRU" method should be very fast, as it's just copying the incoming signal back out, without even decoding it. That could offer a "thru-delay" that is as small as the optocoupler response time.(pretty darn fast) The idea of receiving messages at MIDI IN, then re-sending them on MIDI OUT is what I was discussing above, and that's why there will be more delay involved. Of course that would be necessary if you want to merge your outputs with those already in the stream.. I hope this is making sense. Anyway.. I'll go back to my corner now. LyleHaze

That depends on how much delay is acceptable. The bare minimum delay should be around 1ms per board that you are passing through, so that would be 5 ms for an event from the last board to reach the front of the chain. Mind you, that is the minimum, assuming that there is no timing overhead for other processing. Another possible problem is bandwidth by the time all six streams are connected. You'll have to collect complete messages before forwarding them, as most messages can't be "mixed together", each will have to travel as a complete packet. So this can double or triple the earlier estimate of delay, and impose greater delays as the traffic gets "thicker". All of this depends on the details of what you are combining. But if you want to shove six midi streams into a single MIDI IN port, it will have to be combined anyway. I'm not an expert, and I invite ANYONE to call me wrong or offer a new way of looking at this. Good Luck, LyleHaze

Gee, I don't know. I've been so busy with my own code, I've not yet had a chance to look at the MB64 code. The OP said it was already displaying a value, so maybe find that display code and replace it with a call to the above? I would _hope_ that the original poster was seeking to learn a technique, instead of just finding someone to do it for him... But I don't know. :-) In any case, the code will work, but It's most definetly not the best way to do this. Maybe someone will volunteer a better way. Good Luck, LyleHaze

OK, I'm not TK, but I'll take a shot at this. This may not be the best way, but it will work. So I'm guessing you have about twelve choices. The first step is to convert your 0-127 input into 0-11 for your twelve choices. We take your original value and divide by about 10.66. Since division is not easy, we'll multiply by 24, then divide by 256.(both easy to do) movf yourvalue,W ;get your starting value mullw d'24' movf PRODH,W ;now you have 0-11 in W call channame ;selects the right name call MIOS_LCD_PrintString ;and prints it Next up is to choose your label. I'm SURE there are better ways, but this works for me. ;this will select the proper name for a given channel (in W) channame movwf NameScan ;store our channel target TABLE_ADDR TEXT_CHAN_0 ;point to first name movf NameScan,F btfsc STATUS,Z ;if the channel number is Zero, return TABLE_ADDR TEXT_CHAN_1 ;point to second name dcfsnz ChanScan ;decrement the channel number. If the result is zero, return TABLE_ADDR TEXT_CHAN_2 ;point to the third name dcfsnz ChanScan ;dec the channel number. If the result is zero, return TABLE_ADDR TEXT_CHAN_3 ;point to the fourth name dcfsnz ChanScan ;dec the channel number. If the result is Zero, return TABLE_ADDR TEXT_CHAN_4 dcfsnz ChanScan ;repeat until a name is found return TABLE_ADDR TEXT_CHAN_5 dcfsnz ChanScan return TABLE_ADDR TEXT_CHAN_6 dcfsnz ChanScan return TABLE_ADDR TEXT_CHAN_7 dcfsnz ChanScan return TABLE_ADDR TEXT_CHAN_8 dcfsnz ChanScan return TABLE_ADDR TEXT_CHAN_9 dcfsnz ChanScan return TABLE_ADDR TEXT_CHAN_10 dcfsnz ChanScan return TABLE_ADDR TEXT_CHAN_11 return Finally, define the names with the string macro ;Name your channels here ;remember to change the number to the length of the new name ;the 0x04 tells where to put the text on the display TEXT_CHAN_0 STRING 8,0x04,"Whatever" TEXT_CHAN_1 STRING 3,0x04,"XVQ" TEXT_CHAN_2 STRING 3,0x04,"FU2" TEXT_CHAN_3 STRING 9,0x04,"Channel 4" TEXT_CHAN_4 STRING 9,0x04,"Channel 5" TEXT_CHAN_5 STRING 9,0x04,"Channel 6" TEXT_CHAN_6 STRING 9,0x04,"Channel 7" TEXT_CHAN_7 STRING 9,0x04,"Channel 8" TEXT_CHAN_8 STRING 9,0x04,"Channel 9" TEXT_CHAN_9 STRING 10,0x04,"Channel 10" TEXT_CHAN_10 STRING 10,0x04,"Channel 11" TEXT_CHAN_11 STRING 10,0x04,"Channel 12" Hope that helps, LyleHaze [edit] cleaned up the code just a little bit

Cimo, I'm sure it could be done. My design is just a "line mixer" with nothing but volume and balance or pan (it follows both balance and pan controls). I'm thinking that a basic EQ is just a couple low and/or high-pass filters, each with it's own level control. That shouldn't be too tough. I tried to write the controls in a way that's easy to change around. The PGA4311 does four channels, that could easily be Bass, Mid, Treble, and Main Level for a single channel. It'll take a lot more chips to get the job done though. I need to get this thing posted to the Wiki so others can play with it a bit. I finished the meter code, all I have left is a way to adjust the balance from the front panel. I'm beginning to wonder if I'm putting too much stuff on a single encoder with pushbutton. :-) I also need to finish building the boards. The first two pairs are working great, but I have parts, space, and the need for six more pairs. I guess I can post the project anyway, I'm sure it's working. I'll try to get some more documents written at work tomorrow. The text is easy, but the schematics take more time to do. I could lay out Eagle boards too, but the more I try to get done, the longer it will take. Maybe I should post what I have already and go from there. Time to sleep, LyleHaze

Looks good. The PGA chips have the same connections. There's an enable and clock that go to all, and data that goes from each chip out to the next in. I've been too tired to build boards this weekend, but I did some more work on the MIOS code. I've got two pairs built and working, and they are controlled by CC#7(Volume) and CC#8(balance) right now. The front panel encoder can also adjust them, and it sends out the same CCs to keep the controls updated. The channels are named, so when I tweak channel one it displays as "CD Player", channel two is my computer, etc.. Now I'm working on using the bottom line of the display as a stereo VU meter. I'm halfway through the display code for that. I thought about putting the project up on the WIKI, but I'm afraid I'll screw up the webpage or something. The board has been powered up and working 24/7 for over a week now. So far it's working solid and sounding sweet. Time to go to work.. Lyle

It's working. :-) I only have the first 4311 wired in yet, but today I was able to power it up and control the levels from a remote MIDI console. Sound quality is excellent. Since I'm hand-wiring everything but the core, it's going a bit slow, but it is going well. I should have it far enough along to photograph and document it within a few weeks. MIOS Rocks. LyleHaze

Thank You Sir. Got a great deal done yesterday, including first sound check. So far, the quality of the mix is very good. No audible noise, even at very high levels :-) Had I not cut myself trimming a header strip, I might be finished already. Off to search for the post you mentioned.. LyleHaze