Out of memory warning + crash

I am working on a very large patch with many subpatches and keep getting out of memory warnings:

Exception EOutOfMemory in module vvvv.exe at 0000770B. Out of memory.

It usually happens when I want to insert a subpatch inside an existing subpatch that is used more than once. Let me clearify:

I am working on a patch that renders midi notes in 3D. For each midi note there is an identical subpatch (same file), so there is 127 of them. Now if I insert a patch in this subpatch it is opened once for each subpatch it exists in (ie. 127 times), usually this is when vvvv crashes. It seems that its more the number of patches that are opening rather then the size of them.

I am using 29.2 x86 version. x64 version is a no-go as the patch simply doesn’t even open in x64 - just crashes straight away.

Hardware should also not be an issue… 16Gb Ram in a rMBP, running Win 7 Ultimate 64 bit.

Anyone know possible solutions?

well, vvvv might simply be out of memory and you should use the x64 version. so the question is why that would not work at all.

are you using any of the stuff mentioned in missing-in-64bit-builds?
can you try loading smaller portions of your patch one after the other to debug where it is crashing?

it sounds like you are doing something in a not very optimal way, in vvvv you should never use 127 of the same sub patch, you should use spreads: tutorial spreads and tutorial spreadsii for starters

perhaps post your patch, that makes it easier to give constructive feedback to you

Thank you for both your replies.

@joreg:

Yeah I’d really love to use the 64 bit version and i will just have to spend some time to recreate it bit by bit in the x64 version. But yeah, the patch is really big with lots of S and R nodes and a lot of subpatches. Ill just bite the sour apple and do it, but yeah it’s a shame it doesn’t just work straight away. I am not using any of the modules that are missing that I am aware of and when i open some of the subpatches then I get red nodes sometimes in nodes that DO exist - especially Store(Value) seems to be a problem, but which is kind of at the heart of the whole patch (storing midi values to build 3D objects out of them).

@sunep:

Yes I am sure there is a lot of room for improvement, but it seems fine at the moment, its just that I have now hit the memory limit of the x86 version it seems.

I am still fairly new to vvvv (around 1.5 years), but do have a pretty good understanding of spreads. Let me briefly explain what happens in those 127 identical patches.

For each midi note it uses 5 Store nodes to store the values for Time, Velocity, Length, Pitch and Mod in a spread. So the spread fills up with the notes being played of the same midi value. Then in the same patch a “transformer” supbatch takes those spreads and maps them to properties of a simple object, for example a cube. This spread is then fed into a GouraudDirectional node and the render output fed to the parent patch where all 127 are grouped and finally go into a Render node.

So unfortunately this is where the simple (one-dimensional) nature of spreads or my understanding of spreads hits its limit. But i will ponder on a solution, that was after all pretty much the first part of the patch that i built…

As for posting the patch… I am not sure it will be of that much help. It really is rather large and not that easy to understand i guess and needs a certain midi-controller and some drivers to actually see the render output. But if you want i can try to zip it all together and see what you think… Where is a vvvv-geniusbar when you need it :D

You can have a look here to see what it does:

I am still amazed how well vvvv works in realtime, even with the 127 subpatches like they are in the video.

basically there shouldn’t be a reason for your patches not to run on the x64 version. the problem is quite likely related to a single node causing troubles. and i see you mentioned the store node before as a troublemaker: https://discourse.vvvv.org/t/9950

and woei offered to debug it but you didn’t provide a crash-demo for him. so i’d concentrate on finding such a demo-case first…

Yeah I would have thought the same. Just tried it again with the latest 30.2 x64 and this is what i got:

Problem signature:
Problem Event Name: APPCRASH
Application Name: vvvv.exe
Application Version: 4.5.30.0
Application Timestamp: 519d3392
Fault Module Name: clr.dll
Fault Module Version: 4.0.30319.1
Fault Module Timestamp: 4ba21eeb
Exception Code: c0000005
Exception Offset: 00000000002109f4
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 5e2d
Additional Information 2: 5e2db6551cdb41e8e263437be962106f
Additional Information 3: 45bd
Additional Information 4: 45bd77ad7120e40c0b53569f23206b2a

Whenever i try anything with the store node in a fresh patch, it works just fine. :/

Like i said i will try to 1) copy things over slowly to x64 and see where it crashes. 2) go back to the drawing board and see how to turn 127 patches into 1…

I think the main problem why i need the 127 patches is that several notes can be played at the same time, so i would need to Set and Insert several values at once. Can that be done? ie. Does Index except a spread as well?

It would still be very tricky. For example say Note 1 is pressed and played for 10 seconds, but in those 10 seconds Note 2 is played 3 times. I would have to constantly set slice 1, but insert and set 3 more slices.

you can do that, index does support spreading

Well thats good news, just trying to understand Buffer as well and doing the whole store thing from scratch so it doesn’t need 127 subpatches. Getting somewhere, but the only thing that is giving me headaches is the fact that to get the length of a note being played i need to have a TogEdge + Stopwatch. How do i do that for any number of notes at once? Using the 127 subpatches its not a problem…

except for clear and flush all pins on store are spreadable. so you can set one slice and insert another and remove another. you just can’t do 2 operations in the same frame on the same slice (wouldn’t make much sense anyways).
furthermore you have a bin size pin, so you could store the 5 parameters in one index without using 5 store nodes. just use zip and unzip your parameters.

the tricky part is probably the stopwatch thing, in case you also remove slices.

Thanks woei, that is good to know. That should make it possible. I’m still trying to get my head around bin sizes and zip and unzip. All sounds pretty good though!

In a eureka moment I figured I don’t necessarily need a stopwatch, as I can just reference a global frame counter and rather than measure length just store start and end frame for each note, making it rather easy to calculate the length from that.

You mention clear and flush - can you tell me what the difference is between the 2?

At the moment the difficult thing for me is how I can extract in each frame only those slices of a spread that have changed since the last frame. I have already made a patch where I use sort and its rather great “previous Index pin” to get a spread of the notes and their velocity being played at any one moment. Now i just need to find a way to store each note that is new since the last frame, constantly set it as long is its playing then store the frame the note ended - and do that for all notes being played so I end up with a spread (or several) that start filling up with all the notes that were played.

In case you are interested or care to have a look, ill attach what I am working on right now. Unfortunately to get midi notes from a midi file, you have to do the weird midi re-routing. I use the free LoopBe1 driver and set the midi output and midi input in the patch both to LoopBe1. I have added a S+H node to see whats going on when i stop playback. There is 2 midi test files, one very simple and Fairies Aire - a sort of midi benchmark test file for me, as it has a few thousand notes in the first 60 seconds and as many as 20 at the same time.

spread midi store.zip (47.0 kB)

Thank you @woei)) and ((user:sunep for your inputs. I have managed to recreate the 127 patch monster into 1 patch that runs in the 64 bit version of vvvv. :)

It was a lot of work to get my head around what had to happen, but it worked out in the end and once again was assured that with any kind of coding breaking down the problem into its lowest parts is the key to success. The hardest part was to understand how store works with spreads in index, insert and set, and to realize that you can spread (almost) everything in vvvv, not just the obvious pins.

The single most important node was Sort and realizing that you can sort multiple spreads using one of them as the “sort column” by using the Former Index pin.

There is still a little issue when playing multiple notes at the same time, almost like the Set pin in Store lags behind a frame sometimes and then sets the wrong slice. But it only happens when there is more then 2 notes playing at the same time. Hopefully i can find the error…