MonoBuf and MonoData v1.4
| Author: | mediadog |
| Date: | 05 Mar, 2011 |
| Category: | module |
| Credits: | Based on work by West, wirmachenbunt and tonfilm |
Download
64bit
Description
Update v1.4 (1.3 was buggy): Added ability to modify individual slices in MonoData.
Update v1.2: Fixed lifetime working correctly with spreads/changing values. Added "Pause" and "Clear" input pins, and "Inverse" output pin (goes from 0 to 1 through lifetime). Also should always be guaranteed of getting a zero lifetime and value (and inverse of one) for one frame at the end of the life (for triggering things like MIDI note-off) before that slice is removed from the spread.
Update v1.1: Now correctly handles spreads on the input pins. Also added a "Mod" input pin to MonoData to optionally modify the stored data each frame - example in the help file.
I needed the ability to dynamically create a spread of objects with a specifiable lifetime, and couldn't find exactly what I was looking for. In my case I am creating visual objects from music data received via OSC, but this should work for particle systems and more as you can add as many arbitrary data spreads as you want.
Just add a MonoBuf node, give it the desired lifetime (in seconds), and bang the create pin. A new slice will be added, and when that slice's lifetime has expired, it will be automatically removed. MonoBuf provides as output spreads of the remaining time-to-life in seconds and a normalized lifetime (1 to 0) of each slice.
You can connect the "master" MonoBuf node to any number of MonoData nodes, and whatever data you want will be associated slice-wise in their output spread.
Helpfile included; please post any questions/comments/good jokes.
Comments
Comments are no longer accepted.Please create a new topic in the vvvv beta forum to discuss this contribution.
I´m using it ;)
that's coll. thanks.
simple but really effective concept ;)
Thanks for the comments! They reminded me I hadn't posted the updated versions.
However, I just found a bug with the "Life Time" pin if you change the value while things are still "alive", or spread it with dissimilar values; I've just been using it with a constant lifetime and didn't catch it until now. Will fix and update ASAP.
OK, should be much more versatile now, works as expected with my (admittedly non-exhaustive) test cases.
Thanks, mediadog