Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

5 participants
7515 discussions

by Aurélien Leblond

>> Well all the plugins in ams.lv2 are coded in c++ and are compiled with the >> c++11 standard. >> But when ported the FFT Vocoder, it only compiles when using the c99 >> standard. > C and C++ complex types are not compatible for C++, not even if > they have the same binary representation as they will have for > all modern C++ compilers. > You can probably fix some of these errors (at least the first > one) by including <complex.h> (not <complex>) before <fftw3.h>. > This will make fftw use the C native complex type instead of > its own. This will allow float to complex assignment for > example. > If you really want a 'pure' C++ version you will need to > reinterpret_cast whenever you use a function that expects > or returns a C++ complex. It won't make your code any more > readable. > IMHO the C++ complex type (a template class trying to hide > its implementation) is completely useless and a real PITA, > and a good example of the pedantic attitude that is typical > of the C++ crowd. > Nobody with even just a minimal knowledge of scientific > computing would want to hide the implementation of complex > types - almost all classical algorithms (e.g. the FFT) > depend on it being cartesian. What would you advise? As far as I can see I have 2 options: - Port the code to the c++11 standard - but you seem to think that's a bad idea - Compile this plugin with C99 - that's the solution I have in the git at the moment but I get the warning "cc1plus: warning: command line option ‘-std=c99’ is valid for C/ObjC but not for C++ [enabled by default]" and call me pedantic but I don't like warnings! Would you know how this is handled in AMS (being c++ as well)? I did check the code but I can't figure it out and I would like to stay as close as possible to the actual Alsa Modular Code so it's easier when futur modifications are applied to the code. > A second source of problems with the vocoder is the mixing > of floats and doubles. There is no good reason to use a > double FFT here. I actually did notice that, but again I don't want to "correct" it in ams-lv2 because my aim here is to port "as-is". I made the mistake of adapting the code when I ported the first set of plugins but realised that was a mistake for maintenance when syncing with changes in ams

10 years, 9 months

Re: [LAD] fftw_complex and C++11

by Aurélien Leblond

> > > Hi all, > > > > I'm porting the FFT Vocoder from AMS to ams.lv2. > > The FFT Vocoder is using fftw_complex, and I can compile my code if I use > > -std=c99 but not if I use -std=c++11 > > > > I get error like: > > > > error: incompatible types in assignment of ‘float’ to ‘fftw_complex {aka > > double [2]}’ > > modinforward[l2] = modbuf[l2] * window[l2]; > > > > error: cannot convert ‘double*’ to ‘__complex__ double’ for argument ‘1’ > to > > ‘double creal(__complex__ double)’ > > p(p_modulatorfft)[l2] = logf(fabs (creal (modoutforward[l2])) + 1.0); > > > > error: invalid array assignment > > modinbackward[ lclfrq ] = modoutforward [l2]; > > > > carrinforward, carroutforward, carrinbackward, > > carroutbackward, modinforward, modoutforward, modinbackward, > modoutbackward > > are pointers to fftw_complex. > > > > > > Would you guys have any idea why it doesn't compile in the c++11 > standard? > >>From my research I saw there were some changes between c99 and c11 with > > complex numbers, but I can't figure out how to bring the code to C++11. > > > > Just to make sure I understand correctly. Your goal is to rewrite the > code from c99 to c++11 and not c11? > > Well all the plugins in ams.lv2 are coded in c++ and are compiled with the c++11 standard. But when ported the FFT Vocoder, it only compiles when using the c99 standard. So I guess yes, I would like to rewrite the code from c99 to c++11.

10 years, 9 months

fftw_complex and C++11

by Aurélien Leblond

Hi all, I'm porting the FFT Vocoder from AMS to ams.lv2. The FFT Vocoder is using fftw_complex, and I can compile my code if I use -std=c99 but not if I use -std=c++11 I get error like: error: incompatible types in assignment of ‘float’ to ‘fftw_complex {aka double [2]}’ modinforward[l2] = modbuf[l2] * window[l2]; error: cannot convert ‘double*’ to ‘__complex__ double’ for argument ‘1’ to ‘double creal(__complex__ double)’ p(p_modulatorfft)[l2] = logf(fabs (creal (modoutforward[l2])) + 1.0); error: invalid array assignment modinbackward[ lclfrq ] = modoutforward [l2]; carrinforward, carroutforward, carrinbackward, carroutbackward, modinforward, modoutforward, modinbackward, modoutbackward are pointers to fftw_complex. Would you guys have any idea why it doesn't compile in the c++11 standard? >From my research I saw there were some changes between c99 and c11 with complex numbers, but I can't figure out how to bring the code to C++11. Thanks in advance for the help, Aurélien

10 years, 9 months

Re: [LAD] [LAA] CLAP, new virtual instrument and effect plugin interface proposal

by Florian Paul Schmidt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.01.2015 12:48, Alexandre Bique wrote: >> 3] It would make plugin development easier if it was required to >> call deactivate() on a plugin before clap_destroy'ing it. The >> additional burden on the host would be small. Is there a good >> reason for it to be this way? > > I did it this way for robustness reasons. Because even if the host > has a bug in his destroy code path and forgets to deactivate, the > plugin must handle this case correctly. OK, let me put it this way. It really is a number's game. Let's take a successfull plugin standard like VST. There's thousands, maybe tens of thousands of plugins, but maybe tens to hundreds of hosts. So there's an order of magnitude or two difference. Every plugin has to have this extra check. What are the chances that a few plugin authors forget to do this check? What are the chances that a few hosts get this wrong? What are the chances that plugins get fixed? What are the chances that hosts get fixed? Also it's just boilerplate code. If every plugin has to do it, then it shouldn't have to do it at all since it clearly can be automated. And the automation in this case is just the host calling deactivate before destroy. Give the plugin authors as much guarantees as possible. With the proposed way around plugins might work in some hosts that honour the standard, but not in others (I.e. ones that do call deactivate() before destroy() vs. those that do not). If you make calling deactivate() before destroy() a requirement this whole problem just goes away. It makes life easier for the plugin developer while not making life _much_ harder for the host dev. Also it's trivial to implement a test plugin for host devs to use that checks things like this - one that does basically just copy input to output but checks that lifecycle requirements are met by the host: - - abort() on calling process() before activate - - abort() on calling destroy before deactivate() - - etc.. Have fun, Flo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUp/nYAAoJEA5f4Coltk8Zk+AH/0mnqvtw09iw2Mccyj4UTzBY xgm7n0i9N664e2qk2a0JrmRs/gOxAy1ddMGiNbXzgfI+mMqdh1XRlIgm0APcu+mK xAyxsYQuNVM88wq1kVVETAve/dvdAqMVYFkwViR5a7HlPPZVzj0vAsbAJT8HNWE3 O9oayGVDkzvY30ax13ktrFGSiMgiY1qEZq9DhapxTSwr929LnIGHzCWNSEXTepxi iSF/5k4j61V/zEFCNjL1/gHOdvANwKTbSQTXcNUY8RrbiR6vU18H/7wEypIbNI9a 4s4lHdzw4paAcIuj/Xvjqc8NUGi67z6BGRKqDU9y6jPg99T7vqX4lFCIScFV2go= =0gbu -----END PGP SIGNATURE-----

10 years, 9 months

Re: [LAD] [LAA] CLAP, new virtual instrument and effect plugin interface proposal

by Florian Paul Schmidt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sending this to LAD (additionally to replying to the author directly) as I cannot post answers to LAA and maybe it's interesting to keep this discussion on LAD.. On 29.12.2014 16:48, Alexandre Bique wrote: > Hi, > > I worked on a new plugin interface, it is not yet finished and set > in stone, but ready enough to gather initial feedback and advice. > > The specification is hosted on github: > https://github.com/free-audio/clap and is available under the MIT > license. There is a generated specification document at: > http://free-audio.github.io/clap/ > > I hope that you'll find it interesting and give it a chance. > Thanks. > > Regards, > Hi, I'm just skimming over the generated docs. Generally it's a laudable effort but maybe a few years too late. I guess many people in the linux audio community would agree that there is no lack of plugin standards :) Some remarks: 1] The generated docs display rather badly in my browser as I cannot move the separator between the two "lanes" which results in the left one not being readable at least partly. http://i.imgur.com/4MhRWvf.jpg (yes, this is a two monitor setup with an upright 4:3 monitor on the left :)) 2] It would be cool if clicking on a function name in the left panel would take you to the function declaration in the right panel. E.g. clap_create. 3] It would make plugin development easier if it was required to call deactivate() on a plugin before clap_destroy'ing it. The additional burden on the host would be small. Is there a good reason for it to be this way? 4] The plugins collection query mechanism (with index 0) seems a little "hackish". Why not have extra functions for it? 5] tunning -> tuning (spelling) 6] Adding to 3]: Change some of the "should not" to "must not" as it would make the API semantics clearer. Example: "Also deactivate() should not be called if the plugin is not activated. Yet the plugin should handle a call to deactivate() even if it is not activated." How should it handle it? It would be simpler to just make this a "must not". Little additional burden on the host while making every single plugin easier to implement and less error prone.. That's it for now (it's how far I got into reading the spec). Have fun, Flo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUp8xtAAoJEA5f4Coltk8ZCogIALDFJMjfOrg3jeGrp6IB6dk/ 3LvICyE53XrdjZsBqbETAPY6LAIf5HOwuoyU8JbBPECirILKM0T5diK/+G9CMTJL gx93UTWkdWVFivVI79y5Rys+Fj3fRBpknBXttplATBohIeMWvam8ey2F5/6UN82H y3IVPp+y9CXsEZ6Ekv/Z25S5FWlBQ7X2mdojafWnxk8euJedPSAUFF3248LHvAaX oeNZkMX7KANlw+3r/8R0mOhez/Z1p016Q5/Ckc1U/t6kHoAeSHNSDmL1ONS/0hzL VEcVHjLoxSDpW3D2NksKtkTK6w98xHS7BQtG9Rm8c2h0ReA6JWXunE2MClbltVI= =jS92 -----END PGP SIGNATURE-----

10 years, 9 months

minos-one_v1.1

by Joël Krähemann

Hello everybody, please take a look at http://sourceforge.net/p/ags/files/minos-one_v1.1.iso It targets mainly users interested in gobject and gtk+ based applications. minos-one starts as default within openbox and proper systemd usage. It should be entirely based on Free Software, please report inappropriate content. Since threads aren't really reliable in `ags` me has some difficulties to get a screencast because system freezes and no input possible, but take a look at my google+ page of Advanced Gtk+ Sequencer - Linux 3.14.25-rt22 - Advanced Gtk+ Sequencer 0.4.2-21 - Swami - fluidsynth - LADSPA - ffmpeg - mplayer - wine-64 - dssi-vst - bristol - jackd - ...

10 years, 9 months

Alsa Modular Synth - Hysteresis unused control

by Aurélien Leblond

Hi, While porting the new AMS modules into LV2, I noticed the High and Low Offsets controls are not used in the code. I wanted to open a ticket on Sourceforge about it but I don't seem to have the rights to do so. Could this be checked? If you want me to create a patch to remove references to these 2 controls, please let me know. Aurélien

10 years, 9 months

minos-one fixed live DVD

by Joël Krähemann

Hi out there Download the enhanced ISO image of minos-one http://sourceforge.net/projects/ags/files/minos-one.iso

10 years, 9 months

Live DVD including Advanced Gtk+ Sequencer and Swami

by Joël Krähemann

Hi all, please take a look at https://sourceforge.net/projects/ags/files/minos-lxdm.iso and https://sourceforge.net/p/ags/blog/2014/12/live-dvd-including-advanced-gtk-… best regards Joël

10 years, 9 months

Some things to play with during the Xmas holidays

by Fons Adriaensen

Hello all, The first release of pyjacktools is now available at <http://kokkinizita.linuxaudio.org/linuxaudio/downloads> Python C++ extensions and classes for audio. I wanted to demo these during the Audio Measurements workshop at LAC 2014, but we ran out of time... AudioFile Read/write audio files to/from numpy arrays. Reads anything libsndfile can read, and writes wav, wavex, amb, aiff, caf and flac, any number of channels. JackControl Simple Jack client allowing to connect arbitrary ports and control Jack transport. JackPlayer Multichannel (up to 64) audio file player. The interface is deliberately kept low level, but it's easy to create derived classes providing a higher level interface. This is the player used in the automated systems at La Casa del Suono in Parma. JackSignals Generate and capture arbitrary test signals from/to numpy arrays. Combined with numpy, matplotlib, pyqt, etc. this can be used to create anything from a simple measurement to sophisticated automated test systems. All four classes are documented using Python docstrings (use Python's help function to read these). Some simple examples are provided as well. The C++ extenstions should work with either Python 3.x or 2.7. The Python code is tested using Python 3.4, but will probably work even with 2.7. If not the required changes should be minimal. To install you need the Python setuptools, then just make and sudo make install. The examples require numpy and for some also matplotlib. Enjoy ! -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

10 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev