Global midi follower not global?

I don't have VDMX or Ableton. But, your patch works just fine for me to receive notes and velocities from the little freebie app MIDI Keys. I have run a slight mod of your qtz also as a player inside of Coge with successful results: the last note and velocity are correctly displayed. So, I am guessing that the plugin architecture of VDMX or the publishing architecture of Ableton are the source of your problems.

Remember that there is no "MIDI bus" inside of OSX. There are physical devices, and the IAC driver. The IAC driver does all inter-app MIDI. So possibly the "to VDMX" connection from Ableton (which goes through the IAC) is truncated in the implementation of the VDMX plugin api, so no message get forwarded over to the qc engine running the plugin? Logic along the lines of "this qc plugin Note2Value.qtx is not VDMX, I'm VDMX, so why should I send it a message that was only meant for ME!"

You can probably work around this with a virtual patcher such as MIDI Patchbay, and route your Ableton Messages to the IAC input and then from IAC input to IAC output, so the message becomes visible to every application including the qc engine.

But I would talk first with the VDMX guys about how THEY would solve this. It's either a limitation of their code or they've got a routing solution themselves.

Paul

OK, I think I've got this sorted. Quartz Composer patches will only see physical and IAC driver ports. Ableton has to publish its MIDI out to an IAC port. QC just will never see virtual MIDI sources and destinations provided by other applications. Same for QC editor, VDMX plug, Coge plug.

If you need to see only notes coming from Ableton and you want them to go to VDMX also, then you must publish to IAC in Ableton and subscribe to it in VDMX. Your qc plug will see it automagically.

You could ask the guys at Kineme to build a MIDI port patch to let you discover virtual ports (for MIDI input) or even create virtual ports (for MIDI output). I'm sure the xcode AudioMIDI frameworks make that straightforward for an Objective C programmer. Then the Kineme MIDI Tools could use them, I would presume. But short of building a new plugin and updating the MIDI Tools, I don't think you can get your patch to listen directly to Ableton output directed to the "VDMX Input" port.

However, if you need some separation and control, remember that you can add and rename ports on the IAC Driver in AudioMIDI Setup utility. And with something like MIDI Patchbay you can republish messages from one port onto others. So, you certainly can set things up so that your patch either gets ONLY "VDMX Input" directed messages, or gets all messages INCLUDING "VDMX Input" directed messages.

There. Enough ideas for you?

-Paul

UPDATE: Okay, and on top of the above, the "Source Filter" port on the Global MIDI patches can be used, together with the various IAC Driver ports you have (renamable) to focus the qtz on the universe of interest. Voila! Pretty complete solution without writing a new patch. -Paul

Thanks Paul, ur such a helpful dude. "Quartz Composer patches will only see physical and IAC driver ports. Ableton has to publish its MIDI out to an IAC port", yep that's what I had confirmed and was asking why in the first place, more to understand the infrastructure of midi in osx in general. ableton's "to vdmx" still works when the IAc device is disabled so it seems there is a more private handshake going on.. I did indeed have it working through the IAc but was wondering why the "global" midi listener didn't listen to the ableton-vdmx midi link. I was wondering how to use the source filter input, do you get it working in practice? The filter input would have to distinguish between IAC and physical controllers, and then the ports on the iac, correct? So a kind of key structure to stipulate the parent device?

btw i have no idea how I created a forum post in triplicate.

I'm kinda feeling my way thru this stuff, too. I need a conceptual framework for everything in life, I guess. But I think the key is that physical devices and the "IAC Driver" in fact have driver software in the os. Even if they are USB babies that just use the generic Apple USB/Midi drivers all physical devices fit this. So, They all get "registered" when the internal osx MIDI server process gets started up the first time your machine even thinks about midi. And the IAC driver gets started too if you click it to be "Online" in Audio MIDI Setup. Every application that hooks up to the MIDI server, including instances of Quartz Composer engine, will see those devices. After that, you are into xcode CoreMidi API land: applications can choose to register driverless virtual midi devices with ports that input and output MIDI, and applications can go looking for them. Simple CoreMIDI stuff. But it is up to the xcode developer to implement code to look for or use these devices.

Just for instance, the Apple MIDI patches in Quartz Composer implement some of this logic in the Settings. You can see your "To VDMX" port there in the selection list. Kineme did not do that. In fact, I don't really understand what they did. I think it was mostly CWright before he went to Apple, and it does some odd things. As I said before, we could always ask or sponsor Kineme to add that stuff. It's a feature request and a reasonable one.

But the Kineme GLOBAL patches do definitely "see" every set of ports that you define in the IAC Driver. These ports are features of the IAC Driver "device" so they just appear to midi applications. And the filter (just a string comparator) really does work pretty well. Especially since you can follow your own naming convention in the IAC port definitions.

You know, after all this discussion, I have discovered that GLOBAL Midi patches WILL respond to virtual MIDI devices from apps. Now I do not know about VDMX, but this is true for MidiKeys and CoGe, which can publish MIDI messages that are sent "From" an app. The critical factor is that the Source Filter of GLOBAL Midi patches must include a substring of the name of the port with an output connection enabled.

However, if an app does not publish outbound MIDI messages under its own name, but is ONLY directly connected to another app, then GLOBAL Midi is unable to monitor those messages. This makes perfect sense. Two apps can establish a private MIDI connection this way, just as if they had a physical MIDI wire from the MIDI Out of one to the MIDI In of the other. If they publish as a virtual From "name", it is kind of like they plugged into the MIDI Thru of the internal MIDI Server...the message goes out on the MIDI Out of the Server to anyone connecting.

The one totally peculiar thing (to me) about this (and the reason this thread got started at all) is that IF the Source Filter string is null, THEN the GLOBAL Midi patches will ONLY look at ALL physical and IAC Driver ports. This may be a peculiarity of the way Kineme coded it, or a peculiarity of the way the CoreMIDI API works, or some combination.

So, to summarize: GLOBAL Input Midi Follower will respond to (a) messages from any MIDI physical device with MIDI Out, (b) any messages that go into an IAC Driver port with a MIDI Out connection, and (c) any messages from an application with a virtual MIDI device that publishes as having a From MIDI Out port connection (as long as the Source Filter string includes a substring of that published From name). When an app establishes a connection To any device (physical or virtual) other than the IAC Driver, then any messages sent To that device are not seen by GLOBAL Input Midi Follower. For physical and IAC Driver originated messages, any non-nul Source Filter string must match a substring of the device name.

In the two cases of apps that I tested, MidiKeys only allows one outbound Destination at a time. It is visible to GLOBAL Midi as "MidiKeys" when the Destination is set to "Virtual", and not visible otherwise. Coge allows messages to be sent out to multiple destinations simultaneously by checkbox including a From Coge. Messages are visible to GLOBAL Midi as "From Coge" when this is check, and not visible otherwise. With both cases, if the destination includes an IAC Driver port, then the output is visible to GLOBAL Input Midi Follower.

Oh boy, I know so much more about OSX MIDI now than when we started playing this game!

-Paul