Hi,
In searching for a school project, I came across this surface that was generate by music. The surface changed in realtime as the music was being played on the computer.Here is the example:
http://vimeo.com/29951249
I have read that you will be using “fft,” “damper” and “udp-send” components.
But I have read somewhere VVV can send 256 points info.
Hello Chan,
Please check girlpower folder and music 3d patch. It’s a good way to start on understanding the subject you wanted. Best!
hey chan
if all you want is a mesh jumping around, vvvv should be able to do that pretty simple and you can even save the mesh generated to a .x file that you can import into rhino
audioMesh.v4p (16.2 kB)
can you set a timer, where it sends data every fifteen second or so
Set an LFO to cycle over a 15 second period and connect changeto the _cycle_counter. With every change you can bang out a message by connecting it to Send on the UDP node.
But why so intermittently?
Do you understand how to bundle OSC data?
Hadasi
Hadasi,
Thanks, but I am really new to vvvv so can you give me more detail.
I am trying to visually document sound (music) by creating a surface, using grasshopper. While I can see the sound changing the surface in real time, I want to present the surface beyond the digital world and mill surface. So my idea is to document the sound in particular intervals. I am having a difficult time in grasshopper so I thought if I could send intermittent pulse of data it will resolve some of the issue.
Chan
Thanks again Hadasi,
I figured it out the period. You don’t happen to know about grasshopper too? I don’t know about OSC bundle, can you give me a description?
Hi Hadasi,
may you explain osc bundling and how I would go about it?
Hi Antokhio,
I see in your patch that you don’t use an “OSCencoder.” Why do you not use it and when do you think it is appropriate to use an “OSCencoder?”
So, here we have 8 values as spread (means you have 8 slices), so we say ok you values gonna be a single, one slice string, so we are able to send it with one packet thru UDP
in theory UDP would limit you to a packet size, or some data maybe lost
with osc that probably won’t happen but since you send your values on the local host you can try to still use UDP
Basically OSC bit more tricky to do. With OSC nodes from Elliotwoods much more easy but thay’ve been red on my computer somewhy so i did’t have time to see what happen.
i added you fft resolution so you can try to send higher resolution spread
fft2udp.v4p (28.0 kB)
Hi Chan,
Sorry for the silence didn’t know you posted
I’m not a Grasshopper user so I’m going to make some educated guesses at this point. As I understand it the gHowl components above give Grasshopper (& co) a bit of extendibility for communication and data reading outside the norm.
As Antokhio points out it could be possible to send numbers straight in and seeing if they can be read.
The reason I mentioned the OSC stuff and bundling in particular is two-fold:
Ant’s right, though; OSC’s got a pretty funny syntax I don’t really wanna go into, but all the while if you get the data into and out of it your laughing.
So I’ve re-jigged Ant’s patch to give you an idea of what’s going on.
doesn’t leave you with much left to do really, but it might be helpful for prosperity. It’s got some notes about how OSC works but I hopefully haven’t gone into too much detail. There’s a basic explaination about spreads there too.
Hayd
fft2OSC.v4p (42.7 kB)
Thank you all; it is going to take me the weekend to learn and to absorb all the information from these great examples. Especially with OSCencoder, which is i am not theoretically clear about. How much information can you send through OSC; if you have a 3d model in one program can you use OSC-UDP to send it to another program?