Featured

The macOS MIDI Network Session Guide

The macOS MIDI Network Session, as it appears in Audio MIDI Setup, is a robust utility for MIDI routing over your local network (LAN), or even the Internet. This article intends to cover the MIDI Network Session’s terminology, functionality, synchronization and transport methods, and use-case scenarios. If you’ve yet to use the MIDI Network Session, you can follow along on your Mac, and gain a solid understanding of its built-in MIDI network functionality. And hopefully, if you already use the MIDI Network Session, you’ll still find some new informationDefining the Network MIDI Session on macOS

If you haven’t yet, let’s get started by creating a MIDI Network Session.

  1. Open the Mac’s Audio MIDI Setup, located in the Utilities Folder, accessible in Finder’s Go Menu, or by keyboard shortcut Up/Command/U.
  2. We’ll be working with Audio MIDI Setup’s MIDI Studio. If MIDI Studio isn’t showing after you’ve opened Audio MIDI Setup, access it via the AUDIO MIDI Setup’s Window Menu, or CMD-2 keyboard shortcut.

In the MIDI Studio window you’ll see a Network Icon. Double-click the icon to bring up the MIDI Network Setup window.

The MIDI Network Setup Window

The MIDI Network Setup window is divided down the middle, where left of center in the window begins at the top with My Sessions.

To the right of center, beginning with Session at the top section allows a selected MIDI Network Session to be Enabled, provides additional configuration options, and further details, of your Enabled MIDI Network Session.

Let’s take a look first at the Left side of the MIDI Network Setup, which we’ll use first to create a MIDI Network Session.

Immediately below My Sessions is the initially blank Directory window – Here you can Select/Create (+)/Destroy (-) eligible MIDI Network Session Participants/Contacts in the Directory list.

The Who may connect to me drop down located bottom of the My Sessions provides options to control access to your MIDI Network Sessions from other remote endpoints that may request access to participate in your MIDI Network Session.

Moving to the right from center of the MIDI Network Setup Window, is the Session section, which provides details about your selected MIDI Network Session. we’ll cover this section further below, but we’ll begin first by creating, or selecting a MIDI Network Session from the My Sessions window:

  1. Click the + symbol below the My Sessions Panel, you’ll see Session 1 appear in the My Sessions panel.
  2. Next Enable the Session via the Enabled check box in the Session panel of MIDI Network Setup.
  3. Next Select an Eligible MIDI Network Session Participant from the Directory panel’s list, Highlight the Eligible Participant, and click Connect.

MIDI Network Setup – Default View (excepting My Directory List)

If everything goes successfully, you’ll now have officially created a MIDI Network Session. Let’s get a little more detail about what we did, to fully understand what comprises an active MIDI Network Session

a MIDI Network Session is defined at the point in time when an eligible MIDI Source, and an eligible MIDI Destination are connected. When the MIDI Source, and MIDI Destination are connected, they become a MIDI Network Entity. This enumeration process, leading to an active MIDI Network Session, is what the steps above accomplish. Let’s take a look at what defines a MIDI Source.

The MIDI Source of the MIDI Network Session is the endpoint that initiated (sources) the MIDI Network Session, in our case, the Mac. Once you’ve Created a Session, and then Enabled the Session, your Mac is now the MIDI Network Session Host, and awaits an eligible Participant from the Directory, to request a connection to the Session. But until an eligible Participant connects (via the Connect button), we’ve yet to create a MIDI Network Entity. Once an eligible Participant is granted permission by the Host/Mac, and connects, then the MIDI Network Entity is formed, and a MIDI Network Session is defined.

The MIDI Network Entity is a dedicated set of communication Ports through which the MIDI Source/Host/Mac and the MIDI Destination/Connected-eligible-Participant, communicate their MIDI Network Session information and management data, along with your MIDI messages. We’ll talk more about these Ports and how the MIDI Network Session communicates, further below.

Fully Defined MIDI Network Session.

The image just below displays a fully defined MIDI Network Session. The Destination endpoint will be one of the Eligible Participants listed in the Directory, which are also known as Contacts (where we can think of the Directory as our Address Book). Here you’ll see I’ve selected and connected my iPad from the Directory list, connecting it to the Session Host/Mac. After clicking Connect, the Host goes through a series of communications with the iPad, establishing communication over the Session Ports, and establishing synchronization between the 2. We’ll talk more about these communications and Ports further below.

You’ll notice some red lines in the Latency panel, indicating I’ve got a roughly 2-3ms roundtrip latency between my Mac and the iPad. In this case I have my iPad connected to the Mac via the Lightning-to-USB connector, which is plugged into my USB Audio Interface, which is plugged out to my Mac. I’ll discuss the specific communications and formula the MIDI Network Session uses to initialize and maintain synchronization between the Host/Mac and the Destination/iPad, further below.

Fugue Machine’s MIDI Out pointed to the Mac’s MIDI Network Session

Regarding the iPad – you’re not going to see it show in the list of eligible Session Participants until you’ve got an iOS app open that enumerates some Core MIDI. Here you’ll see I’ve opened up Fugue Machine, and set its MIDI out ports to the MIDI Network Session. Not all iOS apps behave the same, but a free one that always works is Midimux, although if robust Audio routing between your iOS device and PC’s or Macs is of interest, then you should check out Studiomux by the same company. I’ve written about Studiomux: Studiomux – Still Tops for Audio & MIDI Routing Between iOS ’11 – High Sierra & Windows:

But before we go firing off MIDI, let’s take a look at how MIDI is processed by the MIDI Network Session, to both avoid problems, and extend its functionality. The following list details some crucial properties of the MIDI Network Session.

  1. MIDI Network Sessions broadcast received MIDI to all of the Session’s connections.
  2. MIDI Input from all MIDI Network Session’s connections – is merged when it reaches the MIDI Network Session Host.
  3. Each MIDI Network Session has 16 Channels of bidirectional MIDI.
  4. Multiple MIDI Network Sessions can be created, and eligible Participants can connect to multiple Sessions. A Session Host cannot connect to its own Session, but can be a connected Participant in any other Session.
  5. Each MIDI Network Session can have any number of connected Participants.
  6. All MIDI 1.0 defined messages can be sent across the MIDI Network Session, the undefined messages will be ignored.
  7. MIDI Beat Clock, MIDI Time Code, and SMPTE can all be transported via the Network Session.
  8. The MIDI Network Session works across Ethernet, WiFi, and USB, and will translate all Din MIDI messages as well.
  9. Every Apple computer since OS X Tiger 10.4 includes the MIDI Network Session functionality.
  10. Every iOS device since iOS 4.2 includes the MIDI Network Session functionality.
  11. MIDI Network Sessions update all connections in the Session when the Contacts List changes. The only caveat here is that connections to the MIDI Network Session must be able to “observe” the MIDI Network Session command messages indicating the change in connections.
  12. Additionally when a change occurs to the MIDI Network Session’s connections, or the Contact policy (Who may connect to me) of the MIDI Network Session is changed, the connections to the Network Session are informed, again presuming they are able to receive the message.
  13. MIDI Network Sessions also work alongside iOS devices using IDAM (Inter Device Audio MIDI Mode) as its known since iOS 11, which prior to ’11 was called Inter Device Audio Mode. The MIDI aspects of IDAM was added in iOS 11. If you’re interested, I wrote about IDAM here: iOS 11 – Features List for Music Production. So yes, you can use IDAM & the Network MIDI Session in conjunction, or separately.
  14. AudioBus 3 and MIDI Network Sessions – If you utilize, or consider utilizing AudioBus 3, you’ll have a powerful MIDI router between your iOS devices, your Macs, PC’s and other MIDI endpoints. MIDI Network Sessions show as MIDI Inputs and Outputs in AudioBus 3, allowing them to be processed and routed via AudioBus 3, through AB3 MIDI FX apps, or out to other iOS apps with eligible MIDI connections. In the following image you’ll see my Mac, PC (Inspiron), the IDAM MIDI Host, and 4 ICM4 listings, which are created by the iConnectMIDI4+. While the image shows MIDI Senders in AudioBus 3, they are all listed as MIDI Receivers as well.

MIDI Network Sessions are eligible MIDI Inputs and Outputs to AudioBus 3

Practical Applications of MIDI Network Sessions – Some Notes on the Above List, potential concerns, and ideas to expand MIDI routing capabilities.

While the above list is fairly straightforward, Let’s look at #1 in particular. Taking our example Session, we noted the Mac is the MIDI Network Session Host.

#1 in the above list states:

  1. MIDI Network Sessions broadcast received MIDI to all of the Session’s connections.

So, any MIDI messages sent out to the MIDI Network Session Host/Mac will be received there, merged, and then sent out to all the Host’s connected MIDI endpoints. This is very much a broadcast message, which you might be familiar with if you’ve worked with network protocols before.

If you have a combination of connected hardware and software MIDI devices connected to the Mac/Host, you’ll want to make sure you take into account that all the MIDI messages received by the Host/Mac MIDI are immediately broadcast to  all the Host/Mac’s MIDI endpoints. You can specify which of the 16 MIDI Channels that your MIDI messages send to the Network Session, but the Session will still send out those messages to all endpoints (albeit only on your specified MIDI Channel).

This broadcasting behavior of the MIDI Network Session Host can be advantageous as it greatly reduces the processing time of the MIDI messages by the Host, but some devices you may not want to receive all that MIDI, so you’ll either have to set them to ignore the MIDI, or if they cannot ignore received MIDI (definitely some hardware does this, or even software that is permanently set to OMNI Mode), then you’ll have to use multiple MIDI Network Sessions and other options to ensure you don’t have ill-behavior, loops, or other Panic scenarios.

MIDI Network Sessions can have more than 1 Participant as well. So if you have multiple computers or other network devices, each will show up in the Directory, allowing you to connect them as MIDI Network Session Participants. Remember that Session participants will receive all MIDI messages sent to the MIDI Network Session. If you have multiple computers on your Network running MIDI software or with attached MIDI Hardware, MIDI Network Sessions are an excellent, low-latency way to route MIDI and keep the devices in sync. As you can see, in my MIDI Network Setup my Windows PC is listed, along with the 4 eligible Participants enumerated by the iConnectMIDI4+.

Also of note, if you create and enable a 2nd MIDI Network Session, you’ll notice your Mac will now appear in the 2nd Session’s Directory. The first Session is always Hosted by the Mac, because the Mac is the Source endpoint that initiated the Session. As the Session Host, the Mac won’t be listed in its own Directory. But on subsequent Sessions you create, the Mac will appear as an eligible Participant using its Local Host name. This way, other computers that are Network Session Hosts, can see the Mac in their Directory, allowing the Mac to connect as a Participant to other Hosts’ MIDI Network Sessions.

Lastly, if you have devices that cannot reject MIDI from an incoming source, then you may want to use multiple MIDI Network Sessions in order to confine such endpoints to their own Session. What’s nice here, is once MIDI is on the Network, Since each MIDI Network Session gets its own set of Ports, Synchronization and throughput are excellent, as Ports run in parallel, rather than Serial, allowing you to manage bandwidth. Devices connected directly to your Switch via Ethernet, will always be the fastest, but Network Sessions work over USB and Wi-fi as well.

MIDI Network Sessions are very lightweight, and because they use Network protocols and ports for communications, they don’t run in a serialized manner, so you should never have to worry about saturating the Ports, or creating as many Sessions as you’d like. With multiple Sessions, you can independently send and receive different clock sources, for example, and use the bandwidth of the network, rather than USB or other protocols, which can be less accurate, and have limited bandwidth. Next we’ll discuss the Live Routings options in MIDI Network Setup, and learn to further control MIDI between specific endpoints.

Live Routings

let’s take a look at what the Live Routings can do. The Live Routings drop down menus in MIDI Network Setup allow you to select MIDI In and Out endpoints for further routing, enhancing your ability to direct MIDI messages to the proper endpoints. While many software MIDI endpoints will be able to see the Network Session on their own, allowing you to Select the Network Session as a MIDI In or Out, some hardware in particular won’t see the MIDI Network Session, in this case you can utilize the Live Routings to Direct MIDI to or from a particular endpoint. The endpoints listed in the Live Routings drop down menus are the endpoints the Host/Mac can see.  Similarly, within your software, you may want to set it to receive and send MIDI via the Network Session, and then use Live Routings to connect a particular set of endpoints in/out of  your Daw etc.

Now let’s finish covering the remaining sections of MIDI Network Setup, before moving on to see how Apple’s Network MIDI Driver works.

You have:

  • Port: The UDP Control port the Network Session will utilize – also known as the MIDI Network Port
  • Local name: The Local name field is the name the MIDI entity will inherit when the Session is Created.  While my Local name is shown as Session 1, endpoints that can see the Local name will likely see it as Network Session 1.
  • Bonjour name: MIDI Network Sessions utilize Apple’s Bonjour protocol. This is the name other connecting bonjour services will see, and is of the format .apple-midi._udp.
  • Participants: Participants in the MIDI Network Session are displayed in the Participants window of MIDI Network Setup, and represent endpoint(s) connected to the Session Host. When connected to the Session Host, the 2 form a MIDI Network Entity. Eligible Participants are listed  (or can be created in) the Directory window of MIDI Network Setup.
  • Latency – explained below in-depth, but measures the roundtrip latency between the Host and Participant(s).
  • Address – a list of the IPv4 & IPv6 addresses recognized by the Session
  • Live Routings – Here you select specific 1 to 1 MIDI connections between endpoints connected to the Session’s Host.

Directory Panel:

The last section of the MIDI Network Setup window we’ll cover is the Directory Panel. In the Directory Panel of MIDI Network Setup, you’ll see a list of  eligible Participants to your Session. Eligible Participants are also known as Contacts, as they’re residing in your address book (Directory).

If you want to add a new Contact (Eligible Session Participant) to your Directory, click the + Button directly below the list of available Participants in your Directory. This is especially useful if you’d like to connect to a device outside your LAN.

I’ll use the Telephone System metaphor as a common way to relate with how the MIDI Network Session Directory, Contacts List and the like operates.

Think of the MIDI Network Session as a Telephone System you want to build. You begin building a telephone system by constructing some location to Host all the gear you’ll need to process all the incoming and outgoing phone calls. After you’ve built this main Hosting location, you’ll need some customers to talk to you, or anyone else connected to you. So you start building out your telephone lines, and you send out messages every so often, to see if anybody out there wants to talk. Then one day, someone decides they’d like to call, so they hook up to your telephone lines, see that you’re sending out these messages, and send you back a response message saying, “Hey, I’m here and I want to talk to you!” But before you’re ready to talk, you look over their connection, make sure it’s going to work, Once you’ve decided you’re compatible, you send them back a message, accepting the request and connecting with them. You then send them over some more questions… what time is it there? Do we speak the same language? And Lastly, what do you want to talk about? So now your phone call is connected, you both agree on a time, understand exactly how to communicate, and then start talking!

Clicking the + sign under the Directory window you get three fields:

  • Name: – You’ll notice this field has the word ‘machine’ grayed out. This indicates the Bonjour name, or Local name for the Participant.
  • Host: here you’ll see host.example.com grayed out. Since the MIDI Network Host Contact you’re creating is likely outside of your LAN, you’ll likely input its IP Address in this field, which in turn becomes the Remote MIDI Network Host Contact’s Local name.
  • Port: – The Remote MIDI Network Session Host’s assigned UDP port number through which it sends and receives MIDI messages. 5004 is grayed out here and signifies this as the first available port number in the Bonjour address space for a Network Session.

In the Who may connect to me drop down menu are three options to help secure your MIDI Network Sessions, by only allowing connections from available participants in the Directory, or from anyone/no one.

With a solid understanding of how to set up a MIDI Network Session, and some of their behaviors, let’s move forward and look with greater detail into the underlying network protocol(s) on which MIDI Network Sessions operate, called by Apple the MIDI Network Driver Protocol.

How MIDI Messages are processed, and Synchronization is achieved, by the MIDI Network Session

The MIDI Network Driver Protocol specifies all the details of Network Sessions.

Essentially, MIDI Network Sessions utilize the UDP protocol,  Apple’s Bonjour service, and a customized implementation of RTP-MIDI. 

Together, these protocols allow Sessions to be Setup, managed, tore down, synchronize clocks, transport MIDI messages, and even provide some means to correct for dropped MIDI messages.

Back in the MIDI Network Setup Window, You’ll notice both a Local name, and a Bonjour name. The Local name, is the User-Selectable name, in our example, titled Session 1. So devices on your Local network, will see this name in their list of MIDI I/O’s. The user-selectable Bonjour name, in my case MacBook.local – is the name Local devices using the Bonjour Protocol, will see. This is why, in the above image from AudioBus 3, MacBook.local is seen as the name of my Network Session, because iOS devices use the Bonjour protocol as well.

If you’re needing to connect to devices outside of your LAN, across the internet, by example, you’ll want to utilize an IP Address. Clicking the + Button below the Directory allows you to set up a connection to a remote participant. I’m not going to cover details here, but in order for this to work, you’ll also have to configure Port Forwarding to your externally facing network device, whatever you have that functions as DNS Server and handles DHCP.

Let’s start with Apple’s Bonjour, the foundation of the Apple MIDI Network Driver Protocol, the protocol by which MIDI transported over your Network, which is a customized version of RFC 6295, RTP Payload Format for MIDI. Next we’ll explore its functionality, how it sends Network Session MIDI, and manages synchronization.

for this next section, You might find it helpful to get a realtime view of your MIDI Network Session. I highly recommend downloading the free Bonjour Browser from Kevin Ballard. It’s a lightweight utility for macOS that will help you to confirm your MIDI Network Session is up and running properly.

MIDI Network Session UDP Ports Explained

When you fully define a  MIDI Network Session a set of UDP Ports are created automatically, or you can assign the Port number yourself.  Port numbers will automatically start at 5004, which you can see above in the Port field of my MIDI Network Setup. Subsequent MIDI Network Sessions increment up by 2 (5006, 5008…10).

Each MIDI Network Session uses 2 UDP ports. A Control Port, which is always the first port (5004) and the next port, a MIDI communication port, which is always n+1, where n is the Control Port and n+1 is the MIDI communication port. So the default 1st created MIDI Network Session utilizes Port 5004 for Control Port messages, and Port 5005 for the MIDI communication messages.

Control port messages include Session Initiation & Termination, Synchronization, and receiver feedback messages that manage and monitor the MIDI Network connections.

MIDI communication messages Port (5005) are the actual MIDI payload, along with what’s called Recovery Journal Format messages. There are also, somewhat confusingly, the same Timestamp messages on the communication port, as there are on the Control port. These messages don’t function to synchronize endpoints, but rather form the basis, along with Recovery Journal Format messages, with which the MIDI Network Session can achieve a running cache of the MIDI messages being sent over the Session, such that if messages are dropped, they can be resent. I’ll discuss these messages further below. They also provide the mechanism for the MIDI Network Driver to send MIDI files over the network, as all MIDI events are timestamped. It remains to be seen whether the Network MIDI Driver’s communication Port will be approved to utilize these timestamps for clocking.

After you’ve got your MIDI Network Session enabled, open up the Bonjour Browser and you’ll see an immediate display of almost all the Bonjour Services running on your Mac. There are a few other types of Bonjour Services not automatically displayed, you can enable these via the Bonjour Browser Menu, in Preferences, and see/deselect the other Bonjour Browser services currently selected for monitoring.

Here’s a screenshot from my Mac, where I have initiated a MIDI Network Sessions which appears as MacBook.local in the Bonjour Browser, which matches the Bonjour name in the Session panel of MIDI Network Setup.

The Address of 192.168.1.6 – is my local network address (the Mac), followed by :5004 – the UDP Control Port of the MIDI Network Session.

MIDI Network Sessions will appear under the Local Menu in the Bonjour Browser under the .apple-midi._udp menu. All MIDI Network Sessions on the Mac will have this format.

How Latency is measured in the MIDI Network Session

Above we noted that the UDP Port 5004 was the Control Port of the MIDI Network Session. The Communication/Data Port handles the synchronization of the MIDI entity (5005). The Data Port, because it handles the MIDI payload, runs at a higher priority than the Control Channel, and so is the better-suited Port for synchronization. When the Host receives a connection request, a series of messages are exchanged, and the connection is enabled. Upon a successful connection, the Network Session Host (the originator of the Session) communicates with the Session Participant to establish synchronization.

Synchronization is interesting as handled by the MIDI Network Session.

The Host selects an Arbitrary and unknown time from which to start counting, called Zero-time, and forwards the Zero-time to the newly Connected Participant.

The Participant receives this packet, and responds back to the Host with a packet indicating the time its clock registered when it received the Zero-time packet.

The Host then sends back one more packet, including the exact timestamp when it received the Participant’s response packet, along with the 2 previous timestamps from the Zero-packet, and the Participant’s  response time to the Zero-packet.

In this manner, both the Host and the Participant have all the information they need to independently calculate the offset between their respective clocks, and then synchronize to that offset.

The Offset, using these 3 timestamps is calculated as such:

Timestamp 3 + Timestamp 1 / 2 – timestamp 2. Here’s an image from a WireShark capture I did, showing the 3 successive Timestamp messages:

MIDI Network Session – 3 Timestamp messages used to synchronize Host with Participant

Additionally, the Host and the connection keep a history of these synchronization exchanges, and use that history as a baseline from which to maintain synchronization. Synchronization exchanges are only required to happen once every 60 seconds, and if the connection doesn’t receive a synchronization exchange in that time, it will likely assume the MIDI Network Session is no longer available.

Lastly, during the first 60 seconds of the newly established connection, synchronization exchanges are (or should be) sent more frequently, in order to obtain a higher synchronization accuracy. If you watch the Latency window as you make a new connection, you’ll likely see it bouncing around a good bit for a few seconds, before it stabilizes. Roundtrip latency on the MIDI Network Session, on a typical LAN, should be between 1-2ms.

It’s also important to note that the MIDI Network Session timestamps are in Hz, not beats. So when incoming MIDI from Din or other protocols is received, the clock events are metrically converted to Hz by the Session Host. This is nominally no issue, as all MIDI events are timestamped.

How MIDI is transported on the MIDI Network Session

MIDI on the MIDI Network Session, is transported with a modified version of RFC 6295  – RTP Payload Format for MIDI. MIDI communication port messages sent to the MIDI Network Session are encapsulated to this format, which does vary quite a bit from other protocols used for MIDI transport. To minimize dropped packets (both Audio and MIDI in this case), the RTP-MIDI protocol uses what it calls a Recovery Journal. The Recovery Journal is an encoded and dynamic history of the Audio & MIDI Stream packets, which is formed by the intermittent exchange of special Checkpoint Packets, which are periodically sent from Participants to the Host.  Only specific MIDI events are encoded in the Checkpoint History packets, but this history allows for a packet recovery system, as the UDP protocol is lossy, where acknowledgement packets are not sent to ensure delivery. The Host keeps a “Journal” of certain MIDI Messages it has sent to the Participant, and can look at the interval between 2 Checkpoint messages, and then compare those interval messages with its sent messages Journal, thereby accounting for any differences, and resend lost messages to the Participant. The Journal includes the messages sent between the last 2 Checkpoint messages the participant sent

So to review – The specific Recovery Journal of the Mac models RFC 6295, in that the Session participant must periodically inform the Host of its most recently received MIDI packet’s contents. This is called a Checkpoint Packet. Once the Connection sends a subsequent Checkpoint Packet, the Host can account for all the messages sent between those 2 Checkpoints, which is called the Checkpoint History. In this manner, the Host keeps a table of these checkpoint messages, along with a table of the messages it sent to the participant, and thereby can reconcile discrepancies between the 2. The size of the Checkpoint messages is minimized by the relative frequency of Checkpoint Packets sent by the Participant, thereby reducing its bandwidth requirements, while helping to ensure packets are retransmitted as necessary.

But not all MIDI messages are included in Apple’s Checkpoint implementation, that are included in the RTP-MIDI protocol.  Apple’s MIDI Network Driver provides for the following types of MIDI messages in its Checkpoint Journal (ie Checkpoint History):

Program Change / Control Change / Pitch Wheel / Note On & Off / Channel Aftertouch / Sequencer state, i.e. beat clock / MIDI Time Code

Apple’s MIDI Network Driver does not provide for the following MIDI Messages in its Checkpoint Journal (These messages Are provided for in RTP-MIDI):

MIDI Parameter System / Note Command Extras / Song Select / Tune Request / Reset / undefined system commands / Active Sense / System Exclusive. So if these messages are dropped, they are not recovered by the Checkpoint History and sent again.

Lastly, Apple’s implementation of the RTP protocol always sends a Recovery Journal, but does not require one from the Network Session’s connections. Different participants may or may not have the Checkpoint schema in place, but the MIDI Network Session always sends them.

And that about sums up the MIDI Network Session. Hopefully, if you’ve made it this far, you’ve got a decent understanding of MIDI Network Sessions! Feel free to offer comments, questions, or corrections in the comments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s