novocaine swift example

[alexisdal]

hello,
I have played around with audio projects in other plateforms than iOs over the past few years.
Since objective-C is such a pain to read and write for me, i never really spent the effort to develop for iOs. And recently with the release of swift I became curious about iOs in general and started writing a few simple apps.

I would like to make a simple audio project for iOS and naturally ended up reading about novocaine.

However, i saw that the example provided are in objectiveC and i notice the following in the README

The RingBuffer class is written in C++ to make things extra zippy, so the classes that use it will have to be Objective-C++. Change all the files that use RingBuffer from MyClass.m to MyClass.mm.

Does it mean that it is impossible to use novocaine with swift ?
Otherwise, can we be provided with a simple swift example to get started ?

thanks

[alexbw]

There is a pull request that has made Novocaine compatible with Swift, but I have not yet had a chance to test it.

[tenKinetic]

I am using Novocaine with Swift. I will see if I can separate other dependencies (and testing garbage) from my project and provide the wrappers I have made. I've been throwing all sorts of C++ DSP at Swift just to see how it goes.

After a clean up I can provide an example project. If I can I'll include the Vamp-sdk and pYIN I started the whole thing for.

Of course, there's also just AVAudioEngine which I use as well but I've never used it with non-AVFoundation filters. When I want to do that I use Novocaine (primarily because it's a known entity for me). I've never tried using the floatChannelData from the AVAudioPCMBuffer in the TapOnBus to call arbitrary C++ filters through the wrapper. Maybe it's worth a go.

[clecap]

@alexbw: could you provide a pointer to this Swift code? I would be happy to do some testing on it.

I have the same issue here and the show stopper for me is that I do not yet know how to bridge from C++ to Swift.

[tenKinetic]

I think the pull request @alexbw was referring to is one that allows the library to compile when part of a Swift project more so than making it Swift compatible per se. You still have to implement the bridge you mention which I believe is a separate issue. I happen to not need the AudioFile classes, as I work with a live signal for what I'm doing, which are the ones that will not compile and require the update. If you can leave those out then you won't need to worry about it. Alternatively it isn't hard to grab the classes from the pull request and use them.

As such, my project compiles, and has the bridge implemented. There's quite a few warnings for deprecations and value conversions but the bridge implementation is the point of it all really.

It's imaginatively called AudioBase because I'll be spawning several projects from it when it's finished.

[alexbw]

I would gladly welcome a PR that removes the AudioFile classes (which are
buggy, and have been the source of most issues, and I don't think anybody
but me has really used them in production), and cleans things up for modern
compatibility.

On Sun, Sep 20, 2015 at 10:30 PM, tenKinetic [email protected]
wrote:

I think the pull request @alexbw https://github.com/alexbw was
referring to is one that allows the library to compile when part of a Swift
project more so than making it Swift compatible per se. You still have to
implement the bridge you mention which I believe is a separate issue. I
happen to not need the AudioFile classes, as I work with a live signal for
what I'm doing, which are the ones that will not compile and require the
update. If you can leave those out then you won't need to worry about it.
Alternatively it isn't hard to grab the classes from the pull request and
use them.

As such, my project compiles, and has the bridge implemented. There's
quite a few warnings for deprecations and value conversions but the bridge
implementation is the point of it all really.

It's imaginatively called AudioBase because I'll be spawning several
projects from it when it's finished.

—
Reply to this email directly or view it on GitHub
#111 (comment).

[tenKinetic]

@alexbw do you mean remove or replace? I simply don't include them and haven't had any issues (that I've noticed) due to their absence. It is possibly kind of useful for some to have something in there for file based streams and need a push in some direction as a starter. There's very little to the related pull request for the Reader and it does allow my project to compile however I think that even though things compile a similar update is needed in the Writer I don't like warnings and I totally do not like the warning given for the timer there. I can see now why you haven't acted on the pull request. After a 2 minute look it seems there's likely to be more to it. 2 minutes though, I haven't exactly done it justice.

Personally, I think the RingBuffer might be the only thing I'm going to use moving forward. I'm not sure if I missed something significant in my early forays into CoreAudio but what I've found since using Swift is that AVFoundation pretty much provides me with what I think I originally needed from Novocaine which was a quick and easy way to tap into the signal. From memory. Which is often wrong for me.

I'm also doing a lot of what I call 'bar work' these days which is where I sit in bars drinking pints of beer converting C++ to Swift. Often with hilarious mistakes. It's my version of coding competition combined with drinking competition. It will be big. Trust me. Actually I think it's already a big thing based on every project I've ever inherited. PHP is often complained about but I have seriously compelling evidence it drives people to drink.

[alexbw]

I mean remove, but if people are getting some utility out of it, then they
should stay.
It's awesome if there's been API additions to AVFoundation that make
Novocaine obsolete — it was only designed to fill a gap.

On Wed, Sep 23, 2015 at 12:07 AM, tenKinetic [email protected]
wrote:

@alexbw https://github.com/alexbw do you mean remove or replace? I
simply don't include them and haven't had any issues (that I've noticed)
due to their absence. It is possibly kind of useful for some to have
something in there for file based streams and need a push in some direction
as a starter. There's very little to the related pull request for the
Reader and it does allow my project to compile however I think that even
though things compile a similar update is needed in the Writer I don't like
warnings and I totally do not like the warning given for the timer there. I
can see now why you haven't acted on the pull request. After a 2 minute
look it seems there's likely to be more to it. 2 minutes though, I haven't
exactly done it justice.

Personally, I think the RingBuffer might be the only thing I'm going to
use moving forward. I'm not sure if I missed something significant in my
early forays into CoreAudio but what I've found since using Swift is that
AVFoundation pretty much provides me with what I think I originally needed
from Novocaine which was a quick and easy way to tap into the signal. From
memory. Which is often wrong for me.

I'm also doing a lot of what I call 'bar work' these days which is where I
sit in bars drinking pints of beer converting C++ to Swift. Often with
hilarious mistakes. It's my version of coding competition combined with
drinking competition. It will be big. Trust me. Actually I think it's
already a big thing based on every project I've ever inherited. PHP is
often complained about but I have seriously compelling evidence it drives
people to drink.

—
Reply to this email directly or view it on GitHub
#111 (comment).