Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fork of vvopensource with MIDI timestamps and OSC service type option #7

Closed
wants to merge 8 commits into from
Closed

Conversation

markwheeler
Copy link
Contributor

Hi,

Firstly, big thanks for your work on vv, I've found it real useful in my own project! In working on that project (it's a sequencer for OSX) I made this fork with a few updates to vvopensource – just thought I would send it over and see if it's of interest. No problem if it doesn't fit with your plan, I can keep it separate.

The main changes I've made are:

MIDI messages always get sent with a timestamp
I was actually kind of surprised this wasn't done already, as many people would consider it an invalid message to do so (although most software won't care)

You can specify that timestamp
This means you can schedule MIDI messages ahead of time (in my sequencer app I have a 10ms buffer) to make sure they get there exactly when they should.

OSC service type can be specified
This was fairly unique to my use case. I'm working with the monome hardware which for some reason shows up as '_monome-osc._udp' rather than the usual '_osc._udp' I'm guessing it could be useful in other cases too though.

Note
I'm not an iOS developer so I haven't checked that side of it to see if I broke anything :)

So yeah take a look and let me know what you think!

Mark

@mrRay
Copy link
Owner

mrRay commented Jan 29, 2014

howdy-

thank you very much for the pull request! i hope you don't mind- i did some minor copy-editing and integrated your changes as a separate commit. please let me know if i left anything out or if you have any problems or requests.

"I was actually kind of surprised this wasn't done already, as many people would consider it an invalid message to do so (although most software won't care)"

i don't understand how or why MIDI messages sent at time "0" would be considered invalid, and i'd like to: could you please explain that in a bit more detail when you get a chance? i'm under the impression that any MIDI messages scheduled in the past are sent out by OS X's MIDI server immediately, which is the desired effect- which applications/hardware devices exhibit errors under these circumstances, and what sort of errors should i look for?

"OSC service type can be specified"

i'm surprised that the monome devs decided to use a custom service name, as it seems like this would kind of defeat the point of using bonjour in the first place (forcing devs- or users- to enter non-standard service names isn't much more convenient than manually entering IP address/port info).

cheers
: : ray

@markwheeler
Copy link
Contributor Author

That's great! I'm gonna close this pull request then.

Re: Timestamps. This seems to be a bit of a grey area in the MIDI spec and I've seen people online talking about the fact that CoreMIDI docs say its fine to set a timestamp of 0 for an immediate send. However, some software doesn't always respond to incoming note msgs with a 0 timestamp – most notably Ableton Live. I was using MIDI Monitor to check what was going and on and noticed that it flags these messages. There's also a fair bit of discussion on the Ableton forums about it. eg:
https://forum.ableton.com/viewtopic.php?p=1426466
https://forum.ableton.com/viewtopic.php?p=1347051

Re: OSC service type. Yes totally agree, seems like a bad decision on the monome side! Saying that, they are phasing out bonjour in their implementation so this should become a non-issue. I'm not sure if anyone else is making up their own service names or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants