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...

Hello all,
Wondering if anyone can help me out on this project– ultimately, the goal is to have values from pure data create objects within IanniX (curves + creation arguments/coordinates) as well as triggers and cursors to move throughout. All the information is actually coming from Arduino sensors, but I'm not sure if that really matters in this equation or not.

I feel quite confident in pd in general, but I can't seem to get the grasp for how adding objects to IanniX works (and I'm pretty sure the problem here lies within PD, not IanniX, which is why I'm in this forum and not theirs). The example IanniX patch for interfacing with PD works fine for me (controlling the speed of playback), but when it comes to adding new objects, not manipulating existing objects, it doesn't quite seem to work the same way.

For reference, what I'm doing is creating a message box:

[send /iannix/add trigger $1] ------- [sendOSC]

This successfully creates a trigger, but how can I edit its other parameters from PD? How would the creation of curves (i.e. plotting multiple coordinates) work?
There is one example patch on the IanniX forum but it doesn't really give me much information...

Any help would be much appreciated!

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.

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

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

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

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?

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

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!

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!

That is helpful (its a less complicated patch than what I use to extract OSC from IanniX), but what I'm actually trying to do is the opposite:

have data from PD create curves and triggers in IanniX. The information supplied by PD would have to include creation arguments for the objects– curves, for example, need at least two cartesian coordinate pairs (though IanniX technically accepts x,y,z arguments) in order to make a straight line and (ideally) even more to make more complicated shapes.

Any idea how to do this?