mp3
or ogg
IMO!
I was hoping for a super cryptic formatâŠ
Sorry, just another random question while we are here. Should I be careful about samplerates with bufnmfcross? Letâs say if my source and target are on different sr, will that mess things up or is the algo taking that into consideration?
Itâs completely oblivious Iâm afraid, so youâll want to SRC if it matters for what youâre doing
and the simplest way to SR-convert it is with the HIRTâs [bufresample] at load time if they are all over the place, or after load if there is just a mistmatch of the whole corpus vs the target.
Thanks! I just resample my source, thatâs okay, I was just curious if it matters.
Hello, Thanks for you amazing works. Iâm from RĂ©union French a french island in Indian Ocean. I just discover FLUCOMA and your videos and works. Iâm trying to download your patch âasinglewordisnotenough3.maxpatâ without succes. Can you be nice to tell me how to do. Thanks.
I did a little .amxd with fluid.transport~for Live. How can i sended to you? I am a self-taught beginner and sometimes things escape me!!!hihi
Best regards
Joao Ferreira
Hi everyone, new here. I was looking into bufnmfcross recently and found this discussion, which is pretty much the only information on it I can find on the internet! Iâve been using the FluCoMa decomposition tools via Reaper for a little while, also learning Max for about the same time, a year or two. I havenât been doing too much FluCoMa patching in Max though. Reading through the discussion gave me the idea that maybe if I learn how to condense the source files for nmfcross per the discussion, it could give me more insight into the data side of FluCoMa and how I might incorporate it into my Max patching. Easy enough, right?
Iâve looked at OPâs patch, but I get a bunch of âpatchcord outlet out of range: deleting patchcordâ messages in the console, pretty much for all the FluCoMa objects. Also no .json file. Maybe the patch is supposed to generate the file, but anyways, patch doesnât work for me. And looking it over, I donât really understand the patch tbh.
Trying to figure it out on my own, I cobbled together a patch from the help files that does an mfcc analysis on a file, then runs a pca analysis on the results of that and generates a dataset that gets sent to a buffer. Iâm not sure if the data needs to be normalized at this point. Assuming I did things correctly, I should have a 2d dataset of my source file - it looks how I expect at least - but how to get from there to a buffer bufnmfcross can work on, I donât know. Itâs kind of a ânow draw the rest of the owlâ situation.
It could very well be that this is beyond me at the moment, and looking at OPâs patch, seems not unlikely. But maybe a more modest application doesnât require as much complex patching, I dunno. I should note that Iâm not horribly computer or math competent, I rarely find this stuff intuitive, I just like playing with sound. Thanks for reading and any clues how to proceed. Also, cheers for all the good work, the decomposition tools alone have been very useful for me.
Hello and welcome here!
In effect, what the whole thread is about, is that short sounds will be a lot faster to analyse. So I wonder, have you tried to split your long sounds? We also discussed on ways to reduce the number of redundant samplesâŠ
Iâm not sure where you are stalled now, so it is hard to help⊠let me know which patch is not updated with the new interface and that would be a start
let me know which patch is not updated with the new interface and that would be a start
The patch balintlaczko posted doesnât work for me. Looking closer, all the route objects got disconnected from the fluid objects. I suppose maybe the patch was built with earlier versions? But itâs also looking for a .json file for the coll object. But seems like the patch is specific to balintlaczkoâs project, so maybe not horribly relevant.
So I wonder, have you tried to split your long sounds?
I havenât been working with super long sounds, a few seconds to a few minutes. Of course, even a few minutes takes an hour or so. Though it occurs to me as Iâm typing this that I could prepare sounds by eliminating silence or quiet parts, but then thereâs still the problem of longer sounds even after that process.
We also discussed on ways to reduce the number of redundant samplesâŠ
This is where Iâm getting stuck. If I understand things correctly, I want to do an mfcc analysis on my source audio, take the data from that and run it through a pca to reduce the dataset to 2 dimensions. This is where the redundant information gets eliminated, yeah? I can get this far, but I donât know how to get from the 2d dataset to something that I can use for the bufnmfcross operation. Iâm probably missing a bunch of steps here. Edit: one step looks like Iâm missing is fluid.grid~, but Iâm not sure how it fits in.
As explained above, the process will take a lot longer as sounds get longer. Square the time. So if a 10 second sound is processed in 5 sec, a 20 second sound will take 25 sec, and a 40 sec sound will take 33 minutes⊠so the shorter the sound the much much more efficient the process will be.
The idea is not âfor bufnmfcrossâ but to remove duplicate sounds (so you have less sounds to process). The idea is to describe the sounds somehow (MFCCs might do) then map them in 2d with UMAP (the cleverest way we have to do dimension redux) then to use grid to force that map on to a 2d equidistant plane. Then, you skip boxes:
1 2 3
4 5 6
7 8 9
if you keep 1 3 5 7 9, or 2 4 6 8, you have a âdownsampledâ dataset that is more representative (covers a wider space) than taking 1 2 3 4.
Does it make sense?
I donât know how the grid âforcesâ the map to the more âcontinuousâ distribution, but the more classical way some people do it is to find a K with K-means that is the lowest while describing much of the variance (one idea is to measure the mean/std of distances to centers and try to get low means while getting low variance too â donât forget multiple runs on each K to be sure), and then picking N samples closest to each of the cluster centers. Does not guarantee any kind of continuity though, but it might help pick the ârepresentativeâ samples. I remember that in my case above the grid gave me a surprisingly good decimation of the dataset, and made me realize that my dataset was not so diverse after all⊠But I was a bit crazy and then went on using the full dataset anyway, because I felt that there was some tiny extra variation in that version that sounded better.
(Also, maybe this is redundant to mention here, but in my experience the perceptual relevance of a scatter plot could be a bit of a hit or miss, and it very much depends on the descriptor space and your sounds. (A wise @tremblap once told me to actually listen to my sounds and decide what descriptors to use based on that, which helped me quite a lot.))
I think I understand all that, at least in very broad strokes. But I donât understand what to do with that information. Say I do all the data analysis correctly on my source file, now I have a âdownsampledâ dataset, how do I use that data to reduce the size of my original sample?
Or am I approaching this from the entirely wrong angle here? Like, Iâm talking about using a single source file. Does this discussion assume that the source is already sliced up somehow, analyzed and then individual samples/slices are selected and re-assembled (concatenated?) to build a new source?
now that you have a representative sample, you use only these slices.
bufnmfcross indeed works on full buffers, but you can compose temporary buffers for processing via bufcompose, instead of writing many files to disk.
Ok slicing is a major step I was missing. Iâve been doing all my analyses on the source file as a whole, rather than on slices. I hadnât noticed looking at the help patches, e.g. for the pca and umap objects, that they included pre-made slice information and so I couldnât figure out why things werenât working how I expected. Iâm now using/picking apart Ted Mooreâs pca/umap patch from one of his talks, thatâs helping me understand better (hopefully) that part of the process. Then I need to figure out how to select slices from the grid for downsampling and then pack them into a buffer to use for nfmcross. Fancy list-processing and then build a giant message for bufcompose, I guess? Iâm not that far yet though.