Build error about milkrack HOT 24 CLOSED

Hey folks, thank you so much for all the info on this thread. I'm sorry I didn't reply earlier, I had my notification settings messed up and I didn't see this thread until @dizzisound mentioned me directly!

I know nothing of Windows development, and I don't have a Windows machine to test on, but I'm very happy to take PRs and edits that improve the portability issue. I actually put Milkrack on the backburner for the past couple of weeks because I realized I wouldn't be able to work on cross-platform compatibility for a while, so I'm super happy that you picked up the ball there! If we have working tests on all platforms I can actually release this :)

@NRG70 I think stretching should be possible, I did some testing when I was figuring out projectM integration and it seems that I can just scale the texture. I must confessed I haven't tried JW Scope yet so I'll have a look at how it works on the VCV side. I will probably be able to work on that this week.

Thanks all for the feedback!

from milkrack.

I post a fresh Windows build that gets rid of the libdl dependency issue, through the use of function macro directives that redirect dl* calls onto native Windows API. Windows users should experiment no more issues deriving from their installed libdl subsystem.
Milkrack-0.6.0-win.zip

from milkrack.

nice! loads error free now :)
would it be possible to make this window stretchable, same as jw-scope ?

from milkrack.

Thanks Daniele Zerbini. Windows version now work. Great job :)

from milkrack.

@NRG70 Good news, and thanks for testing! Anyway, regarding your question, yes, I think it should be theoretically stretchable, though I don't know much about the internals of OpenGL context, viewport scaling, clip remapping or shader transforms. But I am not the developer of the plugin here, I'm only a builder/tester volunteer. I didn't change neither improve anything in the original code, I only pushed very little edits aimed at a cross-platform integration.
Hopefully, increased deliverability can motivate a work in progress to be progressively improved with bug-fixing and new features, but this definitely depends on the developer's goals, his precious time and good will.

@korfuri By the way, thanks for hosting this thread, also feel free to remove the on-going releases if they appear out of context to you. I realize that the builds I posted are development/unofficial releases and it's rather the case to go the standardized official way now (that is, at least, forking the repository and pushing edits, and at best reaching for a PR). That's what issues like this one are targeted to.

from milkrack.

Awesomesauce! I merged your changes and I now have Travis building on all 3 platforms. Here's a RC using the automated builds for everyone. I'm using your pre-built projectM library.

I have a minor concern that this may not be OK for the plugin manager since effectively this is an unverifiable blob, they may not be able to verify that it's not malware. If it comes to that, I'll spend some time figuring out how to build projectM from scratch on Travis as well, but that's plenty good for now IMO. (In case anyone is concerned about the lib being malware, here's a clean Virustotal scan of it: https://www.virustotal.com/#/url/a613a2d98add6515f2419044e2a89d2bbd6bf42ce85c02720435ac5d76e40a18/detection).

Here's a RC with dists for all 3 platforms, fresh from Travis: https://github.com/korfuri/Milkrack/releases/tag/0.6.0-rc3
Folks with Windows and OSX, please let me know if this works for you!

from milkrack.

Managed to cook a build working on my Windows 8.1 x64 machine.
I post the zipfile here for everyone wanting to test it.
Milkrack-0.6.0-win-dev.zip
EDIT: Applied strike-through to the above file path to highlight it's an obsolete build. See below for a fresh build.

from milkrack.

Failed to load...missing library:

plugin.dll
[7.618 warn src/plugin.cpp:84] Failed to load library ./plugins/Milkrack/plugin.dll: code 126

from milkrack.

[8.308 warn src/plugin.cpp:84] Failed to load library ./Rack/plugins/Milkrack/plugin.dll: code 126

:)

from milkrack.

Sorry, I tested only on my development machine, and it worked. But the build I posted dynamically links with libdl.dll (64-bit), and I too easily assumed it was present in different Windows machines. The plugin just fails loading a 32-bit version or in case the library is missing. I'll have to try static linking.

from milkrack.

from milkrack.

from milkrack.

It works well but the liddl.dll must be put in the Windows folder not in the sysWOW64 folder (don't replace the libdl.dll in this folder)...

from milkrack.

from milkrack.

great work guys!

from milkrack.

from milkrack.

Also works for fine for me! Some future idea maybe: an option to save the resulting video stream to disk along with the audio it receives! And a second button to go back to the previous one. (or the original F1 menu from milkdrop! :D )

from milkrack.

Thanks everyone for the comments!

I've made good progress getting this ready to release. I have automatic CI builds for Linux and OSX, and I've fixed a few small issues that did block the release. I still have no way to test on OSX and Windows, so here's the blockers list, and I'd love some help with these items:

• Confirm that the automatic dists for Linux work: Milkrack-0.6.0-lin.zip
• Confirm that the automatic dists for OSX work: Milkrack-0.6.0-mac.zip
• Provide instructions to go from git checkout to make dist on Windows (@dizzisound, did you perchance document your process there?)

All help much appreciated!

@Ghalebor this is fixed in head, it'll be fixed in the first official release.

@catronomix honestly I don't think I want the weight of a screen capture system in the plugin. Capturing video and sound should be done outside of the module IMO. Also, making that portable would be a nightmare. I don't remember what the F1 menu did in Milkdrop, care to enlighten me? :)

from milkrack.

from milkrack.

@korfuri Hi, I just forked your repo here with the latest commits, and pushed my edits to the Makefile, adding a libs/win/libprojectM subfolder where I placed the static library which the plugin depends on.
I don't know if this is compliant with the Plugin Manager requisites for distribution to end-users.
It should be fine if someone can test this approach on a Windows machine. In this case, there's no need to build the dependency, a simple make dist command should go for building the plugin.

Note:
To build the libprojectM library, taking in account some open issues and no official Windows release for the project, I folllowed a "trial and error", manual workflow, adopting a MingW toolchain in place of the recommended Visual Studio way. I know, I am a billygoat. Anyway, to sum it up:

• I first installed glm and SDL2 dependencies (via pacman)
• launched the autogen/configure pipeline suggested for *nix and OSX builds
• fixed a bunch of Windows specific headers, #include, and #define directives
• defined dl* function alias
• added GLEW headers to the project
• tricked with the auto-generated recursive Makefiles so as to normalize the remaining compilation and linkage issues (mainly related with opengl/glew linkage and win32-dirent.h replacement)
• built with --with-pic --enable-sdl options, but without the --enable-gles one.

Got a couple of final errors while trying to build the test subproject, but the main library (libprojectM) was already there.
I may have forgotten something, anyway, in substance, I should have to fork the entire libprojectM repo and try automate the process, but that's a little hard to me (complex build automation is not my everyday thing). I think there should be a simpler way, via the Visual Studio project or AppVeyor maybe? I also hope someone can get there before I'll ever be able to manage such a task! :-)

EDIT: I forgot to upload the Windows build conforming to the last committed sources, with the fixed "Cycle through presets" functionality. I do it now.

Milkrack-0.6.0-win.zip

from milkrack.

from milkrack.

@catronomix [...] I don't remember what the F1 menu did in Milkdrop, care to enlighten me? :)

@korfuri I think he's referring to what's depicted here ;-)

from milkrack.

@Ghalebor said:

Changing works but in time when I clone module to rack it crash all VCVRack

I hadn't tried to duplicate the module yet. On my DAW system (Win 7 Pro x64), I can duplicate the module (what an impressive effect, btw!), if I assure that the Cycle through presets option is disabled. If the option is enabled when I duplicate the first module, or if I activate it on whichever one of the modules after having duplicated multiple modules, I experience the same issue, i.e. Rack ungracefully crashes.

Note 1 - Duplication tests (with and without flagging the Cycle through presets option) should be verified on the other platforms too, so as to check if it's the case of a Windows-only related issue.

Note 2 - This bug should better be reported to a new issue.

Here a screenshot of the working thing - i.e. NO automatic presets' cycling option.

from milkrack.

@catronomix honestly I don't think I want the weight of a screen capture system in the plugin. Capturing video and sound should be done outside of the module IMO. Also, making that portable would be a nightmare. I don't remember what the F1 menu did in Milkdrop, care to enlighten me? :)

@korfuri its indeed that link @dizzisound posted. But I see there that libprojectm does not include the original milkdrop menu... too bad, I hoped the code could just be copied over.
The original milkdrop rendering was also 100x prettier, I remember having these deep, complex presets, and on projectM they all become somewhat dull, simplistic shapes 😢

As for the screen capturing: since the video buffer is already being generated and drawn, wouldnt the overhead to save to disk be very minimal? I'd donate 10 or 15 euros for this ability 😀

from milkrack.