I also tried the MuLab daw, but it opened fullscreen and largely unresponsive. The developer is easy to find, with a kvr dev forum to chat in.Ī free reverb, MUVerb, is probably worth checking. It is a locked part of the full version, without some complex reg scheme. The demo makes some average white noise at times, and is not too loud. The controls seem to work fine, and are big enough so stress is not invoked The oscillators have a handy submenu with options to modify the sound. I loaded the excellent LaGrange granular delay plugin There is a preset selector, with load/save options. The modular view is off by default, and is opened by clicking a widget,* a lot like patchage So a woodblock may have a small panel with a few basic controls, while a complex synth sound may have dozens. Lots of docs:Įach preset opens a gui suited to it's complexity, (categories are color coded) Tons of categorized presets to launch out from. Must be one of the easiest to useĪnd most flexible 'deep' synths around, as others have mentionedĪlso, it's colorful and fun. To try it out in Mint 18, generic kernel, in the latest wine-staging.Īnd what a great instrument it is. I'm not sure how you maintain long-term uniqueness with only 32 bits, but it'll hopefully be sufficient for relaunches of your app.I've read lots of good comments about MUX Modular from experienced users, so took part of the holiday I've made the assumption that 0 is an invalid unique ID, which is at least true for connections (the docs for kMIDIPropert圜onnectionUniqueID say it's "non-existant or 0 if there is no connection"). OSStatus result = MIDIObjectGetIntegerProperty(endpoint, kMIDIPropertyUniqueID, &savedUniqueId) If not saved, record the system-assigned ID OSStatus result = MIDIObjectSetIntegerProperty(endpoint, kMIDIPropertyUniqueID, myUniqueId) So maybe something like this: // Try to set the ID if it's saved. Creators of virtual endpoints may set this property on their endpoints, though doing so may fail if the chosen ID is not unique. The system assigns unique ID's to all objects. How do I retain the uniqueness of my MIDI port in between runs of my application? So I hypothesized that maybe I should keep track of this UInt32, but that seems like a bad idea.Īfter digging through all of this I feel like I'm hitting a bit of a brick wall. The out parameter for MIDISourceCreate is a MIDIEndpointRef, which according to the docs is just typedef'd to a UInt32 down the line. Except I have no idea how to assign the source a unique ID. This seems like exactly what I'm looking for. (Although you should be prepared for this to fail in the unlikely event of a collision.) This will permit other clients to retain persistent references to your virtual source more easily. So I looked at the MIDISourceCreate documentation, and read this:Īfter creating a virtual source, it's a good idea to assign it the same unique ID it had the last time your application created it. Save our api-specific connection information. OSStatus result = MIDISourceCreate( data->client,ĬFStringCreateWithCString( NULL, portName.c_str(), kCFStringEncodingASCII ),ĮrrorString_ = "RtMidiOut::initialize: error creating OS-X virtual MIDI source." void RtMidiOut :: openVirtualPort( std::string portName )ĬoreMidiData *data = static_cast (apiData_) ĮrrorString_ = "RtMidiOut::openVirtualPort: a virtual output port already exists!" The client parameter is (what I presume after browsing the docs) an identifier for my application, it being a client of the CoreMIDI services. All that the MIDISourceCreate asks for is a string. So I dug into the RtMidi source, and the CoreMIDI wrapper seemed straightforward enough. I know it's possible to retain some uniqueness of a virtual midi port, since MidiKeys behaves just as I'd like my application to behave: my DAWs remember it even if MidiKeys closes and re-opens while my DAW is still running. "My DAW" in this case is Reaper 4, but I've duplicated the behavior in Pro Tools, Logic, and MuLab. I was originally using pyrtmidi, so went and verified the behavior writing in C++ directly with RtMidi. However, if my program closes and I open it again, my DAW does not recognize the input device as the same port, despite being given the same name. I use RtMidiOut::openVirtualPort("MyAwesomePort") so I can select my app as an input source in a DAW. I'm working on a little hack sending MIDI messages from an app using RtMidi as a wrapper for CoreMIDI on OS X.
0 Comments
Leave a Reply. |