Re: coremidi virtual endpoint problem
Re: coremidi virtual endpoint problem
- Subject: Re: coremidi virtual endpoint problem
- From: William Stewart <email@hidden>
- Date: Wed, 22 Oct 2008 18:00:07 -0700
James
That's what I described to you earlier - there is no way to get in the
middle of this. Either you have to have the player play to a bus on
the IAC Driver, or you could create a MIDI Destination, set that, and
then resend this received data as your own MIDI Source (so you build a
bridge between a midi destination that the music player plays to and
your midi source that then republishes that midi data to an external
client)
On Oct 21, 2008, at 12:55 PM, James Maxwell wrote:
bump...
How can I use MIDIReceived to "emit midi from virtual sources" when
the midi is coming from
a MusicSequence. This is by no means clear in the documentation, and
isn't obvious from anything that's been said in this thread. I'm not
the first to ask, so I certainly doubt I'll be the last...
I know about IAC, and it does work as expected, but as has been
mentioned many times before, IAC really isn't ideal, as it forces
the user to take care of setting up the virtual inputs and outputs.
Failing any help on this, perhaps someone could answer John's
question about programmatically creating and destroying IAC ports...
On 20-Oct-08, at 8:31 PM, <email@hidden> <email@hidden
> wrote:
Thanks Doug, But I'm really not clear how I would use MIDIReceived
when my
objective is to play from a MusicPlayer - there just doesn't seem
to be any
way of getting in there and messing around with what's going on. The
MusicSequence gets the endpoint, and the MusicPlayer gets the
MusicSequence, then you just tell it to start... How do I stick any
specialized code in the middle of all that???
Thanks again, J.
On Mon, 20 Oct 2008 14:09:14 -0700, Doug Wyatt <email@hidden>
wrote:
To send MIDI from one app to another, you want to create virtual
sources, and emit MIDI "from" them using MIDIReceived.
Applications that are aware of virtual sources will either connect
automatically to them or provide UI to connect and listen to them.
When they do this, they will receive what your app emitted via
MIDIReceived, as if your app were a hardware source.
Some applications, including some major ones, aren't aware of
virtual
endpoints. Maybe a polite email will encourage the developers to fix
their code; they've gone out of their way to exclude the virtual
endpoints and ignored the documentation.
As Bill said, the IAC driver is designed to get around apps like
this,
though unfortunately everyone has to pay some special attention to
it
because it's capable of creating MIDI feedback loops. I also don't
like the IAC driver as much because it forces the user to deal
with it
in both applications.
Doug
On Oct 20, 2008, at 11:46 , James Maxwell wrote:
Okay, so if I use a virtual destination I can at least see that
midi
is being sent, using MIDI Monitor...
But everything I read says that to send midi from a virtual port in
your own application, you create a virtual source, not a
destination. This makes sense, and is consistent with what I'm
observing, in that Logic (for example) doesn't get input from the
virtual destination, presumably because it's only looking for
sources... It sees the sources, but the midi data won't transmit
over those ports.
As I say, if I use MIDI Monitor I can see that the virtual
destination is getting the data. But, as far as what I'm actually
trying to do is concerned, which is to send midi to another app
(i.e., Logic), the virtual destinations are totally useless - that
is, they can't be selected as inputs.
So how on earth do I play a midi sequence over virtual ports to
another app, like Logic? Do I need to somehow point my virtual
destinations at my own sources? That seems like a bad idea, since I
can't see it doing anything but creating a feedback loop.
This all feels unnecessarily confusing...
If someone knows what's up with this, please, please, please,
reply.
I found one other thread with a user having the same problem, but
it
wasn't really resolved. The user was told to use virtual
destinations, instead of sources, but that **won't** get midi to
another app's inputs.
J.
On 20-Oct-08, at 10:31 AM, James Maxwell wrote:
hmm... Actually, I'm wondering whether this has something to do
with the fact that virtual outputs, which are represented as
sources (not destinations), need to use MIDIReceived instead of
MIDISend? I should mention that this is for playback from a
MusicSequence/MusicPlayer, so it's MusicPlayerStart that outputs
nothing when using my virtual ports, but works correctly when
using
the IAC bus.
So is there some special way of dealing with MusicPlayerStart when
using virtual outputs?
I'm using the same call to MusicSequenceSetMIDIEndpoint in both
cases.
J.
On 20-Oct-08, at 9:12 AM, James Maxwell wrote:
I'm setting up 4 virtual endpoints for my app - at this point
these are just sources, so they're for output to other apps. I'm
using the PYMIDI framework to simplify things, and they ports
appear to initialize correctly - no errors during init, and the
ports are visible to other apps. However, they won't send any
midi
data. If I switch the assignment to the IAC Bus, midi is sent as
expected, so it's something to do with the endpoints I'm
creating.
I contacted Pete Yandell (author of PYMIDI) about it, and he
couldn't see any problems in my code. So I'm wondering whether
anyone else has had virtual endpoint problems in 10.5.5, or if
anyone has experienced something like this and found a solution?
Thanks,
J.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden