Block or activate only certain slices in a spread

vvvv beta general
1

hello,

im looking for something that blocks or (de)aktivates certain slices

for example

i have a spread with 5 slices
and for what reason 2 slices are one the others just 0
now i just want one of the slices passed through without selecting it with get slice, this would destroy the slice positioning

should look somewhat like this

somehow its selcted that just slice4 is active

first slice
1 0 --> 0
2 X --> 0
3 0 --> 0
4 X --> X
5 X --> 0

if the first slice would be selected than the new slice would be just zero if the second one would be selected only the second slice would be X

is there a patch … or how do i build this??

2

nevermind!

works with three spreads and getslice and setslice

first one which has the inputs goes in a getslice with sliceNumber X.

than another one just with zeros which is the spread input for the setSlice, the value input is the getslice output

there it goes!

3

isn’t it easier to just multiply your matrix with a PeakSpread (Spreads) or MultiPeakSpread?

4

yes, because:
x * 0 = 0
x * 1 = x

5

i gotta admit, the above was more of a rhethorical question :-P

6

where to find multipeakspread?

7

that’s a good question. i also searched yesterday, (frustratingly) without success.

hooray to the wiki’s excellent search engine/functionality sarcasm
generally, imo, finding information/modules/etc. on this homepage is really difficult, and heavily relies on knowledge of other users.
that’s why we get redundant questions and “oh i’ve seen that once, but don’t know where” so often.
also, in nearly all cases it’s faster (and more successful) to ask kalle (or other senior members) where to find a module you seek, than searching yourself, which is definitely inefficient/slow/a waste of human resources.

i wonder why meso doesn’t once hire an intern to get together a nice search function.
and while we are at it, why not also use/implement a forum engine that is up to today’s standards, i.e. subscribing to threads/forums, emails when new posts arrive, you know, all the really amazing stuff… rant over

let’s all just wait until someone by chance reads this thread and knows who coded MultiPeakSpread… :-/

8

http://vvvv.org/tiki-index.php?page=diki+modules#MultiPeak_Spreads_

9

ah, thanks kalle!

10

and you nicely proved my point ;-)

11

we are about to collect all modules at sourceforge:
http://vvvv.svn.sourceforge.net/viewvc/vvvv/modules/

but this will require some days of work, because each module must be tested with the current version, before it gets its place there.

i like the idea of a module upload form very much, but who is gonna make it?

12

module upload form? ooohkaaay. there is for sure a way to categorise an upload as module or patch or fx or… maybe i could do that…by time.
i do not need to be hired by meso, ;-) - of course if there are any programming needs to help - send me a pm, i’ll look if i could help - something like my “thanks, meso” for vvvv.

13

its really sad that the good old User Modules are not found by every user :( especially since they are not hidden (fan club > bazaar > user modules). a lot of the nice stuff is published there.

but i must apologize for screenshooting the “MultiPeak (Spreads)” as a “MultiPeakSpread”; poor old search engine could never find that.

14

@bilderbuchi @victronic @all

completely agreed. i have to admit the vvvv group was always a little reluctant on doing little fixes on this situation, as we always imagined big improvements on this whole topics.

my personal mantra here was

saving patches to a global repository should be

  • more easy
  • more powerful and
  • more safe
    than saving stuff to the local disc.

which will obviosuly make sharing the most natural thing to do. this is a big development effort, so the User Modules page (Diki is right as always) sounded like a workable inbetween solution to us.

as vvvv matures and many wonderful users continue to surprise the community with patches of unseen sophistication, this whole topic is getting more and more urgent.

so anybody willing to spend 4-6 months working full time on this topic (e.g. as part of an academical thesis) please contact us. the vvvv group can provide some basic funding for this.

we are about to publish a list of possible development projects for the community - joreg recently internally formulated this little text (with some minor modification by me) for showing it to your professors:

The ever growing amount of vvvv externals (modules, plugins, effects, …) makes it difficult for the user to get an overview of all the available functionality. Different or even obsolete versions of externals are currently hard to identify. Also developers of externals are still missing a central space where they can register and manage their contributions. A package management system for vvvv externals similar to those typically used with linux distributions or like the Firefox Add-On manager could help a lot.

Further, when working on bigger vvvv-projects that involve a lot of patches and resources (textures,…) using a version control system (like usually used with traditional textual programming) is a big relief for the organization of the project, as it also deals with backup and distributed collaborative work at the same time.

Goal of the Thesis is to find the common grounds of version control and package management and the tight integration in the rapid prototyping graphical programming system vvvv.

Given that the basic problems are already widely explored fields it also part of the research to find out if it makes sense to base the work on any of the many available open source package managers or well known version control protocols like subversion.

15

very nice, a very ambitious goal! a module/patch repo definitely is a very good idea.

i just want to clarify my point from above a bit: my critic was less with a module repo, but with the search function. it may be less effort to implement a nice® search function in the forum (first/essential step: default sort results by relevance :-P), so one gets efficient access to the information already floating around in the wiki.
This would also capture user patches/ patches in response to a user question. These are often not suitable as a module and as such would not be captured by oschatz’ proposed measures.
Also, more importantly information/discussion in threads, would also not be captured by these measures, but often answer questions quite effectively. (cf. “googling” for some encountered computer/driver error often leads to some forum where someone already had your problem). Sadly, this information remains quite inaccessible with the current forum functionality, which in turn leads to many redundant questions…
Therefore, iMHo a better search function would be an easier, more near-term and more efficient goal to fulfill…

(I do realise that it’s easy to make such propositions, and much more difficult to implement them, and that I sadly can’t contribute much more (due to lack of web-coding skills) to the solution than my analysis of the problem and a possible solution strategy)

16

agreed. the current search is a complete waste of time for everybody.

the problem is, its part of a huge pile of code called tikiwiki and it needs a lot of dedication to through the sources and make significant changes. it never really occured to me why nobody else in the tikiwiki community seems to have the same kind of issues with the search function - but it looks like the tikiwiki site is as messy as ours and finding things there seems to have the same issues. which might be no surprise :)

so any tikiwiki expert willing to contribute here, feel free to contact us

17

a workaround in the meantime is searching vvvv.org with google.

brings way better results than the tikiwiki search, which even seems to ignore the page titles:
compare this tikiwiki search results with the google results.

18

yes, i also use google if im looking for something here. it might be easy to integrate a google search field somewhere. but still, a dedicated forums search would help a lot.

the packaging system would be really great, having a central database with all stuff and be able to browse/download/upload it from within vvvv. if there is nobody in the near future who wants to make it, i will give it a try. better sooner than later.