Hello. Do we still need public modules, that internal structure looks like a mess of not organized nodes? How this modules can be modified and understood by other users? Why we still including this modules into the core addon pack? And finally, why we not mentioned this already?
Previously we discussed with @defetto, that mess in patches in most cases is the user problem. But if we accepting this huge organised modules we encourages this style of patching. I think we need something like a patch convention, similar to the plugins and namings convention.
completely disagree in the point.
addonpack modules are extremely userful e.g. Camera, PerfMeter and so on, they are modules.
and you can use module as it is or simply copy/rename and modify .v4p file by your own way.
of course, patch is not so clear to read as code, because of values hided in pins, but:
if you like module you can use it as it is,
if you like module, but dislike some options or patchstyle - you can spend some time to fix or change it
if you dislike module just delete it or never use.
or lets say, “users shaders and plugs are messy, users need to understand their code, why we still share shaders and plugs?”
and now it’s the best time to say THANK YOU to everybody who contribute their modules. it is always better to share!
I’m completly understanding your position. But if we talk about evolution of VVVV as language and want to integrate it into any well formed workflow, we need to understand it bad sides. And mess in sources - is the one of them. Currently, i’m trying to integrate VVVV as production tool in our company, and spending a lot of time thinking, how i can share my knowledge with another programmers. Yes, i need to say huge thanks to all contributors, but you forgot that latest version of PerMetter (Debug) cleaned and easy to read. After some time community will also clean Camera (Transform Softimage), because current version are hard to modify. You also forgot, that Camera and PerfMeter are legacy modules. Currently i’m talking about future of our community. Interactive installations already crossed the line of it’s complexity and complexity of our patches will be also increased. Our tool is also evolving - just look into dynamic plugins and our discussions in https://discourse.vvvv.org/t/7353 . But when i’m looking into some of the new modules, i’m feel like i’m in 2008. Hope you can understand me.
lets talk about corporate and non-corporate style of business (please not to be confused with commercial-non-commercial)
as i see vvvv style is commercial but non-corparate style with live community and live developing. by corporate style i mean adobe/microsoft/apple etc.
you are talking about structuring knowlege/contribution base - this sound like full-time job for couple interns (at the moment, and will need more and more since community grow everyday).
for me this is not language problem, this is business problem. lets choose what we like more? more freedom and live growning or better customers support?
i’m very interesting in future plans of vvvv group too. but since it sounds like business plans i have no hopes to heard anything before it will happens.
back to mess in modules. my solution is simple. i have my own list of trusted users. if let’s say @kalle contribute a module i’m sure it’s good and when i need it, i use a module as it it.
if i have a goal but can not find a ready to use node/module/shader/plug in 20 minutes, when i start to patch my own. but most frequency needed goals already realized in nodes or addonpacks.
No, you not understood. I’m talking about increasing code quality and evolution of the language and tool. And it’s evolution is community driven, so it’s not corporate. Just look into Processing community - most libraries are well documented and have nice API. It’s because programming style matter. Because VVVV is more artistic than Processing, we have a lot more artist in our user base and it’s affects code quality. I’m not asking to bane contributions from artists, but i’m asking to improve it’s quality and somehow filter what we integrate to the core and what not. I think artist will finally learn what matter “convention” in software development. Also, as opensource community we need to create tools, that not just solve problems. We need to create tools that shows how to solve problems. For me this is the one of the core features of open code. Nice patch organisation is simple task and it can show, that better understanding of your work is important for you.