» Blog
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Blog

new post

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.

  reset tags

addon-release core-release date devvvv gallery news screenshot stuff
delicious flickr vimeo
Order by post date popularity

helos,

this is to announce that vvvv alpha-builds now include the afformentioned unicode changes.

summarized to you this means:

  • no more dealing with UTF8 vs. ANSI on various string-related nodes
  • Reader/Writer (String) now default to UTF8 (which can of course still be changed to other encodings. also note that when loading old patches the old default is being preserved!)
  • no more strange characters in patches for asian users
  • in a totally unrelated coincidence it fixes https for HTTP (Network Get)

but:

  • saving a patch with unicorn-characters in a unicorn-alpha will not let you open the same patch in older vvvv releases. if you still need to do so there is a way... bug us in the alpha-forum for more information.
  • MySQL nodes had to be removed (for now)
information given in the vvvv-unicorn-upgrade blog-post is no longer accurate.

enjoy.
and if you find a specific unicode-related bugger -> alpha forum.

@devvvvelopers: this would be a good time to pull upstream

joreg, Thursday, Nov 8th 2012 Digg | Tweet | Delicious 3 comments  

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.

good to know

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.

the deal

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:

 unicorn-builds

don't forget the suitable addonpack and run your patches with it. what would be interesting to hear tested, are:

  • boygrouping
  • networking (osc,..)
  • arduinoing (rs232,..)
  • file reading/writing
  • general string-heavy patches

nota bene:

  • saving a patch with unicorn-characters in alphaXE2 will not let you open the same patch in older vvvv releases. if you still need to do so there is a way... bug us in the alpha-forum for more information.
  • MySQL nodes had to be removed (for now)

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.

joreg, Tuesday, Sep 25th 2012 Digg | Tweet | Delicious 15 comments  

thanks to MESO for sponsoring and CEF and Chromium for doing the hard work, it's finally possible to render web content (HTML, Flash, WebGL, etc.) directly into a texture using one of the two new nodes:

HTMLTexture (EX9.Texture String)
HTMLTexture (EX9.Texture URL)

as there's no window involved at all in the rendering process this is also known as offscreen rendering. and, probably the best feature, the generated texture contains an alpha channel. so for example setting no background color on the <body> element of your HTML content will result in a completely transparent texture.

the new possibilities are of course endless:

  • build your own fancy 3d webbrowser
  • integrate web services directly into your application
  • generate content by using all the expressional power of HTML and JavaScript
  • or in combination with the new XML nodes patch a WYSIWYG editor or whatever nonsense you can come up with :)

the nodes are fully spreadable, so for example feed it with a spread of urls you last visited, add some scale/translate magic and voila, you patched the welcome screen like we know it from firefox or chrome.

with the key and mouse inputs you can redirect user input wherever it needs to go, so you could display several websites at once, but redirect user input to only one of them.

for more advanced usage scenarios use the JavaScript input pin in combination with the Execute pin. they allow you to run custom JavaScript code on the displayed web site.

if you want to test these new nodes download the latest alpha build of vvvv including the addonpack.

Flash demo

WebGL demo

support for WebGL is highly experimental and whether it works or not highly depends on system configuration and the actual WebGL example.
Elias, Thursday, Aug 30th 2012 Digg | Tweet | Delicious 16 comments  

Motivation & Concept

We added nodes that ease the creation and analyzation of xml documents.

Documents are represented by Elements and Attributes - not strings, which helps performance...
You now can easily get some parts of your document and route those as a spread of Elements to other parts of your patch, where they get further analyzed.
You always can convert an element to a simple string via AsString (Object) - or back to an element via AsElement (XML). But typically you only want to do that once: when reading from disk or writing to disk. For the rest working with Elements and Attributes is much more comfortable.

Joining & Splitting

There are nodes with which you can easily join & split XML-Elements (aka Tags) and Attributes: Element (XML Join), Element (XML Split), Attribute (XML Join), Attribute (XML Split).

Note that by concatinating several Element (XML Split) nodes - which also outputs an elements' child elements - will give you the possibility to dig into the xml structure. E.g. you could retrieve all child elements of an element, check its properties and dependant of some test select some of the childs via Select (Node). You therefore could patch a query into your xml structure...
However this can get complicated and so we added some more nodes:

Handy nodes for analyzing XML

With GetElements & GetAttributes we added different ways of searching for child tags and attributes.
When searching by name you get those that have a certain tag or attribute name and are direct child elements or attributes of the specified element.
do that with GetElements (XML ByName) & GetAttributes (XML ByName)

When searching by XPath you can express a more complex query that allows you dig deeper...
do it with GetElements (XML ByXPath) & GetAttributes (XML ByXPath)

While those nodes are flexible and spreadable in means of what you are searching for, they might be a bit unhandy when you already know that at a certain point in your patch only a certain tag with certain attributes are of interest.

For those cases we added Prune (XML) which lets you set those tag and attribute names statically in configuration pins with the bonus that you get friendly pin names and dont need to further process your attribute data.

For being really sure that your patch system can work with a certain xml-File or string you can check validity with IsValid (XML RelaxNG). link: RelaxNG
Both XML Syntax (.rng-Files) & Compact Syntax (.rnc-Files) are supported.

Sponsoring

Thanks to our MESO for putting those node on our agenda and for sponsoring.

gregsn, Tuesday, Aug 28th 2012 Digg | Tweet | Delicious 3 comments  

For analysing small textures there is a new node that let's you do that in a patch:
Texture (EX9.Texture Split) gives you all RGBA-Values for each texel of the texture.
Even for small textures this results in quite big spreads. So typically this is useful when you can identify the interesting texels with just a few nodes. E.g. you could check if the alpha value is > (Value) 0. You then can Select (Value) those texels and operate on just those few texels.

texture-split-demo

gregsn, Monday, Aug 13th 2012 Digg | Tweet | Delicious 0 comments  

the beta28 release will contain two new spread operations available for all major data types: zip and unzip. their operation is best explained by two screenshots of their help patches:

Zip
Unzip

read more...
Elias, Tuesday, Aug 7th 2012 Digg | Tweet | Delicious 10 comments  

there're situations were one needs to create pins at runtime depending on the value of some config pin. for example consider the Expr (Value) node. it creates input pins for each given variable name.

with beta28 coming up this kind of task got considerably easier to do with a new interface called IIOFactory.
it basically provides a method to create so called IO containers, containing the actual "view" on the pin data (such as ISpread) and controlling the lifetime of it.

say we want to create an ISpread<ISpread<T>> during runtime, we do something like this:

[Import] 
IIOFactory FIOFactory;
...
var inputAttribute = new InputAttribute("Input Foo");
var inputFooContainer = FIOFactory.CreateIOContainer<ISpread<ISpread<T>>>(inputAttribute);
var inputFooSpread = inputFooContainer.IOObject;
...

in case we decide to get rid of those two pins which are used by inputFooSpread we simply call Dispose on the associated IO container:

...
inputFooContainer.Dispose();
...

for details and as a starting point have a look at the new dynamic plugin template contained in beta28, which creates inputs and outputs on the fly, when changing the associated config pins.

Elias, Tuesday, Aug 7th 2012 Digg | Tweet | Delicious 0 comments  

the easiest way to write a plugin with a texture output was by extending the DXTextureOutPluginBase class and overriding the CreateTexture and UpdateTexture methods. this approach lead to several issues though:

  1. the plugin was limited to one texture output. if there was the necessity to have more than one texture output one had to go the long route by implementing IPluginDXTexture2 and doing the resource management manually.
  2. it wasn't possible to reinitialize the textures on a slicewise basis. for example if the size of one texture changed all textures had to be recreated.
  3. dealing with a pin of type texture was completely different than all the other data types. wouldn't it be nice to simply write ISpread<Texture> and be done with it?

well it's nearly as simple as that now. you can create a texture output by writing

[Output("Texture")]
ISpread<TextureResource> FMyTextureOut;

the TextureResource class takes care of the resource management, for example if a renderer is moved to another screen, the directx9 device changes and therefor the texture on the old device needs to be disposed and recreated on the new one.

the resource management is the reason why we can't simply write ISpread<Texture> as there might be multiple textures for one single slice. for example if the texture output is connected to two renderer each using its own directx9 device, two textures have to be created for each slice.

the constructor of the TextureResource class takes up to four arguments:

  1. some arbitrary user data which will be supplied as the first argument to the following functions
  2. a function which creates the texture, taking as first argument the user data, as second the device for which a texture was requested and returning the newly created texture.
  3. a function which updates the texture (optional), taking as first argument the user data and as second argument the texture to be updated.
  4. a function which destroys the texture (optional), taking as first argument the user data and as second argument the texture to be destroyed.

so in order to create a texture we need to do this:

FMyTextureOut[i] = TextureResource.Create(i, CreateTexture);
...
Texture CreateTexture(int slice, Device device) {
  return new Texture(device, ...);
}
the static TextureResource.Create method does nothing more than calling new TextureResource<TMetadata>(...), so you might ask yourself why not calling new directly? well the reason is that using the static factory method we can make use of c#'s type inference. so instead of writing new TextureResource<SomeComplexMetadataType<ContainingInnerTypeArguments>>(...), we let the type inference algorithm figure out the SomeComplex...BlaFoo thing.

if we want to update the texture when some input changes:

FMyTextureOut[i] = TextureResource.Create(i, CreateTexture, UpdateTexture);
...
void UpdateTexture(int slice, Texture texture) {
  // Do something with the texture
}

and if something special needs to be done when destroying the texture:

FMyTextureOut[i] = TextureResource.Create(i, CreateTexture, UpdateTexture, DestroyTexture);
...
void DestroyTexture(int slice, Texture texture) {
  // Destroy the texture
}

in many cases the UpdateTexture call can be quite expensive, in order to disable it set the NeedsUpdate property on the TextureResource to false and set it back to true under a certain condition.

for a full example have a look at the rewritten dynamic plugin template.

oh and all this stuff works for meshes too, simply replace TextureResource with MeshResource.

Elias, Thursday, Jul 26th 2012 Digg | Tweet | Delicious 1 comments  

ever wanted to write a sample and hold node as a plugin? well you couldn't, until now :)

read more...
Elias, Wednesday, Jul 25th 2012 Digg | Tweet | Delicious 5 comments  

hola,

here is the thing: until now, when creating modules or plugins that take mouse input you'd always have to cons XY and the mousebuttons together somehow so that you'd not need 5 connections to the node. also with the keyboard it was quite messy to parse the actual keystate only given a keycode. no more. we're introducing a special datatype for those now, and we call them "MouseState" and "KeyboardState".

so now, when creating a module that takes mouse or keyboard input use:

to use the data conveniently inside the module.

plugin writers simply use:

ISpread<MouseState> FMouseState;
ISpread<KeyboardState> FKeyboardState;

to create pins of the respective types.

and as a user you'd notice how the following have turned into modules that return an additional handy Mouse or Keyboard:

internally those modules use:

which of course you can use to simulate mouse/keyboards from any arbitrary input. and note that of course those are spreadable.

nodes that already take that input now include:

so for the developer this provides a standard interface for mouse/keyboard input and for the user it will save some clicks. win/win.

joreg, Wednesday, Jul 25th 2012 Digg | Tweet | Delicious 8 comments  

anonymous user login

Shoutbox

~15h ago

joreg: But first: This Friday in Berlin: Join our full day "Getting started with Generative Design Algorithms" workshop https://nodeforum.org/announcements/workshop-getting-started-with-generative-design/

~19h ago

joreg: In #Linz for #ArsElectronica? Join us for a free 2 days #vvvv workshop sponsored by businesses/responsive-spaces-gmbh Apply here: 2-day-gamma-vvvvorkshop-at-responsive-spaces-in-linz

~2d ago

joreg: Need your custom dose of #vvvv training? Join us at our studio in #berlin: vvvv-training-at-the-source

~8d ago

~13d ago

~13d ago

domj: Dev stream: Painting with light with a Vive controller, developing using VL and Schéma. Start at 17:00 https://www.twitch.tv/dominikjancik

~14d ago

joreg: July as it happened: vvvvhat-happened-in-july-2019 #vvvv

~15d ago

levi: @mrboni thanks mrboner. solved it by turning all the lights to strobe mode so framerate drops were actually a relief :P . love

~16d ago

joreg: reminder: this thursday, just before the patching circle, there is a free 2h intro to #vvvv gamma: free-vvvv-intro-workshops-this-summer-in-berlin