Duplicated MIDI messages between apps?

104 views
Skip to first unread message

Jonatan Liljedahl

unread,
Jan 3, 2013, 6:02:35 PM1/3/13
to open-music-app...@googlegroups.com
Hi,

I just thought of this potential problem, and wonder what you others think about it.
Say we have two apps, one with a virtual midi source and one with a virtual midi destination. Both apps allow the user to connect to specific endpoints.

Imagine this scenario:
App A sends to its own virtual port (outgoing traffic from A) as well as to app B's virtual port (incoming to B), since the user checked "app B" in the midi output settings. In the same way, user checked "app A" as midi source in app B.

Wouldn't this fire app B's midi-input-callback twice for every message, since it would be receiving the same data on two endpoints: app A's virtual output and its own virtual input?

How would you avoid this? Or perhaps I'm misunderstanding something...

Cheers
/Jonatan

Amos

unread,
Jan 3, 2013, 7:45:12 PM1/3/13
to open-music-app...@googlegroups.com
I believe this happens.  I've encountered apps which establish such a double-connection (er, Animoog can be one of them) and if there's a standard way of handling this condition gracefully I don't know it.  I'd like to, though :)
-Amos

Jesse Chappell

unread,
Jan 3, 2013, 8:29:43 PM1/3/13
to open-music-app...@googlegroups.com
Yes, app B would receive duplicate data, and the answer is to educate
users *not to do that*!

Either receive only from another app's virtual port, or send to one,
but not both. This can be even more troublesome when midi clock is
involved. The problem occurs most on apps that automatically attach
to someone else's virtual port, then the user manually sends to the
app from another.

Perhaps we can come up with best practices for apps' default
behaviors, in order to reduce the chance of the user falling into the
trap.

jlc

On Thu, Jan 3, 2013 at 6:02 PM, Jonatan Liljedahl
<j.r.li...@gmail.com> wrote:

Jonatan Liljedahl

unread,
Jan 4, 2013, 6:35:29 AM1/4/13
to open-music-app...@googlegroups.com
Ok, interesting!

One could send only through ones own virtual midi port (and hardware ports) and not even list other apps virtual ports, but that would depend on the receiving app being able to connect to the sending apps port. It would mean that you only use virtual midi sources, no destinations.

Or perhaps the other way around would be even better: Never create virtual midi sources, in a sending app just display a list of available midi destinations (including virtual midi destinations). In a receiving app, create a virtual midi destination, and display a list of available midi sources (which would contain only hardware ports and the network session). If all apps did this, it would be fine. You would just connect to the destinations you want in the sending app. However, this is not reality today..

Would it be possible to detect the case when a user makes such a double-connection? One could then disable one of the connections and show some alert explaining how it works.

/Jonatan

Amos

unread,
Jan 4, 2013, 10:23:28 AM1/4/13
to open-music-app...@googlegroups.com
On Fri, Jan 4, 2013 at 6:35 AM, Jonatan Liljedahl <j.r.li...@gmail.com> wrote:
Would it be possible to detect the case when a user makes such a double-connection? One could then disable one of the connections and show some alert explaining how it works.


Perhaps test for the condition where MIDI is received on more than one port within a given session; then if this is the case do a test on MIDI message receive; compare the current message to the most recent message received on the "other" port.  If you find an identical message on the other port (you could also test for time offset between the two messages to be sure they arrived near to each other in time), this could identify the double-connection case.

Jonatan Liljedahl

unread,
Jan 4, 2013, 11:11:47 AM1/4/13
to open-music-app...@googlegroups.com
Something like that could work, yes, but could only be done in the receiving app. My app is only sending, and I wonder if it would be possible to detect the actual connection. So, if OtherApp connects to my virtual midi source, and the user has also choosen OtherApp's virtual midi destination for output, then we see that there's a double connection. It could work if 1) we get a notification when another app (dis)connects to our own port, and 2) we can know the name of this other app and match it against the list of available destination ports.

/Jonatan

Jesse Chappell

unread,
Jan 4, 2013, 11:52:56 AM1/4/13
to open-music-app...@googlegroups.com
I've looked in the CoreMidi docs and I don't see any way to list or
detect connections that other apps make to your own virtual midi
source. I would be happy to be wrong, but my expectations are not
high.

jlc

On Fri, Jan 4, 2013 at 11:11 AM, Jonatan Liljedahl

Sebastian Dittmann

unread,
Jan 4, 2013, 12:01:24 PM1/4/13
to open-music-app...@googlegroups.com
Hi guys,

Just a heads-up: we intend to solve this with Audiobus.
Of course this will only solve it for Audiobus users.

Best,

Sebastian

Jonatan Liljedahl

unread,
Jan 5, 2013, 12:24:59 PM1/5/13
to open-music-app...@googlegroups.com
Looking forward to that, Sebastian!

In any case, the current state is a big problem. For example, here's a typical case of a user wanting to sync the sequencer in Magellan with the clock from Loopy:

- Start Magellan and Loopy HD.
- In Magellan, select "external clock".
- In Loopy, select Magellan for "Clock output".

Seems quite logical that this should work, but in fact Magellan will now receive double midi clocks, making the tempo twice as fast.
It's not very obvious that you should actually *not* select Magellan for "Clock output" in Loopy, because Magellan will receive directly from Loopy's virtual midi source, and has actually no way of not doing that.

Wouldn't the best solution be that no apps ever should create a virtual midi source, but that they should always create a virtual midi destination (if they can receive midi)? And then you choose in the sending app which other apps you want to send to.

I'm currently working on a MIDI settings screen for Gestrument, and trying to figure out what the best way is. Should I create a virtual midi source or not? If not, then it won't be able to send to apps that doesn't have their own virtual midi destination. But if I do, users will very easily make double connections. I'm leaning towards not creating a vm source, and explain that "Gestrument can only send MIDI to apps that has a Virtual MIDI port".

Cheers
/Jonatan

Nic G (Audeonic Apps)

unread,
Jan 5, 2013, 12:48:44 PM1/5/13
to open-music-app...@googlegroups.com
Magellan listens to all ports in the system, so could be classed as a 'badly behaved' MIDI implementation. :-)
(lots of big names fall into the same category; Apple, IK & Korg spring to mind)

Use Rolf's 'little manifesto of best practices' document found in this group which is the closest thing we have to a standard for implementing virtual MIDI. Please do define a virtual source and dest in your app, and allow your user to enable/disable which sources your app listens to.

Nic.

Jonatan Liljedahl

unread,
Jan 5, 2013, 1:43:43 PM1/5/13
to open-music-app...@googlegroups.com
Well, that manifesto doesn't mention the problem with double connections.

The only point in creating a virtual midi source (for midi output) would be to support apps that don't have a virtual midi destination but just listens to all available ports. If all apps receiving midi just created a virtual destination port, there wouldn't be a problem of double connections, afaict.

/Jonatan

Nic G (Audeonic Apps)

unread,
Jan 5, 2013, 2:56:24 PM1/5/13
to open-music-app...@googlegroups.com
No, the manifesto doesn't solve the problem. As Jesse says, user education is key here; and with flexibility comes danger.

Making the user select which port(s) an app listens to mitigates the problem somewhat (or selecting the output in a controller).

Your observation holds, but just about every dev has implemented CoreMIDI in their apps differently with varying levels of configuration vs hardcode, so you have to take this on board.

If you limit Gestrument to only controlling apps that have defined a virtual destination, then your users won't be able to control GarageBand or the Korg apps (without some sort of bridging app) for example.

I think it is better to offer your users the ability to control both kinds of apps, and in your case to solve the double connection to Magellan and SampleTank (the only two apps I can think of that behave this way) you make your users specifically select or even consider only allowing one virt. destination at a time. You're going to have to make the call in the tradeoff of flexibility vs safety yourself ultimately. ;-)

Nic.

Jonatan Liljedahl

unread,
Jan 5, 2013, 5:40:20 PM1/5/13
to open-music-app...@googlegroups.com
Ah, yes, choosing between two exclusive modes would fix it:
1) send only on "Gestrument" virtual source port
2) send to one or more virtual destinations

The cases where one would need both at the same time is probably rare
enough to not support it.

However, how do I detect if a destination is virtual or not?
--
/Jonatan
http://kymatica.com

David Warman

unread,
Jan 5, 2013, 6:42:32 PM1/5/13
to open-music-app...@googlegroups.com
Apps like Sequencers, MidiBridge, and potential future MIDI EFX Apps, would need to support both IN and OUT Virtual MIDI Ports.

This mess could have been avoided by Apple had they not ignored their own lessons from OS X. There might have been a rational pattern to follow. For example, all Apps must present the user with a list of available ports to which to listen. And never automatically deliver all incoming from all ports to any listener by default (or not even possible as in OS X).

As it is, I agree there is ony one solution and that is user education. I am very impressed with what the author of the Genome Sequencer did - a whole page dedicated to discussing Virtual MIDI.

Extending that with a discussion of configuration patterns (a crib sheet?) - like, e.g., using MidiBridge with conforming Apps and also with unsophisticated Apps. Or Any other combination of sources and sinks - like, say, connection topology vs who selects what preferred setups in tabular form. I'm probably going to write something like that for myself anyway, if that is of interest.


On Saturday, January 5, 2013, Jonatan Liljedahl wrote:
Ah, yes, choosing between two exclusive modes would fix it:
1) send only on "Gestrument" virtual source port
2) send to one or more virtual destinations

The cases where one would need both at the same time is probably rare
enough to not support it.

However, how do I detect if a destination is virtual or not?

On Sat, Jan 5, 2013 at 8:56 PM, Nic G (Audeonic Apps) <ap...@audeonic.com> wrote:
> No, the manifesto doesn't solve the problem. As Jesse says, user education
> is key here; and with flexibility comes danger.
>
> Making the user select which port(s) an app listens to mitigates the problem
> somewhat (or selecting the output in a controller)
>
> Your observation holds, but just about every dev has implemented CoreMIDI in
> their apps differently with varying levels of configuration vs hardcode, so
> you have to take this on board.
>
> If you limit Gestrument to only controlling apps that have defined a virtual
> destination, then your users won't be able to control GarageBand or the Korg
> apps (without some sort of bridging app) for example.
>
> I think it is better to offer your users the ability to control both kinds
> of apps, and in your case to solve the double connection to Magellan and
> SampleTank (the only two apps I can think of that behave this way) you make
> your users specifically select or even consider only allowing one virt.
> destination at a time. You're going to have to make the call in the tradeoff
> of flexibility vs safety yourself ultimately. ;-)
>
> Nic.
>



--
/Jonatan
http://kymatica.com


--
- David Warman

Nic G (Audeonic Apps)

unread,
Jan 6, 2013, 4:30:52 AM1/6/13
to open-music-app...@googlegroups.com
On Saturday, January 5, 2013 10:40:20 PM UTC, Jonatan Liljedahl wrote:
However, how do I detect if a destination is virtual or not?

 
AFAIK there isn't anything specific in an endpoint's data that tells you this definitively, although for a virtual endpoint the device name is NULL but sometimes devices have a NULL there too, so not always reliable. I ended up enumerating the hardware to figure out the complement, which takes a bit more effort.

Or if you're using the OMAC registry you can also correlate an app's virtual MIDI port name.

Nic.

Jonatan Liljedahl

unread,
Jan 6, 2013, 7:52:07 AM1/6/13
to open-music-app...@googlegroups.com
I think this one should do it:

MIDIEndpointGetEntity()

the endpoint's owning entity, or NULL if none.

Virtual sources and destinations don't have entities.

So, if this returns NULL, it's virtual.

Jonatan Liljedahl

unread,
Jan 6, 2013, 7:54:33 AM1/6/13
to open-music-app...@googlegroups.com
On Sun, Jan 6, 2013 at 12:42 AM, David Warman <dwa...@davidwarman.net> wrote:

> As it is, I agree there is ony one solution and that is user education. I am
> very impressed with what the author of the Genome Sequencer did - a whole
> page dedicated to discussing Virtual MIDI.

Do you have a link to that page, or is it in-app? (I don't own Genome)

--
/Jonatan
http://kymatica.com

David Warman

unread,
Jan 6, 2013, 11:44:08 AM1/6/13
to open-music-app...@googlegroups.com

David Warman

unread,
Jan 6, 2013, 11:52:52 AM1/6/13
to open-music-app...@googlegroups.com
I'd add one little tidbit I learned the other day to his order of startng things up: if you are using Audiobus, apparently the glitchy sound problem can be made to clear up if you start NLogPro first even if you are not going to use it. It seems that establishes a 512 sample buffer depth which everybody else uses. Otherwise some use 256 and some 512, and bad DSP ensues. Perhaps there are people here who could expand on this?
--
- David Warman

Rob Fielding

unread,
Jan 6, 2013, 12:30:07 PM1/6/13
to open-music-app...@googlegroups.com
:-(  Gah!  Latency setting fights.
 
Geo had this problem when it came out because if we saw that somebody set the latency high behind our back (512, 1024 - simply unplugging the headphone jack was often the cause, but it could have been a different app that wanted this!) then we would set it back to 256 if our engine was on.  So for apps that insisted on high latency while using us as a controller, we would have them turn off our sound engine before turning them on.  Some apps even just *assumed* that the buffer size was 1024 and never even set it, so we would recommend some app to start to set it for us.   ... a lot of apps are not (ergonomically) playable so that 1024 is fine - so they glitch at 256; but for what we do, a buffer setting higher than 256 is essentially broken for us because it's easy to play very fast on it.   Actually, 256 is still too high, but it's as good as you can practically get on an iPad, because touches have latency coming into the hardware too.  Pro audio environments try to write chunks of 64, which it the point where you will stop having musicians complain about latency when doing the hard stuff.
 
 
 

Sebastian Dittmann

unread,
Jan 7, 2013, 4:14:05 AM1/7/13
to open-music-app...@googlegroups.com

On Jan 6, 2013, at 5:52 PM, David Warman <dwa...@davidwarman.net> wrote:

> Perhaps there are people here who could expand on this?

Don't despair, there might stil be hope.

We're encountering a new user behaviour which seems to affect many (if not all) Audiobus users. They are starting Audiobus first and then launch apps from that, even if they wouldn't actually need to run them incombination with Audiobus. The main reason for this might be that they like the connection panel which allows them to fast switch between apps.

The very positive aspect of it is that the first app that is launched which does recording, sets the general buffer size for the audio buffer for all apps until it is closed.
Currently that is 256 frames but we're strongly considering to increase that to 512 on iPad 2, iPhone 4S and iPad mini because those devices are just not fast as fast as we'd like them to be.

We're also considering to add a buffer size switch in the system preferences app for Audiobus where users can change this.

So in the long run, a large chunk of iOS musicians will be launching their apps in a way that lets developers predict what buffer size is the prevalent one.


Sebastian

Jonatan Liljedahl

unread,
Jan 7, 2013, 5:37:05 AM1/7/13
to open-music-app...@googlegroups.com
I'm not sure how this other favorite topic of mine ended up in this
thread, but this is great news, Sebastian :)
Putting the switch in the system prefs app sounds like a good idea, so
it will not clutter the UI for people who don't need it. But that
depends on having good device/model-specific defaults, so its good to
hear you're considering this.

--
/Jonatan
http://kymatica.com
Reply all
Reply to author
Forward
0 new messages