NodeBeat – Created with libpd + openFrameworks

seth.sandler

Since I didn't announce NodeBeat (http://NodeBeat.com) when it first came out, I think now is the appropriate time since we just released a major version update for NodeBeat HD (iPhone version to follow). The new NodeBeat HD has a lot of new features including a drum generator node and drag/drop interface for music creation.

NodeBeat is an experimental node-based audio sequencer and generative music application. It's a cross between a toy and a music creator.

It's programmed in c++/obj-c using openFrameworks and uses libpd for audio via Dan Wilcox's (http://noisepages.com/members/danomatika/) ofxPD addon (https://github.com/danomatika/ofxPd).

In terms of libPD, the audio is fairly simple. It can switch between sine, triangle, sawtooth, and square oscillators, with adjustable ADR. We also use a delay line so people can control the echo. We're able to record to wav file using PD's [writesf~] object, but we compress the audio for e-mailing using native obj-c code (I can share that somewhere if interested). It would be great to find a non-GPL licensed object for PD that does audio compression; does anyone know of one?

If you have any questions, feel free to ask. Take a look at the website to get a sense of the application. There's even a free desktop version with minimal features. The video will be updated soon to showoff the new overhaul.

Thanks everyone for contributing to libPD, it's really helped making audio applications relatively painless. :)

seth.sandler

Here's a new video demonstrating some of the features.

reakinator

I tried out the ipad app, very nice interface and it sounds solid! There are a couple comments I have though:

- clicking some of the menu items lags the audio thread. It doesn't seem to skip, I think it is the messaging layer that is being lagged, while the audio layer keeps on happily processing audio.
- when there are a few nodes and generators (is this what you call them?) I find it hard to distinguish what node is producing what sounds. I think it would be helpful to add a 'pulse' down the line that connects with the node right when it sounds off. They do this with the reactable and it works well.

All in all, I think you guys did an excellent job, a very creative approach to sound sequencing. Thanks!

seth.sandler

Thanks for the feedback Rich, it's really appreciated!

I'm still pretty new to iOS development and c++ in general to some degree. On the iPad 2, the menu items don't get the lag, but I've seen what you're talking about on my iPhone (about to release the iPhone 1.5 version). I'm trying to figure out how to avoid that as it seems to be during allocation of the view controller (the menu). If anyone has any ideas, that'd be great. ;) I haven't really dealt with multi-threading much, but maybe this is a place for it? It's definitely something I'm looking into.

Yeah, 'generators' (cause sound) and 'notes' (play sound) are what we call them :). I like your idea about the pulse dot down the line to indicate where in time it'll play. I was thinking of something similar; i'll see what I can do. :)

Thanks again for the comments/support. It really helps!

reakinator

About the lag for the menus, have you looked at grand central dispatch? If you do some profiling in your view controller's loadView method (or viewDidLoad, depending on which one you prefer) and you find any sort of things non UIKit related, you can push it to a background thread quite easily using GTD.

Another thing I have done in the past is to call the "performSelector:afterDelay" method in the button handlers so that the button is released without any stuttering. I don't know if this will help in your case, but maybe something along these lines will allow the messaging thread to keep running without hickups.

seth.sandler

Thanks for the suggestions. I haven't looked into central dispatch. I haven't seen button lag personally - I've only seen the lag when opening/loading the view. I'll definitely look into these.

I know there's also some issues with GUIs and openGL. For example, table views and anything that slide, stop the main time loop. I don't want to get too off topic though hehe.

I also wanted to say that in an early test of ofxAndroid (openFramework's android addon) libpd works without any changes to the codebase for iOS (other than just commenting out native iOS calls). I have a non-GUI version of NodeBeat running now on Android with libpd.

dreamless

I'm facing a similar problem. I have the CPU load meter from pd output to a label so I can monitor it, which works fine. The CPU load always spikes when allocating new views to show, and after the view has been opened and closed a few times the CPU load stays quite high, even when everything has stopped. I tried running pd in its own thread but the result is the same. Any ideas on why the gui affects pd's CPU usage?

seth.sandler

I'm not sure why it could affect PDs usage specifically, but I can imagine that it would effect the overall app usage or slow down PD if everything else is slowing down.

I think I found what the problem is in terms of NodeBeat (still working on a fix). I'm using openFrameworks which draws openGL. It's currently drawing on the main thread. From what I understand it's best to leave iOS UI stuff to the main thread and move other things off. Because the app is openGL heavy, it's blocking the UI (and vice versa) when a UI loads.

I was reading up and it's possible to move openGL to it's own thread and I've been testing this with positive results. There's good examples here: https://github.com/Volcore/LimbicGL. By moving the drawing to another thread, the menu doesn't pause openGL/audio when it comes up. It is slightly delayed (while it loads), but it's better than blocking everything else.

Is your app using openGL or openFrameworks? Is there other high CPU things going on besides PD? I haven't tested yet to see how much CPU usage is being used from PD in NodeBeat. I can report back with that later. In the iPhone version I tried combating things by allocating the views and retaining them before the app stars. It's off though because the first time they load, they are slow - but all the times after they are fine. I couldn't figure out a way to preload that first view.

dreamless

My app uses nothing but libpd. I'll continue to search for a solution as well. It might be worth noting that the audio continues to play back fine, even when the CPU loads reads 100% or more. This is on an iPad 2 though, so there is a lot of power for libpd to use. I'll eventually have to test it on older devices.

seth.sandler

Yeah, let us know if you find anything out. It may be worth opening another thread so other people can chime in. On my iPad 2, I actually don't see this issue. However, I also have a first gen iPhone and I can see the menu pause openGL somewhat. Based on your description, our issues may be different as the audio/draw thread does seem to pause. You can see what's happening in this video at 2:15

dreamless

Just a heads up, my cpu spikes were due to an NSTimer that I had let run wild on accident. Allocating the view controllers once at startup also solved the problem of the views lagging the audio thread (except for the first time they are opened, but thats better than every time!)

seth.sandler

Great to hear you got it worked out. I still find it odd that it lags when opening the first time considering things are allocated prior. I'm curious if there's a way to load these earlier on so that even the first time this doesn't happen. I'm still experimenting on my end since I think moving openGL to it's own thread may have solved the lag (even the first time).

veqtor

Sorry for resurrecting an old thread, I was wondering, are you loading pd patches or patching by commands?

Howdy, Stranger!

Categories

In this Discussion