Working on MIDI in/out Module for Gadgeteer

Pete,

This is just a transistor.
The only important points are the gain and Vcesat, just like with a stabdard transistor.
While for default transistor we would consider the gain as Ic/Ib, on an optocoupler, it is Ic/Iled

As far as you have enough Ic current to reach Vcesat, it’s fine.

I had problem with some opto with poor gain for which I had to increase the resistor value.

However this is on your side of the design, not on the MIDI side, so you can what you need.

This is a problem with MIDI standard interface being specified by a reference schematics instead of pure specifications.

@ Barbudor

Awesome, thanks for the explanation.

Agreed on how it is spec’d. For a while, I searched for actual usable specifications, but that one tiny (old!) schematic with some footnotes is essentially it. You can’t even find good min/max information, which is almost certainly why the different machines are so sensitive to deviation from 5v values, and from different opto isolators.

Of course, it is an early 80s spec, so I should just be happy it works at all :wink:

Pete

PCBs are in!

I ordered them from Seeed. Shipping via HK post took longer than the manufacturing time. I usually use DHL but they had a big warning about having to pay customs. For whatever reason, I’ve never been asked to pay customs fees on anything that has been shipped to me.

Pete

Here’s an interesting bit of funniness from them.

I ordered two quantities of 10 PCBs in the same order. It’s obvious they did them as part of two different production runs, and even did two different layouts.

The photo here shows the back of each. On the first, there’s no silkscreen on the back, and they did the tracking numbers by not putting soldermask in that area. Same with the circles around the mounting holes. Odd, and not particularly nice, but not the end of the world.

On the second, it was done more as I would have expected with actual silkscreen.

In both cases, they put the IDs on the back even though I put the order number on the front silkscreen as requested.

Pete

Nice looking boards! Congratulations!

Nice to see more modules being born! So what next? A gadgeteer garage band?

Maybe I need to wire this up with one of @ devhammer’s boards and remote control a helicopter from a synthesizer

Mod wheel could be interesting :wink:

Pete

Hmm…put that together with the MeeBlip Micro I just ordered and you could have sound AND motion…I’m thinking that’s a demo project for MADExpo! :slight_smile:

D’oh! Wrong package outline for the opto isolator. Bad advice (not from this forum), but I should have checked the data sheet.

Turns out, optos simply aren’t available in that package. They’re relatively large ICs due to what’s in them.

At least Seeed was cheap enough that using these as practice boards won’t make me cry :wink:

I’ll probably dead-bug one of the 6n138s this just to verify everything else works. On the plus side, I managed to solder all the resistors and that tiny SOT23-5 logic gate - the first time I’ve done anything with SMD components. My recommendation: lay off the coffee for a while before you try to do this :slight_smile:

Pete

The trick I use is to stabilize my soldering hand against my Panavise. Usually keeps it stable enough to hit the target OK, though not sure how well it’d work if I had tinier components than what I used. :slight_smile:

That’s a bummer about the boards…but at least Seeed got them to you pretty fast.

I’ve decided, to make it more kit-friendly, to make this second rev pretty much all through hole. The only parts I can’t find in through hole are the Gadgeteer connector (available, but so tiny I think SMD is easier) and the TTL-level logic gate. The only TH for the logic gate are giant ICs with multiple gates.

@ devhammer

Thanks. I never before realized how much my hand shook :slight_smile:

Pete

Bug fix for using the wrong footprint.

She may not look like much, but she’s got it where it counts, kid.

I hope :slight_smile:

Pete

Is it singing yet :slight_smile:

Not yet. Working on MIDI receive first :slight_smile:

Getting there.

Ok, the skeleton driver is written. Code needs some cleaning and I’d like to provide slightly more friendly MIDI message info, but:

  • MIDI Receive works
  • MIDI Soft Thru (automatically echoing in to out) works. Latency isn’t horrible. It’s there, but not as bad as I thought it would be.

Need to make MIDI send work, but that should be working in a few hours…well, after I go to sleep anyway :slight_smile: The mechanics are there due to the soft thru.

Also, I need to see how to handle these events in such a way that user code isn’t going to kill the whole thing. I’m considering raising the events on their own thread, but that’s not very user friendly. Of course, I could just put a big old note in there “put long running code in your Midi Message Received event handler and performance will tank”. Thoughts?

Pete

@ Pete

That’s some…um…creative soldering there. :slight_smile:

Seriously, though, good job working around the footprint issue…now you’ll have plenty of time to get the drivers in good shape before the next set of boards arrive.

v0.1 of the module driver is done. Uses the “U” port on Gadgeteer

API Surface Area:

MidiModule

public event MidiMessageReceivedEventHandler MessageReceived
public bool SoftThru { get; set; }
public void EnableReceiver()
public void DisableReceiver()
public void SendChannelMessage(MidiChannel channel, MidiMessageId id, byte data1, byte data2)
public void SendChannelMessage(MidiChannel channel, MidiMessageId id, byte data1)
public void SendNoteOn(MidiChannel channel, byte note, byte velocity)
public void SendNoteOff(MidiChannel channel, byte note)
public void SendPolyphonicAftertouch(MidiChannel channel, byte note, byte pressure)
public void SendControlChange(MidiChannel channel, byte control, byte value)
public void SendProgramChange(MidiChannel channel, byte program)
public void SendChannelAftertouch(MidiChannel channel, byte pressure)
public void SendPitchWheelChange(MidiChannel channel, Int16 value)
public void SendChannelAllSoundOff(MidiChannel channel)
public void SendChannelResetAllControllers(MidiChannel channel)
public void SendChannelLocalControl(MidiChannel channel, bool localControlEnabled)
public void SendChannelAllNotesOff(MidiChannel channel)
public void SendChannelOmniMode(MidiChannel channel, bool omniModeEnabled)
public void SendChannelMonoModeOn(MidiChannel channel, byte numberOfChannels)
public void SendChannelPolyModeOn(MidiChannel channel)

Helper classes:

MidiUtility

public enum MusicalNote
public static byte NoteNameToMidiNoteNumber(MusicalNote note, int octave)
public static MusicalNote MidiNoteNumberToNameAndOctave(byte midiNoteNumber, out int octave)

General MIDI

public enum GeneralMidiDrumNotes
public enum GeneralMidiInstrumentPrograms
public enum GeneralMidiControlNumbers

Others

public enum MidiMessageId

public class MidiMessage
{
    public MidiChannel Channel;
    public MidiMessageId ID;
    public byte DataByteCount;
    public byte DataByte1;
    public byte DataByte2;
}

There’s very little in the guts that’s Gadgeteer-specific, so with a little conditional compilation, I should have no issues making a version of this that works on other netmf devices (that’s also the reason behind the pin header on the board)

No SysEx or clock implementation yet.

Also, I plan to provide more specific events as the current generic MessageReceived event requires you to understand how the different bytes are used.

I wrote a little test program that scrolls through program changes using one button, triggers a note with another, and uses the Joystick for pitch bend.

I’m taking requests if there’s some functionality you want to see baked in or in an optional utility module

Pete

Pete,

It may already be possible using your existing methods, but I’d like to be able to use the MIDI module to control parameters on the MeeBlip micro (http://meeblip.com/get-one/) that I ordered. I’m also going to add headers to the board so that I can breadboard the analog/digital controls on the MeeBlip, but it would be cool to just hook it up to the Gadgeteer and go crazy. :slight_smile:

@ devhammer
I wonder how it really sounds (I’ve listen to the sound samples, but not real music).
Web says monophonic and use a Dual 8-bit DAC so why do they claims 16-bit sound ?

On the other side, I would be interested to get the feedback of those who played with music shield and/or VS1053/VS1103 chips.

It’s a monophonic synth.

The sound is a bit like my SammichSID in its gritty 8-bitness, a tiny bit 303, and a bit like nothing else I own.

I’m looking at the schematic (attached) and I agree it’s a dial 8 bit DAC. It’s mono output, though. Looking at the bottom of the schematic, it looks like he’s summing the two signals, although I have to profess complete cluelessness as to how exactly that part of the circuit works.

All sounds are meeblip:

Meeblip bassline

Some music (drums and fx are other machines)

Also, some demos here that range from sound demo to almost music
http://soundcloud.com/search?q[fulltext]=meeblip

Other Meeblip demos here, but most are people tinkering:
http://www.youtube.com/results?search_query=meeblip

Pete