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