Add OSC instrument communication #199
Comments
|
OSC would be great a feature - audiokit be the first swift osc implementation ? One reason more ... ! |
|
Most of AudioKit is still Objective-C at this point, though accessible in Swift. |
|
Send/Receive OSC over VPN ? shadowsocks/shadowsocks-iOS#124 ... |
|
If you get a network connection of any kind, why would we have to care whether it's over a VPN? It should be pretty much transparent to applications. |
|
... IP addresses tend to be dynamic , generic or unknown - and ports tend to be blocked or mapped or even attacked or however router-dependend - not quite an easy or safe environment for ANY protocol . And Eventually slipping through firewalls by the grace of your fellow admin, you lost your precious payload on UDPs "who cares" ... |
|
Well that's all fine and dandy, but how is that the job of an audio library? |
|
Are we discussing networked audio ? |
|
https://github.com/sebpiq/rhizome ... Tough wrestler ! |
|
... Both VPN and coreaudio share the extension points API - I wonder if there isn't something for us audiokids .... |
|
OK, well I can see how that might be confusing, and arguably I know nothing about OSC. However the most any kind of networked audio library should do is worry about establishing and maintaining connections for the purpose of exchanging audio data. That's it. If you're doing anything like trying to set up a VPN, you are doing it wrong. That's the job of the OS, as it should be. We're at the application layer, not the network routing layer. The most I'd like to see in any kind of networked audio as far as AudioKit (or any other audio library, for that matter) do is make sure that it supports IPv6, as Apple is going to start enforcing that apps support that. Anything else is out of the purview of this project. Yes you can now write VPN and CoreAudio extensions, but these have absolutely nothing to do with each other. |
|
I'd just like to emphasize that a properly designed networked library should be as network-agnostic as possible. Sure you want to make sure that it is efficient enough to handle a variety of network conditions, but you don't go about handling details of the operating system unless you absolutely, really need to, and that's just not the case for networked audio. |
|
... That's all taken care of by the Extension Point API's "Protocol based Programming" - as far as I understand Apples system architecture strategies ... |
|
Do you have a link for that? What do you propose to achieve with an extension that is relevant to AudioKit? AFAIK protocol-based programming has to do with new design patterns in Swift 2. |
|
http://khanlou.com/2015/06/protocol-oriented-networking/ that's more of a march through the "wortfeld" but worth reading ... as for Relevance and exclusions, I find khanlou's thoughts on requirement engineering interesting ... |
|
OK, well I think you're confusing a few things. Again, this new syntax in Swift 2 is very nice in many ways and that blog post shows how protocol extensions can be used to make network code more intuitive. But don't let the Swift "extension" syntax fool you, this has absolutely nothing to do with the various extension points in iOS/OS X which are more or less independent apps that integrate in various parts of the system (think share dialogs, custom keyboards, and yes now basically VPN drivers in iOS 9). And let me be clear: I'm all for networked audio via OSC or any other protocol. It will be a great fit for AudioKit alongside the MIDI support. It just won't need any kind of fancy operating system-level stuff to achieve, beyond the regular networking APIs used in apps. |
|
How is audiokit actually intended to be fitting into the AudioUnit ecosystem fostered by apple ? |
|
It will be possible to write Audio Units with AudioKit as the engine. We'll make every effort to make the process easier. It's already been done with Csound, so that's the plan. The news with iOS 9 is that it will be possible to package these in apps, to have the AU available in other host apps (such as GarageBand for instance). |
|
Do you have a link to a Csound (as) AudioUnit - just found the Book chapter, but no code to look at ... |
|
You're in luck, this was just posted to the Csound mailing list a few minutes ago: 😄 |
|
Whohoo ! Thank you for that - exciting ! |
|
hmmm - install csound via homebrew ? Bit of a show stopper right now ... |
|
If Csound was easy, there wouldn't be a need for AudioKit. 😉 But this is an interesting proof of concept. |
|
True. |
|
There's promises for an audiounit xcode template published by the core audio team - do you know about any news on this ? |
|
That's very likely gonna be in Xcode 7, currently in beta. You could check out their session on the subject: https://developer.apple.com/videos/wwdc/2015/?id=508 |
|
was the first I'd been watching ...but thanx ! https://github.com/csound/homebrew-csound solves my build problems - but 120 Deprecations seem quite a lot. |
|
But one time back to the "The extension point" lingo - is it just that, or is it to suppose an area of product enhancement (like "Protocol Oriented Programming") - or is it just unfortunate advertising , a misunderstanding - ? |
|
What's protocols, what's extensions ? |
|
This is getting rather off-topic, but I can see how it can be confusing terminology in the Apple ecosystem. These words are used with completely different meanings in both the Swift/Objective-C languages and with regards to system components like networking. A network protocol is mostly a conceptual definition of how to exchange data over the wire (it's not tied to any language per se). This is very different from the protocol keyword in both Swift and Objective-C, which is about defining interfaces for classes and is thus entirely a language construct. It is very similar to interfaces in Java, or abstract virtual methods in C++. Swift also has an extension keyword that allows you to add functionality to pretty much any existing type (be it a class or even a built-in type like Integer). This is also a programming construct that comes in very handy. This doesn't apply to Objective-C. Swift 2 adds a way to extend Swift protocols (again, nothing to do with networking), which allows for some pretty cool new design patterns making programming certain things easier and cleaner. At the same time, since iOS 8 developers have been able to ship app extensions, basically apps within an app, allowing to hook up into the system and other apps via clearly-defined extension points. This is a way for app components to escape the sandbox they are normally confined to. In practice, it is basically a set of APIs that allow developers to write these kinds of extensions (and there are plenty of types of those, and iOS 9 does include Core Audio extensions among others, finally allowing to ship Audio Units on iOS). These extensions have again nothing to do with the extension keyword in Swift, and actually can be written in any language (Objective-C or Swift) as long as the proper APIs are used. For more info, I suggest you look at all the Apple documentation on the subject, there is a lot there and I don't want to take this thread off the rails too much. |
|
Given audiokit applications being deployed as AudioUnits at clearly defined extension points on the one device - ( where and how?) - how does networked audio via OSC not merely become an audiokit decor feature but an option beside streaming buffers ? Stated like this, does it bring back things on track & to your liking ? ( and, truly- thank you for doing the hard work of definition !) |
|
The way I see it, OSC support would affect what outputs and inputs are available when using AudioKit, as an alternative to just regular iOS/OS X audio. So you could choose to connect and send the audio from your app to another device, or vice versa to receive audio as an alternative input. This should be doable regardless of the type of app you are building with AudioKit, whether it's just a vanilla app or an Audio Unit extension. In that last case, I would imagine that host apps (think GarageBand) would then automatically take advantage of the OSC support via AU extensions using AudioKit. |
|
... sounds a bit like conditionally messing with the air-streaming feature. |
|
... ah ... Bidule ! |
|
... but there's still the problem of network security and the technical death of OSC, killed by sys admins. How does OSC enabling become a proper citizen in IOT ? Leave it to the browser ? |
|
AirPlay is another beast altogether, it's a proprietary Apple technology for transparently streaming audio and not applicable here. Again, any network considerations are solely the purview of the operating system and/or dealing with your network administrator. Absolutely not the job of AudioKit. It is entirely the responsibility of the user to make sure they have a working network connection to do networking of any sort. I'm assuming there's some kind of authentication that happens as part of the protocol, but that's as much as we'd be touching that. If you need to use a VPN, then do so, but this has nothing to do with anything we're dealing with here. |
|
You never leave userland. So be kind 😏 ! |
|
We could revive OSC by means of VPN - Apple seems to want it. |
|
... and ty it to their server / MDM product. |
|
I have literally no idea what you are talking about. For the last time: VPNs are of no concern to AudioKit. That's the entire point of virtual networks, to be transparent to applications. If OSC is somehow a crappy insecure protocol that needs to be secured with a VPN, then so be it, but that is not our job to provide that VPN. If our implementation of OSC works with any regular network, it will work with a VPN. That's the entire point of a VPN. Do you think that when you connect to a VPN, an application like Safari does anything special to work with it? I guarantee you it doesn't. Nor should we. The OS makes it look like any other network to your apps. Can we please drop this? I feel like we've been beating this dead horse for long enough. |
|
So - leave it (networked audio) to the browsers ? The current "hot keys" seems to be "extension points" which is kind of a shared trait of AUUnits and VPNs of the apple flavour - but okay - I'll map your ports because I'm a nice admin 😌 Thank you and all the best ! Benedikt |
|
If you can't understand this simple concept, maybe you should really stop trying to argue it. I never said to leave it to the browser, I was just using it as an example of an application that can work over VPN, without having to do anything special to work. Like every single other networked application. Including AudioKit apps. It is not and never will be our problem if your admin will not allow certain ports - it is 100% the user's responsibility to solve this. There is nothing to do to support VPN in an application. Nothing. So we don't need to talk about this anymore, ok? |
|
https://twitter.com/peterkirn/status/620885038817779712 hurry up - technical death is a fact. |
|
Will bring this up again later. |
We have full MIDI support, but no OSC support yet. There seems to be a few options listed at Charles Martin's Blog:
http://charlesmartin.com.au/blog/2013/3/26/finding-a-good-osc-library-for-ios
but so far it looks like his Metatone might be best
https://github.com/cpmpercussion/MetatoneOSC
and it comes with this example
https://github.com/cpmpercussion/ExampleOSC
If you are on OSC wiz and want to knock this out, that would be great, or else you can also just comment that you would also like to have this feature, and that will motivate us to prioritize this higher.
The text was updated successfully, but these errors were encountered: