"Voice" Tracking - interface question for design

New Ideas
1

Hello

I am continuing to add to the toolbox elements that help understand what is happening, and the next in line is to build the “voice allocation” part of FluidSines. FluidSineFeature (new as of 1.0.5) does only the sinusoidal peak tracking part, but FluidSines has also two clever ways of trying to reduce ‘space monkeys’ - mostly taken from SPEAR and also not dissimilar to the voice tracking of [sigmund~] in Max and Pd. See the learn page of FluidSines for an explanation. In effect, the algo looks for distance in frequency and in magnitude to assign a sine peak to a voice, and how long it has been on, and then resynthesise it if it is a valid voice. I want to be able to do that.

Now my question is one of interface. The input to the FluidVoiceAllocator object (or FluidTrackAllocator ?) will be 2 lists (or KR in SC) of the same length X (X frequencies on the left, and X magnitudes on the right) followed by a maximum number of voices (Y).

The output is where my interface option question lies: at the moment, after much pondering and discussions with @weefuzzy and some with @tedmoore and with @rodrigo.constanzo I am facing a dilema:

  • Plan A: always output Y values from 2 outlets, one per voice. Allocate the amp/mag pair to a slot and let it be there until it dies (mag 0 for a least one frame).

  • There were a few plan Bs, including having a 3rd outlet with voice numbers (but what a mess to reassign voices, especially in SC)… another option is to have that 3rd outlet to just assign a number, so inlet 1 and 2 are passed through to outlet 1 and 2, and outlet 3 is just an incrementing number of allocation with the same condition as above (a voice is freed only after being 0mag for 1 frame). I kind of like that too, as it has no maxima needed…

  • There was also a crazy short-lived plan C of merging all of that in FluidSineFeatures (but what a loss for other opportunities of freq/mag voice allocation!).

So, let’s talk interface. When I have enough arguments in one direction, or at least when I’m convinced by one more than another, I’ll implement it.

2

I don’t think I fully understand the semantic difference here, but it’d be worthwhile looking at mc.voiceallocator~ (in Max at least) for how things like that are handled there. There you do get an extra outlet that iterates through the voices.

3

oh nice call - so I’ll check [sigmund~] again and the [mc.*] family to see what they offer and how they limit voices and assign output.

SC people (looking at you @tedmoore @spluta @elgiano @yannics @salkin @mccrmck @alicee @Chriskiefer @groma @axambo) any preferences/examples of such voice allocation mechanism (on the server please!)