OMAC SysEx Container

[Amos]

Hello OMAC group, especially Rolf and Gabriel.

I am writing to follow-up on an earlier discussion about an official SysEx container specification, for passing OMAC-standardised information between apps (in the form of a URL scheme).

The beginnings of a proposal are here:

https://docs.google.com/document/d/1AHfYx7iu9KQYC1rwptHGVFQiI9xo-HGJBzpvY20WK0M/edit

This proposal has been waiting for feedback from the MMA; here is that feedback.

----

MMA feedback on OMAC "SysEx Container" Draft Proposal:

1.) There is a small error in the Byte count in the table on page 2 of the OMAC document.  

If the OMAC Manufacturer ID is bytes 02,03,04, then the first byte of the "Message" portion should be numbered 05.  

It is currently numbered 03.  

In the text of the following paragraph there is another 03 which should be changed to 05 (referring to the same byte).

2.) "The format of the message is a normal URL scheme... therefore it can be transmitted directly as sysex without any further encoding." 

 -- It may very well be the case that the URL standard does not allow any values which would be illegal as SysEx data, 

but a reference to the URL-encoding spec which states this would be ideal here. For example, there is a lot of info at the following link:

http://www.url-encode-decode.com/

... which suggests that the document RFC 3986 (from the Internet Engineering Task Force, IETF) specifies what characters are allowed in a URL scheme:

http://www.ietf.org/rfc/rfc3986.txt

...in any case, the request is for the OMAC spec to make refernece to a document which defines what characters are allowed, so as to specify clearly that no characters which would be illegal as Sysex (numeric value > 127) will be used.

---

If the entire payload is "plain text" which requires no further encoding, then the above feedback should suffice... that would mean that the OMAC proposal is compliant with the outlines for SysEx and further definition of the payload is entirely up to OMAC.

Given that the OMAC proposal is compliant with the rules for SysEx, the MMA is willing to specify a "manufacturer ID" for OMAC SysEx Container communications.

 

Kind regards,

Amos Gaynes

on behalf of

 **** MIDI MANUFACTURERS ASSOCIATION ****  

Technical Standards and Executive Boards

[Gabriel Gatzsche]

Hello Amos,

many thanks for your follow-up. Its great that it will be possible to get an OMAC MIDI Manufacturer ID.

Regarding 1) I've fixed the error with byte 5 in the document.

Regarding 2) The document rfc3986 provides an encoding scheme for URLs. If an URL is encoded using this scheme, only a subset of 7-Bit ASCII chars is allowed, but not the chars F0 and F7.

I've added an information to the proposal that the URL has to be encoded according to rfc3986,

Are there any further things I should do?

What are the next steps to?

Best, 

    Gabriel

--
You received this message because you are subscribed to the Google Groups "Open Music App Collaboration" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-colla...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rob Fielding]

Finally an answer about whether finger area sensing (after-touch capable pressure-sense equivalent) can be used, after years of every music developer asking and getting conflicting answers from actual reviewers at Apple (some say yes!) to the black hole that has been getting email inquiries about it since iPad1 came out: No.  

Apple called me today to nicely inquire with me about this.  They gave me an opportunity to fix it.  As far as I know, I am the first person to have my app removed from the store for this.  I was told that it will be gone in two weeks.   Ironically, I just got rid of my only Apple laptop last night in favor of a linux laptop; so I just kind of shrugged my shoulders and told them to go ahead and remove it.

(What I am doing does not resemble TenOne's pressure-sense stylus thing in the slightest way.)  Cantor blatantly uses finger area sensing.  It has been the first thing listed in the submission description since the first time I submitted it more than a year ago.  It got approved like that for 2 subsequent updates.  I presume that this was a clear 'yes'. 

Not being able to have this feature was the main reason I lost interest in working on Geo Synthesizer.  The build that we had a month before we shipped had this feature, and it was done right and was farking *amazing*.  It was the difference between something that would compete with a real instrument, and something that is just kind of neat in some special cases.  The decision was made to remove finger area sensing out of caution (code completely removed - not just disabled).  The playability of Geo turned out ok without it I guess...but to illustrate how much better it was before that: every tester deserted the day after we removed it.  Then months later, most of them sent me an email asking for a private build that had it re-enabled.  I decllined.  So fortunately Geo Synthesizer does not have this problem.

I knew how to do finger area sensing since about three months after iPad1 came out.  We even tried to get an answer from Phil Schiller at the time (JR knows him), and we didn't get an answer back then.  Cantor doesn't really make as good of a use of this feature as those early Pythagoras/Geo builds did.  I polished Cantor enough to be good enough for my own purposes and shipped it with this blatantly enabled and documented to see what the answer really was.  

--
http://rfieldin.appspot.com
http://rrr00bb.blogspot.com

[Jesse Chappell]

Very interesting. Kevin (BitShape) asked Apple at WWDC this year and
they also said no. I bet Orphion is getting the same treatment, since
they are also quite obviously featuring it.

Kevin also was told that we should all file radar's that say how
useful it would be to have the functionality that area-sense gives us,
with exact use cases, and then casually mention the capability that
already provides it.

jlc

[support (One Red Dog Media)]

Sent from my iPhone

[Gabriel Gatzsche (Audanika - SoundPrism)]

Hi Rob,

please, please, please create new threads for topics that have less to do with existing ones. This thread is about the OMAC sysex container and not finger sensing area stuff.

Best,

    Gabriel

[Amos]

Thank you Gabriel,

On the topic of the OMAC sysex container, the next step is for OMAC folks to get together and hash out the spec; define and codify what you want it to do.

When you're happy with it, let me know and I will submit it to the MMA for approval and publishing as an official MMA document.  That is the mechanism whereby the MMA will reserve an official sysex ID for "container" purposes.

I promise MMA will do their best to review and approve in a more timely manner. :)

Cheers,

Amos

[Amos]

Hello OMAC folks,

I am just checking in on behalf of the MMA, regarding the OMAC Sysex
Container specification.
I know that OMAC is an informal association, without regular meetings
or the like, so perhaps the best question would be: is anyone working
on this, or planning to do so in the near future?
If so, please reply and let me know.

As a reminder, the next step is to specify some common actions that
you'd like to coordinate across multiple apps, and define the URL
schemes which will accomplish these actions.
To join the working group for this project, go here:
https://groups.google.com/forum/#!forum/omac-standard-sysex-container

kind regards,

Amos Gaynes
MIDI Manufacturers Association

[Gabriel Gatzsche]

Hi Amos,
many thanks for your kind reminder to take progress on this. Rolf had very much to do with the release of Nave and Sebastian was at the WWDC. Thus we didn't discuss the next steps. I will get back to that after talking to Rolf and Sebastian.

Best,
Gabriel

[Sebastian Dittmann]

Hello all,

After having a very constructive conversation with Rolf and Gabriel today it became clear that I would have to check with some other potential stakeholders before definition of URL schemes and further steps should be taken. If possible I'm asking for up to two weeks time so I can have a few conversations to then make better suggestions regarding this.

Would everybody be ok with this?

Sincerely,

Sebastian Dittmann

[Amos]

It's all fine over here. MMA doesn't meet again for another four
weeks, so no hurry from us.

Cheers,

Amos

[Sebastian Dittmann]

Hello Amos,

I've talked with a few companies who might be interested in getting involved in this discussion. One of them is Miselu (http://www.kickstarter.com/projects/miselu/c24-the-music-keyboard-for-ipad) since they're working on a specific iOS controller that might make use of the sysex container.

Therefore I think it would be great if Malte Groesche und Jeffrey Horton of Miselu could be involved in the design discussion. I've CC'd this to them but I think they're already part of the OMAC group.
What would be the best way for them to add suggestions or get a view of the current state of the definition of the sysex container?

Best,

Sebastian

[Amos]

Hi Sebastian, I think they could join the google group to post
comments, and the basic outline of the spec proposal is publicly
viewable... that ought to do it, I would think.

Cheers,

Amos

On Fri, Jul 12, 2013 at 12:22 PM, Sebastian Dittmann

[Joshua Pollack]

Hi Amos, Sebastian, all.

I'm Joshua, I work on software architecture at Miselu.  Thanks for thinking of us.  I think this is a great idea, and a good first step at standardization.  I have a few ideas for suggestions and possible improvements which will make this more suitable for all use cases, and a bit futureproof.  I'll post my comments and questions in the other group, as it might get a bit verbose and detailed.

Joshua

>>>>>>>> email to open-music-app-collaboration+unsub...@googlegroups.com.

>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google Groups
>>>>>>>> "Open Music App Collaboration" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it, send an

>>>>>>>> email to open-music-app-collaboration+unsub...@googlegroups.com.

>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://rfieldin.appspot.com
>>>>>>> http://rrr00bb.blogspot.com
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google Groups
>>>>>>> "Open Music App Collaboration" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it, send an

>>>>>>> email to open-music-app-collaboration+unsub...@googlegroups.com.

>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google Groups
>>>>>>> "Open Music App Collaboration" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it, send an

>>>>>>> email to open-music-app-collaboration+unsub...@googlegroups.com.

>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups "Open Music App Collaboration" group.

>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-collaboration+unsub...@googlegroups.com.

>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "Open Music App Collaboration" group.

>>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-collaboration+unsub...@googlegroups.com.

>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Open Music App Collaboration" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-collaboration+unsub...@googlegroups.com.

>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Open Music App Collaboration" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-collaboration+unsub...@googlegroups.com.

>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Open Music App Collaboration" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-collaboration+unsub...@googlegroups.com.

[Amos]

Hi OMAC.

Here is a reminder that some of you have suggested using a URL scheme, passed between apps via MIDI SysEx, to allow complex communication between apps over an existing channel.

There seems not to have been any progress on this in a while... is it because no one is interested anymore, or is there still interest but no time to work on it?  I am certainly familiar with the latter condition... :)

In any case, if someone wants to hash out the details of the URL schemes you want to define, and write it up into a document... the MMA is still willing to publish the result and assign a universal SysEx ID to identify this sort of inter-app communication.  Keep us posted.

Thanks,

Amos Gaynes

MIDI Manufacturers Association
Technical Standards Board

To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-colla...@googlegroups.com.