planet.linuxaudio.org

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 increases the effort of the reader. It could be noted that Gould in Behind Bars recommends indicating ratios in full when using the nearest 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

[LAA] Constant-Q library and Vamp plugin

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

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

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

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

This library provides:

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

The Vamp plugin provides:

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

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

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

read more

August 13, 2014 01:00 PM

[LAA] LV2 1.10.0 and friends

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

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

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

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

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

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

Related release announcements:

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

The RDF stack has also seen some updates:

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

Enjoy,

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

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

--
dr

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

read more

August 13, 2014 01:00 PM

[LAA] Hydrogen 0.9.6 released

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

Hi everyone,

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

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


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

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

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

Best regards,
Sebastian


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

read more

August 13, 2014 01:00 PM

[LAA] amsynth 1.5.0

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

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

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

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

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

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

Nick

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

read more

August 13, 2014 01:00 PM

August 12, 2014

Libre Music Production - Articles, Tutorials and News

Content Wish List

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

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

by Conor at August 12, 2014 04:47 PM

August 11, 2014

Libre Music Production - Articles, Tutorials and News

Recording audio and using MIDI in Ardour 3

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

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

This video uses the following gear and software:

by Gabbe at August 11, 2014 06:06 PM

Nothing Special

Drawing a GUI in Inkscape

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

And I arrange them like so:


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

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

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

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

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

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

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


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

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

Create Digital Music » open-source

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

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

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

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

3d_printing_hero-angle-view

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

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

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

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

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

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

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

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

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

Bhoreal

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

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

Mini OONTZ: 3D Printed MIDI Controller

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

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

August 08, 2014

drobilla.net » LAD

Jalv 1.4.6

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

Changes:

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

flattr this!

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

Ganv 1.4.2

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

Changes:

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

flattr this!

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

Lilv 0.20.0

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

Changes:

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

flattr this!

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

Suil 0.8.2

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

Changes:

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

flattr this!

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

Sratom 0.4.6

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

Changes:

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

flattr this!

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

Ubuntu Studio » News

Ubuntu Studio 12.04.5 Point Release

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

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

August 06, 2014

blog4

RIP Marilyn Burns

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


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

Here Englund recalls his meeting with Jones 

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


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

August 04, 2014

Create Digital Music » Linux

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

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

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

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

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

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

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

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

Details:

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

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

The AFX:

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

Touch control – look familiar?

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

The AMX:

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

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

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

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

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

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

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

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

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

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

    August 01, 2014

    Create Digital Music » open-source

    Midular are the Free MIDI Modules Every Ableton Live Setup Needs

    midularpitcher

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

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

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

    The starting lineup:

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

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

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

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

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

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

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

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

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

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

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

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

    July 30, 2014

    Create Digital Music » Linux

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

    1248-iso-right

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

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

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

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

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

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

    Interfacing Features

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

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

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

    1248 I/O.

    1248 I/O.

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

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

    16A. A is for ... analog.

    16A. A is for … analog.

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

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

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

    Networked Audio

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

    Say what?

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

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

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

    plus reference implementations by xcore

    Browser Mixer UI

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

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

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

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

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

    Hackaday » » digital audio hacks

    Adding Bluetooth And A Lightning Connector To Beats Pro Headphones

    Beats

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

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

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

    Thanks [Tony] for the tip!


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

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

    July 28, 2014

    Create Digital Music » open-source

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

    malloc

    What’s the sound of a computer program running?

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

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

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

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

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

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

    So good.

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

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

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

    Thank you, Myles Ashley Borins.

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

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

    July 25, 2014

    Ubuntu Studio » News

    Ubuntu Studio 14.04.1 Released

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

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

    July 23, 2014

    GStreamer News

    GStreamer OpenMAX IL wrapper plugin 1.2.0 release

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

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

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

    July 23, 2014 12:00 PM

    July 20, 2014

    linux.autostatic.com » linux.autostatic.com

    Wolfson Audio Card for Raspberry Pi

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


    Wolfson Audio Card for Raspberry Pi

    by Jeremy at July 20, 2014 07:28 PM

    July 19, 2014

    GStreamer News

    GStreamer Core, Plugins and RTSP server 1.4.0 stable release

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

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

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

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

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

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

    July 19, 2014 05:00 PM

    July 17, 2014

    Create Digital Music » Linux

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

    LCX_3quarter

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

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

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

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

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

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

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

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

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

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

    LCXL_withlaunchpad

    LCXL

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

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

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

    July 16, 2014

    Create Digital Music » Linux

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

    Can I get an Amen break?

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

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

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

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

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

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

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

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

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

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

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

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

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