Blog-posts are sorted by the tags you see below. You can filter the listing by checking/unchecking individual tags. Doubleclick or Shift-click a tag to see only its entries. For more informations see: About the Blog.
dear commercial users of vvvv,
it has been brought to our attention that you're looking for a way to protect your precious patches from some untrustworthy bunch.
as announced during the keynode at node13 such a system is now in place and ready for testing. interested parties who are owners of an active (not older than a year) vvvv license please send an email with their postal address to email@example.com to apply for a test-dongle. you'll then receive further instructions.
pricing and public availability still to be announced.
vvvv contained two RS232 nodes, both with different pros and cons:
we therefore decided to make the previous two nodes legacy (not breaking existing patches) and rewrite the RS232 node as a plugin with all the features of the two previous nodes combined:
the mouse and keyboard nodes of vvvv have seen a complete rewrite in the lastest alpha version (29.4). their interface (in- and outputs) and behaviour is still the same, but under the hood they work differently:
up till now vvvv installed a so called system wide global hook on startup which rerouted mouse and keyboard messages from other processes to the vvvv process.
for reasons beyond the scope of this blog post, this caused random freezes of vvvv or even crashes of other processes. another issue was that it only worked with one vvvv instance at a time.
with the new nodes we got rid of those global hooks. in case of the window versions of the nodes we use a much safer technique called subclassing and in case of the global versions the keyboard and mouse states are retrieved at node evaluation.
hopefully this change shouldn't affect the user at all, if it does, please report in our alpha forum.
what's probably also worth mentioning is that the mouse nodes now output the state of XButton1 and XButton2.
to plugin developers:
Made a little cleanup of the midi output modules.
MidiCtlOut (Devices) -> MidiControllerOut (Devices)
MidiPgmOut (Devices) -> MidiProgramOut (Devices)
There were two midi note out modules, i renamed one to MidiNoteOut(Devices Bang), check the help patch to see the difference between the two.
And the two MidiControllerOut modules are merged, it has a bool to enable the send on change behavior.
All modules use midi channels 0-15 now.
This might break some midi patches of you. very sorry, but its clean now.
If you encounter any problems, please check the midi channel and whether you have the correct module loaded.
As you know, the devvvvs never sleep and constantly come up with implementations of random stuff, which you have to catch up with.
We have been accepted as one of the first who get a free development version of the Leap Motion device. The device is not yet available, but if your lucky and also got one, you can use it with vvvv right away.
Leap will ship another 10k dev devices in the next week, you might be lucky. apply here:http://developer.leapmotion.com
Otherwise this is just a public announcement that the Leap SDK found its way into our code base.
after quite some months in development and testing we are happy to announce the availability (in alpha builds) of Player (EX9.Texture). It was developed in collaboration with and initiated and sponsored by eno | nsynk.
The idea was to have a professional/highperformance alternative of playing back videos based on stacks of images instead of video files. The node is quite versatile/spreadable and does the heavy datahandling a background thread. Check its helppatch for instructions.
vvvv has finally arrived in the age of 64bit computing. to you this means you can finally use all of your PCs memory. to us it means we have to maintain two builds now. but nevermind. service is our success.
so basically "out of memory" messages should be out of our memories (cheese us!) soon and content/texture heavy vvvv-applications ahoi. in theory due to the compilers use of SSE2 instructions things should be generally faster as well..but we already noticed this doesn't seem the case just yet. generally.
now available from: alpha builds
and of course every beauty has its beast. so here is a list of a couple of things that are not yet (probably never will be) working in the 64bit builds:
most of the addons already work with the 64bit build. below is a listing of those which still need some treatment. chances are good that we'll get most of them to run..given some time.
when you want to debug 64bit stuff use:
in the bash to get the according executables and in the Addonpack.sln set the Configuration to x64.
here is to introduce a new primitive (node-)datatype. so next to value, string, ... transform there is now: raw
nothing to get too excited about as long as you're not dealing with device-communication and raw-byte handling.
if that is what you do though, this is your lucky day. instead of misusing strings as bytearrays (which you had to do in vvvv until now - and you can still do) there is now a native raw (byte) datatype. so think no more Ord (String) and SpellValue (String) but instead:
make sure to check the helppatches of those to get all their details.
further the following nodes now have raw inputs:
still the old versions of those nodes with string inputs are available as modules and versioned "string".
so this is to distinguish more clearly between string and byte-handling and should also have a positive influence on performance in situations where string/byte conversions can now be omitted.
please give it a run and let us know what you think.
as always get the latest from here: alpha builds
this is to announce that vvvv alpha-builds now include the afformentioned unicode changes.
summarized to you this means:
and if you find a specific unicode-related bugger -> alpha forum.
@devvvvelopers: this would be a good time to pull upstream
oui this maybe a small step for yousers but it is definitely a big step for vvvvs codebase. advancing it by about 10 years letting it finally arrive in ~2007 (yep, still some more to catch up..). so what happened? vvvv is now fully unicorn..ah unicode. from highest to lowest bit.
for most of you this will not change anything except that you don't have to deal with UTF8 vs. ANSI in IOBoxes or on specific nodes (e.g. Text (EX9)) anymore. as from now on there is only unicorn..code. that is: inside of vvvv.
when getting strings into vvvv you may have to specify an encoding. for those special cases the Reader/Writer nodes got a (visible in inspektor only) Encoding. its default should work in 99% of all cases for you. for the Reader (File) the default setting of Auto will work if the file is encoded in the current system codepage or UTF8, else you'll have to chose the specific codepage manually. for the Writer (File) the Auto setting means it will write files as UTF8.
doing those changes under the hood caused quite a stir in the codebase and while our tests show all green we're still a bit cautious with merging those changes in our main alpha-branch. therefore we're asking you to give this a ride with your patches using the latest unicorn-build from:
don't forget the suitable addonpack and run your patches with it. what would be interesting to hear tested, are:
now please give us a quick feedback in the comments if that fukcs everything up for you or you'd say it basically works. if you find a specific bugger -> alpha forum.
anonymous user login