Sender | Message | Time |
---|---|---|
2 May 2020 | ||
gregsn | *
it's a pity that we didn't manage to communicate this better. But if you only look at the technical aspects you will see that vvvv beta and vvvv gamma benefit from our work on VL. there are libraries popping up that were realized with VL and come with node sets for vvvv beta and vvvv gamma. there is even some vvvv beta specific stuff coming up like a new contribution manager that should make it much easier to set up the system. the installer for vvvv beta is another thing that happened on that "product line". So as it is true that our hopes and wishes regarding a pure VL based system are high, we always made sure that vvvv beta benefits from our developments. So I would argue: whatever works. If the current state is having two systems where one isn't quite replacing the other, then I say use vvvv beta. Tha's what I would tell a user that knows beta well. However regarding workshops: It does feel a bit weird to teach vvvv beta without mentioning VL and teaching both at the same time is probably overwhelming. So yes. it is tricky | 08:02:37 |
wirmachenbunt | i quote joreg out of my head (seen in forum and riot) "gamma is in many regards already better than beta" , thats a message which i interpret as beta is done. you can use it but it isn't our concern anymore. beta is only a testbed for gamma and in terms of the VL integration not even uptodate. i had several occasions where i was told a specific problem is already solved, just not for beta VL. | 08:15:01 |
gregsn | Elias already put quite some work into getting beta up to date regarding VL, but it's not ready yet. But it's on the agenda. Regarding joregs quote: might be, but maybe he said something like VL is better suited for some tasks, which is different from saying vvvv gamma is better suited. But again regarding workshops it feels right to teach VL as this helps users of vvvv beta and gamma to create more elaborate applications | 08:25:05 |
gregsn | so i guess i am saying: there is no such thing as teaching vvvv gamma. there is teaching beta or teaching VL | 08:31:49 |
gregsn | * so i guess i am saying: there is no such thing as teaching vvvv gamma. there is teaching pure beta and there is teaching VL (for beta or gamma) | 08:37:00 |
iorec | obviously most tricky is the situation regarding the still missing 3d engine. at NODE17 we had roughly 50 workshops and a bit more than half of those were relying on 3d. but the other ~half was not. so while we're working hard on having a first version of VL.Stride accessible for everyone, we could first focus on the other topics and see who'd like to take those on and then work together preparing those. | 11:03:56 |
iorec | i came up with this rough list of topics that could be prepared already. please add yours: | 11:04:53 |
iorec | • computer vision • 2d data visualization • music visualization • audio basics • building control user interfaces • lighting control • laser control • firmata/arduino • 2d physics animations • skeleton tracking and interaction • networking/iot (udp, osc, mqtt, zmq,...) • accessing web apis (websocket, parsing json/xml) • lighting control • laser control • firmata/arduino • object oriented patching • reactive patching • application patching patterns • using .NET nugets • building VL libraries | 11:05:18 |
domj | Some stuff is there twice :) but it's a pretty exhaustive list | 11:06:27 |
iorec | hehehe, i cannot fool you.. indeed. let me fix that. | 11:06:55 |
iorec | * computer vision • 2d data visualization • music visualization • audio basics • building control user interfaces • lighting control • laser control • firmata/arduino • 2d physics animations • skeleton tracking and interaction • networking/iot (udp, osc, mqtt, zmq,...) • accessing web apis (websocket, parsing json/xml) • object oriented patching • reactive patching • application patching patterns • using .NET nugets • building VL libraries | 11:07:28 |
domj | It's also the stuff I was hoping to contribute with in some way | 11:07:33 |
iorec | now.. | 11:07:48 |
iorec | ideally we'd have individuals jump on any of those topics and prepare needed libraries, content, webinars for those. and let us know wherever you need help. preparing libs can be very much a communal effort. once a topic is covered it can be made into a webinar right away, doesn't even have to wait until NODE | 11:09:43 |
iorec | one of the most hot contenders for me would be working on a 2d physics lib | 11:11:20 |
iorec | meaning: i'd love to see someone take this on | 11:11:44 |
iorec | it is not something that will happen soon from our side. | 11:12:08 |
iorec | also lighting control and laser contro | 11:12:20 |
iorec | * also lighting control and laser control | 11:12:23 |
domj | Aether2D is there for the taking regarding the physics https://www.youtube.com/watch?v=l1FhHXAhfRQ&t=1s | 11:12:38 |
iorec | yep, for example | 11:13:41 |
domj | I have bunch of useful lighting control abstractions in Schéma, which I hope to release as a usable library on their own. Some GDTF parsing work has been done by c nisidis | 11:14:27 |
iorec | sounds all good. focus on those, make them a thing. that would be amazing. | 11:17:29 |
domj | laser control is a plethora of DAC hardware, each requiring its own implementation. I have shortly tried using the EtherDream library in VL with mild success, but the library itself is slightly crap (unreliable in corner cases such as reconnecting). A much better approach imo for that box in particular would be a pure TCP implementation of the protocol, but the VL TCP nodes are so-so. The TCP is actually something you could work on I think. | 11:19:31 |
domj | Also IIRC colorsound had some other DAC (Moncha.NET or something) working in VL more than a year ago in the november 2018 meetup. | 11:20:32 |
iorec | i think most important for here and now is not discussing implementation details but finding people who want to commit to topics and then discussing details in smaller groups. | 11:21:57 |
iorec | can anyone come up with other topics that don't require 3d? | 11:22:01 |
domj | But it would make sense to not repeat common tasks such as point interpolation and path finding. So it would be good to have a coordinated effort resulting in a common laser library and a number of HW specific bridges. | 11:22:08 |
domj | In reply to @joreg:matrix.orgok, shutting up | 11:22:20 |
iorec | hehe | 11:22:30 |