Hi,
I found this old thread about watermarking.
http://linux-audio.4202.n7.nabble.com/Looking-for-Audio-Watermarking-Advice…
I have a potential use for watermarking that is entirely above board and
completely within the realms of open source technology while also being
business friendly at the same time.
It's a potential solution to an AV sync issue where there are no other
hardware sync solutions available (BLE, NFC, wifi, etc...)
The host environment has ONLY audio and video hardware installed. In this
situation it has been suggested that watermarking could allow syncing an
audio track located on a mobile device with the main audio stream that is
playing on speakers in the display room.
Obviously the success of this solution is entirely dependant on the
response of the mic->signal processing->output chain. I don't think
Android devices will be viable in this situation ;-)
However I thought it might be interesting for some people here as a
counterpoint to the more sinister use of audio watermarking. The
processing algorithm could be 100% open source.
--
Patrick Shirkey
Boost Hardware Ltd
[Sorry for cross-posting, please distribute.]
Linux Audio Conference 2015 - Call for Participation
(Due to exceptional circumstances, this announcement comes a bit late,
so please note the early deadline of Feb 1st for submissions. We
apologize.)
We are happy to announce the next issue of the Linux Audio Conference
(LAC), April 9-12, 2015 @ JGU | Johannes Gutenberg University, in
Mainz, Germany.
http://lac.linuxaudio.org/2015/
The Linux Audio Conference is an international conference that brings
together musicians, sound artists, software developers and researchers,
working with Linux as an open, stable, professional platform for audio
and media research and music production. LAC includes paper sessions,
workshops, and a diverse program of electronic music.
*Call for Papers, Workshops, Music and Installations*
We invite submissions of papers addressing all areas of audio processing
and media creation based on Linux and other open source software. Papers
can focus on technical, artistic and scientific issues and should target
developers or users. In our call for music, we are looking for works
that have been produced or composed entirely/mostly using Linux and
other open source music software.
The online submission of papers, workshops, music and installations is
now open at http://lac.linuxaudio.org/2015/participation
The deadline for all submissions is Feb 1st, 2015 (23:59 HAST).
You are invited to register for participation on our conference website.
There you will find up-to-date instructions, as well as important
information about dates, travel, lodging, and so on.
This year's conference is hosted by the Computer Music Research Group
(Bereich Musikinformatik) at the IKM (Institut für Kunstgeschichte und
Musikwissenschaft) of the Johannes Gutenberg University (JGU) at
Mainz. Being founded in 1991, our research group has been among the
first German academic institutions in this interdisciplinary field at
the intersection of music, mathematics, computer science and media
technology. In our media lab students are working almost exclusively
with Linux, and in our research we are also devoted to contributing to
the growing body of open source audio and computer music software.
http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/
We look forward to your submissions and hope to meet you in Mainz in
April!
Sincerely,
The LAC 2015 Organizing Team
--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef(a)gmail.com
WWW: https://plus.google.com/+AlbertGraef
MusE 2.2 - 2015-01-06
Hi All!
Following our plan of making monthly releases. Ah, I mean yearly releases...
Well, actually, it's been nearly two years since last stable release. Sorry.
Here we are anyway with a new release of MusE, and we think it's a good one!
Since last we have moved to github and Andrew has joined the team to, among
other things implement LV2 support, which he has done excellently. We are
quite happy with the current state and music has been recorded with MusE like
never before, some demonstrations are listed below.
Major feature improvements of this release includes:
* Support for LV2 Synths and effects
- effects are supported both in Effect rack and in Arranger
- State interface
- Worker interface.
- Instance-access.
- KX studio Programs interface + extended programs interface to support
per-channel bank/patch change (only Yoshimi now supports this feature).
- Common must-have features: Atom, buf-size, event, options, uri-map, urid.
+ Other extensions: CV type lv2 ports
+ LV2_TIME__Position
+ Atom_Event_Transfer support for plugin<->UI communication
+ LV2 path MAP and MAKE extensions
+ LV2 LOG extension
- UI interface. Supported UI subtypes:
+ QT4
+ GTK2
+ GTKMM2
+ X11
+ External interfaces (from kx studio specs).
+ idle callbacks
* Yet another MAJOR audio engine and plugin/synth process chain re-write
- Track controllers (vol, pan) now sample-accurate and near noise-less
Numerous bug fixes and minor enhancements:
- Metronome with accent clicks and replaceable clicks
- Synths rearranged in separate menus
- Reworked the PluginDialog to use a ui file and give more filter
possibilities
- Added [HOME] button to file open dialog
- Ignore undo/redo while recording
- Fix crash reported by LakeIshikawa: Pressing delete while clicking or
dragging events or parts
- Fixed copy/paste problem: Paste copies not clones, if the original
parts/tracks have been deleted.
- More commands support Undo/Redo, like setting global tempo.
- Some new scripts, RemoveAftertouch, TempoDelay
- Fix song not 'dirty' on many operations (close was not prompting to save).
- Instrument Editor now basically complete: Added Initialization Sequence
editor.
- Sysex event editor now allows selection from pre-defined Instrument Sysex
list.
- Revised and edited Roland SD-50.idf by Patrick (split into GM2/nonGM2).
- MusE now imports GM2 midi files. (Properly selects GM2 instrument.)
- Added a visual metronome to Bigtime
- Added line drawing of tempo in graphical master track editor
- Fixed bug (issue #342 Moving Aux sends crashes muse)
- Added more keyboard shortcuts in midi editors
- Mods/fixes to Midi Input Transformator plugin:
- When midi in is enabled in drum editor the selected track is moved along
with the triggered key
- Fixed bug with playback of drums clicking on notes in the new drum editor,
it was playing the wrong instrument
- MESS synths (esp Deicsonze): Controls (like Track Info program) and synth
controls now mirror each other, both ways.
- Deicsonze softsynth: Fixed: Not remembering settings + ladspa plugin
settings, midi controllers moved to NRPN14 type.
- Native VST: Call idle periodically. Makes some plugins like Glitch work,
as per LAD mail.
- Change window title when there are unsaved changes
- Add auto-save feature, when enabled tries to save after 5 minutes
- Added pitch control to SimpleDrums, first version
- Fixed Ctrl+arrows in the arranger so the track list is scrolled
For more information and additional changes see the full changelog at:
https://github.com/muse-sequencer/muse/blob/muse_2_2/muse2/ChangeLog
News section:
http://muse-sequencer.org/index.php/News
Download:
http://muse-sequencer.org/index.php/Download
Demos page:
http://muse-sequencer.org/index.php/Demos
Forum:
http://muse-sequencer.org/forum/
Happy new year from the MusE Team!
>> 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
>
> > 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.
-----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-----
-----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-----
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
- ...