Home Artists Posts Import Register

Content

I think this should do for getting the 3 common AVS visualisation plug-in builds (2.81d, 2.82 & Cockos Happy AVS) into WACUP for those that need it without doing installing it by default & generating a load more crash & bug reports (as AVS does like to crash as I note 😱).

-dro

Files

Comments

Anonymous

Does it just crash the vis, or WACUP as a whole. If it crashes everything, could it be isolated in a separate process ?

wacup

It's all done in-process so it generally takes down the process. Sometimes it won't but things are super weird afterwards & a process restart is needed. Plus for WACUP things are a bit tighter due to the extra aspects the crash reporter tries to catch though AVS instability is one of the reasons that Milkdrop became the default Winamp vis plug-in. Running it in another process is something I've considered doing & have done a bit of research into but it's how to do the appropriate IPC (especially for the audio data & some of the skin integration) which is the pain. -dro

Anonymous

Ooh, how could I forget the audio data :/, yes, making sure that gets there in a timely manner would a priority. I dont know if you the plugin could do all its rendering in another process which would be output in a window that wacup had captured (not sure the windows terminology). Yeah, definitely gets tricky. I've found zeromq / nanomsg quite nice for fast message passing, Cap'n Proto is another one with maybe even less overhead.

Anonymous

One slightly wacky idea would be to make the vis window Wacup a Spout host. Then have the process that runs the plugins share their video output via Spout, that way your suddenly compatible with loads of VJ tools that are Spout compatible.

wacup

Whatever the solution, it's potentially got to cope with plug-ins that just cannot be updated any more (closed / lost source). Though maybe trying to use some of the more recent decompiler tools might have to be the way forward to try to get code that can be re-worked into something usable. AVS is itself a weird one as there is the source code for the core plug-in but the ape's it relies upon were 3rd party & generally that code has been lost & it's often them that are the reason for stability issues (old compiler options & optimisations can prevent them working nicely with DEP/NX-enabled being the norm). There's also weirdness with AVS in that I've seen it's behaviour change based on the compiler & that can break how the presets render which is what led to the mess between 2.81b/d & 2.82/2.83 & the CHAVS fork. So trying to find a happy middle ground where things are stable & don't break the expected presets is a pain. That's before even trying to deal with replacing the DirectDraw based rendering with something that'll work on Win7+. As there's a DX11 based port but it's incomplete & I've never managed to get it to run for more than a few seconds & even that barely rendered the simple preset. -dro