new datatype: RAW

November 8, 2012 posted by: joreg

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)node and SpellValue (String)node but instead:

  • AsRaw(Value)node
  • AsRaw(String)node
  • AsValue(Raw)node
  • AsString(Raw)node make sure to check the helppatches of those to get all their details.

further the following nodes now have raw inputs:

  • UDP (Network Server)node
  • UDP (Network Client)node
  • TCP (Network Server)node
  • TCP (Network Client)node
  • RS232 (Devices)node
  • Reader (Raw)node
  • Writer (Raw)node

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


Comments are no longer accepted for this post.

08.11.2012 - 17:58


08.11.2012 - 20:26
YES!! long live the byte! appriciating it very much indeed.
05.11.2013 - 12:00
can we have the spectral nodes working with raw, too?
05.11.2013 - 16:39

@oschatz: next release introduces Skip (Raw) and Take (Raw) nodes. the former skips n bytes and returns the rest, the latter takes and returns n bytes. there’ll also be a module called GetBytes (Raw) similiar to GetSpread (Spreads) using both of them.

@sebl: what spectral nodes? i can only think of + (Raw Spectral), similiar to + (String Spectral) … all the others are specific to values, not byte streams.

05.11.2013 - 20:44

@Elias: yes, i had a need for + (Raw Spectral). i thought there were more, but didn’t have specific ones in mind…

aaand another thing: i think it’s often hard to ‘see’ the raw data, because iobox (Node) doesn’t display them. Though every pin displays raw-values while hovering, that doesn’t help when one wants to watch a spread of raws.

a possible solution could be a iobox (Raw) what essentially is a iobox (Node) but has the ability to display raw data similar to Value or String iobox. what do you think, or how do you inspect raw data? always Asvalue (Raw) and an iobox afterwards?

06.11.2013 - 14:42
well i think the + (Raw Spectral) should be easy enough to write and should make it into the upcoming release. i fear the iobox raw will have to wait a little more.
06.11.2013 - 20:35
whoop, thanks! iobox (raw) was just a spontaneous idea… but i still think it has its right to exist.
19.01.2014 - 11:54

+1 for IOBox (Raw)

This node would make debugging of device-communication much more comfortable. Displaying the byte pattern hovering the output pin with the mouse in many cases is not really helping a lot. And even this is not working on the output pin of IOBox (Node) if Raw is used as output of a subpatch or module ( like for example GetBytes (Raw) ).

Another very basic node that is somehow missing in the raw-category is = (Raw), which also would be good (and logical) to have as a native node.

30.04.2014 - 18:47
in the upcoming release (beta32) the IOBox (Raw) will now show the byte pattern and we’ve also included the = (Raw) node.
30.04.2014 - 22:06
Can you enter byte patterns into the iobox directly?
02.05.2014 - 13:20
@mrboni: nope. this will still take a while but latest alpha already contains a convenience module AsRaw (String Hex)
02.05.2014 - 14:33
thanks joreg
08.11.2012 - 22:29
super just in time!
08.11.2012 - 23:43
thank you devvvvs!!!!!!!!!!!!!!!!!!! :)
09.11.2012 - 02:03


See, when a nigga say he likes it raw he means dirty, down to the floor

08.02.2013 - 16:39

i would strongly consider REMOVING the RS232 (string) variant, as it will garble characters between $80 and $A0 in a way wich is only understandable by someone knowing the exact difference between the Latin Extension 0x0080-0x00FF) codepage of Unicode and good old ANSI in the area (0x80 and 0xFF)

99% of all programmers using RS232 to control devices will drive this crazy, as patches which worked perfect in previous versions will have unobvious but serious bugs.

the same goes for TCP, UDP, Reader, Writer (string) i would strongly argue for removing these completely.

08.02.2013 - 18:40
we were actually hoping that by setting encoding of all related nodes to “System Default” we would circumvent such problems. but we are well aware that this is a delicate topic, we just couldn’t come up with an actual problem yet. so pleaseplease provide us a simple demo where your scenario happens.
22.05.2013 - 15:58

what happened to the ultra-handy Offsetpin Pin of the Ord (String)node node in the new AsRaw (Value) implementation?
the old one-slice-in one-slice-out paradigm proved to make quite simple patches when decoding binaries into its bits.

Tokenizer (string)node should be available in a Raw variant

22.05.2013 - 16:03
if AsString (Raw)node would have a Hex and Decimal mode, it would make the trusty Byte (String)node node obsolete. which would be nice.
22.05.2013 - 17:31
what i don’t like concerning the raw datatype is that there’s nothing visible in the ioboxes. is it possible to display the same thing that is shown in the Pins’ tooltip? that’d be really nice.



vvvv - Dießl & Gregor GbR
Oranienstrasse 10
10997 Berlin/Germany
VAT: DE275566955


Follow us

Sign up for our Newsletter

Your subscription could not be saved. Please try again.
Your subscription has been successful.