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.
seems you haven’t found the
alt+rightclick = reset
shortcut yet. like this you can reset individual pins to their default values or when applied to a node reset all of a nodes pins. also mentioned here: the user interface in detail#changing values in the patch
have you got the dont-panic-the-noobs-guide-to-vvvv already? thats a cheatsheet with all such useful shortcuts.
of course it is frustrating that they didn’t yet manage to visually decorate pins that are not set to their default. jeeez devvvvs, what are you doing all day?!
and about pins keeping their data after being disconnected:
thats even more unintuitive once you understand that with all primitive datatypes (value, string, color, enum) the behavior is as you noticed, but with all others (mesh, texture, transform, …) it is as you expected.
we kind of learned to like it that way…for now at least…
Well, initially I found difficult to manage this behaviour of pins, but I guess was just a state of mind… I mean just a way of thinking.
Anyways, as long as I started to patch something more complicated, it helped me a lot to keep patch clean, avoiding spreading nodes all over the patch.
More, if I can suggest something, probably you won’t need an XY res of 30 for such a large number of objects: I guess you could reduce res proportionally to the quantity of objects, for example.
In the attached file I’ve put a spread of 1024 spheres, XY res = 30 and it runs at least at 30fps on an athlon 64X2 Duo, geforce9600 gt: rather poor, I know. But goin’ smoothly (yes, the result is ugly as death, but helpful, I hope).
Ciao.
PS: When you work with 3d objs enable ZBuffer to enjoy “depth”.
EDIT: I forgot to set GetSlice (Spread) BinSize to 3.
WobblyColorDisc2_mod.v4p (12.2 kB)
+1 oh yes, some feedback on pins which are not set to default anymore would be cool…it would make teaching vvvv a lot easier since this is the most common error my students make. like “i dont see my quad anymore, vvvv is broken”