andrea mancianti

I am trying to access the signal vector size from within a max4live device, in order to bring it to 512, as requested by some 3rd party spectral processes I need to integrate in the device, but it keep being 64 smp and nothing seems to work.

I first assumed it was linked to the buffer size of Live, but changing it has no effect whatsoever on that value within max. I tried change it manually using the menu in the audio status window when the m4l device is open for editing. The menu shows all other values but no matter which one you choose, only 64 will be set. Obviously the same happens if using the adstatus objects.

Is it 64 really the only usable value? I am sure there should be a way to access it, otherwise all spectral processes with regular 512 or 1024 fft windows would be impossible, and i would be curious to know how the creators of devices using fft have been dealing with this issue... (Unless pfft now adjusts to smaller buffer sizes by chaining together consecutive buffers???).

I am using live 10 but still on max 7, could this be the issue? I read there could be some driver limitation if a max 8 license is not present on the machine, but still this seems a fairly serious limitation... 

Can anybody point me to the right direction please? It is a fairly important thing. 

Hi all, 
Please help!
I am trying to access the signal vector size from within a max4live device, in order to bring it to 512, as requested by some 3rd party spectral processes I need to integrate in the device, but it keep being 64 smp and nothing seems to work.
 
I first assumed it was linked to the buffer size of Live, but changing it has no effect whatsoever on that value within max. I tried change it manually using the menu in the audio status window when the m4l device is open for editing. The menu shows all other values but no matter which one you choose, only 64 will be set. Obviously the same happens if using the adstatus objects.

Is it 64 really the only usable value? I am sure there should be a way to access it, otherwise all spectral processes with regular 512 or 1024 fft windows would be impossible, and i would be curious to know how the creators of devices using fft have been dealing with this issue... (Unless pfft now adjusts to smaller buffer sizes by chaining together consecutive buffers???).

I am using live 10 but still on max 7, could this be the issue? I read there could be some driver limitation if a max 8 license is not present on the machine, but still this seems a fairly serious limitation...  

Can anybody point me to the right direction please? It is a fairly important thing. 
Thanks a lot and happy patching!

Hi all, 
Please help!
I am trying to access the signal vector size from within a max4live device, in order to bring it to 512, as requested 

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.

Screen Shot 2018-10-22 at 11.30.49.png

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

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 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, 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.


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)

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.

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? :)

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. 

ok right. i could swear it didnt when i tried it earlier today, i guess i had audio off.

did you try yet to put the vst into a pfft?

 it will throw this error "poly~: bad fixed vector size and/or sample-rate 

ok right. i could swear it didnt when i tried it earlier today, i guess i had audio off.

did you try yet to put the vst into a pfft?


Hey Roman, thanks a lot for all your answer. We might be getting closer to a solution but not to understanding I am afraid... :)

Yep, the dac on is what triggers the error.

I rethought what I wrote yesterday. Most probably the reason why pfft still works in smaller vs contexts is simply because it performs zero padding on all the missing samples. So that every window of 512 samples is in fact only 64 samples and 448 zeros.. But this is also speculation.

But, as a matter of facts the plug-in does load in it. I did not have time to figure out how the sound is effected by the padding, if that's what it does, since if I bypass the fft (fftin nofft) I will end up with the zeros in my signal, but at least this could be a direction to explore.

This said i think it would still be extremely helpful to know if there is or there will be at some point a way to affect this vs size altogether inside m4l. Beyond my particular problem, I find it quite a limitation, considering the flexibility we have in max.

Hey Roman, thanks a lot for all your answer. We might be getting closer to a solution but not to understanding I am afraid... :) 

Yep, the dac on is what triggers the error. 

I rethought what I wrote yesterday. Most probably the reason why pfft still works in smaller vs contexts  is simply because it performs zero padding on all the missing samples. So that every window of 512 samples is in fact only 64 samples and 448 zeros.. But this is also speculation.

But, as a matter of facts the plug-in does load in it. I did not have time to figure out how the sound is effected by the padding, if that's what it does, since if I bypass the fft (fftin nofft) I will end up with the zeros in my signal, but at least this could be a direction to explore.

so many new options - but simple and basics tasks stopped working or are "not yet" implemented.

i just found out that with VST3 you can hardly send CC to the host. something we did 15 years ago with no problem.

perfectly terminated at 0:01 o clock at october the 1th, dozens of DMCA requests cleaned the interwebz from the last traces of VST2, to make sure the young generation has no access to building midi controller plug-ins anymore.

it is a question of time that they will reinvent it some day and present it as "new revolutionary feature". probably right after automatic AAX wrapping and support for DSD2048 streams.

but we will not be able to use it anyway because we will no longer be allowed to use GUI buttons with VST4.

oh, this modern stuff. 

so many new options - but simple and basics tasks stopped working or are "not yet" implemented.

i just found out that with VST3 you can hardly send CC to the host. something we did 15 years ago with no problem.

perfectly terminated at 0:01 o clock at october the 1th, dozens of DMCA requests cleaned the interwebz from the last traces of VST2, to make sure the young generation has no access to building midi controller plug-ins anymore.

it is a question of time that they will reinvent it some day and present it as "new revolutionary feature". probably right after automatic AAX wrapping and support for DSD2048 streams.

but we will not be able to use it anyway because we will no longer be allowed to use GUI buttons with VST4.


you can use live 10 together with max 7 ... if you treat them as individual systems.

it should be possible to send audio from live to standalone max (or bidule or rax), run your plug-in there, and send audio back, using a virtual driver like soundflower.

eventually it is more comfortable to build an aggregate device with your IO and soundflower first.

then you can just re-select this driver when you want to get into the same setup again.

but back to your problem.

you can use live 10 together with max 7 ... if you treat them as individual systems.

it should be possible to send audio from live to standalone max (or bidule or rax), run your plug-in there, and send audio back, using a virtual driver like soundflower.

eventually it is more comfortable to build an aggregate device with your IO and soundflower first.
then you can just re-select this driver when you want to get into the same setup again.


The metod you described now with live and max running at the same time via soundflower is exactly the one I have been using so far, but being able to integrate the two i believe could help a lot into keeping complexity (and latency) down.

And, back to the pfft, I menaged to do a preliminary listening test with the no-pfft workaround, and guess what? It sounds quite well! At least in max, set with the same parameters the live drivers requests (1024 64) it is now working fine!

I would be curious to know why it does, how the difference in buffers is compensated, but I welcome the good news.

So I will continue with this and see what happens!

Hi Roman, 
thank you very much for your support! 
The metod you described now with live and max running at the same time via soundflower is exactly the one I have been using so far, but being able to integrate the two i believe could help a lot into keeping complexity (and latency) down.

So I will continue with this and see what happens!
Thanks again
Andrea

haha, great that it works. can you show your current pfft patch so that we can make it a generic variable frame vst abstraction?

Tested also inside Live, no complaints.. :)

of course i cant tell offhand if it is not a misbehaviour of that VST plug-in or the new vst~ object regarding its use of 

using fft without fft to replace poly to host vsts which dont work in vst in max for live

now i wonder if there are there possible other cases besides vst~ where a certain framesize could be required by an object or something which is linked from the object. (usb drivers? networked streams? rewire?)

of course  i cant tell offhand if it is not a misbehaviour of that VST plug-in or the new vst~ object regarding its use of setBlocksize & co.

but i love this pfft solution; using fft without fft to replace poly to host vsts which dont work in vst in max for live is exactly when maxing becomes fun. :)

now i wonder if there are there possible other cases besides vst~ where a certain framesize could be required by an object or something which is linked from the object. (usb drivers? networked streams? rewire?)

-workaroundaroundaround #110



Changing Signal Vector Size in Max4Live - Problem