A Little Manifesto of Best Practices

[nlogmusic]

Hi All,

I put some ideas, experiences and best practices together to explain
what I mean by alls this:

https://docs.google.com/document/d/1UW-8vPEf95p0zO0hV1lpwD5MTgefKB1y-jdWR-nFYM8/edit?hl=en_US

I am very happy to receive feedback and see some discussion here if it
matters or not and about further ideas. Input is welcome from
everybody esp. developers AND musicians.

Cheers
Rolf

[Morten]

"- An external MIDI controller plays a synth app running in the
background while the
iOS interface is used for an app in the front triggering loops"

Let´s say you do this.
Will you then be able to control both the background app and the
active app with the external MIDI controller, or will the active app
just be controllable via the iOS interface itself?

Can it be done to make a button (or something) in the active app to
send a midi signal to the background app to change patches, for
instance?


- Morten

On Aug 21, 11:22 am, nlogmusic <nlogmu...@googlemail.com> wrote:
> Hi All,
>
> I put some ideas, experiences and best practices together to explain
> what I mean by alls this:
>

> https://docs.google.com/document/d/1UW-8vPEf95p0zO0hV1lpwD5MTgefKB1y-...

[Sebastian Dittmann]

Hi Morten,

Don't know about changing patches but I've successfully used accelerometer based MIDI CC messages from SoundPrism Pro to control parameters of the existing Patch in Nlog Pro Beta.

However Rolf and me agreed to not make this first implementation anything special in regards to SoundPrism using a dedicated tool inside the app to send messages dedicated to Nlog only.
What we want to achieve is to create an example of how iOS applications - not just SoundPrism and Nlog - can work together. Therefore the first implementation of this will not feature any specific Nlog/SoundPrism stuff.

It's really just intended as a message to other developers that we think this is the future and that we're open for collaboration with any iOS app developer who thinks this is the future.

Best regards,

Sebastian Dittmann
CEO Audanika GmbH

[nlogmusic]

Hi

in regards to the first point: Yes, MIDI coming from external can
control any app, i.e. the one in the foreground as well as the others
running in the background.
The prerequisite is only, that the app is listening to the external
device.

For the second point, yes, the MIDI standard defines messages to
change patches. If the apps in the background implement these messages
that should work.

cheers
Rolf

[Greg W]

Very excited about the recent developments, and this group is a great
idea. Nice work pulling all the important info together.

[Nic Grant (Audeonic Apps)]

Interesting document.

One of the issues that could be problematic that I'd welcome ideas on
is how
an app that does not do audio can remain in the background under
Apple's
multitasking rules. None of the 3 multitasking categories (gps, voip,
audio)
would apply to a MIDI only app running in the background unless Apple
change/bend the rules. There is a 'continuous' category but that
wouldn't
make it into the app store since it would be considered 'private'.

- Nic

[nlogmusic (TempoRubato - NLogSynth)]

You could just go into audio
background mode, run an audio session but deliver only zeros. That
should
not be too critical in terms additional performance consumption. Well,
Apple
may accuse here of 'faking' things, so why not have a little metronome
(click)
optionally played to justify in case Apple review complains ;-)

But maybe somebody else has a better solution, anybody?


On Aug 23, 10:59 am, "Nic Grant (Audeonic Apps)" <a...@audeonic.com>
wrote:

[Nic Grant (Audeonic Apps)]

For a different app I was able to set my app as voip (even though it
wasn't) to get it remaining in the background and Apple didn't
complain. I did try sending zeroes to the audio port as you suggest
but I found it problematic to reliably restart the zero audio stream
on interruption while in the background. Also this app runs 24/7 so
running an audio stream wasn't really an option.

I suspect 'location' background mode would be the only viable
alternative, but may not pass Apple's gatekeepers. I plan to try it on
in the future if I can though. :-)

- Nic.

On Aug 23, 10:12 am, "nlogmusic (TempoRubato - NLogSynth)"

[nlogmusic (TempoRubato - NLogSynth)]

I guess the Apple Audio/MIDI folks are already "watching us" ;-)

Seriously, anybody from Apple reading this, please get in contact!

We can help to implement this in GarageBand ;-)

On Aug 23, 11:46 am, "Nic Grant (Audeonic Apps)" <a...@audeonic.com>
wrote:

[finger]

Hi All,

I think it would be useful if developers provide a MIDI Implementation
Chart (http://www.midi.org/techspecs/midi_chart-v2.pdf) for their
apps. That would help users to judge the compatibility between apps
and/or connected devices.

Best,
Markus

On Aug 21, 11:22 am, nlogmusic <nlogmu...@googlemail.com> wrote:

> Hi All,
>
> I put some ideas, experiences and best practices together to explain
> what I mean by alls this:
>

> https://docs.google.com/document/d/1UW-8vPEf95p0zO0hV1lpwD5MTgefKB1y-...

[Greg W (polychord)]

Great idea, Markus.

[Tibor (Audioforge Labs)]

Hi guys,

I just wanted to introduce myself and thank Rolf and whoever was
involved in figuring it out!
I have not implemented midi in my apps yet as I am manipulating wave
files and not midi data.
However, this concept opens up a whole new level of apps. So while I
cannot support the midi connect (or whatever the name will be) I am
planning on writing my next experimental app entirely around it!

Cheers,
Tibor
Audioforge Labs Inc
http://www.audioforge.ca

[nlogmusic (TempoRubato - NLogSynth)]

Hi Nic

does the Midi Bridge run in background mode and can connect also
virtual ports?
Would be great!

Cheers
Rolf

On Aug 23, 11:46 am, "Nic Grant (Audeonic Apps)" <a...@audeonic.com>
wrote:

[Nic G (Audeonic Apps)]

Hi Rolf,

The version that is available now doesn't. I only found out about this
movement after it was released.

I have updated the midi engine for both my apps (MidiVision &
MidiBridge) to offer and recognise virtual ports.

In the case of MidiVision I'm just finishing off adding CoreMIDI
support and other enhancements and when that is done, tested and
released it will.

With MidiBridge, I have to either let Apple allow it to be
backgrounded continuously or do your zeroes to audio trick and
hopefully one of those techniques will work and it will be
backgroundable and ViCable compatible.

Nic.

On Aug 25, 11:19 am, "nlogmusic (TempoRubato - NLogSynth)"

[humbletune]

Hi Rolf. I am having some troubles getting my app working with
soundprism. I am using Pete Goodliffe's implementation of coreMIDI
where I can receive midi messages with the help of a midi session
running on my computer. But just on the device I get nothing. I am
guessing it is to do with the virtual ports maybe.

Any more information on how to connect them up would be most
appreciated. From my understanding the virtual ports are not actual
midi ports but MidiEndPointRef…

I am also a bit confused about the MIDIObjectSetIntegerProperty. What
is the value that this should be?

Thanks.

ERik

[nlogmusic (TempoRubato - NLogSynth)]

Hi

yes, you have to set up virtual midi ports as described in the
manifesto.
If you just want to listen for SoundPrism or other controllers, you
need just
this:

ret = MIDIDestinationCreate(client, (CFStringRef)name,
NLogMIDIReadProc, self, &virtInput);
ret = MIDIObjectSetIntegerProperty(virtInput,
kMIDIPropertyUniqueID, NLOG_VIRT_INPUT_ID);

The second line is pure optional. It makes me easy to identify my own
virtual
port. For example I do not want to listen to my own virtual output ;-)
Data type of virtInput is for sure MIDIEndpointRef, calling them vulgo
'ports' has
some hope that app users will understand 'port' more probable than
'endpoint references' ;-)
The NLogMIDIReadProc is the usual MIDIReadProc type like

static void NLogMIDIReadProc(const MIDIPacketList *pktlist, void
*readProcRefCon, void *srcConnRefCon)

And I guess, you have the special beta of Sound Prism from Sebastian?

Cheers
Rolf

[Sebastian Dittmann]

On Aug 29, 2011, at 10:25 PM, nlogmusic (TempoRubato - NLogSynth) wrote:

> And I guess, you have the special beta of Sound Prism from Sebastian?
>
> Cheers
> Rolf

Yeah he does.

-
Sebastian

[humbletune]

Cheers for the quick reply. Yes Sebastian was kind enough to share it.
Hmmm, that is all I have to do then. What about the (CFStringRef)name,
does that have to be anything special? Don't think so, but worth a
shot.

ERik

[nlogmusic (TempoRubato - NLogSynth)]

It is a good idea to give it your app name that other apps can present
users a list of existing ports with meaningful names. Core MIDI itself
does not care, and programmatically I would use the ID as described
below.

What also needs to be done is, that one of both apps actually creates
a
MIDI connection. In the case of SoundPrism, SP just connects to
whatever
port is found including your virtual one. With other apps like MoDrum
one side (regardless which, but not both) have to create a connection.

[humbletune]

Cheers. That might be it then. Have to look into that. :) I can see SP
triggering my kMIDIMsgSetupChanged.

ERik

[Rob Fielding]

Does anybody still want to use geo to test? If you work on sound generating app, send udid. I know that some of you are low on your own udids.

http://rfieldin.appspot.com

The midi messaging is exotic to get full poly fretlessness working, so a lot of cases that a normal controller will miss, described in problem cases in my midi ios entry in blogspot:

Http://rrr00bb.blogspot.com. ... Second to last post.

It describes a NRPN to allow for full resolution pitch bend across entire range too (instead of change pitch wheel resolution, add a cross-channel note tie)

Sent from my iPhone

[humbletune]

Ok, sorry to bother you again Rolf. My final question, I think, so
when SP connects to my virtual port, it must trigger my code, right?
So how do I get a source to connect to my virtual port rather than my
inputPort? This is what the code I have does right now:

- (void) connectSource:(MIDIEndpointRef)endpoint
{
PGMidiSource *source = [[PGMidiSource alloc] initWithMidi:self
endpoint:endpoint];
[sources addObject:source];
[delegate midi:self sourceAdded:source];

OSStatus s = MIDIPortConnectSource(inputPort, endpoint, source);
NSLogError(s, @"Connecting to MIDI source");
}

Well, I guess you can tell I don't really know what is going on, but I
can see the source is connecting to the inputPort, but how does the
virtual input fit in to it? I am sorry for being stupid and
annoying...

ERik

[nlogmusic (TempoRubato - NLogSynth)]

Hi Erik,

I cannot tell much specifics about the PG... classes from the example
app
since I do not know it. I guess its design needs to be adapted a bit
for
virtual ports.

But right, when connecting two apps A & B (for sending data from B to
A)
here is what needs to be done:

So, if app A creates a virtual input, then app B sees that input as a
MIDI Destination
as any other available virtual or non-virtual MIDI destination
available via
MIDIGetDestination(i) etc. App A does not create this connection, but
app B
can write to it us usual with MIDISend. Thus, if you have a virtual
input
you do not call MIDIPortConnectSource for it within app A.

Or alternatively, if app B creates a virtual output, app A sees that
output
as a MIDI Source it can connect to with MIDIPortConnectSource. App B
write to the virtual output with (strangely named) MIDIReceived.

Again, only one of both methods need to be done, otherwise you are
getting data twice.

Keep care, if you app creates a virtual output & input that you do not
connect with MIDIPortConnectSource to your own virtual output ;-)

Cheers
Rolf

[Jonah]

I'm speaking more as a musician than a dev. A few points:

1)If each app isn't spitting out it's own audio file running multiple
programs at once is of limited usefulness.

2)Recording multiple instances of the same synth is extremely common
with a traditional DAW, but you can't load the same app multiple times
on iOS. I'm not going to buy 10 synths and learn them all just to get
10 tracks going. I guess MIDI channels are the best solution?

3)How do you keep track of CPU usage and keep the user aware of it? It
appears someone has to make a controller/host app that monitors CPU
usage, the audio recording and probably MIDI routing and timing issues
so the user doesn't have to faff around with it and worry that things
could come crashing down at any moment. It would say "hey, this is all
you can reasonably run now" and hopefully give some rough numbers so
the user can learn for next time how much they can have going on.

I dunno, Windows and OS X programs can't even operate this easily. For
example managing multiple MIDI channels in a DAW and recording them
isn't that enjoyable and a bit of a chore. A closed system like Reason
is the closest equivalent that "just works" and on a related note
Rewire is a pretty poor solution.

The one (or few) apps at a time approach appeals to me anyway and I
like using the ipad to get away from from some of the traditional DAW
complexities and mundane tasks that are required of me.

Now, what I would like to see is a system that automagically gets MIDI
or audio into your DAW! Be it windows, os x or even another iOS
device. Record a synth and boom, it starts transferring and shows up
as a named clip in Live. Record some MIDI and it's instantly available
in Logic for deeper editing. Make it just as painless to transfer
back. Or get an "audio copy/paste" equivalent to work as soon as the
user hits stop. Maybe a gesture that moves the audio or MIDI that all
apps share? Three finger swipe up and down moves it from that app you
are in to the one you last used? I dunno. I feel it's a better
expenditure of energy to let iOS excel at what it currently does
right, rather than shoehorn it into another paradigm. At least until
OS 6. :)

I don't think Apple has any incentive to implement my dream or most of
interapp communication because for their target market the current
implementation works fine. For most it seems audio apps are something
you have a bit of a cheap thrill with and then go on with your life.

[Aaron Pride]

Apple will hopefully add support for audio units in the mac app store... not sure the big box shops will publish this way but we all will.  Hopefully that will build momentum for registering and using 3rd party audio units in iOS apps which will solve this mess without any duct tape.  Purely speculative but I think we would all be well served to develop apps simultaneously as audio units to make transition easier.

[Nic G (Audeonic Apps)]

Just to follow up on this. Today, MidiVision 1.2 was released which
uses this mechanism to remain in the background (and supports
virtual ports now also).

It didn't seem to be an issue for the app review team. MidiBridge to
follow soon.

- Nic.

On Aug 23, 10:12 am, "nlogmusic (TempoRubato - NLogSynth)"

[Brian Ping-Yao Wang]

Hello Erik,

I encountered similar issues that my app can't get the MIDI message
from some apps. I am using PGMidi classes and I found that in your
MIDIReadProc (which should be PGMIDIReadProc() in PGMidi code) , the
srcConnRefCon is nil when the the source app connects to your app by
your destination. You can make a breakpoint in PGMIDIReadProc to
verify if this is your case.

If it is, you should modify PGMidi code to fix this problem. In
PianoAngel (I just managed to found the root cause and fixed the
problem), I created another MIDIReadProc for readProc of virtual MIDI
Destination. and I provide another delegate to pass incoming MIDI
packets.

The srcConnRefCon is non-nil when your app connects to either a
virtual MIDI source from another app or a MIDI output port from a
device. Therefore sending MIDI messages from Network MIDI port or real
MIDI device can't reproduce this issue. You have to test with another
virtual MIDI app which doesn't create virtual MIDI source (like free
MIDI Monitor app)

If you have problem modifying PGMidi classes, send me an email and I'm
happy to share my modified code to you. :)
I am contacting pete (Author of PGMidi) to provide him my fix as well.

Hope it helps.

Best regards,
Brian

--
PianoAngel - The Best iOS Piano App to play piano beautifully and easily!
http://bwinnovationtw.blogspot.com/2011/03/pianoangel.html

BW Innovation Taiwan http://bwinnovationtw.blogspot.com

[humbletune]

Hi Brian. Thank you for sharing. I am busy working at the moment but
will defenitely look into this. I would love to have a look at your
solution, please send it to erik_sigth [at] yahoo DOT se. You are a
star Brian. :)

ERik