hours and hours trying around to get useful data out of NativeInstruments Traktor, reading through hundreds pages in NI's forums, the old vvvv-board i saw an old thread by MSBERGER about the lost "enqueue" mode of the UDP (Network Server) node....
ok, i turned back to beta6.8, opened the OSCdecoder helpfile, which is a complete different one, and:
Decodes an OSC packets into its arguments (Cannot deal with bundled messages and timestamps)
and i am wondering about the fact that the only thing i get from the UDP-node is #bundle
since ampop is member of the bestboys luckily there are lots more helpfiles with vvvv.
but vvvv grows lots faster than its documentation which is a known problem to all here.
so lots of the helpfiles a lack of important detail informations, show only rudimentary functions. (e.g.: FileTexture and the missing explanation of the very new parameters commented somewhere else here)
what would be the right way to implement a kind of users helpfiles database here in vvvviki? i think this has to be very narrow to the node reference which is, ahem,....not really...
i really like to contribute some helpfiles like in the old board, where the node reference could easily be replied.
don't feel harassed about my previous post
its just thought as a constructive critic
best regards to the devvvs
The easiest way would be just posting help files here, and let us take care of putting them at the best place.
A better solution could be collecting them at the Downloads page (i just created a headline there) It probably makes sense to sort these not after Users but after Categories.
I would consider this as a preliminary place for not yet released help files - the final place should be in the next release, so our users can have one convenient package - so dont mix up help page replacements with modules or demo patches. In case of a new release we would probably like to clear the list and have everything included in the release. Please do not require any media files apart from the ones already in the help directory, and try to format your patches similar to the ones included.
And please note when posting that you agree on including your patches in the next release.
And actually we are still thinking about the long awaited node reference. So it could be actually a good place for posting patches some day.
mh just wanted to ask if theres any progress with that osc bundle issue... because all NI-Software sends everything in bundles... bundles would be a nice feature anyway: Receive from multiple adresses parallel in one frame without having to open several network ports.
I'm wondering if its possible to patch an osc-decoder that is able to handle bundled messages? what nodes should be used? i think with regexpr i dont come far because it just handles strings?
Is there any idea when the new release (the one after beta10) will be available ?
I just stumbled over the old #bundle-issue with the OSCDecoder that following the change log seems to be solved with the new version.
"OSCDecoder now copes with concatenated OSC messages (even if they are not bundled)" - does this mean that OSCDecoder now can deal with bundled messages ?
I somehow only get spreads with a spreadcount of 2 out of the OSCDecoder pins "Arguments:" and "Type Tags:" although the OSC bundle should contain a lot more elements.
I checked with another application (Eyesweb) if reactivision is sending more than these two elements and it looks like reactivsion is working fine.
A problem could be that the OSC bundle contains strings AND integers at the same time !?
Any ideas ?
ha. strange indeed.
i just tried with the ingenius tuio simulator that can send demo data to vvvv. strangly the received bundles contain the same /address several times. the OSCDecoder consequently only decodes the last one from the bundle discarding the rest. that is correct as i understand that identical /addresses in one bundle don't make sense.
strings and integers don't matter.
i'll contact the author of reactivision about that issue and report back. brilliant piece of software by the way.
the tuio protocoll is not compatible with vvvvs OSCDecoder and the tuio-guys won't change their (admittedly) strange usage of the osc-protocoll.
so i see two ways to go:
both options are equally plausible and should be achievable within finite time..
please knock back when it gets really important for you.
@joreg: just for understanding this issue:
is the problem that TUIO extends OSC with some additional type tags?
or is there some deeper quirk in TUIO which breaks vvvv´s parser?
anyway, option B might be a topic for my course at hochschule darmstadt this fall
the problem is not with typetags. the tuio protocoll sends several identical osc-messages (only with different parameters) in one bundle. since all messages in one bundle are supposed to happen at the same time it is not defined what to do with the arriving parameters. vvvv only outputs the last.
the tuio-protocoll could be corrected but they won't do it because they already have it implemented in several applications.
modin (the reactivision author) is planning an eyesweb-plugin later this year and wanted to have a look at the freeframe option too which really should be simple to implement. but if anybody in darmstadt is faster she is welcome.
native fiducial tracking support for vvvv via a freeframe plugin?
It seems there's a bug in the osc nodes (especially into OSCdecoder one). I actually made a patch that's receive 16 float values from another computer running max/msp. Theses values forms 8 (x,y) coordinates. I just detected a weird behavior (short screen freeze, and cpu gap) using this patch.
The two computers (macbook and pc) are connected with an ethernet cable.
After some tests (using debug mode and renderer tty) seems to be an OscDecoder issue (it blink red and turn to 60 debug time 5i.e not sure what's exactly°). The tty renderer report:
"01:31:54 * : validatevalue: error occured in ]: Zugriffsverletzung bei Adresse 0071DCBA in Modul 'vvvv.exe'. Lesen von Adresse 00000000"
The bug seems to occur according to the packets' rate, the precision of the incoming float values and the changing speeds of theses same values (the ones encapsulated into the OSC packets).
Does any user experience this before ?
Is there some way to fix that (if it's related to vvvv)?
It'd be great if that can be fixed (if this a vvvv issue), so that it'll allow a better communication between vvvv and max.
jep, seen that before. are you sure you are using latest beta13.1 because i thought that problem was fixed some time ago. if it is still there if would be fine to get have a patch that demonstrates the problem..
could you try simulating your maxpatch in vvvv and send the 16 values locally to an other vvvv-patch for decoding to see if the problem persists? and if so send those patches?
Yes, I'm using vvvv beta13.1.
Today, I've try to use the same receive patch. And to send some random values from another pc running vvvv (not the same behavior than the max patch) and it works.
For trying simulating the max patch in vvvv it's another story right now, as it deals with physics and interpolation between boids pattern, not sure i've enough knowledge to simulate it within vvvv. But could make a try.
This week-end my mate will use his max patch and record output in a text file, then i'll try to read that values locally using vvvv and send to another pc running vvvv. I'll let you know if it goes crazy too.
Here's my receive patch. It receives 16 value from /boidnX (n -> 1..8) and /boidnY (same). Maybe i'm doing smth bad in this patch too.
As soon as i can have access to the max patch (it use some custom librairies) i'll let you know and post it.
Cheers and thx,
anonymous user login