Fluid.audiofilesin responds only to mouse click events, not automated events

Usage Questions
1

I am trying to automate the generation of audio files in Max and then immediately set off a chain of analysis. The last stage of my audio generation sends a file system path like

/Users/username/Documents/somefolder

To a subpatcher like this screenshot

image
image1380Ă—398 54.3 KB

As the comments in the screenshot state, nothing comes out of [fluid.audiofilesin] unless I manually click on the [message] object. Is there any reason why the behavior would be different with a mouse click than an automated bang?

2

my guess is a threading issue. try putting a defer before your [t b s] and see if that changes anything. If not then I’ll need to try to reproduce.

3

That did the trick. Thanks.

I am still seeing other errors downstream in the 2D Corpus Explorer example subpatchers:

  • fluid.umap~: DataSet is empty
  • fluid.bufmfcc~: Input buffer corpus: not enough frames
  • fluid.bufmfcc~: Input buffer corpus invalid start frame 88200
  • fluid.umap~: Number of Neighbours is larger than dataset

Maybe some of these other ones are also related to threading? But for some of them, it seems like the fluid.* objects want me to provide more data. I can get it to reliably produce errors in the analysis pipeline if I don’t include at least 16 samples being generated. Is there a minimum number of things that the nearest neighbors part needs?

I am going to try to upload my little test project here to see if anyone else can replicate them. Here are the contents:

  • data/ - an empty directory where sound files will be written into
  • env-randomizer.maxpat - little abstraction to select from a handful of envelope shapes used by the FM synth
  • envelopes.coll - envelope metadata
  • FM-Synth.maxpat - a wrapper wrapper abstraction around the [simpleFM~] abstraction that comes with Max so that it displays a simple UI
  • randomizer.js - script used by [node.script] to generate random values for the FM synth and setup new batch directories for collections of .wav files recorded by…
  • synth-explorer.maxpat - the main patcher to open

The generation of sound files is mine (left side of synth-explorer.maxpat) and the right side analysis part is mostly made from a copy of the plotter-5.maxpat linked from James’ video tutorial (I think I just renamed the sound buffer corpus).

The purpose is to create a “synth explorer” to generate and then analyze the range of sounds that a synth could make. This is a simple example that just generates a small number of random FM synth params (an amp envelope, a modulation index envelope, carrier and modulator ratios, frequency).

My hope is that if I can get this running in a stable manner I could wire up more complex configurations that randomize larger numbers of parameters for more complex synths. The idea is to automate the process of putting a synth through its paces, generating a huge number of sound samples and then using the extremely elegant 2D corpus explorer plot to categorize and cluster sounds.

At the same time I generate the random parameters that generate a new sound, the node script also writes out an entry in a manifest.coll file in each batch directory so the parameter set could be recalled. The recall of parameters from the scatterplot IDs is not yet implemented.

Synth Explorer.zip (15.7 KB)

4

I checked quickly:

fluid.umap~: DataSet is empty

This is a threading problem – it goes away if I turn overdrive off. I think there are two causes:

  • [delay] at the bottom of the loop always promtes to the scheduler thread. Place [defer] after it to go back to main thread.
  • [node.script] returns on to the scheduler thread by default. You can either set @defer 1 or place [defer] after

I think the buf.mfcc errors come from this too

fluid.umap~: Number of Neighbours is larger than dataset

The default number of neighbours in fluid.umap is 15, but there’s only 10 items in the dataset, and NN needs to be > than the size of the source dataset (which ought to be better documented). I’d suggest just making a bunch more examples (but just setting @numneighbours to something smaller will at least make things work).

(FWIW, I think reducing 91-D to 2-D with just 10 examples is a stretch, but see how you get on!)

5

Much appreciated on all these insights. I will try out the additional deferring as suggested and report back if I am still seeing issues.

I definitely understand the issues with using such a small example set. Part of that is just feedback/sharing about how a novice Flucoma user (me) who is new to the entire space of techniques approaches the development process. This particular tutorial (and the others I have tried) are really great because the example patchers are well organized for plugging into my own project for adaptation. So using only 10 examples is just about working out the kinks in my overall automation/pipeline. That is, since this generates samples in real time, I don’t want to wait for 1K samples to be produced just to see if my tweak to the [node.script] code works, which is a classic Max programming problem for me of testing/isolating subsections…

1 Like