An efficient binaural spatializer

The "binauralModeled-ircam" object is a pure-vanilla implementation of the binaural model created at IRCAM.. An example of its capabilities can be found at this page.

The object is found at my repository: https://github.com/andresbrocco/binauralModeled-pd

Main concept

Basically, it applies ITD and approximates the HRTF to a series of biquad filters, whose coefficients are avaliable here.

Sample Rate limitation: those coefficients work for audio at 44100Hz only!

Space interpolation

There is no interpolation in space (between datapoints): the chosen set of coefficients for the HRTF is the closest datapoint to the given azimuth and elevation (by euclidean distance).

Time interpolation

There is interpolation in time (so that a moving source sound smooth): two binauralModels run concurrently, and the transition is made by alternating which one to use (previous/current). That transition occurs in 20ms, whenever a new location is received.

Interface

You can control the Azimuth and Elevation through the interface, or pass them as argument to the first inlet.

Performace

Obs.: If the Azimuth and elevation does not match exactly the coordinates of a point in the dataset of HRTFs, the object will perform a search by distance, which is not optimal. Therefore, if this object is embedded in a higher level application and you are concerned about performance, you should implement a k-d tree search in order to find the exact datapoint before passing it to the "binauralModeled-ircam" object.

Ah, maybe this statement is obvious, but: it only works with headphones!

@pedrobosch https://forum.pdpatchrepo.info/topic/5968/euclidean-rhythm-abstraction
..... and a video tutorial based on that discussion......

@ddw_music Well, it sort of is right since the [mod 5] before it means the [select 0 5] will never see a 5 so the polyrhythm will play properly in its entirety. The reset was a last minute addition and I clearly did not think it through all of the way. Fixed. Thanks for pointing that out.

Here is a scheduler-queue approach. It's a bit verbose because this isn't a common idiom in Pd AFAICS; I haven't figured out ways to streamline the flow. But it does work.

At left, it's ticking once per second, but it can handle any subdivisions you drop into the queue.

22-1125-polyrhythm-sched.pd

Requires abstractions from https://github.com/jamshark70/hjh-abs

hjh

Apologies if I've overlooked something, but isn't the easiest solution to the original problem to withhold the new metro tempo until the metro outputs? Instead of new speed direct to metro, stash it in a [f] box; then the metro updates its own speed at the right time.

22-1125-polyrhythm.pd

This pattern -- forward to storage, then bang later when needed -- is really fundamental, solves hundreds of situations.

hjh

If you follow the algorithm in http://cgm.cs.mcgill.ca/~godfried/publications/banff.pdf, E(5,13) = 1001010010100, But if you use the much simpler one from @Stutter you get 1001001010010. Yes, they are the same if you ignore rotation, but in normal musical practice nobody would say they are the same--they'd say one had flipped the beat (or something). Sometimes the algorithms agree; both algorithms output the same pattern for E(3,8).

[1] Is there a base rotation for Euclidean rhythms?
[2] For arbitrary E(k,n), what is the offset between these algorithms?

@beem said:

Mike Moreno has made these Euclidean rhythm things based on the Stutter patch I think...
https://github.com/MikeMorenoDSP/mian-

Thanks, at the link above the patch that interests me is:
eucgui-help.pd

But I don't know how to use the [midirealtimein] object, there is also no help file: connecting an external keyboard and pressing some keys nothing happens, not even when printing with [print( from outlets.
What should happen?

(I specify that [notein] object, for example, works correctly with my midi keyboard.)

Anyway I tested the patch by putting a metro and works fine.

[I use Purr Data on Ubuntu 18.04]

a.

Mike Moreno has made these Euclidean rhythm things based on the Stutter patch I think...
https://github.com/MikeMorenoDSP/mian-
https://github.com/MikeMorenoDSP/Euklid

@jameslo said:

@atux Can you please repost the links to the two patches you tested? I'm particularly interested in the arithmetic of post #7 but can't make sense of the text representation of @Stutter's patch (and all the hurleur links are broken for me).

Ok, I see that I was preceded.... :D
I add @kyro's patch with matrices: euclidean.pd

I tested @Stutter's patch as subpatch.
For example, with the triad: 3,0,8 the rhythm is obtained:

TUM ta ta TUM ta ta TUM ta

Bye,
a.

Thank you,

very interesting. Two completely different ways: a matricial approach and an apparently simple and effective algorithm.
Ok, the graphic part is missing (with clocks and inscribed geometries ...) to "visualize" the rhythms, but the engine that generates the Euclidean rhythms works perfectly.
I have tested both patches, they are great.
Bye,

a.