New Object Early Community Build #1: FluidVoiceAllocator (NOW WITH SC TOO)

ok here is the first offering. No help yet, but a great demo patch by the brain behind the voice allocation, @fearne - Warning: everything might change, interface and all. It is carefully thought of, but hey, suggestions and discussions are welcomed :slight_smile:

Presenting FluidVoiceAllocator, a real-time implementation of message-in message-out voice allocation. It has the same interface as FluidSines for the track allocation and validation, then some special magic voice allocation ideas from @fearne @a.harker and yours truly… not forgetting @weefuzzy and @groma for the original sine tracking interface!

Max (MacOS and Windows) only now but any Pd users could translate the patch if they have time (I can put the binaries of all 3 OSes here too). For SC, I’m still testing the framework changes, then binaries will be available if anyone wants to help to code the same max example. or that will happen eventually too.

(now FAT for MacOS) (327.0 KB)


fluid.voiceallocator: could not load due to incorrect architecture

Guess it’s not UB2 yet?

Screenshot 2023-08-26 at 11.54.10 PM

Managed to test it on my laptop and it sounds good!

Even at more real-time friendly FFT sizes.

I guess it could get expensive, but having a waveshaper core, rather than individual oscs would be nice (for a future help file). Also, I guess in this case fluid.sinefeature~ outputs n amount of components all the time, so there’s no use in muting individual voices (since they just steal/transition to each other)


I forgot the fat builds sorry - can you check this binary please? If it works I’ll repackage (76.2 KB)

Nope, same issue.

hmmmm. Indeed it is not fat (after terminal check) despite me asking for it in XCode. I hate them.

Mucho mysteriouso that stuff is…

Actually, don’t know if you still are mc. averse, but an mc.-based implementation would be super elegant and a lot more mutable/tweakable.

I am still mc. averse yes :slight_smile:

I have now compiled the object another way and it fails. I’m troubleshooting

ok this should work - it is fat according to my terminal invocations. (134.9 KB)

1 Like

so that heart is a yes?

link in OP now FAT - any Pd takers to translate the example? I can provide (fat) binaries for MacOS, or skinny ones for Windows and Linux :slight_smile:

SC is almost there for the binaries

Yup, had to hop on a quick zoom mid-typing out my response!

Working well.

This is going to to be the most terrible nitpick and I would be angry if I read this feedback about my own work… but…

Should it not be fluid.sinesfeature~ plural to match fluid.sines~? I can easily forgive the incongruence but there is something to be said about autocomplete helping people find things. If you type fluid.sines into a box you won’t see it in Max. I assume something similar would be the same for SC. pd… well…

One piece of feedback is that much of the instantiation of the voiceallocator object in the help file occurs outside of the object and is also quite distant spatially in the patch. That means if you copy out some of the contents, such as what is seemingly the most important part you won’t get a functional patch. I would advocate that the attribtues such as @numvoices and @prioritisedvoices are written into the box alongside having the controls.


I really like this object, I can see myself having a lot of fun with it :slight_smile:


Don’t know if that starts getting too clunky, but having some Max version checking and scripting to instantiate an mc. example, as it would be super useful in that context (sines in general, as a descriptor type, as per @jamesbradbury 's example above).

It’s a bit inconsistent all over the place (mfcc vs melbandS), but they typically stay consistent among each descriptor type.

Also curious about the naming here, since the naming is generic and not sines-specific. Is there another use for this object inside FluCoMa, or in general? (it seems quite different from the voice allocation inside mc. for example, and from sigmund~ from what I remember).

Ah, this is great, I did want to implement the demo patch with mc. objects but hadn’t worked with them in a while and something that worked was better than nothing at all haha

One piece of feedback is that much of the instantiation of the voiceallocator object in the help file occurs outside of the object and is also quite distant spatially in the patch.

And this is a great point, I shall make adjustments to the version I make for the help file :slight_smile:


this was discussed in and @weefuzzy opted for singular - if you look at the commits it started as plural but he made me see the light… :slight_smile:

it is actually grammarly right: mfcc is an abreviation (no plural) and bands is a noun. but then, people have started to argue about anything grammar in English since the US independance, so we have a style sheet for naming - usually Oxford Brit English :slight_smile:

I can think of one or two - for instance, you could take 40 melbands and keep the loudest 4 with this to find peaks and allocate them. or you could do that with EQ peaks to ride an eq smoothly. Anything that needs assignation of (pitch and/or gain) lists to its nearest ‘voice’ to make poly patches is your friend here.