Jamoma Windows_x64 not working

[matcham]

all nightly builds of Jamoma Windows_x64 do not work :
I get
Jamoma | build 87e3c18
in Max window on startup.
no error message in Max, but instantiating any j.* results in an empty max object (the frame of the object is drawn, but text is invisible)
impossible to load a patch containing jamoma externals : the patch just do not open (no error message)
no crash
�

[alfonso73]

Hi, confirmed here on Win 64.
I get
Jamoma | build 87e3c18
in Max window on startup.
But as soon as i try to instantiate any j.* object Max 7.3 crashes right away.
a.

[sone]

I can confirm this problem regarding the same build as mentioned above, too.

I'm trying to compile. I'm unexperienced especially on Windows but willing to learn. The needed steps are not completely documented as far as I can see. I had to set the path to sh.exe (git or Cygwin) but after running the shell script there are some more steps to execute - some more I don't know yet... In the pop-up window opened by the build.sh there is text about something like "it's not available on windows" - is this text logged? The --multi flag is not working on windows - it looks like the reason why is because sysctl is called which is not available on windows - even not with Cygwin.

If I can be of any use regarding JamomaMax on Windows 64bit, please let me know.

Cheers, Johannes

[tap]

Thanks for trying to build and debug @sone !

I have personally not tried building and debugging on Windows in a while and it would be good to give it a try in order see where some of these problems arise -- and to document what comprises a viable Windows build environment.

My system:

• Windows 8.1 (being run under Parallels on Mac hardware)
• I do not have Cygwin installed
• I use the MinGW shell provided by installing Git on Windows
• I'm using Visual Studio 2017
• I have CMake 3.8.1 installed

My sequence:

• I run git clone [email protected]:jamoma/JamomaMax.git
• cd JamomaMax
• git submodule update --init (maybe the --recursive flag works too, but I've never used that)
• ./build.rb --win64 (don't use --multi for debugging because it jumbles-up the error reporting)
• doesn't work because that script requires an old version of Visual Studio... So I update the build.sh script line accordingly: JAMOMA_CMAKE_GENERATOR="Visual Studio 15 2017 Win64"
• Now I run ./build.rb --win64 and note that there are lines saying "Does not work yet on Win64". Do these refer to LIBICONV? Something else? I don't know. But in the end it complains that no Makefile was generated and it doesn't build.
• Let's try it for 32-bit. ./build.rb --clean. It fails to build in a similar way... and I don't really know why.
• Looking at appveyor.yml I see that the nightly builds are being done using the script at script/build-appveyor.ps1. From here deduce the cmake commands so I can try to run them manually...
• delete the old build and build64 folders from previous failed attempts
• mkdir build
• cd build (let's try 32-bit instead of 64 since we are desperate for a success)
• cmake -g "Visual Studio 15 2017" -DCMAKE_INSTALL_PREFIX=`pwd`/JamomaInstall -DCMAKE_BUILD_TYPE=Release .. -- this appears to produce something reasonable, so proceed to actually building...
• cmake.exe --build . --config Release > build.log (can watch the build results as it churns by opening that build.log file in Sublime Text)
• I'm not sure if it works or not, but this produces a valid looking package. Hooray! Now let's try 64-bit...
• cd ..
• mkdir build64
• It fails to build the modular framework due to linking agains printf() and other functions which have always been a hassle on Windows but not a failure like this. Probably the failure is due to me using a newer version of Visual Studio than 2013.

If I were to now try building for 64-bit it would look like this:

• cd build64
• cmake -g "Visual Studio 15 2017 Win64" -DWIN64:Bool=True -DCMAKE_INSTALL_PREFIX=`pwd`/JamomaInstall -DCMAKE_BUILD_TYPE=Release ..
• cmake.exe --build . --config Release > build.log

Is this enough information to assist you in getting a build environment working?

[sone]

Yes, it should be enought information for the first round, thank you very much @tap
I've had problems with defect RAM and latency issues with my Thinkpad P50 in a way that I'm not so happy and at least one eye is looking at these hot glue computers again... anyway... sadley I have to reinstall Windows completley to find out if these latency issues can be cured or if I have to get a different computer. Thus it will take a little time before I can get back to JamomaMax.

[sone]

Hi, it took some time...
but I tried to build for 64-bit as tap suggested today.
Because I've VS Community 2013 installed, I've changed "Visual Studio 15 2017 Win64" to "Visual Studio 12 2013 Win64" The build log is attached. It's about 2036 Warnings and 59 Errors and 1 fatal error as below:

"D:\DATA\DEV\git\JamomaMax\build64\JamomaCore\Modular\library\Release\JamomaModular.dll : fatal error LNK1120: 27 unresolved externals [D:\DATA\DEV\git\JamomaMax\build64\JamomaCore\Modular\library\Modular.vcxproj]"

best, j.

jamoma_build-log_win10_64bit_180119_01.txt

[tap]

Hi Johannes -- that's pretty overwhelming! A couple of thoughts... 1. I'm not sure if VS2013 will work or not. Some of what I'm seeing in the out is about problems with std::mutex -- which might not be fully implemented in VS2013. 2. The link errors building the Modular framework (at least some of them) look like they are problems finding LibXML, which is a third-party library. 3. Is the OSSIA project building on Windows? If so, I wonder if that is a more fruitful path forward? best, Tim

…

On Fri, Jan 19, 2018 at 9:13 AM, Johannes Sienknecht < ***@***.***> wrote: Hi, it took some time... but I tried to build for 64-bit as tap suggested today. Because I've VS Community 2013 installed, I've changed "Visual Studio 15 2017 Win64" to "Visual Studio 12 2013 Win64" The build log is attached. It's about 2036 Warnings and 59 Errors and 1 fatal error as below: "D:\DATA\DEV\git\JamomaMax\build64\JamomaCore\Modular\ library\Release\JamomaModular.dll : fatal error LNK1120: 27 unresolved externals [D:\DATA\DEV\git\JamomaMax\build64\JamomaCore\Modular\ library\Modular.vcxproj]" best, j. jamoma_build-log_win10_64bit_180119_01.txt <https://github.com/jamoma/JamomaMax/files/1646970/jamoma_build-log_win10_64bit_180119_01.txt> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1012 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGsRU7G5-8uo39vaoOAk1GbcAMoW48Gks5tMLErgaJpZM4J8gfP> .

[bltzr]

On 29 Jan 2018, at 18:57, Timothy Place ***@***.***> wrote: 3. Is the OSSIA project building on Windows? If so, I wonder if that is a more fruitful path forward?

Yes, I think it does, see: https://github.com/OSSIA/libossia/wiki/Building#building-libossia--tests-on-ms-windows-with-visual-studio <https://github.com/OSSIA/libossia/wiki/Building#building-libossia--tests-on-ms-windows-with-visual-studio> Could you confim that it does, if you give it a try ?

[sone]

I cannot confirm really but I've attached the logs for both OSSIA and Jamoma with VS2017 installed. There are far less warnings and errors regarding Jamoma now. If I can do anything, like to provide more detailed information and testing, please let me now.

jamoma.zip
ossia.zip

[bltzr]

you might be interested by this, @avilleret

[tap]

Thanks, Johannes! What I see in the error output is basically one error, but it is present many many times because the error is in a header file that is included in many places. The error looks like it stems from the use of a custom string class called TTString instead of using std::string. At some point in the ancient past (like 10 years) we did this because there were problems with memory alignment and std::string because we were building using Cygwin and GCC instead of MSVC and Max is built with MSVC. That has not been the case for a long time now (thank heavens). I had thought we moved ahead and switch from the custom TTString to using std::string, but it looks like I'm mistaken on that. Perhaps we decided that we should and then never did the work... Regardless, doing this would be more fruitful in my opinion that layering-on further hacks to allow TTString to work with the rest of the STL properly. best, Tim

…

On Wed, Jan 31, 2018 at 12:22 PM, Johannes Sienknecht < ***@***.***> wrote: I cannot confirm really but I've attached the logs for both OSSIA and Jamoma with VS2017 installed. There are far less warnings and errors regarding Jamoma now. If I can do anything. like to provide more detailed information and testing, please let me now. jamoma.zip <https://github.com/jamoma/JamomaMax/files/1682816/jamoma.zip> ossia.zip <https://github.com/jamoma/JamomaMax/files/1682817/ossia.zip> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1012 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGsRaIvaMNlYJtgPsvGTDG5wr0cQ2r8ks5tQK9rgaJpZM4J8gfP> .

[balintlaczko]

Hey there! A lot of people would be extremely happy to have a stable windows jamoma. If you ever tried to make a large-scale (and scale-able) patch system in Max, I would say it's probably close to impossible without jamoma. And ossia is very nice, but it's missing many of the subtle things jamoma has.
What I (and probably many of us) would need is actually just a small part of the package, around 10-15ish externals, most probably not more than 20.
Is there any chance that you try building/testing at least a few of them on a Windows 10 x64 machine sometime in the future if we ask really nicely? Like reeeaaaally nicely! :)

[avilleret]

I don't know anyone who want to dive again into Jamoma code under Windows.
Implementing missing features in OSSIA would be a better path.
Some people are actually very busy at gathering some "chance" all over the world to make that happen.

[tap]

@avilleret This is very exciting!

@balintlaczko If you could name the exact externals in your reduced set, I'm curious what they would be.