mrRay / vvopensource

OSC and MIDI frameworks for OS X and iOS, a framework for managing and rendering to GL textures in OS X, and a functional ISF (interactive shader format) implementation for OS X.
231 stars 33 forks source link

fyi - MIKMIDI #16

Closed johndpope closed 7 years ago

johndpope commented 8 years ago

I've been using successfully using vvopensource with an app of mine http://komposer.io - but with el capitan upgrades - my apps gone pear shaped. I tried cherry picking the el capitan fixes for code - but it didn't resolve issue. https://github.com/krevis/MIDIApps/issues/45

I'm not sure if you taken a look at MIKMIKI recently - but the 1.1 branch has had a significant updates including midi device management. https://github.com/mixedinkey-opensource/MIKMIDI

Anyway - with some lament - I will be decoupling my app from vvmidi manager / vvmidinode classes - and using mikmidi. Having access to pods / tags / submodules rather than a single monolithic library does appeal.

mrRay commented 8 years ago

hi john-

“Anyway - with some lament - I will be decoupling my app from vvmidi manager / vvmidinode classes - and using mikmidi. “

you opened an issue, so i’m assuming you’d like help resolving your issue- but i don’t see a description of the problem you’re having, which is something i need before i can be helpful. a reproducible test case and/or sample code would also be nice.

beyond that: awesome! i’m glad you found another MIDI framework that better suits your needs, and i’m assuming that right now you just want a hand getting stuff working while you begin the process of transitioning to your new framework.

“but with el capitan upgrades - my apps gone pear shaped.”

changes in el capitan definitely revealed a bug in VVMIDI, and this was fixed by commit c129e5b4a0ddeb0ea2e27065451e4d4f25a3217b. in a nutshell, CoreMIDI really doesn’t want you to ever create more than one MIDIClientRef (or to delete the MIDIClientRef you created): prior to that commit, VVMIDI would potentially create more than one client. that was the only change/problem i’m aware of in 10.11.

“I tried cherry picking the el capitan fixes for code - but it didn't resolve issue.”

it would be a lot easier to troubleshoot whatever problem you’re having if you don’t have any modifications to the base framework.

beyond that, all i can really do is mention that after a good amount of testing we started deploying to 10.11 a few weeks ago, and there haven’t been any complaints about systemic MIDI issues yet from any of our testers or users. i know this is horribly subjective and anecdotal, but from my point of view it seems like either VVMIDI is fine in 10.11, or nobody i’ve been in touch with has stumbled on the part of VVMIDI that’s causing you grief.

again, this is where a description of your problem and a reproducible test case would be helpful.

"rather than a single monolithic library does appeal.”

are we talking about the same thing? VVMIDI is a very small framework with exactly one (also very small) dependency (helpfully included in the project file).

johndpope commented 7 years ago

@mrRay - closing this. Thanks for feedback.