Long buffer size requests on fl.sink~ or similar hang

[Former user]

By accident I passed the arguments '=' and '2' to fl.sink~ with a space in between. This produced an indefinite hang and can be reproduced.

fl.sink~ = 2 <- not okay

I assume its being its parsing the = as an argument and doesn't agree with this as its reserved for multi-stream things.

Seeing as its pretty easy to make this mistake and it can cause you to potentially lose work/have to restart max its fairly worth providing an exception to this kind of input and giving the user an error in the console.

[Alex Harker]

This isn't about the = and nothing is actually going wrong here, expect that the arguments in the object result in a request for a massive buffer. I'll rename this as something more appropriate

[Alex Harker]

There needs to be some protection for this....

[Former user]

I suppose its a very specific accident to make, but its definitely an easy one to make especially if you do lots of multi-stream processes and separation at the output

[Alex Harker]

Yes - but what actually happens is that the buffer size is read as a string (error - it should be a number) and the 2 is used to select the units of the enum - as the default length of the buffer is in samples and now we are in seconds badness occurs. I'll sort it - just a bit more complex than I'd hoped for now...

[Former user]

I feel like this is now fixed with the error handling which was implemented a while ago. I didn’t want to close unless this needs review - but just confirming that I don’t get the crash on my end and it all seems fine.

[Alex Harker]

I need to look at this some more and think of some useful protections for the user.

[Alex Harker]

Fixed in the latest by limiting the size