Problem with fps

I m delightly fighting with my fps wich are vvvverrry bad… 8 to 9 fps…
Despite the processor is used at globally 17%.
I m working on a hudge project, where there is a lot of DOPE structure to load and a lot of dds on screen, and a lot of audio wich can be played simultanously ( 12 players).
I m not undrestanding in fact, if my processor is not very used,whats going on.
I have a good ssd.
I m using the Enable trick to avoid extra calculation than needed.
Does anyone has any trick to help me going back to a correct 25 fps ?

thank you so much !

I guess your patch utilizes just one core of your processor. Depending on the core count of the prozessor 17% most likely means that this one core is running at full capacity. To get more FPS per second you have to use more cores. How to achieve that is highly dependend on your specific patch / setup. One thing that you can try is running mutliple instances of vvvv, let’s say five. Four of them have Three players each and then share the texture via SharedTexture or Spout to the fifth instance which ouputs the “scene”.

1 Like

Thank you Bjoern. Ok that is a super answer.
The pb is i have many S and R things. It works between multiple instances ? (values)
And how do you setup the repartition of the VVVV instances ?
Other question is: is it possible to send in memory a dX11 group output ?
I have 17 chapters, all along corresponding to 198 animated images with sounds
Sincerely yours

You could also try the HAP player, it is spreadable and is quite effective.

Thank you sunep its not only audio, its more the DOPE wich is consuming a lot. Here is a preview:

So is there any way to reventilate all process on all the cores than instancing ? Thank you

1 Like

HAP is video, kind of like dds files wrapped in a video format.
As far as I remember, it is multithreaded and very effective.

Merci sunep but this is not suited for this project, everything is animated live, no stream. Just dope mesh and dds textures… all animation is done with sensors and inputmorph tricks

btw: good morning !

@bjoern using AsSharedTexture(DX11.Texture2D) would work ?
and shoudl i use shellexecute to launch a second instance ?

@karistouf yes, a good practice is to have one more instance responsible for all the other instances (players). From there you will have the ability to fire them up, kill and inspect them if you need and you will be mostly on the safe side where if some of the players’ instances are crashed to independently start them again.

AsSharedTexture must work out of the box.

Thank you nissidis

sorry, but not used to it.

so i need:

  • to copy vvvv folder somewhere else
  • launch it from vvvv main wth shell node
  • have inside each vvvv a set process affinity dispatching it to processors
  • use AsSharedTexture to receive textures from others instances

or should i use a bat file ? what is best approach ? ( very heavy my patches)

no, not a copy you may inherit multiple instances from the same installation folder. Start the first patch from the commandline (a bat file will be handy for sure) with the appropriate argument /allowmultiple and do the same for each shell executor from the “main” (let’s call it as such for now) patch for the rest (players’ patches).

many many thank you nissidis ! ok i will work around it in next days.
So main patch is with a set affinity, and “players” patchs launched by others instances have there own set affinity node ? (just to be sure)

No that doesn’t work. You’ll have to use either network like UDP / OSC or shared memory.


You can either do this or have a batch file open all instances.
If your folder structure looks somewhat like this:

Your start.bat would be something like:

timeout 15

@echo off

%~dp0\vvvv\vvvv_beta_42_x64\vvvv.exe /allowmultiple /o %~dp0Patches\_Main.v4p

timeout 5

%~dp0\vvvv\vvvv_beta_42_x64\vvvv.exe /allowmultiple /o %~dp0Patches\Player_1.v4p

timeout 5

%~dp0\vvvv\vvvv_beta_42_x64\vvvv.exe /allowmultiple /o %~dp0Patches\Player_2.v4p

timeout 5

%~dp0\vvvv\vvvv_beta_42_x64\vvvv.exe /allowmultiple /o %~dp0Patches\Player_3.v4p

timeout 5

%~dp0\vvvv\vvvv_beta_42_x64\vvvv.exe /allowmultiple /o %~dp0Patches\Player_4.v4p


I think modern process scheduling is quite sophisticated and messing with it might rather make performance worse.

1 Like

how many triangles does your average DOPE mesh have, and how many do you use within one scene?
how full is your vram?

Bonjour and thank you for all your answers…

@bjoern about S and R. Shared memory with values is possible ? (its very important for me if i want to adapt the global patch) If yes, is it possible to have an example ?

@schlonzo no scene is as the others. It may be 2 or 3 DOPE meshes per image, up to 18 or 20 dope meshes per image. Sometimes a chapter will show on screen 12 images containing the meshes.
Not possible to create a goblal DOPE player. Project is too complicate for this ( parts up dow etc…).

Just check the help patch of Reader (SharedMemory Raw).

thank you @bjoern !
i see i have a hudge work to do with all of this :)

So having S and R same name of global variable per instance of vvvv will NOT interfere ?

Hello, i m in the wore of the adaptation of my hudge project, and from scratch it works, but with my project and all its S and R nodes, well its heavy and complicate. I m encoutering troubles to adapt and i I would like to know certains things:

about setaffinityprocess:

  • can i put a VVVV working on 2 core ? If yes, how to do it.

  • i have 8 core, example go up to 4. How to reaches others cores

  • is the shared memory things with values is blocking vvvv when it doenst find those value in shared memory (adapting patches one after one)

thank you !

No, not with plain beta. I guess you could try to rwrite DOPE to make use of multithreading, if it doesn’t already (haven’t checked). Or migrate your project to gamma.

Windows should automatically put the different vvvv processes on different cores.

It won’t block. You can just try this yourself (with the helppatch for example) and see what happens.

Thank you Bjoern. its impossible to migrate to gamma. its a real hudge project.

I have a doubt about the checking box of setaffinity process and its adresses. If i check just one box, its going to the desired processor, right ? a question more about the possibility to ventilate to others cores painfull things.

Actually, all in one VVVV i m at 63% of memory (38 458Mo ).

Im now running second instant from shellExecute from my main. The second instance is launched with a patch with setprocess affinity to other processor. But it seems to block. Could that be related to shellexecute and “from processor” behaviour ?

i will have 3 textures, of 4800x2700 coming from 3 instances of VVV

Many thanks for your replies !