Fluid.hpss~ small crash

Small crash when playing with fluid.hpss~.
I use:
fluid.hpss~ @psize 20 @hsize 3 @winsize 512 @hopsize 512 @fftsize 2048

crash_fluid.hpss~.txt.zip (63.3 KB)

I cannot reproduced - apart that it sounds awful due to the non-overlap. You know that the size of filters have to be an odd number, as written in the helpfile? This does not cause my system to crash though…

Just curious: how hard would it be to add such warnings into objects (to print out to Max console)? I can follow things strictly, of course, but in full mess-about-mode I might forget to reference all arguments in the help file. It actually helps me learn: I know about FFT so I would automatically enter a power of 2 for e.g. fftSize. I’m not sure why the perc. filter size needs to be odd >=3, so seeing that warning would 1) make me inclined to read more 2) stop a coding mistake which I might not notice for a while, while trying to figure out why desired results aren’t occurring.

1 Like

@weefuzzy, how do you like this idea of warnings just verbose enough to entice self-education? I think it tickles the geek curiosity of our target community (it certainly does it for me and @saguaro :wink:

@weefuzzy will let us know the hardship of warnings. Sometimes it has to do with efficiency, sometimes with us.

1 Like

It can throw up a yellow error message, but also “round down” to the nearest value, so it will output sound.

So an even number filter size will become that whatever was input - 1.

As far as I know yellow warning is for naughty scheduler things or audio feedback where its not allowed. Seems bad to put trivial stuff into the yellow warning.

That said @tremblap was there no plan to do error reporting for the user at all? That seems…odd.

You’re asking the man that has you manually calculate the latency in samples with a formula…


you know me - knowledge, power and responsibility are intertwined - I like to share it all!

1 Like

Hello everybody,

This might be quite a variable threshold.

One change in the re-factored version is that attribute constraints can / will be enforced more quietly at wiggle-time, incl. snapping to odd numbers / powers of two, if we feel like it. I know @tremblap worries that this would be feather-bedding people too much, but I’m not so sure, so the infrastructure is in place for me convincing him otherwise :wink:

As for warnings, errors, outbursts of symbolist poetry etc.: I’m still plotting through the best way to do this. One thought is, as is common in supercollider, to have an adjustible level of chattiness, so that warnings can be enabled, e.g. when an attribute has been clipped.

Another side-effect of the redesign, as I mentioned in the thread on long argument lists, is that for offline objects I plan to remove the ability to supply attributes in the argument list, as it’s confusing from a UX point of view, and makes the code more brittle. An upside is that this makes it harder for the object to be in an invalid state before calling process (because constraints can be enforced for the attributes). If this is combined with the option to have some warnings attached to attributes, we might find a good balance between informing people and enabling them…

And, @rodrigo.constanzo, I have already added a latency feature to the new RT objects, because I :heart: U . My plan is that, in Max, this will appear as a read-only attribute, so one could use a dump-outlet to query it, or getattr, or pattrhub, etc etc. All that stands in my way is inferring the missing API documentation on how to make dump outlets work :roll_eyes: In SC (for anyone worried), we can do a thing where a new command is attached to a UGen instance, so the node can be queried from the language at any given point.

1 Like

There’s a time and place for pedagogy, but “every time you use the object” isn’t it!