libpd: Put Pure Data in Your App, On an iPhone or Android, and Everywhere, Free

What if you could make any device or any software a re-programmable musical instrument, effect, or soundmaker? Your phone could be a touch-controlled effect, your tablet a sketchpad for interactive drum sequencers. Patches assembled on your desk on a computer could be taken with you in your pocket. And what if you could do all of this for free, using a time-tested environment?

libpd, authored by Peter Brinkmann, takes on that vision. It’s a way of making Pure Data (Pd), the visual development tool for interactive music and media, more accessible across a range of applications and gadgets. It lets you embed Pd pretty much anywhere. It’s not a new version of Pd. Instead, it makes use of the standard, “vanilla” distribution of the free and open source software. What’s different is that it separates the sound processing part of Pd from the part that talks to audio hardware, allowing Pd to run on a greater variety of mobile devices and inside other applications.

libpd:

turns Pd into an audio synthesis and processing library

liberates Pd from GUI and drivers

allows for easy communication between Pd and the code into which it is embedded (so you can send and receive messages with your Pd patch)

Today, a team of developers and testers (including myself) is releasing the first version of libpd. It’s free to use on any device you wish, and free to modify. Because of its licensing, you can even build commercial applications with it. (That is, yes, it’s open source – but yes, it can also be useful if you’re a commercial developer. You don’t have to choose.)

We’re just pleased to have a tool that makes experimenting with sound and music quicker, easier, and more flexible and compatible. It’s more fun that way.

Supported Platforms, What You Can Make

Right now, today, you can use libpd with:

Android: Thanks to Google’s NDK (Native Development Kit), you can use libpd with any Android device running OS 1.6 or later. Note that devices without the Google Market are often non-standard in other respects, so your mileage may vary, but we’ve found a wide variety of devices work quite well, including the Motorola Droid and Droid X, HTC Legend, and Google NexusOne.

iOS: iPhone and iPad models with the latest, armv7 processors work (3GS, iPad); we’re working to extend compatibility across more devices. Working with Peter Brinkmann, the RjDj development team contributed (and continues to contribute) free code that’s making iOS support compatible and high-performance. But the Objective-C classes mirror the Android and Java classes, meaning the two will stay in sync, and once you’ve learned one, the other will be a piece of cake. (Or coffee. Or cocoa. Or whatever.)

In each case, you just need libpd, Pd for making your patches (graphically), and a copy of the SDK for each mobile platform you want to use.

Additionally, you will soon be able make user interfaces for libpd using cross-platform HTML5, via Chris McCormick’s project WebKitPd. (It’s not quite ready for consumption yet, but will also be free and open source.) Android was the impetus and initial test platform for libpd, so right now it’s the most mature. But we hope to improve iOS compatibility and testing next.

Some Sample Apps to Try for Android

libpd is really aimed at developers who want to embed Pure Data into mobile devices, games, and so on, and soon also people working with Processing, Open Frameworks, and the like.

But if you’re eager to try this out as an end user, there are a number of packages you can try. They don’t show off everything libpd and Pd can do, but they do allow you to load up something on your device and make some noise.

Among the code included in the repository is one complete app, Peter Brinkmann’s own Circle of Fifths. He tells us:

Circle of Fifths: I wanted a circle of fifths tool for the subway, with exactly this kind of GUI. It also nicely illustrates the newly possible separation of concerns — Pd only does DSP, and an elaborate GUI is built somewhere else. It’s a demo and not optimized for universal consumption. In particular, it’s a bit CPU hungry because it’s actually simulating six Karplus-Strong strings in real time.

Of course, if string simulation is what you want to do, this also illustrates that you can – even on a phone.

Chris McCormick has created two libpd-based apps, one of which I feature in the video above. Can of Beats also makes use of WebKit as its UI rendering engine. Chris describes what he’s made:

Can of Beats: This is a procedural hiphop beat generator. The beats are generated using simple hand-crafted probability weightings for each type of sound at each position in the beat. In the Android app, you can also input simple melodies or basslines to go along with the beats.http://mccormick.cx/projects/CanOfBeats/

Garage Acid Lab: This is an algorithmic, 303-style acid bassline generator. The app will make you an infinite number of different acid bass lines and garage style beats. You can also have some fun with the cutoff filter and delay unit settings with a kaos-pad style input. I want to work on this app a bit more to provide an ‘advanced’ mode which will let you write custom basslines, beats, and have more control over the effects. http://mccormick.cx/projects/GarageAcidLab/

RjDj, RjDj team. If you don’t know it by now, RjDj is a fantastic application built on Pd that makes interactive musical and sonic experiences deliverable in the same way as a digital album, not only to musicians, but anyone who wants to experience music and sound in new ways. libpd makes use of code contributed by RjDj. Future development on RjDj will use libpd. (More on those libpd-based versions, and the evolution of RjDj and RjDj Voyager, soon.)http://www.rjdj.me/

2. Join the community. You can discuss patching for libpd, developing using Pd, and making instruments and effects and other sonic creations for gadgets everywhere on our new community group:http://cdm.link/groups/pd-everywhere/

Who made this: libpd was conceived by a team including Peter Brinkmann, Hans-Christoph Steiner, and myself, with input from the RjDj team (particulary Martin Roth). It was primarily developed by Peter Brinkmann, who applied his talents and the work he has done in JJACK, a Java API for JACK, with additional contributions and testing by our team and by Chris McCormick. Major thanks to Martin Roth and the folks at RjDj, to Miller Puckette (creator of Pd), and the generous attendees of our first hackday at the NYC Patching Circle, along with others who are testing now.

Tutorial Next Week; Your Feedback Wanted

I’ve been preparing a tutorial for working with libpd Android (initially), to be followed eventually for developing on iOS devices once we have a better handle on making that go smoothly. We’ll have a complete tutorial for you by next week. Processing is then my next priority.

An FAQ will also be available by then. That means, first, ask some questions!

Got specific questions about what this is for? How to get started? What you’d like to see in the tutorial? Ask away.

And please do get the discussion going not only here in comments, but in the Pd Everywhere group. (Noisepages registration is now open; if you have any trouble, let me know and I’ll sort you out.)

This is so cool! I've been experimenting and testing pdlib on Android and iOS.

As far as I know it's the first cross-platform DSP library that supports both Android and iOS (as well as everywhere else Pd runs!).

Thanks Peter, Peter and Hans-Christopher and everyone else!

Stan

WHOA!!! This is Awesome!

But as cool as this is for devices, are their any plans to make this available for traditional Windows/OSX/Linux platforms? The possibilities of being able to create and use PD patches inside games and multimedia applications is staggering.

Also, if the tutorial could include and example about how the PD Patch interactions are abstracted out [and to what extent] for use in the code that the pdlib is embedded in [and assuming it is pretty simple], I would call this a home run. [For Example: If I created a simple pd patch that plays a Sine Wave and has a slider to control the pitch of the Sine, how are the play/stop/slider controllers represented in is the C++/Obj-C/Java code of the respective platform?

Other platforms: yes. If you know what you're doing, you can wire the library up right now to whatever you want. But for things like Processing, hope to make it plug-and-play by writing the code you'll need.

Stan: As Peter Kirn already said, you can build libpd on lots of platforms. Basically, if you can compile Pd on a platform, then you can compile libpd there. The git repository already includes tentative makefiles for Linux and OS X.

Generally speaking, the project consists of several layers that are designed to be as general as possible: libpd is a C library that's easy to embed in a C/C++ project. On top of the basic C library, there's a Java wrapper (PdBase.java) that provides thread safety and converts between Java types and C types. The Java bindings do not depend on Android. For instance, we have already added Pd components to jReality.

Finally, there's an Android driver layer (PdAudio.java) that connects the Java bindings of libpd to the Android audio architecture. The iOS version mirrors this structure, with a basic ObjC layer that converts types and synchronizes access (PdBase.h/m) and a driver layer that hooks Pd into CoreAudio (PdAudio.h/m).

Regarding your other question, libpd lets you exchange messages with Pd, which will allow you to control Pd with sliders on the C/Java/ObjC side. The documentation explains how: http://gitorious.org/pdlib/pages/Libpd

noou: You can load externals into libpd if and only if your platform supports dlopen. In particular, externals work just fine with Android, but not with iOS because iOS does not support dlopen. You can still use externals with iOS if you're willing to compile them right into your binary.

The Android version includes the usual externals that come with Pd Vanilla (e.g., fiddle~ and bonk~), and it will load them dynamically as needed. Just one warning: If you intend to use your own externals, make sure not to put them on the SD card because Android will refuse to load them from there. (I think I'll go ahead and add a section on externals to the documentation now.)

Hi, for my soon to be released iPad app I used Bryan Summersett's pdlib. I made some iPad specific optimisations and I've made this fork available on github http://github.com/onereddogmedia/pdlib Maybe you guys will also find some of these changes useful.

poopoo

Nice one!

Mudo

…

It can interact with external hardware? via Dock? Bluetooth? Wifi?

It could be perfect for me…

😉

…

Random Chance

At first I thought this was a renamed version of ZenGarden (the re-implementation of Pd as a C++ library with mostly object oriented design instead of the sometimes crude C code that permeates the original Pd implementation), but then I realized: This is "just" a Java wrapper. Surely this makes the Android platform a little more interesting. If they would settle on some way of dealing with upgrades to guarantee your phone will still be up to date in a few months after you buy it I could just be tempted to really get one of those Android based phones to replace my trusty old Palm Treo.

Mudo: The basic goal behind libpd is to have Pd do audio and only audio. Everything else is up to the client code, and communication between Pd and the rest of the world goes through Pd messages. If you want to use external hardware, you can do that by having your code take care of the translation between events from the external hardware and messages in Pd.

Great work! I'd like to know if libpd achieves lower latency than the AudioRecord and AudioTrack APIs on Android. Their minimum buffer requirements are terrible, and if libpd cuts them down, that would be another reason to use it.

libpd uses — has to use — the audio APIs on the platform. That's kind of the point. That's what allows libpd to be embedded in an Android app, as an audio engine. (Reading through the wiki on Gitorious, Peter Brinkmann explains this nicely.)

That is a feature promised for a future version, albeit via OpenSL ES, which I think may just wind up adding more overhead.

The problem is, though, the API is not necessarily to blame for what you're experiencing. Those are in place because of a degree of unpredictability in hardware chipsets and chip drivers. Java's not necessarily to blame, either; what I've been told is that Java is adding a minuscule amount of additional processing overhead. (That makes sense to me, as the Java IO classes are highly optimized, and it's just passing buffers.)

I think you *may* get what you're looking for, but it may come from custom hardware. iOS isn't without its problems here, either. There are things that just don't work well on these mobile devices, because things like low-latency, high-quality audio aren't necessarily a concern. I still find all sorts of things that can be usable. And I think the future as far as pushing the envelope may be rolling custom embedded solutions that make a different set of compromises.

thedude

no c# love? i know its popular to hate on managed code and microsoft in general but it's disappointing that so many cool projects neglect a language with such a huge base. //just sayin

What Peter did was to create a generic callback API mechanism for Pd, and to separate the engine from audio I/O.

In order to apply this, we took the problem of Android audio, which turns out to be more complex than any of the desktop platforms.

Now, the next step is, use it wherever you see fit. If you know enough about C# and the .net platform to make use of such an audio library, it stands to reason that you'd actually know enough to look through this code, and make a .net implementation. If you go and get that started, I'm sure we'd be happy to help. The idea is to go do that, and share what you've done. It'd be great for XNA, at least for Windows (a shame that Microsoft doesn't allow the use of native code on Xbox)

Things that would be possible — C#, .net, Mono, Python, Ruby, Native Client… if you've got *something* that will talk to the audio interface, and it can incorporate native code, you can insert libpd as your sound processor.

thedude

@PeterK: i guess my comment was more about the lack of a c# wrapper right now. i would love to be able to say i have the time and experience to do it properly… but for now i'll just look at PdBase.java to see if i even 'get it' enough to try the .net implementation.

there's a lack of robust dsp libs for .net devs to play with. xna and directx have some built-in dsp for gaming but not for music.

like you mention, a pdlib c# wrapper wouldn't help for xbox. i don't think you can run native code on windows phone 7 either (why ms? why would you limit yourself like this?)… but this would definitely be cool for a winforms synth or sequencer experimentation.

There is currently native code, a Java wrapper, and an Objective C wrapper, that's correct. It really wouldn't be hard to do a C# wrapper… or any number of other things. This wasn't a value decision, though. Once any one of them is done, the others are easier. The C# wrapper would look very much like the JNI wrapper.

We are definitely looking to have Pd embedded in anything where it makes sense, or even where it doesn't! 😉 As long as someone wants to do it, it should not be too hard to do. Peter Brinkmann has done a nice job with the C/Java API of libpd. Palm webOS is another obvious example. I'd like to see Pd embedded into game engines and animation apps like Blender.

Right, and really it will require people using those environments to work out how to make them useful. It's not so much having a separate set of wrappers — the C API covers a whole lot of those scenarios — so much as it is trying it out, maybe having some reusable sample code that glues it into whatever you're trying to use.

Glenn

You say "Because of its licensing, you can even build commercial applications with it." But you also say "The Android version includes the usual externals that come with Pd Vanilla (e.g., fiddle~ and bonk~), and it will load them dynamically as needed."

This pretty much takes it out of the running for use in a commercial product. Many of the externals are published under the GPL, and according to the GPL if you load a GPL DLL, then your entire process falls under the GPL.

From the GPL FAQ:

Can I release a non-free program that's designed to load a GPL-covered plug-in?

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Wish this wasn't the case. For Pd to be used in commercial apps we would need BSD (or similar) licensed versions of all the normal Pd externals.

@Glenn First off, I need to clear up a common misperception: the GPL has absolutely no restrictions on commercial activity. Anyone is free to sell GPL'ed software however they see fit. The GPL does specify that whenever you give someone software, you must also provide them the source code, and give them the same rights over the code that you have. There is tons of commercial software covered by the GPL. RedHat Enterprise is a great example.

The other side of this is that people selling software often believe that you have to hide the source code in order to make money. For those people, they can use the core of Pd and libpd, which is BSD licensed, and the handful of BSD-licensed externals.

Glenn: at the risk of pointing out the obvious, you can also simply avoid those GPL-licensed externals. If you had only the BSD-licensed parts of Pd vanilla on a desert island, you'd still have plenty to keep you busy. You brought up the two most important, arguably, of the GPL'ed bits.

In other words, what we're really talking about is the restrictions on GPL code on iOS. On Android, even that's fine. And on iOS, I think you can safely avoid the GPL-licensed portions and still make an app and sell it; we hope people do. (A previous Pd library was used for a commercial, proprietary iPad app sold on iTunes, so it's already something people do.)

Complying with licenses can demand some effort, but that's true with proprietary software library licensing, too. In this case, it is all very doable. Don't sweat it too much.

Glenn

I would be seriously nervous about using Pd lib in any sort of closed code. Even if you didn't distribute the GPL externals, it could be argued that Pd is designed to load those externals. I think its legally very flimsy trying to say that Pd has a different license than its core set of plug-ins.

The distinction you make, and many free-software proponents make, between commercial and proprietary is a bit disingenuous. Developers usually read "commercial" as "closed." In fact this seems to be the distinction that is being made above:

It’s free to use on any device you wish, and free to modify. Because of its licensing, you can even build commercial applications with it. (That is, yes, it’s open source – but yes, it can also be useful if you’re a commercial developer. You don’t have to choose.)

So, I would stop saying this project can be used in commercial software. It is misleading. At the very least you should make the distinction between commercial and proprietary and the and limitations when working with closed code clear in this paragraph.

It sounds like you should also make the caveat that if you use pdlib you won't be able to release your app in the iOS app store.

Most externals are not rocket science. They are often by nature small bits of code. If a GPL-licensed external is a problem one option is to rewrite it as new code. Hopefully you will open source license the new code with BSD or MIT, but you don't have to. Obviously you must use cleanroom coding techniques because the originals are usually copyrighted. There's lots of books and literature on sound processing techniques and algorithms.

Glenn: I guess I should have said that the Android version provides support for including the externals of Pd Vanilla, but it doesn't include them by default. When you are creating an app based on Pd for Android, you have to make a conscious effort to include and activate these externals. You have to package them with your app, and the app has to unpack them and put them on the search path. If you don't do that, you'll only get the BSD-licensed bits.

thedude: The list of supported languages is largely a coincidence. The entire project started as an Android port of Pd and nothing more. After some refactoring, a Java layer that didn't depend on Android appeared. After some more refactoring, the Java layer split into a C library with a Java wrapper. None of this was part of the original plan, it just sort of happened. Then RjDj got interested and we added an ObjC wrapper for the C library. When someone creates a C# wrapper, I'll be more than happy to add it to the repository.

Glenn

Peter: I don't think that's obvious at all. Pd is designed to work hand-and-glove with its core set of plug-ins. Leaving some of them out doesn't change that fact. A user could still install them, then suddenly (maybe) my app is GPL'd! Personally, I think it is crazy to say that a DLL's license can "infect" the host, but, that's the position of the authors of the GPL, and I wouldn't want to have to gamble on how a judge would decide the case.

Also, one main reason to use Pd is so that people can share patches. If a bunch of the common externals are missing from a distribution you can't do that. Without patch compatibility, why not just start from scratch and do something in C++ with a nicer UI?

Glenn,
"The distinction you make, and many free-software proponents make, between commercial and proprietary is a bit disingenuous."

This only comes into play if you have software that has a license that specifically restricts those uses. That is, if Pd's library said you couldn't make commercial software, or you couldn't make proprietary software, then you'd have to worry about the definition. That's why I bitch and moan about licenses that don't allow commercial use – because then you have to worry about what "commercial" means.

It says neither of those things, so *don't* worry about the definition. Let me be completely clear:

1. You can make proprietary, closed-source software with Pd.
2. You can make commercial software with Pd, software you sell.
3. If you absolutely must use fiddle~, bonk~, etc., you can make commercial software you sell on Android Market (or on desktop, or anywhere else you like that isn't the iTunes store). You just have to release your source. Apple's restrictions on the App Store are out of our purview. They're Apple's business.
4. You can make terrible software with Pd if you want. (I know I have. I am not selling that, happily.)

EA Games, a publicly-traded, NASDAQ-listed, $6 billion revenue-generating company was perfectly find using Pd in Spore, and they have a LOT of lawyers.

If it's good enough for them, it's good enough for you. Don't worry.

"It sounds like you should also make the caveat that if you use pdlib you won’t be able to release your app in the iOS app store."

No. This is not in any way, shape, or form true. You are absolutely, positively free to release a commercial, closed-source app that you sell via iTunes.

This is to say nothing of Apple's approval process. I'm assuming there's a guy with a dowsing rod, a copy of the Human Interface Guidelines, and a sacrificed California Roll who then says an incantation about whether or not you've made the cut. But that's independent of whether you use libpd or not.

Hmmm… actually, that may be how I make my next executive decision. Sounds both wise and delicious.

@glenn Pd is already embedded in a number of commercial, proprietary apps so other developers do not feel there is a threat to worry about. For example, Pd is embedded in EA Games' Spore, rjdj's iPhone and iPad app, iJam in the Apple App Store, and more.

Glenn

>You can make proprietary, closed-source software with Pd.

As I stated above, based on the GPL, I don't think you can. I don't have tons of lawyers. Maybe if I did I would worry less!

Hans said "One last thing to note is that Apple’s App Store licensing terms are incompatible with the GNU GPL. Because of Apple’s restrictions, you cannot include GPL code in the App Store: the code must be useable under a different license in order to be included in the App Store."

— under the link for Vanilla. If you're interested in another external, just check its license. Plenty are also BSD.

You can have a vanilla install next to your, say, extended install. This is actually what the RjDj guys have been recommending, having nothing to do with licensing, and everything to do with compatibility with their RjDj player. So it's a smart common denominator for exchanging patches.

Pd is modular on its own, before you bring externals into the picture. So if you're thinking about distribution, reducing external dependence is generally a smart strategy — just as you'd avoid plugin or library overload with anything you're distributing beyond yourself.

libpd is BSD-licensed, period. I'll look into the situation with particular externals.

As Hans says, patches are another story – those are fine, because you can just release the patch, which is separate from the rest of the code. That means you can still write your closed code, *and* still comply with Apple's rules if you need to.

Glenn

@Richard: But I'm not able to control what plug-ins the user installs and loads into my app. That's why they're plug-ins presumably.

@Peter: What I meant about patch compatibility was, if there are important and commonly used externals that are GPL, then when a user makes a patch in a standard (open source) install of Pd, they may very well not be able to open that patch in the closed source host, since the necessary externals will not be available.

It's nice to hear that you are going to make pdlib pure BSD license. Let me know when it is. I'll be interested to see which externals remain.

RichardL

@Glenn An important thing to understand about GPL is that it covers software distribution. It's possible to come up with an infinite number of scenarios where the end user does thing. (e.g. a jailbroken iPhone running OS dynamic libraries modified with GPL'ed code.)

But it sounds like open-sourced software is not a good fit for you and your projects. I can appreciate that. I'm always the person who sweats all the messy details and licenses.

I wouldn't go that far; your user is not going to be arbitrarily spawning externals. libpd is a pure BSD library. I'm looking further into the situation, but the only external in question is *not* bonk or fiddle, but expr, because of specific parsing code it uses. It is the only exception.

There is an extremely subtle compliance issue, but for the time being, that's our and the Pd project's problem to worry about.

I don't think this should turn you off of open source libraries if one, like libpd, turns out to be the right tool for the job. But I do hope to follow up with a more complete answer for next week.

Glenn

Thanks Peter! I'm definitely excited about pdlib, and appreciate the work you're putting into it.
Yes, if the entire distro is pure BSD that feels a lot safer to me than if parts are GPL that we're having to excise them. It seems like that would still easily leave us open to someone demanding that we prove that the GPL'd parts had been excised and so on. It's not just the GPL that is the problem, its also the proof of compliance that can be a nightmare if you're not careful.

Glenn: It's okay, really. Those few files that make up libpd are all BSD licensed, and they only depend on BSD licensed code. There is no need to excise anything — the only potential concern is the expr external, but it won't affect you unless you explicitly choose to include it in your project.

That said, though, we should probably document that the expr external requires special care. The ideal solution, of course, would be to rewrite expr using nothing but BSD licensed code. Any volunteers?

RjDj is probably the most popular example of a partly closed source, Apple AppStore App based on Pure Data. While we at Reality Jockey are supporters of open source and worked with Peter Brinkmann e.a. to advance libpd and release lots of stuff like the rj library as open source ourselve, we still do the core business on the AppStore, where as Hans-Christoph pointed out, using GPL (v.2) code is at least shady and most likely not possible. Also currently most of the "business logic" parts of the RjDj App (payment stuff an so on) are not open source. So we do not use code that is GPL and written by non-members of RjDj.

But: We can still use Pd in our App because apart from the "expr" object family everything in Miller Puckette's original version of Pure Data is BSD-licensed (including "fiddle", "bonk" and "sigmund"!), so it's save to use in the App Store or embedded in non-open-source Apps. In fact, Pd is (or at least was) used in a similar way in Max/MSP, it is used in the game "Spore" and probably in other closed source apps that don't tell you they are using Pd.

Now of course some popular externals collections are GPL licensed. If you need to use these, you're bound by the GPL terms. But I tell you, there's so much you can do with a pure, expr-less Pure Data, it's amazing. Just check out the rjdj.me website, listen to some recordings, check out the RjDj freestyling or Moovz videos on Youtube, buy the "Air" app or get the RjVoyager for the iPad – all of this music is made with pure vanilla Pd, without any special externals used. You can also reach your goal with a singlespeed and fixed gear bicycle without derailleurs, so to say, and many people even think this is more fun that with a PeDelec. 🙂

Enjoy sounds,
—
Frank

flonk

Awesome news!
And yes, I agree with Frank here, you can do a lot with pd-vanilla – and the lack of expr is not so much an issue, its more a "shorthand" for a series of standard objects, at least as I understand it. Expr~ lets you do a few things that are difficult/impossible (?) in vanilla, but it is probably to cpu-expensive to run on small devices anyways.

Alex

So I'll be able to run this on my S60 3rd Edition too?! I know i need to upgrade, but Im broke.

I simply couldn’t leave your site before suggesting that I really enjoyed the usual information an individual provide on your visitors? Is gonna be back steadily in order to inspect new posts

CyberPhoenix

As you said, Pd talks to audio hardware on the android device, is it possible to get the pure mic recording without the additional manufacturer’s processing with Pd. Most phone manufacturers have their own pre-processing.

CyberPhoenix

As you said, Pd talks to audio hardware on the android device, is it possible to get the pure mic recording without the additional manufacturer’s processing with Pd. Most phone manufacturers have their own pre-processing.

Social

14.5k

Followers

32.8k

Fans

923

Subscribers

CDM is an online magazine for creative technology, from music and DJing to motion and more.