Bidoo

[sebastien-bouffier]

name: Bidoo author: Sébastien Bouffier license: BSD 3-Clause contactEmail: sebastien.bouffier@gmail.com pluginUrl: https://github.com/sebastien-bouffier/Bidoo authorUrl: https://github.com/sebastien-bouffier manualUrl: https://github.com/sebastien-bouffier/Bidoo/wiki sourceUrl: https://github.com/sebastien-bouffier/Bidoo.git donateUrl: https://paypal.me/sebastienbouffier latestVersion: 0.6.1

[sebastien-bouffier]

Last version information Version: 0.6.1 Branch: master Commit: 12f6750b076111d3bf43848a1c8106f24736ffaa

[phdsg]

Makefile in branch/tag 0.6.1 says VERSION 0.6.0.1 sorry. somehow looked over the commit hash :) all fine there

[phdsg]

updated: https://github.com/VCVRack/community/commit/c72ef3015969563d3373e4f6d55a17d66ad32880

[AndrewBelt]

Removed repo from submodule because of build difficulties. This one looks nearly impossible to build automatically because of all the weird dependencies, so I'm going to leave this out of the Plugin Manager and treat it like a closed-source plugin when a procedure is ready. https://github.com/VCVRack/community#addingupdating-your-plugins-build-for-closed-source-plugins That GLFW dependency is pretty nasty. Why do you need that? Calling glfw functions on Windows?

[phdsg]

@AndrewBelt is there a way for a dev to check if their code will build in the buildteam's environment!?

[sebastien-bouffier]

Hello, @AndrewBelt I use GLFW, maybe not correctly, to manage custom key commands or mouse clicks to increase the "usability" of my plugins. Regarding the build issue I just pushed a new version of my makefile which is closer to the previous one where curl is dyn linked based on the curl you have in Rack and everything works fine under W10 ans Lin. I hope some user will test asap under os x. I think there is something I missed regarding "nearly impossible to build automatically" ... is there a thread on that topic so I can understand how to test automatic build ? Until now when I can build/link/make dist on top of Rack I consider it is ok ... not correct ? Thanks for the time you spend in helping me. Best

[AndrewBelt]

@phdsg Not really at the moment. It'd be nice to release a single Docker image for all three OS's and then a nice Makefile, but I'm not that organized yet.

@sebastien-bouffier If you're just using key commands, you don't need GLFW but instead onHoverKey() to accept keys when your ModuleWidget is hovered with the mouse. Perhaps a better solution is to try to statically link as many libraries as I can into Rack, which is no easy task but maybe necessary.

[sebastien-bouffier]

@AndrewBelt I will try to change my approach by using your recommendation. But to make the full story : I have a mixer/patcher/sequencer ACnE that I use a lot and I implemented a simple shortcut that mimic your right mouse click that set knobs to 0 but mine is a center click that set knobs to full value. This is convenient for fast patching. But it was a semi good idea because mac users haven't a center-click so they asked for a workaround and we agreed on shift+click. So onMouseDown I have something like that in my knob widget if ((e.button == GLFW_MOUSE_BUTTON_MIDDLE) || ((e.button == GLFW_MOUSE_BUTTON_LEFT) && ((glfwGetKey(gWindow, GLFW_KEY_LEFT_SHIFT) == GLFW_PRESS) || (glfwGetKey(gWindow, GLFW_KEY_RIGHT_SHIFT) == GLFW_PRESS))))

Regarding static linking yes it might be necessary at some point, if I increase my knowledge on that topic I would be really pleased to help ... but it is a real nightmare .. you are right it is not an easy task.

[AndrewBelt]

You can use windowIsShiftPressed() instead of the glfw calls, and then you don't need GLFW at all.

[sebastien-bouffier]

Haaaaaaaaaaa I did not see that function ... thanks so much.

[AndrewBelt]

Actually, I'm switching to static builds on all OS's for Rack 0.6.1. It doesn't break ABI compatibility, and you'll be able to call glfw functions without compiling it yourself.

[sebastien-bouffier]

thanks a lot Andrew

[sebastien-bouffier]

My pack builds now against the 3 platforms. I have a clean dist for each of them in my last release. Could you consider allowing usicians (users + musicians) to dl my pack via the standard tool please ?

Last version information Version: 0.6.1 Branch: master Commit: e82a658a88e3c7a27b6fbc97bf2b3def486a6e04

[AndrewBelt]

Actually, I could add it to the automated build assuming you've removed GLFW.

[sebastien-bouffier]

Yes it is removed.

[sebastien-bouffier]

I think I am not to far from the target ... curl is statically linked for Lin and Mac ... I do not know why I can not build the same way for Win but it works (I deployed my plugin on a win machine without any dev environment so without curl installed, and it works)

Last version information Version: 0.6.1 Branch: master Commit: 41bca78b33db03eaaec69861f2f5d56155e7368c

[sebastien-bouffier]

LatestVersion: 0.6.2 Branch: master Commit; f548eb304624b32446df09ddac43ac793b6fd2d7

[mdemanett]

Updated. I checked the build (on OSX); looks good to go.

[sebastien-bouffier]

Hello, does it mean that my pack will be available thru Rack ? Do I have to provide a mac os x dist in my last release ?

[mdemanett]

Andrew's build system will build for each platform, and those builds will go out via the package manager. You shouldn't have to do anything more to for that to happen.

[sebastien-bouffier]

Ok thanks

[AndrewBelt]

The ./configure step for mpg123 with mingw cross-compile from Linux doesn't work, so I'm removing this from repos/

[sebastien-bouffier]

Ok. Do you have kept the error message so I can try to fix it ?

[AndrewBelt]

I don't have it anymore, but the reason is clear. autoconf for some reason always has tons of tests that it runs before building the Makefile. This makes it impossible to make cross-builds from a different operating system that can't execute the binaries it's building.

This is why I've resisted Docker, because cross-builds are never the same as builds on an actual platform. However, I don't yet have the infrastructure to make builds on a VM or host OS's.

A solution is to try to adopt the library's .c and .cpp files into your own build system.

[sebastien-bouffier]

Ok thanks for all those informations

[sebastien-bouffier]

Hello, to keep you informed, I tried to include mpg123 but I failed, it is over my skills for the moment. I tried with libmad ... I failed too :) I tried minimp3 which is a single header decoder but I did not manage to go away from artifacts etc ... So ... I give up that project for the moment. Maybe when I will have more time I will try again. I pushed some new features on dTrOY so I am in 0.6.3 now. Could you just update the version number on the plugins page or is it automatically linked to builds ? Best

Last version information Version: 0.6.3 Branch: master Commit : 6001cc59eb22fdaaae108a3b6fb2a4263b3a6f4a

[lieff]

@sebastien-bouffier I have guess why you failed with minimp3. Minimp3 do not have internal buffer to combine mp3 frame (to be small), application must provide buffer with at least one mp3 frame. So, for streaming mode, wrapper with such buffer is needed, 16kb is recommended (for good sync procedure), or at least 3kb (to hold one mp3 frame of any size).

[sebastien-bouffier]

@lieff thanks for the advice I will give another try with minimp3

[sebastien-bouffier]

@lieff it works like a charm ... the mistake I made was to decode in sync with http frames arrival ... thanks again

[sebastien-bouffier]

Last version information Version: 0.6.6 Branch: master Commit: 06026930d1030840eb0662d63f8906e23d940c53

[mdemanett]

Looks good!

[sebastien-bouffier]

Great, thanks.

[AndrewBelt]

Still can't build because referencing libcurl outside of the plugin directory does not work with the build system or the Rack SDK. Also, Rack 0.6.1 will statically link all libraries, so it will not work after that release.

[lieff]

Is https needed? There much simpler libs for http-only, like https://github.com/jonvaldes/jv_http

[AndrewBelt]

You could wait for Rack 0.6.1 to release and then use Rack's statically included curl without any hassle.

[sebastien-bouffier]

@lieff maybe not, I only use http uris ... even not sure if there are uris in https for mp3 streaming @AndrewBelt do you have an eta for 0.6.1 ?

[lieff]

For statically linked libcurl note that it needs modification for cross-distro linux support. Because certificates location determined at configure time, it must be moved to code.

[AndrewBelt]

@sebastien-bouffier No ETA.

@lieff Rack's curl contains no certificates because certificate validation is disabled currently. https://github.com/VCVRack/Rack/issues/123

[sebastien-bouffier]

Last version information Version: 0.6.7 Branch: master Commit: 209747e261188eade56199be764154b985a29c6d

[mdemanett]

Reviewed and queued up to build again -- fingers crossed it works with 0.6.1.

[sebastien-bouffier]

ok thanks.

[AndrewBelt]

Build error on Ubunut 16.04.

g++ -Wsuggest-override -std=c++11 -DUSE_KISS_FFT -Idep/include -I./src/dep/audiofile -I./src/dep/filters -I./src/dep/freeverb -I./src/dep/gist/libs/kiss_fft130 -I./src/dep/gist/src -I./src/dep/minimp3 -I./src/dep/gist/src/mfcc -I./src/dep/gist/src/core -I./src/dep/gist/src/fft -I./src/dep/gist/src/onset-detection-functions -I./src/dep/gist/src/pitch -DSLUG=Bidoo -fPIC -I/Rack-SDK/include -I/Rack-SDK/dep/include -DVERSION=0.6.7 -MMD -MP -g -O3 -march=nocona -ffast-math -fno-finite-math-only -Wall -Wextra -Wno-unused-parameter -DARCH_LIN -c -o build/src/dep/freeverb/allpass.cpp.o src/dep/freeverb/allpass.cpp
g++ -Wsuggest-override -std=c++11 -DUSE_KISS_FFT -Idep/include -I./src/dep/audiofile -I./src/dep/filters -I./src/dep/freeverb -I./src/dep/gist/libs/kiss_fft130 -I./src/dep/gist/src -I./src/dep/minimp3 -I./src/dep/gist/src/mfcc -I./src/dep/gist/src/core -I./src/dep/gist/src/fft -I./src/dep/gist/src/onset-detection-functions -I./src/dep/gist/src/pitch -DSLUG=Bidoo -fPIC -I/Rack-SDK/include -I/Rack-SDK/dep/include -DVERSION=0.6.7 -MMD -MP -g -O3 -march=nocona -ffast-math -fno-finite-math-only -Wall -Wextra -Wno-unused-parameter -DARCH_LIN -c -o build/src/dep/gist/src/Gist.cpp.o src/dep/gist/src/Gist.cpp
In file included from src/dep/gist/src/Gist.h:39:0,
                 from src/dep/gist/src/Gist.cpp:24:
src/dep/gist/src/mfcc/MFCC.h:94:70: error: 'size_t' does not name a type
     void discreteCosineTransform (std::vector<T>& inputSignal, const size_t numElements);

Are you missing an #include <stdlib.h> in MFCC.h or using std::size_t or something?

[sebastien-bouffier]

Last version information Version: 0.6.7 Branch: master Commit: c8c608814409e8b84265b1898315efca37eab348

Hello I added the include since it looks like 'size_t' is an unknown type, but I am not able to ensure it will fix the issue since my previous commit was building fine under Win 10 and my Linux VM under budgie-desktop 10.4

[AndrewBelt]

Works great, updated build. Probably should be reported upstream in gist.

[sebastien-bouffier]

Great, thanks.

[AndrewBelt]

Spoke too soon. The plugin fails to load on Linux.

[0.077 warn src/plugin.cpp:90] Failed to load library /home/vortico/.Rack/plugins/Bidoo/plugin.so: /home/vortico/.Rack/plugins/Bidoo/plugin.so: undefined symbol: curl_easy_perform

No idea why. The symbol is clearly statically linked in Rack.

[AndrewBelt]

Looks like the SDK is platform-dependent because of curl's OS-specific headers, fantastic. Easy fix for me, but this makes plugin development more difficult for others, since they now technically have to juggle three SDKs.

PSA for C/C++ developers of projects like libcurl: Please do not generate code. Code is for humans to write, not computers.

[AndrewBelt]

Turns out curl doesn't generate headers thankfully.

I tried building this locally, and it still doesn't work. What OS's have you tested this on? Doesn't even seem to work on Mac when built locally.

Removing build.

[sebastien-bouffier]

Haaaa ... nightmare. I tested the build under my Lin VM but not the execution .. only under Win 10 which is my main OS. I will test it under my Linux VM under budgie-desktop 10.4

[sebastien-bouffier]

Make dist under WIN 10 against Rack SDK => OK Copy Bidoo dist in documents/Rack etc.. Run Rack => plugins OK Make dist under budgie-desktop 10.4 (Ubuntu if I am correct) against Rack SDK => OK Copy Bidoo dist in Rack/plugins etc.. Run Rack => plugins missing

So I decided to checkout Rack under budgie-desktop 10.4 to perform a "make debug" when loading my pack Cloned Rack repo + update deps + make dep etc ... I have errors building Rack ... can't view #include "nanovg.h" So I add FLAGS += -Idep\nanovg\src then can't view nanosvg.h so I add FLAGS += -Idep\nanosvg\src, then blendish then etc .... so I end up adding osdialog, rtaudio etc .. But it still fails on linking ... cannot access lrtaudio

I think that my Lin VM might be f***up => I will have to clean everything and restart from scratch. I will post updates in coming days but due to workload + concerts with my band I won't be hyper reactive.

Thanks a lot for your help.