Working (but really now just troubleshooting) a patch for an interactive installation with a dance company.

Basis of the patch is that it takes arduino analog input (from piezo elements) and when it detects a 'hit', triggers both a soundfile and a note. Pretty simple all around... nothing too confusing.

The problem is that there are 15 of them so I've already taken steps to reduce all around volume, etc. I've set up a 'keyboard prototype' which is use to troubleshoot my arduino patches (it just triggers using keypad button), and when I test it like this, it seems to perform fine.

HOWEVER, when I use it in realtime with dancers/arduino, the sound suddenly becomes murky and sounds almost as if the sampling rate has been decreased. Curious to see what people think... is it a CPU issue or problem with PureData processing speed? My patch seems to be basically solid, and the arduino performs reliably across the board...

On which os do you work ?
Does your arduino feed your patch with dense flows of data ?(I know, your description seems to answer 'no'). [speedlim] is often used in series with sensor data flows to avoid flooding.

I'm on OSX 10.6 (basically new macbook pro) and using Arduino MEGA 2560 (don't know if that matters, but the more information the better I suppose).

How do you mean 'dense' flows of data? In general, Arduinos do give off that rapid-fire data stream (I think its default is reporting data every 100ms), but since I'm working with Piezo elements (which create the voltage as opposed to modulating or resisting it), all sensors rest at ~0.00 when not activated.

Activated (triggered) converted voltage data tends to register 0.01 - 0.5. My threshold is set at 0.02 for triggering events.

Thanks for your suggestion– I'll play around with [speedlim] and see if that does anything.

A more general question: does Pd reading a consistent value of 0.00 at 100ms take the same amount of processing power as reading constantly fluctuating data at the same rate? If so then [speedlim] might definitely be the solution...

Thanks!

@hzhz said:

In general, Arduinos do give off that rapid-fire data stream (I think its default is reporting data every 100ms), but since I'm working with Piezo elements (which create the voltage as opposed to modulating or resisting it), all sensors rest at ~0.00 when not activated.

100 ms isn't a big deal at all in Pd. The only time it could be a problem is if you are monitoring the data with a GUI object, but I tend to [speedlim] data at 150 ms when doing that because it seems suitable. If you have a bunch of sensors going to GUIs, you should [speedlim] the connection to the GUI objects, and probably slow the rate as you increase GUI objects. But the non-GUI stuff should be fine with a data rate of 100 ms, especially for simple sample triggering that you're doing.

I don't know what the default is for Arduino boards is, to be honest, but I seem to remember the rate coming in from using Pduino was closer to 20-40 ms.

A more general question: does Pd reading a consistent value of 0.00 at 100ms take the same amount of processing power as reading constantly fluctuating data at the same rate?

Yes. However, you can filter redundant data using the [change] object. If your threshold is set to .02, then you can use something like [> .02] connected to [change] to make sure anything following the [change] is only processed when the threshold is crossed.

Great, thanks for that. Actually, never even considered using [change] with relationals... so, news to me!

Haven't gotten a chance to try out [speedlim] or [change] yet, but I'll probably be able to do it tonight, so I'll let you know if it changes anything.

RE rate from Arduino– I actually misrepresented that– what I meant was that my patch is set to re-sample @100ms. Arduino reporting probably is faster– I don't actually know.

One more thing I thought of that could have something to do with it: all of my samples are triggered using [readsf~]... I've had some latency issues with [readsf~] in the past, so I'm wondering if that could account for anything?

Thanks!

It might be. [readsf~] reads directly from the disk, which isn't as fast as reading from RAM. Plus, it has to look-up the file each time you use an [open( message. If you load your samples into tables and play them back with [tabplay~], you'll be reading from RAM. Probably worth a try.

Have you tried just playing 15 [readsf~]s at once without the Arduino triggering?

I haven't tried playing all of them at the exact same time, but I have played them all very nearly at the same time.

I'm basically testing it out as a change it with a 'keyboard prototype' which just has the home row keys and a few other keys trigger the samples as if the piezos were doing it. So, a swipe of the hand across the keyboard triggers them all within a second of each other. And generally, in the installation itself, nothing is ever being triggered in such close proximity (time-wise).

I'm going to try [tabplay~] first instead– seems like that will be the more drastic change, so if that doesn't help it I can go back and try [speedlim] in the old version.

Thanks again, I'll let you know how it works out

I'm already about 3/4 of the way through converting all of my [readsf~] to [tabplay~] and it is already beginning to do the same thing. I am also at this time not using the arduino, so it would seem to have nothing to do with reading or reporting rate on either end.

Could it just have something to do with the number of in's to the [dac~]? Each subpatch (a sample and a note) has two outlets, each going to [dac~].

The thing I'm noticing is that it was behaving totally fine up until the 9th subpatch. Then the same problem started intermittently. On the 10th (where I am now), the problem persists more often, but the more I trigger the subpatches, it seems to 'correct' itself and return to normal. Now, working on the 11th, it hardly ever returns to normal, even if I disconnect all but 1 subpatch from [dac~]

I remember this happening in live rehearsals: it would sometimes 'correct' and sound as it is intended to, and then lapse back into the problematic sound.

Does this help the diagnosis at all?

@hzhz said:

Could it just have something to do with the number of in's to the [dac~]? Each subpatch (a sample and a note) has two outlets, each going to [dac~].

No. Connecting multiple patch cords to audio inlets are nothing more than [+~ ], which is trivial these days. Don't worry about that.

The thing I'm noticing is that it was behaving totally fine up until the 9th subpatch. Then the same problem started intermittently. On the 10th (where I am now), the problem persists more often, but the more I trigger the subpatches, it seems to 'correct' itself and return to normal. Now, working on the 11th, it hardly ever returns to normal, even if I disconnect all but 1 subpatch from [dac~]

I remember this happening in live rehearsals: it would sometimes 'correct' and sound as it is intended to, and then lapse back into the problematic sound.

Does this help the diagnosis at all?

This makes me think that you might be doing some redundant stuff in your subpatches. (I also wonder if it would be easier for you to just do them as abstractions, but it depends on what you are doing.)

We can't really diagnose it without a patch to look at, though. Maybe you could post something that doesn't require the Arduino but still reproduces the problem.

Here's one version of my patch. I made another one earlier without the voice samples, which seems to be working better, but still not perfect. Ideally though, I am able to use both the tones (with [osc~] and [bassemu~]) and the samples. Samples volumes are going to be increased, so don't worry if they don't come through as much and I'll be doing more complex synthesis with the tones, but I'd like to just get this bigger problem figured out for now.

Basically, the arduino input is still there, but it won't do anything (besides give you an error message in the console telling you that there is no arduino port detected...)

Use the home row keys to trigger the samples.

You might have to just play with it for a bit... as I said, the problem doesn't necessarily occur right off the bat, but it usually does happen at some point.

Let me know if you catch anything (or if you see anything that I should be doing differently anyway– I'm by no means a puredata master)

thanks!

http://www.pdpatchrepo.info/hurleur/Dangling_InstallFINALv2.pd

Sorry– totally did not even think about the fact that you won't be able to play any of the samples....

Since they're not abstractions, you have to go through and change file names to things on your computer– that's a lot of extra work for you so if you don't have time, I totally understand!

If you do replace them, consider that each sample is (generally) no more than a second in length, and they are .wav files

apologies again, let me know if you end up being able to do something with it

I don't have time to take an in-depth look at it, but just taking a quick look, the problem might actually be with [freeverb~]. [freeverb~] has denormal issues (i.e. doesn't deal well with extremely small numbers), and when you stop feeding it input the values internally decay but never quite get to zero, leading to really small numbers that end up taxing your CPU. You can prevent it by feeding it just a tiny amount of noise:

[1(
|
[dbtorms]
|
[noise~]
|
[freeverb~]

Also, it looks like all of those [freeverb~]s have the same setting. You may as well just have everything feed into one [freeverb~] in that case.

Thanks– [freeverb~] was actually next on my list of things to look at troubleshooting-wise, so I'll try that out.

I've always been confused as to how [freeverb~] works in feeding it multiple signals... the reason why I configured it the way I did is because I figured that with each set of sample/tones going into its own [freeverb~], the result would be more cumulative in the output, as opposed to sending everything through one [freeverb~] which (in my mind at least) would mix everything together.

Is that the wrong way of thinking about how [freeverb~] works?

Regardless, I'll try out your suggestion. Just to make sure I understand the theory behind it though: the [noise~] (w/ [dbtorms]) is just an extra boost to make sure the amplitude re-sets back to 0, correct? Could you also accomplish this with an LFO?

Thanks for indulging me in all these questions

@hzhz said:

I've always been confused as to how [freeverb~] works in feeding it multiple signals... the reason why I configured it the way I did is because I figured that with each set of sample/tones going into its own [freeverb~], the result would be more cumulative in the output, as opposed to sending everything through one [freeverb~] which (in my mind at least) would mix everything together.

Is that the wrong way of thinking about how [freeverb~] works?

Reverb units are typically linear systems (they might all be, actually, but I haven't studied them in-depth enough to be 100% sure, but I do know that [freeverb~] definitely is). One of the properties of linear systems is that if you have multiple signals each going into their own identical system and sum the outputs, it will be exactly the same as summing the original signals and feeding that into only one system. So if you are trying to get everything to sound like it's "in the same room", you can do it both ways and get the same results, but having only one [freeverb~] is more efficient.

Regardless, I'll try out your suggestion. Just to make sure I understand the theory behind it though: the [noise~] (w/ [dbtorms]) is just an extra boost to make sure the amplitude re-sets back to 0, correct? Could you also accomplish this with an LFO?

Well, first, I should mention that I messed up that previous example. It should be:

[noise~]
| [1(
| /
| [dbtorms]
| /
| /
[*~ 0]
|
[freeverb~]

But you may have figured that out.

A possibly better solution if you don't want any noise added is to just give the input a slight DC offset. This will eliminate the little bit of noise being in the signal, but will, of course, result in a DC offset at the output. It shouldn't be anything significant, but you can always follow it with [hip~] to get rid of the offset if you want.

(signal)
|
| [1(
| /
| [dbtorms]
| /
| /
[freeverb~]
|
[hip~ 5]

Great– the [noise~] treatment seems to be working fine so far and also causes no noticeably audible disruptions (and yes, I did catch the mistake, but no worries!). If I change any of the parameters in [freeverb~], I won't have to change anything on the normalization end, correct? [noise~] should still re-set to 0 regardless of parameters... ?

Just one more question (I promise!): Will having all 15 players set out individually (as opposed to abstractions) affect Pure Data's performance in any significant way that I should worry about, or should I go back and change all of the [tabplay~]'s into abstractions?

Thanks for your help with this, definitely learned something! I've had strange outcomes from [freeverb~] in the past but I've never been able to attribute it to anything specific until now.

@hzhz said:

If I change any of the parameters in [freeverb~], I won't have to change anything on the normalization end, correct? [noise~] should still re-set to 0 regardless of parameters... ?

I don't entirely understand what you mean here, but the [noise~] should remain constant regardless of [freeverb~]'s parameters, if that's what you're asking.

Just one more question (I promise!):

NO! Ask as many questions as you need.

Will having all 15 players set out individually (as opposed to abstractions) affect Pure Data's performance in any significant way that I should worry about, or should I go back and change all of the [tabplay~]'s into abstractions?

I don't think it will matter performance-wise. Individual subpatches will increase the file size, but that's pretty trivial since Pd patches are just text files. It's really more of an issue of patching style and workflow. If all of those subpatches are basically the same, just with different parameters (like the loaded sample), I personally would find it easier to use abstractions instead. You only have to edit the one, and all others will be updated.