planet.linuxaudio.org

August 31, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Drumstick 1.0.0 Released

From: Pedro Lopez-Cabanillas <pedro.lopez.cabanillas@...>
Subject: [LAA] Drumstick 1.0.0 Released
Date: Aug 31, 3:56 am 2014

Drumstick is a set of MIDI libraries using C++/Qt5 idioms and style. Includes
a C++ wrapper around the ALSA library sequencer interface: ALSA sequencer
provides software support for MIDI technology on Linux. A complementary
library provides classes for processing SMF (Standard MIDI files: .MID/.KAR),
Cakewalk (.WRK), and Overture (.OVE) file formats. A multiplatform realtime
MIDI I/O library is also provided.

Changes:
* migration to Qt5.
* new library: drumstick-rt for multiplatform realtime MIDI I/O.

Copyright (C) 2009-2014, Pedro Lopez-Cabanillas
License: GPL v2 or later

Project web site
http://sourceforge.net/projects/drumstick

Online documentation
http://drumstick.sourceforge.net/docs/

Downloads
http://sourceforge.net/projects/drumstick/files/

_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 31, 2014 04:00 AM

[LAA] Luppp 1.0.1 Bugfix release

From: Harry van Haaren <harryhaaren@...>
Subject: [LAA] Luppp 1.0.1 Bugfix release
Date: Aug 31, 3:55 am 2014

Hey all,

OpenAV is pleased to announce the Luppp 1.0.1 bugfix release!
Webpage: http://openavproductions.com/luppp/#release
Github: https://github.com/harryhaaren/openAV-Luppp/releases/tag/release-1.0.1

Features added:
-Metronome has seperate JACK port
-Play / Stop functionality for transport
-Arrow keys on keyboard move special clip
-Keyboard capitals clears clips
-Updated icon / integration

Bugs fixed:
-JACK timebase master BPM / BBT fixed
-Fixed packaging issues
-Ogg file loading available
-Preferences file auto-written

Merge requests thanks:
-AutoStatic
-Florian Paul Schmidt
-katacarbix
-keszybz

Packages, feel free to work your magic if/when you have time :)
Cheers, -Harry of OpenAV.
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 31, 2014 04:00 AM

August 29, 2014

Create Digital Music » Linux

Free Patching Tool Pd (Pure Data) 0.46 Released: Native OSC, Jack

pdkinect

Pd: Ugly. Hugely useful. Free.

The open-source, free graphical patching environment can do everything from simple MIDI tasks to building synths and effects to advanced multimedia. And because it’s free software, it’s also been adapted to run places other tools can’t – it’s been used in commercial iOS apps with millions of downloads (via libpd), and will run happily on a Raspberry Pi or even a hacked e-reader or ancient iPod.

Contrary to popular belief, it’s also getting a healthy stream of updates. And while those usually don’t merit specific mention, 0.46 is very cool. (It’s the “vanilla” version, so perfectly suited to work with libpd for iOS, Android, and game development, among other things.)

New in this release:

  • Native OSC (Open Sound Control) support. oscformat, oscparse objects now does OSC over UDP. (TCP, USB, etc. still require the slip encoder/decoder by mrpeach.)
  • Built-in support for Jack (inter-app audio, etc.) on OS X.
  • No more manually setting up devices: “Audio and MIDI devices saved by name so that when they get switched around Pd has a better chance of restoring settings correctly.”
  • New string support: ,
  • Netsend/netreceive bi-directional TCP support. (Overdue – thanks!)

And of course the usual bug fixes and improvements.

Having OSC support built-in was for most of us doing run-of-the-mill stuff the last remaining obstacle to using Pd across mobile and desktop, so that’s really nice. And now is a good time to say, don’t bother with puredata.info for the vanilla version. Instead, grab via Git:

git clone git://git.code.sf.net/p/pure-data/pure-data
cd pure-data
git checkout

Or just download here:
http://msp.ucsd.edu/software.htm

The obvious comparison to Pd is Max/MSP – the two tools share the same lineage, the same original creator (Miller Puckette), lots of concepts and object names, and even some code. But they’re best thought of as very distinct tools, in increasingly different directions. Max is a much bigger program, apart from costing some money; that’s what allows it to do things like let you patch with DSP code (which can now be exported), or work with Ableton Live. Pd is free and lightweight, a more canonical vision of what the Max/Pd family would be, and as a result can run in environments where Max can’t. I find I enjoy working with each, and switching between the two feels really strangely different, even if familiarity with one can help with the other.

Worth revisiting this film of a Pd event in Nantes for a bit of visual stimulation regarding what Pd can do:

Pure [creative] Data / Stereolux Nantes (29-30 mars 2012) from stereolux on Vimeo.

The post Free Patching Tool Pd (Pure Data) 0.46 Released: Native OSC, Jack appeared first on Create Digital Music.

by Peter Kirn at August 29, 2014 02:12 PM

August 27, 2014

GStreamer News

GStreamer Core, Plugins and RTSP server 1.4.1 stable release

The GStreamer team is pleased to announce a bugfix release of the stable 1.4 release series. The 1.4 release series is adding new features on top of the 1.2 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework that contains new features. The 1.4.x bugfix releases only contain important bugfixes compared to 1.4.0.

Binaries for Android, iOS, Mac OS X and Windows are provided by the GStreamer project for this release.

The 1.x series is a stable series targeted at end users. It is not API or ABI compatible with the 0.10.x series. It can, however, be installed in parallel with the 0.10.x series and will not affect an existing 0.10.x installation.

The stable 1.4.x release series is API and ABI compatible with 1.0.x and any other 1.x release series in the future. Compared to 1.0.x it contains some new features and more intrusive changes that were considered too risky as a bugfix.

Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, or gst-rtsp-server, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav, or gst-rtsp-server.

Check the release announcement mail for details and the release notes above for a list of changes.

Also available are binaries for Android, iOS, Mac OS X and Windows.

August 27, 2014 05:00 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Yoshimi V 1.2.3

From: Will Godfrey <willgodfrey@...>
Subject: [LAA] Yoshimi V 1.2.3
Date: Aug 27, 12:13 pm 2014

Up on sourceforge now.

It's faster:
Has better compatibility with Zyn:
Has some usability enhancements:
Introduces 'naturalising', a small, configurable, per part random pitch shift:

Kudos to Mark and Paul for an interesting optimisation to Zyn in AddSynth.

At the last minute I heard of a bug in ALSA MIDI where trying to auto connect
resulted in Yoshi bailing out, so from this version onward until I can sort it
out the feature is disabled.

--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 27, 2014 01:00 PM

August 26, 2014

KXStudio News

DISTRHO: New plugins and minor fixing

In this release we bring 4 new Linux plugin ports:
- EasySSP
- LUFS Meter
- Luftikus
- Stereo Source Separator
(Go to http://distrho.sourceforge.net/ports to see the current list of Linux ports.)

The DPF-based plugins also had some minor fixes:
- 3BandEQ/Splitter had its sliders inverted, now fixed
- ProM now has pre-compiled linux binaries; UI can be resized by using - and + keys
- MVerb knobs order has been fixed
- Allow to open UI in LV2 hosts that don't support options feature (Ingen)
- Workaround for some VST hosts that don't set sample rate during init (Ardour3 and energyXT)

by falkTX at August 26, 2014 10:18 PM

August 25, 2014

GStreamer News

GStreamer Conference 2014 schedule of talks available now

The GStreamer team is pleased to announce that the schedule of talks for this year's GStreamer Conference is now available on the GStreamer Conference website.

The GStreamer Conference takes place on 16-17 October 2014 in Düsseldorf (Germany), alongside LinuxCon Europe, the Embedded Linux Conference Europe, and the Linux Plumbers Conference.

Topics covered include GStreamer on embedded systems, set-top boxes and mobile platforms; testing, tracing and debugging; HTML5, WebRTC and the Web; Wayland, 3D video and OpenGL; secure RTP and real-time streaming; adaptive streaming (HLS, DASH, MSS); latest codec developments; and multi-device synchronisation.

There will be two parallel tracks over two days, and a social event for attendees on the Thursday evening.

All talks will be recorded by Ubicast.

We hope to see you in Düsseldorf in October!

The GStreamer Conference 2014 is sponsored by Google.

August 25, 2014 03:00 PM

August 22, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] xjadeo 0.8.0

From: Robin Gareus <robin@...>
Subject: [LAA] [ANN] xjadeo 0.8.0
Date: Aug 22, 2:15 pm 2014


Xjadeo is a video player that displays a video-clip in synchronized to
an external time source (MTC, LTC, JACK-transport).

http://xjadeo.sf.net/

-=-

Greetings Soundtrack Designers and fellow Multimedia Artists,

Xjadeo version 0.8.0 just came out and brings a lot of significant
changes. Most notably:

* openGL display
* video-frame indexing
* built-in UI / context menu

With openGL, video-scaling is now performed in hardware and playback
synchronized to the screen's vertical refresh (if the hardware permits
that; most graphics cards do). This is the new default display and
supersedes prior platform-specific video outputs (XVideo, X11/imlib2,
SDL, quartz, which are still available via the --vo option and also used
a fallback).

Video files are now scanned and indexed on load which provides for
reliable seeking to video frames for a wide variety of codecs where
frame-accurate seeking was not possible with earlier versions of xjadeo.
This also acts as a guard to detect and refuse broken video files early on.

User interaction has been overhauled, most notably by adding a menu that
facilitates discovering key-bindings. This deprecates the external
control application qjadeo which previously came with xjadeo.


There have been over 200 changes since the last release, the complete
changelog is available at https://github.com/x42/xjadeo
Other highlights include:

* separate On-Screen-Display for Sync-Source and Video Timecode
* self-documenting OSC API
* disable screensaver
* 64 bit timeline
* new website

Note that various command line options have changed. The seek-related
-K, -k parameters are no longer needed due to the change to indexing.
Letterbox is enabled by default, and it is now also possible to start
xjadeo without an initial file. In short, a lot of defaults have been
updated to make xjadeo more topical (despite that fact the the menu for
the X11 variant is plain old toolkit-less Xlib :)


Statically linked binaries are available for GNU/Linux, OSX and Windows
from http://xjadeo.sourceforge.net/download.html as is the source code
in terms of the GPLv2.

xjadeo is developed and has been tested for accuracy with ffmpeg-2.2.5
it may or may not work properly with different versions, but compiles
with any version of ffmpeg >= 1.0 to date.

Many thanks to Chris Goddard who provided valuable feedback and spent
several weeks on quality assurance and polishing user interaction. We're
far from done on the quest to 1.0, yet 0.8.0 marks a major milestone in
the life of xjadeo.


Cheers!
robin
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 22, 2014 03:00 PM

Re: [LAA] [LAU] [LAD] hrec

From: Egor Sanin <egor.sanin@...>
Subject: Re: [LAA] [LAU] [LAD] hrec
Date: Aug 22, 7:40 am 2014

Hi Silvain

Thanks for trying it out!

On 8/21/14, F. Silvain wrote:
> Hey egor,
> thanks for the new tool. I just installed and ran into this error:
> *** cut ***
> Traceback (most recent call last):
> File "/usr/local/bin/hrec", line 19, in
> from pyeca import *
> File "/usr/lib/python3.1/lib-dynload/pyeca.py", line 46, in
> from ecacontrol import *
> File "/usr/lib/python3.1/lib-dynload/ecacontrol.py", line 77
> print 'c=' + I._cmd
> ^
> SyntaxError: invalid syntax
> *** end ***
>
> I just updated ecasound from git and made sure it compiled with python3.1 .

Yeah at the moment I can only confirm that hrec works when run with
Python2 explicitly. As I mentioned I had problems running it with
Python3. As far as I know, the pyeca python module, which I use as a
bridge between hrec and ecasound, doesn't play well with Python3.

Try installing hrec with python2 explicitly, on Arch Linux it would be
like this:

$ python2 setup.py install
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 22, 2014 08:00 AM

[LAA] [LAD] hrec

From: Egor Sanin <egor.sanin@...>
Subject: [LAA] [LAD] hrec
Date: Aug 22, 7:40 am 2014

Hi folks,

I've been working on and off for the last little while on a command
line recording utility. It's really basic and the code is pretty
ugly. It exists partly because in my lazy search I couldn't find
anything that satisfied my particular need, and also because it was
interesting. I just made a first release, so you could try it if you
like.

The program is called hrec, it's basically a curses front end to a
very limited subset of ecasound's functions.

Code is here:
https://sourceforge.net/projects/hrec/

AUR package is here:
https://aur.archlinux.org/packages/hrec/

I'm planning to do change it soon, but the basics will remain the
same. Mostly I plan to remove the playback functionality, as it's
almost useless -- plenty of other software to do it much better. Also
I need to migrate the code to Python 3, but I'm getting stuck on the
python ecasound bindings. In the couple of (admittedly not very
thorough) attemps I've made I ran into problems with the current pyeca
module. Any advice would be appreciated. Anyway I thought I might as
well release it now and get some feedback.

I hope someone finds hrec useful!

Criticism and insults are also welcome.

Thanks!
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 22, 2014 08:00 AM

linux.autostatic.com » linux.autostatic.com

LAC2014: submission accepted!

My submission for the Linux Sound Night at LAC2014 with The Infinite Repeat has been accepted. The Call for Papers page mentions the term "danceable" so I'm going to focus on that. Making danceable music is quite a challenge for me but it should definitely be doable to produce a solid set, especially now that I'm the proud owner of a Korg Volca Keys. I'm definitely going to integrate it in my current setup as the Volca reacts great on MIDI sent from my workstation. It has some fat sounds that just scream dance floor.


Korga Volca Keys

I'm really looking forward to this year's LAC. It seems falkTX and avlinux are going too, it'd be great to meet these guys in real life!

by Jeremy at August 22, 2014 12:28 AM

August 21, 2014

Libre Music Production - Articles, Tutorials and News

Thank you and welcome aboard!

Since we launched on Sunday, we have had an overwhelmingly positive response. We're really delighted with the fantastic reception and level of interest which demonstrates the need for a community driven project like LMP. Thank you to everyone for all the interest. There is loads more to come so keep checking the site. This is just the beginning.

Coverage

“The new project is a long missing link between experienced Linux audio users and newbies who want hands-on information about libre tools for making music.” - Alexandre Prokoudine, Libre Graphics World

by admin at August 21, 2014 04:48 PM

blog4

Elektronengehirn Germany concerts in August

next Elektronengehirn Germany concerts dates:

24.August Platzhirsch Festival Duisburg performing reqPZ
28. August Kyoto Protocol NK, Berlin performing reqPZ and Octopus, a collaboration with Michael Lyons from Kyoto, Japan

by herrsteiner (noreply@blogger.com) at August 21, 2014 01:11 PM

Hackaday » » digital audio hacks

A Hackable Hi-Fi Audio DSP

DSP 01 Hi-fi Signal Processor

 

Audiophiles tend to put analog systems on a pedestal. Analog systems can provide great audio performance, but they tend to be quite costly. They’re also hard to tinker with, since modifying parameters involves replacing components. To address this, [tshen2] designed the DSP 01.

The DSP 01 is based around the Analog Devices ADAU1701. This DSP chip includes two ADCs for audio input, and four DACs for audio output. These can be controlled by the built in DSP processor core, which has I/O for switches, buttons, and knobs.

[tshen2]‘s main goal with the DSP 01 was to implement an audio crossover. This device takes an input audio signal and splits it up based on frequency so that subwoofers get the low frequency components and tweeters get the higher frequency components. This is critical for good audio performance since drivers can only perform well in a certain part of the audio spectrum.

Analog Devices provides SigmaStudio, a free tool that lets you program the DSP using a drag-and-drop interface. By dropping a few components in and programming to EEPROM, the DSP can be easily reconfigured for a variety of applications.


Filed under: digital audio hacks

by Eric Evenchick at August 21, 2014 02:01 AM

August 20, 2014

Nothing Special

Making an LV2 plugin GUI (yes, in Inkscape)

Told you I'd be back.

So I made this pretty UI last post but I never really told you how to actually use it (I'm assuming you've read the previous 2 posts, this is the 3rd in the series). Since I'm "only a plugin developer," that's what I'm going to apply it to. Now I've been making audio plugins for longer than I can hold my breath, but I've never bothered to make one with a GUI. GUI coding seems so boring compared to DSP and it's so subjective (user: "that GUI is so unintuitive/natural/cluttered/inefficient/pretty/ugly/slow etc. etc....") and I actually like the idea of using your ears rather than a silly visual curve, but I can't deny, a pretty GUI does increase usership. Look at the Calf plugins...

Anyhow, regardless of whether its right or wrong I'm going to make GUIs (that are completely optional, you can always use the host generated UI). I think with the infamous cellular automaton synth I will actually be able to make it easier to use, so the GUI is justifiable, but other than that they're all eye candy, so why not make 'em sweet? So I'll draw them first, then worry about making them an actual UI. I've been trying to do this drawing-first strategy for years but once I started toying with svg2cairo I thought I might actually be able to do it this time. Actually as I'm writing this paragraph the ball is still up in the air, so it might not pan out, but I'm pretty confident by the time you read the last paragraph in this almost-tutorial I'll have a plugin with a GUI.

So lets rip into it:


One challenge I have is that I really don't like coding C++ much. I'm pretty much a C purist. So why didn't I use gtk? Well, cause it didn't have AVTK. Or ntk-fluid. With that fill-in-the-blank development style fluid lends to, I barely even notice that its C++ going on in back. Its a pretty quick process too. I had learned a fair bit of QT, but was forgoing that anyway, but with these new (to me) tools I had a head start and got to where I am relatively quickly (considering my qsvg widgets are now 3 years old and unfinished).

The other good news is that the DSP and UI are separate binaries and can have completely separate codebases, so I can still do the DSP in my preferred language. This forced separation is very good practice for realtime signal processing. DSP should be the top priority and should never ever ever have to wait for the GUI for anything.

But anyway, to make an LV2 plugin gui we'll need to add some extra .ttl stuff. So in manifest.ttl:
@prefix lv2:  <http://lv2plug.in/ns/lv2core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ui:   <http://lv2plug.in/ns/extensions/ui#> .
 
 <http://infamousplugins.sourceforge.net/plugs.html#stuck>
a lv2:Plugin, lv2:DelayPlugin ;
lv2:binary <stuck.so> ;
rdfs:seeAlso <stuck.ttl> .
 
<http://infamousplugins.sourceforge.net/plugs.html#stuck_ui>
        a ui:X11UI;
        ui:binary <stuckui.so>
        lv2:extensionData ui:idle; . 

Thats not a big departure from the no-UI version, but we'd better make a stuckui.so to back it up. We've got a .cxx and .h from ntk-fluid that we made in the previous 2 posts, but its not going to be enough. The callbacks need to do something. But what? Well, they will be passing values into the control ports of the plugin DSP somehow. OpenAVproductions genius Harry Haaren wrote a little tutorial on it. The thing is called a write function. Each port has an index assigned by the .ttl and the dsp source usually has an enum to keep these numbers labeled. So include (or copy) this enum in the UI code, declare an LV2UI_Write_Function and also an LV2UI_Controller that will get passed in as an argument to the function. Both of these will get initialized with arguments that get passed in from the host when the UI instantiate function is called. The idea is the LV2_Write_Function is a function pointer that will call something from the host that stuffs data into the port. You don't need to worry about how that function works, just feel comfort knowing that where ever that points, it'll take care of you. In a thread safe way even.

Another detail (that I forgot when I first posted this yesterday) is declaring that this plugin will use the UI you define in the manifest.ttl. What that means is in the stuck.ttl you add the ui extension and declare the STUCKURI as the UI for this plugin:
@prefix doap:  <http://usefulinc.com/ns/doap#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix lv2: <http://lv2plug.in/ns/lv2core#> .
@prefix ui: <http://lv2plug.in/ns/extensions/ui#> .

<http://infamousplugins.sourceforge.net/plugs.html#stuck>
a lv2:Plugin, lv2:DelayPlugin ;
doap:name "the infamous stuck" ;
doap:maintainer [
foaf:name "Spencer Jackson" ;
foaf:homepage <http://infamousplugins.sourceforge.net> ;
foaf:mbox <ssjackson71@gmail.com> ;
] ;
lv2:requiredFeature <http://lv2plug.in/ns/ext/urid#map> ;
lv2:optionalFeature lv2:hardRTCapable ;
ui:ui <http://infamousplugins.sourceforge.net/plugs.html#stuck_ui> ;

lv2:port [
... 

So enough talk. Lets code.
For LV2 stuff we need an additional header. So in an extra code box (I used the window's):
#include "lv2/lv2plug.in/ns/extensions/ui/ui.h"


It will be convenient to share a single source file for which port is which index. That eliminates room for error if anything changes. So in an additional code box (the Aspect Group's since the window's are all full):
#include"stuck.h"
 
We also will need 2 additional members in our StuckUI class. Do this by adding 2 "declarations" in fltk. The code is:
LV2UI_Write_Function write_function;

and
LV2UI_Controller controller;

And finally in each callback add something along the lines of (i.e. for the Stick It! port):
write_function(controller,STICKIT,sizeof(float),0,&stickit->floatvalue);

This is calling the write function with the controller object, port number, "buffer" size (usually the size of float), protocol (usually 0, for float), and pointer to a "buffer" as arguments. So now when the button is clicked it will pass the new value on to the DSP in a threadsafe way. The official documentation of write functions is here. The floatvalue member of dials and buttons is part of ffffltk (which was introduced in the other parts of this series) which was added exclusively for LV2 plugins. Cause they always work in floats. Or in atoms, which is a whole other ball of wax. Really though, its really easy to do this as long as you keep it to simple float data like a drone gain.

Another important thing you must add to the fluid design is a function called void idle(). In this function add a code block that has these 2 lines:
Fl::check();
Fl::flush();


To help clarify everything here's a screenshot of ntk-fluid once I've done all this. Its actually a pretty good overview what we've done so far:


Possibly the biggest departure from what we've done previously is now the program will not be a stand-alone binary, but a library that has functions to get called by the host (just like in the DSP). This means some major changes in our stuck_ui_main.cxx code.

For the GUI the most important functions are the instantiation, cleanup, and port event. To use NTK/fltk/ffffltk you will need to use some lv2 extensions requiring another function called extension_data but we'll discuss it later. The instantiation is obviously where you create your window or widget and pass it back to the host, cleanup deallocates it, and the port event lets you update the GUI if the host changes a port (typically with automation). We'll present them here in reverse order since the instantiation with NTK ends up being the most complex. So port event is fairly straightforward:
void stuckUI_port_event(LV2UI_Handle ui, uint32_t port_index, uint32_t buffer_size, uint32_t format, const void * buffer)
{
    StuckUI *self = (StuckUI*)ui;
    if(!format)
    {
      float val = *(float*)buffer;
      switch(port_index)
      {
        case STICKIT:
          self->stickit->value((int)val);
      self->led->value((int)val);
      break;
        case DRONEGAIN:
          self->volume->value(val);
      break;
        case RELEASE:
          self->time->value(val);
      break;
      }
    }
}


The enlightening thing about doing a UI is that you get to see both sides of what the LV2 functions do. So just like in the widget callbacks you send a value through the write_function, this is like what the write function does on the other side, first you recast the handle as your UI object so you can access what you need, then make sure its passing the format you expect (0 for float, remember?). Then assign the data corresponding to the index to whatever the value is. This keeps your UI in sync if the host changes a value. Nice and easy.

Next up is the simplest: Cleanup:
void cleanup_stuckUI(LV2UI_Handle ui)
{
    StuckUI *self = (StuckUI*)ui;

    delete self;
}



No explanation necessary. So that leaves us with instantiation. This one is complex enough I'll give it to you piece by piece. So first off is the setup, checking that we have the right plugin (this is useful when you have a whole bundle of plugins sharing code), then dynamically allocating a UI object that will get returned as the plugin handle that all the other functions use, and declaring a few variables we'll need temporarily:
static LV2UI_Handle init_stuckUI(const struct _LV2UI_Descriptor * descriptor,
        const char * plugin_uri,
        const char * bundle_path,
        LV2UI_Write_Function write_function,
        LV2UI_Controller controller,
        LV2UI_Widget * widget,
        const LV2_Feature * const * features)
{
    if(strcmp(plugin_uri, STUCK_URI) != 0)
    {
        return 0;
    }

    StuckUI* self = new StuckUI();
    if(!self) return 0;
    LV2UI_Resize* resize = NULL;


Then we save the write_function and controller that got passed in from the host so that our widgets can use them in thier callbacks:
    self->controller = controller;
    self->write_function = write_function;


Next stop: checking features the host has. This is where using NTK makes it a bit more complicated. The host should pass in a handle for a parent window and we will be "embedding" our window into the parent. Another feature we will be hoping the host has is a resize feature that lets us tell the host what size the window for our plugin should be. So we cycle through the features and when one of them matches what we're looking for we temporarily store the data associated with that feature as necessary:
    void* parentXwindow = 0;
    for (int i = 0; features[i]; ++i)
    {
        if (!strcmp(features[i]->URI, LV2_UI__parent))
    {
           parentXwindow = features[i]->data;
        }
    else if (!strcmp(features[i]->URI, LV2_UI__resize))
    {
           resize = (LV2UI_Resize*)features[i]->data;
        }
    }


Now we go ahead and startup our UI window, call the resize function with our UI's width and height as arguments and call a special NTK function called fl_embed() to set our window into the parent window. It seems this function was created specially for NTK. I haven't found it in the fltk source or documentation so I really don't know much about it or how you'd do it using fltk instead of NTK. But it works. (You can see the NTK source and just copy that function).  Once that's done we return our instance of the plugin UI object:
    self->ui = self->show();
    fl_open_display();
    // set host to change size of the window
    if (resize)
    {
       resize->ui_resize(resize->handle, self->ui->w(), self->ui->h());
    }
    fl_embed( self->ui,(Window)parentXwindow);

    return (LV2UI_Handle)self;
}


Ok. Any survivors? No? Well I'll just keep talking to myself then. We mentioned the extension_data function. This function gets called and can do various special functions if the host supports them. Similar to the port event, the same extension_data function gets called with different indexed functions and we can return a pointer to a function that does what we want when an extension we care about gets called. Once again we get to see both sides of a function we called. The resize stuff we did in instantiate can be used as a host feature like we did before or as extension data. As extension data you can resize your UI object according to whatever size the host requests. This extension isn't necessary for an NTK GUI but since the parent window we embedded our UI into is a basic X window, its not going to know to call our fltk resize functions when its resized.

In contrast, a crucial extension for an NTK GUI is the idle function. Because similarly the X window doesn't know anything about fltk and will never ask it to redraw when something changes. So this LV2 extension exists for the host to call a function that will check if something needs to get updated and redrawn on the screen. We made an idle function already to call in our StuckUI object through fluid, but we need to set up the stuff to call it. Our extension_data function will need some local functions to call:
static int
idle(LV2UI_Handle handle)
{
  StuckUI* self = (StuckUI*)handle;
  self->idle();
 
  return 0;
}

static int
resize_func(LV2UI_Feature_Handle handle, int w, int h)
{
  StuckUI* self = (StuckUI*)handle;
  self->ui->size(w,h);
 
  return 0;
}



Hopefully its obvious what they are doing. The LV2 spec has some stucts that are designed to interface  between these functions and the extension_data function, so we declare those structs as static constants, outside of any function, with pointers to the local functions :
static const LV2UI_Idle_Interface idle_iface = { idle };
static const LV2UI_Resize resize_ui = { 0, resize_func };


And now we are finally ready to see the extension_data function:
static const void*
extension_data(const char* uri)
{
  if (!strcmp(uri, LV2_UI__idleInterface))
  {
    return &idle_iface;
  }
  if (!strcmp(uri, LV2_UI__resize))
  {
    return &resize_ui;
  }
  return NULL;
}

You see we just check the URI to know if the host is calling the extension_data function for an extension that we care about. Then if it is we pass back the struct corresponding to that extension. The host will know how these structs are formed and use them to call the functions to redraw or resize our GUI when it thinks its necessary. We aren't really guaranteed timing for these but most hosts are gracious enough to call it at a frequency that gives pretty smooth operation. Thanks hosts!


So, its now time for the ugly truth to rear its head. Full disclosure: this implementation of the resizing extension code doesn't work at all. The official documentation describes this feature as being 2 way, host to plugin or plugin to host. We've already used it as plugin to host and that works perfectly, but when trying to go the other way I can't get it to work. The trouble is when we declare and initialize the LV2UI_Resize object. The first member of the struct is type LV2UI_Feature_Handle which is really just a void* which should really just be a pointer to whatever data the plugin will want to use when the function in the 2nd member of the struct gets called. Well for us when resize_func gets called we want our instance of the StuckUI that we created in init_stuckUI(). That would allow us to call the resize function. But we can't because its out of scope, and the struct must be a constant so it can't be assigned in the instantiate function. So I just have a 0 as that first argument and actually have the call to size() commented out.

Perhaps there's a way to do it, but I can't figure it out. I included that information because I hope to figure out how and someday make my UI completely resizable. The best way to find out, I figure, is to post fallacious information on the Internet and pretty soon those commenters will come tell me how wrong and stupid I am. Then I can fix it.

As a workaround you can put in your manifest.ttl this line:
lv2:optionalFeature ui:noUserResize ;

Which will at least make it not stupidly sit there the same size all the time even when the window is resized. If the host supports it.

"So if its not even resizable why in the world did you drag us through 3 long detailed posts on how to make LV2  GUIs out of SCALABLE vector graphics?!" you ask. Well, you can still make perfectly scalable guis for standalone programs, and just having a WYSIWYG method of customized UI design is hopefully worth something to you. It is to me, though I really hope to make it resizable soon. It will be nice to be able to enlarge a UI and see all the pretty details, then as you get familiar with it shrink it down so you can just use the controls without needing to read the text. Its all about screen real estate. And tiling window managers for me.


So importantlyin LV2 we need to have a standard function that passes to the host all these functions so the host can call them as necessary. Similar to the DSP side you declare a descriptor which is really a standard struct that has the URI and function pointers to everything:
static const LV2UI_Descriptor stuckUI_descriptor = {
    STUCKUI_URI,
    init_stuckUI,
    cleanup_stuckUI,
    stuckUI_port_event,
    extension_data
};


And lastly the function that passes it back. Its form seems silly for a single plugin, but once again you can have a plugin bundle (or a bundle of UIs) sharing source that passes the correct descriptor for whichever plugin is requested (by index). It looks like this:
LV2_SYMBOL_EXPORT
const LV2UI_Descriptor* lv2ui_descriptor(uint32_t index)
{
    switch (index) {
    case 0:
        return &stuckUI_descriptor;
    default:
        return NULL;
    }
}


As a quick recap, here are the steps to go from Inkscape to Carla (or your favorite LV2 plugin host):
1. Draw a Gui in Inkscape
2. Save the widgets as separate svg files
3. Convert to cairo code header files
4. Edit the draw functions to animate dials, buttons, etc. as necessary.
5. Create the GUI in ntk-fluid with the widgets placed according to your inkscape drawing
6. Include the ffffltk.h and use ffffltk:: widgets
7. Assign them their respective draw_functions() and callbacks
8. Add the write_function, controller members, and the idle() function
9. Export the source files from fluid and write a ui_main.cxx
10. Update your ttl
11. Compile, install, and load in your favorite host.

So you now have the know-how to create your own LV2 plugin GUIs using Inkscape, svg2cairo, ffffltk, ntk-fluid, and your favorite editor. In 11 "easy" steps. You can see the source for the infamous Stuck that I developed this workflow through in my infamous repository. And soon all the plugins will be ffffltk examples. I'll probably refine the process and maybe I'll post about it. Feel free to ask questions. I'll answer to the best of my ability. Enjoy and good luck.

As an aside, in order to do this project. I ended up switching build systems. Qmake worked well, but I mostly just copied the script from Rui's synthv1 source and edited it for each plugin. Once I started needing to customize it more to generate separate dsp and ui binaries I had a hard time. I mostly arbitrarily decided to go with cmake. The fact that drmr had a great cmake file to start from was a big plus. And the example waf file I saw freaked me out so I didn't use waf. I guess I don't know python as much as I thought. Cmake seemed more like a functional programming language, even if it is a new syntax. I was surprised that in more or less a day I was able to get cmake doing exactly what I wanted. I had to fight with it to get it to install where I wanted (read: obstinate learner), but now its ready for whatever plugins I can throw at it. So that's what I'm going to use going forward. I'll probably leave the .pro files for qmake so if you want to build without a GUI you can. But maybe I won't. Complain loudly in the comments if you have an opinion.

by Spencer (noreply@blogger.com) at August 20, 2014 12:40 PM

August 19, 2014

Hackaday » » digital audio hacks

Beach Buddy is a Boombox, Phone Charger, and Sunburn Warner

The Beach Buddy

When you venture out onto the beach for a day in the sun, you’re probably not preoccupied with remembering the specifics about your sunscreen’s SPF rating—if you even remembered to apply any. [starwisher] suffered a nasty sunburn after baking in the sunlight beyond her sunscreen’s limits. To prevent future suffering, she developed The Beach Buddy: a portable stereo and phone charger with a handy sunburn calculator to warn you the next time the sun is turning you into barbecue.

After telling the Beach Buddy your skin type and your sunscreen’s SPF rating, a UV sensor takes a reading and an Arduino does a quick calculation that determines how long until you should reapply your sunscreen. Who wants to lug around a boring warning box, though?

[starwisher] went to the trouble of crafting a truly useful all-in-one device by modifying this stereo and this charger to fit together in a sleek custom acrylic enclosure. There’s a switch to activate each function—timer, charger, stereo—a slot on the side to house your phone, and an LCD with some accompanying buttons for setting up the UV timer. You can check out a demo of all the Beach Buddy’s features in a video below.

[via Dangerous Prototypes]


Filed under: Arduino Hacks, digital audio hacks, solar hacks

by Josh Marsh at August 19, 2014 02:00 AM

August 17, 2014

ardour

New community driven online project, Libre Music Production (LMP), launches today

Make music the free, open and easy way with Libre Music Production!

New community driven online project, Libre Music Production (www.libremusicproduction.com), launches today, Sunday 17th August 2014.

This new resource focuses on promoting music creation and composition using Free/Libre/Open Source Software (FLOSS).

The idea of Libre Music Production (LMP) was born out of a perceived lack of integrated resources, and in particular a lack of information aimed at new and non-technical users.

By providing hands-on material submitted by the community, such as guides, tutorials, articles and news updates, Libre Music Production shows you that there is great FLOSS audio software out there, and also how to practically use that software to make music.

To read the full press release, visit www.libremusicproduction.com/pressrelease

read more

by paul at August 17, 2014 04:43 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Announcing LibreMusicProduction.com

From: Gabriel Nordeborn <gabbe.nord@...>
Subject: [LAA] Announcing LibreMusicProduction.com
Date: Aug 17, 2:37 pm 2014

--089e0153715ad15f7e0500d0945f
Content-Type: text/plain; charset=UTF-8

Hey everyone!

It's our great pleasure to announce Libre Music Production (
http://www.libremusicproduction.com). Libre Music Production (LMP) is a web
portal and resource aimed at helping you make music using free and open
source software. While the portal was initially developed by a small group
of people, the aim and ambition is that LMP becomes a community project
where we all help out in building a great resource for making music using
FLOSS software. At launch we have over 10k words worth of articles and
guides, as well as a little over 2 hours of recorded video material.

We've prepared a press release that details more about this project at:
http://libremusicproduction.com/pressrelease

We'd greatly appreciate any help in spreading the word about this resource,
as well as any help with contributing content and so on. Please feel free
to copy+paste the press release as you'd like, and thank you very much for
any help!

Any other feedback is also greatly appreciated. Please use the contact
forms on the website :)

Have a nice day!

--089e0153715ad15f7e0500d0945f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey everyone!

It's our great pleasure to announ=
ce Libre Music Production (=
http://www.libremusicproduction.com
). Libre Music Production (LMP) is a=
web portal and resource aimed at helping you make music using free and ope=
n source software. While the portal was initially developed by a small grou=
p of people, the aim and ambition is that LMP becomes a community project w=
here we all help out in building a great resource for making music using FL=
OSS software. At launch we have over 10k words worth of articles and guides=
, as well as a little over 2 hours of recorded video material.


We've prepared a press release that details more about this project=
at: http://librem=
usicproduction.com/pressrelease


We'd greatly appreciate any =
help in spreading the word about this resource, as well as any help with co=
ntributing content and so on. Please feel free to copy+paste the press rele=
ase as you'd like, and thank you very much for any help!


Any other feedback is also greatly appreciated. Please use the contact =
forms on the website :)

Have a nice day!


--089e0153715ad15f7e0500d0945f--

read more

August 17, 2014 03:00 PM

August 15, 2014

Nothing Special

Creating A GUI in Inkscape

Long time no post eh? Busy busy times. The roof of my house is naked and I'm trying to get it covered up, so not much free time. But I was trying this while waiting for a build at work. I still owe you dedicated reader(s) a discussion on some of the production techniques on my new song, but it will be a while.

Anyhow, I fiddled for a year or more with creating QT widgets that display svg drawings of primitives I draw in inkscape. I was trying to do this for rakarrack and at the time it was the best way I could reconcile my infantile GUI knowledge with my infantile art skills (inkscape is manageable for me. You just draw shapes. Its geometry!). I had moderate success, the widgets are functional, (and can be found in my infamous repository) but lacking some significant features, namely, due to QT, no floating point representation in dials. Also I have to manually create a file to dictate what primitive files are used and where they are placed in the window. The svg files are loaded at run time after this descriptor file is parsed allowing for anyone to customize the look, which is kinda cool, but not really necessary. In the end, it was over complicated, and I didn't really like working on it (why I haven't released a single program with a fancy stylized gui yet).

Enter AVTK.

Wait. AVTK is just a set of NTK widgets that get drawn with cairo; NTK in turn is an FLTK fork that renders the FL widget drawing with cairo. And cairo doesn't have tools for drawing svg content anyway. So how will that help? Somehow I need to draw svg files!

Enter svg2cairo.

Oh, ok. That makes sense.

I'm losing my runtime loading/skinning ability, but I think the ease of programming will make it so I ACTUALLY release something with a GUI. Its something I've wanted to have done for quite some time, without actually doing it.

Anyhow, we'll talk about specific implementations later, for now lets have an almost tutorial on how to do it.

I assume you already have drawn an svg that you want to use so first lets install the tools (on ubuntu) **WARNING: if you aren't careful, you could make it so that the xserver doesn't start on your system. It happened to me. Its fixable, but a pain. If you follow these instructions in this order you will be ok:

sudo apt-get install librsvg2-dev
git clone https://github.com/original-male/ntk.git ntk-source
cd ntk-source
./waf configure
./waf
sudo ./waf install

Cairo unfortunately has to be built with a special flag for the converter to work, so download the source of a release:
mkdir cairo
cd cairo
wget http://cairographics.org/releases/cairo-1.12.16.tar.xz
tar xf cairo-1.12.16.tar.xz
cd cairo-1.12.16
./configure --enable-xml=yes

make
sudo make install

IMPORTANT UPDATE: I found that installing NTK from source always breaks my X setup so that I can't login with the display manager (read: bad). The easiest workaround is after installing (before rebooting!) run the commands:
sudo apt-get install --reinstall libcairomm-1.0-1
rm ~/.Xauthority


This doesn't replace what you just installed, it just reconfigures some stuff or something. If you can explain it to me please do. I suppose an easier workaround is just use NTK from the kxstudio ppas.

I then had to make sure building the program looks at this local library rather than the one installed from the distribution (don't copy over the distro version, it breaks a lot of stuff). Run the command:
export LD_LIBRARY_PATH=/usr/local/lib

Once you're done converting you'll want to set the LD_LIBRARY_PATH back to usr/lib or it will break some stuff.
Now you can download and install svg2cairo
git clone https://github.com/akrinke/svg2cairo.git
cd svg2cairo
make

After all that work I'm hungry.

Enter lunch.
 ...
Exit lunch.

Now lets convert an svg. For the first example here's a vintage dial I drew:

image/svg+xml

If you view the source of this page and copy the svg code into a file, you can repeat this almost-tutorial yourself. Now lets convert it:
./svg2cairoxml vintagedial.svg vintagedial.xml
lua cairoxml2cairo.lua -f c vintagedial.xml draw_vintagedial.c


This creates a c source file that has 3 functions:
cairo_code_draw_vintagedial_height();
cairo_code_draw_vintagedial_width();
cairo_code_draw_vintagedial_render(cairo_t * cr);


It always names the functions to match the name of the file. You can test it out and see the result by editing the test-c.c file to include the generated c (which is terrible code style, never include a .c) and function names then compiling and running it:
sed -i s/<name of the file>/draw_vintagedial/ test-c.c
gcc test-c.c -I /usr/include/cairo -L /usr/lib -lcairo
./a.out


This generates a nice PNG:

 I'm impressed. Theoretically you can convert to some other formats that might make previewing easier, but the conversion from cairo xml throws more errors (warnings?). In the end I really just want a c function anyway. One major setback is that there is no gaussian blur so make sure you take any blurs out of the svg before converting. This makes highlights and shadows more difficult. They sometimes can be done with gradients, but only if you have a very simple shape. But blur in the file makes the generated c uncompilable.

If you are following along it may not have worked. Make sure your LD_LIBRARY_PATH variable is set correctly as mentioned above. With all these details I made a script that would batch convert everything in a local directory:
#!/bin/bash

export LD_LIBRARY_PATH=/usr/local/lib




if [[ -z $1 ]]

then

cd svgfiles


mkdir formats

cp ../formats/* formats/
for file in *.svg;
do
echo "converting $file"
./../svg2cairoxml $file ${file}.xml
lua ../cairoxml2cairo.lua -f c ${file}.xml draw_${file/.svg/}.h
file=draw_${file/.svg/}.h
size=$(file $file | grep "empty")
if [[ -z "$size" ]];
then
echo success
sed -i s/CAIRO_DEFAULT/CAIRO_ANTIALIAS_DEFAULT/ $file
sed -i "1s,^,inline ," $file
sed -i "2s,^,inline ," $file
sed -i "3s,^,inline ," $file
caps=`echo ${file^^}`
caps=`echo $caps | sed s/[.]/_/`
sed -i "1s,^,#ifndef $caps\n#define $caps\n," $file
sed -i -e "\$a#endif" $file
else
rm draw_${file/.svg/}.c
fi
done


rm -rf formats/

rm *.xml
cd ..
 
else
echo "converting $file" 
 ./svg2cairoxml $1 ${1}.xml
lua cairoxml2cairo.lua -f c ${1}.xml draw.c
sed -i s/CAIRO_DEFAULT/CAIRO_ANTIALIAS_DEFAULT/ draw.c
fi


export LD_LIBRARY_PATH=/usr/lib


 


Once you have the source file, you can draw the thing to your hearts delight, but we want to make it an interactive widget. So the important thing you'll have to do is animate the movement (more or less). There are a couple of approaches. One (that I took before in my QT attempts) is make separate svg files for the primitives and draw them separately, i.e. one for the round part of the knob that doesn't move and one for the needle that spins. The conversions will make 2 separate files with 2 separate functions that you'll need to call. Before calling the function that draws the needle do some transforms that will turn the drawing. Something like:
cairo_code_draw_vintagedial_render(cr);
cairo_translate(cr,width/2,height/2);
cairo_rotate(cr,3*PI/2*value - 3*PI/4);
cairo_translate(cr,-width/2,-height/2);
cairo_code_draw_vintageneedle_render(cr);


I haven't tested this, so no copy pasting but hopefully that gets the idea across. I however am opting for making a single drawing, then editing the render function to rotate it. To do so you'll have to figure out whats going on in the generated function. I don't know cairo hardly at all, but I was able to figure it out, so its not that bad. More or less it just draws each object in the svg from bottom layer to top. It draws the fill then the outline. And each part is conveniently separated with a comment line.

So edit draw_vintagedial.c to become draw_vintagedial.h with the following changes:

diff --git a/draw_vintagedial.c b/draw_vintagedial.h
index 44f6b35..8246911 100644
--- a/draw_
vintagedial.c
+++ b/draw_vintagedial.h
@@ -1,6 +1,7 @@

+#define PI 3.1415926535897932384626433832795
 int cairo_code_draw_vintagedial_get_width() { return 91; }
 int cairo_code_draw_
vintagedial_get_height() { return 91; }
-void cairo_code_draw_
vintagedial_render(cairo_t *cr) {
+void cairo_code_draw_
vintagedial_render(cairo_t *cr, float val) {
 cairo_surface_t *temp_surface;
 cairo_t *old_cr;
 cairo_pattern_t *pattern;
@@ -59,6 +60,11 @@ cairo_pattern_set_extend(pattern, CAIRO_EXTEND_PAD);
 cairo_pattern_set_filter(pattern, CAIRO_FILTER_GOOD);
 cairo_set_source(cr, pattern);
 cairo_pattern_destroy(pattern);
+
+cairo_translate(cr,45.5,45.5);
+cairo_rotate(cr,3*PI/2*val - 3*PI/4);
+cairo_translate(cr,-45.5,-45.5);
+
 cairo_new_path(cr);
 cairo_move_to(cr, 57.8125, 84.710938);
 cairo_curve_to(cr, 56.824219, 91.421875, 34.003906, 91.601562, 33.007812, 84.902344);



If you haven't seen a git diff before, its showing what lines get removed (-) and what gets added (+) with some unchanged lines above and below.

So I actually lied a little. We won't be using AVTK at all, we'll be using FFFFLTK: the forked-forked-forked-fast and light toolkit! Which I invented. Just now. Its, (you couldn't guess?) a fork of AVTK. The primary difference is rather than a built in draw function (which is used as a fallback default)  it just calls a function pointer you pass to it.

So in the end (for a dial or slider) you just need some function that takes a value from 0-1 (min to max) as the argument and draws the drawing accordingly and pass a pointer to it into the ffffltk widget. Alternatively you can just copy and paste the guts of the render function into the draw function of the AVTK widget, but I'm going to do it with function pointers. This is because I want my plugins to each be customized, so they'll be using lots of different looking knobs, and I don't want to copy all the other stuff over and over. Instead I'll just repeat this process for each drawing and generate a bunch of headers that I can include at will.

So get a copy of the ffffltk dial widget. There's a button in the link above to download a snapshot. Do that, open the archive and extract src/ffffltk/ffffltk_dial.h to the folder we're using for this little project.

So lets look at how to make a dial and assign the drawing function:
ffffltk::Dial *dial = new ffffltk::Dial;
dial->drawing_h = cairo_code_draw_vintagedial_height();
dial->drawing_w = cairo_code_draw_vintagedial_width();
dial->drawing_f = &cairo_code_draw_vintagedial_render;


and thats it. With various drawing functions you can have loads of different looking knobs on the same GUI.

So lets make a test. One of the programs installed when you installed NTK is ntk-fluid which is the NTK version of the fast-light-user-interface-designer. This makes designing the gui a breeze because much of it is drag and drop and the rest is fill in the blank. It might help to review the official fluid tutorial on that page linked above. I'm just going to breeze through it.

First make a new class, name it "FancyUI" and add a function and window named whatever the default is. In the C++ tab add in an extra code box:
o->show();

Add a single dial to the window and we'll edit its properties. Label it "Fancyness" and move it and resize it however you like. In the C++ tab type in the class box "ffffltk::Dial" in an extra code box type 
#include "ffffltk_dial.h" #include "draw_vintagedial.h"

and finally in another extra code box type:
o->drawing_h = cairo_code_draw_vintagedial_get_height(); o->drawing_w = cairo_code_draw_vintagedial_get_width(); o->drawing_f = &cairo_code_draw_vintagedial_render;

Save it as test.fl then go to file>write code and it will spit out  test.h and test.cxx that you can include in any project. For the test, make a main.cxx file with the following:
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include "test.h"

int main()
{
  FancyUI *a = new FancyUI;
  a.make_window();
 
  Fl::run();
 
  return 0;
}



Now compile and run it:
g++ -fpermissive *.cxx -lGL -lntk `pkg-config --cflags --libs cairo ntk` -o test_ui
./test_ui

And you should see something like this:
Congratulations! You are on the bleeding edge of technology. I am literally writing ffffltk as I write this, but I think the dial is more or less ready. Eventually I'll make a background, button, slider and whatever other widgets I'll need. Feel free to pitch in. I ought to mention too, big thanks to Harry Haaren of openAV productions for helping me out and making AVTK so simple to fork. And really to the creators of all these many tools I'm using. Thats the beauty of FLOSS: you really get to stand on the shoulders of giants.

Some issues:
One thing is that drawings don't actually scale well. At some point as it shrinks you need to remove details to keep it clear, and as it grows you should add detail. This method simply scales everything. It works ok within limits. If you know you are going to need very small or very large then you can change your drawing function accordingly. Or fork it and add height and width arguments to the draw function call. Its hard to keep it simple and make it flexible at the same time. The point was to be able to just use an svg with as little coding as possible. And there you have it.

Any questions?

by Spencer (noreply@blogger.com) at August 15, 2014 08:02 PM

KXStudio News

The 2nd beta of Carla 2.0 is here!

The Carla Plugin Host 2.0 beta2 release is finally here!
This release was slightly delayed in order to ensure plugin bridges were working properly.
If you haven't heard about the Carla 2.x series do so here.

In short, this release makes plugin bridges actually work and it's the first to support MacOS (>= 10.6).
The backend is now completely toolkit agnostic, only depending on the native window system (like X11 on Linux).
This release is much more stable when compared to the previous beta - it will no longer eat your cat! ;)
It should already be good enough for regular usage, if you can ignore some incomplete UI things.

Known issues / Release notes: (all to be fixed in the next beta)

  • All DPF and JUCE-based internal plugins were removed to reduce code size and complexity, they will be re-introduced later
  • AU plugin support is available on MacOS, but the discovery mechanism fails to find them
  • Linux release has support for bridging Window plugins using Wine (32bit and 64bit).
  • Linux 32bit release will not load 64bit plugins even if ran on a 64bit system
  • MacOS Carla-Rack LV2 plugin fails to show UI
  • MacOS and Windows do not support native widgets in LV2 yet (Cocoa and HWND, respectively)
  • MacOS release is 64bit only but it can load 32bit plugins
  • Windows 64bit build doesn't provide GIG and SFZ support, use the 32bit build if you need those
  • Windows builds do not support bridges (ie, 32bit plugins on a 64bit Carla) or Carla as plugin

The next beta will change a few things, specially UI-wise.
The discovery mechanism needs to be reworked for AU support and faster LV2 access.
Adding plugins and browsing presets will probably change too.
LMMS and VST plugin versions of Carla-Rack are also planned, but no promises for these.
We'll be posting more news as things are developed.

by falkTX at August 15, 2014 03:44 PM

August 13, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] MOD Duo's Kickstarter campaign to be launched in mid September

From: Gianfranco Ceccolini <gianfranco@...>
Subject: [LAA] [ANN] MOD Duo's Kickstarter campaign to be launched in mid September
Date: Aug 13, 12:58 pm 2014

--047d7bfcec50a28ceb0500619929
Content-Type: text/plain; charset=UTF-8

Greetings Linux Audio Users and Developers !!!

I'm very happy to inform that we will launch the MOD Duo's Kickstarter
campaign in mid September.

The MOD Duo is our second model and we've been putting a lot of engineering
in it based on the feedback we had from the MOD Quadra experience.

We deeply hope it becomes a device that empowers the Linux Audio community,
bringing together developers and musicians.

A pre-campaign site was created to warm up the communication engines:

http://stepontothefuture.com.

Hope you all enjoy and spread the word

Kind regards

Gianfranco Ceccolini
The MOD Team

--047d7bfcec50a28ceb0500619929
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Greetings Linux Audio Users and Developers !!!


iv>
I'm very happy to inform that we will launch the MOD Duo's =
Kickstarter campaign in mid September.

The MOD Duo=
is our second model and we've been putting a lot of engineering in it =
based on the feedback we had from the MOD Quadra experience.



We deeply hope it becomes a device that empowers the Li=
nux Audio community, bringing together developers and musicians.
=

A pre-campaign site was created to warm up the communication=
engines:



=C2=A0
Hope you all enjoy and spread the word

v>
Kind regards

Gianfranco Ceccolini=
The MOD Team


--047d7bfcec50a28ceb0500619929--

read more

August 13, 2014 01:00 PM

[LAA] Silvet Note Transcription Vamp plugin v1.0 released

From: Chris Cannam <cannam@...>
Subject: [LAA] Silvet Note Transcription Vamp plugin v1.0 released
Date: Aug 13, 12:58 pm 2014

Silvet is a Vamp plugin for note transcription in polyphonic music.

http://code.soundsoftware.ac.uk/projects/silvet

** What does it do?

Silvet listens to audio recordings of music and tries to work out what
notes are being played.

To use it, you need a Vamp plugin host (such as Sonic Visualiser).

How to use the plugin will depend on the host you use, but in the case
of Sonic Visualiser, you should load an audio file and then run Silvet
Note Transcription from the Transform menu. This will add a note
layer to your session with the transcription in it, which you can
listen to or export as a MIDI file.

** How good is it?

Silvet performs well for some recordings, but the range of music that
works well is quite limited at this stage. Generally it works best
with piano or acoustic instruments in solo or small-ensemble music.

Silvet does not transcribe percussion and has a limited range of
instrument support. It does not technically support vocals, although
it will sometimes transcribe them anyway.

You can usually expect the output to be reasonably informative and to
bear some audible relationship to the actual notes, but you shouldn't
expect to get something that can be directly converted to a readable
score. For much rock/pop music in particular the results will be, at
best, recognisable.

To summarise: try it and see.

** Can it be used live?

In theory it can, because the plugin is causal: it emits notes as it
hears the audio. But it has to operate on long blocks of audio with a
latency of many seconds, so although it will work with non-seekable
streams, it isn't in practice responsive enough to use live.

** How does it work?

Silvet uses the method described in "A Shift-Invariant Latent Variable
Model for Automatic Music Transcription" by Emmanouil Benetos and
Simon Dixon (Computer Music Journal, 2012).

It uses probablistic latent-variable estimation to decompose a
Constant-Q time-frequency matrix into note activations using a set of
spectral templates learned from recordings of solo instruments.

For a formal evaluation, please refer to the 2012 edition of MIREX,
the Music Information Retrieval Evaluation Exchange, where the basic
method implemented in Silvet formed the BD1, BD2 and BD3 submissions
in the Multiple F0 Tracking task:

http://www.music-ir.org/mirex/wiki/2012:Multiple_Fundamental_Frequency_Estimation_%26_Tracking_Results

_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 13, 2014 01:00 PM

[LAA] Constant-Q library and Vamp plugin

From: Chris Cannam <cannam@...>
Subject: [LAA] Constant-Q library and Vamp plugin
Date: Aug 13, 12:58 pm 2014

Announcing a new C++ library and Vamp plugin implementing the Constant-Q
transform of a time-domain signal.

https://code.soundsoftware.ac.uk/projects/constant-q-cpp

The Constant-Q transform is a time-to-frequency-domain transform related
to the short-time Fourier transform, but with output bins spaced
logarithmically in frequency, rather than linearly. The output bins are
therefore linearly spaced in terms of musical pitch. The Constant-Q is
useful as a preliminary transform in various other methods such as note
transcription and key estimation techniques.

This library provides:

* Forward transform: time-domain to complex Constant-Q bins
* Forward spectrogram: time-domain to interpolated Constant-Q magnitude
spectrogram
* Inverse transform: complex Constant-Q bins to time domain

The Vamp plugin provides:

* Constant-Q magnitude spectrogram with high and low frequency extents
defined in Hz
* Constant-Q magnitude spectrogram with high and low frequency extents
defined as MIDI pitch values
* Pitch chromagram obtained by folding a Constant-Q spectrogram around
into a single-octave range

The code is provided with full source under a liberal licence, and
plugin binaries are provided for Windows, OS/X, and Linux.

The method is drawn from Christian Schörkhuber and Anssi Klapuri,
"Constant-Q transform toolbox for music processing", SMC 2010. See the
file CITATION for details. If you use this code in research work, please
cite this paper.
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 13, 2014 01:00 PM

[LAA] LV2 1.10.0 and friends

From: David Robillard <d@...>
Subject: [LAA] LV2 1.10.0 and friends
Date: Aug 13, 12:58 pm 2014

Good news everyone! LV2 1.10.0 is out, along with enough parallel
releases that I'm entirely too busy[1] to make a proper release email
for each one.

LV2 1.10.0 download: http://lv2plug.in/spec/lv2-1.10.0.tar.bz2

Cutting edge developers who go to all the best parties should note that
the atom Object/Resource/Blank types have been merged and new code
should use only Object (this simplification is not conceptually a
compatibility breakage, but code explicitly using only Blank should be
updated).

Aside from this, there have been only minor improvements and additions
since 1.8.0. Freshly prettified documentation and a full change log is
available at http://lv2plug.in/ns/

Also check out the work-in-progress example-based LV2 book, "Programming
LV2 Plugins" at http://lv2plug.in/book/

Related release announcements:

http://drobilla.net/2014/08/08/jalv-1-4-6/
http://drobilla.net/2014/08/08/lilv-0-20-0/
http://drobilla.net/2014/08/08/suil-0-8-2/
http://drobilla.net/2014/08/08/sratom-0-4-6/

The RDF stack has also seen some updates:

http://drobilla.net/2014/08/08/sord-0-12-2/
http://drobilla.net/2014/08/08/serd-0-20-0/

Enjoy,

~ Your friendly local neighbourhood benevolent dictator who clearly
needs to automate the release process.

[1] i.e. lazy, but "busy" makes me sound important, doesn't it? There
could even be meetings involved.

--
dr

_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 13, 2014 01:00 PM

[LAA] Hydrogen 0.9.6 released

From: <mauser@...>
Subject: [LAA] Hydrogen 0.9.6 released
Date: Aug 13, 12:58 pm 2014

Hi everyone,

i'm happy to announce the final release of Hydrogen 0.9.6. I'm pretty
sure that most of the users are already working with a 0.9.6-beta
version, but here again is a small list of the most important changes in
0.9.6:

* new build system (cmake)
* add undo for song/pattern editor
* jack-session support
* jack-midi support
* several bug fixes
* tabbed interface
* several small changes to the GUI
* improve ExportSong add use of TimeLineBPM,
RubberbandBatch processor and different types of resample
interpolation


The release can be downloaded via github:
https://github.com/hydrogen-music/hydrogen/archive/0.9.6.tar.gz

At this time, this is a linux-only release. Installers for Windows / OS
X may follow in the future.

Big thanks to all those wonderful people who made this release happen
and who are keeping this project alive!

Best regards,
Sebastian


_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 13, 2014 01:00 PM

[LAA] amsynth 1.5.0

From: Nick Dowell <nick@...>
Subject: [LAA] amsynth 1.5.0
Date: Aug 13, 12:57 pm 2014

amsynth 1.5.0 is now available, with a host of improvements and new
features;

- new filter modes: notch and bypass
- new filter controls for key-tracking and velocity sensitivity
- OSC2 octave range increased
- ring modulation can now be dialled in (instead of on/off)
- LFO can now be routed to OSC1, OSC2, or both
- fixes an audible click when using fast filter attack times
- note and controller events are now rendered sample-accurate when run
as a plugin or JACK, fixing MIDI timing jitter
- DSSI & LV2 plug-in builds can now load any preset by right-clicking
the UI background
- bank & preset loading is now faster

Source code:
https://github.com/nixxcode/amsynth/releases/download/release-1.5.0/amsynth-1.5.0.tar.gz

If you find any problems, please file a bug report @
http://code.google.com/p/amsynth/issues/list

Thanks to all who have helped by providing suggestions and feedback.

Nick

_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

August 13, 2014 01:00 PM

August 12, 2014

Libre Music Production - Articles, Tutorials and News

Content Wish List

The content wish list is a list of articles and tutorials we would like to see on LMP. If you do have knowledge on anything in the list and are considering contributing content, please do contact us.

If you are a new user who is interested in a specific piece of software and would like to see it covered on LMP, please do contact us so we can add it to the wish list. There is also a survey that you could fill out if you would like to tell us more about general content that you would like to see on LMP.

by Conor at August 12, 2014 04:47 PM

August 11, 2014

Libre Music Production - Articles, Tutorials and News

Recording audio and using MIDI in Ardour 3

This video series features a basic overview of recording and editing audio, plus basic recording and editing of MIDI, using Ardour 3. We start by setting up Ardour and creating a new session. After that, we add MIDI tracks, connect our MIDI keyboard, record, and edit MIDI.

Next we add a few audio tracks and record some short segments of guitar. Finally, we do some basic editing of that recording, and some basic arrangements.

This video uses the following gear and software:

by Gabbe at August 11, 2014 06:06 PM

Nothing Special

Drawing a GUI in Inkscape

So I got all excited and posted that last article about a lot of the technical stuff to make a GUI in Inkscape, but after posting it I realized it makes quite a few assumptions, so I'm going to add a few follow on posts, some of which (mostly this one) should have been written first. So its a prequel. Or a Part 0. Something like that.

Anyway the biggest assumption I made is that you are proficient in inkscape. Perhaps you are, but I wasn't until I started trying to draw GUIs in it. So basically all my skills are honed to this purpose. I'm not qualified to give a real inkscape tutorial so you should probably stop reading right now, but just in case I can help someone out there make a cool GUI I'll press onward.



I think I originally found inkscape when trying to draw a cover for my bands forthcoming album (which has been forthcoming for several years). I started with GIMP, but I couldn't really draw very well with it. I also really liked the idea of scalable drawings rather than pixmaps, so I stumbled upon inkscape. Not long after I read the rakarrack team was looking for new GUIs so I volunteered that I didn't know what I was doing, but I would try anyway. I drew some 30 svg drawings in inkscape of "stompboxes" for the various rakarrack effects and wrote the qsvgwidget library thing that I mentioned before. That faded as the programming got complex, but I have since used inkscape for my masters thesis diagrams, work documents, and even for sketching up layouts for remodeling my kitchen.

I'm about to give a bunch of information that may not even be helpful, but its what I use all the time when drawing stuff, but first (before you get scared) lets have an overview. You can make it pretty simple and have some good looking results. You are drawing lines and shapes. Shapes are just lines that connect together to form a boundary (so really you are just drawing lines). These lines and shapes become objects you can copy and paste, move around, shape, layer and do all sorts of things to make them look how you want, but in the end you are just defining lines and shapes.

I'd read an watched some tutorials that helped a lot and you'll do better with those, but here's a crash course (more like list) of basic Inkscape "moves" that help a lot in drawing GUI elements.
Need to know skills:

Ctl+D - duplicate, creates a copy exactly over the original. Use it then the arrow keys to make identical copies that are aligned, i.e. a grid of dials

(arrow key) - move object
Alt+(arrow key) - move object small step
Shift+(arrow key) - move object large step

Ctl+g - turn objects into a group. Nothing is worse than making an intricate object then accidentally missing one piece when selecting it to move to its place. Ctl+z fixes it by undoing, starting you over, but its much nicer just to have one object (group really) that you just click and drag. You can have groups of groups, groups of mixed groups and objects etc.
Ctl+Shift+g - separate the topmost group back into individual objects/groups, sometimes you need to go change a detail, so you ungroup, change, regroup

Ctl+(rotate, resize, etc) - holding control usually makes things work in nice increments, i.e. when drawing a rectangle, holding ctl forces it to a square, rotations while holding ctl go in 30 degree increments (or something like that).

Ctl+Shift+C - converts the object/shape/text to a path so you can manipulate its little details. For text especially this matters because if the target doesn't have the correct font installed it won't appear correctly, but once its a path, it just draws that shape. Make sure your text is exactly how you want it first though.

Rectangle drawing tool, circle drawing tool, gradient tool, and node editing tool; align and distribute menu, fill and stroke menu; etc. etc. etc.

Ok there's probably too much to mention. But these are the ones I use the most. You can see there are a lot of things you can do with inkscape and this doesn't scratch the surface.

The node editing tool is especially powerful. In this almost-tutorial I'm going to make a GUI and I went through the pain of visually documenting each step for one of the shapes:

You see first it was a rectangle, then I converted it to a path, and used the node editing tool. I added some nodes, deleted the ones I didn't want, then changed the node curvature properties so the middle 2 nodes on the sides are corners, and the top one is a symmetrical curve. In the bottom row I drew a line, centered it, duplicated the lines and moved them to one side, duplicated the 3 lines, mirrored it horizontally and moved them to the other side. For the screenshot I selected everything with the node adjust tool so you can hopefully see what I was doing. Also take note how nicely aligned the steps are are due to the duplicate/move-with-arrow  combo.

The node tool is pretty advanced. You don't have to go that far. Here's a simple dial:

So make a circle, add a radial gradient, edit the gradient stops (colors), then add (and align) a rectangle for a pointer. Easy as PI. You can even skip the gradient.

The point is its a little easier (because its WYSIWYG) than trying to edit style files or blindly using a drawing API like cairo. That is why I started ffffltk (and qsvgwidgets before that).

So I'm not going to describe how to draw every single widget, you can go learn more about drawing on your own (or just ask for specifics in the comments below). But here are some tips on how to make your life easier when you convert them to Cairo code.

Symmetry is nice, but some things are asymmetrical. For dials you will need to know what point you want to rotate around in the drawing so you can do it in cairo, typically its the middle so just keep the width and height the same and divide by 2. Also important is that the original drawing or "canvas" size will fit everywhere the drawing could be. For example this switch:

Once toggled the other way it's going to go off the other side of the canvas. Like this:

So instead, change the size of the canvas so that it doesn't. To get the right size of canvas: duplicate the whole switch (Ctl+D), flip the copy vertically (V), and carefully move it (using only up and down arrow keys) so that the circle parts are aligned. I find it helpful to temporarily change the opacity of the top one so you can see the one beneath. Zoom way in and use the Alt+Down key to make those fine detailed moves till it fits. Then press Ctl+Shift+D to change the canvas size. Click the resize page to drawing or selection button in the custom size box and it will resize it perfectly:


Now if you delete one copy you get the same thing, but it won't get cut off:

When using the ffffltk button widget to display this, you will convert to cairo and then you need to "animate" the drawing. With this one you could probably get away with doing a cairo_rotate(cr,PI) before drawing the top object (the switch), but I chose to leave both copies of the switch in the drawing and use an if statement to toggle which one will actually be drawn. Having the drawing like this also helps when prototyping the layout of the window in inkscape, so you can see if you are going to cover up some text or something once the switch is thrown (because the drawing shows both positions). If this paragraph is completely confusing, you probably should review my last blog post. Or I'm just a terrible writer.

The same sort of thing goes with dials. In the example "vintage" dial I used in the last post the canvas was made by duplicating and rotating the needle 90 degrees and resizing the canvas so the point doesn't get cut off when you turn it sideways. Hopefully that covers this point.

Another widget I'm using quite a bit in these skeuomorphic designs is an l.e.d.. Because you can't use Gaussian blur natively in cairo, I achieve it with a radial gradient. In this UI design there's a blue l.e.d. so I make a drawing of an unlit l.e.d. and then a lit version. Below you see them side by side. The "light" is just a lighter blue circle over top with a multi-stop radial gradient centered on the circle so that the edges are becoming transparent. It works. These are used in a toggle button draw function that just removes the "light" circle when passed a 0.


So once you've drawn a bunch of widgets and saved them as separate svgs, its probably worth throwing them all together into a layout. So for this example here are the pieces:

And I arrange them like so:


One trick I use is that I make a group of the 2 dials and center the group with respect to the background, then ungroup them so that they are equally spaced, then center their respective labels to the knobs.

This part is the most complicated, but can be bypassed by using simpler backgrounds, using labels on the widgets rather than fancy text drawn into the background, and just laying it out in ntk-fluid. We want to take note of the size of the background canvas and where each widget falls so that we can reproduce the inkscape drawing in ntk-fluid. The trouble is SVG/Inkscape defines the origin as the bottom left corner and fltk defines the origin as the top left corner with the y axis inverted. So to really reproduce the drawing we can't just copy the numbers, we have to take each widget and recalculate it. So for example the background is 128x200 width x height and in Inkscape the switch falls at a position (x,y,w,h) of about (20,71,11,36). So once that's switched to fltk the y changes to 200-(71+36) = 93.  Another tip is select all the objects, then in the bar above the drawing, lock the width and height and then type a nice round number into one of them (such as 200). This scales everything respectively. You could even move and scale each object to nice integers by directly entering numbers this way, but I just figure the nearest pixel is close enough.

Once you have a mockup and note all the important numbers, save each object that will become a widget separately (delete everything but the widget of interest, resize canvas, save, undo till the other widgets are back, repeat). So here I generate 4 files, the dial, the switch, the l.e.d. and everything else gets saved as the background file (remember to convert text to paths!). Convert those files to cairo code as described in the last post and make the switch and l.e.d. render functions have an additional argument for being on or off (dials were covered last time, follow that). Now, continue with that guide to make a UI in ntk-fluid.

I'm doing some things differently from the previous guide. One is setting all the widget styles such that they have no boxes. I was going to do the window with no box so that it was a "non-rectangular" window, but then it requires a window manager with compositing. In the extra code section for the window I include ffffltk.h and in another extra code box enter "using namespace ffffltk;" This way I don't have to declare each widget a ffffltk::Dial etc. only "Dial" (else it will look for a non-existent "ffffltk::Fl_Dial").

 Also not mentioned is that the ffffltk::Background widget has a property "stretch" that is set true by default; in this UI I would set it to false so that the background height and width are always scaled proportionally, preserving the shape. This good for decorations but not really the best for this UI because the other widgets scale and move with respect to the window not the drawing. To make up for this I created a new ffffltk widget: Aspect_Group. Clever name huh? Its a group that always preserves aspect ratio. So you assign the draw function to the background drawing and then put all the other widgets inside the group. They then scale and move proportionally to the background rather than the whole window. So if you want the window to be able to change shape (i.e. be tall and narrow or short and wide), use a Background widget and put your text labels as separate Backgrounds with stretch disabled. If you want it to maintain aspect ratio, use an Aspect_Group.

  The l.e.d. is an inactive button and gets its value set by the callback of the other button with "led->value(stickit->value());". I also set the buttons to toggle buttons using "o->type(FL_TOGGLE_BUTTON)" in initialization since there is no ffffltk::Toggle_button to instantiate.

This UI design is obviously impractical. More than half the window is wasted simply for decoration, when there are only 3 real widgets, and one redundant indicator. But this is going to a plugin that can have a host generated UI and be perfectly functional with that, so the only reason you would use this GUI is because you want eye-candy. So now you've got some:


There you have it. Overall this is another almost-tutorial that is probably more confusing than helpful. The last post I wrote to help myself remember, this one I kinda wrote for you readers. If you really exist. Hope it helps. Ask for clarification and I'll either elucidate or write a separate post detailing whatever it is. But also hang on for a follow up on how to apply this UI to an LV2 plugin. That post might be more thorough since I'll be writing for myself again. Sorry but it's true.

by Spencer (noreply@blogger.com) at August 11, 2014 04:11 PM

Create Digital Music » open-source

Will Your Next Controller Be 3D Printed? Meet Adafruit’s Open Source Grid

The original monome project did more than just create a novel piece of hardware for music. It established a design language for what essential digital interfaces might be, in the deceptively simple form of its light up grid of buttons.

It’s not so interesting to just copy that hardware, then. More compelling are efforts to extract the elements of the design in ways that can be turned into new things.

Adafruit has been slowly building up a nice set of building blocks clearly inspired by monome. Trellis is a system for making the grids component work – lighting the buttons and responding to keypresses in a big array. Add something like an Arduino as the “brains,” and you can add grids to your own hardware. In typical Adafruit fashion, everything is exquisitely well-documented and perfectly friendly even to those just dabbling in making their own stuff for the first time.

3d_printing_hero-angle-view

OONTZ is a project that demonstrates how all these bits can come together. The notion is to build a MIDI Controller with basic parts and Arduino that can be used with computers, MIDI hardware, and iOS. Mini OONTZ goes one step further: 3D print the case, so you can have your grid, your pots, and MIDI in one box that’s ready for jamming.

3D printing here is a nice angle. 3D printers are just one solution among others, but clearly the case is a step that often stymies people making creative new hardware. And the tools for using and modifying files are getting better, too (just as the 3D printers gradually improve and become more available). In the case of the Mini OONTZ, you get free and open downloadable files for the case, plus the ability to modify the files on Autodesk 123D.

Once a design does work for more than a handful of people, it seems that conventional production remains the best solution for cases. 3D printing isn’t cost- or time- effective beyond one-off production. Wood and metal are options, too, not just plastic. But at the same time, it’s terrific to see Adafruit cover all the bases, from the bits that make the grids work to controllers as full-blown products with cases.

The guts of the system: Trellis, when connected to an Arduino, does the work of wiring up and lighting up those buttons.

The guts of the system: Trellis, when connected to an Arduino, does the work of wiring up and lighting up those buttons.

And the shell: a 3D printed case makes this something you might actually use, and provides cutouts for connections (including MIDI), the keypad, and pots.

And the shell: a 3D printed case makes this something you might actually use, and provides cutouts for connections (including MIDI), the keypad, and pots.

And they’re not alone. The Bhoreal project has their own open source grid controller project, which we covered earlier. Bhoreal has some innovations of its own, including OSC over wireless connections and slim-line cases. And geography matters, too, when building communities: Bhoreal’s Barcelona location gives them some possibilities to work more closely with a European audience (including in languages other than English) and to try to begin to work with local suppliers.

The big news there is that Bhoreal is also now shipping to its crowd funding backers, so we’ll check in with them soon; in the meantime, you can follow their Facebook page (and maybe I’ll keep an eye out for Vueling’s airfares to go on sale so I can pay them a visit):

Bhoreal

Because these are open projects, of course, the more resources the better – you can learn something from both projects.

Please, let us know if you build a Mini Oontz or another project based on the Adafruit stuff; we’d love to see it. And if there’s something in the open source controller world that you’re lacking, that you’d want to see developed, definitely let us know that, too.

Mini OONTZ: 3D Printed MIDI Controller

The post Will Your Next Controller Be 3D Printed? Meet Adafruit’s Open Source Grid appeared first on Create Digital Music.

by Peter Kirn at August 11, 2014 08:36 AM

August 08, 2014

drobilla.net » LAD

Jalv 1.4.6

Jalv 1.4.6 is out. Jalv is a simple but fully featured LV2 host for Jack. It runs LV2 plugins and exposes their ports as Jack ports, essentially making any LV2 plugin function as a Jack application.

Changes:

  • Show newly saved presets in the preset menu.
  • Generate Qt moc nonsense at build time for broader compatibility.
  • Update for latest LV2 Atom Object simplifications.
  • Set port pretty names via new Jack metadata API.
  • Add support for data-access extension (based on patch by Filipe Coelho).
  • Support new UI show/hide interface in console version.
  • Add option to print control output changes to stdout.
  • Support saving the same preset several times.
  • Update man pages and console jalv help output for new options.
  • Upgrade to waf 1.7.16.

flattr this!

by David Robillard at August 08, 2014 10:34 PM

Ganv 1.4.2

Ganv 1.4.2 is out. Ganv is an interactive Gtk canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc).

Changes:

  • Fix bug where edges would not update when nodes are moved after the canvas is cleared (fix stuck connections in Patchage after refresh).
  • Upgrade to waf 1.7.16.

flattr this!

by David Robillard at August 08, 2014 10:30 PM

Lilv 0.20.0

Lilv 0.20.0 is out. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications.

Changes:

  • Don’t load files multiple times if they are listed as rdfs:seeAlso for several plugins.
  • Call lv2_lib_descriptor separately for different bundle paths (fix loading several dynamic plugins like Ingen at once).
  • Tolerate calling lilv_node_as_uri or lilv_node_as_blank on NULL.
  • Add convenient lilv_new_file_uri for creating file URIs.
  • Fix use of lv2info -m and -p options to write plugin data (useful for porting plugins bridges with NASPRO).
  • Fix issues with lilv_plugin_get_author_name and friends (thanks Filipe Coelho).
  • Improved/working lv2_apply.py to apply plugin to a .wav (thanks Joe Button).
  • Add lilv_world_unload_bundle() and lilv_world_unload_resource().
  • Fix several minor memory leaks.
  • Improve test coverage.
  • Upgrade to waf 1.7.16.

flattr this!

by David Robillard at August 08, 2014 10:24 PM

Suil 0.8.2

Suil 0.8.2 is out. Suil is a lightweight C library for loading and wrapping LV2 plugin UIs. Suil transparently presents UIs written in any toolkit as the desired widget type of host programs, so hosts do not have to depend on foreign toolkits.

Changes:

  • Fix embedding several Qt UIs in Gtk.
  • Add configure options to disable all Gtk or Qt support.
  • Upgrade to waf 1.7.16.

flattr this!

by David Robillard at August 08, 2014 10:21 PM

Sratom 0.4.6

Sratom 0.4.6 is out. Sratom is a small C library for serialising LV2 atoms to/from Turtle.

Changes:

  • Update for latest LV2 Atom Object simplification.
  • Don’t set eg prefix in sratom_to_turtle.
  • Upgrade to waf 1.7.16.

flattr this!

by David Robillard at August 08, 2014 10:17 PM

Ubuntu Studio » News

Ubuntu Studio 12.04.5 Point Release

This is another point release of 12.04 Precise Pangolin, with the latest updates. If you already have 12.04 installed, you will have all the latest updates if you’ve kept your system up to date, so no need to do a fresh install. You can find the ISOs at our download page https://ubuntustudio.org/download/.

by Kaj Ailomaa at August 08, 2014 07:37 AM

August 06, 2014

blog4

RIP Marilyn Burns

Texas Chainsaw Massacre scream queen Marilyn Burns passed away at 65.
She also starred in Tobe Hoopers second, lesser known movie Eaten Alive. After his success with Texas Chainsaw Massacre he reunite with writer Kim Henkel and assembled with a higher budget an interesting cast in an amazing set that unlike his first movie is not realistic at all, its artificial looking giving the movie an colorful EC Comics feel. Marylin Burns plays the young mother of a dysfunctional family with William Finley (the phantom in De Palmas Phantom Of The Paradise) as husband, checking in the wrong motel in a swamp area, ending up screaming her lungs out, again. In the cast was also Robert Englund who later shall become famous as Freddy Krueger, delivering here a quote in the opening scenes which decades later will be picked up by Tarantino. Carolyn Jones as an old brothelowner, unrecognizable in her mask as an old hag. Only 10 years before she fueled our gothic dreams as Morticia in the original Addams family. Mel Ferrer is on the receiving end of my favorite murder in this movie, Stuart Whitman supports as Sheriff. But the star is Neville Brand as mumbling vet and owner of that motel who lost all his marbles.
Unfortunately Tobe Hooper got kicked out during the filming by the producers but the film feels rather coherent in all its insanity.


Unfortunately Tobe Hooper got kicked out during the filming by the producers but the film feels rather coherent in all its insanity. The electroacoustic soundtrack is again done by Hooper, like in TCM.

Here Englund recalls his meeting with Jones 

The trailer, unsuitable for children as all of my posts so get of my lawn you brats:


by herrsteiner (noreply@blogger.com) at August 06, 2014 01:52 PM

August 04, 2014

Create Digital Music » Linux

Serato DJs Get Slim-Line Controllers at Last, with New Akai Hardware

AMX is an audio interface, it's DVS ready, and it includes a full copy of Serato DJ.

AMX is an audio interface, it’s DVS ready, and it includes a full copy of Serato DJ.

Serato DJs swear by their software. But one thing they haven’t had lately is a lot of choice in DJ controller hardware. Sure, there’s now a range of hardware getting updated for the latest software. But even after a transition to the new Serato DJ platform, almost all of this hardware is of the “really wide with two big wheels” variety.

That big hardware is a big problem. It leaves out Serato DJs working with vinyl who just want some added control of the software. It adds two big platters, which are arguably something you don’t need in the first place. And it gives you hardware that’s tough to fit in a bag – and sometimes impossible to fit in a booth. It works for some people in some situations, that is, but not all. And to add insult to injury, Allen & Heath’s beautiful XONE:K2 controller supported almost every DJ tool except Serato (even competing head-to-head with Native Instruments’ own hardware for Traktor).

Well, now there’s release, in two inexpensive, versatile-looking controllers from AKAI. AKAI, for their part, seems intent on world domination of every category (with InMusic comprising that brand as well as M-Audio and Alesis).

The AFX is a US$199 slim USB controller for effects, cueing, and loops. The AMX is a $249 control surface and audio interface.

There’s an obvious parallel to Native Instruments’ X1 and Z1, respectively. (It’s worth mentioning that, because NI has just announced that it’s including Traktor Pro for free with the purchase of either one, for the month of August.) But for Serato lovers, there’s no real comparison. Not only do you get extensive Serato integration, but the AMX gets you the latest full copy of Serato DJ – meaning, if you’re looking to upgrade (or, cough, get a legitimate copy), this is a smart buy.

Details:

DJ controllers for Serato that aren't huge things with wheels. New AKAI hardware, out this month.

DJ controllers for Serato that aren’t huge things with wheels. New AKAI hardware, out this month.

The AFX:

  • Custom layouts with Serato Flip
  • 4 decks of control
  • 9 touch-activated knobs
  • 8 velocity-sensitive RGB-backlit pads
  • Different pads modes: trigger hot cues, loops, or slices.
  • USB powered
Touch control - look familiar?

Touch control – look familiar?

That controller is also driverless, so you’re not limited to Serato here. You could even map it on Linux, if you really wanted.

The AMX:

  • 24-bit/96kHz audio interface
  • 2 phono/line inputs, stereo and headphone outputs
  • 9 touch-activated knobs
  • Includes a full license for Serato DJ
  • Akai’s innoFADER crossfader
  • Headphone output
  • Velocity-sensitive pads on the front of the AKAI, a packed controller unit for Serato DJ.

    Velocity-sensitive pads on the front of the AKAI, one draw on a packed controller unit for Serato DJ.

    Here's where things get interesting: dual inputs mean you could really run a digital vinyl system off this, turntablists.

    Here’s where things get interesting: dual inputs mean you could really run a digital vinyl system off this, turntablists.

    Actually, having said there’s no comparison, let’s compare. The AFX has velocity-sensitive pads and 4 decks of control; the NI Kontrol X1 has only trigger buttons and 2 decks. (Switches at the top of the Akai give you the second two decks.) They both have touch-sensitive strips. But the trade-off is, the X1 gets a much cleaner layout than the AFX. Also, if the AFX feels anything like the new Ableton controller hardware from Akai, I’m suspicious you’re likely to prefer the more-solid feel of the NI gear – you don’t get anything for free. And, I’m sorry Akai, the NI box is just better looking.

    Then again, maybe it’s not fair to compare these two for a second reason – with the slicer, sampler, roll, and velocity-sensitive pad features, the Akai is more about live controllerism than the NI box. The question I have is whether you just want a dedicated pad controller at that point – and, if so, Akai will happily sell you one.

    The AMX is more of a no-brainer – and a portal into upgrading to Serato DJ. The NI Z1 has the advantage of seamlessly switching between desktop and mobile (working with the iPad version of Traktor), and it still covers the bases for audio. But the AMX is a different story: it adds separate LEDs for each track for cueing (absent on the Z1), it has two inputs so it can be used with Digital Vinyl systems (key for a lot of Serato’s market), and built-in browse and cueing. So here, the comparison between the two is a little more superficial.

    The big question is whether the AMX/AFX duo can cure Serato Face, the disease of laptop DJs (regardless of software maker) glued to their computer screens.

    The post Serato DJs Get Slim-Line Controllers at Last, with New Akai Hardware appeared first on Create Digital Music.

    by Peter Kirn at August 04, 2014 06:25 PM

    August 01, 2014

    Create Digital Music » open-source

    Midular are the Free MIDI Modules Every Ableton Live Setup Needs

    midularpitcher

    Forget fancy effects or sophisticated plug-ins – day-in, day-out, it’s those simple MIDI modules you wind up using again and again and again and again. It’s like having a bucket of paperclips on your desk. It doesn’t have to be exciting. It’s the simple stuff that gets used.

    So, one of my favorite demos from the jam-packed sessions at MIDI Hack Day in Stockholm in May was unquestionably Midular. The idea was simple: make some basic modules that do stuff to notes and control events, then combine them in useful ways. It deserved an ovation.

    And now, you can get those same modules for Max for Live, for free. They’re open source, properly under a GPL license (meaning, if you want to port them to Pure Data, you can, for instance). And they’re good enough that you’ll wonder with at least a couple of them why Ableton didn’t include these as defaults effects.

    The starting lineup:

    • LiveQuantizer. Well, duh. And as the creator notes, this means you can do to notes what Live does to clips.
    • Repeater. Repeat incoming notes.
    • Buffer. A round-robin note storage-and-playback sequencer – cool. And that naturally leads to -
    • Rotator. 8-note rotating buffer plus an 8-step sequencer, based on the Roland System 100m modular sequencer. This is a no-brainer to add to that Roland SYSTEM-1 I’m dragging into the studio tonight, in fact, both in SYSTEM-1 and SH-101 modes – I’ll report back.
    • SuperPitcher Works the way you wish Pitch did in Ableton – but then also adds a step-based modulator, for other effects.

    Yeah, so put them together, and then, you know, stuff.

    Yeah, so put them together, and then, you know, stuff.

    It’d be great to see this collection grow over time, particularly with additions from others in the Max for Live community. You can start on that right away by forking it on GitHub – or just download and get to playing.

    So, yes, fairly simple. It’s combining these (and, no doubt, communing them with other tools and toys from the Max for Live community) that gets more interesting. Some video examples:

    A simple demonstration showing how some of the Midular MIDI effect modules can be used together, focusing on the 8 note step sequencer called Rotator. I’ve tried keeping the sounds and sequences as simple as possible so that it’s easy to get a feeling for what’s going on.

    A simple demonstration of how some of the Midular MIDI effect modules can be used to generate various arpeggiated sequences from a single sustained note. The sound is purposefully kept as basic as possible so that it’s easier to hear what’s going on.

    News item:
    Introducing Midular, a set of MIDI effects built in Max for Live

    The project is the work of Knut Andreas Ruud. Brilliant stuff, Knut!

    https://github.com/carrierdown/m4l-midular (look for the “download ZIP” link in the right-hand column if you haven’t used GitHub before!)

    The post Midular are the Free MIDI Modules Every Ableton Live Setup Needs appeared first on Create Digital Music.

    by Peter Kirn at August 01, 2014 12:46 PM

    July 30, 2014

    Create Digital Music » Linux

    This is What High-End Audio Can Do Now: New Trio of Thunderbolt Boxes from MOTU

    1248-iso-right

    You’d be forgiven for missing it in the blur of press releases and trade show hand-outs – and, let’s face it, most musicians are too focused on music to pay much mind. But slowly, steadily, audio interfaces have been getting a lot better. Talk to the people who make them, and they can tell you what’s happened even in terms of individual components.

    Next, they’re about to get smarter and more networked.

    And so that means it is worth paying attention today as industry heavyweight MOTU unveils a trio of new audio interfaces, compatible with Thunderbolt 1 and 2 and USB2. MOTU says all three are built on an all-new platform. What you get is three different I/O configurations, but all sharing the same headline features. In short, that includes:

    • Thunderbolt connectivity plus USB 2.0
    • 48-channel mixing and DSP built-in
    • High-dynamic range analog/digital conversion (and d/a)
    • Networking via the new AVB Ethernet standard for expansion with extremely-low latency
    • Web-based control of the mixer, via any connection (wired or wireless)

    Yes, you read that right – Web browser mixer control. So that mixer can be on iOS, on Android, on a computer, anything. (And with class-compliant USB, in fact, this whole box can work without ever seeing a driver or particular OS.)

    A/D and D/A are the bit that impact the sound, but that networking is some interesting new sauce. AVB boasts both the ability to wire institutions with multiple audio interfaces in different rooms with next-to-null latency. Then, Web app support means you can let your guitarist tweak her headphone mix with her iPad. More on that in a bit.

    Interfacing Features

    The models: 1248, 8M, 16A. The 1248 is probably what readers here are most interested in: 8×2 balanced TRS analog I/O, four mic ins, two front-panel hi-Z inputs for guitars, two independent headphone outs, S/PDIF digital I/O. The 8M is if you want more inputs (eight analog outs, eight combo mic-line-instrument ins), whereas the 16A is all analog (16 ins, 16 outs, TRS).

    As is the tradition with MOTU and a handful of rival vendors, these aren’t just “studio” interfaces, spec’ed only for sound engineers. They’re also configured in ways musicians might use in their own work. And, of course, they’re MOTU boxes, so you still get get not only all these mixing features, but standard functionality like word clock I/O (key for video production and the like).

    Also interesting: that’s class-compliant USB, so you could theoretically connect these to an iPad if you wanted.

    1248 I/O.

    1248 I/O.

    8M, for gentlemen and ladies who prefer those extra mic pres.

    8M, for gentlemen and ladies who prefer those extra mic pres.

    16A. A is for ... analog.

    16A. A is for … analog.

    The analog-to-digital and digital-to-analog conversion is handled by ESS Sabre32 Ultras, which MOTU says mean that, on those TRS analog outs, you get some serious dynamic range – “a measured dynamic range of 123 dB (A-weighted, 20 Hz to 20 kHz).” And analog I/O latency has a round-trip of 32 samples (0.66 ms) at 48 kHz. (Note that doesn’t figure in the computer side of the equation, of course.)

    And, they’re mixers, with internal DSPs, so you can add modeled analog EQs, compression, and gating in the box without adding latency on the computer.

    So, that much is familiar. Here’s where things get interesting.

    Networked Audio

    What’s new is the Ethernet port with support for IEEE’s “802.1 Audio Video Bridging (AVB) extension to the Ethernet standard.”

    Say what?

    AVB is about the ability to combine interfaces via standard Ethernet cabling. You can even get a MOTU switch and connect three to five (or two using the onboard port).

    Why is that interesting, apart from MOTU selling you more hardware? Well, you can not only daisy-chain interfaces, but do so over long runs – up to 100m between devices. And you can do that even over Ethernet cabling you already have. Once you do, you get up to 128 channels of networked audio with latency of 30 samples – just above half a millisecond – and then you can clock them.

    Nerds, there’s open source AVB code from Intel:
    https://github.com/AVnu/Open-AVB

    plus reference implementations by xcore

    Browser Mixer UI

    You can also use the MOTU interfaces’ network savvy to control the mixer over the Web. The audio interface itself incorporates its own Web server, accessed via a connected machine on Thunderbolt or USB, or over that Ethernet port, or (with the Ethernet port jacked into a WiFi router), wirelessly.

    Pricing isn’t astronomical, either. Each unit is US$1495.

    More at MOTU:
    Introducing the 1248, 8M and 16A

    The post This is What High-End Audio Can Do Now: New Trio of Thunderbolt Boxes from MOTU appeared first on Create Digital Music.

    by Peter Kirn at July 30, 2014 08:13 PM

    Hackaday » » digital audio hacks

    Adding Bluetooth And A Lightning Connector To Beats Pro Headphones

    Beats

    Not wanting to wait for Apple to step up their game and complete their purchase of Beats headphones, [Carnivore] decided he wanted his own pair of Apple-compatible Beats cans with Bluetooth. He created something that will probably be for sale in the Apple store come Christmas: a pair of Beats Pro headphones with Bluetooth and a Lightning connector for charging.

    [Carnivore] liked the sound of his Beats Pro headphones but hated the wires. After disassembling the headphones, he carefully rewired the speakers with smaller gauge wire, added a small Bluetooth module and battery, and sealed everything back up.

    There are a few interesting bits to this build – by getting rid of all external wires, [Carnivore] was left with a few holes in the headphones. These were a perfect place to add a 3D printed mount for the power button and the Lightning adapter taken from an Apple Lightning extension connector.

    Thanks [Tony] for the tip!


    Filed under: digital audio hacks, macs hacks, wireless hacks

    by Brian Benchoff at July 30, 2014 11:00 AM

    July 28, 2014

    Create Digital Music » open-source

    Listen as a Compiler Makes Weirdly Good Blippy, Glitchy IDM Sounds [Free Tools]

    malloc

    What’s the sound of a computer program running?

    Normally, nothing – the number crunching that takes place as software allocates memory forms patterns, but not ones that might immediately make sense of sound. “malloc” is a C function that allocates memory in which code executes. But a simple hack takes the output of a compiler, and makes sound files out of it. It’s the equivalent disconnecting the pipe from a widget-making factory, and instead of producing useful tools, making cool shapes out of sugary icing – useless and delicious. It’s a sonification of the memory allocation and reading process itself, so that patterns in that data, applied to an auditory timescale, form oscillations, blips and bleeps, and sometimes, sounds that to our ears begin to resemble synthesized basslines and percussion.

    You actually don’t have to know anything about code to try this out; you just need to paste some lines into a command line. That means you could make your own sounds with the tool if you like. (Your life will be easier if you use Linux or OS X; Windows users will need to look up how to get a UNIX command line working – like Cygwin or GOW.)

    The author has already posted some “musical” examples to SoundCloud. My favorite is the first one; it’s almost listenable as a glitch track. (More than almost, actually, at least if you’re a bit weird like me; I’ve been oddly soothed by letting it run for a bit in the background.)

    Creative Commons-licensed – non-commercial, so sorry, you can’t turn in this file as the music bed for that Audi ad you were commissioned to make. (And you were all set to explain to them that this is what “dubstep” means to kids now.)

    Sounds like it can also make some damned fine basslines. malloc(), the new 303:

    This one… gets more interesting later. (Best use of this comment ever: “where’s the drop?”)

    So good.

    The project is the work of Thomas Gordon Lowrey IV, aka gordol. On his GitHub, he makes all sorts of productive things. None can match for me taking 67 lines of code and nerding out.

    https://github.com/gordol/malloc-ld_preload-sounds

    It’s also fun watching SoundCloud decide what tracks should be related. Dear Universal: try to take this down.

    Thank you, Myles Ashley Borins.

    The post Listen as a Compiler Makes Weirdly Good Blippy, Glitchy IDM Sounds [Free Tools] appeared first on Create Digital Music.

    by Peter Kirn at July 28, 2014 07:10 PM

    July 25, 2014

    Ubuntu Studio » News

    Ubuntu Studio 14.04.1 Released

    A new point release of the Trusty Tahr LTS has been released. If you already have Ubuntu Studio Trusty installed, you will have the latest updates so no need to do a fresh install. Ubuntu release notes: http://wiki.ubuntu.com/TrustyTahr/ReleaseNotes

    by Kaj Ailomaa at July 25, 2014 08:07 AM

    July 23, 2014

    GStreamer News

    GStreamer OpenMAX IL wrapper plugin 1.2.0 release

    The GStreamer project is proud to announce a new release of the GStreamer OpenMAX IL wrapper plugin for the API and ABI-stable 1.x series of the GStreamer multimedia framework.

    This plugin wraps available OpenMAX IL components and makes them available as standard GStreamer elements.

    Check out the release notes for gst-omx, or download tarballs for gst-omx,

    July 23, 2014 12:00 PM

    July 20, 2014

    linux.autostatic.com » linux.autostatic.com

    Wolfson Audio Card for Raspberry Pi

    Just ordered a Wolfson Audio Card for Raspberry Pi via RaspberryStore. I asked them about this audio interface at their stand during the NLLGG meeting where I did a presentation about doing real-time audio with the RPi and they told me they would ship it as soon as it would become available. They kept their word so I'm hoping to mount this buddy on my RPi this very week. Hopefully it will be an improvement and allow me to achieve low latencies with a more stable RPi so that I can use it in more critical environments (think live on stage). It has a mic in so I can probably set up the RPi with the Wolfson card quite easily as a guitar pedal. Just a pot after the line output, stick it in a Hammond case, put guitarix on it and rock on.


    Wolfson Audio Card for Raspberry Pi

    by Jeremy at July 20, 2014 07:28 PM

    July 19, 2014

    GStreamer News

    GStreamer Core, Plugins and RTSP server 1.4.0 stable release

    The GStreamer team is pleased to announce the first release of the stable 1.4 release series. The 1.4 release series is adding new features on top of the 1.0 and 1.2 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework.

    Binaries for Android, iOS, Mac OS X and Windows are provided together with this release.

    The stable 1.4 release series is API and ABI compatible with 1.0.x, 1.2.x and any other 1.x release series in the future. Compared to 1.2.x it contains some new features and more intrusive changes that were considered too risky as a bugfix.

    Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, or gst-rtsp-server, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav, or gst-rtsp-server.

    Check the release announcement mail for details and the release notes above for a list of changes.

    Also available are binaries for Android, iOS, Mac OS X and Windows.

    July 19, 2014 05:00 PM

    July 17, 2014

    Create Digital Music » Linux

    24 Knobs, 8 Faders, 16 Buttons, in a Launchpad Form: Launch Control XL

    LCX_3quarter

    If you’re reading this, and if you care about controllers at all, you’ve probably got one. Now the question is, what are you missing? LaunchControl XL is coming with a whole mess of handy faders and knobs if you’ve got more controls than you can map.

    In fact, while it would make an utterly horrid marketing statement, I would dub the slogan of this hardware like this:
    Twist knobs without having to constantly press shift and select keys or give up having some faders.

    There’s Push, of course, the Ableton-controlling flagship, complete with pressure- and velocity-sensitive grid. There’s AKAI’s former APC, which already has a full complement of faders, encoders, and triggers. Beyond that, we’re talking about various combinations of faders and knobs and triggers in smaller controllers in some combination. For example:

    There’s the Novation Launchpad – built like a tank, dirt cheap, just a grid.

    There’s the new AKAI APC mini – grid with faders, but no knobs.

    There’s the Novation LaunchControl – knobs and some pads, but no faders.

    Well, now Novation is back with the LaunchControl XL. It’s knobs, yes – but more knobs. And those knobs get their own colored indicators so you know what they’re controlling. And now it has faders, too. And if it doesn’t sell like hotcakes to everyone, betcha it sells like hotcakes to people who have just a Launchpad.

    24 knobs in three rows of eight – which maps conveniently to Live
    Multicolored indicators on the knobs for multiple functions
    Driver-free (so if you’re using Bitwig or Renoise on Linux, you’re in, too)
    16 multi-color buttons give you track focus, mix controls
    Works on iOS, too, via Camera Connection Kit

    £159.99, coming late August, which is also roughly when we should have one in for review.

    More pics and a video… (though I didn’t personally take the musical style in the vid, maybe you will – )

    LCXL_withlaunchpad

    LCXL

    Significantly, whether that video is your cup of tea or not, you can watch an in-depth video here on how they did what they did and download the set to have a look. So, we can all get back to making weird, dancefloor-clearing IDM if we really want to. (Hey, if she or he is still on the dance floor, that may be the one for you. Nerd love. The best.)

    The post 24 Knobs, 8 Faders, 16 Buttons, in a Launchpad Form: Launch Control XL appeared first on Create Digital Music.

    by Peter Kirn at July 17, 2014 02:56 PM

    July 16, 2014

    Create Digital Music » Linux

    Fork this Chant: GitHub Goes Gregorian, with Open Source Notation

    Can I get an Amen break?

    Can I get an Amen break? Photo (CC-BY) MyBiggestFan.

    Before there was computer code, there was music notation. And before there was forking code or remixing music, there were centuries of variations to the musical code, stored in notation. So it’s fitting that musicians would begin to use GitHub – built originally as a repository for programmers – to store notation.

    And that means that in addition to music software and the like, you can find the WWII-era Nova Organi Harmonia organ accompaniments today on GitHub. Adam Wood, Director of Music with St. Stephen’s Episcopal Church in Hurst, Texas, made the addition, with help from a team including Jeff Ostrowski. The GitHub repository is hosted by the Church Music Association of America.

    For musicologists and composers alike, Git seems a perfect fit. It makes it easy to track the contributions of any number of people, to file and manage variations, and to keep track of revisions over time.

    In this case, the project uses LilyPond, an open source language for scores I’ve praised in the past. Because it’s text-based, that means you can track changes fairly easily. (The same would be true of interchange format MusicXML.)

    Indeed, even for an individual musical user, Git could be a useful way to backup materials, access them online, and keep track of revisions – even before you get into the utility of collaboration.

    Wood tells Wired that the project, in its infancy, improves the accessibility of the music, and calls GitHub “a much more stable and content-centric approach than warehousing your creative output on a blog or (good lord) on your own computer.”

    I’d love to see what others might do with this. After a recent computer crash during a sound check, I’m now keeping my open source tools and materials for live performance on GitHub – more on that migration soon – and using the cloud for proprietary stuff, too.

    What tools do you use online? And are you using GitHub (or other similar repository tools) for music? Let us know in comments.

    Holy Octocat! There’s Church Music on GitHub Now [Wired]
    Nova Organi Harmonia (Organ Accompaniments) [Corpus Christi Watershed blog - who put these online to begin with]
    and: https://github.com/CMAA/nova-organi-harmonia

    Oh, and do let us know if you come up with a creative use for this repository, too.

    The post Fork this Chant: GitHub Goes Gregorian, with Open Source Notation appeared first on Create Digital Music.

    by Peter Kirn at July 16, 2014 02:12 PM

    July 15, 2014

    KXStudio News

    DISTRHO New release pack (2014-07-16)

    DISTRHO has a new release!

    In this release we cleaned up all the plugins, added new ones and removed those that we not considered good enough.
    Standalones are no longer available. Highlife was removed as a requested by its authors.

    The plugins we added to Ports are:

    • Dexed
    • KlangFalter
    • MVerb
    • Nekobi
    • Obxd
    • PitchedDelay

    Additionally we made a new plugin - ProM - a music visualizer as audio plugin based on projectm.

    See the plugins and ports sections on DISTRHO's website for screenshots and downloads.
    The complete source code is available at https://github.com/DISTRHO/.

    by falkTX at July 15, 2014 11:28 PM

    Airtime News

    Airtime 2.5.1a, minor security release with SSL login

    The Broadcaster theme for Newscoop features the integration of Airtime functionality

    The Broadcaster theme for Newscoop features the integration of Airtime functionality

    This latest security maintenance release, Airtime 2.5.1a is a recommended update for anyone hosting multiple Airtime installations on a single web server. It resolves a critical security issue related to user accounts in Airtime versions 1.6.0 to 2.5.1. However, web servers that are hosting single Airtime installations are not affected.

    Another security enhancement in this release is that the administration interface is accessed over https by default, using the method described in the Airtime manual.

    In the last minor release, 2.5.1, Airtime improved the reliability of program scheduling with linked shows, and added important bugfixes to station and user timezone handling.

    Introducing Airtime's website theme: Broadcaster

    Working on new features for The Scope radio station, based at Ryerson University, the Airtime team have been working closely with our Newscoop theme developers to offer a brand new Broadcaster theme. This theme is customised for radio broadcasters and offers Airtime users even more functionality and control for a full online radio experience. The design is based on our popular Newscoop theme, Rockstar, designed by Stephanie Miebach and Christian Kobben. One of the distinctive features of this theme is how it integrates Airtime widgets for weekly schedules and HTML5 audio playback.

     

    The Program Grid in Broadcaster features the radio program schedule integrated in the web design

    The Program Grid in Broadcaster features the radio program schedule integrated in the web design

    You can find out more about Broadcaster:

    Airtime 2.5.0 introduced custom logging

    The last major release, Airtime 2.5.0, enabled playout logging in the exact format you require and the ability to export that data in CSV or PDF file formats. This is a great feature for professional radio stations who need an organised (digital) paper trail. Advertisers and stakeholders, the DJ community and listeners benefit from having easy access to detailed playout history in formats that are easy to share forward.

    Template customisation makes data broadcast ready

    The playout history templates can be customized to comply with the broadcasting regulations in your country. This feature also enables you to see playback statistics on each file and show in your library. That data can be edited manually, for corrections or logging of analogue sources.

    Airtime is open source broadcast automation, playout and scheduling software.

    What's next?

    The Airtime team is planning a new tool to connect radio producers and podcasters with radio stations. We'd like to hear your feedback about how we can build this tool to suit your needs. Join the conversation over on our forum and stay tuned in 2014!

    • Don't forget, you can get started with a free trial of Airtime Pro today!

    July 15, 2014 06:13 PM

    Linux Audio Announcements - laa@linuxaudio.org

    Re: [LAA] jackwsmeter 1

    From: Guillaume Pellerin <lists@...>
    Subject: Re: [LAA] jackwsmeter 1
    Date: Jul 15, 5:57 pm 2014

    Hi Fred,

    Great project!
    I get this:

    momo@wm22:~/dev/audio/jackwsmeter$ make
    CC jackwsmeter-jackwsmeter.o
    jackwsmeter.c: In function ‘callback_http’:
    jackwsmeter.c:92:3: error: too few arguments to function
    ‘libwebsockets_serve_http_file’
    In file included from jackwsmeter.c:41:0:
    /usr/local/include/libwebsockets.h:1077:1: note: declared here
    jackwsmeter.c:125:7: error: ‘LWS_CALLBACK_SET_MODE_POLL_FD’ undeclared (first
    use in this function)
    jackwsmeter.c:125:7: note: each undeclared identifier is reported only once for
    each function it appears in
    jackwsmeter.c:129:7: error: ‘LWS_CALLBACK_CLEAR_MODE_POLL_FD’ undeclared (first
    use in this function)
    make: *** [jackwsmeter-jackwsmeter.o] Erreur 1

    Cheers,
    Guillaume
    _______________________________________________
    Linux-audio-announce mailing list
    Linux-audio-announce@lists.linuxaudio.org
    http://lists.linuxaudio.org/listinfo/linux-audio-announce

    read more

    July 15, 2014 06:00 PM

    July 14, 2014

    Create Digital Music » Linux

    This Free Tool Will Make Any Mobile Browser Into a Multi-Touch Music Controller

    Hey, look: a controller, right in your browser, with drag-and-drop editing. No app needed.

    Hey, look: a controller, right in your browser, with drag-and-drop editing. No app needed.

    Tablet or phone or touch-enabled desktop computer – now it doesn’t matter. A free tool called (for the moment) Nexus lets you make any browser a canvas for music. iOS, Android, Windows, Mac – if the browser is there, your creations become omni-platform.

    Shown at the NIME (New Interfaces for Musical Expression) conference in London earlier this month, Nexus is the most complete foundation for this idea seen yet. And since it’s free, it’s open to others to build upon. Right out of the box, it includes basic interface widgets obviously inspired by Lemur (and apps like TouchOSC), so you get faders and knobs and multi-touch arrangements of balls and keyboards and so on. But because it’s all built with Web tech, anyone can create any interface they imagine – with a custom look and feel, and complete with animations. And even in the browser, it uses OSC (Open Sound Control), for flexibility with a range of commercial or custom-built software.

    Various demos are featured in a video:

    There are a few ways you can work with Nexus, depending on whether you’re an end user or a coder, and which tools you prefer:

    1. Drag and drop in a browser. Take any modern browser on desktop or tablet, and you can make your interfaces without coding at all using NxDrop. You can design right on the device, or build on a computer and then send to a mobile gadget.

    2. Work with the browser to make sound. You can interface directly with the Web Audio API, meaning you can both create your interface in the browser and use it with sound.

    3. Work with libraries like libpd. Another way to integrate interface and sound engine is with tools like libpd, the open source Pure Data engine, which you’ll see in some of the examples.

    4. Make interfaces with – and for – Max/MSP. Integration features with Max make it really easy to automatically route messages, and even (in one demo) to use Max to help create the interfaces themselves. That should be welcome for both Max and Max for Live users.

    5. Code with JavaScript. It’s clear that Nexus has some potential for non-coders right now, and that more ready-to-use applications will come in time if it attracts interest. In the meanwhile, though, if you do Web technologies as your day job, you’ll be happy as a pig in slop. With just a few lines of JavaScript and HTML5, you can code interfaces directly.

    If you do want to give it a go – and you don’t necessarily know about code or Web server operation – there are a couple of useful video tutorials complementing the resources on the official site. These walk you Mac users (works reasonably well on Linux, too, or a Windows *nix setup of some kind) through the Web server bits and gets you up and running:

    The advantage of all of this is, controllers can be distributed and shared and operate independent of platform. You could build a synth and let someone run it in a browser or a simple cross-platform app. You could have backups of your live rig run if your iPad breaks or is stolen. You can make mobile music ensembles, or give friends controls over a music creation for jamming. And you know your controllers aren’t tied to a single device or app – they’ll run on whatever you have, making them future-proof.

    So far, Nexus is a starting point. It isn’t as polished in look and feel or installation as dedicated apps; you’ll need to do a little DIY (like installing a Web server, though there’s a good tutorial below). It receives data, but doesn’t send it yet, though that’s on the agenda. It seems some graphic designers could give the whole thing a better look, and the drag-and-drop app could be cleaner. And the name needs some work, because it’s too close to Google’s line of mobile devices. (Anyone got any ideas?)

    But the technology works beautifully. And on a project-by-project basis, there’s no question it can begin to rival those better-known apps. There’s already a tool called Vox that converts existing TouchOSC layouts for use with Nexus.

    There’s quite a lot of work done already – perhaps the most so far along these lines – thanks to the terrific labors of the team Ben Taylor, Jesse Allison, and Yemin Oh (of Louisiana State University).

    And there are some interesting projects already. In addition to the video above, some of the LSU folks are working with the idea of laser-cut overlays, adding tactile feedback to tablets. I had a go on their iPads, and the results were impressive – it was still nearly as smooth running my fingers along the iPad, but my fingers could find their way to notes, as you would with frets or keys.

    OLYMPUS DIGITAL CAMERA

    OLYMPUS DIGITAL CAMERA

    OLYMPUS DIGITAL CAMERA

    Lindsey Hartman has made a patch remixing of Imogen Heap, showing how Max and Nexus combine (photo via suncanon Instagram):

    imogen_nexus

    You’ll find all the code in a BSD license, with loads of documentation, on GitHub:

    https://github.com/lsu-emdm/nexusUI

    No need to dive into the code, though. At NIME, we had people up and running after just a couple of minutes following directions to install a Web server. The main site will take you straight to the getting started tutorials and free downloads:

    http://www.nexusosc.com

    Academics (or the technically curious), check out the full paper:
    Simplified Expressive Mobile Development with NexusUI, NexusUp and NexusDrop

    I’m curious to see what you do with this. And I do hope some intrepid Web designers reading this venture in, as well, or let us know if this might interoperate with other browser music projects.

    nexusUI

    The post This Free Tool Will Make Any Mobile Browser Into a Multi-Touch Music Controller appeared first on Create Digital Music.

    by Peter Kirn at July 14, 2014 05:10 PM

    Linux Audio Announcements - laa@linuxaudio.org

    [LAA] MMA Version 14.07 now available

    From: Bob van der Poel <bob@...>
    Subject: [LAA] MMA Version 14.07 now available
    Date: Jul 14, 7:04 am 2014

    --001a113452562ec04a04fe03c3b6
    Content-Type: text/plain; charset=UTF-8

    A stable release, version 14.07, of MMA--Musical MIDI Accompaniment
    is available for downloading. In addition to a number of bug fixes
    and optimizations, MMA now features:

    - Works with Python 2.7 or 3.x
    - Plectrum articulate
    - MIDI enhancements
    - Lots of minor enhancements and bug fixes

    Please read the file text/CHANGES-13 for a complete list of changes.

    MMA is a accompaniment generator -- it creates midi tracks
    for a soloist to perform with. User supplied files contain
    pattern selections, chords, and MMA directives. For full details
    please visit:

    http://www.mellowood.ca/mma/

    If you have any questions or comments, please send
    them to: bob@mellowood.ca

    --
    **** Listen to my FREE CD at http://www.mellowood.ca/music/cedars ****
    Bob van der Poel ** Wynndel, British Columbia, CANADA **
    EMAIL: bob@mellowood.ca
    WWW: http://www.mellowood.ca

    --001a113452562ec04a04fe03c3b6
    Content-Type: text/html; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable


    A stable release, version 14.07, of MMA-=
    -Musical MIDI Accompaniment
    is available for downloading. In addition to=
    a number of bug fixes
    and optimizations, MMA now features:

    =C2=
    =A0- Works with Python 2.7 or 3.x

    =C2=A0- Plectrum articulate
    =C2=A0- MIDI enhancements
    =C2=A0- Lots of=
    minor enhancements and bug fixes

    Please read the file text/CHANGES-=
    13 for a complete list of changes.
    =C2=A0
    MMA is a accompaniment gen=
    erator -- it creates midi tracks

    for a soloist to perform with. User supplied files contain
    pattern selec=
    tions, chords, and MMA directives. For full details
    please visit:


    >=C2=A0=C2=A0 http://www.mellowood=
    .ca/mma/



    If you have any questions or comments, please send
    them to:
    =3D"mailto:bob@mellowood.ca">bob@mellowood.ca


    --
    **** Listen=
    to my FREE CD at
    =3D"_blank">http://www.mellowood.ca/music/cedars
    ****

    Bob van der Poel ** Wynndel, British Columbia, CANADA **
    EMAIL:
    =3D"mailto:bob@mellowood.ca" target=3D"_blank">bob@mellowood.ca

    WWW:=
    =C2=A0 http://www.me=
    llowood.ca



    --001a113452562ec04a04fe03c3b6--

    read more

    July 14, 2014 08:00 AM

    July 12, 2014

    GStreamer News

    GStreamer Core, Plugins and RTSP server 1.3.91 release candidate

    The GStreamer team is pleased to announce the second release candidate of the stable 1.4 release series. The 1.4 release series is adding new features on top of the 1.0 and 1.2 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework.

    This release candidate will hopefully shortly be followed by the stable 1.4.0 release if no bigger regressions or bigger issues are detected, and enough testing of the release candidate happened. The new API that was added during the 1.3 release series is not expected to change anymore at this point.

    Binaries for Android, iOS, Mac OS X and Windows are provided together with this release.

    The stable 1.4 release series is API and ABI compatible with 1.0.x, 1.2.x and any other 1.x release series in the future. Compared to 1.2.x it contains some new features and more intrusive changes that were considered too risky as a bugfix.

    Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, or gst-rtsp-server, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav, or gst-rtsp-server.

    Check the release announcement mail for details and the release notes above for a list of changes.

    Also available are binaries for Android, iOS, Mac OS X and Windows.

    July 12, 2014 05:00 PM

    July 11, 2014

    Hackaday » » digital audio hacks

    Party Ready Mini LED Volume Tower

    Audio LED Light Tower

    There are many very cool visual effects for music, but the best are the kind you build yourself. [Ben's] mini LED volume towers adds some nice bling to your music.

    [Ben] was inspired to created this project when he saw a variety of awesome stereo LED towers on YouTube (also referred to as VU meters). We have even featured a few VU meters, one very recently. [Ben] goes over every detail, including how to test your circuit (a very important part of any project). The schematic is deceptively simple. It is based on the LM3914 display driver IC, a simple chained comparator circuit is used to control the volume bar display. All you really need is a 3D printer to make the base, and you can build this awesome tower.

    See the completed towers in action after the break. What next? It would be cool to see a larger tower that displays frequency magnitude!


    Filed under: digital audio hacks, led hacks

    by Nicholas Conn at July 11, 2014 02:01 AM

    July 10, 2014

    Create Digital Music » open-source

    Transform Sounds for Free, with Tools Made with MeeBlip anode by Diego Stocco

    FFS CA Convoluting Anode Web

    The technique is called convolution, and it uses the power of digital audio theory to combine sounds, as if one is heard “inside” another. And if you’ve heard of it before, you probably associate it with reverb – rightfully so, as you can produce highly detailed, realistic reverberation with the technique. But as celebrated film and TV composer Diego Stocco has shown us previously, you can use that same potential to create sounds that would be otherwise impossible.

    And it means you can fuse the sounds of a synthesizer with totally unrelated sounds to create something unlike you’ve ever heard before.

    Diego Stocco recently picked up our own monosynth, the MeeBlip anode. Let me be a bit humble here for a moment. The hardware alone really doesn’t do the work. We tried to make a synthesizer that has its own personality, that inspires people. But it’s really a lot to do with the musician who picks up what we designed: Diego makes sounds with anode that sound like him, that don’t sound like just another analog monosynth – gorgeous, droning detuned hums reminiscent of a just-discovered, ancient folk instrument.

    The message of what Diego is doing is also that you aren’t restricted to using just the sound of a synth directly. It can be a machine for producing ingredients to use elsewhere. He has an ear for making new percussive creations with this approach, as we’ve seen previously:

    Cure Dull Sound and Transform Rhythms By Adventuring Into Convolution [Watch]

    With MeeBlip anode, every aspect of the hardware became the starting point for something new – even the sound of turning off the power supply. The deep intonations of anode’s pitched sounds become a dark, pulsating hum. Higher harmonies buzz like bees, the edge of the analog filter turning into odd, otherworldly colors. Others become pitched, but sound like the resonance of some hitherto-uninvented synthetic material from the future. Alien insect swarms? Check. The inside of the lungs of an android? Got it. And yes, you can even work with some of the sounds as reverbs, but different in timbre than what you’d normally here.

    You can try out these 15 sounds for free, using any convolution processor that accepts audio files as impulses. On Ableton Live Suite 9, for instance, you can drag and drop these onto the new Convolution Reverb and Convolution Reverb Pro. (The “Pro” version even sees the whole folder as a collection.) The Space Designer Pro in Apple’s Logic works nicely, as well. Freeverb is an open source option and includes VST builds.

    For another tutorial on convolution (minus Diego’s clever creative percussion ideas, but a good companion to his work):
    How to Use Convolution for Reverb & Effects [Tuts+]

    15 sounds is already a lot to start with; I barely got round to writing this article as I got distracted listening to even some semi-boring default drum loops in Ableton Live through them. Feeding rhythmic material works really well, either mixed or completely wet, and that’s just as a starting point. I now also have to hook up my own anode and try capturing impulses; there’s no way not to be inspired by this if you’re addicted to sound design.

    Still, I love listening to Diego’s own compositional ideas. Here, he applies this and his other libraries to a music track. Keep listening – it starts minimal, then heats up.

    Shameless plug, but because we haven’t mentioned it much: yes, you can now buy a MeeBlip anode anywhere worldwide. They’re also gradually arriving in dealers in North America and Europe.
    MeeBlip

    But back to not spending money, just enter your email address and you can download all the WAV files (24-bit) for use as impulses. If you don’t want to donate to Diego, just type a ’0′ in the amount form and the fields for your credit card information magically disappear.

    FFS // Convoluted Anode Bonus [Free Download]

    For more on the whole series, see Diego’s site

    I’d be really interested to hear tracks made with this, so get in touch if you use them. And let us know if you discover other convolution techniques or try making some impulses of your own.

    The post Transform Sounds for Free, with Tools Made with MeeBlip anode by Diego Stocco appeared first on Create Digital Music.

    by Peter Kirn at July 10, 2014 06:12 PM

    Music, Programming and a Cat

    Laborejo 2 Alpha Video DevLog

    Youtube link to watch the videos

    Here are five short videos so far.

    I think they are good to watch.

    So "like" and share and comment all this stuff, please!

    Nils

    July 10, 2014 05:56 PM

    July 09, 2014

    blog4

    32 years Tron

    32 years ago the movie Tron was released. I was on vacation in Japan with my father when we saw posters of that film and we both became hysterical (and that in a country which already made me hysterical) about it and saw it eventually in a cinema either in Tokyo or Kyoto, complete with japanese subtitles.
    The soundtrack is by Wendy Carlos who also did the amazing music for Clockwork Orange ten years before, conceptual designer team included Moebius and Syd Mead.
    https://www.youtube.com/watch?v=of-IF7R-fgo

    by herrsteiner (noreply@blogger.com) at July 09, 2014 02:46 PM

    July 08, 2014

    Hackaday » » digital audio hacks

    MIDI And Vintage FM Synthesis

    FM

    Before the days when computers could play and record audio that far surpassed the quality of CDs, sound cards were very, very cool. Most audio chips from the 80s, from the Commodore SID is pretty much a synth on a chip, but you can also find similar setups in ancient ISA sound cards. [Emilio] pulled one of these cards with an ADLIB OPL2 chip on it, and used a PIC micro to create his very own FM synthesis synth (IT, translatatron, although Google is screwing up the formatting).

    The Yamaha YM3812 chip, otherwise known as the OPL2, was a fairly complete synthesizer in a very tiny package using FM synthesis for some very unique sounds. Once [Emilio] had the PIC sending commands to the sound chip, he added MIDI support, allowing him to play this vintage ‘synth on a chip’ with a keyboard instead of a tracker.

    Judging from the video below, it sounds great, and that’s with [Emilio] mashing the keys for a simple demo.


    Filed under: classic hacks, digital audio hacks

    by Brian Benchoff at July 08, 2014 08:00 PM

    Objective Wave

    Some Hydrogen features

    Long time not posting on the blog, but I have been busy working on a few requirements for Hydrogen, the open-source drum-machine (http://www.hydrogen-music.org).

    Two features that are already finished:

    I am now in the middle of coding the possibility to have multiple banks per instrument. This would allow to for example have snare drum top and bottom, or drums overhead. Although not finished yet, it’s (kind of) functional and available here: https://github.com/blablack/hydrogen/tree/multi_bank_per_instrument


    by blablack at July 08, 2014 05:10 PM

    July 07, 2014

    Linux Audio Announcements - laa@linuxaudio.org

    [LAA] Qtractor 0.6.2 - The Boson Walk Beta is out!

    From: Rui Nuno Capela <rncbc@...>
    Subject: [LAA] Qtractor 0.6.2 - The Boson Walk Beta is out!
    Date: Jul 7, 7:28 pm 2014

    So it's summer, they say.

    White bright and light pastel colors sparkling on every corner and turn.
    Cheesy and silly season, they say. Alas, southerners don't apply. Sorry
    about that. Of course I mean the hemisphere, obviously.

    For whom it might concern, all anxiety has come to an end.

    Indeed.

    It all relates back to this last May 3, when a not-so-formal meeting
    (aka. workshop) took place while during LAC2014@ZKM-Karlsruhe, where
    some pertinent and undeniable requests were dodged and framed to a
    "soonish" implementation. And guess what?

    Yup, the "soonish" are no more, or so I think.

    Qtractor 0.6.2 (boson walk beta) is out!

    Perhaps an additional word is due though, about the riddling code-names
    that are branding the post-TYOQA beta releases. They have no personal
    nor logical sense, I assure you. Perfectly arbitrary now. Everything in
    life and the universe is way more unconventional than just a name.

    Without further assay.

    Qtractor is an audio/MIDI multi-track sequencer application written in
    C++ with the Qt4 framework. Target platform is Linux, where the Jack
    Audio Connection Kit (JACK) for audio and the Advanced Linux Sound
    Architecture (ALSA) for MIDI are the main infrastructures to evolve as a
    fairly-featured Linux desktop audio workstation GUI, specially dedicated
    to the personal home-studio.

    Release highlights:
    * Plugins activation MIDI controller / automation (NEW)
    * LV2 UI Idle and Show (>= Qt5) interface support (NEW)
    * Discrete editing of automation curve node velues (NEW)
    * Missing audio/MIDI files and plugins warning message (NEW)
    * MIDI note drawing on tempo-map changes (FIX)
    * Automation curves re-adjusted to tempo-map changes (FIX)


    Website:
    http://qtractor.sourceforge.net

    Project page:
    http://sourceforge.net/projects/qtractor

    Downloads:
    http://sourceforge.net/projects/qtractor/files

    - source tarball:
    http://download.sourceforge.net/qtractor/qtractor-0.6.2.tar.gz

    - source package (openSUSE 13.1):

    http://download.sourceforge.net/qtractor/qtractor-0.6.2-12.rncbc.suse131.src.rpm

    - binary packages (openSUSE 13.1):

    http://download.sourceforge.net/qtractor/qtractor-0.6.2-12.rncbc.suse131.i586.rpm

    http://download.sourceforge.net/qtractor/qtractor-0.6.2-12.rncbc.suse131.x86_84.rpm

    - quick start guide & user manual (severely outdated, see wiki):
    http://download.sourceforge.net/qtractor/qtractor-0.5.x-user-manual.pdf

    - wiki (help wanted!):
    http://sourceforge.net/p/qtractor/wiki/

    Weblog (upstream support):
    http://www.rncbc.org

    License:
    Qtractor is free, open-source software, distributed under the terms
    of the GNU General Public License (GPL) version 2 or later.

    Change-log:
    - Prevent linear and spline automation curve modes for all integer
    valued subjects. Also, make sure those values are rounded to the nearest
    integer away from zero.
    - Fixed save of LV2 Presets for plugins with state files.
    - A man page has beed added (making up Gürkan Sengün's work on debian,
    thanks).
    - When moving plugins by eg. drag-and-dropping across tracks, automation
    curves were being left behind, maybe leading to unpredictable mistaken
    behavior. Hopefully, not anymore.
    - Translations install directory change.
    - Automation curves are now automatically re-adjusted to tempo map node
    changes (after a ticket by Holger Marzen, thanks).
    - Audio/MIDI files or plugins found missing on session load are now
    subject for an explicit modal warning message and prompt for an
    immediate session backup salvage.
    - Changing instrument plugin p [message continues]

    read more

    July 07, 2014 08:00 PM

    rncbc.org

    Qtractor 0.6.2 - The Boson Walk Beta is out!

    So it's summer, they say.

    White bright and light pastel colors sparkling on every corner and turn. Cheesy and silly season, they say. Alas, southerners don't apply. Sorry about that. Of course I mean the hemisphere, obviously.

    For whom it might concern, all anxiety has come to an end.

    Indeed.

    It all relates back to this last May 3, when a not-so-formal meeting (aka. workshop) took place while during LAC2014@ZKM-Karlsruhe, where some pertinent and undeniable requests were dodged and framed to a "soonish" implementation. And guess what?

    Yup, the "soonish" are no more, or so I think.

    Qtractor 0.6.2 (boson walk beta) is out!

    Perhaps an additional word is due though, about the riddling code-names that are branding the post-TYOQA beta releases. They have no personal nor logical sense, I assure you. Perfectly arbitrary now. Everything in life and the universe is way more unconventional than just a name.

    Without further assay.

    Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt4 framework. Target platform is Linux, where the Jack Audio Connection Kit (JACK) for audio and the Advanced Linux Sound Architecture (ALSA) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio.

    Release highlights:

    • Plugins activation MIDI controller / automation (NEW)
    • LV2 UI Idle and Show (>= Qt5) interface support (NEW)
    • Discrete editing of automation curve node values (NEW)
    • Missing audio/MIDI files and plugins warning message (NEW)
    • MIDI note drawing on tempo-map changes (FIX)
    • Automation curves re-adjusted to tempo-map changes (FIX)

    Flattr this

    Website:

    http://qtractor.sourceforge.net

    Project page:

    http://sourceforge.net/projects/qtractor

    Downloads:

    License:

    Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

    Change-log:

    • Prevent linear and spline automation curve modes for all integer valued subjects. Also, make sure those values are rounded to the nearest integer away from zero.
    • Fixed save of LV2 Presets for plugins with state files.
    • A man page has beed added (making up Gürkan Sengün's work on debian, thanks).
    • When moving plugins by eg. drag-and-dropping across tracks, automation curves were being left behind, maybe leading to unpredictable mistaken behavior. Hopefully, not anymore.
    • Translations install directory change.
    • Automation curves are now automatically re-adjusted to tempo map node changes (after a ticket by Holger Marzen, thanks).
    • Audio/MIDI files or plugins found missing on session load are now subject for an explicit modal warning message and prompt for an immediate session backup salvage.
    • Changing instrument plugin programs is now an undo/redo-able command operation, especially for DSSI but also for plugins that come with the LV2 Programs interface extension support (http://kxstudio.sourceforge.net/ns/lv2ext/programs).
    • Drawing, selecting and/or resizing of MIDI note events that extend across tempo/time-signature changes is now made a bit more correctly over the MIDI clip editor (aka. piano-roll), especially regarding to current snap-to-beat setting (after an outstanding ticket by yubatake, thanks).
    • Once again, audio frame/MIDI time drift correction has been slightly refactored to improve MIDI input monitor and timing.
    • Discrete automation curve node values may now be edited via a numerical entry floating spin-box on double-click (as yet another request by AutoStatic aka. Jeremy Jongepier, thanks).
    • Pressing shift/ctrl keyboard modifiers while double-clicking on a plugin list entry now briefly reverses the current View/Options.../Plugins/Editor/Open plugin's editor (GUI) by default option preference.
    • Fixed an old crash lurker when switching output buses that implied a change on the number of audio channels, while on tracks that have (auto-)monitor turned on and at least one active plugin in chain (yet another ticket by AutoStatic aka. Jeremy Jongepier, thanks).
    • MIDI Controller assignment (aka MIDI learn) and/or automation of plugins (de)activation state has been added (as requested by AutoStatic aka. Jeremy Jongepier, thanks).
    • LV2 UI Idle and Show interfaces support added.
    • Allow the build system to include an user specified LDFLAGS (patch by Alessio Treglia aka. quadrispro, thanks).

    Enjoy && Have (lots of) fun.

    by rncbc at July 07, 2014 05:30 PM

    Create Digital Music » open-source

    There’s an Unofficial Eurorack Version of MeeBlip anode

    MeeBlip-Anode-Eurorack-module-e1404588146822

    MeeBlip anode is the monosynth with an analog filter, co-produced with CDM and shipping now worldwide – see meeblip.com – and open source, at GitHub.

    Now, much to our surprise when we opened Synthtopia over the weekend, it seems someone has gone ahead and made a Eurorack version. You can’t buy it – this is a one-off – but it’s certainly a clever idea. 20HP wide, and tons of analog ins and outs: gate, envelope controls, inputs for the analog filter and resonance (the only way to external control resonance, actually, as that’s an all-analog control), plus two outs.

    They’ve also produced an epic demo video. The sound quality isn’t exactly pristine, but some nice musical ideas and it shows off the patching powers clearly.

    Details: Ninstrument, which has some nice things to say about what we’ve done with anode as a synth.

    For a better idea of what anode sounds like, listen to our SoundCloud demos:

    This isn’t the first time someone has tried something like this. Shawn Rudiman in 2012 took the MeeBlip DIY version and built an extraordinary rack module out of it, making it look like a Roland SH-7, and also including CV ins and outs for everything. Also, awesomely, the video seems like it was shot on VHS in the 80s.

    So, for now, anode is available exclusively in a case with MIDI. But I’m curious – how many of you would want a module, and is this what you’d want it to look like?

    One note: while MeeBlip is open source, anyone selling a module like this would need to call it something else — and perhaps list it as “MeeBlip-compatible.” That’s just to avoid confusion in identification and support. This is a one-off, though, so we’re happy to see our logo on the front!)

    The post There’s an Unofficial Eurorack Version of MeeBlip anode appeared first on Create Digital Music.

    by Peter Kirn at July 07, 2014 10:05 AM

    July 05, 2014

    Linux Audio Announcements - laa@linuxaudio.org

    [LAA] jackwsmeter 1

    From: Frederic Peters <fpeters@...>
    Subject: [LAA] jackwsmeter 1
    Date: Jul 5, 6:18 pm 2014

    Hello all,

    Here is the first release of jackwsmeter.

    This is a small utility that gets the signal values of the audio that
    flow through JACK ports and make the peak levels available over a
    websocket link, it's a clean and efficient way to get an overview of
    levels from a serie of jack servers.

    It's available in git at http://repo.or.cz/w/jackwsmeter.git, it's
    released under the GNU GPL v2 or later.

    The release tag is http://repo.or.cz/w/jackwsmeter.git/tag/refs/tags/1


    I hope it can be useful to some people.


    Cheers,

    Fred
    _______________________________________________
    Linux-audio-announce mailing list
    Linux-audio-announce@lists.linuxaudio.org
    http://lists.linuxaudio.org/listinfo/linux-audio-announce

    read more

    July 05, 2014 07:00 PM

    [LAA] [LAU] Guitarix 0.30.0 released

    From: hermann meyer <brummer-@...>
    Subject: [LAA] [LAU] Guitarix 0.30.0 released
    Date: Jul 5, 6:18 pm 2014

    This is a multi-part message in MIME format.
    --------------070709050407090503080608
    Content-Type: text/plain; charset=ISO-8859-1; format=flowed
    Content-Transfer-Encoding: 7bit

    The Guitarix developers proudly present

    Guitarix release 0.30.0

    For the uninitiated, Guitarix is a tube amplifier simulation for
    jack (Linux), with an additional mono and a stereo effect rack.
    Guitarix includes a large list of plugins, support LADSPA plugs, and
    now, new, as well LV2 plugs.

    The guitarix engine is designed for LIVE usage, and feature ultra fast,
    glitch and click free, preset switching, full Midi and/or remote
    controllable (Web UI not included in the distributed tar ball).

    Preset could organized in Banks, so a Bank could represent your "show".
    If you have any issue with Preset loading/creating/handling, please read
    here in our wiki how this stuff work in guitarix. It is straightforward,
    and maybe more intuitive then you guess.
    http://sourceforge.net/p/guitarix/wiki/EnhancedUI/#creating-presets

    This release fix some bugs in our faust based zita-rev1 implementation,
    add LV2 support to the guitarix racks and introduce some new plugs, GX
    based and as well in the LV2 format.
    new plugs:
    * GxDetune (gx / LV2)
    * Baxandall tonestack(gx)
    * GxShimmizita ( LV2)
    * GxSwitchedTremolo (LV2)

    Please refer to our project page for more information:
    http://guitarix.sourceforge.net/

    Download Site:
    http://sourceforge.net/projects/guitarix/

    Forum:
    http://guitarix.sourceforge.net/forum/

    Please consider visiting our forum or leaving a message on
    guitarix-developer@lists.sourceforge.net




    --------------070709050407090503080608
    Content-Type: text/html; charset=ISO-8859-1
    Content-Transfer-Encoding: 7bit




    charset=ISO-8859-1" />
    charset=ISO-8859-1">



    The Guitarix developers proudly present




    Guitarix release 0.30.0





    For the uninitiated, Guitarix is a tube amplifier simulation
    for


    jack (Linux), with an additional mono and a stereo effect
    rack.

    Guitarix includes a large list of plugins, support LADSPA plugs,
    and now, new, as well LV2 plugs.



    The guitarix engine is designed for LIVE usage, and feature
    ultra fast, glitch and click free,  preset switching, full Midi
    and/or remote controllable (Web UI not included in the
    distributed tar ball).



    Preset could organized in Banks, so a Bank could represent your
    "show".

    If you have any issue with Preset loading/creating/handling,
    please read here in our wiki how this stuff work in guitarix. It
    is straightforward, and maybe more intuitive then you guess.

     http://sourceforge.net/p/guitarix/wiki/EnhancedUI/#creating-presets

     

    This release fix some bugs in our faust based zita-rev1
    implementation, add LV2 support to the guitarix racks and
    introduce some new plugs, GX based and as well in the LV2
    format.


    new plugs:

    July 05, 2014 07:00 PM

    Scores of Beauty

    Trees, Music and Lilypond

    In this post I write about some hierarchical aspects of typesetting music with LilyPond. In a way the elements that form a musical score can be split into pieces that stand in a hierarchical relation. We can make use of this relationship to do interesting stuff such as creating templates and injecting tweaks into a score without touching the music source itself. For my personal use I have developed several tools that help me manage my projects in a structured manner. Recently I made them publicly available and today I’ll start introducing them on this blog. This first post is about the theory behind the implementation which I will describe in following articles.

    Compositing Music

    Any piece of music can be seen as a tree — I might say: It is alive ;) . But here I want to look at the way of compositing music. Yes, it is not composing, but assembling parts to a complete piece of engraved music. A piece of music can be seen as a tree with branches from several perspectives. If you look at the printed sheet music, you will find a conductor having a full score on his desk (or in his head) while the individual instrumentalist or singer only deals with the necessary information for performing his own part. The conductor is looking at the whole tree, a single particpant is looking at a single branch.

    Now what does this have to do with typesetting music? Let us first look at a very simple score and dissect it.

    Dissecting Music

    If you enter the music in a lilypond file, you will most likely define variables for every participating musician and then use them in a score block to actually engrave the piece. The names for the variables might for example be:

    violin = \relative c'' { a4 b c d }
    viola = \relative c' { r8 f e4 g f }
    cello = \relative c { c2 bes }
    
    \score {
      <<
        \new Staff { \violin }
        \new Staff { \clef "alto" \viola }
        \new Staff { \clef "bass" \cello }
      >>
    }
    

    This is an easy case: We just have to combine three staves to compose the full score and use the variables for each part — making this an example of the mentioned situation with a conductor and the instrumentalists. Vocal music adds a level of complexity already: each singer needs not only a melody but also lyrics. The variables might be called sopranoMelody, sopranoLyrics, altoMelody and so on. So the singers are looking at two sub-branches – melody and lyrics – for their own voice. This example exposes a strict naming scheme, marking the hierarchy with an upper case letter in the variable name.

    Adhering to such a naming scheme makes it possible to go one step further: Instead of using the music variables directly we can create a (Scheme) function that automatically retrieves the right music variables by selecting them based on a given part of the variable name (you will see later what that means). This way you may not have to type all variables and contexts explicitly. And it will help us circumvent another issue you have to take care of when writing everything explicitly: how to arrange the definition of music variables and score blocks when combining multiple movements to one piece. You can find working solutions on the net, for example in the lilypond-user archive. Rainhold Kainhofers OrchestralLily also deals with this issue, but in this post I want to take a deeper look at the hierarchical aspect behind it.

    Planting a tree

    The next thing to understand is that we can use paths to address branches in a tree. Thinking as a software engineer we call the branching points nodes and can give them names. If every node in our imagined tree has a name every branch and every leaf can be denoted with a path by listing all nodenames from the root up to the one we’re interested in. Such a path might be massInC/kyrie/soprano/melody to point to the melody to be sung by the sopranos in the kyrie movement of a piece called massInC. Now it is easy to separate the lyrics massInC/kyrie/soprano/lyrics, the music for the alto-singers massInC/kyrie/alto/melody, the other movements massInC/gloria/soprano/melody or another piece massInD/kyrie/soprano/melody. These paths are comparable to a file path or a URL in a web address: http://www.music-server.example/massInC/kyrie/soprano/lyrics.

    If the tree structure follows the same naming conventions on all nodes and their child nodes we can apply the same methods to all leaves — or may I say fruits? In the given example of a hypothetical “massInC”, we want to reach the melody of the soprano voice. From the root of the tree the first node is named “massInC”. From this node emerge five branches with nodes named “kyrie”, “gloria”, “credo”, “sanctus” and “agnus-dei”. And each of these five nodes branch into four nodes named “soprano”, “alto”, “tenore” and “basso”, which carry each two fruits named “melody” and “lyrics”.

    The way to massInC/kyrie/tenore/melody

    The way to massInC/kyrie/tenore/melody (click to enlarge)

    Now that we have this concept in place, implemented through the strict naming scheme, let us recall what we’re after: we want to retrieve the right music variables through a function in order to put them in the right place in the score structure. To achieve this we will store the content in a special kind of variable, an “association list” with the name of musicTree.
    (Please note: from now on I will use Scheme code which is partly non-trivial. If you don’t understand it in detail please don’t give up on the post. Its main intent is to demonstrate the underlying concepts and not the concrete implementation. I will not try to explain how the code actually works but what it is meant to do.)

    We start with writing two functions \putMusic and \getMusic which store and retrieve the content in the musicTree list:

    % the main music tree
    musicTree = #'()
    
    % function to store music in `musicTree`
    putMusic =
    #(define-void-function (parser location path content)(string? ly:music?)
       (let ((pl (string->path path)))
         (set! musicTree (tree-set! musicTree pl content))
         ))
    
    % function to get music from `musicTree`
    getMusic =
    #(define-music-function (parser location path)(string?)
       (let* ((pl (string->path path))
              (content (tree-get musicTree pl)))
         (if (ly:music? content) content (make-music 'SequentialMusic 'void #t))
         ))
    

    To make these commands work, we first have to define the helper functions tree-set! and tree-get. These do the actual work of dealing with the internal list structures.

    % set a value in a tree -- based on nested association lists
    #(define-public (tree-set! tree path val)
       (if (> (length path) 1)
           (let ((tab (assoc (car path) tree)))
             (if (not (pair? tab))(set! tab '((car path))))
             (assoc-set! tree (car path) (tree-set! (cdr tab) (cdr path) val))
             )
           (assoc-set! tree (car path) val))
       )
    % get a value from a tree -- based on nested association lists
    #(define-public (tree-get tree path)
       (let ((ret (assoc (car path) tree)))
         (if (pair? ret)
             (if (> (length path) 1)
                 (tree-get (cdr ret) (cdr path))
                 (cdr ret))
             #f))
       )
    % split a string by '/'
    #(define-public (string->path str)(string-split str #\/))
    

    With those methods available we have the tools to composite parts from a tree, for example the melody and the lyrics of a vocal staff. We can now write a function \vocalStaff that creates a staff and retrieves the melody and the lyrics from the “fruits” of the branch given as a string. Another function SATBgroup can then call \vocalStaff four times to create a choir score:

    % helper function to append strings
    stringAppend =
    #(define-scheme-function (parser location str1 str2)(string? string?)
       (string-append str1 str2))
    
    % create one vocal staff
    vocalStaff =
    #(define-music-function (parser location my-path-to-vocal)(string?)
       ; create a unique name for the voice
       (let ((voice-name my-path-to-vocal))
         #{
           <<
             \new Staff \new Voice = #voice-name { \getMusic \stringAppend #my-path-to-vocal "/melody" }
             \new Lyrics \lyricsto #voice-name { \getMusic \stringAppend #my-path-to-vocal "/lyrics" }
           >>
         #}))
    
    % and now combine four vocal staves to a choir group:
    % create vocal staffs for Soprano, Alto, Tenore and Basso
    SATBGroup =
    #(define-music-function (parser location my-path-to-choir)(string?)
       #{
         \new ChoirStaff <<
           { \vocalStaff \stringAppend #my-path-to-choir "/soprano" }
           { \vocalStaff \stringAppend #my-path-to-choir "/alto" }
           { \vocalStaff \stringAppend #my-path-to-choir "/tenore" }
           { \vocalStaff \stringAppend #my-path-to-choir "/basso" }
         >>
       #})
    

    Now, let us use \putMusic to insert some music into the tree:

    \putMusic "massInC/kyrie/soprano/melody" \relative c'' { c2 d4 c }
    \putMusic "massInC/kyrie/soprano/lyrics" \lyricmode { Ky -- ri -- e }
    \putMusic "massInC/kyrie/alto/melody" \relative c'' { r4 g f e }
    \putMusic "massInC/kyrie/alto/lyrics" \lyricmode { Ky -- ri -- e }
    \putMusic "massInC/kyrie/tenore/melody" \relative c { \clef "G_8" e4 f( g) g }
    \putMusic "massInC/kyrie/tenore/lyrics" \lyricmode { Ky -- ri -- e }
    \putMusic "massInC/kyrie/basso/melody" \relative c { \clef "bass" c4 g4 c~ c }
    \putMusic "massInC/kyrie/basso/lyrics" \lyricmode { Ky -- ri -- e __ }
    

    and engrave it:

    \SATBGroup "massInC/kyrie"
    

    trees-and-music.score_

    Finally the different movements of the composition might be collected this way:

    \score {
      \SATBGroup "massInC/kyrie"
    }
    \score {
      \SATBGroup "massInC/gloria"
    }
    \score {
      \SATBGroup "massInC/credo"
    }
    \score {
      \SATBGroup "massInC/sanctus"
    }
    \score {
      \SATBGroup "massInC/agnusdei"
    }
    

    You can download the whole example here. (The Gloria, Credo, Sanctus and Agnus-Dei movements are to be composed …)

    Let us again line up, what is happening here:

    1. \SATBGroup is called with path "massInC/kyrie"
    2. The function (or template) \SATBGroup calls for all four voices (sopranos, altos, tenors, bassos) — replace tenore with soprano, alto or basso respectively
      \vocalStaff "massInC/kyrie/tenore"
    3. \vocalStaff calls
      <<
        \new Staff { \new Voice = "melody" \getMusic "massInC/kyrie/tenore/melody" }
        \new Lyrics \lyricsto "melody" \getMusic "massInC/kyrie/tenore/lyrics"
      >>
      

    The hierarchical naming and storing scheme makes it possible to separate content and layout. A function \SATBTwo might create two staves — with sopranos and altos in the upper and tenors and bassos in the lower stave — accessing the music with the same paths.

    vocalTwo =
    #(define-music-function (parser location my-path-to-vocal-A my-path-to-vocal-B)(string? string?)
       (let (
              (staff-name (string-append my-path-to-vocal-A my-path-to-vocal-B)) ; a name for the staff-context
              (voice-name-A my-path-to-vocal-A) ; a name for the upper voice-context
              (voice-name-B my-path-to-vocal-B) ; a name for the lower voice-context
              )
         #{
           <<
             \new Staff = #staff-name <<
               \new Voice = #voice-name-A { \voiceOne \getMusic \stringAppend #my-path-to-vocal-A "/melody" }
               \new Voice = #voice-name-B { \voiceTwo \getMusic \stringAppend #my-path-to-vocal-B "/melody" }
             >>
             % align lyrics above the staff and voice A
             \new Lyrics \with { alignAboveContext = #staff-name }
             \lyricsto #voice-name-A { \getMusic \stringAppend #my-path-to-vocal-A "/lyrics" }
             % align lyrics below the staff and voice B
             \new Lyrics \with { alignBelowContext = #staff-name }
             \lyricsto #voice-name-B { \getMusic \stringAppend #my-path-to-vocal-B "/lyrics" }
           >>
         #}))
    
    SATBTwo =
    #(define-music-function (parser location my-path-to-choir)(string?)
       (let ( ; create paths for the four voices
              (soprano (string-append my-path-to-choir "/soprano"))
              (alto (string-append my-path-to-choir "/alto"))
              (tenore (string-append my-path-to-choir "/tenore"))
              (basso (string-append my-path-to-choir "/basso"))
              )
       #{
         \new ChoirStaff <<
           { \vocalTwo #soprano #alto }
           { \vocalTwo #tenore #basso }
         >>
       #}))
    

    With those functions available, you can decide whether to engrave the previously stored music in four or in two staves.
    And to create a score only with the tenors part, you simply call \vocalStaff "massInC/kyrie/tenore".

    Conclusion

    Now we have a method to write template functions and to store music in a structured hierarchical manner.
    Coming back to the image of a tree, the \SATBGroup builds the trunk of the engravement-tree for a whole movement. It delegates to four \vocalStaff calls, which retrieve music from the named branches of the tree.
    And from a software developers point of view the tree represents the musical content — or is kind of a model in the sense of the model-view-controller pattern and the templates are the view on the music-model formed by the tree.

    With these ideas in mind I developed a template framework to be used with LilyPond edition projects. The original framework can be inspected or downloaded from lalily@GitHub, but I’m gradually making it available in a slightly more generic form at the openLilyLib repository. Of course, the implementation of the functions differ from the demo functions above. The next posts will develop the examples exposed in this article towards the existing implementations and introduce the usage of them. And this will also lead us to the edition-engraver, which is another important step towards separation of content and layout.

    by Jan-Peter Voigt at July 05, 2014 09:44 AM

    July 04, 2014

    PID EINS!

    FUDCON + GNOME.Asia Beijing 2014

    Thanks to the funding from FUDCON I had the chance to attend and keynote at the combined FUDCON Beijing 2014 and GNOME.Asia 2014 conference in Beijing, China.

    My talk was about systemd's present and future, what we achieved and where we are going. In my talk I tried to explain a bit where we are coming from, and how we changed focus from being purely an init system, to more being a set of basic building blocks to build an OS from. Most of the talk I talked about where we still intend to take systemd, which areas we believe should be covered by systemd, and of course, also the always difficult question, on where to draw the line and what clearly is outside of the focus of systemd. The slides of my talk you find online. (No video recording I am aware of, sorry.)

    The combined conferences were a lot of fun, and as usual, the best discussions I had in the hallway track, discussing Linux and systemd.

    A number of pictures of the conference are now online. Enjoy!

    After the conference I stayed for a few more days in Beijing, doing a bit of sightseeing. What a fantastic city! The food was amazing, we tried all kinds of fantastic stuff, from Peking duck, to Bullfrog Sechuan style. Yummy. And one of those days I am sure I will find the time to actually sort my photos and put them online, too.

    I am really looking forward to the next FUDCON/GNOME.Asia!

    July 04, 2014 04:43 PM

    July 02, 2014

    Linux Audio Announcements - laa@linuxaudio.org

    [LAA] Vee One Suite 0.5.0 - Officially beta now!

    From: Rui Nuno Capela <rncbc@...>
    Subject: [LAA] Vee One Suite 0.5.0 - Officially beta now!
    Date: Jul 2, 7:17 pm 2014

    Greetings,

    The Vee One Suite of old-school software instruments, primarily slated
    for Linux, featuring synthv1 [1], a polyphonic synthesizer, samplv1 [2],
    a polyphonic sampler and drumkv1 [3], a drum-kit sampler, are officially
    in beta phase now.

    Change-log for the new release:
    - LV2 UI Idle and Show interfaces support added.
    - First attempt to allow a headless stand-alone JACK client application
    run mode, without a GUI, with option given as command line argument
    (--no-gui).
    - A man page has beed added (re. stand-alone JACK client).
    - Reverse sample option and parameter knob added. (samplv1 and drumkv1
    only).
    - Allow the build system to include an user specified LDFLAGS.

    As before, all made available in dual form:
    - a pure stand-alone JACK [4] client with JACK-session, NSM [5] (Non
    Session management) and both JACK MIDI and ALSA [6] MIDI input support;
    - a LV2 [7] instrument plug-in.

    The Vee One Suite are free and open-source Linux Audio software,
    distributed under the terms of the GNU General Public License (GPL) [8]
    version 2 or later.


    The fine print follows ;)

    * synthv1 - an old-school polyphonic synthesizer [1] *

    synthv1 0.5.0 released!

    synthv1 is an old-school all-digital 4-oscillator subtractive
    polyphonic synthesizer with stereo fx.

    LV2 URI: http://synthv1.sourceforge.net/lv2

    website:
    http://synthv1.sourceforge.net
    downloads:
    http://sourceforge.net/projects/synthv1/files
    - source tarball:
    http://download.sourceforge.net/synthv1/synthv1-0.5.0.tar.gz
    - source package:

    http://download.sourceforge.net/synthv1synthv1-0.5.0-17.rncbc.suse131.src.rpm
    - binary packages:

    http://download.sourceforge.net/synthv1synthv1-0.5.0-17.rncbc.suse131.i586.rpm

    http://download.sourceforge.net/synthv1synthv1-0.5.0-17.rncbc.suse131.x86_84.rpm


    * samplv1 - an old-school polyphonic sampler [2] *

    samplv1 0.5.0 released!

    samplv1 is an old-school polyphonic sampler synthesizer with stereo fx.

    LV2 URI: http://samplv1.sourceforge.net/lv2

    website:
    http://samplv1.sourceforge.net
    downloads:
    http://sourceforge.net/projects/samplv1/files
    - source tarball:
    http://download.sourceforge.net/samplv1/samplv1-0.5.0.tar.gz
    - source package:

    http://download.sourceforge.net/samplv1/samplv1-0.5.0-17.rncbc.suse131.src.rpm
    - binary packages:

    http://download.sourceforge.net/samplv1/samplv1-0.5.0-17.rncbc.suse131.i586.rpm

    http://download.sourceforge.net/samplv1/samplv1-0.5.0-17.rncbc.suse131.x86_84.rpm


    * drumkv1 - an old-school drum-kit sampler [3] *

    drumkv1 0.5.0 released!

    drumkv1 an old-school drum-kit sampler synthesizer with stereo fx.

    LV2 URI: http://drumkv1.sourceforge.net/lv2

    website:
    http://drumkv1.sourceforge.net
    downloads:
    http://sourceforge.net/projects/drumkv1/files
    - source tarball:
    http://download.sourceforge.net/drumkv1/drumkv1-0.5.0.tar.gz
    - source package:

    http://download.sourceforge.net/drumkv1/drumkv1-0.5.0-13.rncbc.suse131.src.rpm
    - binary packages:

    http://download.sourceforge.net/drumkv1/drumkv1-0.5.0-13.rncbc.suse131.i586.rpm

    http://download.sourceforge.net/drumkv1/drumkv1-0.5.0-13.rncbc.suse131.x86_84.rpm


    References:

    [1] synthv1 - an old-school polyphonic synthesizer
    http://synthv1.sourceforge.net/

    [2] samplv1 - an old-school polyphonic sampler
    http://samplv1.sourceforge.net/

    [3] drumkv1 - an old-school drum-kit sampler
    [message continues]

    read more

    July 02, 2014 08:00 PM

    [LAA] ZynAddSubFX 2.4.4

    From: Mark D. McCurry <mark.d.mccurry@...>
    Subject: [LAA] ZynAddSubFX 2.4.4
    Date: Jul 2, 7:17 pm 2014


    --CXFpZVxO6m2Ol4tQ
    Content-Type: text/plain; charset=utf-8
    Content-Disposition: inline

    ZynAddSubFX 2.4.4 is out.

    ZynAddSubFX is a general purpose musical synthesizer with a very long list of
    features and capabilities licensed under the GPLv2 License.

    Changelog:
    2.4.4 (28 Jun 2014)
    - Add UI Mousewheel Support
    - Add Spectral Adjust Parameter Rescaling
    - Add Subnote filter smoothing
    - Add Unison derandomization options
    - Add NSM import/export
    - Add NTK UI compatiability
    - (re)Add OSX Support
    - Enhance performance of ADnote and SUBnote
    - Enhance Installer
    - Fix JACK2 specific segfault
    - Fix possible DSSI specific segfaults
    - Fix Unison Regressions
    - Documentation additions
    - Misc bug fixes


    Project page:
    http://zynaddsubfx.sf.net/

    Download:
    http://downloads.sf.net/zynaddsubfx/zynaddsubfx-2.4.4.tar.xz

    Enjoy,
    --Mark McCurry

    --CXFpZVxO6m2Ol4tQ
    Content-Type: application/pgp-signature

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1

    iQEcBAEBAgAGBQJTsDxcAAoJENYPRmmhc6KtRq0H/3jxr3G2acnW5Mpl4CGysNaF
    ndBmK39Yjh74qoY97OblwD8soYkoB3PvboEMq+/npOSPo36+vN7nkjA2wgT0T7Ix
    iPp3WWdAxv69cdkbCzmqIvucw0SHVEUMxrzdP/dznBTjP5WADsF3U/XddlSZTDe5
    jiZcu3vyVPj9/tch0E022FvwrPXqdWyld7udF7AvP73ZyIAPTd5EIrc5KDmycBl2
    8zdEnCxvdhID9q9oeDvV2IE3F3hBWw/MK/GEc7rwFdD0/uLTjIOeAe+RVqFekVNb
    ntJnhob/CplJz46roITLikGvHPKU+YVmu/CRlTHv/P2yGSxFi8rmbfIjDtNVcZo=
    =YHoI
    -----END PGP SIGNATURE-----

    --CXFpZVxO6m2Ol4tQ--

    read more

    July 02, 2014 08:00 PM

    [LAA] Yoshimi 1.2.2 available

    From: Will Godfrey <willgodfrey@...>
    Subject: [LAA] Yoshimi 1.2.2 available
    Date: Jul 2, 7:17 pm 2014

    There are a couple of 'doh' bug fixes.
    A really obscure one!
    Some GUI tidy-ups.
    A few small extensions to existing features.
    Reinstatement of two features that got lost in the mist.

    --
    Will J Godfrey
    http://www.musically.me.uk
    Say you have a poem and I have a tune.
    Exchange them and we can both have a poem, a tune, and a song.
    _______________________________________________
    Linux-audio-announce mailing list
    Linux-audio-announce@lists.linuxaudio.org
    http://lists.linuxaudio.org/listinfo/linux-audio-announce

    read more

    July 02, 2014 08:00 PM

    June 30, 2014

    rncbc.org

    Vee One Suite 0.5.0 - Officially beta now!

    Greetings,

    The Vee One Suite of old-school software instruments, primarily slated for Linux, featuring synthv1, a polyphonic synthesizer, samplv1, a polyphonic sampler and drumkv1, a drum-kit sampler, are officially in beta phase now.

    Change-log for the new release:

    • LV2 UI Idle and Show interfaces support added.
    • First attempt to allow a headless stand-alone JACK client application run mode, without a GUI, with option given as command line argument (--no-gui).
    • A man page has been added (re. stand-alone JACK clients).
    • Reverse sample option and parameter knob added. (samplv1 and drumkv1 only).
    • Allow the build system to include an user specified LDFLAGS.

    As before, all made available in dual form:

    • a pure stand-alone JACK client with JACK-session, NSM (Non Session management) and both JACK MIDI and ALSA MIDI input support;
    • a LV2 instrument plug-in.

    The Vee One Suite are free and open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

    The fine print follows ;)

    synthv1 - an old-school polyphonic synthesizer

    synthv1 0.5.0 released!

    synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx.

    LV2 URI: http://synthv1.sourceforge.net/lv2
    website:
    http://synthv1.sourceforge.net
    downloads:
    http://sourceforge.net/projects/synthv1/files

    Flattr this

    samplv1 - an old-school polyphonic sampler

    samplv1 0.5.0 released!

    samplv1 is an old-school polyphonic sampler synthesizer with stereo fx.

    LV2 URI: http://samplv1.sourceforge.net/lv2
    website:
    http://samplv1.sourceforge.net
    downloads:
    http://sourceforge.net/projects/samplv1/files

    Flattr this

    drumkv1 - an old-school drum-kit sampler

    drumkv1 0.5.0 released!

    drumkv1 an old-school drum-kit sampler synthesizer with stereo fx.

    LV2 URI: http://drumkv1.sourceforge.net/lv2
    website:
    http://drumkv1.sourceforge.net
    downloads:
    http://sourceforge.net/projects/drumkv1/files

    Flattr this

    Enjoy && ever again, have fun.

    by rncbc at June 30, 2014 05:00 PM

    Nothing Special

    The Infamous Cellular Automaton Synth

    It started with the obfuscated C competition... and a youtube video. Well, no it really started with learning about Conway's Game of Life. Err.. It started with a video about a 13 year old girl who was implementing Conway's Game of Life on the raspberry pi... Ahem. I became interested in cellular automata and especially linking it to music. I originally tried to emulate this one liner that was getting passed around on IRC:


    echo "main(i){for(i=0;;i++)putchar(((i*(i>>8|i>>9)&46&i>>8))^(i&i>>13|i>>6));}" | gcc -x c - && ./a.out | aplay

    I tried to implement my own version that used an automaton to do the same sort of thing (I'll let you scratch your head on what it does, or just copy and paste it into your terminal). It took me a while to get it working, but I eventually got an automaton operating successfully on a torus. I then went and obfuscated it thinking of entering it into the IOCC. It looks pretty good:


    echo "main(_i_,i,_,i_i){i_i=30;for(i=7;;i=_i_<<1|_i_>>7)
    {_i_=0;for(_=0;_<8;_++)_i_|=((i_i&1<<((i>>_|i<<(1+~_&7))&7))>0)
    <<_;putchar(_i_);}}" | gcc -x c - && ./a.out | aplay

     
    Got it? Simple enough. So where did I go with this?




    It works. Well. It compiles. Problem is it sounded awful. I was hoping for some really great sound, but just got an annoying buzz. Oh well. I let it rest there.

    Then several months later, I contributed a filter to the LV2 Midi filters project using a normal random distribution approximation rather than the uniform distribution method employed initially. I had already looked at the source of many plugins but never got the nerve to jump into developing, but this broke down the wall.

    I knew I wanted to make a synth. I'm not sure how exactly I came to decide the way to do it, but eventually I decided to use the cellular automaton code I'd developed in it. I thought for a while, whether each cell would be another note or what, but I eventually settled on making an additive synth with each cell being a harmonic, that sounds when the cell is alive and is silent when the cell is dead. This works pretty well, especially to get pulsating sounds, though the synth isn't limited to those sort of things. The fundamental is always on, and you can easily create a patch that all the harmonics are on or off and don't change. If that doesn't sound so easy, then read on.

    An elementary cell automaton basically is a sort of state machine where a number of cells will change in the next time step according to their current state and that of their neighbors. Since this is operating on a toroid this means that the edge cell wraps and is neighbors with the other edge. We use 16 cells, though actually any number is doable by the code. How cells respond is determined by a rule, which is basically an 8 bit number (0-255) where each bit value corresponds to the next state and the bit position is the current state. So for example rule 30 is hex value 0x1E or binary 00011110b. Which means the cells operate as follows:

    111 110 101 100 011 010 001 000
     0   0   0   1   1   1   1   0

    So a cell sequence of three cells in a row alive, the middle one will die for the next state. If the inital conditon is 0x0100 or 0000000100000000b (16 cells middle one alive) then the sequence looks like:
           0       
          000      
         00  0     
        00 0000    
       00  0   0   
      00 0000 000  
     00  0    0  0 
    00 0000  000000
    0  0   000     
    00000 00  0    0
          0 0000  00
    0    00 0   000
    00  00  00 00  
    0 000 000  0 0 0
      0   0  000 0 0
    0000 00000   0 0
         0    0 00 0
    0   000  00 0  0
     0 00  000  0000
     0 0 000  000  
    00 0 0  000  0 
    0  0 0000  00000

    where a 0 is a cell and blank is no cell. I cut it off of course but it will go on indefinitely unless it reaches a stable state (i.e all cells are dead and the last bit of the rule is zero). Wikipedia has a nice article with some great graphics from elementary cell automata, though the images are generated from random initial conditions and not on a torus.

    If you want to do some great sound design using the automaton, I recommend getting a pencil and paper and writing out the states and filling in what you want the next state to do:

    111 110 101 100 011 010 001 000
     1   1   1   1   0   0   0   0

    This rule is 0xF0 = 240. In this example I made it so each cell becomes the state its left neighbor is in. Coupled with an input like 0xAFAA you get diagonal stripes going down:
    0 0 00000 0 0 0
     0 0 00000 0 0 0
    0 0 0 00000 0 0
     0 0 0 00000 0 0
    0 0 0 0 00000 0
     0 0 0 0 00000 0
    0 0 0 0 0 00000
     0 0 0 0 0 00000
    0 0 0 0 0 0 0000
    00 0 0 0 0 0 000
    000 0 0 0 0 0 00
    0000 0 0 0 0 0 0
    00000 0 0 0 0 0
     00000 0 0 0 0 0
    0 00000 0 0 0 0
     0 00000 0 0 0 0

    This gives an interesting phasor sort of sound. These sequences shown are generated by the rule utility provided with the source of Infamous Plugins, which will help you in your explorations. I used this methodology to make all the presets.

    The synth has no filter, though filter like effects can be attained through adjusting the number of harmonics played. If you use this parameter to turn off the harmonics because you don't want that sort of sound I reccommend you also turn the cell lifetime up to the max because the cells are calculated even when they are not going to be played (this way you can "open up" the number of harmonics like a filter for some nice effects). Nothing bad happens if you don't, just wasted CPU cycles.

    You can also use the lfos for some FM synthesis or to get some good drum sounds like I do on the kick drum of the demo. The demo is entirely made with the Infamous Cellular Automaton Synth plugin. Have a listen and feel free to comment, make suggestions, ask questions, etc. Oh ya and download the source and install it!

    *note: I accidentally deleted this post, but luckily was able to recover it from the linux audio planet! whew.

    by Spencer (noreply@blogger.com) at June 30, 2014 01:57 PM

    Scores of Beauty

    What You “Miss” When Using Version Control

    Recently I stumbled over this list about “How I save documents” – it’s German but you’ll surely get the point.

    It is meant to be funny, but actually it’s a comprehensive documentation of one of the reasons why using plain text and version control rocks. When presented with this list scholars or other people usually respond with telling sighs of recognition – while my personal recognition has actually faded away and has to be actively pulled from a very distant past ;-)

    I realized that while having written so much about version control on Scores Of Beauty we don’t have an article yet telling you concisely why you should use it as your bread-and-butter tool for daily work. So today I’m going to give you a list of things you will miss and eventually forget when you switch your toolkit to using version control.

    Issues “missed most” when using version control

    1. Naming schemes and file duplication as displayed in the above list
      With version control you will have to content yourself with just one “projekt.doc” (well, it should rather be “projekt.tex” or “projekt.md”)
    2. Asking yourself which copy you should edit or have edited
      With version control you edit the single file. Fullstop. Any modifications are commited to and documented in the project history.
    3. Propagating wrong edits or deletions through shared drives etc.
      Thinking that managing a project on Dropbox or similar service serves you as a backup may fall hard on your toes. If you delete a file while online it will immediately be propagated to the server, and when you are sharing that server with others the files will be deleted from their computers too. If you accidentally delete a file in a version control repository you can simply “discard” that action and revert to the last state. Actually it’s quite improbable that one accidentally deletes a file and commits that deletion to the repository. And even in that case version control won’t finally delete the file but will propagate the deletion as a revertable process.
    4. Concurrent and conflicting edits
      Did you ever run into the issue that your collaborator sent you a document containing some edits. Then you continued to work on that document (respectively a renamed copy, see 1.), and the next day your partner sent the file again, with some more edits? Then you’ll probably be sad to hear that version control takes all the fun out of manually searching the copies for the different changes and figuring out where to apply which version of the content (see 5.). With version control you’ll simply merge in the changes and have the latest state of all collaborators’ work available. And if these changes should conflict in some places, you’ll be conveniently confronted with the decision to choose from the respective version on a line-by-line basis.
    5. Searching for modifications
      Although many programs offer features such as “tracking changes” or similar, in the end all modifications will somehow be melted into a document file. When you look at a document, for example a Finale score returned from a proof-reader, how can you tell where the fixes are? Either you simply trust your colleague, use some external documentation such as a commenting email and trust that, or you have to compare the files yourself again. Version control presents you with the exact changes through the project history, so you’ll immediately (and persistently) know who has changed what and when, usually also why (using commit messages).

    Feel free to extend that list in the comments :-)

    Rounding off this article I’ll tell you a real-world story I heard from a member of a well-known publishing house. It makes use of a mix of these aspects.
    After ten years of regular use editors of said publishing house reviewed the edition of an opera and did some improvements and fixes to the musical text. Unfortunately someone applied these fixes to the wrong score files, say, a backup copy representing the state of the edition half a year before publication (I’m not completely sure about these details, but the point is true). So the result was a completely faulty edition – but with the latest fixes. Unfortunately they only realized their mistake after having trashed all existing copies of the rental material and having printed 20 new sets (and I can tell you that sets of material for this composer’s operas are big). In fact it was the orchestras who had to notice that their new performance materials seemed crappy and unusable …
    With version control the initial mistake could have happened too: it’s perfectly possible doing some work while having the wrong branch checked out, and one would even commit that work to the wrong branch. But there are so many opportunities where it’s usual or necessary to look at the project history that it’s extremely unlikely that this error wouldn’t be noticed before actually producing the paper copies. And fixing the issue itself is really straightforward: As mentioned above all changes are completely documented in the project history, so it’s not an issue at all to identify the modifications that have been applied during the review. Actually you now would not identify the modifications and re-apply them manually to the correct state of the edition, but you would rather take the commits and apply them to the right branch – which is appropriately called “cherry-picking” in version control terminology. Depending of the “distance” between the two base points in the project history this process may in fact produce a number of “merge conflicts”, but these can be handled in a straightforward manner too. And finally the version control documentation will clearly indicate the spots where the edition has been changed, so the responsible engraver will know exactly where she should have a close look to check for any regressions and side-effects.

    So, actually the question should not be “Why should I use version control?” but “How could I ever justify not using version control?”

    by Urs Liska at June 30, 2014 06:09 AM

    June 29, 2014

    GStreamer News

    GStreamer Core, Plugins and RTSP server 1.3.90 release candidate

    The GStreamer team is pleased to announce the first release candidate of the stable 1.4 release series. The 1.4 release series is adding new features on top of the 1.0 and 1.2 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework.

    This release candidate will hopefully shortly be followed by the stable 1.4.0 release if no bigger regressions or bigger issues are detected, and enough testing of the release candidate happened. The new API that was added during the 1.3 release series is not expected to change anymore at this point.

    Binaries for Android, iOS, Mac OS X and Windows are provided together with this release.

    The stable 1.4 release series is API and ABI compatible with 1.0.x, 1.2.x and any other 1.x release series in the future. Compared to 1.2.x it contains some new features and more intrusive changes that were considered too risky as a bugfix.

    Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, or gst-rtsp-server, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, or gst-libav, or gst-rtsp-server.

    Check the release announcement mail for details and the release notes above for a list of changes.

    Also available are binaries for Android, iOS, Mac OS X and Windows.

    June 29, 2014 01:00 PM

    harryhaaren

    LV2 and Atom communication

    EDIT: There are now better resources to learn LV2 Atom programming: please use them!
    www.lv2plug.in/book
    http://lac.linuxaudio.org/2014/video.php?id=24
    /EDIT


    Situation: You're trying to write a synth or effect, and you need to communicate between your UI and the DSP parts of the plugin, and MIDI doesn't cut it: enter Atom events. I found them difficult to get to grips with, and hope that this guide eases the process of using them to achieve communication.

     

    Starting out

    I advise you to first read this : http://lv2plug.in/ns/ext/atom/
    It is the official documentation on the Atom spec. Just read the
    description. It gives a good general overview of these things called Atoms.

    This is "message passing": we send an Atom event from the UI to the DSP part of the plugin. This message needs to be safe to use in a real-time context.

    (Note it is assumed that the concepts of URIDs is familiar to you. If they're not, go back and read this article: http://harryhaaren.blogspot.ie/2012/06/writing-lv2-plugins-lv2-overview.html )

    Step 1: Set up an LV2_Atom_Forge. The lv2_atom_forge_*   functions are how you build these events.

    LV2_Atom_Forge forge;
    lv2_atom_forge_init( &forge, map ); // map = LV2_URID_Map feature

    Atoms

    Atoms are "plain old data" or POD. They're a sequence of bytes written in a contiguous part of memory. Moving them around is possible with a single memcpy() call.

     

    Writing Atoms

    Understanding the URID naming convention

    // we need URID's to represent functionality: There's a naming scheme here, and its *essential* to understand it. Say the functionality we want to represent is a name of a Cat (similar to the official atom example). Here eg_Cat represents the "noun" or "item" we are sending an Atom about. eg_name represents something about the eg_Cat.

    something_Something represents an noun or item, while something_something (note the missing capital letter) is represents an aspect of the noun.

    LV2_URID eg_Cat;
    LV2_URID eg_name; 


    In short classes and types are Capitalized, and nothing else is.

    Code to write messages

    // A frame is essentially a "holder" for data. So we put our event into a LV2_Atom_Forge_Frame. These frames allow the "appending" or adding in of data.
    LV2_Atom_Forge_Frame frame;


    // Here we write a "blank" atom, which contains nothing (yet). We're going to fill that blank in with some data in a minute. A blank is a dictionary of key:value pairs. The property_head is the key, and the value comes after that.
    Note that the last parameter to this function represents the noun or type of item the Atom is about.
    LV2_Atom* msg = (LV2_Atom*)lv2_atom_forge_blank(
                    &forge, &frame, 1, uris.eg_Cat );


    // then we write a "property_head": this uses a URID to describe the next bit of data coming up, which will form the value of the key:value dictionary pair.
    lv2_atom_forge_property_head(&forge, uris.eg_name, 0);
     

    // now we write the data, note the call to forge_string(), we're writing string data here! There's a forge_int() forge_float() etc too!
    lv2_atom_forge_string(&forge, "nameOfCat", strlen("nameOfCat") );

    // Popping the frame is like a closing } of a function. Its a finished event, there's nothing more to write into it.

    lv2_atom_forge_pop( &forge, &frame);

     

    From the UI

    // To write messages, we set up a buffer:
    uint8_t obj_buf[1024];

    // Then we tell the forge to use that buffer

    lv2_atom_forge_set_buffer(&forge, obj_buf, 1024);

    // now check the "Code to write messages" heading above, that code goes here, where you write the event.

    // We have a write_function (from the instantiate() call) and a controller. These are used to send Atoms back. Note that the type of event is atom_eventTransfer: This means the host should pass it directly the the input port of the plugin, and not interpret it. write_function(controller, CONTROL_PORT_NUMBER,
                   lv2_atom_total_size(msg),
                   uris.atom_eventTransfer, msg);



    From the DSP

    // Set up forge to write directly to notify output port. This means that when we create an Atom in the DSP part, we don't allocate memory, we write the Atom directly into the notify port.

    const uint32_t notify_capacity = self->notify_port->atom.size;
    lv2_atom_forge_set_buffer(&self->forge,
                             (uint8_t*)self->notify_port,
                              notify_capacity);
     

    // Start a sequence in the notify output port
    lv2_atom_forge_sequence_head(&self->forge,
                                 &self->notify_frame, 0);

    Now look back at the "Code to write messages" section. that's it, write the event into the Notify atom port, and done.




    Reading Atoms


    // Read incoming events directly from control_port, the Atom input port
    LV2_ATOM_SEQUENCE_FOREACH(self->control_port, ev)
    {

      // check if the type of the Atom is eg_Cat
      if (ev->body.type == self->uris.eg_Cat)

      {
        // get the object representing the rest of the data
        const LV2_Atom_Object* obj = (LV2_Atom_Object*)&ev->body;
     

        // check if the type of the data is eg_name
        if ( obj->body.otype == self->uris.eg_name )
        {

          // get the data from the body
          const LV2_Atom_Object* body = NULL;
          lv2_atom_object_get(obj, self->uris.
    eg_name,
                              &body, 0);
          

          // convert it to the type it is, and use it
          string s = (char*)LV2_ATOM_BODY(body);
          cout << "Cat's name property is " << s << endl;
        }
      }
    }



    Conclusion

    That's it. Its not hard. It just takes getting used to. Its actually a very powerful and easy way of designing a program / plugin, as it *demands* separation between the threads, which is a really good thing.

    Questions or comments, let me know :) -Harry

    by Harry van Haaren (noreply@blogger.com) at June 29, 2014 02:42 AM

    June 27, 2014

    Scores of Beauty

    Slur shapes and transposed parts: Use tags!

    Many contemporary music scores are engraved in concert pitch for easier reading. Parts for transposing instruments must (obviously) be transposed. This may cause slurs and ties to be shaped differently between the score and the parts. In most cases, LilyPond’s d default slur and tie positioning will be attractive enough. If so, there’s no particular problem: LilyPond will calculate the slur/tie shape based on the notes actually being processed at the time.

    It does present a problem if the default shape needs to be modified using the \shape command. \shape specifies the alteration in terms of moving the Bezier curve’s control points away from their default positions:

    \shape #'((dx0 . dy0) (dx1 . dy1) (dx2 . dy2) (dx3 . dy3)) Slur

    To make a downward slur deeper, for instance, you would push the
    middle control points down:

    \shape #'((0 . 0) (0 . -1) (0 . -1) (0 . 0)) Slur

    If transposition should cause the slur to flip upward, this modification will flatten the curve instead. This is quite likely to look wrong, perhaps even unreadable.

    I recently ran into this problem in one bar of a trio d’anches that I’m close to finishing. This bar contains a melodic phrase that spans 2.5 octaves in the space of five notes before leaping down a major tenth, under a slur. (Note that the notes themselves are contained in a music variable, and the score only refers to the variable. This is standard practice for any LilyPond project where a score and parts must be generated. It makes it possible to enter the notes once, and lay them out in a score or in parts as needed.)

    music = \relative c' {
      \tupletSpan 1*6/8
      \tuplet 4/3 {
        cis4 f,! ( d' e cis' b'2 g,4 )
      }
      \tupletSpan \default
    }
    
    { \time 12/8 \music }
    (click to enlarge)

    (click to enlarge)

    The slur is pretty close, although it makes me a little physically uncomfortable to look at it. There is not enough space above the B, and the shape also disguises the sharp downward leap in the last note.

    To fix it, push the third control point up (positive Y offset), and the last control point down.

    music = \relative c' {
      \tupletSpan 1*6/8
      \tuplet 4/3 {
        cis4
        \shape #'((0 . 0) (0 . 0) (0 . 1.2) (0 . -0.5)) Slur
        f,! ( d' e cis' b'2 g,4 )
      }
      \tupletSpan \default
    }
    
    { \time 12/8 \music }
    (click to enlarge)

    (click to enlarge)

    What happens if we use that music in a transposed part, however?

    music = \relative c' {
      \tupletSpan 1*6/8
      \tuplet 4/3 {
        cis4
        \shape #'((0 . 0) (0 . 0) (0 . 1.2) (0 . -0.5)) Slur
        f,! ( d' e cis' b'2 g,4 )
      }
      \tupletSpan \default
    }
    
    { \time 12/8 \transpose a c' \music }
    
    (click to enlarge)

    (click to enlarge)

    Now, the slur begins below the top of the stem and just to the right, and it ends quite a bit closer to the notehead than the concert-pitch version. These differences mean that the default curve for A clarinet is much more pronounced. The \shape alteration for concert pitch increases the curvature even further, making the transposed slur look exceptionally “loopy.”

    So we need more curvature than the default for concert pitch, and less curvature of the transposed part.

    But, in the \shape examples in the LilyPond manuals, it appears that \shape must appear right before the note that initiates the slur or tie to be affected. That is, in normal usage, you can have only one \shape per slur or tie. In this case, the music variable needs to specify both shape modifications, and the music expression that uses the variable should be able to choose which one to use at the time of engraving.

    LilyPond has a mechanism to choose between versions of some content: tags. A portion of music (a music expression) can be enclosed in curly braces and associated with a name using the \tag command. If the music variable is used without any tag references, all of the tagged expressions will be kept. Other commands, \keepWithTag and \removeWithTag, can cause certain tagged expressions to be ignored.

    music = { \tag #'tagName { ... music expression ... } }
    
    % Elsewhere, in the score
    \keepWithTag #'tagName \music

    It might not seem to apply to this case, because most uses of \tag will include real music in the expression. Here, all the notes are the same; it would be redundant to put notes inside the tags. Ideally, the tags would include only the content that is different: namely, the \shape alterations. But is that legal? Will it break the \shape calls to put them inside a tag, while the slur itself is outside?

    In fact, it is legal. \shape inserts \once \override commands into the expression. These are considered “music,” and may legally appear alone in a tagged expression. The final expression that LilyPond renders includes the override, followed immediately by the slur to affect: no problem.

    So the surprisingly simple solution is to write both \shape alterations, each with a different \tag. Then, use \keepWithTag or \removeWithTag to choose which of the \shape calls will be used in this context.

    music = \relative c' {
      \tupletSpan 1*6/8
      \tuplet 4/3 {
        cis4
        \tag #'scoreOnly { \shape #'((0 . 0) (0 . 0) (0 . 1.2) (0 . -0.5)) Slur }
        \tag #'partOnly { \shape #'((-0.5 . 1.5) (0 . 0) (0 . 0) (0 . 1.0)) Slur }
        f,! ( d' e cis' b'2 g,4 )
      }
      \tupletSpan \default
    }
    
    \markup \bold "Score in concert pitch"
    \score {
      \new Staff { \time 12/8 \keepWithTag #'scoreOnly \music }
    }
    
    \markup \column { \vspace #1 \bold "Part, transposed for clarinet in A" }
    \score {
      \new Staff { \time 12/8 \transpose a c' \keepWithTag #'partOnly \music }
    }

    example-5.preview

    More on tags: Using tags

    More on shape: Modifying shapes

    by James Harkins at June 27, 2014 06:44 PM

    June 24, 2014

    ardour

    linuxDSP Workstation Plug-ins Bundle - Pay What You Want - Limited Offer

    The linuxDSP Workstation Plug-ins Bundle is now available as Pay What You Want for a limited time until the end of June 2014. A unique opportunity to add professional console grade processing to your Ardour sessions for a fraction of the normal price (or whatever you think it's worth). Min price £5.00 (to cover payment processing and charges). Get it here:

    http://www.linuxdsp.co.uk/download/lv2/download_wpp

    by paul at June 24, 2014 03:42 AM

    June 23, 2014

    ardour

    Subscriptions Updated

    I have manually synced the subscriptions records with a downloaded report from PayPal. All subscriptions known to PayPal to be active should be marked as active, and all subscriptions not known to PayPal to be active should be dead. The active subscription count dropped by nearly 300.

    If you disagree with the state of your own subscription, please let me know. I did not send email to each subscriber because I think this information is mostly redundant.

    read more

    by paul at June 23, 2014 09:08 PM

    June 22, 2014

    GStreamer News

    GStreamer Core and Plugins 1.3.3 development release

    The GStreamer team is pleased to announce the third release of the unstable 1.3 release series. The 1.3 release series is adding new features on top of the 1.0 and 1.2 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework. The unstable 1.3 release series will lead to the stable 1.4 release series in the next weeks, and newly added API can still change until that point.

    This is hopefully the last 1.3 development release and will be followed by the first 1.4.0 release candidate (1.3.90) in 1-2 weeks. Which then hopefully is followed by 1.4.0 soonish in early July.

    Binaries for Android, iOS, Mac OS X and Windows will be provided separately during the unstable 1.3 release series.

    Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, or gst-rtsp-server, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, or gst-rtsp-server, or

    Check the release announcement mail for details and the release notes above for a list of changes.

    June 22, 2014 08:00 PM

    Music, Programming and a Cat

    The Linux Audio Company

    This is an article of the category "Let's talk about Next-Gen. Future ideas for Linux Audio" where I elaborate(!) on realistic near future improvements or unrealistic science fiction scenarios.

    What we want

     

    Music produced with Linux, assuming equal human skill and resources, will be better than music produced on other systems because the ecosystem, the concept, the workflow and the ideas are superior in Linux.

    That said there is a resources mismatch between different operating systems, and Linux is ... Read More

    June 22, 2014 12:09 PM