Tuesday, December 11, 2012

Getting to grips with Ganv

So you want to create a "Graph" based program? Use Ganv! It looks awesome, and David Robillard has already done the hard parts :)

Starting Out:

We're just doing a single file, proof of concept right now. Nothing fancy yet.
So you'll need to install:

Easiest way to do this is just checkout Drobilla's svn:
svn co http://svn.drobilla.net/lad/trunk drobillad

./waf configure --prefix=/usr
./waf install

What next:

Install ganv system wide. Download this tutorial's code from here: https://github.com/harryhaaren/openAudioProgrammingTutorials/blob/master/flowCanvas/flowcanvas.cpp

Read the code, its pretty self explanatory.

Then what?

Its a good idea to get to grips with how all this works together:

Ganv: is the way you interface with the whole
FlowCanvas: is the canvas itself, behind the scenes.
GTKmm: is your window, and you do what you like with it.

So the final structure is somewhat like this:
Gtk window
     Ganv Canvas
            Ganv Module
                  Ganv Port
                          Ganv Edge (connects ports)

That's all for now, hope I saved you a bit of time and effort! -Harry

Monday, November 19, 2012

Luppp: Status as of Nov '12?

Hey everybody,

I'm writing to let you all know that the Luppp project is not dead. I've not posted here about Luppp since May, and also haven't pushed code to the repo at github for 6 months. So what is the status?

Luppp is "taking the back seat" for a while. I mean that real-life has currently taken over, and with my final year of college and projects on, I don't see myself spending a lot of time on Luppp before the next LAC (that's the middle of May).

Don't worry, the reason for not pushing code recently is only partly due to time, the other reason is that during the summer I started doing (another...) total re-write. This time I'm confident that the code is a lot more maintainable. I hope :)

Till next, -Harry

Monday, July 9, 2012

Writing Lv2 GUI's: Making it look snazzy

So we know how to build a basic "amp" plugin, but there's no GUI. We like shiny gui's right? Of course we do :) This tutorial will explain how to make one.

Gooeys - Or GUI's:

The GUI part of a plugin can be viewed as a totally separate entity to the "DSP" or audio part of the plugin. We will call these the "halves" of our plugin. Theres a little bit of theory to cover before we start looking at code. The next communication section describes how the DSP and GUI parts of the plugin can inform eachother about whats going on.


So the GUI runs in the "GUI" part of the host program, and the DSP runs in the audio part of the host program. We can't communicate directly between the halves due to details that don't really concern us. (threading and thread safety if you must know..)

How it works: The two parts of our plugin are loaded into the two parts of the host program. How we communicate between the two "halves" of our plugin is by using Lv2 ports. These ports send communicate data between the host and the plugin. The host can then use that same data to update the GUI.

Similarly the GUI can write data, which will then be sent to the audio half by the host. That's all there is to it!

Choosing a toolkit

So there's a lot of GUI toolkits out there. The most prominent open-source ones are GTK and QT. This tutorial will explain how to create a custom GTK interface for an Lv2 plugin. My reason for choosing GTK? Its what I know. I also like it. If somebody would contribute code for doing the same in QT, I will gladly link to it from here.

Please note that I'm using the C++ wrapper around GTK (called GTKmm), and I use version 2, not the new stable GTK 3. I know that GTKmm 2 works, and have no reason to update to GTKmm 3.

Side note (skip if you want to get hands-on GUI writing): The loading of GUI plugins into hosts is done using the SUIL library. It is useful to know that it has certain toolkits that it supports, currently X11, GTK2 and QT. If you want to use a different toolkit please read the SUIL library page.

Making a GUI

So what do we actually do to get a GUI for an Lv2? We write a widget. If you're not at all familiar with GUI programming, I will suggest you look at the GTKmm2 Drawing Area tutorial code: Drawing a custom widget using a GTK::DrawingArea. When we have a widget created, we need to pass that widget to the Lv2 host, which will display it for us.


Yes. Where is it? There is a copy of the Lv2 repo on my Github, where I will publish the code for this tutorial. Chances are that these tutorials will be merged into the main Lv2 examples from the Github page.

Communication in code

So we talked about the theory of communication between the halves, but how do we actually do that in code? The Lv2 UI extension that we use to load the GUI gives us two "things" that we need to write port events from the GUI to the host. What these things represent is not really important: we just need to use them. (if you must know: LV2UI_Controller is a pointer to the host's own stuff, and LV2UI_Write_Function is a function pointer that will do the work)

Github Lv2 repo: SinSynth folder at commit while writing this tutorial

Writing port events in the GUI

So we have these two things: LV2UI_Controller and LV2UI_Write_Function, how do we use them? More theory first. Events happen in the Widget, ie: if the user clicks, our Widget gets a function called. That function must decide what to do, and then call the write_function().

What this means in practical terms, is that the Widget class needs access to the LV2UI_Controller and LV2UI_Write_Function.

The way that I solve that, is by adding the LV2UI_Controller and LV2UI_Write_Function to the Widget class. Some people might say this is ugly design: but its simple and works well.

Look at Widget::on_button_press_event to see the code in action.


Testing the plugin

There's a program called Jalv, which is a great little host to test out your Lv2 plugins with: I've used it to develop this tutorial and the GUI for the tutorial. Grab it here: http://drobilla.net/software/jalv/

Running jalv.gtk http://lv2plug.in/plugins/eg-sinsynth
gives me this screenshot, clicking it will change the frequency!


That's all!

You've now made a custom GUI, that should work as a Lv2 plugin gui. Sure its not UI artwork yet, but I'll leave you to explore Cairo and its cool graphics functions on your own for a while ;)

Monday, June 11, 2012

Writing Lv2 plugins : An Lv2 Overview


Although I'm relatively aware of what Lv2 is, and also relatively aware of how it works, and relatively know how to write a "host" class: what's inside an Lv2 plugin???

Starters: I'm assuming you know a bit of C/C++, you know what a plugin is, and you're well able to use a terminal. I'm not assuming you know much about plugin specs, Lv2 URI's, manifest files, or Turtle RDF. These things will become apparent as we go along.

For this tutorial, I'm going to talk us trough the "eg-amp" code, that comes with the lv2 source code. If you don't have it yet, grab it now. Extract, and /plugins/eg-amp.lv2/ shows you the sources.


Lv2 works by defining URI's. A URI means *nothing*. It is a string, that contains a unique identifyer for *stuff*. Usually it is in the form of a http:// address, and that web link will show you more info on the plugin. Don't fret about details, just remember this:

Lv2 plugins come in "bundles". A bundle contains one or more plugins. For simplicity, this example contains only one plugin. A bundle is just a directory, with three files inside:
  1. manifest.ttl
  2. <pluginName>.ttl
  3. <pluginName>.so
The other files (waf and wscript) are only to compile the source code into the binary plugin, and install them. Of course any other build system can be used to compile Lv2 plugins too!

Walk trough of the files:


This file lists all plugins that can be found in the bundle. For this example, there's only one. The file has various different bits of information about the bundle its contained in, and this information defines the plugin.

The eg-amp manifest contains this:
@prefix lv2:  <http://lv2plug.in/ns/lv2core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

    a lv2:Plugin ;
    lv2:binary <amp.so>  ;
    rdfs:seeAlso <amp.ttl> .

First of all two "convenience" prefix' are defined. The core Lv2 URI, and the RDF scheme URI.

Next we declare a URI. It is the unique string, that when used always means exactly this object. Afterwards, some details about the "resource" are added:
The resource <http://lv2plug.in/plugins/eg-amp> has the property lv2:Plugin, the property lv2:binary and for more info look at <amp.ttl>.


This file contains all the details about the plugin: think "Who what when how where"?. I won't paste the code here,the 85 lines would clog up this post. I'll talk you through it though, dont' worry!

First section after the license (lines 17-21):
One can declare some RDF data to show the "author" of a plugin. This can point to your own website, or else a company website.

The next section (lines 29-87) contain the implementation details of the plugin: things like the Maintainer of the plugin, the name of the plugin, the license, the plugins "features", and what "ports" it exposes.


Finally: the binary file, that a host will load, and use to do whatever the plugin does. Not much more to say really!

Lv2 Extensions

An extension is a definition of some extra functionality, that isn't contained in the core lv2 spec. These definitions have their own unique URI, and each has its own .ttl and C header files.

Since Lv2 is a "modular" or "extensible" format, anybody can write a Lv2 Feature, and then write plugins or hosts to use that feature. Note that not all hosts support every feature, so using "rare" features may mean you plugin can't be used in a host somebody else wrote.

Lv2 Ports

(If you are familiar with LADSPA ports, skip this section: they're pretty similar)
Ports are a way to transfer data between the plugin and the host. There are various types of ports, some built into the "lv2-core" spec (always available in every host) and some that are "feature" ports, (ie contained in a feature extension to lv2, and perhaps not every host supports it).

Most ports send float values around, like in the eg-amp:
lv2:port [
        a lv2:InputPort ,
        lv2:ControlPort ;
        lv2:index 0 ;
        lv2:symbol "gain" ;
        lv2:name "Gain";
        lv2:default 0.0 ;
        lv2:minimum -90.0 ;
        lv2:maximum 24.0 ;

The above RDF snipped defines a port, its an input port (to the plugin), its a control rate port (not audio), its index is 0, and it changes the "Gain" parameter of the plugin. Pretty readable right? I'll leave the rest to you! :D

Compiling eg-amp

So to get the eg-amp lv2 bundle compiled and running you've a couple of steps to take:
./waf configure           will setup Waf so it knows how to build
./waf                            will compile & link the files
./waf install                moves the .lv2 bundle to /usr/local/lib/lv2/ (by default)

Note that doing a
./waf configure --strict --debug --prefix=/usr
will enable strict compiler checks, a debug build, and install in /usr/lib/lv2/

Test the plugin using any Lv2 host, Ardour, QTractor, Jalv, lv2rack, zynjacku : they should all work, assuming they're up to date!


That's most of the main topics of Lv2 covered: you now have a decent understanding of what is necessary to write Lv2 plugins. In a future post I hope to cover the details of eg-amp.lv2, and the C code it consits of. Also intended is to post about how to implement extra features; both for hosts and plugins. But that'll remain for another day.

PS: Comments and changes welcomed: I'm new to writing Lv2 plugins myself, and I'm sure that improvements can be made on this post!

Wednesday, May 2, 2012

Luppp milestone: Timestretch!

Although its been a relatively quite period for development (due to lots of deadlines) today one of Luppp's long term goals has been reached: on-the-fly time stretching per track.

For the non-techie: This means that you can play a melody loop, and slow it down or speed it up, and the audio will remain in the same key! (No turntable RPM effect? Nope :)

Mandatory examples:

Although I'd call the quality "passable" is obviously not fantastic but there's some parameters in the algorithm that are available to tweak, so I hope to be able to improve it a bit a least :)

So when is a beta release?? Don't hold your breath, sorry. There's still some work to be done before Luppp will be ready for prime-time, but until then feel free to test it if you're interested!

Will keep you posted, -Harry

Sunday, April 15, 2012

LAC performance

Hey All,

With the LAC on at the moment, its a prime time to do some extra development on features that need some finishing before being fully useful. That has been going on, and now the AutoMove feature allows the changing of the length of the fade. Currently the mapping to change the length is set to right click, that needs to be changed as we can only cycle up in length. Current options for beat lengths are 2, 4, 8, 16, and 32.

Also fixed was the "Master Beat Indicator", (the moving widget here). It now just syncs to JACK tempo, and will display which of the beats between 1 and 4 we're on. Since the AutoMove function is triggered on a downbeat (every 4th beat) the tempo indicator shows when the AutoMove fade will come into effect.

The current git head (master branch) is the exact version of Luppp that I used for the performance at the LAC Sound Night yesterday. Many thanks to Luigi Verona for his droning series which was the basis for the piece.

Greetings from the LAC, -Harry

Wednesday, April 11, 2012

Luppp : Scopes and Sends

New features have arrived in the devel branch:
-Interaction with the sends & return widgets
-Scope that displays the master output_W channel

Various code improvements have also been pushed along the way, be it that the headphones volume dial now goes up when you move up, or that that post-fade send now adhere's to the Mute status of the track.

Its another small step along the way! Mandatory screeny:

Wednesday, March 21, 2012

Luppp: New Feature! AutoMove

Over the last days a new feature was designed & implemented: AutoMove.

The idea is simple; in a live situation you just don't have time to write automation lines, not even simple ones! You also don't have a hand free to turn up your reverb during the next 16 bars, so what do you do? AutoMove it!

The following GIF animation of screenshots gives it all away:

There are preset automation lines, and widgets that are active get scaled by the AutoMove's value. You press one button, and it does the rest. Now we're making music :)

Available in the master branch as of right now!

Friday, March 16, 2012

Luppp: Alpha 1

Alpha 1 status:
100%  -  Closed

Today the last bug on the Alpha1 milestone has been closed, hence also the alpha1 release of Luppp 2.0. In a way this is a big occasion, its the first official release!

Alpha1 in action, with various effects and clips!

On the other hand, there's still a bucket load of work to be done before Luppp will be comfortable to use without various hardware controllers. I'm aware that there's lots of half-finished, half broken as well as broken stuff! Hey its still alpha!

Current milestone: Alpha2
There's already a list of bugs / feature requests up! There's also many GUI issues that are known and NOT there, but I'd prefer fix them than waste time posting a bug report.

Welcoming (adventurous alpha) testers, any issues will be dealt with as promptly as possible! Please file bug reports here: https://github.com/harryhaaren/Luppp/issues/new

Wednesday, March 7, 2012

Luppp: New Effects interface

After a "push" quiet period, I've just pushed up a couple of branches changes:
-Luppp's GUI has had a bit of work
-Effect control from the APC40 has been revamped
-Effects sends have been implemented

-The GUI now shows the effects under the track, in a small widget: reasons? Now you can always see the state of all your effects, not just the ones on your currently selected track. Better for live situations!

-The APC40 has 8 buttons under the Device controls, they now each map to Effect on/off. They're labelled for a different purpose, but I find this use quite intuitive.

-Post fader sends are implemented, including widget representing the state. The GUI widget doesn't work yet (ie won't change the value) but it does update upon a controller change.

I've pushed the changes to devel, but also the master branch, AFAIK its stable.


Tuesday, January 17, 2012

Luppp: Settling into Github

In the last couple of days the Luppp repo has made a new home on github, now complete with issue tracker & wiki.

The "manual" for Luppp will be constructed slowly in the Wiki part of github:

It currently contains some info on how to download & build:

as well as a basic overview of what does what in the GUI:

Also new: A master "progress" widget that shows time into your 4 bars, or time till the next "4th queue" process, ie: Event quantization.

Read "When it goes from red to green, your Scene will change."

Fancy GUI suggestions welcomed, I don't really know how to spice this one up yet...

Hopefully in the next couple of days I can update it some more, and fix a couple of critical bugs that really hinder the use of scenes. More news soon!

Saturday, January 14, 2012

Luppp : Source opened, but still pre-alpha!

Hi All!

With recent changes in the world of live looping software I've decided to open my private repo of Luppp.

The Luppp project has been one of my main occupations over the last couple of years, and I've tought myself C++ programming while working on it. Its a live looping instrument with similar features to the well known software Ableton Live, and more recently Bitwig studio. I feel the live workflow available with such programs is something the Linux Audio community would also benefit from, and hence it will be released under the GPL license, version 3.

Its current state is that most "basic" functionality is in place: Loading, playing back & recording of loops works, effects can be added to these audio streams, and later they are mixed. A basic config file is used to store information about loops, and hence Luppp can make more informed decisions how to use loops.

This is pre-alpha software, as not all features to fullfill alpha state are  implemented. On the other side, most features currently available are quite stable (on my local machine anyway :)

I would like to announce that I will continue to work on the Luppp project myself, but that I do also welcome input / testing / help from other developers. I am aware that there are some basic enough flaws in the program in its current state, however these are also the primary items on my TODO list.

Remember its pre-alpha, please keep that in mind :)
Git source repo: https://github.com/harryhaaren/Luppp
ZIP of master branch: https://github.com/harryhaaren/Luppp/zipball/master

If you're intrested in working on Luppp, have a feature request, have ideas, time, or want to build Luppp a website, feel free to get in contact!!
Cheers, -Harry

Mandatory screenshot (note your GTK theme will influence its looks, this is on the todo! ):