lylehaze

In my experience I can offer this gem of wisdom.. There is no such thing as "Idiot Proof". The idiots are much better at being stupid than we are at being smart. So, assuming that "Idiot Proof" is impossible, perhaps the best we can hope for is "Moron Resistant" :-) I use the autorouter in Eagle. I usually follow it with some manual route adjustments, but hey, it's free! Have Fun, LyleHaze

Yes, it should work. Two notes: The supply you showed is a "switching" supply. These are great for digital circuits, but may add HF noise to audio. Since this is for an MBSID, that may be a concern. The supply requires a minimum load to operate. You may need to add a dummy load across the supply to make sure you are always drawing at least the minimum amount. This is common to most switching supplies, including PC power supplies. Have Fun, LyleHaze

Good Morning, OK, so I was just showing off. If I hadn't written a MIDI file player last week, I would have been as blank as the wall in front of me. Regarding removing excess channels, that sounds like a good idea, but it's up to whatever program you are using to edit/save the MIDI file. Yes, you could do it by hand.. (remove the final MTrk and everything after it, then change the MThd track counter from 3 to 2. channels 3 and 4 are gone) BUT.. since you are handling .mid files in your PC (I hope!), it doesn't really matter yet. Regarding making NOTE_ON and NOTE_OFF execute over a period of time.. Think about this. Neither of them execute over a period of time, they are each a brief, instantaneous MOMENT in time. You need to adjust the amount of time in between them. Example: "90 3C 40" Note On, channel 1, Middle C "7F" Wait 127 "ticks" "80 3C 00" Note Off, channel 1, Middle C Will sound a middle c for a period of time. How long also depends on Tempo, and divisions, not shown here. We change it to "90 3C 40" "81 7E" delay 254 "ticks" "80 3C 00" Will sound the same note, but will hold it for twice as long. The NOTE_ON and NOTE_OFF took the same amount of time, but we doubled the delay between them. But, as mentioned before, let your sequencer do it for you! Don't try to manage MIDI files yourself. Find software like Stryd_One showed you, and you can ignore all this detail stuff. A few more suggestions: Find a sequencer that supports "A-B-A" editing. Then you can write short, separate tracks for each primitive motion (like leg B step forward) and then arrange those TRACKS repetitively for more complex actions like walking. Instead of using consecutive notes for related actions, choose a group of notes that are within a musical scale and key. That will make "listening" to your compositions much more tolerable. The website that I pointed you towards (Jeff Glatts site) has absolutely ALL the information I have presented, and a lot more. Finally, if you want to see the C code for a MIDI file player, I can offer mine, but you won't be able to compile it unless you have an AmigaOne with OS4. The chances of that are about 0.0001%. Otherwise you can just see one way of parsing the data.. BUT YOU SHOULDN'T NEED TO BOTHER!! Have Fun, LyleHaze

OK, I have a few monutes, I'll try to show off a bit.. 0000: 4D 54 68 64 00 00 00 06 00 01 00 03 02 D0 4D 54 MThd..........MT 0010: 72 6B 00 00 00 0B 00 FF 51 03 07 A1 20 00 FF 2F rk......Q... ../ 0020: 00 4D 54 72 6B 00 00 00 33 00 B0 07 7F 00 C0 18 .MTrk...3....... 0030: 00 B0 65 00 00 B0 64 00 00 B0 06 18 00 B1 07 7F ..e...d......... 0040: 00 C1 18 00 B1 65 00 00 B1 64 00 00 B1 06 18 00 .....e...d...... 0050: 90 30 68 96 40 80 30 00 00 FF 2F 00 4D 54 72 6B .0h.@.0.../.MTrk 0060: 00 00 00 2A 00 B2 07 7F 00 C2 21 00 B2 65 00 00 ...*......!..e.. 0070: B2 64 00 00 B2 06 18 00 B3 07 7F 00 C3 21 00 B3 .d...........!.. 0080: 65 00 00 B3 64 00 00 B3 06 18 00 FF 2F 00 e...d......./. OK. I have a few minutes, and the format should be fresh in my mind. Let's see how much I remember. MIDI files are divided into chunks. the two "official" chunk types are MThd at the head of the file and MTrk at the beginning of each track. Your file starts with "MThd 00 00 00 06", this is the header chunk, and always has a length of six, as shown. Following that are six bytes, representing three SHORT numbers. "00 01" is format 1 (multitrack), "00 03" is track count, three tracks should follow. "02 D0" is the divisor, indicating 720 "ticks" per quarter note. Next is the first track. Like all tracks, it begins with the MTrk chunk header, followed by a LONG length. In this case, this first track has a length of "0B" (11) Following this will be a variable-length time delay, then a MIDI event, then time delay, then event et-cetera until the track is finished. In this case, delay 0, then Meta-Event "FF 51 03 07 A1 20", which is NOT a MIDI event, it just instructs the sequencer to set the tempo to "07 A1 20" microseconds per quarter-note. In this case, 07a120 is 500000, so we get a tempo of 120 BPM. Then we get another delay of zero, and "FF 2F 00" which marks the end of track. On to the next track.. MTrk header, track length will be 33(51). Delay zero, then event "B0 07 7F" which is control change, channel 1 Volume to MAX. then delay 0, then "C0 18" which will send a program change, channel 1, to the 24th patch. delay zero again, then "B0 65 00" which will send Control Change, channel one, Portamento OFF. Then delay of zero again, and "B0 64 00" Control change, channel 1, Hold pedal OFF. then delay zero again, and "B0 06 18" setting channel 1 data entry slider(coarse) to 24.(why??) The next groups, without any delays will send all the same to channel two. "00 B1 07 7F 00 C1 18 00 B1 65 00 00 B1 64 00 00 B1 06 18 00" Then we get on to "90 30 68" which sends NOTE ON, channel 1, the 48th note, velocity 104. Then we have "96 40" which is a delay of 2880 "midi ticks" (remember, all delay values may be variable-length) That should be one whole-note long unless I screwed up the math.(720 from the file header = 1 quarter-note, so 2880 is a whole note) Then comes an "80 30 00" which will turn the previous note on channel 1 OFF. then a delay of zero, and the "FF 2F 00" end of track marker. On to the third track. (Ugh, getting tired!) standard track header, track length will be 42 bytes. delay zero, "B2 07 7F" channel 3 volume max. "C2 21" channel 3 program change 33, "B2 65 00" channel 3 Portamento OFF, "B2 64 00" Channel 3 hold pedal OFF, "B2 06 18" Channel 3 Data slider (coarse) at 24. Then "B3 07 7F 00 C3 21 00 B3 65 00 00 B3 64 00 00 B3 06 18 00" does much the same for channel 4. Finally, FF 2F 00 ends the track. There is a lot in this that is not needed to play a single note. It's doing basic setup for channels 1-4. This is nice, but a lot more than you need. Also, you can see that the length of a note is not encoded in the note-on message, but in the time that passes between the note-on and the note off. Have Fun,. LyleHaze Interesting.. I wonder how many Format 1 MIDI files have multiple channels of data in a single track? I wonder how many players assume that all events in a single track are the same channel? I have at least one sequencer here that makes this mistake. Among other things, it puts the drums into the wrong channel for playback. I learned something today! No wonder I'm so tired. :-)

Sounds like a lot of fun. It also sounds like two separate projects (at least) The MIDIBox usually deals with a live stream of MIDI data.We have all of MIOS to handle the data easily, and using it to control 12 valves or solenoids would be a breeze (that's a pneumatic joke). To control (and experiment) with your robot, you could use any sequencer on any platform. All the editing facilities of that sequencer would be at your disposal. Just a 2 wire MIDI cable would tether your data stream into your little Frankenstein. A second cable could give a stream of sensor data in return. Everything I have described so far is easily available, and not that hard to do. You will note, however, that no mention has yet been made of .mid files, or the MIDI file format. See, everything so far has been "live" MIDI streams. The sequencer is in your PC. IF you want to write a MIDI file player, great! If you want to do it inside the MIDIBox, you'd probably best stick with Format 0. Formats 1 and 2 require buffer space for each track that would quickly exceed what is available in most MIDIBoxes. Format zero is manageable as a single track. You'll need some way of getting the .mid files into the MIDIBox. At this time, you'll probably need a bankstick to do that. There is something easier in the future, but it's not yet ready for release. ;-) Even if you write a MIDI file player, that still doesn't offer easy editing. You'll still need software on a PC to do that. Hopefully this has helped to explain the difference between what you are asking and what we seem to be hearing. Still want to write a MIDI file player? you'll find all the information you need on the MIDI file format at http://home.roadrunner.com/~jgglatt/ You'll also find info there on MIDI commands (not the same as the file format!) Based solely on information at that site, I was able to write a Format 0 MIDI file player in 2 days. In 2 more, I expanded it to support format 1, but none of this was in a MIDIBox. That would be a different challenge altogether. Format zero playback in a MIDIBox can be done(and might have been done already), but I don't have any need for that. The PC MIDI file player I wrote last week is written in "C", but "C" for a PC and "C" for a single chip processor like the MIDIBox are NOT the same language. I hope this helped. Have Fun, LyleHaze p.s. You mentioned that "the length of the note controls the rate at which the valve pressurizes the piston". Two thoughts: You will need proportional control valves. These are neither common nor easy to control, especially since air is not at a constant volume, you will at best be controlling pressure, not position. Assuming you have the means to work with those limitations, you would be far better off using note velocity instead of duration, as velocity is available at the moment the note is struck, but you won't learn the duration of the note until it has ended.

Sometimes Snail-Mail is the only way. I'm glad it worked. Thanks Jeff! Lyle

A valuable website for all things MIDI recently disappeared. I was unable to reach the name by E-mail, so I did a web search and tried writing some snail-mail. I was lucky to reach him, and he has asked that I pass the NEW address of the "MIDI Fanatics Technical Brainwashing Center" along to all my friends. SO if you want any info on MIDI the MIDI protocol, the MIDI file format, MIDI interfaces, or whatever. Here we are again! http://home.roadrunner.com/~jgglatt/ Website is compliments of Jeff Glatt. Enjoy, LyleHaze

Chuck: There's a link to chat at the top of the page. I feel your pain on 1U size. I remember trying to fit a VFD display in mine. VERY tight, but it worked. Control surface: I suggested keeping it separate and MIDI based, as people have different needs, and there are great resources here already for custom designed boards. DAMN! I was linking to the MIDI brainwashing center in the documents I'm writing now. I hope it's not permanently lost. LyleHaze

Very Cool. Off topic, but maybe useful? I am very close to releasing V2 of the MBMix software. I see that the interface is similar for both chips. Everything I have is written in asm for MPLAB, but I'd be happy to donate it if you think it may be useful. The method I used separates the controls from the application, using two tables. One of midi controls, and a resulting "table" of data to transmit. so you could "lift" half the code and be running quickly, then just replace the MIDI controls as you define them for your app. I suppose if I knew exactly how your controls were defined, even more of the code might be useful for you. Anyway, code available on request. Or not if you'd rather not. All I have left to add is 64 banks of preset values and I'll be complete for my own project. (I'm about halfway done with that) Sorry if this is deemed "off topic".. LyleHaze

tilted, Thanks, I needed a good laugh this morning. I wonder what happens if you drop a PIC chip in a 2 liter bottle of diet coke? Back to writing documents.. LyleHaze

Oops, sorry if I confused anyone. I'm so old I can't "C" anymore, I'm just an asm kind of guy. Now if I could get that newfangled compiler ported to OS4, I might be willing to leave MPLAB behind.. Still, no matter your language, it's a good idea to read the processor-specific includes to better understand what you're playing with. But these are just the ramblings of an old man. :-) LyleHaze

The definitions for PORTx, LATx, and TRISx are in the PIC header files for that chip. In my case P18F452.inc. Those are from MicroChip, the PIC maker. How MIOS has assigned them further would be somewhere else. :-) Sorry, I'm too tired after reading stryd_ones response. LyleHaze

You might want to include the LCD during design and testing, and leave it off for the final rev. It is very handy for seeing what you are doing. LyleHaze

Yes, that would work.. There is a larger project afoot here at http://www.midibox.org/forum/index.php/topic,11262.0.html or you might just go at it yourself. I have an old book here titled "Electronic Projects for Musicians" by Craig Anderton that details making an effects switcher using 4066 chips. All the methods mentioned are possible, and a few more, I'm sure. Have Fun, LyleHaze

Maybe they'd be more popular if someone would breed them into the team colors of local sports teams. "Go Red Wings"!! or something like that. :-) LyleHaze

I think the challenge of adding a bit LED matrix to the EDrum is one of timing.The EDrum is scanning a lot of analog inputs, and it has to do it fast. It is also managing (of course) MIDI transmission and the display. Anything that delays it further might be come with a cost in response time. By monitoring the MIDI out from the EDrum and using a MIDIBox to manage the LEDs, you are assured that your "shiny stuff" is not costing you any timing delays. It also makes the project portable to any other MIDI instruments. Just my two cents. And probably that's about what my thoughts are worth! :-) LyleHaze

Yes indeed. Every "NOTE_ON" message includes: A channel number (usually 10 for drum kits) A note number (For drums, which drum got hit) A Velocity number(For drums, how hard it got hit) Bonus question: Why are drums usually on channel 10? LyleHaze

I have not worked with DOUTs or LED Matrices yet, so I'll avoid those questions. Whether you use the NOTE-OFF messages or just do a rapid decay from NOTE-ON is your choice. Since it's a software change you can easily try it both ways after it's built. I will _suggest_ a change in terminology. The word "channel" has very specific meanings in MIDI terms. Perhaps it would be less confusing if we described it as 24 NOTES on a given channel (priobably channel 10, if I recall). Your assumption on MIDI-THRU is exactly correct. It's an exact copy of MIDI-IN for the "next device in the chain". If you do it in hardware there is no software issues and almost no delay (let's call it less delay than measurable) Have Fun, LyleHaze

Velocity information is available in the MIDI output of the EDrum. Perhaps you could just set up a MIDIBox with a hardware MIDI-THRU jack, and monitor the data coming in. I know that software MIDI-THRU is available, but doing it in hardware is not too hard, and it reduces the delay to near nothing. That way you get the "peak" value of each hit from the velocity of the NOTE-ON message. Most drum controllers (I'm not sure about the E-Drum) never send NOTE-OFF messages, so just set up a rapid decay for each ring that has something lit. It would make setting your input gain pots a lot easier, if you could see how big your signal is. Sounds like fun! LyleHaze

If I understand the question correctly, and I might be wrong.. The EDrum has it's input pots connected from the piezo input to Gnd, with the wiper connected to the input circuit. This allows you to control the "level" of the input from the piezo, setting the sensitivity of the circuit. Most MB pot inputs connect +5Volts across the pot, with the wiper connected to the input, so you get a constant voltage somewhere between 0 and +5 volts into the AD input. I think the easiest way to combine these is.. a double-pot at each position. One wired to the EDrum input, and the other wired for the MIDIBox's analog input. Not a simple solution. But I might misunderstand completely! LyleHaze

@stryd_one, Lighter? is +12 semi tons too much? OK, Just being playful! Looks like someone has been having FUN with MIOS! LyleHaze

Seppoman: I like your answer a lot better than mine. :-) LyleHaze

Greetings. I'm not sure I understand the question, so we'll see how much of an answer I can manage. You want to "Directly select a saved patch/setup" What is the patch/setup saved on? If you are recalling a patch on any MIDI device, then you will need to use the MIDI commands that that device will recognize. This is usually by "selecting" a pre-saved patch, sometimes with a Program change command, or by sending the entire patch,usually with a System Exclusive command. The MIDIBox can easily do the first, and can support the second as long as memory/storage is sufficient. OR you want to select a "saved patch/setup" on the MIDIBox itself. Sure! Assuming you have saved it somewhere, and you know where to reload it to. There are MANY different things you can build with a MIDIBox, so what to save/load is a rather loose definition. MIDIBoxes have been used to make synthesizers,routers, control surfaces,mixing boards, and a lot of other cool stuff. If you want a better answer, you'll need to be more specific.

The fan-out limitation: I'll go a little deeper. A single pin on the PIC18F chip (on the core) is driving.. let's say SCLK for the PGA chain. It connects via J10 (I think) to the first channel board, and the second, and the third, and the forth et-cetera.. That signal moves pretty fast, as it "clocks" all the data being moved through the chain. Each channel board "loads" the signal a little more. At some point, it's not strong enough to carry cleanly to all the channel boards listening to it. The "Fan-Out" has been exceeded, and the signal integrity is lost. Since each SDO pin goes only to the next boards SDI input, there is no fan-out problem, but the SCLK and CS may have issues. (or WILL have issues when enough boards are attached) Regarding memory, it's not in the PGAs, it's in the core. The current plan includes (all RAM) 64 bytes of ram to support the "output image" for 16 channel boards. (I don't know if the hardware will support it, but the software will! :-) An array of ram sized at maxchannels (16?) * at least 6 bytes. The bytes of ram include the most recently received values for that channel: CC7 volume CC8or10 Bal/Pan CC11 Expression CC12 FX1 CC13 FX2 A byte of "flag bits" holding FX1 Pre/Post, FX2 Pre/Post,FX1 Mute, FX2 Mute (The previous all controlled by CC80 through CC83) Then some other choice bits, does this channel follow master volume? Will this channel follow ANY channels Expression settings? (for ganging faders) And whatever else I dream up. The program will use the values in the CC registers to "create" an image to send out to the PGA chips. It's the same as the current program, just a bit more complex. As a last step it also does a lin to log conversion, so the feel of the controls is correct. Example gain setting for the left channel is: ((128-Pan)*Volume*Expression*16)/65536 saturate at 255, then convert to Log by LUT and put the result in the output image table for the left channel. The right is just slightly different: Pan*Vol*Exp*16/65536. Obviously pan takes one up and the other down. I like the idea of being able to select each Effect as Pre or Post "on the fly". I can picture a "perfect" control deck for this, but I know there are people here with MUCH better skills than I to build that. I need to go find code for multiplying 3 8 bit numbers into a 24 bit result. Party On, LyleHaze

(I screwed up the quoting.. Work with me here!) Bah we can get around those kind of problems.... However I'm still trying to nut out how you've done it... I can't find anything in the doc about the digital signals.... You probably won't. Signal "Fan Out" is a property of the technology used. TTL, LSTTL, HCT, CMOS etc. It's a very "old school" kind of problem. Most families have a fan-out of 10 within the same family. Between different families you have to make sure that "high" is high enough, "Low" is low enough, and then figure fan-out based on strength. Because it's common to entire families, it's not usually even mentioned in the datasheets. [edit] Oh, Duh again. In MY doc. The eight stackpins on the right side carry digitals. Six pass straight through, common to all boards. (in no particular order) MUTE,ZCEN,+5V,GND,CS,SCLK In the other two holes, SDI and SDO, we need to chain each output to the next input. We cannot do this "straight through" as that would be a common buss. So we install one stack socket facing UP, and the other facing DOWN, both with their tails cut off. then take about 3/4" long .025 square post(cut off a WW socket?) and bend into a slight "Z" shape. Cut to finished length of about 1/2", and insert between successive boards from the bottom SDO to the top SDI. Repeat for every level. I hope that explains it. [end edit] I would have thought that the way you'd do it is to chain the serial IO and clock, buffered up if necessary (which it should not be for the SDI/O, but maybe for the clock), and have an SR driving the chip selects? Close, but CS and Clock are common to all in the line. The SDO/SDI line needs no buffering, as each has a load of 1. All the CS lines are supposed to go low at once (for a given set of 8/16) We can buffer CS and Clock, heck, we may not need to if the PIC outputs are strong enough. The next obstacle to a long chain is the MIDI standard. Unless you want to adopt a private messaging system, we have only 16 channels to work with. (or 16 per series stack) As for the latency concerns if it gets really big...well if people like moogah and I want to be stupid about things then we can figure out a multi-core design. Don't sweat about making your design work with my little dreams ;) If you really want to know, you'll hear it at about 2ms, so divide that by the time it takes to load a PGA chip. Thanks, I'll do the math later. :-) Mute = Mute, kill it all. I can do that. But having separate mutes to toggle means we don't lose the level setting, it will go back to where it was when unmuted. Maybe that's good, maybe not. CC96 "Increment".. Channel Volume? CC97 "Decrement".. Channel Volume? Yeh but I wouldn't bother, pretty much nothing else uses these CC's I'm planning an IR receiver for standard remote controls. That will need INC and DEC to operate. CC120 "All Sound Off".. By mutes, or full preset? Mute the master out After an "All Sound Off", how do we get it back "On"?? Unmute Yeah, I guess it can be turned on and off. Duh. CC121 "Reset All Controllers". Sounds like we could load a "preset all to default state". User defines that state! Default should really be all at 0.... Keeps the monitors safe ;) I started the math today. It's coming well. I will be leaving town next week for 10 days, so there will be a break in my work. Don't worry, I'm going to finish this. Make Beautiful Music, LyleHaze