I compiled TheTechnobear's mutable instruments externals and made some slightly better helpfiles from the info in orac plugin descriptions and source.
so far only compiled for osx:
Mi4Pd-OSX-x86_64.zip

Hello, I'm trying to build these wonderfull externals on windows 64bit without success for the moment.
You can see here the issue I made https://github.com/TheTechnobear/Mi4Pd/issues/12

If someones achieve to build them (or can explain how it should be done) I would be super happy

Thank you everyone

Guillaume

@Guillaume It seems like it can't find pd.dll in PD_CMAKE_PATH from what I can tell.
Btw it doesn't seem like windows is supported by the author unfortunately (according to the Readme)

Arg... This is what I was fear about... So I hope one day someone with more knowledge than me on building will port this on windows

Thanks for your answer

Guillaume

I managed to compile in msys2 MinGW 64-bit on win10 after adding this to CMakeList.txt

if(WIN32)
    message("windows support limited")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DTEST -fPIC" )
    set(PD_CMAKE_PATH "C:/Program Files/Pd") 
    set(EXECUTABLE_NAME mi4pd)
endif()

also, to force cmake to use Unix Makefile generator instead of default MSVC
I added file next to CMakeList.txt called PreLoad.cmake with following:

set(CMAKE_GENERATOR "Unix Makefiles" CACHE INTERNAL "" FORCE)

So,

mkdir build && cd build && cmake .. && make

produces DLLs in ./release/bin/ with some minor warnings, but all audio object causes segmentation fault and crashes Pd straight after enabling DSP. Only grids is usable.

thanx man !
made already some little track with it

One thing to keep in mind with these externals (unless you have modified them, which I don't know how to do) is that they were created/adapted for use in Organelle, that is, at 44.1K and 16 bits.

The original hardware modules have different and very varied sample rates. In short, I think clouds uses 32k, rings 48k, braids 96k, etc...

They are great externals, I managed to compile them in Linux after looking for some information and since then I haven't stopped using them.

I just noticed a few days ago, that shortly after commenting on the forum or even at the same time, a couple of externals (brds and rngs) were updated on TheTechnobear's GitHub.
They can now run at their original sample rate and if not, a message like this now pops up in the console:
"brds~.pd is designed for 96k, not 44100.000000, approximating pitch".

Hi, looking at the lmnts help file, seems none of the blow or strike parameters do anything...then looking at the code in Github https://github.com/TheTechnobear/Mi4Pd/blob/master/lmnts/lmnts~.cpp#L163-L166, it looks like it's been disabled.

Does that sound about right? Are samples in the actual hardware, therefore subject to copyright stuff etc..?

Of course can make our own impulse..but just struck (no pun intended) me as a little odd.

@boonier I don't think there's any copyright issue as the Mutable Instruments source code is freely distributed... I'm not sure why the code you mentioned was commented out.

I made some changes to the code and built another version:

lmnts~.pd_linux

I must be missing something, but both blow and strike parameters have always worked flawlessly for me without having made any changes to the code.

Well, this is strange. I've just compared both versions (with and without code changes) on a different machine and these strike/blow parameters affect the sound output for both.

There do seem to be some subtle variations between the versions' responses to strike_timbre but this could just be my imagination.

Not sure what happened here, perhaps a sample-rate issue? In any case, I have closed the GitHub issue for now. I am still wondering if any other users have experienced this behavior.