Changing Signal Vector Size in Max4Live - Problem

perhaps you can put you patch in poly~ an set the vector size for the poly~.

Thanks for your suggestion DOUBLE_UG, but unfortunately it is not possible to allocate a bigger vector size in the poly~ than the mother patch. Only the other way around is possible: you can have a poly with vs 512 if the general vector size is 1024, but not 512 with a general vs of 64). It just throws an error...

Ping. Sorry to insist but this thing is keeping me stuck and the fog is getting thicker.
Finally I purchased the actual max8 and now the audio status doesn't seem to influence the vsize at all. I might lack information on how the connection between live and max work, there is something going on under the hood obviously, but there seems no way to influence it.

I upload a snapshot of the m4l device open, dac on, buffer size of 512 and the audio obviously running somewhere else, since the vst loaded in the m4l device still doesn't get the 512 sample it requires. Obviously, just to be clear, it works on pure Max and I already tried changing Vsize in Live.

I would really like to hear an official answer on this.
Is there really no way to change the vs from a m4live device??? It seems such a problematic limitation to me... Thanks a lot for the help

cant you can use pfft~ instead of that third party external?

plug-in interfaces usually dont let you change their vectorsize for a reason. you might say thats also true for dirac :) ...but who was first?

Well, of course I could, but the question here was not how to possibly do the same work in an alternative way, but rather if and how it is possible to use that specific tool, developed in the university where I work, within the max4Live framework.
Since in max changing the vector size is one of the most basic features, I would expect this to be possible in max4live also and I am surprised of the contrary. I also believe it is important to understand the mechanics of a host when designing plugins for that host, no matter what. I for instance fail to understand for example with a fixed vs even how pfft is going to work in real time.

well, it introduces latency.

actually the question should be why it doesnt work in poly when it works in pfft.

in disregard of my first (failed?) attempt to make a useful comment, the "i/o vectorsize" of the plug-in interface should have nothing to do with a subpatcher like poly.

i was just looking into max 7 (i dont use m4l) and there the "vs" argument is not even listed under "arguments" in the helpfile - only as attribute. (but it works, including increasing the vs)

oh wait, maybe the vst~ object ignores the poly vs around it. :D

try using a vst inside a poly down 8 and you´ll see where the problem is.

that it probably also the case for amxd and her friends.

Actually I guess in pfft there is a work around the fixed small vector size of 64 samples, with some sort of buffer that accumulates the smaller chunks coming in until it reaches the amount specified in the pfft window size, but this is all pure speculation.

For sure it does not work with poly, where independently of what you put inside poly (vst or no vst) it will refuse to instantiate a vs of 512 when the live driver inside max allows for 64. But this is also true for pure max. If you have 64 as a vector size in the audio status and trying changing the vs of the poly to 512 , it will throw this error "poly~: bad fixed vector size and/or sample-rate (512 > 64)" because there is nothing accumulating the 64 frames until they reach 512...

The question is then simply, can I use live for this work or have to switch to a different piece of software, since the whole project is about using that vst with this 512 limitation? :)

Thanks a lot anyway