• Pierre Guillot

    Great work! And your videos are so cool :)

    posted in output~ read more
  • Pierre Guillot

    @Schorschua-Phrosch Yes, indeed. You have to use [receive openpanel] (and not [receive camomile]) to receive the file path. Here is the documentation. And here is a fixed version: Openpanel.pd.

    And as it seems that you use a Windows system, you will encounter the bug 131. I recommend you to use the beta release. Here is the last ones for Windows64 and for Windows32. At last, using your patch with the plugin PdStal just reveals a new bug - it seems there is a conflict with this example.I will fix this for the next release.

    posted in news read more
  • Pierre Guillot

    @Schorschua-Phrosch There are two known issues with the openpanel method of Camomile v1.0.6 (131 and 137). The fixes are ready and will be present in the next release. If you think that your problem is related I can give you a beta release for your OS. Otherwise, fell free to report the bug on Github.
    Cheers,

    Pierre

    posted in news read more
  • Pierre Guillot

    And faustgen~ have to be compiled with the 64 bits floating-point support. I don't know how they managed it on Purr Data but I don't think it's compatible with Pd Vanilla...

    posted in news read more
  • Pierre Guillot

    Yes, there is a link to the pd-faust (faust~) project in the help file and in the legacy section of the readme. I can't list the different features between the two objects, sorry. There are too many little things. I guess the best way would be to try both ;) What I can tell is that faust~ is based on the pure language so you have to install Faust and the pure language but it has the FAUST internal MIDI support and it dynamically creates Pd GUI to control the FAUST engine. What I tried to do with faustgen~ is offer an object easy to install and easy to use (Faust is embedded in the external there is nothing more to install) with the similar features to faustgen~ for Max - but the GUI and the MIDI are not managed by the object you have to patch it with Pd.

    posted in news read more
  • Pierre Guillot

    Since Mac doesn't help the development of 32-bit application (the last Xcode tools don't support it anymore), I think I will drop the 32-bit support of Camomile for MacOS in a near future, and I'll provide a 64-bit version only.

    Would it be a problem for someone?
    Is there anybody using a 32-bit DAW on MacOS?
    In this case perhaps I will split in two separate releases like for Windows. Let me know what you think and if you have any suggestion.

    posted in news read more
  • Pierre Guillot

    @barbouze said:

    Is it possible to circumvent this by putting a faustgen~ into a subpatch with a different sample rate?

    Yes, it should work because each faustgen~ instance is independent.

    posted in news read more
  • Pierre Guillot

    For Windows users, I have just released a fix for a small bug (v0.1.1): the text editor didn't open when you clicked on the object if there was a space in the path of the FAUST file. It's already available on the website and on Deken.

    posted in news read more
  • Pierre Guillot

    A new release v0.1.0 is available on Deken and the Github repository.

    • Add support to preserve parameters values during recompilation
    • Fix autocompilation when DSP instance not initialized
    • Fix support for the double-float-precision option
    • Add support to look for the DSP file in all Pd's search paths
    • Add support to open the FAUST file in the default text editor when object is clicked
    • Add a default locked FAUST file used when no argument is provided
    • Fix minor bugs

    posted in news read more
  • Pierre Guillot

    @weightless In theory, there is no 32/64-bit limitation. I didn't published the 32-bit version because I think most of people use (or will use) Pd 64-bit and it requires more dev, more testing and so on. Anyway, I managed to compile 32-bit versions on Mac and Linux but I didn't achieved to do it on Windows. The system's libraries of the 32-bit version of LLVM that I compiled was not compatible with Pd (perhaps it's my computer or perhapsI did a stupid mistake). Anyway, compiling LLVM last more than 1 hour so, after a couple of tests, I gave up. But if you're familiar with build systems, you can try yourself. All the instruction are on the README.

    posted in news read more
  • Pierre Guillot

    Thanks! And I add that FAUST is really an efficient language for DSP. With FAUST code, you can automatically generate audio plugins (VST, LV2, etc.), a diagram representation of the process, a mathematical documentation, applications for phones, web applications, etc (see the FAUST online compiler). And it is one of the most optimized language for audio. If you have cpu problem: use FAUST!

    PS: I have no share in FAUST inc. ;)

    posted in news read more
  • Pierre Guillot

    Thank you for sharing! I'm really happy to see new creations with Camomile!

    posted in patch~ read more
  • Pierre Guillot

    The CICM and the GRAME are pleased to announce the faustgen~ object for Pure Data.

    Faustgen~ is an external object with the FAUST just-in-time (JIT) compiler embedded that allows to load, compile and play FAUST files within the audio programming environment Pure Data. FAUST (Functional Audio Stream) is a functional programming language specifically designed for real-time signal processing and synthesis developed by the GRAME. The FAUST JIT compiler - built with LLVM - brings together the convenience of a standalone interpreted language with the efficiency of a compiled language. The faustgen~ object for Pure Data is a very first version with elementary features, help and contributions are more than welcome. The faustgen~ object is available for Linux, Mac and Windows (64-bit) via Deken (v0.4.1) or via the github repository: https://github.com/CICM/pd-faustgen/releases.

    We hope that you'll enjoy this project!

    FAUST: http://faust.grame.fr
    GRAME: http://www.grame.fr
    CICM: http://cicm.mshparisnord.org

    posted in news read more
  • Pierre Guillot

    Here are two new videos:
    Camomile v1.0.6 - Demo n°9 - Ping Pong effect using PdStalFx:

    Camomile v1.0.6 - Demo n°10 - Using the script to generate the plugins on MacOS:

    posted in news read more
  • Pierre Guillot

    I'm pleased to announce the new Camomile release 1.0.6.

    This new version includes several great new features:

    • Add support for the LV2 format thanks to the work of Filipe Coelho that created an interface for the LV2 format with JUCE.
    • Add a new plugin example PdStalFx that allows to dynamically load patches. It can be used in a similar way to the first Camomile versions (v0.0.1 to v0.0.7).
    • Add support for naming the audio buses, so you can name the first bus "MainBus" and the second bus "SideChain", for example.
    • Add script for Linux and MacOS that speeds up and facilitates the generation of the plugins.

    And many other improvements and bug fixes:

    • Fix MIDI channels correlation between Pd (0-15) and Juce (1-16)
    • Fix buses with no-channels (for Debug mode only)
    • Improve console for concurrent access
    • Remove LibWebKit on Linux plugin for better Ardour and Carla Support (#116)
    • Fix text ellipsis of the number boxes and the symbol box
    • Add support for bypass parameter/manual bypass in the patch (#108)
    • Fix param.get abstraction for the first value (using a default value)
    • Improve the IEM/atom GUIS label rendering (#118)
    • Fix invisible comments in subpatches and abstractions (#120)
    • Improve font size rendering
    • Add Fuzzy tests using pluginval on the Travis CI
    • Fix the margins of the main patch

    I hope you will like this new release! As always, feel free to give feedback, to submit bugs and to request new features!

    I would like to thanks all the people that helped me for the development and especially Filipe Coelho and Alfonso Santimone! Thanks for your help!

    Few words about the support for external libraries as this feature is highly requested. I didn't forget but for the moment I don't have any solution that seems usable and sustainable. You can read this discussion for further information: https://forum.pdpatchrepo.info/topic/11242/camomile-v1-0-1-an-audio-plugin-with-pure-data-embedded/13.

    And few words on the future of project. I will continue this project but, for many reasons (that are good news), I will unfortunately have less time to work on it after this summer. That's why I tried to document the project and to simplify the compilation process. If anybody wants to join me on the Camomile development, it would be great and I'll be really pleased to help for this.

    Cheers,
    Pierre

    posted in news read more
  • Pierre Guillot

    @alfonso.santimone said:

    So i guess i have to remove directly from the external code all the static variable, so basically remove the "static" keyword from the variable declarations.

    No, if there are static variables (except the static variable for the class that is managed by Pd) you must find a way to avoid them. For example you can use variables in your object structure.

    How can i compile libpd as a .lib/.so/.a and not .dll?

    The libpd version in the Camomile repository generates the static library. You only need to follow the instructions.

    Should i use those flags in the various makefiles or just as a fleg in the command line? (assuming working with msys2 on Win64)

    If you include the external sources to libpd, you should not have to use the makefiles and the right flags will already be defined.

    So it's enough to use a x64 compiler and a x64 target?

    For the 64 bit target yes.

    How to include the static pthread lib for Win compilation? You mention it the Camomile build process readme.

    You have to compile it. There are several way to do it so I don't want to impose one way to do it but you can have a look at the Appveyor file https://github.com/pierreguillot/Camomile/blob/dev/v1.0.6-lv2/appveyor.yml or in the Camomile directory do

    git clone -q https://github.com/GerHobbelt/pthread-win32.git Dependencies\PthreadWin32
    cd Dependencies\PthreadWin32
    sed -i 's/4820;4668;4255;/4820;4668;4255;4711;4100;4312;4127;4296;4456;4619;4310;4311;/' pthread_lib.2015.vcxproj
    sed -i 's/MultiThreadedDLL/MultiThreaded/' pthread_lib.2015.vcxproj
    sed -i 's/MultiThreadedDebugDLL/MultiThreadedDebug/' pthread_lib.2015.vcxproj
    msbuild pthread.2015.sln /t:pthread_lib /nologo /verbosity:quiet /p:Configuration=Release /p:Platform=%PLATFORM% /p:OutDir=lib
    

    posted in news read more
  • Pierre Guillot

    Hi @alfonso.santimone

    I argue that adding external is just a matter of incorporating them in libpd.dll. Am I right?

    Yes but the libpd used by Camomile is the static library (.lib/.so/.a) that why libpd is embedded in Camomile.

    1. In fact, I guess that some of the external libraries are already compatible with multiinstance support because it depends on what parts of the Pd API the libraries use. But to ensure the multiinstance support you must use the C flags -DPDINSTANCE=1 (and -DPDTHREAD=1) while compiling the library or libpd and avoid all the static variables (except if they use thread local storage and you ensure to init them well on each thread). Here is one of the 1st posts by Miller about it: https://lists.puredata.info/pipermail/pd-dev/2017-04/020980.html

    2. The same way you did it for the "standard" approach.

    3. Including an external library with libpd is pretty straightforward (as long as, in this case, the library has the multiinstance support). See this: https://github.com/libpd/libpd/wiki/Adding-Pure-Data-external-libraries-to-your-project. And if a library is included in libpd it will also be included in Camomile.

    So you also have to compile libpd then Camomile (all the instructions are on the Github repository - I updated it a week ago https://github.com/pierreguillot/Camomile/tree/dev/v1.0.6-lv2#compilation - or just do the same steps as on Travis and Appveyor and I can help if needed).

    Cheers

    PS: Another approach would have been to ship the libpd dynamic library next to each plugin. i need to try this but I afraid that, on Windows and Linux, the DAW think that the libpd library is another plugin try to load it.

    posted in news read more
  • Pierre Guillot

    @gusadel Hi Gus. Thanks! No it's not possible to load dynamically externals (compiled objects) but you can load abstractions. There are two main reasons:

    • I don't know if it's the DAW or if it's the APIs of the plugins but the dynamic loading of libraries is restricted. There are ways to get round this problem but it's a bit tricky.
    • Most of the externals objects don't have the multi-instance support so you have to re-compile the object with the multi-instance.

    A solution would be to include some external libraries directly in Camomile but I'm still a bit afraid of the durability of such approach. Furthermore, depending on the library it could requires a lot of developpement and I'm already pretty busy with the basic functionnalities and the support for the several formats and operating systems.

    But if anybody would like to work on some kind of Camomile-extended, I'll be pleased to help him!

    Cheers

    posted in news read more
  • Pierre Guillot

    Here's a short demo video of the last plugin I'm working on: Space VBAP - an implementation of the Vector Base Amplitude Panning for sound spatialization. It's still a work in progress but you can see some of the new features such as the dynamic graphical interface or the adaption to the input/output layouts submitted by the digital audio workstation.

    I hope you'll enjoy!

    posted in news read more
Internal error.

Oops! Looks like something went wrong!