planet.linuxaudio.org

October 02, 2014

Create Digital Music » open-source

USB is the new CV: monome meadowphysics as Modular, in New Video

meadowphysics possibilities from tehn on Vimeo.

Here’s a lovely new monome demo, demonstrating their meadowphysics module interfacing between Eurorack hardware (that’s the stuff with the cables and knobs and things) and monome (that’s the stuff with the light-up grid).

Call your family and random strangers and tell them that today you’re really stoked about “rhizomatic cascading counters,” which is what this is. (In more technical terms, let’s go with “chimey note-y thing.”)

I’ve heard people who don’t like computers much complain that USB is some sort of source of planned obsolescence. On the contrary, with serial and standard class-compliant implementations over serial, USB seems poised to take its place alongside MIDI and control voltage as things that never go away. That’s particularly true of hardware that’s community-supported, user-serviceable, or open in some way (doubly so if its key components are open source).

In this case, swapping USB cables works like swapping other jacks on your modular. As the monomers say:

we’ve introduced a new grid-enabled module called meadowphysics. it is a rhizomatic cascading counter. it’s great for polyrhythmic sequences, evolving drum patterns, and rule-based explorations.

you do not need multiple grids to run several monome modules in your eurorack setup— the USB cable is hot-swappable between modules, and each will continue running when disconnected. swapping a USB cable is as easy as swapping a patch cable.

meadowphysics is available now via our retailers: http://monome.org/order

thank you for your ongoing support and we hope you are all very well.

brian and kelli and trent

mp-full

Full specs on the new module:

retail price: $260
abstract: eurorack format rhizomatic cascading counter for monome grids
requirements: monome grid controller (see note below *)
width: 6hp
depth: 40mm (“skiff friendly”)
power: 12v: 18ma, -12v: 17ma 5v: 42ma (grid unconnected), up to 600ma (grid connected, see note below **)

meadowphysics facilitates the exploration of polyrhythms and rule-based sequencing, producing a wide range of emergent patterns.

a monome grid is plugged into the front panel of the module, serving as a complete interface. the procedure continues running when the grid is disconnected, facilitating both live performance and precomposed playback of generative systems.

as the second module in the grid-based eurorack series, this module highlights the ability to swap the grid between modules rapidly, patching the usb cable much like a 3.5mm cable. this module can be used in conjunction with white whale using a single grid gracefully.

the foundation of meadowphysics is an incoming clock which can be internal or external. seven additional counters can be cross-assigned with this clock to count down an assignable number of counts, which is the primary interface on the grid. when a counter reaches zero, the corresponding output is triggered on the panel. given a flexible assignment method, very complicated long-form mutating polyrhythms can be created intuitively.

in addition a series of “rules” can be applied at the zero count of each counter. the count length can be reassigned– incremented/decremented, randomized, reset to last value, etc. a counter can have a rule assigned to change another counter’s behavior. in this way long evolving patterns emerge.

very simple falling rhythms can also be accomplished in a very straightforward manner. a standard subdivided counter runs as a default behavior.

configurations are preset-able and savable to flash for later recall and instant resume on power-up.

The firmware itself is open source, and there’s full documentation:
http://monome.org/docs/modular

More:
monome.org/modular

The post USB is the new CV: monome meadowphysics as Modular, in New Video appeared first on Create Digital Music.

by Peter Kirn at October 02, 2014 03:27 PM

Libre Music Production - Articles, Tutorials and News

Infamous Plugins, v0.1 - The Eye Candy Release

The infamous plugins have been developed over the last couple years and now
GUIs have been created for them. A fund raiser in the style of the OpenAV
Productions release system
has been started to free the source. The LV2
plugins are already open without GUIs and can be tried and used freely.

The plugins include:

by Conor at October 02, 2014 08:31 AM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [LAD] [LAU] Guitarix 0.31.0 released

From: hermann meyer <brummer-@...>
Subject: [LAA] [LAD] [LAU] Guitarix 0.31.0 released
Date: Oct 2, 7:34 am 2014

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

The Guitarix developers proudly present

Guitarix release 0.31.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[*] and support LADSPA / LV2
plugs as well.

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).

Here is the " Ultimate Guide to Getting Started With Guitarix
"

This release fix a bug in the preset naming schema ( vowel mutation in
preset names will crash guitarix) and introduce some new LV2 plugs:
* GxRoomSimulator
* GxDigitalDelay
* GxLiveLooper

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


The Guitarix project never accepted Donations, and still wouldn't do.
But, if you ever wished to donate the project, I would kindly ask you to
back the MOD Kickstarter campaign here:
https://www.kickstarter.com/projects/modduo/mod-duo-the-limitless-multi-effects-pedal
to reach this Goal:
>
> If the campaign reaches U$100.000 the MOD Duo will offer an Audio
> Interface from it's USB connection. This means that when you plug the
> MOD Duo to your computer you will be presented with a 4 input audio
> device (two pre-processed + two post-processed) that can be used for
> recording the MOD's audio directly to your favorite software.
>
> Add this to the quality of our analog circuit and you'll have, as a
> free bonus, a professional grade audio interface that if bought alone
> would cost the price of a MOD Duo.
>


[*]Here is a list of all included plugs:


Guitarix tube emulations
========================

12ax7
12AU7
12AT7
6DJ8
6C16
6V6
12ax7 feedback
12AU7 feedback
12AT7 feedback
6DJ8 feedback
pre 12ax7/ master 6V6
pre 12AU7/ master 6V6
pre 12AT7/ master 6V6
pre 6DJ8/ master 6V6
pre 12ax7/ push-pull 6V6
pre 12AU7/ push-pull 6V6
pre 12AT7/ push pull 6V6
pre 6DJ8/ push-pull 6V6
noamp

Guitarix Tonestacks
===================

default
bassman
twin
princeton
jcm800
jcm2000
mlead
m2199
ac30
soldano
mesa
jtm45
ac15
peavey
ibanez
roland
ampeg
ampeg_rev
sovtek
bogner
groove
crunch
fender_blues
fender_default
fender_deville
gibsen
engl

Guitarix Cabinets
===================

4x12
2x12
1x12
4x10
2x10
HighGain
Twin
Bassman
Marshall
AC-30
Princeton
A2
1x15
Mesa Boogie
Briliant
Vitalize
Charisma

Guitarix internal mono plugins
===============================

Mono : Distortion : JCM 800 Preamp
Mono : Distortion : MultiBand Distortion
Mono : Distortion : Multi Band Distortion
Mono : Distortion : Ov [message continues]

read more

October 02, 2014 08:00 AM

[LAA] Infamous Plugins, v0.1 The Eye Candy Release

From: Spencer Jackson <ssjackson71@...>
Subject: [LAA] Infamous Plugins, v0.1 The Eye Candy Release
Date: Oct 2, 7:34 am 2014

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

The infamous plugins have been developed over the last couple years and now
GUIs have been created for them. A fund raiser in the style of the OpenAV
Productions release system has been started to free the source. The LV2
plugins are already open without GUIs and can be tried and used freely.

The plugins include:
-the infamous cellular automaton synth
-the infamous envelope follower
-the infamous cheap distortion
-the infamous hip2b (square wave distortion)
-the infamous stuck (a "sound retainer" effect)
-the infamous powerup and powercut (tape stop and start effect)

Please visit the project website to learn more about the plugins and visit
the donate page to learn how you can help free them.

http://infamousplugins.sourceforge.net

Thanks for reading!
_ssj71

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

The infamous plugins have been developed over th=
e last couple years and now GUIs have been created for them. A fund raiser =
in the style of the OpenAV Productions release system has been started to f=
ree the source. The LV2 plugins are already open without GUIs and can be tr=
ied and used freely.

The plugins include:
-=
the infamous cellular automaton synth
-the infamous envelope follow=
er
-the infamous cheap distortion
-the infamous hip2b (s=
quare wave distortion)
-the infamous stuck (a "sound ret=
ainer" effect)
-the infamous powerup and powercut (tape =
stop and start effect)

Please visit the project website to lea=
rn more about the plugins and visit the donate page to learn how you can he=
lp free them.


Thank=
s for reading!
_ssj71


--047d7b5d436ea29e7b050463bd80--

read more

October 02, 2014 08:00 AM

Libre Music Production - Articles, Tutorials and News

New release of Guitarix, including new LV2 plugins

The Guitarix developers have just announced the release of Guitarix version 0.31.0. For the uninitiated, Guitarix is a tube amplifier simulation for JACK, with an additional mono and a stereo effect rack. Guitarix includes a large list of plugins and also supports LADSPA/LV2 plugins.

This is mainly a bug fix release but it also includes three new LV2 plugins. They are -

GxRoomSimulator (Based on Gardner's room reverberator models)
GxDigitalDelay
GxLiveLooper

by Conor at October 02, 2014 07:42 AM

blog4

exhibition and concert in Berlin 3.-5.October Signs Of Dexterity art festival

the first showing of the installation deStatik in Berlin and a concert by Notstandskomitee are in the talks for early October for the Signs Of Dexterity art festival. DeStatik will be shown from 3.- till 5. October, Notstandskomitee performs Sunday the 5. October 19:00 and share the stage with old tape scene buddy C-Drik.

by herrsteiner (noreply@blogger.com) at October 02, 2014 12:35 AM

October 01, 2014

Scores of Beauty

Crowd Engraving Picking Up Speed

My very first post on this blog was the announcment of a “Crowd Engraving” project: preparing the performance material for the voluminous orchestral score of “Das trunkne Lied” by Oskar Fried. Unfortunately it took a really long time, but now the project has finally picked up speed and changed its status from a task to a “living” project. We will update you with hopefully interesting reports and information on this blog so this will be the first of a series of posts, similar to our series of posts about our edition of the Oskar Fried songs.

Over the last year we have always written about the joy of working with plain text and version control, and particularly what a positive impact this has on our ways of collaboration. Doing that in a team actually takes it to the next level, and I can already ensure you that this really works out nicely :-) .

Apart from the conceptual demands of such an undertaking it also was a technical challenge for me, as I’m now the “root” user of a virtual private server – with all its joys and menaces. There I could set up a LilyPond building environment, run my own mailing lists, and particularly install GitLab. GitLab is an open source application often characterized as a “self-hosted GitHub” – slightly less equipped with features but in the end an equally useful tool. Being one’s own server administrator is challenging but also exciting, and you don’t have to give your data to a commercial provider with dubious Terms Of Service.

When all this was set up I could take the time to fix the project framework, set everything up and write something like a Contributor’s Guide so I could ask for participants on the lilypond-user mailing list. This resulted in an impressive list of around 30 collaborators, although I have to admit that so far only a handful of them has found their way into active and regular contribution. But it really turned out to be an enjoyable experience to collaborate on a score that way, with a number of contributors who (some after some initial learning curve with the tools) work very independently and reliably by now. Like a gardener who has finished the seed I can watch my plants growing, and I can safely assume that while I’m writing this someone in any timezone of the earth is laying his hands on a number of segments. Having established a workflow of continuous peer review and having the power and robustness of LilyPond plus Version Control at hand I can be really comfortable with not having to do everything myself – but I’ll tell you more about that and our innovative “segment grid” approach in the next post of this series …

For today’s entertainment I have used the cool gource tool to generate a video documenting the project’s progress. This tool visualizes the history of a version control repository over time. I’m not sure yet whether this is really a tool and not rather a toy but it’s definitely fun to watch the output.

(we recommend viewing the video full-screen so that you can read the labels)

Around the center of a root directory you see how the directories and files are added and modified, and you can see the users who are doing this. At the top of the screen you can see how time proceeds – but be aware that the (virtual) editor in gource tries to avoid boredom and decides to skip longer periods of inactivity.

You can see that I initially worked on the infrastructure alone and only on May 08, 2013 (0:16) created the first directory with actual music (“violoncello”, in the upper right corner). After a little setting up two initial parts over the next week work concentrated on the infrastructure again.

From June 2013 to August 2014 you’ll notice several small and one huge skip, and only at the end of August 2014 (0:56) you’ll see the appearance of the first contributors. You can then see that the first week of September was one of increased activity with a number of contributors, until on September 08/09 (1:07) things start to go wild.

Over the rest of the video you can see a kind of settlement: Basically all files have been created and are now edited in detail. Also it gives a quite accurate representation on how the project directory is organized, but that’s a topic for next time …

by Urs Liska at October 01, 2014 09:14 PM

Libre Music Production - Articles, Tutorials and News

LMP Asks: Eat the apple – an interview with Red Plastic Label

LMP asks logo.

In an old farm near Milan, Italy, live and work the people at Red Plastic Label, a web-based label that produces and promotes her artists using open source software and creative commons licenses. LMP had the opportunity to ask them what they do, how they do it and why.

The building of Red Plastic Label.

Who are Red Plastic Label?

by admin at October 01, 2014 09:11 PM

Sidechaining in Qtractor using Ducka

Ducking is a special application of sidechaining. In this tutorial we take a track with a kick drum – the sidechain – to "duck" (silence) another track with a pad sound. The sequencer we use is Qtractor, the ducking-plugin is Ducka, from the Arty FX plugin suite.

by Conor at October 01, 2014 04:40 PM

Recent changes to blog

Some new LV2 plugs

There is progress in our git repository,

some new LV2 plugs have been added.

GxRoomSimulator

Based at Gardner's room reverberator models,

alternate text

GxDigitalDelay

port of the guitarix digital delay plugin

alternate text

GxLiveLooper

port of the guitarix dubber plugin

alternate text

by brummer at October 01, 2014 05:34 AM

September 30, 2014

Hackaday » » digital audio hacks

The Teensy Audio Library

teensy3_audio There are a few ways of playing .WAV files with a microcontroller, but other than that, doing any sort of serious audio processing has required a significantly beefier processor. This isn’t the case anymore: [Paul Stoffregen] has just released his Teensy Audio Library, a library for the ARM Cortex M4 found in the Teensy 3 that does WAV playback and recording, synthesis, analysis, effects, filtering, mixing, and internal signal routing in CD quality audio.

This is an impressive bit of code, made possible only because of the ARM Cortex M4 DSP instructions found in the Teensy 3.1. It won’t run on an 8-bit micro, or even the Cortex M3-based Arduino Due. This is a project meant for the Teensy, although [Paul] has open sourced everything and put it up on Github. There’s also a neat little audio adapter board for the Teensy 3 with a microSD card holder, a 1/8″ jack, and a connector for a microphone.

In addition to audio recording and playback, there’s also a great FFT object that will split your audio spectrum into 512 bins, updated at 86Hz. If you want a sound reactive LED project, there ‘ya go. There’s also a fair bit of synthesis functions for sine, saw, triangle, square, pulse, and arbitrary waveforms, a few effects functions for chorus, flanging, envelope filters, and a GUI audio system design tool that will output code directly to the Arduino IDE for uploading to the Teensy.

It’s really an incredible amount of work, and with the number of features that went into this, we can easily see the quality of homebrew musical instruments increasing drastically over the next few months. This thing has DIY Akai MPC/Monome, psuedo-analog synth, or portable effects box written all over it.


Filed under: ARM, digital audio hacks

by Brian Benchoff at September 30, 2014 08:00 PM

blog4

Witchfinder General

If you had ever faith in humanity, this film might help you. Witchfinder General from 1968 sports one of Vincent Price strongest and most serious performances in a dark and depressing movie. Absent is his typical overacting style which makes his evil characters kind of likeable or at least enjoyable, this is the real deal, playing the sadistic witch hunting general abusing his power. Prices not getting along with the director Michael Reeves might helped. Its amazing how a movie set in 1600s times during the witch hunt times can be still disturbing, after watching it I was terrified and depressed (well before watching it I was just depressed), its a good party stopping movie and belongs in the list we discussed here a while ago of the movies you should bring your first date, when you want to stay on your own. Very close to the Theatre Of Cruelty. Director Reeves died just some months after the release, some say it was suicide.
Its success created a short lived hype of witch hunt movies, also because they are good excuse to show scantily clad women and violence, most notorious the German coproduced Mark Of The Devil with Herbert Lom, Udo Kier and Herbert Fux!

by herrsteiner (noreply@blogger.com) at September 30, 2014 02:10 PM

Hackaday » » digital audio hacks

Finding a Shell in a Bose SoundTouch

BOSE Bose, every salesperson’s favorite stereo manufacturer, has a line of WiFi connected systems available. It’s an impressively innovative product, able to connect to Internet Radio, Pandora, music libraries stored elsewhere on the network. A really great idea, and since this connects to a bunch of web services, you just know there’s a Linux shell in there somewhere. [Michael] found it.

The SoundTouch is actually rather easy to get into. The only real work to be done is connecting to port 17000, turning remote services on, and then connecting with telnet. The username is root.

The telnet service on port 17000 is actually pretty interesting, and we’re guessing this is what the SoundTouch iOS app uses for all its wizardry. [Michael] put a listing of the ‘help’ command up on pastebin, and it looks like there are commands for toggling GPIOs, futzing around with Pandora, and references to a Bluetooth module.

Interestingly, when [Michael] first suspected there could be Linux inside this box, he contacted Bose support for any information. He figured out how to get in on his own, before Bose emailed him back saying the information is proprietary in nature.


Filed under: digital audio hacks, linux hacks

by Brian Benchoff at September 30, 2014 08:00 AM

September 29, 2014

GStreamer News

GStreamer Core, Plugins and RTSP server 1.4.3 stable release

Note that this announcement includes everything from 1.4.2 too, which was never officially released as some critical bugs were found.

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 (1.4.3), gst-plugins-base (1.4.3), gst-plugins-good (1.4.3), gst-plugins-ugly (1.4.3), gst-plugins-bad (1.4.3), gst-libav (1.4.3), or gst-rtsp-server (1.4.3), 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.

September 29, 2014 04:00 PM

GstValidate 1.3.90 release candidate

The GStreamer team is pleased to announce the first release candidate of the stable 1.4 version of the GstValidate developper tool.

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.

Check out the release notes for here, and download tarballs here,

September 29, 2014 01:00 PM

Audio, Linux and the combination

The 'MOD duo' on Kickstarter

Hi all,

It's happening : the 'MOD duo' kickstarter campaign is on !
The MOD team has been working on this guitar stomp box for quite some time, and everything they learned from making their prototype (the MOD quadra) has been applied in the MOD duo concept.

And I must say I'm impressed, so impressed that I just ordered one !



Read more »

by noreply@blogger.com (Thijs Van Severen) at September 29, 2014 10:59 AM

Hackaday » » digital audio hacks

The LPT DAC

LPT

About 30 years ago, before every computer had CD quality audio built in, audio cards and chips were technological marvels. MIDI chips, FM synthesis, and synths on a chip reigned supreme but one little device – just a handful of resistors – sounded fantastic. it was the Covox Speech Thing, a simple resistor ladder wired up to the parallel port of a computer that would output 8-bit audio to an external amplifier. [FK] recently built his own Covox (Czech, Google translatrix) with just 18 resistors, and the results sound fantastic.

Instead of fancy chips, the original Covox Speech Thing used the 8 bit parallel port on a PC. Back in the olden days, this was the fastest way to get digital data out of a computer, but since it was digital only, a DAC was required to turn this into audio. A simple resistor ladder was sufficient, and this hardware was eventually supported by the old DOS games from Sierra and Id.

[FK] has a demo of this LPT DAC available here, but we’re not thinking that link will last long. If anyone has a better link, leave a note in the comments and we’ll update this post. Thanks [beavel] for sending this in.


Filed under: classic hacks, digital audio hacks

by Brian Benchoff at September 29, 2014 08:00 AM

September 28, 2014

zthmusic

New song: Never Stop Raising The Bar

I’ve just uploaded a new song to my SoundCloud called Never Stop Raising The Bar. It’s featuring some vocals found online (attribution below), and it was made late this summer. I’ve decided to take a break from trying to make … Continued

The post New song: Never Stop Raising The Bar appeared first on zthmusic.

by zth at September 28, 2014 11:58 AM

September 27, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Sonic Visualiser v2.4 released

From: Chris Cannam <cannam@...>
Subject: [LAA] Sonic Visualiser v2.4 released
Date: Sep 27, 8:20 pm 2014

Sonic Visualiser is an application for inspecting and analysing the
contents of music audio files. It combines powerful waveform and
spectral visualisation tools with automated feature extraction plugins
and annotation capabilities.

Version 2.4 of Sonic Visualiser is now available. This release contains
some interesting new features, perhaps most noteworthy the ability to
sonify (play back) continuous frequency curve layers, as well as a
number of bug fixes and code quality improvements.

http://www.sonicvisualiser.org/

For more information, please read the change log at:

http://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/CHANGELOG

Sonic Visualiser uses Vamp plugins for automated audio feature analysis.
For more information about Vamp plugins, including downloads and
developer resources, see

http://vamp-plugins.org/

Sonic Visualiser is Free Software under the GNU General Public Licence,
developed at the Centre for Digital Music, Queen Mary University of
London.


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

read more

September 27, 2014 09:01 PM

PipeManMusic

Sour Dough

I've tried baking sour dough before and it wasn't very successful. Without a doubt it came down to not know how to build a good starter. Recently I started listening to the Stella Culinary School Podcast and following his instructions to make sour dough bread.
All I can say is that:
My first loaf
  1. Sour Dough requires more knowledge than most cooking techniques and can't just be done with a recipe.
  2. Once you understand some of the science it isn't all that hard though.
  3. It is super rewarding to make home made sour dough from local wild yeast.


With an Egg Wash

by Daniel Worth (noreply@blogger.com) at September 27, 2014 02:39 PM

Small business.

Saw this coffee van at my daughter's cross country meet and loved the black board doors.

by Daniel Worth (noreply@blogger.com) at September 27, 2014 01:06 PM

Hackaday » » digital audio hacks

Reanimating a Philips HDD 1420 MP3 Player

philips mp3 player hack

[OiD] had a dusty, old, forgotten Philips HDD1420 GoGear mp3 player kicking around his place. As you can imagine, the battery was dead. He had no charger or connector for the thing, but decided to try to resurrect it anyway.

He thought it would simply be a matter of providing alternative power, but the GoGear wasn’t having it and insisted on being connected to a computer. He had some luck consulting Pinouts.ru and found Philips’ own device manager software, but it still wasn’t easy. The device manager doesn’t work on Windows 7. He tried an XP box, but it didn’t detect the device.

Finally, he discovered that the hard drive was kaput and replaced it with an 8GB Microdrive. That helped, but he still had a hard row to hoe. [OiD] formatted the new HD and gave it the official firmware, but still had to replace some system files according to the Philips manual. He ended up using RockBox to reanimate it and decided to keep it on the device.

There was still an issue with charging, though. It has an IC that handles selection of either the proprietary external adapter or USB power, but the RockBox firmware doesn’t implement switching and defaults to the adapter. Several tweaks and a hacked-in mini USB later, the patient is in stable condition and cranking out the tunes.


Filed under: digital audio hacks

by Kristina Panos at September 27, 2014 02:00 AM

September 26, 2014

Libre Music Production - Articles, Tutorials and News

Sonic Visualiser v2.4 released

Version 2.4 of Sonic Visualiser has just been released. Sonic Visualiser is an application for inspecting and analysing the contents of music audio files. It combines powerful waveform and spectral visualisation tools with automated feature extraction plugins and annotation capabilities.

The aim of Sonic Visualiser is to be the first program you reach for when want to study a musical recording rather than simply listen to it.

by Conor at September 26, 2014 11:56 AM

September 25, 2014

Scores of Beauty

LilyPond’s Look & Feel

As described in the introductory essay on its website LilyPond is modeled after classical plate-engraved scores. This deeply influences the way how LilyPond “thinks” about laying out objects on a virtual paper, but it also results in a characteristic “Look & Feel” that makes music engraved with LilyPond stand apart.

However, while this default appearance is undisputedly of high quality it is (of course) not to everybody’s pleasure, and it can be considered a rather severe limitation that the Emmentaler notation font is so deeply interwoven into LilyPond itself that it can’t easily be replaced with other fonts matching different styles.

But wait a minute: Did I say “it is a limitation”? Well, I have to stand corrected: It was a limitation, and this limitation has gone now! :-)

The Gloomy Days of the Past

LilyPond has a very special relationship to its notation font. For example its source code is managed with the source code of LilyPond itself, and with each build of LilyPond the font is also built newly. But LilyPond is also (to my knowledge) the only notation software that makes use of optical sizes. That means: when printing at very small sizes it uses a font variant with less detail that looks better and somewhat bolder. As a consequence of that approach and attitude the usage of Emmentaler is realized in a very non-standard way, and originally it wasn’t possible to use different fonts to change the global appearance of the scores as you could do with other notation programs.

There has been one approach with one alternative font, Gonville that you could use, but only through a very hacky procedure where you basically made LilyPond think it used Emmentaler. It has been discussed as a severe usability restriction on the mailing lists, and when I talked with representatives of several major publishing houses this topic was one that always came up very early – and it definitely was a potential showstopper.

Unfortunately there hadn’t been any progress in that area because despite of a constant need for switching fonts there didn’t seem a solution in sight. While not qualified impossible it was understood that the issue is quite complex and those who are interested in it didn’t have the knowledge to do anything about it while those who could have tackled the task were too busy with other development tasks. One particular problem was the vicious circle that without fonts it doesn’t make sense to develop a switching mechanism, and without the option to use them it doesn’t make sense to develop fonts …

A First Approach: LilyJAZZ and SMuFL

Some time ago Torsten Hämmerle created a new Jazz font and made it usable with LilyPond (see this post). Some time later Nathan Ho adapted that approach to enable the use of SMuFL compatible fonts with LilyPond, as described in this post.

While this already was a significant improvement – particularly with the expectation of more and more SMuFL compliant fonts becoming available – the approach still wasn’t completely satisfying. It is somewhat unnatural to LilyPond in its technical implementation, and as you can see from the referenced articles it is quite some work to get such fonts to work flawlessly with LilyPond.

The Breakthrough: LilyPond Can Switch Fonts!

This was the situation until quite recently when Abraham Lee came around. He was the one combining the knowledge and tools with sufficient interest in the topic, and he created a working solution that really makes it possible to use LilyPond with different music fonts now :-) .

Starting with LilyPond 2.19.12 you can switch the music fonts as easily as switching the text fonts, and for the current stable release 2.18 there is a simple patch that anybody could apply. In addition Abraham has already supplied a really useful range of fonts that can now be used with LilyPond, and it seems he has found convenient workflows to add more fonts in the future.

It still doesn’t mean you can use LilyPond with any notation font – the fonts have to be set up to be compatible with LilyPond’s metrics and glyph allocation. And there is the small limitation that the new fonts don’t support the optical sizing (they do work but “only” the way notation fonts work in other programs). But having the option to switch fonts that easily, and already having such an interesting array of fonts freely available is nothing less than a breakthrough in LilyPond’s usability!

You get the fonts (and the patch) with a lot more information at http://fonts.openlilylib.org, and I hope that Abraham will find the time to write a post on Scores of Beauty giving us more insights in his motivation, experiences, and the technical background of his development. In the meantime please enjoy the following samples:

beethoven-thumbnail

cadence-thumbnail

emmentaler-thumbnail

gonville-thumbnail

gutenberg1939-thumbnail

haydn-thumbnail

lilyjazz-thumbnail

paganini-thumbnail

profondo-thumbnail

ross-thumbnail

scorlatti-thumbnail

by Urs Liska at September 25, 2014 08:13 PM

September 24, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] QMidiArp-0.6.1 maintenance release

From: Frank Kober <goemusic@...>
Subject: [LAA] QMidiArp-0.6.1 maintenance release
Date: Sep 24, 7:24 pm 2014

Here is a new qmidiarp release, some small things take some days more than 9
months, don't they?
Along with a couple of (important) bugfixes and changes mainly regarding the
QMidiArp LV2 plugin suite, 0.6.1 comes with only one new feature: the Arp can
now step up and down octaves after a chord has been arped through, nothing
more than what you would expect from an Arp right? Although this is something
that was already partly possible by constructing a rather long pattern, it is
now simply selectable from combo boxes.

The LV2 plugins should now work fine in Ardour, Qtractor and Carla (1 and
upcoming 2) including transport synchronisation and preset storage.

Qt5 build is supported via configure option, but not recommended at the moment
since the LV2 user interfaces wouldn't work in non Qt5 hosts, so basically
nowhere.

Thanks go to the reliable translators and to the bug reporters, but also to
Rui and Filipe for making their plugin hosts better and better.

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

read more

September 24, 2014 08:00 PM

GStreamer News

gst-editing-services, gst-python and gnonlin 1.3.90 release candidate

The GStreamer team is pleased to announce the first release candidate of the stable 1.4 release series of gst-editing-services, gst-python and gnonlin. 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.

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 gst-editing-services, gnonlin, gst-python, and download tarballs for gst-editing-services, gnonlin, gst-python.

September 24, 2014 01:00 PM

September 22, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Qtractor 0.6.3 - The Armed Hadron beta release!

From: Rui Nuno Capela <rncbc@...>
Subject: [LAA] Qtractor 0.6.3 - The Armed Hadron beta release!
Date: Sep 22, 7:11 pm 2014

Ah, the equinox...

Twice a year a cherished planetary alignment checks in on schedule,
once again.

The little rock gets another round from its warmy solar furnax, from
which were forged. The pale blue dot gets yet another round and to no
surprise, another tinier dot gets here around:

Qtractor 0.6.3 (armed hadron beta) is now released!

Release highlights:
* Revamped mixer (un)dockable panels (NEW)
* Plugin preset selection sub-menu (NEW)
* LV2 Time position/transport event support (NEW)
* Constrained plugin multi-instantiation (FIX)
* Automation curve node resolution (FIX)

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.

nb. Despite the old Qt4 stance, but still recommended, Qtractor does
build, runs and does it all on Qt5 for quite some time now. However, the
former recommendation prevails as the despicable LV2 plugin GUI
X11/embedding support through libSUIL just does NOT work on modern Qt5.


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.3.tar.gz

- source package (openSUSE 13.1):

http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.src.rpm

- binary packages (openSUSE 13.1):

http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.i586.rpm

http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.x86_84.rpm

- quick start guide & user manual (still 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:
- Make the mouse-wheel to scroll the plugin list views, when not
hovering a direct-access parameter slider.
- Mixer widget gets (un)dockable Inputs and Outputs panels, also with
their respective title captions.
- Plugin instantiation is now constrained as much to prevent any audio
channel output overriding.
- Existing plugin presets may now be selected right(-click) from plugin
list context-menu (ticket by Harry van Haaren, thanks).
- So-called "painting" over multiple selected event values, while on the
MIDI clip editor view pane below the main piano-roll (eg. note
velocities, controller values, etc.) is now split into two similar
painting modes, whether the sub-menu Edit/Select Mode/Edit Draw is set
on (free-hand) or off (linear).
- Drag-and-copy of plug-in instances across tracks or buses (ie.
cloning) now also copies the direct access parameter setting (ticket by
Holger Marzen, thanks).
- File/Save As... now prompts and suggests an incremental backup name
for existing sessions files.
- Zooming in/out increment is now augmented by whether shift /ctrl
keyboard modifiers are set (on a ticket request by
Holger Marzen, thanks).
- LV2 Time position event messages for plugin atom ports that support it
is now being implemented.
- Attempt to break extremely long audio [message continues]

read more

September 22, 2014 08:00 PM

zthmusic

Video, changes to the blog, and more

Feels like it has been forever since I’ve posted on this blog. Which, looking back on the recent post date, is more or less true.. Well, I’ve been up to lots of different stuff, and time has really been short. … Continued

The post Video, changes to the blog, and more appeared first on zthmusic.

by zth at September 22, 2014 07:01 PM

rncbc.org

Qtractor 0.6.3 - The Armed Hadron beta release!

Ah, the equinox...

Twice a year a cherished planetary alignment checks in on schedule, once again.

The little rock gets another round from its warmy solar furnax, from which were forged. The pale blue dot gets yet another round and to no surprise, another tinier dot gets here around:

Qtractor 0.6.3 (armed hadron beta) is now released!

Release highlights:

  • Revamped mixer (un)dockable panels (NEW)
  • Plugin preset selection sub-menu (NEW)
  • LV2 Time position/transport event support (NEW)
  • Constrained plugin multi-instantiation (FIX)
  • Automation curve node resolution (FIX)

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.

nb. Despite the old Qt4 stance, but still recommended, Qtractor does build, runs and does it all on Qt5 for quite some time now. However, the former recommendation prevails as the despicable LV2 plugin GUI X11/embedding support through libSUIL just does NOT work on modern Qt5.

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:

  • Make the mouse-wheel to scroll the plugin list views, when not hovering a direct-access parameter slider.
  • Mixer widget gets (un)dockable Inputs and Outputs panels, also with their respective title captions.
  • Plugin instantiation is now constrained as much to prevent any audio channel output overriding.
  • Existing plugin presets may now be selected right(-click) from plugin list context-menu (ticket by Harry van Haaren, thanks).
  • So-called "painting" over multiple selected event values, while on the MIDI clip editor view pane below the main piano-roll (eg. note velocities, controller values, etc.) is now split into two similar painting modes, whether the sub-menu Edit/Select Mode/Edit Draw is set on (free-hand) or off (linear).
  • Drag-and-copy of plug-in instances across tracks or buses (ie. cloning) now also copies the direct access parameter setting (ticket by Holger Marzen, thanks).
  • File/Save As... now prompts and suggests an incremental backup name for existing sessions files.
  • Zooming in/out increment is now augmented by whether shift /ctrl keyboard modifiers are set (on a ticket request by Holger Marzen, thanks).
  • LV2 Time position event messages for plugin atom ports that support it is now being implemented.
  • Attempt to break extremely long audio file peak generation on session close or program exit (as reported by EternalX, thanks again).
  • MIDI Controllers Hook and Invert properties are now properly saved for tracks (after bug report by Nicola Pandini, thanks).
  • A segmentation fault when closing with VST plugins open has been hopefully fixed (after a patch by EternalX, thanks).
  • Messages standard output capture has been slightly improved as for non-blocking i/o, whenever available.
  • Automation curve node editing has been slightly improved in regard to time positioning and resolution.

Enjoy && Have fun.

by rncbc at September 22, 2014 05:30 PM

Libre Music Production - Articles, Tutorials and News

Qtractor version 0.6.3 is released

Rui Nuno Capela has just announced a new release of Qtractor, an audio and MIDI multi-track sequencer. The new version, codenamed The Armed Hadron, has a number of new features, including the usual bug fixes.

Release highlights:

by Conor at September 22, 2014 04:44 PM

September 20, 2014

linux audio live

madfuload (m-audio transit), fedora 20 and ubuntu 13

I’m stuck. Madfuload used to put my M-Audio Transit card to work under linux but not on the new Ubuntu versions or Fedora (I recently changed to Fedora 20). It doesn’t work anymore. Something has changed.

It’s not in the repository (of Fedora) so I downloaded the sources (madfu loader). The configure scripts have to be adjusted slightly to get the sources compiled. The Transit still doesn’t work, neither does the Midiman Oxygen according to a post from Oliver Sampson on the madfu user mailing list, where the necessary changes in the configure scripts can be found, too.

So, any help is really appreciated. What’s wrong? I tried to use the dfu-programmer, so far with no success either. Is there more people with this problem? With common efforts it should be possible to solve (“Like” this to solve the problem)!


by linuxaudiolive at September 20, 2014 09:28 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Rivendell v2.9.3

From: Fred Gleason <fredg@...>
Subject: [LAA] Rivendell v2.9.3
Date: Sep 20, 7:37 pm 2014

On behalf of the entire Rivendell development team, I'm pleased to
announce the availability of Rivendell v2.9.3. Rivendell is a
full-featured radio automation system targeted for use in professional
broadcast environments. It is available under the GNU General Public
License.

From the NEWS file:
*** snip snip ***
Changes:
Fixed a DSP bug that caused audio distortion in the Local Audio
Adapter device for ALSA.

Various other bug fixes. See the ChangeLog for details.

Database Update:
This version of Rivendell uses database schema version 239, and will
automatically upgrade any earlier versions. To see the current
schema version prior to upgrade, see RDAdmin->SystemInfo.

As always, be sure to run RDAdmin immediately after upgrading to
allow any necessary changes to the database schema to be applied.
*** snip snip ***

Further information, screenshots and download links are available at:

http://www.rivendellaudio.org/

Cheers!


|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| -- Cicero |
|----------------------------------------------------------------------|
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

September 20, 2014 08:00 PM

September 18, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] Super Announcement - All MOD software for your PC

From: Gianfranco Ceccolini <gianfranco@...>
Subject: [LAA] [ANN] Super Announcement - All MOD software for your PC
Date: Sep 18, 6:50 am 2014

Hello Linux Audio Users and Developers

In less than an our the MOD Duo Kickstarter campaign will go live and so it is with great pleasure that the MOD Team makes the announcement of the desktop versions for our entire software suite.

Some of this software has already been announced in the past but, as part of our Kickstarter campaign, we put the necessary effort to have them running in a regular Linux environment and not just inside the MOD. All instructions in Github were also updated in order to yield working elements when followed.

Most of this software has been under development for almost two years and their history is related to the development of the MOD itself. Being so, they carry some differences in workflow when compared to other LV2 programs and our current effort is being put on correcting those differences.


The softwares are:


MOD Client - run your LV2 plugins using the MOD interface.

https://github.com/portalmod/mod-client


——————————————————————————————————————————

MOD SDK - plugin interface creator

Use this program to create the HTML interface required by the MOD Client. If you don’t create an interface the plugins still work, but their icons will be a tuna fish can with just the ON/OFF button. When you click on the gear symbol on the upper right side of the icon you have access to the Plugin Settings Screen in which all parameters are visible.

The MOD SDK is Python based and can be installed by typing “pip install modsdk”

As the MOD Client, it runs on your browser and requires a mod-workspace folder (or link) in which you place your LV2 bundles.

Just run “modsdk" in your terminal and point your browser to localhost:9000

There is also post on our blog about the SDK: http://portalmod.com/blog/2014/09/the-mod-sdk

——————————————————————————————————————————

LV2BM - tool for analyzing and benchmarking LV2 plugins

Allows to select which URIs to test

Uses minimum, maximum and default control values to run the plugins

Uses several controls combinations in the full test mode

The output shows the JACK load percent


——————————————————————————————————————————

Plugins


- CAPS-LV2
LV2 port of the CAPS suite of LADSPA plugins.

- TAP-LV2 -
LV2 port of the TAP suite of LADSPA plugins.

- Pitch shifters - http://github.com/portalmod/mod-pitchshifter
Capo - up to 7 semitones up pitch shifting
SuperCapo - up to 24 semitones up pitch shifting
Drop - up to 12 semitones down pitch shifting
SuperWhammy - continuous pitch shifting from -12 to 24 semitones
Harmonizer - scale interval generator

- Utilities - https://github.com/portalmod/mod-utilities
Switchbox - A/B box for audio signal routing
SwitchTrigger - 4 excluding channel selector
ToggleSwitch - 4 non-excluding channel selector
Gain (mono and stereo)
Filters (LP, HP and BP) - 1st, 2nd and 3rd order
Two way mono crossover - 1st, 2nd and 3rd order
Three way mono crossover - 1st, 2nd and 3rd order

- Distortions - mathematical simulations of classic distortion circuits
BigMuff
DS-1
Muff Fuzz

- SopoperLooper
LV2 simplified port of the SooperLooper.

All plugins from our repository have the HTML MOD GUI included.

In our Github repository - www.github.com/portalmod - we also have plugins that were forked from the original repositories.

One of our aims is to trig [message continues]

read more

September 18, 2014 07:00 AM

[LAA] OpenAV ArtyFX 1.2 Released!

From: Harry van Haaren <harryhaaren@...>
Subject: [LAA] OpenAV ArtyFX 1.2 Released!
Date: Sep 18, 6:50 am 2014

Hey *,

Its my pleasure to release ArtyFX 1.2!

Checkout the plugins on the website: now
includes quick reference for each plugin:
http://openavproductions.com/artyfx/

Code available on github:
https://github.com/harryhaaren/openAV-ArtyFX/releases/tag/release-1.2

Cheers -Harry

--

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

read more

September 18, 2014 07:00 AM

[LAA] Vee One Suite 0.5.1 - One second official beta release!

From: Rui Nuno Capela <rncbc@...>
Subject: [LAA] Vee One Suite 0.5.1 - One second official beta release!
Date: Sep 18, 6:50 am 2014

Howdy,

The gand-of-three aka. the Vee One Suite of old-school
soft(ware)-instruments, featuring synthv1 [1], a polyphonic synthesizer,
samplv1 [2], a polyphonic sampler and drumkv1 [3], as a drum-kit
sampler, are once again released in beta phase though.

The changes for this one second beta release are the following:

- Fixed LV2 plugin relative/absolute file path state resolution.
(drumkv1 [3] only).
- One decimal digit added to all scalar parameters and knobs.
- Stand-alone JACK client ports outrageously renamed from a zero based
numbering scheme into a plus one natural one.
- Experimental LV2 Time/position atom-event support (Delay BPM).

Please, don't hesitate to ask whether any of the above esoteric babbles
doesn't get you on to update as soon as you can. One special note goes
for all the users out there of drumkv1 [3] LV2 genre: the update is not
just interesting but a must, seriously ;).

As usual, all is 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 gore details are as follows ;)

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

synthv1 0.5.1 (second official beta) is out!

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.1.tar.gz

- source package:

http://download.sourceforge.net/synthv1synthv1-0.5.1-18.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/synthv1synthv1-0.5.1-18.rncbc.suse131.i586.rpm

http://download.sourceforge.net/synthv1synthv1-0.5.1-18.rncbc.suse131.x86_84.rpm


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

samplv1 0.5.1 (second official beta) is out!

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.1.tar.gz

- source package:

http://download.sourceforge.net/samplv1/samplv1-0.5.1-18.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/samplv1/samplv1-0.5.1-18.rncbc.suse131.i586.rpm

http://download.sourceforge.net/samplv1/samplv1-0.5.1-18.rncbc.suse131.x86_84.rpm


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

drumkv1 0.5.1 (second official beta) is out!

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.1.tar.gz

- source package:

http://download.sourceforge.net/drumkv1/drumkv1-0.5.1-14.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/drumkv1/drumkv1-0.5.1-14.rncbc.suse131.i586.rpm

http://download.sourceforge.net/dr [message continues]

read more

September 18, 2014 07:00 AM

[LAA] Rivendell v2.9.2

From: Fred Gleason <fredg@...>
Subject: [LAA] Rivendell v2.9.2
Date: Sep 18, 6:49 am 2014

On behalf of the entire Rivendell development team, I'm pleased to
announce the availability of Rivendell v2.9.2. Rivendell is a
full-featured radio automation system targeted for use in professional
broadcast environments. It is available under the GNU General Public
License.

From the NEWS file:
Changes:
Fixed a regression that broke report generation.

Database Update:
This version of Rivendell uses database schema version 239, and will
automatically upgrade any earlier versions. To see the current
schema version prior to upgrade, see RDAdmin->SystemInfo.

As always, be sure to run RDAdmin immediately after upgrading to
allow any necessary changes to the database schema to be applied.

*** snip snip ***

Further information, screenshots and download links are available at:

http://www.rivendellaudio.org/

Cheers!


|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| -- Cicero |
|----------------------------------------------------------------------|

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

read more

September 18, 2014 07: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 September 18, 2014 04:12 AM

September 17, 2014

Libre Music Production - Articles, Tutorials and News

MOD Duo launches Kickstarter campaign

The MOD Duo, a hardware guitar effects unit running open source software, has just officially launched it's kickstarter campaign.

As opposed to other hardware units out there, the MOD Duo allows you to download, arrange, control and share effects, all using the power of open source software.

by Conor at September 17, 2014 05:11 PM

Open Source Musician Podcast

Open Source Musician Podcast - Episode #70

News:
Uhe plugins - http://www.u-he.com
   - free binary of podolski synth, *send them feedback!* - http://www.kvraudio.com/forum/viewtopic.php?f=31&t=419984&sid=934e99f0e4796ce4f34db82f14f5ed94
Mod Open Source Hardware Effect Pedals - http://portalmod.com/
 
Send us your questions, songs, and content submissions: contributions@opensourcemusician.com

September 17, 2014 01:52 PM

September 16, 2014

Create Digital Music » open-source

littleBits Adds “User-Generated” Hardware, Launches Store with Oscilloscope, Bleep Drum

littleBits, the snap-together magnetic hardware module system for easy DIY hardware mash-ups, has a unique take on how to add new hardware. Previously, modules came from littleBits; the popular Synth Kit collaboration with KORG being a significant exception. littleBits has certainly offered a lot of options, including the recent Cloud Kit for adding Internet connectivity.

But now, it’s opening up hardware development to anyone with an idea. While littleBits calls itself “open source hardware” – founder Ayah Bdeir even co-founding the Open Hardware Summit — that openness has always been restricted when it comes to the magnetic connectors. Those are proprietary, and littleBits has told us previously that they’d be hard for anyone else to manufacture.

That changes with the release of the “Hardware Development Kit” (HDK) and the new Pro Module and connectors. Now you can add littleBits connectors to any project you’ve made. Built an Arduino-powered noisemaker? Now you can connect it electrically to littleBits using magnets. The US$39.95 HDK is basically a bundle of Proto Modules, magnetic snaps, and a perf board for assembling circuits. See video below.

That’s already very cool, but littleBits – fresh with venture funding – is going further. They’re letting users vote on modules they want, then manufacturing them if projects get a minimum of 1000 votes. (It’s up to makers whether to go open source or not, though the current modules are all open circuit designs, and littleBits tells us they’re encouraging the idea.)

There are various launch partners, including Makey Makey and an EKG. For us music folks, that already includes Bleep Labs and their lovely Drum Beat drum machine, which should pair nicely with the KORG Synth Kit (see video at top), and the Gabotronics oscilloscope, from Venezuela-born, Florida-based developer Gabriel Anzziani. (I’d love to see hardware show up in Venezuela, Gabriel, but that’s another topic!)

Here’s a look at those modules I’m especially excited about – see the oscilloscope at top and drum at bottom:

oscilloscope

image001

large_filled_littlebit-drum-3

If you join the manufacturing program and your design goes into production, littleBits tells CDM you earn 10% net revenue (gross revenue minus returns, discounts, etc.) on your work, plus co-branding if you have an established brand, as works with KORG. That’s of course a fairly slim margin compared to what you’d optimally have producing hardware yourself, but it also means you don’t carry the obligation of manufacturing, distribution, and sales support, which can drive your take-home profits down to that number or into red ink and requires you to have your own capital.

Impressively, they’re also promising worldwide distribution.

Here’s the new hardware development stuff:

HDK_2a

I still find the littleBits idea fascinating. The modules aren’t cheap compared to buying individual parts, but of course, that saves DIYers the trouble of soldering and allows insanely rapid prototyping with different combinations of modules. There are some tradeoffs for designing music solutions too: the connectors can snap apart as easily as together, and some of the (necessary) requirements of designing the hardware can restrict certain ideas. But there’s still a lot of potential. It’s best thought of as its own universe than a direct competitor for standalone DIY hardware or things like Eurorack modules. (I only bring this up as I’ve seen some direct comparisons, and that may miss the point.)

If you’re interested, check out the lab, vote for projects you like, or even consider making your own hardware:

http://littlebits.cc/bitlab

Submission Requirements

The post littleBits Adds “User-Generated” Hardware, Launches Store with Oscilloscope, Bleep Drum appeared first on Create Digital Music.

by Peter Kirn at September 16, 2014 02:55 PM

September 14, 2014

Midichlorians in the blood

Notes about VMPK 0.6.0 for Desktops

Dear Blog,

It has been a long time, but a week later after the release it is time to discuss some aspects of the latest version of our Virtual MIDI Piano Keyboard for desktop computers.

Where to start? an interesting point is the change of architecture with the replacement of RtMIDI by Drumstick-RT. This library is new and homegrown, part of the Drumstick family which includes Drumstick-File and Drumstick-ALSA as well. The motivation to create it was the difficulty of extending RtMIDI with other drivers different to the ones chosen by his author. This was not a problem in the past, because the RtMIDI sources were always included in the application, and any customization was possible and easy. Now, thanks to the Taliban of Linux distributions forcing the dynamic linking of RtMIDI this is simply not feasible - to the hell with the freedom of Free Software!. Throwing away the ipMIDI backend was not an option. On the other hand, with Drumstick RT is not only possible, but new backends can be compiled separately and installed in the system without recompiling neither VMPK nor Drumstick, because they are in fact plugins. By chance it also has fixed the bug reported (in 2009!) in ticket #15: LinuxSampler did not appear among ALSA connections, because LinuxSampler MIDI port has no flag providing proper characterization and RtMIDI (unlike Drumstick RT) filters out that port.

The replacement of the RtMIDI library with Drumstick-RT was a long time plan, not only for VMPK, but for Drumstick as well, that finally took place now. I hope that this shall be a foundation for features like recording/playback in the future. The only thing that maybe would be missing for some users is the jack-midi interface, but on the other hand Unix users will enjoy native OSS support, and also FluidSynth direct output on all operating systems, meaning  also configurable SoundFonts: a very demanded feature for Windows users.

Another long time request finally implemented is the ability of displaying any number of keys, for instance 88 keys, instead of full octaves, starting with any arbitrary white note (ticket #39), like configuring 25 or 49 keys (depending on which device, laptop or tablet, and screen size you have). Congratulations to all the requesters and sorry for keeping you waiting for this feature so long.

Finally, the migration to Qt5 has happened. This means also replacing a dependency from Xlib to XCB, that hopefully will bring future support for wayland/whatever. The victim has been the keyboard grabbing feature, that was only working on Linux thanks to a now lost X11/Qt4 feature. I hope to bring it back in the future with a multiplatform implementation.

There are now binary packages for 32/64 bit Linux users that shall work on any modern distribution, in the form of installers packaged using the excellent BitRock InstallBuilder. That means including all the required dependencies inside the package, in the same way the libraries are included in the Windows and Mac OS X setup packages. In order to reduce the package weight, superfluous things like Jack support were excluded, because the new FluidSynth backend is intended to provide instant audio out of the box without requiring the users to search, find, ask, learn, install, try and tweak. Something that traditional Linux distributions have failed to do, in despite of their duty of integration and making the life easier to their users. I am pretty sure that many Linux distros will fail to provide VMPK native packages for this release like they did for the 0.5.x  series (see Debian, Ubuntu and Fedora repositories for instance). Prove me wrong, and this kind of binary Linux packages would be deprecated.

by Pedro Lopez-Cabanillas (noreply@blogger.com) at September 14, 2014 11:36 PM

Libre Music Production - Articles, Tutorials and News

September 12, 2014

Libre Music Production - Articles, Tutorials and News

New release of Vee One Suite plugins

Rui Nuno Capela has just announced version 0.5.1 of his Vee One Suite of plugins. The plugin suite is available in the LV2 plugin format as well as standalone JACK clients, with NSM support. There are 3 plugins in the suite. They are as follows -

Synthv1 - an old-school polyphonic synthesizer
Samplv1 - an old-school polyphonic sampler
Drumkv1 - an old-school drum-kit sampler

by Conor at September 12, 2014 07:35 PM

rncbc.org

Vee One Suite 0.5.1 - One second official beta release!

Howdy,

The gang of three aka. the Vee One Suite of old-school software instruments, featuring synthv1, as a polyphonic synthesizer, samplv1, a polyphonic sampler and drumkv1, as a drum-kit sampler, are once again released in beta phase though.

The changes for this one second beta release are the following:

  • Fixed LV2 plugin relative/absolute file path state resolution. (drumkv1 only).
  • One decimal digit added to all scalar parameters and knobs.
  • Stand-alone JACK client ports outrageously renamed from a zero based numbering scheme into a plus one natural one.
  • Experimental LV2 Time/position atom-event support (Delay BPM).

Please, don't hesitate to ask whether any of the above esoteric babbles doesn't get you on to update as soon as you can. One special note goes for all the users out there of drumkv1 LV2 genre: the update is not just interesting but a must, seriously ;).

As usual, all is 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 gore details are as follows ;)

synthv1 - an old-school polyphonic synthesizer

synthv1 0.5.1 (second official beta) is out!

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.1 (second official beta) is out!

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.1 (second official beta) is out!

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 && have fun.

by rncbc at September 12, 2014 05:00 PM

September 11, 2014

Libre Music Production - Articles, Tutorials and News

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Rivendell v2.9.1

From: Fred Gleason <fredg@...>
Subject: [LAA] Rivendell v2.9.1
Date: Sep 11, 6:57 pm 2014

On behalf of the entire Rivendell development team, I'm pleased to
announce the availability of Rivendell v2.9.1. Rivendell is a
full-featured radio automation system targeted for use in professional
broadcast environments. It is available under the GNU General Public
License.

From the NEWS file:
Changes:
RDImport Enhancements. Added '--cart-number-offset' and
'--set-daypart-times' switches to rdimport(1) while also extending
metadata import for SCOT chunks to include segue marker data.

New Device Support. Added support for the Broadcast Tools
GPI-16 General Purpose Input Module. See the 'SWITCHERS.txt' file
for details.

Build System Cleanups. Cleaned up many autotool and compiler
warnings while also implementing a '--sysconfdir=' switch in
'configure'. See the 'INSTALL' file for details.

Various bug fixes. See the ChangeLog for details.

Database Update:
This version of Rivendell uses database schema version 239, and will
automatically upgrade any earlier versions. To see the current
schema version prior to upgrade, see RDAdmin->SystemInfo.

As always, be sure to run RDAdmin immediately after upgrading to
allow any necessary changes to the database schema to be applied.
*** snip snip ***

Further information, screenshots and download links are available at:

http://www.rivendellaudio.org/

Cheers!


|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| "No, `Eureka!' is Greek for `This bath is too hot!'" |
| -- Dr. Who |
|----------------------------------------------------------------------|

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

read more

September 11, 2014 07:00 PM

[LAA] DrumGizmo 0.9.6 released

From: Lars Muldjord <muldjordlars@...>
Subject: [LAA] DrumGizmo 0.9.6 released
Date: Sep 11, 6:57 pm 2014

We're very proud to announce the immediate availability of DrumGizmo
version 0.9.6!

New features / fixes include:
- 64bit dll for Windows. Loading of bigger kits now possible if you
have the ram for it.
- Better spread of velocities for instruments with few samples. This
was especially a problem with the cymbals in MuldjordKit2.
- Possible fix for the bug where certain hits would seem to disappear.
Please re-report this if you still experience it!
- Possible fix for the bug where all hits got played at highest
velocity. Please re-report this if you still experience it!
- Bug fixes! If you had a problem with 0.9.5, please try out 0.9.6 and
let us know if you still have the same problem.

Notes:
The drumkit editor DGEdit is now split out into its own project. More
info on this soon.

Download it from http://www.drumgizmo.org

Visit us at the official irc channel at the Freenode network. Channel
name is #DrumGizmo. We would love to hear from you.

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

read more

September 11, 2014 07:00 PM

Scores of Beauty

How to write readable tuplets

All notation programs aim of course at being as powerful a tool as possible to help composers, arrangers and engravers rather than hold them back. I’d like to explore an area where I think you have to use these powers with care – I’m talking about tuplets.

This article is written from the perspective of writing music in LilyPond (this is after all the LilyPond blog) but my aim is that anyone interested in music notation should be able to follow this.

Tuplets in LilyPond

Most readers of this blog would of course already know that as of LilyPond 2.17.x the syntax for writing a tuplet is this:

\tuplet fraction { music }

Those who aren’t familiar with LilyPond will note that it is text-based, and that ‘writing’ music here is more literal than in more graphical programs. Here’s an example with an ordinary triplet:

\tuplet 3/2 { g8 a b }

tupl-ex1
As a side note I personally think that tuplets are an area where the text-based model really is an advantage. I’d like to illustrate this by showing how easy it is to make a nested tuplet. Here is the last triplet quarter substituted with another triplet:

\tuplet 3/2 {
    g4 a
    \tuplet 3/2 { g8 a b }
  } g2

tupl-ex2
In my experience though the real advantage comes when you have to edit an already created tuplet.

Readable tuplets?

Different notation programs may have small restrictions for what is possible but I think it can be assumed that the aim is to make notation as easy as writing with pen and paper, so in theory the only impediments are limited imagination and rhythmical miscalculations. But where this can make life easy for the person who writes the music it can make life hard on the person who is to perform it. When we are talking about nested tuplets that is of course very complex. But also single tuplets can be somewhat overpowering.

It should be noted that LilyPond and other notation programs don’t prevent the user from creating tuplets that are ambiguous or even totally misleading, just as they don’t prevent the user from bad notation in general – the more flexible and powerful the program, the more responsibility for the user. Hence you should always seek to follow notational practices to facilitate the interpretation of the score.

Unfortunately for tuplets the situation is even more complex because of there being two conventions regarding their notation that are somewhat competing:

The mathematical rule

The first rule regarding tuplet notation is slightly mathematical. It says that if you calculate the tuplet fraction the result should always be between 1 and 2. (For those of you who would like an even more mathematical definition this could be stated as: 1 < Tf < 2 where Tf is the tuplet fraction.)

To further explain this rule and its rationale I would like to start with the fraction 3/4 (= 0.75 < 1), which is disallowed by the rule. Why is that? Let’s look at this example:

\tuplet 3/4 { g8 a b } d4 e

tupl-ex3
We have three 8ths in the space of four 8ths and then we have 2 ordinary quarters just like we prescribed. But this looks completely wrong. And that is of course because we have a very strong convention that three 8ths as a tuplet/triplet equals a quarter and not a half. Thus we normally would obey the mathematical rule, in the case of triplets at least. We would instead use the fraction 3/2, which is allowed by the rule (1 < 3/2 = 1.5 < 2). It would look like this:

\tuplet 3/2 { g4 a b } d4 e

tupl-ex4
It could again be noted that although the first example is very misleading and would take some attention to figure out, it would not result in any error or warning from LilyPond. And I don’t think it should, it should be up to the user to think of readability and proper notation. Furthermore a composer could have a very good reason to choose a non-standard notation and should be allowed to do so.

What happens on the other end, when the fraction is greater than 2? With this rule e.g. the fraction 5/2 (= 2.5 > 2) isn’t allowed. Let’s again look at an example:

\tuplet 5/2 { g8 a b c d } c2.

tupl-ex5
Here again it looks wrong; it seems very strange to put as many as five 8ths in the duration of a quarter and we can just as easily as in the previous example see the rationale for the rule. Here the duration of the five 8ths should take up a half, as in this example:

\tuplet 5/4 { g8 a b c d } c2

tupl-ex6
To conclude before moving to the next rule, this rule should be fairly easy to follow, and it’s actually what I would prefer and even recommend.

The nearness rule

Now for the second rule. Let’s begin with this example:

\tuplet 7/4 { g8 a b c d e f } e2

tupl-ex7
This follows the first rule. But in the same space as the seven tuplet 8ths we could fit eight 16ths and only 4 regular 8ths. Isn’t it then more intuitive to use 16th notes for this instead?

\tuplet 7/8 { g16 a b c d e f } e2

tupl-ex8
No, I don’t really think so and this wouldn’t be allowed by the first rule, because the fraction is less than 1. But the supporters of the second rule would say that this is the way to do it. The second rule could roughly be stated as saying simply that tuplets should mimic the regular note values as closely as possible, thus I call it the “nearness rule”.

I think it’s important to note that this second rule is less definite than the first. It isn’t hard to find examples where you couldn’t absolutely settle what the rule would recommend. Take for instance the previous example of 3/4 — this is as close to regular note values as 3/2 but the general convention would definitely rule it out. On the other hand, even if this practice of 3/2 is not fully sanctioned by the second rule it is definitely not contradictory to it.

Maybe it’s too hard on this practice of seeking the nearness relation to require it to give a definite answer in every instance. Maybe it’s even misleading to call it a rule. I guess it’s on a more intuitive level when you choose the notation which is nearest to the standard division.

Must I follow a rule?

To write music in a notational software is of course not more flexible than to write music with pen and paper. But with tuplets at least I think the software invokes the idea that the flexibility which is allowed by the program is also a flexibility I have as a creator. When writing with pen and paper you get a better sense of having to create the boundaries yourself. (This is my own experience anyway.)

I think I have shown that it is possible to construct examples which are fully possible to conceive and create but which run counter to our normal idea of how tuplets should be notated and interpreted. But I have also explained that the consensus isn’t clear in detail on how to notate tuplets. Isn’t it then more important to make the notation distinct and unambiguous (for example by clearly stating the ratio) than to follow these competing rules?

Let’s go back to the previously discussed ratio 3/4, here’s the example again with explicit ratio and additionally the explicit note value of the denominator:

\once \override TupletNumber.text =
    #(tuplet-number::append-note-wrapper
      tuplet-number::calc-fraction-text "8")
  \tuplet 3/4 { g8 a b } d4 e

expl-ratio
Now this notation should be clear – it’s three 8ths replacing four 8ths; although unusual, it’s now also unambiguous.

If you have good reasons to create a non-standard tuplet it’s of course advisable to make it clear in this way. But I think the ability to make yourself clear should not be taken as an excuse for arbitrarily breaking the conventions that after all exist.

It’s equally easy to write 3/4 as 3/2 but the former will require a clarification and hence a greater effort from both you and your reader. So the choice should be obvious for most cases.

Again, this is not an argument against using the more explicit notation of the tuplet ratio to make it clearer. There are of course cases where it instead decreases the effort of the reader. It could be noted that Gould in Behind Bars recommends indicating ratios in full when using the nearness rule in a way that contradicts the mathematical rule (which she, like me, thinks is clearer).

Conclusions

Creating tuplets in LilyPond and other notation software is very flexible and powerful, but you as a user should be careful not to misuse these powers. We have seen that currently there are two conventions on how to notate tuplets and that LilyPond in these examples isn’t taking a side between these two views, and as long as these two conventions exists side by side she should not do that. But you as a music writer should definitely take a side and only use one of the conventions at the time. Otherwise it could potentially be very confusing for the reader and performer of the music you write.

My main point here is not to restrict the use of tuplets (they are part of our musical language), but when they are used they should be notated carefully in order not to unnecessarily increase the complexity. Don’t trust the software to do the thinking for you — take those conventions that exists into account and if you want to go beyond then use the possibility of making the notation more explicit.

What do you think? Please share your thoughts in a comment!

References:

Elaine Gould – Behind Bars (London, Faber Music Ltd, 2011)
Gardner Read – Modern Rhythmic Notation (London, Victor Gollancz Ltd, 1980)

by Peter Bjuhr at September 11, 2014 11:34 AM

September 10, 2014

Create Digital Music » Linux

Finally, Connect a USB Hub and Audio in One Gadget, on Laptop or iPad

AudioHub-3quart_Retouch-HR

File this directly under “why has no one done this properly before?”

One of the few remaining annoyances in computer music making is just getting connected. First, you need an audio interface to get proper sound and headphone cueing. Then, you’ve got all this great gear for control – but where to put it? Macs and even many new PCs have few USB ports (especially ultrathin notebooks like the MacBook Air).

Yes, it’s about time someone combined a practical audio interface with a USB hub.

Focusrite/Novation seem to be the right folks for the job. Focusrite’s audio interfaces are some of the best of the bunch – I’ve had good luck with their drivers, and they deliver good sound for the price, thanks to the company’s experience in things like mic pres. Novation, meanwhile, are one of the companies making all the stuff you want to plug in (like the ever-popular Launchpad line).

The Novation-branded Audiobus, labeled “Audiohub 2×4″ (meaning I would expect they have other configurations in mind), merges both sides. There’s a 96kHz, 24-bit Focusrite interface for the audio guts, plus a three-port, powered USB hub.

AudioHub-PP_Image7

Specs:

Three USB 2.0 ports
Stereo line input (phono/cinch plug) with high/low gain switch
Four line RCA outputs or two balanced jack outputs
“Loud” outputs, including the headphone jack (with DJs and producers in mind)
Bus-powered audio interface – or connect a 12V DC power supply (included) to power the USB hub
Low latency performance and zero-latency (direct) monitoring

AudioHub-rear-HR

Crucially, those headphones can be set to outputs 1-2 or 3-4, so you do get separate headphone monitoring. That, combined with loud headphone output gain, indeed makes this DJ and live performance worthy. I also like those output knobs on the top of the unit.

And it works with the iPad, Linux, and the like, too, thanks to class-compliant operation. In fact, the hub combined with the ability to connect to iOS via a USB camera adapter makes this really ideal.

All in all, this looks like a box that ticks all the boxes for live PA and DJing. Where it sacrifices things is for those who need a mic or instrument input. If it’s a hit, though, a variant that does that seems close behind.

MIDI is missing, too, but that fits easily on one of the USB ports, so no complaints. (And then you can add more ports, for yet more connectivity…)

And because it’s hard to find a perfect, leave-it-in-your-bag-at-all-times interface for sampling, DJing, and live electronic performance, I have a feeling this will become a classic if they’ve done their job. Definitely hitting the review queue – stay tuned.

In the meantime, Novation has some nice marketing on this – I like the mention of DJ and Maschine sampling workflows alike, alongside this cute artist video.

Not that you need any of this. They had me at “USB hub.”

Novation Audiohub 2×4

The post Finally, Connect a USB Hub and Audio in One Gadget, on Laptop or iPad appeared first on Create Digital Music.

by Peter Kirn at September 10, 2014 05:57 PM

Nothing Special

Adding Blur in Cairo

I've made several widgets now that light up. I've worked around it mostly through gradients. Radial gradients are perfect for a circular LED. A linear gradient filling a carefully shaped path got me by for a square LED. But now I'm making an analog oscilloscope type widget, and a 7 segment LED and gradients aren't cutting it. If only you could do blur in Cairo.

Oh, but you can...


Cairo doesn't NATIVELY support blur, but you can totally blur in Cairo. In fact there is an "official" blur example in the cairo cookbook on their site. I'm no Cairo master, so it took me a bit to figure out how to really apply it to my svg2cairo converted code, dispite having several other examples. But if you've been following along on my ffffltk development you'll also find this post useful. If you haven't... then this is just another example, (though the only one I know of using the "official" blur function).

The goal of ffffltk is to get from inkscape drawing to GUI binary with as little coding as possible, and its not terrible. You do have to do some coding, but its much better than my last attempt was using Qt (more because I've learned a lot than any shortcoming of Qt). Blur unfortunately departs slightly from that goal, but its useful enough that it's worth it. Overall the process is to make your drawing with blur, remove the blur before you convert to cairo (else svg2cario generates unbuildable code), convert to cairo, add the blur in the code, proceed making your gui in ntk-fluid. We'll break down what "add the blur in the code" constitutes as we go.

To make the cairo code generated by svg2cairo work as an ffffltk widget you already have to get your hands dirty editing the code, and adding blur is just a little bit extra work. So lets play with the 16 segment LED display I'm currently working with. Here's the drawing with and without blur:



You see even a 3 pixel blur makes a nice difference to make it look like its glowing. Its also perfect for shadows. The code generated by the non-blurred version (blur doesn't work with svg2cairo) (and run through the script  I gave you in this previous post) looks roughly like this:
#ifndef DRAW_BLUE16SEG_H
#define DRAW_BLUE16SEG_H
#include"blur.h"
inline int cairo_code_draw_16seg_get_width() { return 30; }
inline int cairo_code_draw_16seg_get_height() { return 45; }
inline short char2seg(char c);
inline void cairo_code_draw_16seg_render(cairo_t *cr, char num, unsigned char color) {
unsigned short val = char2seg(num);

cairo_surface_t *temp_surface;
cairo_t *old_cr;
cairo_pattern_t *pattern;
cairo_matrix_t matrix;

cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(0.4,0.4,0.4,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 3.753906, 0.761719);
cairo_line_to(cr, 26.492188, 0.761719);
cairo_curve_to(cr, 28.148438, 0.761719, 29.492188, 2.101562, 29.492188, 3.757812);
cairo_line_to(cr, 29.492188, 41.550781);
cairo_curve_to(cr, 29.492188, 43.207031, 28.148438, 44.550781, 26.492188, 44.550781);
cairo_line_to(cr, 3.753906, 44.550781);
cairo_curve_to(cr, 2.097656, 44.550781, 0.757812, 43.207031, 0.757812, 41.550781);
cairo_line_to(cr, 0.757812, 3.757812);
cairo_curve_to(cr, 0.757812, 2.101562, 2.097656, 0.761719, 3.753906, 0.761719); cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
/********************/
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
cairo_set_line_width(cr, 1.5);
cairo_set_miter_limit(cr, 4);
cairo_set_line_cap(cr, CAIRO_LINE_CAP_SQUARE);
cairo_set_line_join(cr, CAIRO_LINE_JOIN_MITER);
pattern = cairo_pattern_create_rgba(0,0,0,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_pattern_set_matrix(pattern, &matrix);
/********dot************/
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(0,0,.3333,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 27.773438, 39.507812);
cairo_curve_to(cr, 27.773438, 40.652344, 26.847656, 41.578125, 25.707031, 41.578125);
cairo_curve_to(cr, 24.5625, 41.578125, 23.636719, 40.652344, 23.636719, 39.507812);
cairo_curve_to(cr, 23.636719, 38.367188, 24.5625, 37.441406, 25.707031, 37.441406);
cairo_curve_to(cr, 26.847656, 37.441406, 27.773438, 38.367188, 27.773438, 39.507812);
cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
/********************/
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(0,0,.3333,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 18.671875, 3.734375);
cairo_line_to(cr, 18.234375, 6.359375);
cairo_line_to(cr, 19.601562, 8.484375);
cairo_line_to(cr, 23.050781, 8.484375);
cairo_line_to(cr, 26.503906, 4.953125);
cairo_line_to(cr, 25.71875, 3.734375);
cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
/********************/

...

I added the #include blur.h which is really the blur.c in the cookbook edited just  a bit. The full code has 16 dark segments, and 16 identically shaped light ones on top. To make this work as a widget I edited the render function to accept a character and either draw or don't draw light segments based on that character. The full implementation of course is available in my infamous repository. I have a function that encodes the character to a bit sequence where each bit corresponds to a segment (char2seg()). Therefore I use an if to decide if the segment should be drawn like so:
... if(val&0x4000){
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(.3,.6,1,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 18.671875, 3.734375);
cairo_line_to(cr, 18.234375, 6.359375);
cairo_line_to(cr, 19.601562, 8.484375);
cairo_line_to(cr, 23.050781, 8.484375);
cairo_line_to(cr, 26.503906, 4.953125);
cairo_line_to(cr, 25.71875, 3.734375);
cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
}
/********************/
if(val&0x8000){
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(.3,.6,1,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 10.835938, 3.734375);
cairo_line_to(cr, 9.613281, 4.984375);
cairo_line_to(cr, 11.871094, 8.484375);
cairo_line_to(cr, 15.34375, 8.484375);
cairo_line_to(cr, 17.421875, 6.359375);
cairo_line_to(cr, 17.859375, 3.734375);
cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
}
/********************/
...

Now we have a draw function that we can use with the ffffltk_display widget. But it's not blurred. We want the light segments to be blurred and the dark segments and the frame/background to remain solid. The function provided by the cairo cookbook blurs the whole surface that we're drawing to, so we need to create a new, separate surface, draw the things to be blurred on it, blur the new surface, then embed the temporary surface onto the target surface which is really our window. It looks a little like:
...
/********************/
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(0,0,.3333,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 7.144531, 36.796875);
cairo_line_to(cr, 3.71875, 40.296875);
cairo_line_to(cr, 4.527344, 41.546875);
cairo_line_to(cr, 11.542969, 41.578125);
cairo_line_to(cr, 11.976562, 38.984375);
cairo_line_to(cr, 10.566406, 36.796875);
cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
/********************/

//blur
temp_surface = 
   cairo_image_surface_create( CAIRO_FORMAT_ARGB32,
                               30,45);
old_cr = cr;
cr = cairo_create(temp_surface);

/********dot************/
if(num < 0){
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(.3,.6,1,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 27.773438, 39.507812);
cairo_curve_to(cr, 27.773438, 40.652344, 26.847656, 41.578125, 25.707031, 41.578125);
cairo_curve_to(cr, 24.5625, 41.578125, 23.636719, 40.652344, 23.636719, 39.507812);
cairo_curve_to(cr, 23.636719, 38.367188, 24.5625, 37.441406, 25.707031, 37.441406);
cairo_curve_to(cr, 26.847656, 37.441406, 27.773438, 38.367188, 27.773438, 39.507812);
cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
}
/********************/
...
 
So you see the last dark segment being drawn, the new surface is created (in temp surface), an associated cairo context is made and then all the light segments are drawn into it. Then as we get to the last light segment:
...
 /********************/
if(val&0x0002){
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
pattern = cairo_pattern_create_rgba(.3,.6,1,1);
cairo_set_source(cr, pattern);
cairo_pattern_destroy(pattern);
cairo_new_path(cr);
cairo_move_to(cr, 7.144531, 36.796875);
cairo_line_to(cr, 3.71875, 40.296875);
cairo_line_to(cr, 4.527344, 41.546875);
cairo_line_to(cr, 11.542969, 41.578125);
cairo_line_to(cr, 11.976562, 38.984375);
cairo_line_to(cr, 10.566406, 36.796875);
cairo_close_path(cr);
cairo_set_tolerance(cr, 0.1);
cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING);
cairo_fill_preserve(cr);
}
/********************/

blur_image_surface(temp_surface,3);
cairo_set_source_surface(old_cr,temp_surface,0,0);
cairo_paint(old_cr);
cairo_surface_destroy(temp_surface);
cairo_destroy(cr);
}



We blurred the new surface (with blur radius 3 pixels) and the "embeded" the surfaces together using cairo_set_source_surface, then painted the original source surface. After that its just a bit of cleanup. The blur_image_surface()function is where the magic happens and its provided in blur.c in the cairo cookbook. All I did was rename the file to .h and change the functions to be inline. I guess its not really an official cairo function since it doesn't start with cairo. A native implementation is on their todo list, but for now, here's a workaround.

That's all. Pretty simple really. Hopefully that helps someone out there. I can't make any guarantees about performance or anything, it seems like this is doing it fairly manually, so there might be a cheaper way to do it. All of ffffltk could probably use some optimization techniques. If you have tips or tutorials on how to make light cairo programs please comment!

by Spencer (noreply@blogger.com) at September 10, 2014 03:28 PM

September 09, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Port of U-HE synthesizers to Linux

From: Alexandre Bique <bique.alexandre@...>
Subject: [LAA] Port of U-HE synthesizers to Linux
Date: Sep 9, 10:10 am 2014

Hi,

Urs kindly offered me to port his plugins to Linux and we are now
starting some initial testing with Podolski, which is a free
synthesizer (free as in beer).

I invite you to download Podolski for Linux and participate in the
test at http://www.kvraudio.com/forum/viewtopic.php?f=31&t=419984&p=5869575

Thanks a lot, and I hop that you'll enjoy it!

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

read more

September 09, 2014 11:00 AM

[LAA] [ANN] Virtual MIDI Piano Keyboard (VMPK) 0.6.0 has been released

From: Pedro Lopez-Cabanillas <pedro.lopez.cabanillas@...>
Subject: [LAA] [ANN] Virtual MIDI Piano Keyboard (VMPK) 0.6.0 has been released
Date: Sep 9, 10:10 am 2014

Virtual MIDI Piano Keyboard is a MIDI events generator and receiver. It
doesn't produce any sound by itself, but can be used to drive a MIDI
synthesizer (either hardware or software, internal or external). You can use
the computer's keyboard to play MIDI notes, and also the mouse. You can use
the Virtual MIDI Piano Keyboard to display the played MIDI notes from
another instrument or MIDI file player.

Changes for v0.6.0:
* Qt5 migration completed. XCB replacing Xlib on Linux/Unix
* RtMIDI replaced by Drumstick-RT with pluggable backends: ALSA Seq, OSS,
Windows, Mac OSX, Network and FluidSynth.
* Ticket #39: keyboard can start on any note
* Allow to configure any number of keys, instead of full octaves
* New translations: Serbian and Galician

Requirements for all platforms: CMake 2.8/3.0 and Qt 5.1 or later.

Please use the mailing list for questions
and comments. Thanks.

Copyright (C) 2008-2014, Pedro López-Cabanillas and others
License: GPL v3

More info
http://vmpk.sourceforge.net

Downloads
http://sourceforge.net/projects/vmpk/files/vmpk/0.6.0/

Regards,
Pedro


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

read more

September 09, 2014 11:00 AM

September 07, 2014

Libre Music Production - Articles, Tutorials and News

OpenAV announces new plugins in the ArtyFX plugins range

OpenAV have just annouced 3 new plugins to the ArtyFX plugin range. The new plugins for ArtyFX version 1.2 are as follows -

Bitta - Bit crusher
Vidha - Stereo widener
Panda - Compressor/expander

by Conor at September 07, 2014 09:48 AM

September 05, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] OpenAV: ArtyFX 1.2 Announce

From: Harry van Haaren <harryhaaren@...>
Subject: [LAA] OpenAV: ArtyFX 1.2 Announce
Date: Sep 5, 8:18 pm 2014

Hi!

OpenAV is pleased to announce ArtyFX 1.2, bringing three
new plugins to the ArtyFX suite!

Demo video:
http://youtu.be/yPR-P4CZjns

The three plugins are:
-Bitta, for bit crushing
-Vihda, for stereo width
-Panda, for compression/expansion

OpenAV is now accepting donations for these plugins,
details at the ArtyFX page.
http://www.openavproductions.com/artyfx

Cheers, -Harry

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

read more

September 05, 2014 09:00 PM

[LAA]

From: Takashi Iwai <tiwai@...>
Subject: [LAA]
Date: Sep 5, 7:30 pm 2014

Hi,

like previous years, we're going to hold a meeting to discuss
lowlevel audio on Linux. This time it's along with Linux Plumbers
conference, so many people who work on the lowlevel stuff (sound
drivers, sound backends, etc) can meet up nicely there.

For avoiding the conflicts with other LPC mini conferences (and other
parallel conferences), our meeting will be held on Tuesday October 14,
at the same venue as LPC, Congress Center Düsseldorf, Germany.

If anyone is interested, feel free to sign up in the attendee list
below. It's a public accessible Google doc, so you can edit freely.

http://goo.gl/VbXLPW

(or https://docs.google.com/spreadsheets/d/1wBAiAyZSnMjVFJbxdXE5JoVdKGIBIWt-4tuSsHzGw4w/edit?usp=sharing)

The topics that have been currently raised are found in the URL below.
If you have any more topics to discuss there, just put your favorite
one in the URL below as well.

http://goo.gl/JSasQ9

(or https://docs.google.com/spreadsheets/d/1cXzON65QYNrTXi31AIQHffUZ9NWwJuNEJAC0ubfKlZc/edit?usp=sharing)

If you have any question or suggestion, drop me a mail.


Thanks!

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

read more

September 05, 2014 08:00 PM

Scores of Beauty

Towards templating with la-lily-pond

In my previous post “Trees, Music and Lilypond”, I introduced a hierarchical naming scheme to store music in a structured manner and then to use template functions on it. Now I will explain how template functions can also be organized hierarchically (in a tree) and “normalized,” and what benefit we gain from this. In short, this is an effective way to separate different tasks — storing the music (content) is one task and laying it out in a score (presentation) is another. While I was previously writing about the theory grounding this technique, I will now shift these ideas towards the actual implementation and the main goals of this approach. This post will have three parts:

  • First I’ll make some adjustments to the code I shared in my previous post.
  • Second I’ll write about the hierarchical organization of templates.
  • Third I’ll show a “normalized” signature for template functions.

Coding adjustments

The following adjustments will improve our coding and avoid a pitfall when working with trees.

1. dot-notation

When addressing nodes in a tree, we use paths. In my previous post I entered these paths as strings, which were then split into lists. Now I want to show the benefits of a relatively recent LilyPond feature, namely the dot-notation, which provides a better way of working with paths. An argument to a music function with a predicate list? can be entered in dot-notation so that my.path.to.music will yield a list #'(my path to music). So instead of using strings that are split into lists to create such path lists (as in my previous post), from now on I will use the list? predicate and dot-notation for any path input, which avoids the quotes and is (IMO) easier to type.

2. relative paths

As we work with trees, we want to be able to use relative path lists. So say we are at path my.path.to.melody, and we want to access my.path.to.lyrics. We may want to use a relative path to get there, which would look like this list: #'(.. lyrics). The .. part of this relative path moves us one hierarchical step up in the path, and from there we can access the “lyrics” branch instead of “melody.” For this to work, we need a little function to normalize path lists:

#(define-public (normalize-path path)
   (let ((ret '()))
     (for-each
      (lambda (e)
        (set! ret
              (cond ((eq? e '..)(if (> (length ret) 1) (cdr ret) '()))
                (else `(,e ,@ret))))) path)
     (reverse ret)))

Next let’s see how we would use this function to “normalize” a relative path. (The following code also shows the function called “Path” that allows us to use the dot-notation discussed above.)

% get a list from dot-notation
Path = #(define-scheme-function (parser location p)(list?) p)
% a path to a melody
pathToMelody = \Path my.path.to.melody
% create path to lyrics with relative path
pathToLyrics = #(normalize-path (append pathToMelody '(.. lyrics)))

pathToLyrics is “normalized” from my.path.to.melody.'..'.lyrics to my.path.to.lyrics.

3. the tree-object

There is one issue with the association-list based tree that I discussed in my previous post, and this problem might occur while storing either music or templates using paths. If you have stored a template with a path vocal it would be overridden by a second template that was stored with the path vocal.group, which is not what we want. So instead of the association-list approach, I decided to use an object-oriented approach, which is also possible with Scheme. I won’t explain all the details of the Scheme code used to create the trees. Again, if you are not familiar with Scheme, just try to understand the basic idea of a class tree, which has methods get and put.

% OOP module in scheme
#(use-modules (oop goops))

% a class for one tree-node
#(define-class <tree> ()
   ; the children of this node
   (children #:accessor children #:setter set-children! #:init-value '())
   ; the node-name
   (key #:accessor key #:init-keyword #:key #:init-value 'node)
   ; the node-value
   (value #:accessor value #:setter set-value! #:init-value #f)
   )

% set value "val" at "path" in "tree"
#(define-method (tree-set! (tree <tree>) (path <list>) val)
   (if (= (length path) 0)
       ; if we reached the addressed node, set value
       (set! (value tree) val)
       ; else look for child
       (let ((ckey (car path))
             (cpath (cdr path)))
         ; get child tree
         (let ((child (assoc-get ckey (children tree)) ))
           ; if it is not a tree, create one and store it
           (if (not (is-a? child <tree>))
               (begin (set! child (make <tree> #:key ckey))
                 (set! (children tree) (assoc-set! (children tree) ckey child ) )))
           ; ascending the tree recursively
           (tree-set! child cpath val)
           ))
       ))
% get value at "path" in "tree"
#(define-method (tree-get (tree <tree>) (path <list>))
   (if (= (length path) 0)
       ; if we reached the addressed node, return value
       (value tree)
       ; else get next child
       (let* ((ckey (car path))
              (cpath (cdr path))
              (child (assoc-get ckey (children tree)) ))
         (if (is-a? child <tree>)
             ; ascending the tree recursively
             (tree-get child cpath)
             #f)
         )))

With this Scheme code we can create objects of class tree, add objects to it with a method tree-set! and retrieve them with a method tree-get. We can do this at any point in our path without overriding any child values. For example, our tree can now store separate objects under vocal and vocal.staff at the same time.

A template tree

Now that we have these code adjustments in place, we can move on to our next topic which is the hierarchical organization of templates. So far I have mainly written about the tree representing the musical content of a score, but now I’d like to shed some light on another tree: the template tree.

First a brief word about the inherent design pattern that I am using here, from a software development perspective. (This is a sidenote, if you are not familiar with these software development terms, just take note that there are established design patterns that describe what we are doing here.) In my previous post I outlined template functions. Those functions are also hierarchically related: vocalStaff is called by SATBGroup, which might be called in a file combining the five movements of a composition. The functions call each other (roughly) following the composite design pattern or may be seen as the “view” part in the model-view-controller design pattern.

So now we will create a tree to hold our templates and define the functions \registerTemplate and \callTemplate to work with this template tree.

templateTree = #(make <tree>)

registerTemplate =
#(define-void-function (parser location path templ)(list? ly:music-function?)
   (tree-set! templateTree path templ))

A template in this tree can call its children, siblings, or parents, by using a relative path that starts from wherever it is located in the path. So a template with a path vocal can call its child vocal.staff with a relative path staff. A template vocal.group.SATB might call its parent vocal.group with a path ‘..‘. In this way multiple templates can work together and delegate work to other related templates in order to assemble a composite piece of engraved music. This lets us engrave a piece by calling a base template, which then delegates different parts of the work to its child templates. The “leaf” templates may only need to engrave one single context — a Lyrics context, a Staff, or even just a Voice. Each template will only get the musical content that it is to handle or display.

Now that we have a tree for our templates, we store the templates, which are just music functions, in the tree with a function \registerTemplatepath.to.template #(define-music-function ...). The music function we are defining here is our template, and the path.to.template is where it is being stored in the tree. We can then call our templates with a path to the template and a path to the musical content that it will take: \callTemplatepath.to.template path.to.music.

What shall happen during this call?

  1. call the function stored at path path.to.template with the music stored at path "path.to.music".

This looks reasonable. But do we want to do the path-appending (path-unfolding) in a template? No, it would result in a lot of recurring code. But we can avoid this with a global current template path and a global current music path. The functions \getMusic, \putMusic and \callTemplate use those global paths like the current working directory in a file system. Any given template path or music path is taken to be a relative path and is unfolded against the globally stored current base path.

Let’s update our list of what happens during a template call:

  1. set the current template path and the current music path
  2. call the function stored in the current template path
  3. reset the current template path and the current music path to their previous values
callTemplate =
#(define-music-function (parser location template-path music-path)(list? list?)
   ; get template from path
   ; set current template-path and current music-path
   (set! return-value ((ly:music-function-extract templ) parser location music-path)')
   ; reset current template-path and current music-path to previous value
   return-value
   )

This snippet is shortened for readability. I prepared an example file based on the one from my previous post, where the code is complete.

Let us line up, what is happening now:

  1. we call \callTemplate vocal.group.SATB massInC.kyrie to create the music for our score — like \SATBGroup in the previous post
  2. this call sets the current music path to massInC.kyrie and the current template-path to vocal.group.SATB
  3. the template vocal.group.SATB calls the template vocal (its grandparent) with the relative path #'(.. ..), for the four voices with the relative music paths soprano, alto, tenore, basso
  4. the current template path is set to vocal for all four calls, while the current music path is set to massInC.kyrie.soprano, massInC.kyrie.alto, massInC.kyrie.tenore and massInC.kyrie.basso, respectively for each call
  5. the template vocal creates a Staff, a Voice and a Lyrics context using the music from the given path appended with melody and lyrics respectively (i.e. massInC.kyrie.soprano.melody, massInC.kyrie.soprano.lyrics, etc.) — like \vocalStaff in the previous post

Normalizing the signature

What advantage do we gain with this tree of templates? To answer this, we will first add an argument to the signature of all the template functions. Any template must define two arguments, music-path and options, both with a predicate list?:

#(define-music-function (parser location music-path options)(list? list?) ...)

The music-path is not essentially needed as it is available as #(current-music-path), but it is still given for convenience (and backward-compatibility).

Now we can give an association list with an arbitrary set of options to the templates. So vocal.group.SATB can call vocal with additional arguments (options) to set the clef, the instrumentName or other needed information. And even better, we can register a template vocal.group wich receives a list of voices as one of its options. That way, we can easily define other choral group setups like SAATBB, for example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
\registerTemplate vocal.group
#(define-music-function (parser location my-path-to-choir options)(list? list?)
   (let ((staff-list (assoc-get 'staff-list options '())))
     #{
       \new ChoirStaff $(make-music 'SimultaneousMusic 'elements
        (map (lambda (staff) #{ \callTemplate #'(..) #(list (car staff)) #(cdr staff) #}) staff-list))
     #}))

% create vocal staffs for Soprano, Alto, Tenore and Basso
\registerTemplate vocal.group.SATB
#(define-music-function (parser location my-path-to-choir options)(list? list?)
   (let ((opts (assoc-set! options 'staff-list '(
                                                  (soprano . ((clef . "G")))
                                                  (alto . ((clef . "G")))
                                                  (tenore . ((clef . "G_8")))
                                                  (basso . ((clef . "bass")))
                                                  ))))
     #{ \callTemplate #'(..) #'() #opts #}))

The vocal.group.SATB template calls its parent (vocal.group) with predefined options. As you can see in lines 13–16, the voices are defined as pairs of a voice name and an association list that contains all options given to the vocal template. But you can also call vocal.group directly with whatever options are needed.

If you are thinking that setting up options as nested association lists manually is quite tedious, then you are absolutely right! But you can use helper functions that are included in openLilyLib and lalily. For example \optionsAdd myOptions staff-list.tenore.clef "G_8" will set the tenor-clef option inside the association list myOptions. I will explain this in more detail when I actually write about lalily.

Consolidation

In the implementations discussed here, the trees and the current paths are hidden and secured inside a closure which is part of a scheme module. If you are not familiar with scheme, modules, or closures, the important part is the attribute “hidden and secured.” The trees are globally available and won’t be overridden, for example, if you include files twice. The trees and their fruits, namely the music and the templates, are globally available, so you can separate the tasks of music input (content) and engraving (presentation). You can first include multiple files containing \putMusic statements and then build a book with several scores in it.

What’s next?

Now we have defined the core functions which are used in openLilyLib and lalily. In a future post I will discuss how to actually use the lalily-templates and what templates are already available.

The lalily-templates come with quite a few wrapper functions that automate the score creation — in some cases conditionally. This lets you have a score for proof-reading that is only created when the file containing a score-creating command is not included. And the predefined templates already contain the edition-engraver, so you can include the music definition (\putMusic) and add tweaks to an edition (for example, to customize it for a special paper-format) without ever touching the music content.

by Jan-Peter Voigt at September 05, 2014 05:34 PM

September 04, 2014

Hackaday » » digital audio hacks

Levitating Speaker Plays Back Eerie Recordings

Levitating Speaker

Let’s face it, levitating anything is pretty fascinating — especially when you think there should be wires. This project puts a new spin on magnetic levitation by using a PID controller to levitate a speaker while it plays music!

It uses the standard levitation setup — an electromagnet, a permanent magnet, and a hall effect sensor. A microcontroller implements the PID system, varying the current supplied to the electromagnet to keep the speaker floating at just the right height. Music is wirelessly transmitted to the speaker via Bluetooth, but unfortunately the speaker’s power is not. It features a small lithium ion battery which has a run-time of around 5 hours before it has to be recharged manually.

As you’ll notice in the following video, having a floating speaker has a pretty interesting effect — especially when it starts spinning.

It is possible to also wirelessly transmit power, like this floating LED project we saw awhile ago — but either way, it’s pretty cool.


Filed under: digital audio hacks

by James Hobson at September 04, 2014 08:01 PM

September 01, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] linuxaudio mailing lists and gmail issues (bounces)

From: Marc-Olivier Barre <marco@...>
Subject: [LAA] linuxaudio mailing lists and gmail issues (bounces)
Date: Sep 1, 9:40 am 2014

Hi everyone,

Some of you might have noticed, we're having issues delivering mailing lists
posts to gmail users (it can be fairly random). I'm also having similar
issues at work and on my own server. It seems gmail has tightened their
filtering rules a bit and generate quite the amount of backscatter emails
which generally results in mailman accounts being disabled.

TL;DR
mailman issues, gmail sucks, I'm working on a fix :)

Cheers !
--
Marc-Olivier Barre
XMPP ID : marco@marcochapeau.org
www.MarcOChapeau.org
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

September 01, 2014 10:00 AM

August 31, 2014

Pid Eins

Revisiting How We Put Together Linux Systems

In a previous blog story I discussed Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems, I now want to take the opportunity to explain a bit where we want to take this with systemd in the longer run, and what we want to build out of it. This is going to be a longer story, so better grab a cold bottle of Club Mate before you start reading.

Traditional Linux distributions are built around packaging systems like RPM or dpkg, and an organization model where upstream developers and downstream packagers are relatively clearly separated: an upstream developer writes code, and puts it somewhere online, in a tarball. A packager than grabs it and turns it into RPMs/DEBs. The user then grabs these RPMs/DEBs and installs them locally on the system. For a variety of uses this is a fantastic scheme: users have a large selection of readily packaged software available, in mostly uniform packaging, from a single source they can trust. In this scheme the distribution vets all software it packages, and as long as the user trusts the distribution all should be good. The distribution takes the responsibility of ensuring the software is not malicious, of timely fixing security problems and helping the user if something is wrong.

Upstream Projects

However, this scheme also has a number of problems, and doesn't fit many use-cases of our software particularly well. Let's have a look at the problems of this scheme for many upstreams:

  • Upstream software vendors are fully dependent on downstream distributions to package their stuff. It's the downstream distribution that decides on schedules, packaging details, and how to handle support. Often upstream vendors want much faster release cycles then the downstream distributions follow.

  • Realistic testing is extremely unreliable and next to impossible. Since the end-user can run a variety of different package versions together, and expects the software he runs to just work on any combination, the test matrix explodes. If upstream tests its version on distribution X release Y, then there's no guarantee that that's the precise combination of packages that the end user will eventually run. In fact, it is very unlikely that the end user will, since most distributions probably updated a number of libraries the package relies on by the time the package ends up being made available to the user. The fact that each package can be individually updated by the user, and each user can combine library versions, plug-ins and executables relatively freely, results in a high risk of something going wrong.

  • Since there are so many different distributions in so many different versions around, if upstream tries to build and test software for them it needs to do so for a large number of distributions, which is a massive effort.

  • The distributions are actually quite different in many ways. In fact, they are different in a lot of the most basic functionality. For example, the path where to put x86-64 libraries is different on Fedora and Debian derived systems..

  • Developing software for a number of distributions and versions is hard: if you want to do it, you need to actually install them, each one of them, manually, and then build your software for each.

  • Since most downstream distributions have strict licensing and trademark requirements (and rightly so), any kind of closed source software (or otherwise non-free) does not fit into this scheme at all.

This all together makes it really hard for many upstreams to work nicely with the current way how Linux works. Often they try to improve the situation for them, for example by bundling libraries, to make their test and build matrices smaller.

System Vendors

The toolbox approach of classic Linux distributions is fantastic for people who want to put together their individual system, nicely adjusted to exactly what they need. However, this is not really how many of today's Linux systems are built, installed or updated. If you build any kind of embedded device, a server system, or even user systems, you frequently do your work based on complete system images, that are linearly versioned. You build these images somewhere, and then you replicate them atomically to a larger number of systems. On these systems, you don't install or remove packages, you get a defined set of files, and besides installing or updating the system there are no ways how to change the set of tools you get.

The current Linux distributions are not particularly good at providing for this major use-case of Linux. Their strict focus on individual packages as well as package managers as end-user install and update tool is incompatible with what many system vendors want.

Users

The classic Linux distribution scheme is frequently not what end users want, either. Many users are used to app markets like Android, Windows or iOS/Mac have. Markets are a platform that doesn't package, build or maintain software like distributions do, but simply allows users to quickly find and download the software they need, with the app vendor responsible for keeping the app updated, secured, and all that on the vendor's release cycle. Users tend to be impatient. They want their software quickly, and the fine distinction between trusting a single distribution or a myriad of app developers individually is usually not important for them. The companies behind the marketplaces usually try to improve this trust problem by providing sand-boxing technologies: as a replacement for the distribution that audits, vets, builds and packages the software and thus allows users to trust it to a certain level, these vendors try to find technical solutions to ensure that the software they offer for download can't be malicious.

Existing Approaches To Fix These Problems

Now, all the issues pointed out above are not new, and there are sometimes quite successful attempts to do something about it. Ubuntu Apps, Docker, Software Collections, ChromeOS, CoreOS all fix part of this problem set, usually with a strict focus on one facet of Linux systems. For example, Ubuntu Apps focus strictly on end user (desktop) applications, and don't care about how we built/update/install the OS itself, or containers. Docker OTOH focuses on containers only, and doesn't care about end-user apps. Software Collections tries to focus on the development environments. ChromeOS focuses on the OS itself, but only for end-user devices. CoreOS also focuses on the OS, but only for server systems.

The approaches they find are usually good at specific things, and use a variety of different technologies, on different layers. However, none of these projects tried to fix this problems in a generic way, for all uses, right in the core components of the OS itself.

Linux has come to tremendous successes because its kernel is so generic: you can build supercomputers and tiny embedded devices out of it. It's time we come up with a basic, reusable scheme how to solve the problem set described above, that is equally generic.

What We Want

The systemd cabal (Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen, David Herrmann, and yours truly) recently met in Berlin about all these things, and tried to come up with a scheme that is somewhat simple, but tries to solve the issues generically, for all use-cases, as part of the systemd project. All that in a way that is somewhat compatible with the current scheme of distributions, to allow a slow, gradual adoption. Also, and that's something one cannot stress enough: the toolbox scheme of classic Linux distributions is actually a good one, and for many cases the right one. However, we need to make sure we make distributions relevant again for all use-cases, not just those of highly individualized systems.

Anyway, so let's summarize what we are trying to do:

  • We want an efficient way that allows vendors to package their software (regardless if just an app, or the whole OS) directly for the end user, and know the precise combination of libraries and packages it will operate with.

  • We want to allow end users and administrators to install these packages on their systems, regardless which distribution they have installed on it.

  • We want a unified solution that ultimately can cover updates for full systems, OS containers, end user apps, programming ABIs, and more. These updates shall be double-buffered, (at least). This is an absolute necessity if we want to prepare the ground for operating systems that manage themselves, that can update safely without administrator involvement.

  • We want our images to be trustable (i.e. signed). In fact we want a fully trustable OS, with images that can be verified by a full trust chain from the firmware (EFI SecureBoot!), through the boot loader, through the kernel, and initrd. Cryptographically secure verification of the code we execute is relevant on the desktop (like ChromeOS does), but also for apps, for embedded devices and even on servers (in a post-Snowden world, in particular).

What We Propose

So much about the set of problems, and what we are trying to do. So, now, let's discuss the technical bits we came up with:

The scheme we propose is built around the variety of concepts of btrfs and Linux file system name-spacing. btrfs at this point already has a large number of features that fit neatly in our concept, and the maintainers are busy working on a couple of others we want to eventually make use of.

As first part of our proposal we make heavy use of btrfs sub-volumes and introduce a clear naming scheme for them. We name snapshots like this:

  • usr:<vendorid>:<architecture>:<version> -- This refers to a full vendor operating system tree. It's basically a /usr tree (and no other directories), in a specific version, with everything you need to boot it up inside it. The <vendorid> field is replaced by some vendor identifier, maybe a scheme like org.fedoraproject.FedoraWorkstation. The <architecture> field specifies a CPU architecture the OS is designed for, for example x86-64. The <version> field specifies a specific OS version, for example 23.4. An example sub-volume name could hence look like this: usr:org.fedoraproject.FedoraWorkstation:x86_64:23.4

  • root:<name>:<vendorid>:<architecture> -- This refers to an instance of an operating system. Its basically a root directory, containing primarily /etc and /var (but possibly more). Sub-volumes of this type do not contain a populated /usr tree though. The <name> field refers to some instance name (maybe the host name of the instance). The other fields are defined as above. An example sub-volume name is root:revolution:org.fedoraproject.FedoraWorkstation:x86_64.

  • runtime:<vendorid>:<architecture>:<version> -- This refers to a vendor runtime. A runtime here is supposed to be a set of libraries and other resources that are needed to run apps (for the concept of apps see below), all in a /usr tree. In this regard this is very similar to the usr sub-volumes explained above, however, while a usr sub-volume is a full OS and contains everything necessary to boot, a runtime is really only a set of libraries. You cannot boot it, but you can run apps with it. An example sub-volume name is: runtime:org.gnome.GNOME3_20:x86_64:3.20.1

  • framework:<vendorid>:<architecture>:<version> -- This is very similar to a vendor runtime, as described above, it contains just a /usr tree, but goes one step further: it additionally contains all development headers, compilers and build tools, that allow developing against a specific runtime. For each runtime there should be a framework. When you develop against a specific framework in a specific architecture, then the resulting app will be compatible with the runtime of the same vendor ID and architecture. Example: framework:org.gnome.GNOME3_20:x86_64:3.20.1

  • app:<vendorid>:<runtime>:<architecture>:<version> -- This encapsulates an application bundle. It contains a tree that at runtime is mounted to /opt/<vendorid>, and contains all the application's resources. The <vendorid> could be a string like org.libreoffice.LibreOffice, the <runtime> refers to one the vendor id of one specific runtime the application is built for, for example org.gnome.GNOME3_20:3.20.1. The <architecture> and <version> refer to the architecture the application is built for, and of course its version. Example: app:org.libreoffice.LibreOffice:GNOME3_20:x86_64:133

  • home:<user>:<uid>:<gid> -- This sub-volume shall refer to the home directory of the specific user. The <user> field contains the user name, the <uid> and <gid> fields the numeric Unix UIDs and GIDs of the user. The idea here is that in the long run the list of sub-volumes is sufficient as a user database (but see below). Example: home:lennart:1000:1000.

btrfs partitions that adhere to this naming scheme should be clearly identifiable. It is our intention to introduce a new GPT partition type ID for this.

How To Use It

After we introduced this naming scheme let's see what we can build of this:

  • When booting up a system we mount the root directory from one of the root sub-volumes, and then mount /usr from a matching usr sub-volume. Matching here means it carries the same <vendor-id> and <architecture>. Of course, by default we should pick the matching usr sub-volume with the newest version by default.

  • When we boot up an OS container, we do exactly the same as the when we boot up a regular system: we simply combine a usr sub-volume with a root sub-volume.

  • When we enumerate the system's users we simply go through the list of home snapshots.

  • When a user authenticates and logs in we mount his home directory from his snapshot.

  • When an app is run, we set up a new file system name-space, mount the app sub-volume to /opt/<vendorid>/, and the appropriate runtime sub-volume the app picked to /usr, as well as the user's /home/$USER to its place.

  • When a developer wants to develop against a specific runtime he installs the right framework, and then temporarily transitions into a name space where /usris mounted from the framework sub-volume, and /home/$USER from his own home directory. In this name space he then runs his build commands. He can build in multiple name spaces at the same time, if he intends to builds software for multiple runtimes or architectures at the same time.

Instantiating a new system or OS container (which is exactly the same in this scheme) just consists of creating a new appropriately named root sub-volume. Completely naturally you can share one vendor OS copy in one specific version with a multitude of container instances.

Everything is double-buffered (or actually, n-fold-buffered), because usr, runtime, framework, app sub-volumes can exist in multiple versions. Of course, by default the execution logic should always pick the newest release of each sub-volume, but it is up to the user keep multiple versions around, and possibly execute older versions, if he desires to do so. In fact, like on ChromeOS this could even be handled automatically: if a system fails to boot with a newer snapshot, the boot loader can automatically revert back to an older version of the OS.

An Example

Note that in result this allows installing not only multiple end-user applications into the same btrfs volume, but also multiple operating systems, multiple system instances, multiple runtimes, multiple frameworks. Or to spell this out in an example:

Let's say Fedora, Mageia and ArchLinux all implement this scheme, and provide ready-made end-user images. Also, the GNOME, KDE, SDL projects all define a runtime+framework to develop against. Finally, both LibreOffice and Firefox provide their stuff according to this scheme. You can now trivially install of these into the same btrfs volume:

  • usr:org.fedoraproject.WorkStation:x86_64:24.7
  • usr:org.fedoraproject.WorkStation:x86_64:24.8
  • usr:org.fedoraproject.WorkStation:x86_64:24.9
  • usr:org.fedoraproject.WorkStation:x86_64:25beta
  • usr:org.mageia.Client:i386:39.3
  • usr:org.mageia.Client:i386:39.4
  • usr:org.mageia.Client:i386:39.6
  • usr:org.archlinux.Desktop:x86_64:302.7.8
  • usr:org.archlinux.Desktop:x86_64:302.7.9
  • usr:org.archlinux.Desktop:x86_64:302.7.10
  • root:revolution:org.fedoraproject.WorkStation:x86_64
  • root:testmachine:org.fedoraproject.WorkStation:x86_64
  • root:foo:org.mageia.Client:i386
  • root:bar:org.archlinux.Desktop:x86_64
  • runtime:org.gnome.GNOME3_20:x86_64:3.20.1
  • runtime:org.gnome.GNOME3_20:x86_64:3.20.4
  • runtime:org.gnome.GNOME3_20:x86_64:3.20.5
  • runtime:org.gnome.GNOME3_22:x86_64:3.22.0
  • runtime:org.kde.KDE5_6:x86_64:5.6.0
  • framework:org.gnome.GNOME3_22:x86_64:3.22.0
  • framework:org.kde.KDE5_6:x86_64:5.6.0
  • app:org.libreoffice.LibreOffice:GNOME3_20:x86_64:133
  • app:org.libreoffice.LibreOffice:GNOME3_22:x86_64:166
  • app:org.mozilla.Firefox:GNOME3_20:x86_64:39
  • app:org.mozilla.Firefox:GNOME3_20:x86_64:40
  • home:lennart:1000:1000
  • home:hrundivbakshi:1001:1001

In the example above, we have three vendor operating systems installed. All of them in three versions, and one even in a beta version. We have four system instances around. Two of them of Fedora, maybe one of them we usually boot from, the other we run for very specific purposes in an OS container. We also have the runtimes for two GNOME releases in multiple versions, plus one for KDE. Then, we have the development trees for one version of KDE and GNOME around, as well as two apps, that make use of two releases of the GNOME runtime. Finally, we have the home directories of two users.

Now, with the name-spacing concepts we introduced above, we can actually relatively freely mix and match apps and OSes, or develop against specific frameworks in specific versions on any operating system. It doesn't matter if you booted your ArchLinux instance, or your Fedora one, you can execute both LibreOffice and Firefox just fine, because at execution time they get matched up with the right runtime, and all of them are available from all the operating systems you installed. You get the precise runtime that the upstream vendor of Firefox/LibreOffice did their testing with. It doesn't matter anymore which distribution you run, and which distribution the vendor prefers.

Also, given that the user database is actually encoded in the sub-volume list, it doesn't matter which system you boot, the distribution should be able to find your local users automatically, without any configuration in /etc/passwd.

Building Blocks

With this naming scheme plus the way how we can combine them on execution we already came quite far, but how do we actually get these sub-volumes onto the final machines, and how do we update them? Well, btrfs has a feature they call "send-and-receive". It basically allows you to "diff" two file system versions, and generate a binary delta. You can generate these deltas on a developer's machine and then push them into the user's system, and he'll get the exact same sub-volume too. This is how we envision installation and updating of operating systems, applications, runtimes, frameworks. At installation time, we simply deserialize an initial send-and-receive delta into our btrfs volume, and later, when a new version is released we just add in the few bits that are new, by dropping in another send-and-receive delta under a new sub-volume name. And we do it exactly the same for the OS itself, for a runtime, a framework or an app. There's no technical distinction anymore. The underlying operation for installing apps, runtime, frameworks, vendor OSes, as well as the operation for updating them is done the exact same way for all.

Of course, keeping multiple full /usr trees around sounds like an awful lot of waste, after all they will contain a lot of very similar data, since a lot of resources are shared between distributions, frameworks and runtimes. However, thankfully btrfs actually is able to de-duplicate this for us. If we add in a new app snapshot, this simply adds in the new files that changed. Moreover different runtimes and operating systems might actually end up sharing the same tree.

Even though the example above focuses primarily on the end-user, desktop side of things, the concept is also extremely powerful in server scenarios. For example, it is easy to build your own usr trees and deliver them to your hosts using this scheme. The usr sub-volumes are supposed to be something that administrators can put together. After deserializing them into a couple of hosts, you can trivially instantiate them as OS containers there, simply by adding a new root sub-volume for each instance, referencing the usr tree you just put together. Instantiating OS containers hence becomes as easy as creating a new btrfs sub-volume. And you can still update the images nicely, get fully double-buffered updates and everything.

And of course, this scheme also applies great to embedded use-cases. Regardless if you build a TV, an IVI system or a phone: you can put together you OS versions as usr trees, and then use btrfs-send-and-receive facilities to deliver them to the systems, and update them there.

Many people when they hear the word "btrfs" instantly reply with "is it ready yet?". Thankfully, most of the functionality we really need here is strictly read-only. With the exception of the home sub-volumes (see below) all snapshots are strictly read-only, and are delivered as immutable vendor trees onto the devices. They never are changed. Even if btrfs might still be immature, for this kind of read-only logic it should be more than good enough.

Note that this scheme also enables doing fat systems: for example, an installer image could include a Fedora version compiled for x86-64, one for i386, one for ARM, all in the same btrfs volume. Due to btrfs' de-duplication they will share as much as possible, and when the image is booted up the right sub-volume is automatically picked. Something similar of course applies to the apps too!

This also allows us to implement something that we like to call Operating-System-As-A-Virus. Installing a new system is little more than:

  • Creating a new GPT partition table
  • Adding an EFI System Partition (FAT) to it
  • Adding a new btrfs volume to it
  • Deserializing a single usr sub-volume into the btrfs volume
  • Installing a boot loader into the EFI System Partition
  • Rebooting

Now, since the only real vendor data you need is the usr sub-volume, you can trivially duplicate this onto any block device you want. Let's say you are a happy Fedora user, and you want to provide a friend with his own installation of this awesome system, all on a USB stick. All you have to do for this is do the steps above, using your installed usr tree as source to copy. And there you go! And you don't have to be afraid that any of your personal data is copied too, as the usr sub-volume is the exact version your vendor provided you with. Or with other words: there's no distinction anymore between installer images and installed systems. It's all the same. Installation becomes replication, not more. Live-CDs and installed systems can be fully identical.

Note that in this design apps are actually developed against a single, very specific runtime, that contains all libraries it can link against (including a specific glibc version!). Any library that is not included in the runtime the developer picked must be included in the app itself. This is similar how apps on Android declare one very specific Android version they are developed against. This greatly simplifies application installation, as there's no dependency hell: each app pulls in one runtime, and the app is actually free to pick which one, as you can have multiple installed, though only one is used by each app.

Also note that operating systems built this way will never see "half-updated" systems, as it is common when a system is updated using RPM/dpkg. When updating the system the code will either run the old or the new version, but it will never see part of the old files and part of the new files. This is the same for apps, runtimes, and frameworks, too.

Where We Are Now

We are currently working on a lot of the groundwork necessary for this. This scheme relies on the ability to monopolize the vendor OS resources in /usr, which is the key of what I described in Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems a few weeks back. Then, of course, for the full desktop app concept we need a strong sandbox, that does more than just hiding files from the file system view. After all with an app concept like the above the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features), and the kernel itself. Harald Hoyer has started working on generating the btrfs send-and-receive images based on Fedora.

Getting to the full scheme will take a while. Currently we have many of the building blocks ready, but some major items are missing. For example, we push quite a few problems into btrfs, that other solutions try to solve in user space. One of them is actually signing/verification of images. The btrfs maintainers are working on adding this to the code base, but currently nothing exists. This functionality is essential though to come to a fully verified system where a trust chain exists all the way from the firmware to the apps. Also, to make the home sub-volume scheme fully workable we actually need encrypted sub-volumes, so that the sub-volume's pass-phrase can be used for authenticating users in PAM. This doesn't exist either.

Working towards this scheme is a gradual process. Many of the steps we require for this are useful outside of the grand scheme though, which means we can slowly work towards the goal, and our users can already take benefit of what we are working on as we go.

Also, and most importantly, this is not really a departure from traditional operating systems:

Each app, each OS and each app sees a traditional Unix hierarchy with /usr, /home, /opt, /var, /etc. It executes in an environment that is pretty much identical to how it would be run on traditional systems.

There's no need to fully move to a system that uses only btrfs and follows strictly this sub-volume scheme. For example, we intend to provide implicit support for systems that are installed on ext4 or xfs, or that are put together with traditional packaging tools such as RPM or dpkg: if the the user tries to install a runtime/app/framework/os image on a system that doesn't use btrfs so far, it can just create a loop-back btrfs image in /var, and push the data into that. Even us developers will run our stuff like this for a while, after all this new scheme is not particularly useful for highly individualized systems, and we developers usually tend to run systems like that.

Also note that this in no way a departure from packaging systems like RPM or DEB. Even if the new scheme we propose is used for installing and updating a specific system, it is RPM/DEB that is used to put together the vendor OS tree initially. Hence, even in this scheme RPM/DEB are highly relevant, though not strictly as an end-user tool anymore, but as a build tool.

So Let's Summarize Again What We Propose

  • We want a unified scheme, how we can install and update OS images, user apps, runtimes and frameworks.

  • We want a unified scheme how you can relatively freely mix OS images, apps, runtimes and frameworks on the same system.

  • We want a fully trusted system, where cryptographic verification of all executed code can be done, all the way to the firmware, as standard feature of the system.

  • We want to allow app vendors to write their programs against very specific frameworks, under the knowledge that they will end up being executed with the exact same set of libraries chosen.

  • We want to allow parallel installation of multiple OSes and versions of them, multiple runtimes in multiple versions, as well as multiple frameworks in multiple versions. And of course, multiple apps in multiple versions.

  • We want everything double buffered (or actually n-fold buffered), to ensure we can reliably update/rollback versions, in particular to safely do automatic updates.

  • We want a system where updating a runtime, OS, framework, or OS container is as simple as adding in a new snapshot and restarting the runtime/OS/framework/OS container.

  • We want a system where we can easily instantiate a number of OS instances from a single vendor tree, with zero difference for doing this on order to be able to boot it on bare metal/VM or as a container.

  • We want to enable Linux to have an open scheme that people can use to build app markets and similar schemes, not restricted to a specific vendor.

Final Words

I'll be talking about this at LinuxCon Europe in October. I originally intended to discuss this at the Linux Plumbers Conference (which I assumed was the right forum for this kind of major plumbing level improvement), and at linux.conf.au, but there was no interest in my session submissions there...

Of course this is all work in progress. These are our current ideas we are working towards. As we progress we will likely change a number of things. For example, the precise naming of the sub-volumes might look very different in the end.

Of course, we are developers of the systemd project. Implementing this scheme is not just a job for the systemd developers. This is a reinvention how distributions work, and hence needs great support from the distributions. We really hope we can trigger some interest by publishing this proposal now, to get the distributions on board. This after all is explicitly not supposed to be a solution for one specific project and one specific vendor product, we care about making this open, and solving it for the generic case, without cutting corners.

If you have any questions about this, you know how you can reach us (IRC, mail, G+, ...).

The future is going to be awesome!

by Lennart Poettering at August 31, 2014 10:00 PM

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

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