It gave me the basic ideas on what we can/should provide in any platform and what not.
#Linux renoise software#
Web MIDI support in early days was not actually great for Linux software synthesizers (Chrome supported only Mac at first, and software synthesizers need special permission to be enabled), but its API structure was informative. It is expected to be working on Web browsers, but right now it is only Chrome which supports it. There has been another effort to bring MIDI to cross-platform world - Web MIDI API. The primary reason I was developing managed-midi was to write usable MIDI application. The abstraction was done only as MidiPlayer class (then I had PortMidiPlayer and RtMidiPlayer). There was still no proper abstraction, but it was implicitly done. Moreover, the development was active (at that moment).
It had the same issue as portmidi too but didn't require JNI stuff, so building binaries was not so painful.
Unfortunately it was C++ only, so I wrote C wrapper for that (which I ended up to contribute to the project). I almost dumped the idea of offering binaries by myself.Ī few years later, I found RtMidi and it was simpler.
#Linux renoise windows#
And it has to be offered in 32bit for Mono (which supported only 32-bit x86 on Windows at that time) and 32bit binary didn't work on. portmidi was painful to me on Windows since it required JNI header files to build. Since portmidi is a pure third-pary library it always required binary shared libraries. NET runtime has been always Mono, and I was primarily on Windows at that time. It was however somewhat messy to get apps that are based on this library working. There wasn't even appropriate abstraction. I just wanted an SMF parser and a MIDI player that plays MIDI songs that I can compose using my music macro language compiler mugene. I think my idea was good (I still kind of) - it is important to quickly get what we need, right? Those smart native developers dealt with the platform specifics, and I made use of the outcome. Instead, I wrote a P/Invoke wrapper and OO-style API around it.
I didn't want to deal with platform-specific MIDI APIs, especially whatever I was not familiar with. We are seeing new-generation DAWs working on Linux (Renoise, Bitwig Studio, Tracktion WaveForm etc.).īack in 2009 when I started launching this project among other small projects I had in mind (when this project didn't even have a name and repo), I found PortMIDI, which is a cross-platform MIDI library that supports Windows, Mac and Linux, and I found it cool. VST is now available on Linux too (I mean, the original library from Steinberg). The situation in C++ world is however changing. It is kind of ironic that MIDI features are categorized within very platform specific API groups, whereas MIDI itself is designed to be device independent. This development situation is similar to developing "bait-and-switch" PCLs, but like I generally don't care about Mac and UWP, people don't care about platforms they don't use. This is a typical huge problem in C# developer ecosystem that they only care about Windows.Īudio and music libraries are always like that, and few people have interest in cross-platform AND platform specific development. My primary desktop is GNOME on Linux, so it's no-go. Wasn't there any existing effort to provide Midi access API? The only project I can think of is NAudio, which only cares about Windows.
This is my primary motivation to develop this library.īut I'm going to discuss cross-platform part. It's more of a structured music composition as well as messaging foundation. My "cross platform" here is not a marketing term it targets Linux (ALSA), macOS (CoreMIDI) and Windows (WinMM), along with Android, iOS and UWP.Īctually, my managed-midi project is not about cross-platform goodness. I have a (surprisingly) long term project called "managed-midi" which is to offer cross platform C#/.NET MIDI access API.
0 kommentar(er)
