VR Ableton sampler control

Hi patchers,

I am working on live performance with my friend that is based on controling samplers in ableton from vvvv with vr. Honestly I hate hacking ableton like this because its much more easier to make something in reaktor and vvvvaudio, but my friend is working in ableton so this is where we are. I have to mess around with python control surfaces and calculate sample position from midi clock, its kinda meh. This is where I am at:

Basic idea is that there are activable objects in environment in groups. Group is one track in ableton, and when you activate an object, it will play the sample and give you control over it.

I have a question about architecture considering vvvv and vl. VL is doing the sampler control part. I feed values into it with binsizes so i can easy make multiple samplers. So i feed in 10 positions with binsize set to 5 and ill get two working samplers.

Problem is however raycasting. I want to always raycast only the closest object and turn rest of the raycasting off while its colliding. for example:
you want to grab the ground and move the whole world, google earth vr style, for movement. Intersectiong ray with and object with ray would activate it while doing this.
Or you are controlling sampler on one group of samples, and there is another object from different group (track) somewhere behind, you could trigger it while doing this.

I was thinking feeding back the raycast info in vvvv with framedelay to vl, but this seems very messy, I already have one (order by distance, choose closest for raycasting) on objects. Can instances of vl plugin that are binsized talk to each other inside vl, or is it better to make some binsizing thing inside vl?

I think so far this is the only thing that is not working out so much with this vvvv binsize approach. I can work around it but i would love to know how to do this proper as I would like to also put it out as contrib.

The hosting layer of VL which does the bin sizing doesn’t have such a feature of feeding an accumulator through - would be interesting but some work to specify and implement. So I think as you suggested you’re better of doing all that inside VL itself where the loops will give you that kind of ability.

are there some regions/pins or other tools specifically for creating binsizes in vl? Or do i just need to add some group identifier to my objects inside vl and then make foreach work based on them?

Not knowing how your patch looks like exactly but I’d imagine you simply create a new process called “X”, put all your existing stuff in there and then in your vvvv -> vl entry point patch you create an instance of that “X” and put a loop around it. That at least shouldn’t break anything. Now you just have to pass through that boolean whether or not the hit test was done already. That you’ll do with an accumulator on the loop where “X” is placed inside.

well ive gutted the object intersetcion out from to main vl patch, and binsize that part differently in vvvv which works

there is no real need to think in binsizes in VL anymore. the basic building block is usually a spread, and with LINQ nodes you can filter it to your liking, until you have another spread, which you can foreach to e.g. push osc messages, depending on the filtering.
so yes, adding an index or a descriptive tag is the way to go. I imagine, your VR-Boxes deserve a Record of their own right, so that is easy to handle.

Spread also branches savely downstream, so you can have multiple patched filtering-and-processing paths going down your vl patch, in case you want to add more creative non-generalized “instruments”

yessss i stumbled on linq and how to put spread into sequences when looking into order by, and love it so far, grouping by tags etc. is a way to go, now i have one patch for raycasting all things in world so its easy to limit it for first thing hit and which controller did it

Ok new problem i have this structure for intersection, the black text are vl nodes in vvvv

I dont know how to feed back my values back into box intersection. I can join box outside and frame delay values like strings and transforms, but i cant frame delay my type inside vvvv, and it seems to me that when I need to use frame delay for this, I am probably doing something wrong. Is there a way how to, for example - add my box inside VL between vl patches without cables in vvvv?

this is the point where you just need to write your boxes (marked as intersected) back to a pad to save all internal state for next frame - and voila, all stateful nodes (like damper) inside are starting to “work”.

on a side note, sometimes it can help to actually use a dictionary for that (instead of the simpler spread), so you can quickly set only the boxes that have actually changed.

@velcrome thanks a lot for replying!

But should I just move all of my parts into one vl patch because feeding back the cable inside vvvv seems not to work, as vvvv just sees cable flowing from lower node to node upstream and does not like it, even if i concat them as to join two spreads into one. Just the relationship between vvvv and vl can get cofusing sometimes. I would like if there was some way how vl nodes can communicate between each other inside vvvv without cables, even thou I get it could be confusing, but seems cleaner to me.

I was thinking about dictionary as i am using filtring with “keep” and “apply” a lot, but I am not totally sure at which point it is better to use dictionary instead of spreads of custom datatypes.

Edit: actually I have no idea when to use dictionary heh

i did just put it all in one main vl patch, and its ok

just to confirm: yes, in general these days do as much in vl as possible instead of creating little “plugins” in vl for then patching with them in vvvv. it takes some time getting used to obviously, but this is how we and other vl-advocates are working and how we are gaining the most from using vl. if you find anything missing for general patching in vl (except automatic spreading, 3d-graphics, 2d/2d-physics, kinect) give us a shout. we’re not aware of much missing stuff anymore.

its ok, just performance of the interface took a pretty big dive at this point, moving nodes to and out of regions is super painful, kinda like trying to play darts after getting beer spiked with ketamine, and to debug spreads a pretty much still have to output stuff to vvvv just to see whats happening inside spreads

1 Like

Is there a way how to lock mouse into renderer without having to hold left click inside of it? I know anout hiding cursor but that does not really lock it into render window

that doesn’t sound right. without knowing any details i’d vaguely argue there should be a way to improve this. note that by default in vl everything is evaluated every frame unless you’re using if-regions or operations you’re not calling. do you see a way optimize like this?

i’ve heard this the first time. what exactly is it that bothers you about it?

confirmed. ultimate pain.

yes but would involve some coding. roughly i’d say the renderer would need a way to capture the mouse and then a way to set the clip-region for the cursor.

So the .net things with cursor i can now patch directly inside VL, right? I have not yet delved into these parts, so far I was focusing on learning logic and patterns, sounds like a great entry point for me to look into that part of VL.

regarding the performance
video of performance
this is video of me dragging stuff in and out of regions, it basically stalls the whole software for few seconds, that super slowly goes through my motions and let go again. Maybe its because i have too many things in one patch, i am not sure what is optimal. Also when i createMy patch looks like this now:

in other thread i am talking about vvvv performance fluctuating just when i move cursor, i think its linked to the openVR, and especially poser node, steam overlay might be doing something weird.

you’ll need to have access to the control of the dx11 renderer. i’m not exactly sure if this can be done in vl then…

confirmed, large patches like yours still show this. we’ll have to fix that. for now i’m afraid your best bet is to make smaller patches.

lookd good. only big. better slice into smaller patches or operations.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.