Skip to content

Library for C# and other apps to use Windows 10 Anniversary Update native MIDI (USB, bluetooth, etc.)

License

Notifications You must be signed in to change notification settings

SeYoungLee/Windows-10-MIDI-Library

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

53 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Windows-10-MIDI-Library

Library for C# and other apps to use Windows 10 Anniversary Edition native MIDI (USB, bluetooth, etc.)

Want to use a read-to-go version? The NuGet package is kept up to date with milestones here. Right now, it has the basics, the clock and NRPN formatting. Updated on 10/19/2016 to fix a DLL folder issue that was causing a type load failure. https://www.nuget.org/packages/PeteBrown.Devices.Midi/

Requirements

  • Visual Studio 2015 (or higher)
  • Windows 10 Anniversary Edition SDK (or higher)

Working and usable features

  • Beat Clock generator for stand-alone beat clock usage (not for sequencers or similar apps)
  • Device enumeration and watcher
  • Identification of Bluetooth MIDI interfaces vs Other (USB, Network, etc.) interfaces. Requires using MidiDeviceInformation rather than stock DeviceInformation class.
  • Bindable collection of Input and Output port descriptions
  • NRPN message formatting / sending

Experimental or incomplete features

  • RPN message formatting / sending
  • MidiInPortEx for help with processing incoming logical (RPN, NRPN etc.) messages-

Investigating

  • MPE. People who want this know what it is. :)

Questions or concerns?

  • Issues and discussion here on GitHub or, Twitter: @pete_brown
  • Pull requests encouraged. :)

Usage

To see how to use specific features, just look at the C# TestMidiApp. This is a basic UWP app which shows each of the major features in use. You can use it to enumerate MIDI ports, use the beat clock, test message send/receive, etc.

MIDI Beat Clock

The MIDI beat clock is an implementation of a tempo-driven and pretty accurate beat clock. In a sequencer type app, the loop could contain more logic than just a beat clock, so this is solely for the utility of sending a clock without any other clock-driven events. You can use this to drive external sequencers and other devices from your PC.

Optionally, the clock can send MIDI Start and Stop messages. These are the messages that sequencers and drum machines listen for to start or stop their playback.

    using PeteBrown.Devices.Midi;
    
    ...
    
    MidiClockGenerator clock = new MidiClockGenerator();

    // set tempo in BPM
    clock.Tempo = 120.0;

    // yes, we want to send start and stop messages
    clock.SendMidiStartMessage = true;
    clock.SendMidiStopMessage = true;    
    
    // start the clock
    clock.Start();

    // do some other stuff
    
    // stop the clock
    clock.Stop();

The clock runs in a tight loop, which will pretty much tie up an entire core on your PC or device. This is necessary to maintain tight timings. Feel free to look at the C++ code and adapt it to your own needs should you want to do more than just send out clock messages.

Note also that I do not recommend sending clock messages from C#. You'll find that garbage collections and the other things which make C# so great to use can cause jitter and drift in the clock. You may be able to get it to work reasonably well for some window of BPM, but in my experience, C++ is a better tool for this job.

Status

  • Check clock timing with external device
  • Send start / stop messages
  • Send MIDI beat clock

MIDI Device Watcher

A best practice when using MIDI devices (or any devices for that matter) is to allow hot plugging and unplugging. Rather than just enumerate all devices at start and restrict the user to those, you want the app to respond to the user adding or removing devices after start.

UWP makes it easy with the DeviceWatcher class, but the results are not easily bindable in any XAML UI. Additionally, most apps do not want to enumerate the built-in MIDI synthesizer as one of the output ports, so I have included an option to filter that out from the results.

The best way to see this is to look in the MainViewModel in the TestMidiApp project. The UI consists of two lists (input and output) in the main XAML page.

Status

  • Observable collection updated on device add/remove
  • Raise event when enumeration complete
  • Raise additional events on device add/remove

TODO: I need to surface the add/remove events through this class rather than just use the collection. This will enable an app to respond in non-UI ways as well.

RPN and NRPN

(coming soon. Incomplete/experimental at the moment. The intent here is for you to be able to use RPN and NRPN aggregate messages in a way very similar to standard messages. This also requires an input processor, so you'll see a MidiInPortEx in addition to the message types.)

Example code for sending an NRPN message:

    using PeteBrown.Devices.Midi;
    
    ...
    
    var message = new MidiNrpnParameterValueChangeMessage();

    // parameter number and value are 14 bit values
    // and will be split into LSB and MSB across
    // two separate MIDI messages
    
    message.ParameterNumber = parameterNumber;
    message.ParameterValue = parameterValue;
    message.Channel = channel;

    // send the message through a MidiOutPort just like 
    // any built-in MIDI message
    outputPort.SendMessage(message);
    
    // with NRPN, if you send just a value update, it will
    // use the last parameter number you sent it.
    // You could send the parameter number every time,
    // but then you're sending 2x as many messages as 
    // necessary, over a low-speed transport
    
    var valueChangeMessage = new MidiNrpnValueChangeMessage();
    valueChangeMessage.ParameterValue = 5192;
    valueChangeMessage.Channel = channel;
    
    outputPort.SendMessage(valueChangeMessage);
    
    // because the parameter number is sticky, it's good
    // to null it out when you're done messing with a
    // particular controller/parameter
    
    var parameterNullMessage = new MidiNrpnParameterNullMessage();
    parameterNullMessage.Channel = channel;
    
    outputPort.SendMessage(parameterNullMessage);

Status

  • Send NRPN Value and Parameter Change message

  • Send NRPN Value Change message (checked in, but not tested)

  • Send NRPN Parameter Null message

  • Send RPN Value and Parameter Change message

  • Send RPN Value Change message

  • Send RPN Parameter Null message

  • Parse / aggregate NRPN messages on receive

  • Parse / aggregate RPN messages on receive

Samples

These are samples, not production-ready applications.

Main Sample App

This app shows how to use the majority of the features of the MIDI API. You can see input and output ports, send clock messages, etc. It uses a ViewModel-based approach for binding to the UI.

Roland V-1HD Sample app

This app shows how to use the library to simply switch between screens on the Roland V-1HD switcher. Requires that the switcher have MIDI input Rx turned on, and currently assumes A/B mode and changes only the selection from the A bank. Very simple to modify to your own needs.

This app uses a flat approach (no ViewModel) for binding to the UI.

Roland V-1HD

Notes about the ObservableDeviceEnumerationCollection

This is the moral equivalent to C# ObservableCollection<DeviceInformation>. That collection is not available in C# CX without taking a dependency on the .NET framework, which I didn't want to do. Additionally, Vector gets projected as just a plain old List, so that is not observable in C#.

If you're curious about what it takes to make something bindable and observable in C++, take a look. You can also see how to implement multiple interfaces while resolving naming conflicts. Much of the design of this class was shamelessly pulled from the collections.h implementation of Vector<T>

Binding in C# is enabled through the Windows::UI::Xaml::Interop::IBindableObservableVector interface.

    namespace WF =        ::Windows::Foundation;
    namespace WFC =       ::Windows::Foundation::Collections;
    namespace WUXI =      ::Windows::UI::Xaml::Interop;
    namespace WDE =       ::Windows::Devices::Enumeration;
    namespace Details =   ::Platform::Collections::Details;

    namespace PeteBrown
    {
	    namespace Devices
	    {
		    namespace Midi
		    {
			    [Windows::Foundation::Metadata::WebHostHidden]
			    public ref class ObservableDeviceInformationCollection sealed :
				    IObservableDeviceInformationCollection,
				    public WFC::IObservableVector<CollectionItemType^>,
				    WUXI::IBindableObservableVector
			    {
			        ...
			    };
			};
	    };
	};

There are likely ways to simplify the class or otherwise improve it. Happy to take pull requests. :)

MIDI Port Names

Don't like the Windows 10 / WinRT MIDI Port names? Check out this (unofficial, unsupported) PowerShell script that lets you rename them to anything you want: https://gist.github.com/Psychlist1972/ec5c52c9e4999710191d4bb07e82f98a

About

Library for C# and other apps to use Windows 10 Anniversary Update native MIDI (USB, bluetooth, etc.)

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • C++ 68.2%
  • C# 31.6%
  • Other 0.2%