But should I go on from eurorack-blocks for now, just be patient and wait for another windows installation method or is there something on the horizon :)? (just want to adjust my expectations)
So here it seems that python was not installed in the first place. So that python that was executing from /c/msys64/mingw64/bin/ is something else.
But should I go on from eurorack-blocks for now, just be patient and wait for another windows installation method or is there something on the horizon :)? (just want to adjust my expectations)
Well it’s just that I’m super confused about the installation. Nothing really makes sense to me, and I don’t know what to suggest.
So basically now you have a python installation, but that you can’t call directly because there is another one blocking it… from the same package manager.
Use MSYS2 with MinGW-64 with their make and other tools from the MinGW 64 bash console.
WSL2 is th other alternative now it support USB proxy from the there, more info here
I’m not sure if changing the whole process wouldn’t bring its own problems. Here for example python3-pip was installed from the MinGW64 bash console, yet python3 invoked from that same console doesn’t see pip (I guess that’s another python, see my comment upper).
For this we have a reference installation from GitHub, and I guess their engineers have so many different workflows to support that their choices are good. Is it a good assumption?
I’ve just no idea on how to get to the same installation, and when it deviates from it, how to get back on it.
I’ve made this job to check the installation.
@Cpaf can you please run those commands from Git bash and tell me how it diverges from the job upper please?
Thanks!
The user installed tools is not clear from what I’ve read.
Does he use the MSYS2 installation with the MSYS2 MINGW 64 console to install the tools required to run the your python script?
From what I see there is a mixed installation of many tools from many sources.
@Cpaf My advice is to uninstall all the pythons you allready have, and try to install the MSYS2 from the main site https://www.msys2.org/ follow the simply installation step and after installed, use the MinGW 64 console link from the MSYS2 Start menu,
and install the packages needed:
pacman -S mingw-w64-x86_64-python
pacman -S mingw-w64-x86_64-python-pip
after point to the folder of ERB to continue the setup.
I believe it should work.
In the next few days I will try everything on my machine and in case Raphael is interested I will try to write a mini guide for this setup.
I’m super interested!
I’ll need also to make sure this can run on CI (so making sure your guide can be automatically tested). But if you want to contribute that as well, please be my guest 
There will be Superbooth starting tomorrow until the end of the week, so it might take me some time to reply.
I think it’s covered with Github Actions
I mean, we already have a Windows 2019 workflow on GitHub Actions, that executes fine and is already using MSYS (but also chocolatey). But the problem is that it seems impossible for Windows users to reach this (quite simple) setup, and it seems that every Windows users will have a different reason why their setup won’t work with msys.
I’m super confused, starting to wonder if it’s something about MSYS2 and not MSYS, but then I don’t understand why the environment would use msys64 (which is supposed to be MSYS2, right?), etc.
Thanks a lot if you can make this more easy to understand, I hope reading your guide will clarify this mess
On another note, I just figured out that the AWS SAM CLI is python code that comes with its own self-contained installer. I’ll make some effort in that direction to create GitHub releases for the different platforms.
Hi raf, I would like to recommend this again from my analysis from a user point of view, I can report these difficulties in repeating the configuration of the CI:
For example, I use an installation of python 2.7 and consequently by installing a different version I would have some problems using two versions at the same time,
moreover, with windows 10 the installation of Python is also managed by the Store, with an addition of complexity by the non-expert user, because would end up with multiple installations of python in the machine system.
As a result, however, I noticed that you still use MSYS2 for other functionalities, and I would recommend you to use python3 and pip from mingw64 by installing it with pacman from the MSYS2 MinGW-64 bash which is also available in the CI, as show in another post,
thus using a separate python from the system one there should be no conflicts and with the possibility of repeating the environment to use.
The other alternatives could be to delegate to Chocolatey also the installation of python3, but I have not understood well if Chocolatey installs the programs in isolation or globally to the system.
The other option evaluated is to use scoop, this command-line installer for Windows unlike others can also install in isolation without interfering globally with system programs, and this too is available as a github action for the CI.
So for me the simplest solution is to use MSYS2 with MinGW64 and create the whole build environment, I also use it to compile VCVRack, libdaisy and the firmaware for, and easily integrated with vscode.
Sorry for being out of the loop about what to do next, haven’t had time to try out suggestions unfortunately, but I am very keen on installing eurorack-blocks with everything working, somehow when the updated installation method is decided on - so yeah thx for your work raf!!
Cool project! I don’t yet have a bit of daisy hardware to try it out on (eyeing up patch.init()), but I did manage to build the plugins for VCV Rack 2 on Mac (with only a few minor modifications). The vanilla examples run all fine, but the faust examples crash (both Rack 1.1.6 and Rack 2.x) - I don’t know if the faust stuff is still WIP maybe?
Hi raf, I would like to recommend this again from my analysis from a user point of view, I can report these difficulties in repeating the configuration of the CI:
@polyclash I would totally follow your advices on that. How could we practically progress on this? I feel we would need to go off the forum. What I would suggest:
- Making an issue in the project and discuss it there, if it’s short,
- If it’s bigger, maybe have a call about it?
What do you think?
Hi @hemmer and thanks for your interest into the project!
Please don’t hesitate to share your modifications with the project. VCV Rack 2 support should be de-facto now, so if you found something, please share.
Regarding Faust, there are a few points that are not going to work. What issue are you facing? Did you launch a debug session? One thing maybe could be supporting the Faust example reverbs — it’s not going to work. I’m presenting a paper at the International Faust Conference beginning of June about it, if by any chance you are there, let’s meet there!
If not, and it’s typically about a Faust program like a reverb, we will do more work with the Faust developers on that. They introduced lately way better memory management for embedded platforms and we are looking forward to implement it. If this is not about long delay lines, please don’t hesitate to launch the debugger and report a bug with the backtrace!
Sorry for the delay in replying, but I have not received any notifications for this post.
I think instead of discussing this in an issue in github you could create a communication channel directly in github with GitHub Discussions,
obviously as long as you like, otherwise you can contact me directly here, also I am also present in the slack group of Daisy, I prefer more the writing mode instead of the spoken one.
Hey @polyclash, totally fine with that, I thought you would either open an issue or bring it into the discussions. I have already some threads there that are a bit alone 
, but I’ll start a new one on this topic, and post the link there.
(A side question: didn’t you have the rights to open a discussion in the project? Maybe I have some rights that are not properly configured in GitHub. If this was a problem, please don’t hesitate to tell me, as the project is really seeking for feedback. Thanks!)
Incidentally, I received finally my Apple M1 from work, and the installation of ERB is just a disaster. Most dependencies are relying on the popular numpy module for python, and this one fails to install on a very fresh install 
. Something needs to be done, and not only on Windows.
Yes, I can open new discussion, no rigths problem.
argh, I understand you very well 
Yes, I can open new discussion, no rigths problem.
Good to know. I’m making the discussion right now.
argh, I understand you very well
Hopefully we will have finally a robust way to install ERB!
@bosnyak @sam @Alex @Cpaf @jcgriggs please don’t hesitate to participate into the discussion, your inputs are very important to the project!
Super excited to read about a change on the installation - though I won’t be of much use when it comes to the technical side of stuff - but I’ll more than gladly do some test installs on the windows side of things when needed!
I’d be really interested in seeing a midi sync integration. just getting the midi counter (position and start/stop) would actually be enough, as it’s what I currently use in my implementation.
I’ve made a great clock generator in gen~ and would be really interested in integrating it in a vcv rack and/or physical module. I’m now stuck into maxforlive and would enjoy being free of it ! héhé.
I tried to find informations but feel like lost in a sea.