Ive been tinkering with audio analysis and a geometry and even on a low geometrical resolution v is crashing constantly. Its not even using all of its single thread power either. Has anyone used jitter comment on their comparative stability?
yeah, weirdest thing, it was working fine then it suddenly choked, so i saved and closed and reopened, same thing, lowered resolution, deleted spreads, nothing, getting about 2fps now and its chewing up the processor. So if v suddenly chokes it looks like the project is done for too.
Yep, i deleted most of the patch leaving only a simple lighting animation and the geometry and its just broke.
Ah, ok, so i deleted everything but the geometry, and v is chugging, eating processor, and doing nothing. I saved it and closed out and opened it back up and its still chugging. If i open a new patch it works fine though.
Posting the patch would be the only way to see…
jitter is far more stable :)
depends of programmation.
I had only once had a vicious bug comming from a node. Jitter is fat when using vvvv is light.
Be aware that when doing a hudge live patching, restart is a good option to avoid bugs and bad links in memory and verify
he karistouf, my post was ment to be ironic. i find it quite funny asking “is jitter more stable” in the vvvv forum. why not ask “is vvvv the better software” in the cycling74 forum ? pretty vague question, isn’t it.
Once upon a time, in a not so far away land, there was a realm, whose king was kind and generous, dispensing knowledge throughout his reign, and even sending ambassadors to other reigns to share ‘n’ grow in wealth and ease: this way, despite troubles happen everyday, people felt happy and satisfied.
But nothing can stand forever!
Sadly, one day, still nobody knows from where, trolls appeared in his realm!
People got rash where sun don’t ever shine, and the ambassadors were no longer able to travel from reign to reign.
One day, in a dusty and dark library, one man found the way to solve the problem, as the the old book said…
if cometh troll
just you yell lol
if troll cometh
…
Unfortunately the book was unreadable from that point on. But that was enough to fix some bugs.
Do you think I’ll win first prize at Literature Stand of the “Fresh/Grilled/Dried Wild Pork Sausage Festival - Bring Da Bread Edition” in August, or John MacPomme will win again?
Thank you.
@u7: helas in my own tongue i dont have any humour, i presume in other languages its worst !!! ;-)
abou stable or not stable, we all are using specific versions of vvvv that are better ( 17 / 23 and 26)
@h99: ^quote:username:
But that was enough to fix some bugs.
^ ah ah ah !!!
i came across to vvvv from jitter because i found it less capable than vvvv and much slower.
and personally found it less stable, but things have changed a lot since then (2007).
if jitter’s more stable and better performance for what you’re doing, then chances are you think the way the jitter devs think, and then that’s a better platform for you. enjoy your tools! :)
@poof: as @h99 already pointed out: if you’re interested in getting help with your specific problem of a slow patch you’ll just have to post it so we can have a look at it and probably give you some hints on how to improve performance.
Here’s the project file. As you can see i cut it down to nothing, but v still chugs whenever i open it. I hope theres a way to recover a project when this happens, otherwise v is a house of cards.
WobblyColorDisc2.v4p (3.0 kB)
After beta27, VVVV is crushed only once during this all active patching week. Maybe this is just because i’m switched from ATI to NVIDIA, but i think not.
Did you notice that you had a spread of 256 going into the ‘Radius’ pin of the sphere node? All with value 1. So instead of rendering 1 sphere, and creating 1 mesh, you were rendering 256 meshes.
If I keep only 1 slice, framerate goes back to normal…
press shift-f9.
it usually makes it pretty clear what’s causing the performance problems (or at least what general area to look in)
Oh, that was it, there was a huge spread going into that node. But why does it not return to default value after i delete the spread going into it? Instead it leaves a variable locked into the node that i cant change until i go back, replace the spreadnode, and reset it. Thats very unintuitive and difficult to manage.
Thats one thing that i find to be very frustrating about this program, if you want to add something to your patch and mess around you cant just delete it when you’re done because the values are still stored in the node it was going into, and the only way to reset the node is to either delete it and replace it, destroying everything else thats set, or look carefully at the node and figure out what its default value might have been and then figure out how to reset it. This is what i mean when i say the developers should be making a more intuitive program, small things like this are the difference between a crashing laggy patch and the freedom to explore without problems.
you can reset your nodes by alt+right_clicking them
if you care about certain input pins, just give them ioboxes etc
That might work for a single node to node connection, but if i have a node thats connected to a dozen other nodes and i change something on that node that causes problems then i have to go around to a dozen other nodes and reset them. Whats the issue with just having the value reset to default when the pin becomes disconnected? Its automatic, no replacing, no resetting.