< Back to IRCAM Forum

Source presence

Spat
#1

Hi all: I am noticing a certain odd behavior with the source presence parameter.

When I start a patch, I send an init value of 100 to all sources. I then run a series of trajectories, operating on azimuth, distance, and sometimes yaw. When I stop the trajectories and return all distances to 1., source presence values (which vary as a function of distance) do not necessarily all return to 100. Some are at 98, or 93… And these small differences are compounded over the course of a longer piece.

What I would like to understand is: Is this expected behavior? What other parameters, besides distance, influence the source presence value? How does one keep the base value of source presence constant over the course of a piece?

Any help would be much appreciated. Many thanks…

#2

Hello Christopher,

Could you maybe send a patch that demonstrates the issue? In particular, I’d like to see how spat oper is initialized, what is the range of distance being traveled by the trajectories, and what is the approx amount of messages sent (before the problem appears). Also, versions of Spat, Max, and Max overdrive setting might be useful informations to debug the issue.

The distance attenuation law is governed by several inter-related parameters, namely: distance, source presence, radius, drop (and drop factor). Yaw has nothing to do with that. Azimuth is not involved either, although it might marginally contribute due to small numerical rounding errors when converting coordinates (e.g. from cartesian to polar).

T.

#3

Thanks; here’s a demo, with instructions inside the patch.

It’s a weighty patch, for sure. But even without audio, these calculations are off. I expect the number of messages or rounding errors is the problem.

Using Spat 4.8.0, Max 7.3.4 with overdrive on (no audio interrupt).

Demo-Spat-Trapani.zip (31.3 MB)

#4

Hi Christopher and T,

I was curious enough to look at your patch Christopher because I had somewhat similar problem with spat this spring. The source presence didn’t seem to work correctly with the Spat 4.9.0 and Max 7.3.3. F.ex I had a huge distance between the sources (10-50 meters) but I couldn’t hear it in the sounding result at all. Nothing changed, no sense of more distance when moving further away from the center. The only movement I heard was the azimuth. For me the problem was completely solved by switching off the parallel processing of spat.spat. The difference was huge. I saw that in your patch Christopher that the parallel processing was on.

Might the parallel processing still be the problem of the new Spat? Surely it can be the problem of Spat 4.8.0 if it was the case with Spat 4.9.0.

Best wishes,

Maija

#5

Hi Maija and Christopher,

I think those are two different things.

Yes, there has been a bug with parallel processing in some versions;
I have marked this as resolved in 4.9.2 (dont remember exactly when it was introduced).

Then, there is indeed a bug with rounding distance/presence errors that might cumulate over time.
I have mostly fixed this in the attached version. I say “mostly” because, unfortunately, I was not yet able to fully eradicate the issue.
However, the rounding errors are now so small that it should no longer generate noticeable problems.
(I did some testing and after sending a few million random messages, the source presence drifted from less than 0.5%)

In any case:

  • I recommend to use the latest version whenever it’s possible (Christopher, you’re using 4.8.0 which is almost 2 years old; several things have been fixed/improved since)
  • keep in mind that @parallel is tricky, and in many situations it wont improve significantly the performances (it might even degrade it)
  • resetting spat oper from time to time (e.g. in between sections of your piece) wouldnt hurt
  • avoid sending crazy rate of messages to spat oper: this will blow your cpu, but the results might not be audible (spat~ will anyway smooth the audio rendering by using some “slow” ramps and crossfades)

T.

spat.oper_.mxo_.zip (2.97 MB)

#6

Thanks to both of you for having a look, and for the new object T. I added parallel processing just yesterday to try and solve the issue. It didn’t seem to change the performance much, the rounding error was present either way.

I also tried to limit the number of messages sent, gradually increasing the grain of my line objects up to 50ms. But the error persisted. At first it’s barely noticeable, but say you leave a circular trajectory running in Spat while working on something else for twenty minutes: in theory the state of the patch shouldn’t change; in reality, the source presence has diminished below 20… It’s tough to know what the practical limit is, and beyond that, whether changing Max Preferences scheduler settings might help resolve the issue…

Will test with the new mxo, and update soon as well! Thanks again…