[Docs] BufNMF Translation

[jamesb93]

as it says on the tine

[tremblap]

tab 1: good
tab 2: bug: draws the same channel twice for both bases and activations
tab 3: it is sad that we lose the native fft frame extraction. is the vocoder example now in the example folder?
tab 4: it is sad that we lose the non-incrementation explanation, no?
missing tab (for @tedmoore too): in light of my comment of @mode 2, we could have a tab for @mode 2 for both activations and bases, or did you plan to put such example as advanced somewhere else?

[tedmoore]

mode 2 for both activations and bases, or did you plan to put such example as advanced somewhere else?

I think it should go in the help file. It just wasn't a thing yet when the SC versions got done. I'll make a ticket to have it added for SC.

[jamesb93]

tab 1: good
tab 2: bug: draws the same channel twice for both bases and activations
Got it now, thanks.

tab 3: it is sad that we lose the native fft frame extraction. is the vocoder example now in the example folder?

I think this is a matter of perspective. I found that particular sonic example underwhelming and often just quite vague with what was happening. Many combinations of activations / bases even with strong resynthesis results would sound like a bit of noise being enveloped weakly. fluid.nmffilter~ on the other hand is more obvious to me and represents a clear use-case of the objects working together. Also, not many people know or use pfft~. I think we can communicate the nature of nmf better with the objects in FluCoMa.

4: it is sad that we lose the non-incrementation explanation, no?

I find this phrasing of a remark discouraging in terms of discussion. It's a lot like when someone says "is that alright?" as a way of mitigating what they know to be wrong or an imposition. I don't find it sad, and AFAICT, the patch is exactly the same as it once was unless you are 0 counting? I don't quite follow so you'll have to help me.

missing tab (for @tedmoore too): in light of my comment of @mode 2, we could have a tab for @mode 2 for both activations and bases, or did you plan to put such example as advanced somewhere else?

We have fixed bases example in the "fixed bases" tab, so I think another tab would have to be didactic in order to clarify. Maybe "updating bases" can be expanded back to its original form where it had a @basesmode 2 thing going on. To me, the clear use case of of @basesmode 2 is made in the "fixed bases" tab, though it does ignore activations. Do we/ did we have a convincing musical example of seeded activations? That failing, a good didactic one that doesn't just make pshhhhhhh. I imagine something to try would be using noveltyfeature to make activations.

[tremblap]

3: It had a strong didactic angle: we need to show people how to bridge between native fft and our fft mags and that was a good way. maybe that deserves its own vignette if you think it is abstract. maybe a generic one including bufstft+bufflatten since it is the same idea/concept.

4: what was there before is the non-updating part of the same patch @basesmode 2 - so one could see activations updating but bases staying as they are.

newtab: it is very advanced use hence tagging @tedmoore too. I think we should maybe do a vignette/learn with the missing bit of 4 above, and that double mode 2. that way we have an extension to our learn articles on the very rich nmf family and we are not blocked to release. in effect the help is already quite demo enough to get people help - and inspire - without these 2.

[jamesb93]

3: It had a strong didactic angle: we need to show people how to bridge between native fft and our fft mags and that was a good way. maybe that deserves its own vignette if you think it is abstract. maybe a generic one including bufstft+bufflatten since it is the same idea/concept.

Indeed, I think a vignette that shows it would be useful but it is abstract. I also think it could use some finessing because it didn't sound very convincing to me.

4: what was there before is the non-updating part of the same patch @basesmode 2 - so one could see activations updating but bases staying as they are.

Ah I understand now. This seems like it should be somewhere isolated to clearly express it as it's a heady concept.

newtab: it is very advanced use hence tagging @tedmoore too. I think we should maybe do a vignette/learn with the missing bit of 4 above, and that double mode 2. that way we have an extension to our learn articles on the very rich nmf family and we are not blocked to release. in effect the help is already quite demo enough to get people help - and inspire - without these 2.

For sure

[tremblap]

3: it sounded convincing enough to me to be in my last tune :) I'll make a ticket (on learn) with the idea

4+new: again I'll make a ticket on learn

so we can probably push as is then

[jamesb93]

3: it sounded convincing enough to me to be in my last tune :) I'll make a ticket (on learn) with the idea

I think its simpler and more appropriate to stick a patch here

[tremblap]

ok - you can steal back the vocoder code and maybe riff a bit more on the narrative of fftsize+1

I'll make a ticket on learn for mode2 and mode2mode2 - this is deffo advanced!

[tremblap]

this is deffo advanced!

and not urgent!

[jamesb93]

ok - you can steal back the vocoder code and maybe riff a bit more on the narrative of fftsize+1

I think you misread me, I am asking if you can show it doing something cool

[tremblap]

it was already cool for me. so if you don't have any inspiration, just put that tab back.

[jamesb93]

it was already cool for me. so if you don't have any inspiration, just put that tab back.

I don't think that is a good reason. My opinion is that while the example is didactic it doesn't work that well sonically and even then, the didactic benefits are lost in the complexity of the patching and idiosyncratic-ness of the example. fluid.nmffilter~ makes a clearer case for what the object is doing and more abstract theoretical concepts behind freq domain processing could be left to a vignette. Being cool isn't enough, it has to be effective and clear in order to not confuse users. Hence why every cool thing I've done in FluCoMa (in my opinion) for my own works is not in a help file.

[tremblap]

I don't think that is a good reason.

it worked sonically, that exact sound is used in my tune! it worked didactically: it allowed cross synth (which has now dissapeared from the patch). So bring the concept back the way you want, but if you ask me, the old way was both sonically and didactically convincing. we just need the concept back now. we can improve examples later.

[jamesb93]

I don't think that is a good reason.

it worked sonically, that exact sound is used in my tune! it worked didactically: it allowed cross synth (which has now dissapeared from the patch). So bring the concept back the way you want, but if you ask me, the old way was both sonically and didactically convincing. we just need the concept back now. we can improve examples later.

This is exactly what I am asking for. Can we make a better example, perhaps using the bases/activations from your tune? Nicol/TwoVoice cross synthesis does not sound good on its own.

[tremblap]

also, the vocoder metaphor is a useful one to teach what bases+activation do.

[tremblap]

you could do the same as before with 2 components (cross-basis synth on twovoice was done on 5 components before and made it probably too abstract but 2 components would probably make it clearer)