[0.4.x] Re-integrate or drop zombie plugins (that exist but are not being built)

[hartwork]

Hi!

It seems that some of the plugins (in particular actors) are currently not (or not fully) integrated with the build system on 0.4.x, and hence not being built at all. Here's what I found, a check mark means "is integrated with the build system":

• actor/bumpscope
• actor/corona
• actor/dancingparticles — present and integrated on master
• actor/finespectrum — removed on m̀aster in 64e3535, on 0.4.x in [0.4.x] libvisual-plugins: Remove actor plugin "finespectrum" (related to #207) #253
• actor/gdkpixbuf
• actor/G-Force
• actor/goom2k4 — present and integrated on master
• actor/gstreamer
• actor/infinite
• actor/jakdaw
• actor/JESS
• actor/lv_analyzer
• actor/lv_gltest
• actor/lv_scope
• actor/madspin
• actor/nastyfft
• actor/nebulus — present and integrated on master
• actor/oinksie
• actor/plazma — present and integrated on master
• actor/pseudotoad_flower
• input/alsa
• input/debug
• input/jack
• input/mplayer
• morph/alphablend
• morph/flash
• morph/slide
• morph/tentacle

Will have a closer look at the feasibility of options myself, later.

[kaixiong]

@hartwork, not sure why there's no reason given for the removal of finespectrum. I believe we thought that there was no point having it with lv_analyzer around.

[hartwork]

I found commit 5518be7 now, removal was with full intention and I think I may know why.

After looking at these, I find this raises the question where the visual quality bar should be for actors to be in here. One one hand, it's nice to have this be a collection but one the other if they do not meet a certain level, it does damage to the whole package.

We also have two different levers: Build system integration and enabling a plugin in the build by default. If a plugin is disabled by default, distros can override that easily and we're back to poor quality actors on distro xyz. On the other hand, anything not integrated in the build system bypasses CI and is left to bit rot.

With regard to individual actors (and their state in master) my impression is that:

• dancingparticles has some charm
• goom2k also but is rather broken, not usable
  hardly see them and it produces a high frequency of debug output using printf
• nebulus seems to have a problem that audio doesn't seem to affect the rendering much or at all. After that, not all of the 9 effects seem interesting in 2023, even with retro in mind. I'd need to see it with audio effecting it to be sure.
• plazma is not worth looking at, as far as I'm concerned.
• finespectrum was not ready for end users at deletion time, the bars are so short you can hardly see them.

I need to digest on this more, but I think deletion of plazma and finespectrum from 0.4.x is unlikely to be a mistake, for a start.

@kaixiong what do you think?

[kaixiong]

@hartwork, I do agree we should set some kind of standard. I don't want to axe anything at the moment because I've never seen the visualizations in their original presentation and don't know if they look dull because something's not ported or hooked up correctly.

goom2k actually looks very nice. You have to feed it input from pulseaudio or alsa and wait for 1-2 seconds. The actor's got weird pauses (maybe just slow transitions) though.

[kaixiong]

Might be best to ask the person who selected them :) @dsmit

[dsmit]

Just my opinion as I've not been involved for ages.

Especially nowadays I think Libvisual plugins are also an archive of visualizers from the past, and axing them feels wrong to me. Also changing the visualizations isn't really true to their history, in my opinion.

Goom2k4 is very nice, especially since it is software rendered, we were in touch a lot with the authors back in the day.

There are also interesting visualizers not being ported yet, from Linux but also from Windows, that might be an interesting list to set up. One example is the Bomb visualizer from Scott Draves

[hartwork]

@dsmit thanks for your input!

I support what you are saying regarding dancingparticles, goom2k, nebulus, maybe even plazma. That means we'd need to re-integrate them with the build system, fix compilation, find out why goom keeps freezing, why nebulus processes audio input, but doesn't integrate it, and why plazma shows what it does, while I now find it has multiple effects under the hood.

I'm assuming we agree that finespectrum and lv_* are somewhat exempt from this? E.g. lv_analyzer is begging for a re-write to be enjoyable and doesn't seem to have much historic value.

I'd be happy to see more visualizers ported and integrated, e.g. I ran into xmms-scivi recently and the demoscene may have some code we can use, but I think we first need to be on solid ground to have the existing code base running for hours without crashing, before expanding too much.

The key question to me right now is: What do we disable by default in the build system (if any) and what more do we exclude from cycling (if any). What do you think?

[hartwork]

One example is the Bomb visualizer from Scott Draves

@dsmit found it at https://draves.org/bomb/ and https://scottdraves.com/bomb.html but all the source code downloads are 404 and the SourceForge project is gone too, looks like purpose. We may have to ask for the sources and hope for the best 🤷

[kaixiong]

The software archaeology angle is an important one, and I hadn't consider it.

My preference is to keep as much plugins as possible. If maintenance becomes an issue, we could split the actors up the way GStreamer does with their plugins (core, good, bad, ugly) according to support level and licensing issues.

That said, finespectrum was axed because it was more basic than even lv_analyzer.

We should still feel free to modify or rework the innards of some of the visualizations as long as the 'art' is preserved. Some valid reasons (in my opinion) to do so are:

• CPU speed or frame rate dependence: looks wrong on modern systems
• obsolete software and hardware dependencies (T1lib in dancingparticles comes to mind)
• non-portable: reliance on compiler implementation-defined behaviour
• memory errors: leaks, use-after-frees, etc.
• unsafe: undefined behaviour, randomly kills your computer

If the original code is of interest, it's always possible to look them up in Git. Its modification history could serve as a kind of documentation of their evolution.

[stuaxo]

I there is going to be a software archeology angle, it would be nice for users if there was some way of filtering for quality.

In another another project (projectm) its a bit silly that dancing stick men is one of the vis's in my collection and I haven't turned them off, since a lot of the other ones are higher quality and it really stands out when they come on.

[hartwork]

its a bit silly that dancing stick men is one of the vis's in my collection

I know exactly what you mean, they stand out to me as well.

I support the archaeology angle. There is one existing actor plugin that doesn't seem to have any archaeologic value: lv_analyzer. Let's delete both finespectrum and lv_analyzer and use lv_scope instead for a non-GL fallback default in lv-tool?

Maybe a bit radical, but I'm wondering if we should make lv-tool initially skip all actors but lv_gltest and lv_scope and drop actors from the cycle auto-exclusion list over time, bringing them back to user eyes with more quality control. They'd still be accessible directly but we could limit the default cycle set to what passed a certain tests. What do you think?

[kaixiong]

lv_analyzer is a complement to lv_scope. It shows the frequency spectrum of the audio signal, while lv_scope shows only the signal. I would prefer to merge both into a single one eventually for tracing and debugging purposes.

[hartwork]

@kaixiong complement in function yes, but lv_scope has some charm and even a starfield background on master to be backported to 0.4.x while lv_analyzer has bars that are hardly visible and looks terrible. Let's get lv_analyzer out of lv-tool cycling at least, the fewer users see it, the better.

[hartwork]

@kaixiong PS: Also please let's not merge them.

[kaixiong]

@hartwork, I'm fine with keeping the two actors separate and keep lv_analyzer out of the default cycle.

I definitely want to preserve and enhance lv_analyzer to show or superimpose the audio signal, and support more stylized graphing styles like these:

[hartwork]

@hartwork, I'm fine with keeping the two actors separate and keep lv_analyzer out of the default cycle.

@kaixiong thank you!

I definitely want to preserve and enhance lv_analyzer to show or superimpose the audio signal, and support more stylized graphing styles like these:

That would be great 👍