planet.linuxaudio.org

August 01, 2015

Libre Music Production - Articles, Tutorials and News

Guitarix 0.33.0 released

The Guitarix developers have just announced a new release, version 0.33.0. This release sees a number of new plugins added to the virtual guitar amp simulator. These include -

A new Wah plugin with manual/auto/alien mode and the following emulated wah wah's to select from -

  • Colorsound Wah
  • DallasArbiter Wah
  • Foxx Wah
  • JEN Wah
  • Maestro Boomer Wah
  • Selmer Wah
  • Vox Wah

by Conor at August 01, 2015 09:47 AM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Guitarix 0.33.0 release

Release 0.33.0 is out,

Guitarix is a tube amplifier simulation for
jack (Linux), with an additional mono and a stereo effect rack.
Guitarix includes a large list of plugins[*] and support LADSPA / LV2
plugs as well.

The guitarix engine is designed for LIVE usage, and feature ultra fast,
glitch and click free, preset switching and is full Midi (learn)
and remote (Web-interface/ GUI) controllable (bluez / avahi)

Changelog:

This release comes with the old User Interface and reflect only changes
in the plugin section.

New Plugins in guitarix

A new Wah plugin with manual/auto/alien mode and the following emulated
wah wah's to select from:

Colorsond Wah
DallasArbiter Wah
Foxx Wah
JEN Wah
Maestro Boomer Wah
Selmer Wah
Vox Wah

A new Fuzz section with emulations of the:

Astrotone Fuzz
Dunlop Fuzzface
Fuzzface Roger Mayer Mods
Fuzzface Fuller Mods
Foxeylady
Hornet
Sustainer
Muff
Screaming Bird
Colorsound Tonebender
Vintage Fuzzmaster
Ruiner
Fat Furry Freak
Fuzz Drive

and emulations of:

LPB-1 Linear power Booster
High Frequency Brightener
Hogs Foot
Dallas Rangemaster
Buffer Booster
Transistor Buffer
Colorsound Overdrive


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

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

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

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

by web.de at August 01, 2015 06:29 AM

July 31, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] rkr lv2 Beta 0 released

HI all!

Would you like 40 more effect plugins?

After many months of persistence I have ported the Rakarrack effects to lv2
format. With each effect, the individual effect presets have been ported as
well. I am very excited about this project and hope that this can keep the
Rakarrack project as one of the highlights of linux audio. Rakarrack is
currently in need of a proper maintainer. So if you are interested please
contact the developers! I made these ports such that all changes could be
ported back into the main codebase.

The porting took a lot of manual entry of matching parameter bounds and
indices etc.. So as you test and use these, please report any strange
behaviour you notice (such as changing the "gain" parameter actually
changed the decay time, etc.). I will be trying to test these but it will
take me quite some time to give them all a good shake down.Current status
is that they all can be loaded by Carla and Jalv, with some audio testing
on a few by me, and some testing by other parties. No known issues
currently exist.

I am currently working on porting the preset banks to Carla rack presets.
This will allow us to load any of the presets from Rakarrack and insert it
as a single plugin in Ardour or other hosts. I would like to get the
community started testing these in parallel with my effort. Once I have
that done I will announce a second beta.

Not all of the effects were ported, since some were duplicate code, direct
copies of ladspa plugins, or redundant of other lv2 plugins (like the
looper or colvolotron). The interface was kept close to Rakarrack, but some
parameter changes were made for the intent of clarity, such as wet/dry -
instead of the original -64 is all wet, 0 a 50/50 wet/dry mix, 63 dry, now
0 means all wet, 127 all dry. Parameter names were altered in places as
well (e.g. St. Df. now is labeled "Left/Right LFO delay"). Case by case
feedback on these decisions is also welcome.

For those unfamiliar with Rakarrack, here are all the effects, marked to
show which are in this new plugin bundle:

EFFECTS (X - done, W - won't do, + - done with missing features)
[X] Lineal EQ
[X] Compressor
[X] Distortion
[W] Overdrive - exact same engine as distortion, but has fewer controls,
presets were added to dist.
[X] Echo
[X] Chorus
[W] Phaser - I'm not planning to do this. I'm only interested in the analog
phaser version
[X] Analog Phaser
[W] Flanger - this is identical to the chorus, presets from this will be
included there
[X] Reverb
[X] Parametric EQ
[X] Cabinet Emulation
[X] AutoPan/Stereo Expander
[+] Harmonizer - midi mode was not ported
[X] Musical Delay
[W] Noise Gate - Direct copy of Steve Harris's Gate ladspa plugin
[X] WahWah
[X] AlienWah
[X] Derelict
[X] Valve
[X] Dual Flange
[X] Ring
[X] Exciter
[X] DistBand
[X] Arpie
[X] Expander
[X] Shuffle
[X] Synthfilter
[X] VaryBand
[W] Convolotron - other excellent lv2 convolution engines already exist
[W] Looper - other good lv2 loopers exist
[X] MuTroMojo
[X] Echoverse
[X] CoilCrafter
[X] ShelfBoost
[X] Vocoder
[X] Sustainer
[X] Sequence
[X] Shifter
[X] StompBox - an extra plugin for fuzz mode was added, as interface is
different
[X] Reverbtron
[X] Echotron
[+] StereoHarm - no midi mode
[X] CompBand
[X] Opticaltrem
[X] Vibe
[X] Infinity

Further help using them can be found at
http://rakarrack.sourceforge.net/effects.html . I hope you all find these
enjoyable, and make great music with them.

Please download and try them at:

http://github.com/ssj71/rkrlv2

Enjoy!

_Spencer

by gmail.com at July 31, 2015 08:40 PM

July 29, 2015

Create Digital Music » open-source

Drum machines in your browser, and more places to find Web Audio and MIDI

screenshot_62

Open a new tab, and suddenly you have a powerful, sequenced drum synth making grooves. Give it a shot:
https://irritantcreative.ca/projects/x0x
Or read more. (This latest creation came out in June.)

This is either the future of collaborative music making or the Single Greatest Way To Make Music While Pretending To Do Other Work I’ve ever seen.

But, as a new effort works on sharing music scores in the browser, it’s worth checking up on the Web Audio API – the stuff that makes interactive sound possible – and connections to hardware via MIDI.

And there’s a lot going on, the sort of fertile conversation that could lead to new things.

Web Audio and Web MIDI are quite fresh, so developers around the world are getting together to learn from one another and discuss what’s possible. That includes the USA, UK, and Germany:

London: http://www.meetup.com/Web-Audio-London/
New York: http://www.meetup.com/New-York-Web-Audio-Meetup/
Berlin: http://www.meetup.com/berlin-web-audio-meetup/
Philly: http://www.meetup.com/Philly-Web-Audio-Meetup/

Paris was also host to an annual, international conference, which took place this year at famed research center IRCAM.

Online synths and other proofs of concept are likely just the beginning. Web music development began as a sometimes muddled conversation about whether browsers will replace traditional app deployment (so far, probably not). But as the tech has matured, developers are instead looking to ways to use the Web to create new kinds of apps that perhaps didn’t make sense as standalone tools in “native” software (or, for that matter, hardware).

That’s why it’ll be interesting to watch efforts like Yamaha’s to add browser-based patch editing and sharing for their Reface line. There are also more ambitious ideas, like using the browser to share audio for interviews, radio conversations, backup, and works-anywhere recording and streaming.

And there’s more.

Keith McMillen has a great two-article series introducing you to Web MIDI.

It explains what this is all about and what it can do – whether or not you are a developer, worth reading. And if you are a developer, code snippets!

There’s even some explanation of how to use MIDI code outside of Chrome. (Firefox and even Microsoft’s new Edge promise support soon.)

Making Music in the Browser – Web MIDI API

Making Music in the Browser – Web Audio API, Part 1

And their blog in general is full of surprisingly geeky wonderful stuff, not the normal marketing stuff. (In fact, let’s be fair, you’d fire your marketing manager if they did this. But… kudos.)

http://www.keithmcmillen.com/blog/

When we first started using the Web, it seemed like a clumsy way to duplicate things done better elsewhere. Now, it promises to be something different: a place that takes the software and hardware we love, and makes it more useful and connected. There’s something wonderful about switching the Internet off in the studio and focusing on making music for a while. But in this model, when you do turn the Internet on again, it becomes a place to focus more on music rather than be distracted.

The post Drum machines in your browser, and more places to find Web Audio and MIDI appeared first on Create Digital Music.

by Peter Kirn at July 29, 2015 11:24 AM

July 28, 2015

Pid Eins

Announcing systemd.conf 2015

Announcing systemd.conf 2015

We are happy to announce the inaugural systemd.conf 2015 conference of the systemd project.

The conference takes place November 5th-7th, 2015 in Berlin, Germany.

Only a limited number of tickets are available, hence make sure to sign up quickly.

For further details consult the conference website.

by Lennart Poettering at July 28, 2015 10:00 PM

linux.autostatic.com » linux.autostatic.com

Raspberry Pi Revisited

When the Raspberry Pi 2 was released I certainly got curious. Would it be really better than it's little brother? As soon as it got available in The Netherlands I bought it and sure this thing flies compared to the Raspberry Pi 1. The four cores and 1GB of memory are certainly an improvement. The biggest improvement though is the shift from ARMv6 to ARMv7. Now you can really run basically anything on it and thus I soon parted from Raspbian and I'm now running plain Debian Jessie armhf on the RPi.

So is everything fine and dandy with the RPi2? Well, no. It still uses the poor USB implementation and audio output. And it was quite a challenge to prepare it for its intended use: a musical instrument. To my great surprise a new version of the Wolfson Audio Card was available too for the new Raspberry Pi board layout so as soon as people reported they got it to work with the RPi2 I ordered one too.

Cirrus Logic Audio Card for Raspberry Pi

One of the first steps to make the device suitable for use as a musical device was to build a real-time kernel for it. Building the kernel itself was quite easy as the RT patchset of the kernel being used at the moment by the Raspberry Foundation (3.18) applied cleanly and it also booted without issues. But after a few minutes the RPi2 would lock up without logging anything. Fortunately there were people on the same boat as me and with the help of the info and patches provided by the Emlid community I managed to get my RPi2 stable with a RT kernel.

Next step was to get the right software running so I dusted off my RPi repositories and added a Jessie armhf repo. With the help of fundamental the latest version of ZynAddSubFX now runs like charm with very acceptable latencies, when using not all too elaborate instrument patches Zyn is happy with an internal latency of 64/48000=1.3ms. I haven't measured the total round-trip latency but it probably stays well below 10ms. LinuxSampler with the Salamander Grand Piano sample pack also performs a lot better than on the RPi1 and when using ALSA directly I barely get any underruns with a slightly higher buffer setting.

I'd love to get Guitarix running on the RPi2 with the Cirrus Logic Audio Card so that will be the next challenge.

by Jeremy at July 28, 2015 11:59 AM

Libre Music Production - Articles, Tutorials and News

KXStudio Website has moved

KXStudio has been the latest in a line of open source projects to move away from sourceforge. You will now find the KXStudio project hosted on the linuxaudio.org servers. The new website can now be found at http://kxstudio.linuxaudio.org/

For full details about the move, see the announcement here.

by Conor at July 28, 2015 11:26 AM

July 27, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Qtractor 0.7.0 - The Muon Base is out!

Ahoy!

Stepping up to Summer'15 release frenzy stage scene, in it's fourth and
hopefully last act,

Qtractor 0.7.0 (muon base beta) is out!

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

As a major highlight to this release, there's the advent of regular MIDI
controllers mapping/assignment to main application menu command actions,
just like normal PC-keyboard shortcuts, is being introduced (cf. main
menu Help/Shortcuts...).

Have a 'hotta' Summer'15 ;)

Enjoy.


Website:
http://qtractor.sourceforge.net

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

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

- source tarball:
http://www.rncbc.org/archive/qtractor-0.7.0.tar.gz

- source package (openSUSE 13.2):
http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.src.rpm

- binary packages (openSUSE 13.2):
http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.i586.rpm
http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.x86_84.rpm

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

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

License:
Qtractor [1] is free, open-source Linux Audio [6] software,
distributed under the terms of the GNU General Public License (GPL [5])
version 2 or later.

Change-log:
- Complete rewrite of Qt4 vs. Qt5 configure builds.
- Revised MIDI Controlllers catch-up algorithm.
- Mixer multi-row layout gets a little bit of a fairness fix.
- Non-continuous MIDI Controllers now have their Hook and Latch options
disabled as those are found not applicable,
- As an alternative to PC-keyboard shortcuts, MIDI controllers are now
also assignable and configurable for any of the main menu command
actions, all from the same old configuration dialog (Help/Shortcuts...).
- Fixed missing Track and Clip sub-menus from Edit/context-menu that
were found AWOL ever since after the Lazy Tachyon beta release (> 0.6.6).
- An off-by-one bar position (as in BBT, bar, beat and ticks) has been
purportedly fixed as long as LV2 Time/Position atom event transfer goes.
- French (fr) translation line to desktop file added (patch by Olivier
Humbert, thanks).
- A new top-level widget window geometry state save and restore
sub-routine is now in effect.
- Improved MIDI clip editor resilience across tempo and time-signature
changes.
- Keyboard shortcuts configuration (Help/Shortcuts...) now lists
complete menu/action path where available.
- Fixed in-flight VST plugin editor (GUI) resizing.
- Added support to LV2UI_portMap extension, found really handy for the
cases where you have multiple plugins with different port configurations
and a single common UI to drive them all (pull request by Hanspeter
Portner aka. ventosus, thanks).

References:

[1] Qtractor - An audio/MIDI multi-track sequencer
http://qtractor.sourceforge.net

[2] Qt framework, C++ class library and tools for
cross-platform application and UI development
http://qt.io/

[3] JACK Audio Connection Kit
http://jackaudio.org

[4] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/

[5] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html

[6] http://linuxaudio.org


See also:
http://www.rncbc.org/drupal/node/917


Enjoy && keep the fun.
--
rncbc aka. Rui Nuno Capela
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

by rncbc.org at July 27, 2015 01:41 PM

Hackaday » digital audio hacks

Make a Microphone Out of a Hard Drive

[Rulof Maker] has a penchant for making nifty projects out of old electronics. The one that has caught our eye is  a microphone made from parts of an old hard drive. The drive’s arm and magnet were set aside while  the aluminum base was diagonally cut into two pieces.  One piece was later used to reassemble the hard drive’s magnet and arm onto a wooden platform.

v2_micThe drive’s arm and voice coil actuator are the key parts of this project. It was modified with a metal extension so that a paper cone cut from an audio speaker could be attached, an idea used in microphone projects we’ve previously featured. Copper wire scavenged from the speaker was then soldered to voice coil on the arm as well as an audio jack. In the first version of the Hard Drive Microphone, the arm is held upright with a pair of springs and vibrates when the cone catches sound.

While the microphone worked, [Rulof] saw room for improvement. In the second version, he replaced the mechanical springs with magnets to keep the arm aloft. One pair was glued to the sides of the base, while another pair recovered from an old optical drive was affixed to the arm. He fabricated a larger paper cone and added a pop filter made out of pantyhose for good measure. The higher sound quality is definitely noticeable. If you are interested in more of [Rulof’s] projects, check out his YouTube channel.

First Version:

Second Version:


Filed under: digital audio hacks, musical hacks

by Theodora Fabio at July 27, 2015 11:01 AM

July 25, 2015

KXStudio News

KXStudio Website has moved

Hey all,

As you might have noticed sourceforge has been out of service for a while now.
That, coupled together with the previous adware/spyware fiasco led to me look for alternatives.

So you can now find the KXStudio website at http://kxstudio.linuxaudio.org/.

The KXStudio repositories have already been updated to NOT use sourceforge anymore.
New releases will be hosted at github, possibly mirrored in google drive and linuxaudio.org.
I've made some changes to make the website and repositories more easy to move in case something like this happens to github too.

Sorry for any inconvenience.

by falkTX at July 25, 2015 09:23 PM

Introducing JackAss

JackAss is a VST plugin that provides JACK-MIDI support for VST hosts.
Simply load the plugin in your favourite host to get a JACK-MIDI port.
Each new plugin instance creates a new MIDI port.

Here's JackAss loaded in FL Studio:




And an example setup in Carla for it:



JackAss sends the notes from the host to its JACK-MIDI port.
It also exposes 50 parameters, which send a MIDI CC message when changed.
You can use this to easily control external applications that accept JACK-MIDI input and possibly CC for automation (like Carla).

Additionally there's a JackAssFX plugin, which only exposes parameters to send as MIDI CC, in case you don't need MIDI/notes.

JackAss currently has builds for Linux, MacOS and Windows, all 32bit and 64bit. Just follow this link.
As a bonus, you also get special Wine builds - load it in a Windows application running in Linux via Wine and you get a real, native JACK-MIDI port from it!

You can find JackAss source code and bug tracker in Github: https://github.com/falkTX/JackAss/.

PS: Why JackAss? Because it outputs to JACK. ;)

by falkTX at July 25, 2015 09:07 PM

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 July 25, 2015 09:07 PM

Carla 2.0 beta3 is here!

Hello again everyone, we're glad to bring to you the 3rd beta of the upcoming Carla 2.0 release.
There have been quite a few nice features implemented since beta2; here are the highlights.

Highlights

internal-patchbay

Internal Patchbay

This new engine processing mode is similar to what JACK does for all clients and what other modular applications do.
Every plugin gets its own canvas group and ports allowing you to interconnect plugin audio and MIDI.
You can use this mode to build complex plugin routing scenarios, perhaps involving several layers of rack and patchbays.

Note that this is currently not available for non-JACK drivers; but for those you can use the internal carla-patchbay plugin.
There's no support for LV2 Control-Voltage ports as of yet, this will be implemented in the next beta together with MIDI-OSC.


new-look

Carla as VST plugin (Linux only)

With the first beta of Carla 2.0 we introduced Carla as a plugin, which worked as both internal and LV2.
Now Carla is available as a VST plugin too, allowing you to load it all DAWs released for Linux.
There are 4 variants: Rack-Synth, Rack-FX, Patchbay-Synth and Patchbay-FX.


lmms-plugin

Carla LMMS Plugin

Carla has an LMMS plugin too, as Carla-Patchbay and Carla-Rack instruments.
So finally you can use native softsynths within LMMS!
The carla-lmms plugin code is already in LMMS and will be part of its 1.1 release.

If you're using the KXStudio repositories and feel like giving it a try simply install carla-git and lmms.


au-plugins

AU Plugins (MacOS only)

AU plugins are working in Carla now.
Carla's plugin compatibility increases once more.


updated-skins

New and updated skins

There's a new OpenAV-style plugin slot skin.
Calf and ZynFX have been updated.
More to come soon.


no-skins

Old non-skin mode

You can now use the old non-skin mode from Carla 1.x series.
This saves space if you load lots of plugins at once.


More stuff

  • New time panel added, but it's very incomplete.
  • LV2 plugin discovery is now automatic, but without plugin checks or testing.
  • LV2 plugins are fully working on MacOS and Windows, including their native UIs (Cocoa and HWND respectively).

There will still be 1 or 2 more beta releases before going for a release candidate, so expect more cool stuff soon!

Downloads

To download Carla binaries or source code, jump into the KXStudio downloads section.
If you're using the KXStudio repositories, you can simply install "carla-git" instead (plus "carla-lv2" and "carla-vst" if you're so inclined).
Bug reports and feature requests are welcome! Jump into the Carla's Github project page for those.

by falkTX at July 25, 2015 09:06 PM

Carla 2.0 beta4 is here!

Hello again everyone, we're glad to bring you the 4th beta of the upcoming Carla 2.0 release.
This release is mostly focused on bug-fixing, so there aren't many splashy new features to show compared to previous ones.
Still, here's the highlights:

Highlights

updated-skins

Updated plugin skins

The plugin skins received some updates once again.
They can now be collapsed in order to take less space.
More to come soon.


experimental-plugins

New experimental plugins

Some of the best linux-standalone tools are now working as internal Carla plugins.
And because Carla exports its internal plugins as LV2, you'll also get them as LV2.
Note that this is still experimental!
Also, there's no support whatsoever from the original authors...


mod-guis

MOD GUI Support

Carla can now show LV2 MOD GUIs, handled like a regular LV2 UI type.
Note that this only works on the right setups (you need MOD-UI to be working first).
It's not available on pre-compiled binaries, but you can get it via the KXStudio repositories.


More changes

  • LinuxSampler code has been reworked and it's working better, it now exposes 2 output parameters.
  • The plugin bridge code has been reworked; bridges are much more stable and MIDI-out is working.
  • NSM code has also been reworked, testers welcome.
  • OSC ports can be static by using CARLA_OSC_TCP_PORT and CARLA_OSC_UDP_PORT environment variables.
  • Time panel can be shown/hidden as needed.
  • DISTRHO-based internal plugins are back, specifically 3BandEQ/Splitter, PingPongPan, Nekobi, MVerb, VectorJuice and WoobleJuice.
  • carla-single script is back, allowing you to quickly test and run all plugins.
  • Carla as plugin allows new, open and save-as (export) menu actions.
  • Start of new midi-sequencer plugin, still experimental and Linux-only for now.
  • MIDI file internal plugin now saves the contents, so you can share projects without worrying if the file exists on the other system.
  • Added 6 basic parameters to the ZynAddSubFX internal plugin.
  • New MIDI channel filter plugin.
  • LV2 and AU plugins are cached and automatically updated when needed, no need for scanning.
  • Patchbay mode is now working for non-JACK drivers.
  • Carla saves internal and external connections, specially useful in patchbay mode.
  • Lots and lots of bug fixes.

Special Notes

  • Renaming plugins currently is not safe (unless using Rack mode).
  • GIG/SF2/SFZ skin still to be done, and some others...
  • Plugin bridges only work on Linux right now. They used to be working for OSX but stopped due to a OS limitation.
  • Windows 64bit builds a shows small console windows when discovering plugins. This is not intended and will hopefully be fixed soon.

Downloads

To download Carla binaries or source code, jump into the KXStudio downloads section.
If you're using the KXStudio repositories, you can simply install "carla-git" instead (plus "carla-lv2" and "carla-vst" if you're so inclined).
Bug reports and feature requests are welcome! Jump into the Carla's GitHub project page for those.

by falkTX at July 25, 2015 09:05 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Vee One Suite 0.7.0 - Seventh beta release

Hi everyone,

The 'Vee One Suite' of 'old-school' software instruments, aka. the 'gang
of three' have gone through yet another milestone: synthv1 [1], as one
polyphonic synthesizer, samplv1 [2], a polyphonic sampler and drumkv1
[3], as one drum-kit sampler, are now part of the Summer'15 release
frenzy :)

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

Common change-log follows:
- Complete rewrite of Qt4 vs. Qt5 configure builds.
- Reset ramps after LV2 control port reconnection; small fixes to
LV2.ttl (pull-requests by Hanspeter Portner aka. ventosus, on synthv1,
thanks).
- MIDI Controllers/Programs is now an optional feature on the LV2 plugin
forms, as some LV2 hosts might enforce the purity restriction to input
control ports as being absolutely read-only parameter values from a
plugin's instance perspective.
- MIDI Controller mapping/learn is now possible on all parameter control
knobs; with global configuration also available on the Help/Configure
dialog.
- French (fr) translation line to desktop file added (by Olivier
Humbert, thanks).

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

Here they go!


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

synthv1 0.7.0 (sixth 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://www.rncbc.org/archive/synthv1-0.7.0.tar.gz

- source package:
http://www.rncbc.org/archive/synthv1-0.7.0-23.rncbc.suse132.src.rpm

- binary packages:
http://www.rncbc.org/archive/synthv1-0.7.0-23.rncbc.suse132.i586.rpm
http://www.rncbc.org/archive/synthv1-0.7.0-23.rncbc.suse132.x86_84.rpm


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

samplv1 0.7.0 (sixth 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://www.rncbc.org/archive/samplv1-0.7.0.tar.gz

- source package:
http://www.rncbc.org/archive/samplv1-0.7.0-23.rncbc.suse132.src.rpm

- binary packages:
http://www.rncbc.org/archive/samplv1-0.7.0-23.rncbc.suse132.i586.rpm
http://www.rncbc.org/archive/samplv1-0.7.0-23.rncbc.suse132.x86_84.rpm


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

drumkv1 0.7.0 (sixth official beta) is out!

drumkv1 is 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://www.rncbc.org/archive/drumkv1-0.7.0.tar.gz

- source package:
http://www.rncbc.org/archive/drumkv1-0.7.0-19.rncbc.suse132.src.rpm

- binary packages:
http://www.rncbc.org/archive/drumkv1-0.7.0-19.rncbc.suse132.i586.rpm
http://www.rncbc.org/archive/drumkv1-0.7.0-19.rncbc.suse132.x86_84.rpm


References:

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

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

[3] drumkv1 - an old-school drum-kit sampler
http://drumkv1.sourceforge.net/

[4] JACK Audio Connection Kit
http://jackaudio.org/

[5] NSM, Non Session Management
http://non.tuxfamily.org/nsm/

[6] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/

[7] LV2, Audio Plugin Standard, the extensible successor of LADSPA
http://lv2plug.in/

[8] GNU General Public License
http://www.gnu.org/copyleft/gpl.html

[9] http://linuxaudio.org


See also:
http://www.rncbc.org/drupal/node/916


Enjoy && keep the fun ;)
--
rncbc aka. Rui Nuno Capela
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

by rncbc.org at July 25, 2015 03:36 PM

July 24, 2015

rncbc.org

Qtractor 0.7.0 - The Muon Base is out!

Ahoy!

Stepping up to Summer'15 release frenzy stage scene, in its fourth and hopefully last act,

Qtractor 0.7.0 (muon base beta) is out!

As a major highlight to this release, there's the advent of regular MIDI controllers mapping/assignment to main application menu command actions, just like normal PC-keyboard shortcuts, is being introduced (cf. main menu Help/Shortcuts...).

Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt 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.

As a major highlight to this release, there's the advent of regular MIDI controllers mapping/assignment to main application menu command actions, just like normal PC-keyboard shortcuts, is being introduced (cf. main menu Help/Shortcuts...).

Have a hotta Summer'15 ;)

Enjoy.

Flattr this

Website:

http://qtractor.sourceforge.net

Project page:

http://sourceforge.net/projects/qtractor

Downloads:

License:

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

Change-log:

  • Complete rewrite of Qt4 vs. Qt5 configure builds.
  • Revised MIDI Controlllers catch-up algorithm.
  • Mixer multi-row layout gets a little bit of a fairness fix.
  • Non-continuous MIDI Controllers now have their Hook and Latch options disabled as those are found not applicable,
  • As an alternative to PC-keyboard shortcuts, MIDI controllers are now also assignable and configurable for any of the main menu command actions, all from the same old configuration dialog (Help/Shortcuts...).
  • Fixed missing Track and Clip sub-menus from Edit/context-menu that were found AWOL ever since after the Lazy Tachyon beta release (> 0.6.6).
  • An off-by-one bar position (as in BBT, bar, beat and ticks) has been purportedly fixed as long as LV2 Time/Position atom event transfer goes.
  • French (fr) translation line to desktop file added (patch by Olivier Humbert, thanks).
  • A new top-level widget window geometry state save and restore sub-routine is now in effect.
  • Improved MIDI clip editor resilience across tempo and time-signature changes.
  • Keyboard shortcuts configuration (Help/Shortcuts...) now lists complete menu/action path where available.
  • Fixed in-flight VST plugin editor (GUI) resizing.
  • Added support to LV2UI_portMap extension, found really handy for the cases where you have multiple plugins with different port configurations and a single common UI to drive them all (pull request by Hanspeter Portner aka. ventosus, thanks).

Enjoy && keep the fun.

by rncbc at July 24, 2015 09:00 PM

Vee One Suite 0.7.0 - Seventh beta release

Hi everyone,

The Vee One Suite of old-school software instruments, aka. the gang of three have gone through yet another milestone: synthv1, as one polyphonic synthesizer, samplv1, a polyphonic sampler and drumkv1, as one drum-kit sampler, are now part of the Summer'15 release frenzy :)

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

Common change-log follows:

  • Complete rewrite of Qt4 vs. Qt5 configure builds.
  • Reset ramps after LV2 control port reconnection; small fixes to LV2.ttl (pull-requests by Hanspeter Portner aka. ventosus, on synthv1, thanks).
  • MIDI Controllers/Programs is now an optional feature on the LV2 plugin forms, as some LV2 hosts might enforce the purity restriction to input control ports as being absolutely read-only parameter values from a plugin's instance perspective.
  • MIDI Controller mapping/learn is now possible on all parameter control knobs; with global configuration also available on the Help/Configure dialog.
  • French (fr) translation line to desktop file added (by Olivier Humbert, thanks).

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.

Here they go!

synthv1 - an old-school polyphonic synthesizer

synthv1 0.7.0 (seventh 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.7.0 (seventh 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.7.0 (seventh official beta) is out!

drumkv1 is 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 && keep the fun ;)

by rncbc at July 24, 2015 06:00 PM

July 23, 2015

Libre Music Production - Articles, Tutorials and News

Build a 128 touch sensitive keyboard with Arduino

On his blog, Georg Mill, Arduino hacker and musician, describes how to build a 128 touch sensitive keyboard with one Arduino Uno and some additional cheap electronics.

Read about the TouchDuinoX(tended).

Also, be sure to check out our tutorials on how to build your own MIDI interface using the Arduino micro controller:

by admin at July 23, 2015 09:24 AM

July 22, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] XJackFreak released.


Hi everyone,

I've just put XJackFreak up on github so you can try it out.

XJackFreak is an GNU/Linux/X11 Jack Audio app that displays the FFT
frequency spectrum. It can even do some EQ as well!

Here's a nice screenshot:
https://github.com/johnhldavis/xjackfreak/blob/master/doc/xjackfreak.png

Main page:
https://github.com/johnhldavis/xjackfreak

OR a direct download.
https://github.com/johnhldavis/xjackfreak/archive/master.zip

Any probs or feedback appreciated.

Have fun.

regards,
John
PPS Apologies if you're seeing this twice: I sent it to the wrong list! Eek.

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

by mirainet.org.uk at July 22, 2015 07:37 PM

July 21, 2015

Create Digital Music » open-source

Launchpad Pro Grid Controller: Hands-on Comprehensive Guide

launchpad_pro - 7

Novation’s Launchpad Pro is here. It shares the same compact footprint as earlier Launchpads, but adds full color, pressure-sensitive pads, and MIDI inputs and outputs, plus the ability to operate without a computer. So, with other grids to choose from, where does this one fit?

The Launchpad line of controllers has always been about simplicity. Even when the original Launchpad was introduced, it did less than its nearest rival, the AKAI APC. But it was popular partly thanks to being simple, light, small, and affordable. That fits many users’ needs, and can be nicely combined with other hardware.

The Launchpad Pro keeps to that approach, but with more features to round it out as a production tool and performance controller. And it isn’t just for Ableton Live, either – it has a respectable feature set when used with other MIDI software and hardware. I’ve got one of the first units and have been carrying around using it. Let’s have a look.

First, here’s the amazing Thavius Beck performing with the instrument live:

Meet the Family

The Launchpad, drawing on a tradition established by the monome community, is all about triggering clips, making patterns, and playing melodic and drum instruments from a grid. Ableton Live support is standard, which makes setup easy – make sure you’ve updated Live 9, plug in, and go. But integration with other music and live visual software is possible, too. That includes Novation’s own iOS apps, FL Studio, Bitwig Studio, and Renoise, to name a few.

Novation’s current Launchpad lineup includes three models. All the latest models are driverless over USB, so they work with any OS (including iOS, with the proper adapters). The new models also all feature a bright orange rubber base mat to prevent slipping. Beyond that, the models:

Launchpad mini – the portable one. The ultra-compact model offers a basic 8×8 grid with yellow/red/green lighting and trigger keys. Those triggers are labeled A-G and 1-8 on the hardware, but included stickers let you mark up whatever assignments you want for your software of choice.

Launchpad – now RGB. The current Launchpad keeps the original basic Launchpad design – USB, grid, row of triggers on top, column of triggers on the side. But it adds RGB color for more visual feedback on what you’re controlling.

The current color “Launchpad” replaces the first two Launchpads. I still have original Launchpad serial number 7, and it holds up, but it’s not driverless like the other models. The Launchpad S is more compact and has some aesthetic and functional improvements, but you might now opt for the mini instead.

Compatibility/power on the different models is as follows:
Original Launchpad: Bus powered. OS X, Windows drivers. Not USB class-compliant, so you can’t use it with iOS – but there is actually a Linux driver contributed by the community, so you can use it with a Raspberry Pi.

Launchpad S, Launchpad mini: Bus powered. Driverless.

Current, color Launchpad and Launchpad Pro: Bus powered, but iOS doesn’t provide enough power, so you’ll need a hub. Driverless.

lp-pro-left-elevated

Launchpad Pro Form Factor

Remarkably, the Launchpad Pro isn’t much bigger than the original Launchpad – and it’s much smaller than Ableton’s Push. But it still does a lot.

The most important change is the pads. Unlike the rest of the Launchpad line, the Pro is the first and only model (so far) with velocity and pressure sensitivity for more expressive performances.

For 4×4 grids with larger pads, I’m partial to what Native Instruments has done with Maschine and Akai with Renaissance. On 8×8 grids, though, the nearest rival is certainly Ableton’s Push.

What’s impressive about the Launchpad Pro is consistency – both in the velocity range of each pad, and in getting the same results across the grid. That is, there’s a very solid range from minimum pressure to maximum pressure, and each pad performs similarly to each adjacent pad. As a keyboardist, I find this really satisfying – that is, once I switch the Launchpad Pro’s sensitivity to high. In its default setting, it will require more pressure – better if you just want consistent one-shots and don’t care as much about expressive melodic parts. For those of you who want to bang the Launchpad really hard, you can turn sensitivity down to low. At each of these three settings, you’ll still get a range of different velocities. ‘High’ is certainly comfortable to keyboardists and finger drummers with a lighter touch; ‘Medium’ is a more typical finger drumming setting, and ‘Low’ is exclusively for those who like to attack their hardware. (More on that below.)

Color feedback is bright and clear; I actually prefer the colors here to Maschine and Push. And now you do have additional triggers, which means a functions previously doubled on the right-hand side now have their own, dedicated controls.

launchpad_pro - 1

The best part of the Launchpad Pro is its form factor. As on other recent Launchpads, the rubber mat keeps the controller in place when on a surface. You can really wail on the pads, and it won’t budge. Contrast that to Ableton’s solution on Push, which is adding a lot of weight to the device – something that’s nice when you’re in the studio, but not so nice when you put a device in your bag. The Launchpad Pro has some added weight, too, but not enough to give mobility a second thought.

Round the back, you’ll find a jack for a power adapter (for standalone operation, instead of powering via USB), USB, plus minijack breakouts for MIDI input and MIDI output to hardware.

There’s a new Setup button, depressed so you won’t accidentally hit it. It brings up a color-coded menu page for adjusting more settings:

  • Standalone layouts for MIDI operation
  • Velocity
  • Aftertouch – polyphonic or channel aftertouch, pressure sensitivity
  • Pad lighting (internal or via MIDI)
  • MIDI channel

Ableton Live

There are five ways to use the Launchpad Pro with Ableton Live, and they’re clearly marked on the top with the mode buttons.

Session: This is the clip launching mode. It now benefits a lot from RGB feedback. Not only are the clips color-coded, but the new dedicated shortcuts on the bottom are, too. Those are now more convenient to access – no Shift needed. You can still trigger scenes with triggers on the right, but on the left you get new shortcuts for Undo/Redo, Delete, Quantise/Record Quantize, Duplicate, Double, and recording and click. (You can thank Push for adding this functionality to Ableton’s software.)

Session Mode also has stepped faders as on previous models. However, Novation has added the ability to use velocity to make transitions between values gradually. Switch to Volume, for instance, and hit the bottom pad hard to make a fader drop quickly, or gently to make it smoothly transition. (Sadly, you don’t get any software control of that, yet – Lemur-style physics, anyone?)

launchpad_pro - 6

Note (Melodic): On melodic parts, you get a grid of notes. It’s spaced chromatically (half step) in rows, and by fourths in columns. You’ll see a C major scale marked in blue, with octaves in pink, so you could use this as a visual reference to stay in key. Now, that means there’s some overlap — to make a chromatic scale, you would actually use the 5×8 section on the right-hand side of the grid. You can’t change scale mappings as on Push – that’s the problem with lacking a display. But you can use Ableton’s MIDI Devices to do the same job (Pitch, Scale to transpose or restrict pitches).

Note (Drum): On Drum Racks, instead of the blue/pink display, the grid maps to loaded samples. As Ableton added with Push and Live 9.2, the entire 8×8 grid is usable. Unlike Push, though, there’s no step sequencing mode.

Device: Device mode maps to the active parameter controls for instruments, effects, and the like. As on the Session faders, you can use velocity to transition through values at different rates. Here, the Launchpad Pro is decidedly at a disadvantage versus Push, though: without a display, you don’t know what you’re controlling, and you’re likely to miss turning encoders. On the other hand, with the right performance setup, this could still be useful.

User: Novation introduced the idea of a ‘User’ page for easy mapping with Max for Live and the like, and it’s back here. (You will need to do your own patching to add velocity transitions between steps, but that’s possible.) I like it for another reason, too: here, notes are mapped chromatically by row in groups of four, then by major third vertically.

launchpad_pro - 4

launchpad_pro - 5

So, how does it compare? The upshot of all of this is a controller that’s much more limited than Push – and more like a traditional Launchpad.

Now, I tend to shift between doing quick improvisation on a controller and fine-tuned editing on the display with the mouse, so for me, this is fine.

But, then, if the Launchpad is all about performance, I miss some performance-oriented features even more. The absence of a step sequencer for melodic and drum tracks is frustrating. And I really miss having a Note Repeat feature, as found on Akai gear (old and new), Maschine, and with dedicated controls on Push. On melodic parts, that single grid I’m sure won’t work for everyone, either.

All of this calls out desperately for some Max for Live hacks (or other custom tools in other software), which I expect we’ll see coming soon. The affordability and simplicity of the Launchpad line seem to motivate hackers even more.

lp-pro-overhead

Real Controllers Have Curves

One side note, relevant to using the Launchpad Pro as a controller instrument. Making a pad expressive requires a combination of hardware sensing and firmware. In my ongoing tests, I’ve been impressed both anecdotally – and when measuring MIDI values as I play – by the hardware. There’s a large velocity range, you can hit different parts of the range accurately, and sensing from pad to pad is consistent.

The other adjustment is in software. I like setting everything to HIGH, but I got some more clarification from Novation about how the curves actually work – not just for velocity, but aftertouch, as well. (And note that you do get polyphonic aftertouch out of the Launchpad Pro – you just need hardware or software capable of receiving it.)

We designed the velocity curves first by identifying the smallest amount of pressure to trigger a pad and then selecting how hard we wanted to be hitting a pad without hurting fingers to get the max value (127). By
setting the top and bottom points in this way we created the maximum playable dynamic range.

Next we figured out where the main playable area of the curve lies and flattened out the curve in this range to make the majority of playing more controllable.

Finally we created a high curve and a low curve to suit different styles of playing and lighter or heavier handed players. These two curves were created by adjusting the main playable area upwards (HIGH – output is greater for the same velocity input) and downwards (LOW – output is lower for the same velocity input) while keeping the maximum and minimum points the same to maintain the full dynamic range.

The curves are remembered per layout so you can select the MEDIUM curve for use with a chromatic instrument and the HIGH curve for playing drums, for example.

For aftertouch we have three settings described by a threshold of LOW, MEDIUM or HIGH. To get the full range of control the user can choose the LOW setting which means the aftertouch can be triggered easily and has
the maximum range. Medium and high settings raise the threshold making it easier to play the pads without triggering aftertouch with a reduced range.

lp-pro-rear0

Custom MIDI and Standalone Operation

Here’s where things get interesting. Connected to your computer, the Launchpad has three MIDI ports in software: “Live” (when Live is running), “standalone,” and the physical MIDI DIN. So, you can easily intercept MIDI messages.

If you aren’t running Ableton Live, the Launchpad automatically switches to one of the default layouts. That makes it convenient for use with other software.

For instance, here’s a video with Logic Pro X:

Even better, connect the Launchpad Pro to power, and you can use these modes without even attaching a computer – just connect MIDI gear via the included minijack-to-DIN breakouts for the in and out ports.

There are four modes:

Note: This is the melodic layout. You can use the arrow buttons to move around the pitch grid; the other trigger shortcuts dim (though they’re still MIDI assignable if you choose). As it is in Live, pitch is mapped chromatically along the horizontal axis and in fourths along the vertical axis.

Drum: This is a little different than what you get in Live – and actually a little cooler. Each page is grouped into four 4×4 grids and color-coded, perfect for triggering drums and one-shot samples. You can navigate multiple pages, too.

Fader: Here, you get eight faders with velocity triggering. Unfortunately, this is the one mode without pages, which is disappointing. You can actually control 16 banks of 8 faders, one for each MIDI channel, but that requires swapping the active MIDI channel in the Setup page. This seems a missed opportunity, especially with color feedback for each page.

Programmer: This is an “advanced” mode for programming your own functionality.

You can watch them in action in Novation’s video:

Even in the default modes, though, there is room for hackability. All of the trigger buttons still send MIDI messages and respond to LED color messages, so even though they’re disabled by default, you could set up some custom mapping.

Again, it’s the step sequencer I’m sorry to see missing.

Hackability

Most of what you’d probably want out of the Launchpad Pro can be accomplished using only MIDI. For instance, here they are using the Launchpad’s MIDI-addressable LEDs to make a custom light show:

But for more advanced interactions in standalone mode, you need access to the firmware. And there’s some good news. In a story we broke last week, the Launchpad Pro is set to be the most hackable commercial MIDI controller to date. A custom firmware API will let you use simple C code to produce your own functionality.

Hack a Grid: Novation Makes Launchpad Pro Firmware Open Source

The current modes are already great, but the Launchpad Pro for me would become invaluable once it has a usable Note Repeat mode, a step sequencer, and perhaps an arpeggiator or chord generator. All of these are possible in the custom firmware, so now either I can build that myself the way I want or hope someone else does it.

For more on the open source initiative, you can follow Novation on Tumblr:
http://launchpadfirmware.tumblr.com

launchpad_pro - 3

Conclusions

The Launchpad Pro and Ableton’s flagship Push aren’t so much direct rivals as two devices that each serve a particular niche.

If you want a device that is so deeply integrated with Ableton Live that you don’t even have to look at the computer screen, Ableton Push has no match. Push is by far the most powerful studio device, and has the broadest feature set. And odds are, you’ll miss some of that on the Launchpad Pro. Push’s display, encoders, Note Repeat, touch strip, step sequencing, and flexible pitch layouts mean there’s no trouble differentiating it from the Launchpad Pro. Push is also a good choice for newcomers to Live, because unlike long-time users, they probably don’t already have a workflow with faderboxes and the like.

On the other hand, for all the same reasons, it’s possible Push is too much. It’s heavier. It’s bigger. And its street price is twice as expensive as the Launchpad Pro, with Push at $600 street (or a little less if you catch a sale), versus $300 street for the Novation. The fact that it does less also means it may fit a modular setup better – combining with your favorite fader box, for instance.

And on top of that, while the Push costs twice as much, it’s useless when disconnected from a computer. The Launchpad Pro is at home with Ableton Live, but it’s also a nice add-on to standalone synths and drum machines.

All of this gets still more interesting, potentially, as hackers get their hands on the hardware and the custom firmware API.

If you’re looking for a single piece of hardware that integrates all your workflows in Ableton Live, I wouldn’t hesitate to recommend Push. But if you’re mainly interested in a playable grid, in something that’s mobile, and something that works with other hardware, Launchpad Pro is easy purchase at half the price.

The only real downside is that some of the Launchpad Pro’s potential remains in the future. Filling in the gaps in sequencing, giving it more functionality with MIDI hardware, and adding deeper integration with Ableton Live and other hosts will all rely on the community of hackers giving it more to do. But for now, it’s the most mobile and playable grid on the market, and if past experience is a guide, that community will make it more valuable as it ages, not less.

Launchpad Pro [Novation Music / Global Site]

The post Launchpad Pro Grid Controller: Hands-on Comprehensive Guide appeared first on Create Digital Music.

by Peter Kirn at July 21, 2015 06:04 PM

m3ga blog

Building the LLVM Fuzzer on Debian.

I've been using the awesome American Fuzzy Lop fuzzer since late last year but had also heard good things about the LLVM Fuzzer. Getting the code for the LLVM Fuzzer is trivial, but when I tried to use it, I ran into all sorts of road blocks.

Firstly, the LLVM Fuzzer needs to be compiled with and used with Clang (GNU GCC won't work) and it needs to be Clang >= 3.7. Now Debian does ship a clang-3.7 in the Testing and Unstable releases, but that package has a bug (#779785) which means the Debian package is missing the static libraries required by the Address Sanitizer options. Use of the Address Sanitizers (and other sanitizers) increases the effectiveness of fuzzing tremendously.

This bug meant I had to build Clang from source, which nnfortunately, is rather poorly documented (I intend to submit a patch to improve this) and I only managed it with help from the #llvm IRC channel.

Building Clang from the git mirror can be done as follows:


  mkdir LLVM
  cd LLVM/
  git clone http://llvm.org/git/llvm.git
  (cd llvm/tools/ && git clone http://llvm.org/git/clang.git)
  (cd llvm/projects/ && git clone http://llvm.org/git/compiler-rt.git)
  (cd llvm/projects/ && git clone http://llvm.org/git/libcxx.git)
  (cd llvm/projects/ && git clone http://llvm.org/git/libcxxabi)

  mkdir -p llvm-build
  (cd llvm-build/ && cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=$(HOME)/Clang/3.8 ../llvm)
  (cd llvm-build/ && make install)

If all the above works, you will now have working clang and clang++ compilers installed in $HOME/Clang/3.8/bin and you can then follow the examples in the LLVM Fuzzer documentation.

July 21, 2015 10:08 AM

July 20, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Summer'15 release frenzy pt.2 - Qsampler 0.3.1 is out!

The Summer'15 release frenzy continues... ;)

On the wake of LinuxSampler 2.0.0 release [1],

Qsampler 0.3.1 is out! [2]

And it lands at the precise moment sourceforge.net outage disaster [5]
is still going through hopefully out of recovery hell. Also worth noting
is that Qsampler [2] is now raked as a genuine Qt5 [3] application,
leaving Qt4 behind but still an option.

Qsampler [2] is a LinuxSampler [1] GUI front-end application written in
C++ around the Qt [3] framework using Qt Designer.

Website:
http://qsampler.sourceforge.net (still unavailable [5] at this time :()

Downloads:
- source tarballs:
http://download.linuxsampler.org/packages/
http://download.linuxsampler.org/packages/qsampler-0.3.1.tar.bz2
- binary packages:
http://download.linuxsampler.org/packages/rpms/

http://download.linuxsampler.org/packages/rpms/qsampler-0.3.1-16.rncbc.suse132.i586.rpm

http://download.linuxsampler.org/packages/rpms/qsampler-0.3.1-16.rncbc.suse132.x86_64.rpm

Change-log:
- Fixed configure script's Qt include directory lookup for some 64bit
Linux flavours.
- Prefer Qt5 over Qt4 by default with configure script.
- A new top-level widget window geometry state save and restore
sub-routine is now in effect. (EXPERIMENTAL)
- Fixed for some strict tests for Qt4 vs. Qt5 configure builds.

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

See also:
http://www.rncbc.org/drupal/node/914

References:
[1] http://www.linuxsampler.org
[2] http://qsampler.sourceforge.net
[3] http://qt.io
[4] http://www.gnu.org/copyleft/gpl.html
[5]
http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration


Enjoy && have fun!
--
rncbc aka. Rui Nuno Capela
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

by rncbc.org at July 20, 2015 02:42 PM

Create Digital Music » open-source

An ‘Interspecies’ Music Interface Combines a Mask, Bacteria

Organum Vivum – a interspecies interface from Paul Seidler on Vimeo.

Your next digital interface might be grown, not made.

Organam Vivum drops the usual combinations of knobs and hard surfaces and wires for something organic – an “interspecies” interface. The sensors are grown from bacteria, formed into alien-looking, futuristic materials and a mask. The bio-interfacing project began as a collaboration between Aliisa Talja (who has a background in industrial design) with Paul Seidler at the CDM-hosted MusicMakers Hacklab at CTM Festival earlier this year. Not only are the materials literally organic, but in touching and breathing into these delicate constructions, your interactions themselves become unpredictable.

This is bacterial cellulose, routed into a computer via Leslie Garcia’s open source PulsumOSC library. (Leslie was the co-facilitator for this year’s lab; find her OpenFrameworks code on GitHub.) SuperCollider produces the sound, with Arduino providing the interface. Since the hacklab, the project has been steadily growing (so to speak), and Aliisa sends along the latest documentation from her and Paul.

The results may seem strange and alien, but that’s perhaps part of the point. This is speculative work that exposes the tension between interface and user, material and sonification. But in doing so, it also reveals some of what may happen as we open up fabrication and design to new realms, beyond just the oft-trod paths of our petro-chemical world in the peak of the cheap oil age. And watching Paul and Aliisa embrace the ritual of playing it is entrancing. More details below of their process.

11-02-2015_leap_till_bovermann

Here’s an overview of what happened at CTM, including this piece:

Documentary MusicMakers Hacklab at CTM Festival 2015 from CDM on Vimeo.

And reproduced from their research document, more details:

Concept

Organum Vivum is an interspecies interface advantaging the characteristics of organic material as well as exploring the possibilities of combining natural and build organisms in sound synthesis.
Bacterial cellulose items, working as sensors, are translating our direct interaction with them into a soundscape controllable with touch and breath.
In order to communicate in human level through the instrument we’ll have to be aware of the behaviour of a natural material and it’s, sometimes unpredictable, responses to our actions. The result is a sonification of direct interspecies interaction between a human and a micro organism.

Bacterial Cellulose
Bacterial cellulose is an organic compound consisting of certain type of bacteria, which by using glucose creates an envelope around it’s cells thus forming a fine and strong, chemically pure, network structure. We came across it while looking for biomaterials which would be easy to grow without a laboratory environment. By simply making a mixture of black tea and sugar and placing the host culture in the jar we were able to grow several bacterial cellulose pieces of different size then used as sensors in the final setup.

The functionality is based on measuring of the conductivity of bacterial cellulose. As an organic material it’s able to absorb and release water and can thus be used as a breath sensor reacting to the humidity of our exhalation. By touching the material we’re bringing our body, our conductivity, as part of the system, which can then be influenced through the increasing and decreasing of the touch area (e.g. stroking, pressing, folding).

By varying the the amount of water in every piece we’re also able to control the sensibility of the material. The structure can hold enough liquid to reach the conductivity of water, on the other hand it can be dried up so effectively that the conductivity drops close to zero.

organumsetup

Hard- and software

We started by prototyping a small circuit to measure the resistance of four pieces of bacterial cellulose. The circuit has 5.1 k resistors as reference resistance and the analog input pins of the arduino as the input device. The values of the resistors were determined by purely experimenting, while having the openFrameworks application, PulsumOSC by Leslie Garcia, running. This way we were able to get some permanent values.

The design of the circuit also made it necessary to implement four diodes. Software wise, the final setup consists of an arduino script, that is reading constant values from the analog input pins and then sending them via serial to the openFrameworks application which finally transforms the values in OSC messages and sends them to supercollider. The Supercollider patch consists of three Influx’s which control three Ndef’s and some OSCresponderNodes. The first version of
the hardware thus consisted of an arduino, a soldered circuit on a prototyping board and crocodile clamps for embedding the organic material.

For the final prototype we replaced the crocodile clamps with glueing the wires onto the bacterial cellulose with pieces of the material itself. This way we were able to attain both a better usability and the simple aesthetics we wanted. The form of the user interface was to large extent dictated by the functionality of the pieces and easily formable rapid prototyping materials available. In the end we created three different pieces; a mask made out of EVA foam, a touch pad with a base made out of acrylic glass and a foldable piece with poly-propylene holder.

Playability

Organum Vivum can be used for playing solo or as well as a part of an ensemble. By using various bacterial cellulose sensors (breath, touch, pressure) multiple digital instruments can be played simultaneously and a rich, evolving ambience can be created. This soundscape can then form a sound piece in itself or a fragment of a more complex composition consisting of other digital or even acoustic instruments.

Sonic quality

As a controller the piece itself doesn’t have acoustic or sonic qualities. Instead, the digital synthesisers which we created for the performance are inspired by bioacoustics; imitating properties of organic, periodic sound patterns like cat purring and cricket stridulation, mixed with crude sound synthesis. These segments come together as a minimal, medita- tive but animalistic layered soundscape with subtle changes, which spark connotations to both synthetic and organic, thus engineered organisms.

IMG_6674

mask

Performative quality

The focus of the instrument lies on the material and on the idea of interspecies communication. Through moist and touch the bacterial cellulose interface is easily influenced but not entirely controllable. Due to the characteristics of an organic material the player cannot gain a total control over the system which brings the user and the instrument to a more equal position. This concept of control is also explored in Lose control, gain influence – Concepts for Metacontrol, de Campo (2014).

Furthermore, the small size and the limited controllability of the objects bring the quality of presence of the performer in a vital position of performing with Organum Vivum. Like the changes in the soundscape and the response of the bacterium cellulose, the movements of the performer are clear, concentrated and subtle. Performing with Organum Vivum regards setting oneself to a sensitive state as a vital but not dominating part of an organism.

What went well

After circling around biosynthesis related themes for a long time we were able to nar- row down the number of key factors, without losing the original area of interest. We man- aged to find our focus but work open minded with the material. The process stayed flexible as we made use of our research so far and found a way to apply sounds, originally creat- ed for other purposes, to the final work.

In the end we succeeded as well in the defining of the final concept as in holding on to it in the actual performance, and were able to create a holistic, simplified and concentrated piece. A fluent teamwork made it possible to achieve a focused atmosphere and “a mutu- al state of mind” while both practising and performing.

Due to spending a week at Musicmaker’s Hacklab at CTM Festival 2015 our work was influenced by a sound artist Leslie Garcia with whom we were able to discuss and share a ideas of themes related to working with microorganisms. During the festival we also got a valuable chance to present the project to a broader audience.

Further steps

In the future the first step would be to define the hardware, i.e. build a compact, secure setup. It would be fascinating to execute more experiments with the material and possibly be able to detect differences in the relation between the way of touch and the response. To make the system more user friendly we would consider securing the functionality
to reduce it’s unexpectancy (e.g. solving the occasional problems of gaining no response at all). Performing with the original setup a simple improvement would be to get rid of the computer and the grounding plate and using some other kind of controller alongside Organum Vivum instead.

On the other hand, because of the material knowledge we’ve gained so far and the scarce applications of it in the field of sound it would even be interesting to continue working on a creation and definition of a simple, intuitive user interfaces based on the prototypes. In addition the concept of touch pad could be developed further, for instance resulting to a interspecies midi controller.

For more, see the project site:
plsdlr.net/?/Works/OrganumVivum/

You can also catch their performance among others in a concert by the project 3DMIN:

3DMIN CONCERT #3 – Body, Space, Relation from 3DMIN on Vimeo.

A concert of Music performances with experimental instruments, that were developed within the 3DMIN project between october 2014 and february 2015 at the University of Arts Berlin. The concert took place on 12.2.2015 at the Leap in Berlin as the third issue of the collaborative Lecture and Performance Series between 3DMIN and LEAP. Four performances were shown, each featuring one or more instrument prototypes developed in the scope of the 3DMIN project, focusing the aspects Body, Space and Relation.

Artists and pieces:
Julius and Lucas Fischötter – S / A / S / A
Nicolas Lefort und Jonas Hummel – Sum 0.2
Gabriel Treindl, Maximilian Buske and Ruben Layer – Euclidomat
Aliisa Talja and Paul Seidler – Organum Vivum

The post An ‘Interspecies’ Music Interface Combines a Mask, Bacteria appeared first on Create Digital Music.

by Peter Kirn at July 20, 2015 02:25 PM

July 19, 2015

rncbc.org

Summer'15 release frenzy pt.2 - Qsampler 0.3.1 is out!

The Summer'15 release frenzy continues... ;)

On the wake of LinuxSampler 2.0.0 release,

Qsampler 0.3.1 is out!

And it lands at the precise moment sourceforge.net outage disaster is still going through hopefully out of recovery hell. Also worth noting is that Qsampler is now raked as a genuine Qt5 application, leaving Qt4 behind but still an option.

Qsampler is a LinuxSampler GUI front-end application written in C++ around the Qt framework using Qt Designer.

website:
http://qsampler.sourceforge.net
downloads:

Change-log:

  • Fixed configure script's Qt include directory lookup for some 64bit Linux flavours.
  • Prefer Qt5 over Qt4 by default with configure script.
  • A new top-level widget window geometry state save and restore sub-routine is now in effect. (EXPERIMENTAL)
  • Fixed for some strict tests for Qt4 vs. Qt5 configure builds.

License:

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

Enjoy && have fun!

Flattr this

by rncbc at July 19, 2015 06:00 PM

July 17, 2015

Libre Music Production - Articles, Tutorials and News

June/July 2015 – Interviews, tutorial and news

Our newsletter for June/July is now sent to our subscribers. If you have not yet subscribed, you can do that from the Libre Music Production start page.

You can also read the latest issue online. In it you will find:

by admin at July 17, 2015 05:59 PM

Create Digital Music » open-source

Hack a Grid: Novation Makes Launchpad Pro Firmware Open Source

launchpadhack

Novation’s Launchpad Pro has just begun shipping, and it’s lovely, very flexible hardware. You can use it with Ableton Live. You can use it with other software, as a standard MIDI controller. It’s USB class-compliant, so it works with other devices and operating systems, like the iPad and Raspberry Pi. You can change how it works with Max for Live, or any software that supports MIDI. And it works in a variety of standalone modes, so you can use it to play hardware without connecting to a computer.

That’s a lot, already. But soon, the Launchpad Pro could do more.

Novation quietly released a special customizable firmware as open source code on GitHub. And, inspired by recent Head of Product Innovation Dave Hodder has even written a screed about hacking. Despite the Launchpad-specific headline, it’s actually more or less a love letter to the whole hacker / DIYer / open source community, generally:

Launchpad Pro: A Hacker’s Dream

Now, you’re not actually hacking the entire Novation firmware. That’d cause potential mayhem, and apart from being a support nightmare for Novation, it’d be more or less a nightmare for you, too – and wouldn’t really yield any interesting results.

Instead, you can think of this as an open API to the hardware itself. You can’t “brick” the device, or otherwise break it. What you can do is make new applications for the Launchpad Pro as a standalone device.

In your code, you can include messages to and from the hardware:

  • Receive events when you press the pads and buttons
  • Receive messages from the USB port or MIDI port (there are MIDI input and output jacks on the Launchpad Pro)
  • Send messages to the USB and MIDI ports
  • Receive tick messages – so your app can sync to an external source
  • Change the LED colors

Thanks to the Novation team for messing with our synth at a hack day recently!

Thanks to the Novation team for messing with our synth at a hack day recently!

At your disposal is the Launchpad Pro’s brain, an ARM Cortex M3 from STMicroelectronics. (72 MHz, baby!) To make life easier, they’ve even built a virtual machine you can install so your developer environment is ready to run. Then, you build on a command line or in Eclipse and upload via MIDI – fairly easy stuff.

You code in C – the app.c file shows you what’s going on. Even with pretty basic coding skills, it’s pretty accessible; that’s the advantage of them hiding away the nasty stuff you’d only want to touch if you were an experienced developer and Novation offered you a job.

With just those elements, you can do a whole lot. Fun hacks light light shows and games are possible, and might be an enjoyable way to learn. But you’ll also be able to create musical applications that aren’t already on the hardware, like chord generators, arpeggiators, or even a step sequencer.

This could be huge for Launchpad Pro owners even if you aren’t a coder, because it could mean a community around the device sharing this stuff and supporting one another.

To make things even easier, though, we’re talking with Novation about how some examples might be produced that will help get people started.

launchpad_pro - 1

I love the idea, though, as a musician as much as a hacker. It opens up the possibility of having standalone hardware in the studio you can use with or without a computer, ready to perform the tasks you want in your music creation process. And it means you can imagine something and get it working on hardware without the daunting task of trying to build something from scratch. I think it’s potentially a great companion to our open source, standalone, ready-to-play MeeBlip synth – you’ll spot one in the shot above, getting some use at the recent MIDI Hack in Berlin. And I don’t just mean as a product – it’s something I want to use with my MeeBlips, myself!

There really isn’t any direct comparison, either – grid hardware with velocity and standalone operation that you can hack directly on the device. Of course, the whole initiative from Novation does owe a huge debt, though, to the monome line, and the fact that that maker and its community really championed and popularized the idea of sharing open musical solutions around a piece of hardware. It’s difficult to overstate the impact Brian Crabtree, Kelli Cain, and the monome musicians have had on the industry, as well as all the people who have been organizing these hack days and producing creative ideas.

Stay tuned for more on where this is leading. And if you have feedback on that API or what you’d like to see, let us know in comments.

https://github.com/dvhdr/launchpad-pro

Photo: Sebastian Höglund.

The post Hack a Grid: Novation Makes Launchpad Pro Firmware Open Source appeared first on Create Digital Music.

by Peter Kirn at July 17, 2015 01:48 PM

GStreamer News

GStreamer Conference 2015 - Call for Papers

This is a formal call for papers (talks) for the GStreamer Conference 2015, which will take place on 8-9 October 2015 in Dublin (Ireland), and will be co-hosted with the Embedded Linux Conference Europe (ELCE) and LinuxCon Europe.

The GStreamer Conference is a conference for developers, community members, decision-makers, industry partners, and anyone else interested in the GStreamer multimedia framework and open source multimedia.

The call for papers is now open and talk proposals can be submitted.

You can find more details about the conference on the GStreamer Conference 2015 web page.

Talk slots will be available in varying durations from 20 minutes up to 45 minutes. Whatever you're doing or planning to do with GStreamer, we'd like to hear from you!

We also plan on having another session with short lightning talks / demos / showcase talks for those who just want to show what they've been working on or do a mini-talk instead of a full-length talk.

The deadline for talk submissions is Sunday 9 August 2015.

We hope to see you in Dublin!

July 17, 2015 12:00 PM

July 16, 2015

Libre Music Production - Articles, Tutorials and News

Audacity 2.1.1 is released

Audacity 2.1.1 has just been released with new features and performance improvements. Of note are -

by Conor at July 16, 2015 05:29 PM

QjackCtl 0.4.0 is out!

Rui Nuno Capela has just announced the release of QjackCtl 0.4.0.

This release makes it easier to get up and running as it now splits the setup settings between two tabs, one with the primary settings with the other tab housing the more advanced setting.

Some other changes include -

by Conor at July 16, 2015 09:50 AM

July 15, 2015

rncbc.org

Summer'15 release frenzy pt.1 - QjackCtl 0.4.0 is out!


Hi all,

as in through the hottest of summers--as southerners can't even wait--here comes part one:

QjackCtl 0.4.0 (summer'15) is out!

though aside that everybody knows this already,

QjackCtl is a (maybe not so any more but) simple Qt application to control the JACK sound server, for the Linux Audio infrastructure.

website:
http://qjackctl.sourceforge.net
downloads:
http://sourceforge.net/projects/qjackctl/files

Change-log:

  • Some windows fixes added (patch by Kjetil Matheussen, thanks).
  • Most advanced Setup/Settings are moved into new Setup/Advanced settings tab; limit range for the real-time priority setting, now having 6 as absolute minimum valid value (after patches by Robin Gareus, thanks).
  • A new top-level widget window geometry state save and restore sub-routine is now in effect (EXPERIMENTAL)
  • Delayed geometry setup for widget windows upon startup has been deprecated and scrapped altogether.
  • Setup/settings dialog tab is going into some layout changes; also got rid of old patchbay auto-refresh timer cruft, which was previously hidden/disabled.
  • New socket names are now automatically inferred from selected client names while on the Patchbay widget, Socket dialog.
  • Fixed for some strict tests for Qt4 vs. Qt5 configure builds.
  • German (de) translation update (by Guido Scholz, thanks).

License:

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

Enjoy && have a whole hotta Summer'15 fun!

Flattr this

by rncbc at July 15, 2015 05:30 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] QjackCtl 0.4.0 is out!

Hi all,

as in through the hottest of summers--as southerners can't even
wait--here comes part one:

QjackCtl 0.4.0 (summer'15) is out!

though aside that everybody knows this already,

QjackCtl is a (maybe not so any more but) simple Qt [3] application
to control the JACK [2] sound server, for the Linux Audio infrastructure.

website:
http://qjackctl.sourceforge.net

downloads:
http://sourceforge.net/projects/qjackctl/files

- source tarball:
http://download.sourceforge.net/qjackctl/qjackctl-0.4.0.tar.gz

- source package:

http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.src.rpm

- binary packages:

http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.i586.rpm

http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.x86_64.rpm


Change-log:
- Some windows fixes added (patch by Kjetil Matheussen, thanks).
- Most advanced Setup/Settings are moved into new Setup/Advanced
settings tab; limit range for the real-time priority setting, now having
6 as absolute minimum valid value (after patches by Robin Gareus, thanks).
- A new top-level widget window geometry state save and restore
sub-routine is now in effect (EXPERIMENTAL)
- Delayed geometry setup for widget windows upon startup has been
deprecated and scrapped altogether.
- Setup/settings dialog tab is going into some layout changes; also got
rid of old patchbay auto-refresh timer cruft, which was previously
hidden/disabled.
- New socket names are now automatically inferred from selected client
names while on the Patchbay widget, Socket dialog.
- Fixed for some strict tests for Qt4 vs. Qt5 configure builds.
- German (de) translation update (by Guido Scholz, thanks).

License:
QjackCtl stands free, still open-source software, distributed under
the terms of the GNU General Public License (GPL [4]) version 2 or later.


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

See also:
http://www.rncbc.org/drupal/node/912


References:

[1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface
http://qjackctl.sourceforge.net

[2] JACK Audio Connection Kit
http://jackaudio.org

[3] Qt framework, C++ class library and tools for
cross-platform application and UI development
http://qt.io/

[4] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html


Enjoy && have a whole hot'ta Summer'15 fun!
--
rncbc aka. Rui Nuno Capela

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

by rncbc.org at July 15, 2015 03:16 PM

[LAA] 2nd Annual Web Audio Conference - submissions now open


The 2nd Web Audio Conference (WAC) will be held April 4-6, 2016 at Georgia Tech in Atlanta.

WAC is an international conference dedicated to web audio technologies and applications. The conference welcomes web developers, music technologists, computer musicians, application designers, researchers, and people involved in web standards. The conference addresses research, development, design, and standards concerned with emerging audio-related web technologies such as Web Audio API, Web RTC, WebSockets and Javascript. It is open to industry engineers, R&D scientists, academic researchers, artists, and students. The first Web Audio Conference was held in January 2015 at IRCAM and Mozilla in Paris, France.

The Internet has become much more than a simple storage and delivery network for audio files, as modern web browsers on desktop and mobile devices bring new user experiences and interaction opportunities. New and emerging web technologies and standards now allow applications to create and manipulate sound in real-time at near-native speeds, enabling the creation of a new generation of web-based applications that mimic the capabilities of desktop software while leveraging unique opportunities afforded by the web in areas such as social collaboration, user experience, cloud computing, and portability. The Web Audio Conference focuses on innovative work by artists, researchers, and engineers in industry and academia, highlighting new standards, tools, APIs, and practices as well as innovative web audio applications for musical performance, education, research, collaboration, and production.

Contributions to the second edition of the Web Audio Conference are encouraged in the following areas:

- Web Audio API, Web MIDI, Web RTC, and other existing or emerging web standards for audio and music
- Development tools, practices, and strategies of web audio applications
- Innovative audio and music based web applications
- Client-side audio processing (real-time or non real-time)
- Audio data and metadata formats and network delivery
- Server-side audio processing and client access
- Client-side audio engine and audio rendering
- Frameworks for audio synthesis, processing, and transformation
- Web-based audio visualization and/or sonification
- Multimedia integration
- Web-based live coding environments for music
- Web standards and use of standards within audio based web projects
- Hardware and tangible interfaces in web applications
- Codecs and standards for remote audio transmission
- Any other innovative work related to web audio that does not fall into the above categories

We welcome submissions in the following tracks: paper, poster, demo, performance, and artwork. All submissions will be single-blind peer reviewed. The conference proceedings, which will include both papers (for papers and posters) and abstracts (for demos, performances, and artworks), will be published online in SmartTech, Georgia Tech?s archival open-access repository.

*Papers*: Submit a 4-6 page paper to be given as an oral presentation.

*Talks*: Submit an abstract to be given as an oral presentation.

*Posters*: Submit a 2-4 page paper to be presented at a poster session.

*Demos*: Submit an abstract to be presented at a hands-on demo session. Demo submissions should include a title, a one-paragraph abstract and a complete list of technical requirements (including anything expected to be provided by the conference organizers).

*Performances*: Submit a performance making creative use of web-based audio applications. Performances can include elements such as audience device participation, web-based interfaces, WebMIDI, WebSockets, and/or other imaginative approaches to web technology. Submissions must include a title, a one-paragraph abstract of the performance, a link to video documentation of the work, a complete list of technical requirements (including anything expected to be provided by conference organizers), and names and one-paragraph biographies of all musicians involved in the performance.

*Artworks*: Submit a sonic web artwork or interactive application which makes significant use of web audio standards such as Web Audio API or WebMIDI in conjunction with other technologies such as HTML5 graphics, WebGL, and/or interactivity. Works must be suitable for presentation on a computer kiosk with headphones. They will be featured at the conference venue throughout the conference and on the conference web site. Submissions must include a title, one-paragraph abstract of the work, a link to access the work, and names and one-paragraph biographies of the author(s).

*Tutorials*: If you are interested in running a tutorial session at the conference, please contact the organizers directly (webaudio at gatech dot edu).


*IMPORTANT DATES*
- October 1, 2015: submission deadline
- December 1, 2015: author notification
- March 1, 2016: camera-ready papers and abstracts due
- April 4-6, 2016: conference

At least one author of each accepted submission must register for and attend the conference in order to present their work.

*SUBMISSION TEMPLATES AND SUBMISSION SYSTEM*
Submission templates are available on the conference web site at http://webaudio.gatech.edu/node/22

The submission system is open at https://cmt.research.microsoft.com/WAC2016/

by surrey.ac.uk at July 15, 2015 01:17 PM

linux.autostatic.com » linux.autostatic.com

CarPC v1.0

As our collection of MP3 CD's was wearing out I thought why not put a small embedded board with a big drive in our car? I dug up a Cubieboard2 that was gathering dust and started hacking. The goal:

  • Small system based on Debian Jessie
  • MPD to serve the audio files
  • Remote control via WiFi
  • Big drive
  • Acceptable boot time
  • Basic protection against file system corruption

Putting a bog standard Debian Jessie on the Cubieboard2 was quite straightforward with the help of the linux-sunxi.org wiki. The board booted with the standard kernel but unfortunately no sound. Luckily I had just received some ultra-cheap PCM2704 USB audio interfaces and these worked and sounded great too. WiFi worked out of the box but the rtl8192cu driver of the 3.16 kernel for the Realtek RTL8192CU chipset has the tendency to quickly go into suspension and as this driver doesn't have any power management options I ended up with a hacky for loop in /etc/rc.local that pings all IP's in the DHCP range. I quickly dropped this iffy set-up as it just didn't work out that well and ended up using a DKMS based solution that made it possible to control power management of the WiFi dongle. Next hurdle was hostapd that stopped working with this alternative driver. But with the help of the hostapd-rtl871xdrv GitHub repo I managed to cook up a fully working hostapd Debian package.

Next up was the hard drive. I first tried a USB drive but the Cubieboard2 just couldn't provide enough juice to power the drive properly together with the WiFi dongle. I also tried with my Raspberry Pi's but those had the same issues. So I had to resort to a SATA drive. Of course I bought a 3.5" drive first because those are cheaper. But you can't power a 3.5" drive with the SATA cable that comes with the Cubieboard2 and as I had a bit of a deadline I returned it for a 2.5" drive and that works like a charm. I installed MPD, copied my music collection to the hard drive, fired up MPD and was greeted with a segmentation fault. Apparently the Jessie MPD package has issues with the sticker database file so I installed MPD from the backports repo and that version runs without any complaints so far.

For some basic protection against corruption by sudden power loss I created separate partitions for /home and /var on the SD card that are mounted rw with a couple of options to reduce corruption (sync,commit=1,data=journal) and / is mounted ro, just like the big hard drive with the audio files. /tmp is being mounted as tmpfs in RAM. Boot time is about 15 seconds and I'm OK with that. To remotely shut down the CarPC via WiFi I use a JuiceSSH homescreen shortcut of a connection that runs a simple shutdown -h now snippet.

After I had mounted everything in our car the thing wouldn't boot though. Swapped the 1A USB car adapter for a 2.1A version and then the CarPC came up properly. Installed MPDroid on my Nexus 5 to control MPD via WiFi and so far, so good!

Cubieboard2 based CarPC

Addendum

Sometimes the CarPC became unreachable via WiFi. The culprit was that the DHCP service (udhcpd) didn't always come up because it was sometimes started before hostapd. I fixed this by copying /var/run/systemd/generator.late/udhcpd.service to /etc/systemd/system/udhcpd-custom.service and adding hostapd.service to the After line and adding a Requires=hostapd.service line. I also added a [Install] stanza with the line WantedBy=multi-user.target. I then disabled udhcpd.service and enabled udhcpd-custom.service.

Addendum 2

Hostapd didn't always start flawlessly either so I copied /var/run/systemd/generator.late/hostapd.service to /etc/systemd/system/hostapd-custom.service and added sys-subsystem-net-devices-wlan0.device to the After and Wants lines. Also added an [Install] stanza, disabled hostapd.service and enabled hostapd-custom.service.

by Jeremy at July 15, 2015 01:07 PM

Libre Music Production - Articles, Tutorials and News

July 10, 2015

Libre Music Production - Articles, Tutorials and News

LMP Asks #10: An interview with Tobiasz Karoń, aka Unfa

This month we talk to Tobiasz Karoń, better known online as Unfa. Tobiasz's passion is electronic music and open source software. He creates music using GNU/Linux based systems and is a massive fan of ZynAddSubFX. His favourite distro is KXStudio and his favourite DAWs are LMMS and Ardour. LMMS for sequencing and synthesizing, Ardour for recording, editing and mastering.

by Conor at July 10, 2015 09:05 AM

July 09, 2015

Create Digital Music » open-source

This is MeeBlip anode limited edition: White Case, More Direct Control

whiteanode

We’re really proud of our MeeBlip anode synthesizer. It’s gotten some great reviews, and you’ve made some terrific music with it in a bunch of genres. It’s fully open source hardware, but you can get it out and play it right away even if it’s your first synth – as far as we know, it’s the first widely-available synthesizer hardware that can say that.

So, to celebrate anode, we’re bringing out a special limited edition for summer. As you’ve no doubt noticed, it comes in a new creamy white case. But the controls have been updated, too. People liked the wavetable mode so much, we’ve made that the default, so you can dial in a wide range of sounds from the front panel. And to give you blindingly-quick access to envelopes, there’s one knob for amplitude and one knob for decay. Sound performance has also been fine-tuned, so it’s even more responsive.

We’re only making 250 of these, hand numbering them, so once they’re gone, they’re gone. (The original anode will remain available, both direct and at worldwide dealers.)

Get yours here (ships worldwide, free shipping for the limited edition launch in North America):
MeeBlip anode limited edition

Or in Europe, via our dealer network.

I got to jam on dual anodes with the legendary Andreas Schneider and had an obscene amount of fun. (Thanks to the ever-prolific Synthtopia for featuring this video.) That’s Andreas on Jomox Xbase09 drum machine. I used a Future Retro Zillion as sequencer, which worked delightfully well once I learned to let go and embrace the Zillion’s generative way of thinking. Here’s the result:

Meeblip at SchneidersBuero from Andreas Schneider on Vimeo.

anodeangle

I’ll say this, too: I’ve been taking my anode wherever I play, even syncing it to Traktor and playing atop DJ sets. Because it’s so small, there’s never a second thought about whether you’ll have room. And while it seems like there aren’t a lot of knobs, we worked really hard to make sure the knobs you want are there. It’s been terrific to work with James Grahame the engineer/designer on this. And to our existing MeeBlip owners, do keep sending us music and videos and so on on our MeeBlip Facebook page or @meeblip on Twitter.

We’re fixing a whole bunch of stuff with MeeBlip and CDM’s webpages this summer, so thanks for your patience on that – I think you’ll really like what happens when it’s done, and you won’t have to wait too much longer. My apologies for having broken some things, but don’t hesitate to get in touch with James and me for anything you might need.

meeblip.com

The post This is MeeBlip anode limited edition: White Case, More Direct Control appeared first on Create Digital Music.

by Peter Kirn at July 09, 2015 06:10 PM

Libre Music Production - Articles, Tutorials and News

Helm synthesizer reaches Beta

Helm, a polyphonic synthesizer with realtime modulation feedback, has just reached beta stage. Helm is available in a number of forms, including a standalone client as well as being able to run as an LV2 plugin.

Helm has a subtractive synthesizer engine with three oscillators with 15 anti-aliased waveforms, cross modulation, 32 voice polyphony, a low-pass, high-pass, band-pass, notch, low-shelf, high shelf and all-pass filter.

by Conor at July 09, 2015 01:28 PM

July 07, 2015

Create Digital Music » Linux

Akai Launches New MPD Pad Series, with More Controls

MPD226_angle_1200x750_web

Akai is a name synonymous with pad controls, via their MPC. But the MPD line of controllers hasn’t gotten a lot of attention lately – until now.

Today, the company unveils a big update to the MPD line. The numbers are parallel to the MPD18, MPD26, and MPD32, but these are really new pad controllers. They remain inexpensive but add additional hands-on controls and features, as well as a redesign of the pad sensing that Akai says is “ultra-sensitive.” Sounds a bit like something condom packaging would say, but Akai’s flagship MPC Revolution has terrific pads, so I’ll forgive the marketing-speak for now and look forward to trying them.

The MPD26 and 32 had hands-on controls, and the MPD18 had … well, a fader. But now you get lots of controls on the whole lineup and a new step sequencer on the top-of-range MPD232.

Also, following a growing industry trend, the whole line is class-compliant, which means it can work with iOS (and Linux and Raspberry Pi and all that, too – and your laptop, without drivers).

Here’s the quick run-down. All have 16 pads, but they have different bank sizes so you can assign those 16 to a different number:

MPD218_ortho_1200x750_web

MPD218_rear_1200x750_web

MPD218: pads and rotaries
Assign 48 pads / 3 banks
18 rotary encoders / 3 banks
MPC Note Repeat, Full Level
16 presets
USB powered (all have USB, but it appears the other two require power supplies)

MPD226_ortho_1200x750_web

MPD226_rear_1200x750_web

MPD226
Assign 64 pads / 4 banks
4 faders
4 Q-Link knobs
4 Q-Link buttons
36 assignable controls
MPC Note Repeat, MPC Swing, 16 Level, Full Level and Tap Tempo
MIDI in and out jacks
Transport controls

MPD232_ortho_1200x750_web

MPD232_rear_1200x750_web

MPD232
64-part, 32-step sequencer
8 Q-Link faders
8 Q-Link knobs
8 Q-Link buttons
72 assignable controls / 3 banks
MPC Note Repeat, MPC Swing, 16 Level, Full Level and Tap Tempo
30 presets, including DAWs
MIDI in and out jacks

All of them
16 pads that are velocity- and pressure-sensitive
Software bundle with Ableton Live Lite and Sonivox sounds

And, of course, backlighting, because apparently there’s some new industry rule that everything must now light up all the time. Keyboards! Pads! Grids! DJ gear! I think the LEDs now have their own LEDs. But yes, you get that, too.

RGB on the 232 and 226; red backlighting on the 218.

More importantly, you get loads of editing options. Front-panel preset editing is possible, and there’s a Preset Editor. That helps fill a void left by the original M-Audio Trigger Finger, I think.

But that brings us to some confusion, InMusic. Because you’re adding pads to nearly everything you make, even across brands that aren’t Akai (like M-Audio and Alesis). M-Audio also makes the Trigger Finger Pro – which also has a step sequencer. What do these brands mean, exactly, given the similarities? Akai doesn’t resolve matters in the press release; before they introduce the product, they introduce “Akai Professional, a leading manufacturer of keyboards, mixers and production equipment for performers and recording artists.” For the record, that same description fits Alesis (exactly) and M-Audio (minus the mixers).

What I do see as potentially encouraging is that the MPD232 appears to improve on what the Trigger Finger Pro already did. The Trigger Finger Pro is great, but it’s a bit bulky, you don’t get faders for steps, and the pads are usable but not terrific. If the MPD232′s pads deliver, you could get that same step sequencing power in arguably a more usable interface and form factor – and more playable, too. So that’s one to watch.

What these are is relatively inexpensive. US$199 for the MPD218, $299 for the MPD226 and $399 for the MPD232 retail list – so cheaper than that street. If they’ve got the pads right, that sounds a good deal.

And they have each pad labeled “pad,” in case you are easily confused.

Looking forward to these, as having a pad controller that works with everything has some real appeal, nice as the integration of Push/Ableton and Maschine can be.

MPD218_detail1_1200x750_web

MPD226_detail1_1200x750_web

MPD232_detail1_1200x750_web

The post Akai Launches New MPD Pad Series, with More Controls appeared first on Create Digital Music.

by Peter Kirn at July 07, 2015 09:02 PM

July 04, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] x42-plugins-20150702


x42-plugins is a collection of cross platform LV2 audio/midi plugins,
currently featuring over 80 plugins from 11 repositories.

https://github.com/x42/x42-plugins
http://gareus.org/misc/x42-plugins/x42-plugins-20150702.tar.xz
(sha1sum d37977c1a07f6d1a46e673614a2be47881cc7bce)



Changes since the last release (20150530)

* All plugins
- now have LV2 required version numbers
- feature built-in documentation/description

Plugin descriptions are now 100% spec conform and survived
pedantic inspection by the LV2 high inquisitor (falkTX ['s script]).

There have been various small build-system and packaging tweaks reported
by distros in the wake of the previous release last month.
Many thanks to Jaromir Mikes (debian), Edgar Aichinger (openSuSe) and
Filipe Coelho (KXstudio).

Likewise portability has been further improved. While developed an
targeted at GNU/Linux, all plugins now on run reliably on all major OS
and support over 20 CPU architectures.
Thanks to Jean-Luc Nest, Chris Goddart and Harrisonconsoles for QA on
OSX and Windows.


* sisco.lv2 (Simple Scope)
- allow to vertically align individual channels

* meters.lv2 (Audio Signal Meters)
- EBUr128 GUI: improved drawing performance (partial exposure)
- new Bit Meter (inspired by bitmeter the jack app)
- scalable GUI for the 30band 1/3 oct spectrum analyzer
- drawing improvements for the Goniometer "dot" mode.

* midifilter.lv2
- fix some invalid ranges min <= default <= max.
- remove units from port-names, use lv2:unit

* OSC controllable standalone jack applications (simple LV2 host)
are now compiled and deployed by default for the following:
+ x42-eq (mono + stereo variant)
+ x42-tuna
+ x42-meter (collection of all meter.lv2)
+ x42-mixtri (mixer/trigger pre-processor)
(x42-scope was previously available as standalone jack app)

- incl man-pages and --osc-doc built-it doc
- possibility to set initial port-values
- featuring port latency compensation


For a complete list of changes, please see the individual repositories:

https://github.com/x42/balance.lv2
https://github.com/x42/convoLV2
https://github.com/x42/fil4.lv2
https://github.com/x42/meters.lv2
https://github.com/x42/midifilter.lv2
https://github.com/x42/mixtri.lv2
https://github.com/x42/nodelay.lv2
https://github.com/x42/onsettrigger.lv2
https://github.com/x42/sisco.lv2
https://github.com/x42/tuna.lv2
https://github.com/x42/xfade.lv2




Kudos to Fons Adriaensen, some of the DSP code goes back to him and he
provided very valuable feedback and advise throughout the development of
what became x42-plugins over the years.
Also to David Robillard who laid the LV2 groundwork and made portable
free audio-plugins a possibility in the first place.

Last but not least, many thanks to libremusicproduction.com and
libregraphicsworld.org for continued support and publicity.

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

by gareus.org at July 04, 2015 11:34 PM

[LAA] ZynAddSubFX 2.5.1

Hello All,

The 2.5.1 Release of ZynAddSubFX is now available.

This release is primarily a bug fixing release resolving issues
left in 2.5.0.
As such it's a recommended upgrade for anyone using 2.5.0 or anyone
who was cautious about upgrading from 2.4.4.

ChangeList:
- Add Colorized CMake Configuration
- Add PID option for jack
- Add OSC port option
- Add MIDI unlearn
- Add External UI Compilation
- Add Split Pitchbend
- Fix No Install NTK Build
- Fix Linker Issues
- Fix Presets/Copy/Paste
- Fix JACK Samplerate Check When JACK Isn't Running
- Remove Dump
- Remove Some Globals synth/uToB/bToU/etc
- Adjust BankUI Ascetic
- Other Misc Bug Fixes

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

Download:
https://sourceforge.net/projects/zynaddsubfx/files/zynaddsubfx/2.5.1/

Mailing List:
https://sourceforge.net/p/zynaddsubfx/mailman/

Forums:
http://www.kvraudio.com/forum/viewforum.php?fG

Bug/Feature Tracker:
https://sourceforge.net/p/zynaddsubfx/bugs/?source=navbar

IRC:
##zynaddsubfx on FreeNode

Enjoy and please report bugs,
--Mark McCurry

by gmail.com at July 04, 2015 07:33 PM

July 03, 2015

Create Digital Music » open-source

Wave Your Hands or Draw to Make Sounds, with OWOW – Kickstarter Deadline Approaches

“Instead of going to music school, I studied design.”

Wiggle, wob, drum, pads, and scan are new gestural instruments that seek to cut the distance between an idea, making a move with your body, and a sound. Think you could draw a doodle that expresses a sound? Wish you could just air-drum in that percussion line? Easier to wave your hand to describe a noise? These modular components let you do just that.

OWOW, the startup behind it, is nearing a funding goal on Kickstarter – but it’s not quite there, five days until the deadline. So now is the perfect time to go behind the scenes. Not satisfied with that demo video? We’ve got our own resident contributing design expert to head to the source and investigate – completing today’s three-part look at cutting-edge Dutch design startups from the town of Eindhoven.

From the edge of the Netherlands’ slick design scene, industrial designer and music technologist Arvid Jense joins CDM for a series of interviews with Eindhoven Music Startups.

Eindhoven music startups: OWOW

Pieter Jan Pieters is the founder of OWOW, the Omnipresent World Of Wizkids. After graduating Design Acadamy Eindhoven with the Sound On Intuition project (in which he explored movement and musical computer control) and an internship at Teenage Engineering, he’s starting to make his way with things like the Social Project and Booty Drum. Aiming to earn their marks as an independent design studio, OWOW is bringing out a new breed of intuitive MIDI controllers in early spring through Kickstarter. The first series will be brought out in credit-card and product format with an estimated price of €50 and €80. After this series, the same form-factor is planned to be extended for analog modules and digital effect. See their instagram for more pictures and videos.

10748180_1497140963885473_839310699_n

How did you come to make your product?

Everything started two years ago, when I graduated Design Academy Eindhoven where I made a series of musical instruments for which the goal was that they could be played intuitively, without the need for learning theory. A lot of people are making music with computer right now, so rather than translating an acoustic instrument like the piano to control the computer, I wanted to make instruments to play the computer. This resulted in a series of instruments, on which for instance, if you’d want a wavy sound, you could make wavy movements. If you’d tap your finger on the table, you’d trigger a sound. If you bend you finger you would bend a sound. You won’t have to learn any new movements, but you can use what you already know.

Click here to view the embedded video.

After graduation, I did a lot of projects for costumers. And now we’re working hard on our own products and are making good progress. Goal is to make a lot of small instruments. For instance our first product will be wob, which is a plug and play distance MIDI controller. There are similar products, but they are very DIY, you’ll have to build and program everything yourself, which is a huge leap for people who don’t understand those kind of things. But I wanted to give the magic of those DIY tools to everyone. Plug and play; your movements just create sounds.

We started making the wob with a high grade aluminum casing to make the product a beautiful as possible. But we’ve noticed that the product would become much more expensive. But as we wanted to keep the price low, we’ve chosen to make two variations: the full product with casing and just the bare circuit board in credit card format. This is still a high grade product, but we strip everything to its essence. You’ll get a 3d print file with it, so you can still print the casing if you want. For the young dudes want just the thing that matters, for the lowest price.

A lot of our friends who have been making a lot of music and who are touring, are constantly trying to bring their home studio. But it is difficult to take everything because a lot of instruments are heavy and take a lot of space. So we though the credit card format would not only look cool, but could be very practical when you have a wallet with six or seven different instruments in it. We want to have one product/form with a lot of different possibilities.

00_DVC

After the wob we’ll make a whole range of devices. For instance the wiggle, which changes sounds when you move it around its axes. The scan is an analog piano roll, with which you can scannotes you draw on pian. The drum triggers sounds by moving it in the air. And the pads has four drum pads or hot keys. These five are the first series which will come in the credit card format.

Why are you doing this?

This started from me being frustrated that everybody was saying that you need to be able to read music to be able to make music. I could play the drums, but not read music. I just want to make computer music more fun. But it started from a personal interest: this is what I would think is really cool. And apparently there are a lot of people who think similarly and are agreeing with my vision.

How will your instrument change music?

With DAW’s you work in sequencers where you draw in perfectly timed notes, but whether I do it or you do it, it will always sound the same. Already a lot of people start to deliberately shuffle or just-out-of-swing their notes to make everything sound more live. Our products will help bring more personality into the music, because the physical input is always just out-of tempo. Goal is that it will become more personal, with more feeling and more fun! That you’re not just sitting in front of your computer, but that you’re moving and playing. You won’t need to wear a robot suit or have to make huge movements, because the CRD’s and DVC’sare simple and direct.

Click here to view the embedded video.

What do you think design thinking brings to electronic instruments?

If you look at companies like apple, everything looks very slick, even at electronics level. I learned a lot at my internship at Teenage Engineering, because they have a lot of attention to details. So as the product started to go towards just being a bare circuit board, we focused on make just that visually very powerful. It can be both functional and beautiful. Together with Alex, our engineer, we’ve sat down to make the board. Not just to put a graphic on it, but to design it from the start. So then you’ll get things like the finger print at the wiggle, which doubles as an on/off switch. It could’ve just been a switch, but by bringing the functional and aesthetic together, exciting new solution arise.

I’m more focused on users, while engineers are focused on technology. Engineers like to make things more and more complex, while I like to keep things brutishly simple. A guitar is basically a bunch of strings you’re hitting. A drum is just a tensioned skin. A piano is just a key you’re pushing. It’s the simplicity of those instruments which make the musicians creative. The restrictions force you to explore all the ways in which you can use it. All the different options of electronic instruments make them so complex, that people will just choose for the basic settings, losing their resourcefulness. Our products just have one or two functions, that’s it; very specific little instruments, which allow you to explore your own creativity.

The design approach allows you to not always be forced to look for the latest and best technology, but to use those things which are available to the fullest. Some very simple sensors have a lot of possibilities which never have been explored. If you’re technology focused, you might want to develop your own sensors, but we want to check what is possible with this device. We are not the ones adding terms like ‘gesture controls’, while we know that doesn’t work musically. Our thing is stupid.

10808784_389703904529268_974349711_n

What are your future plans?

We will start production, grab all the money and start living on Hawaii. No, but seriously, after the first five, we will take a good look at which ones we’d want to make next. We’d like to bring out new ones regularly. Say every few months or half year there could be a new instrument. We want to bring our instruments to everyone, so we would like to see our instruments at every music store all over the world.

We have a number of musicians who we have given our products to use in their studios. We ask them to play and test them and give us feedback. Sometimes this will result in us adding functionality. One user basically hacked the wob, to be able to triggers sounds just by moving his hand over the device. After checking with other musicians, we added this. So by playing with the instrument, the functionality will develop. We discover new things. We might think something is cool, but only when we see people really using it, we discover the real value. We only put things on it which will be used. For instance, we were measuring the angle of your hand above the wob as an extra effect. But once we made it, we discovered it didn’t work for the users. It might have cost us two weeks, but if it doesn’t work like we want it to, we just remove it. So only playing and testing will get the product we want. You might have ten ideas, but eight of them might not work at all, but you’ll only discover that when you actually build it.

Why do you choose to be independent? How do you deal with investors?

I did not want investors, because then the projects will be about money, and that is not our main interest. We work for costumers for which we do apps, websites or advertisement campaigns. This funds our own work. The CRD series will be the pinnacle of our work on which we have had to give zero concessions, it is purely ours. We’ve extended our release date a few times, just because we thought we could still make it better. But if we would have had investors, there would quickly have been pressure of them to see a return on their investment. This product has to be completely ours, so we can stand on our own feet. We want to be a rebel who can do whatever he wants.

10919499_822913061088163_1414391950_n

Is your product Open-Source?

We doubt in how far we want to go open-source. We are making our casing files public so you can print them by yourself, but in code we are looking not to make everything public, but to give possibilities for making a different version. We want to find a balance. We sned to be able to live from this and avoid blatant copy-cats. We’re not making our products for DIYers, but we do want to create possibilities of the people wanting to tweak.

How is Eindhoven for you?

In a way we just stuck around here, as we went to school in this city. But Eindhoven is very good for giving people the space they need, like our studio here (Sectie C, gathering place for a lot of art and design companies). We were considering moving to Antwerp or Amsterdam, but Eindhoven is not bad at all. There is a lot of technological development and while the city doesn’t directly sponsor us, they do create good locations. We are right in between Antwerp and Amsterdam. Maybe because there is no that much to do in Eindhoven, we start working harder; there is a lot of distraction in the big cities and we might just spend our time in café’s and concert halls, here is just our work.

10958619_699066583525743_927515273_n

While we have a super musician we collaborate with in Eindhoven, others are for instance in London. So it doesn’t really matter where you are, in this age you can be anywhere in no time. If you want to meet to someone, you can just take the plane. We would pay four times as much for our space in a big city, while I’d rather spend that money on development.

There are not that many other musical instrument companies in the Netherlands thoguh, a few guitar pedal builders maybe. There is a lot of electronic music history in Eindhoven, but not much remains. There are a lot of DIY synthesizer builders, but I am not aware of anything major going on. But what I notice is that those people working on music products really do their own thing. Maybe in a few years a number of those will get successful and it might seem everything comes from here.

What is the future of music?

Everything will become more expressive. Things have been very serious, but now things will become more playful. In the past some guys just picked up some guitars and a drum kit and just hit it to create something cool. While now people are inside their computer, making music like a programmer. And I think a lot of companies are trying to bring back fun and playfulness. I’m not sure if it will happen, but that is what I want it to turn into. And if people, think it’s cool, we’ll get a stream of people, and otherwise we might have to wait some years.

#01_wob_crd

The post Wave Your Hands or Draw to Make Sounds, with OWOW – Kickstarter Deadline Approaches appeared first on Create Digital Music.

by Arvid Jense at July 03, 2015 12:18 PM

Inside the 18€ Lunchbox Synthesizer Kit with Unit Unlikely

Click here to view the embedded video.

18€ buys you this lunchbox-style synthesizer kit – and it’s just the thing to put together on your lunch break.

Unit Unlikely is a hardware startup working with simple parts to make accessible, fun instruments. And its founder joins our resident Dutch design expert to talk about what it’s like diving into the synth business for the first time – and where he might go.

It all continues our series from Eindhoven, NL. From the edge of the Netherlands’ slick design scene, industrial designer and music technologist Arvid Jense joins CDM for a series of interviews with Eindhoven Music Startups. Here he talks to Unit Unlikely.

Eindhoven music startups: Unit Unlikely

Tijs Duel is a master student at the Industrial Design faculty at Eindhoven University of Technology. Together with Sebastiaan de Monte, he makes the Lunchbox synthesizer with their company Unit Unlikely. The Lunchbox is sold as a kit for €18.

How did you come to make your product?

I received my first analog synthesizer as a gift after an internship at STEIM. This was the super cool Korg Monotribe. Suddenly a whole world of making sounds opened for me. Sebastiaan (de Monte) and I thought this was fascinating. But there were not a lot of other cheap synthesizers available for us to play around with. With this dissatisfaction we thought “what if we wouldn’t only make our own sounds, but even make our own instruments which make our own sounds? What could happen if extend the creative process that much?” So we started a company to see if we could make our own synthesizers; Unit Unlikely.

For this arose the Lunchbox; a synthesizer based on three 555 timers. It’s basically a do-it-yourself, analog synthesizer which fits into your pocket, with a 9v battery and a 3.5mm output. You play it with four knobs, two for tone control, one for tremolo and one for volume. Everything is enclosed in a cardboard box, which we think is important, because we want it to be a full instrument rather than just a bunch of electronics; you’ll have something to hold on to, instead of the nasty solder points on the bottom of the circuit board. We’ve got a lot of very positive reactions, so we wanted to explore the possibilities selling the Lunchbox. To keep production costs low, we decided to make kits out of it. It shouldn’t be just a soldering practice or a toy for some weird sounds, but we want people to play songs with it or that that they use it as input for their samplers.

dsc_0251

We started with the sale of single units at a Maker Faire. This went ok, but we saw that the task of soldering was a big holdback for people. We decided to give workshops, which turned out to be very popular. We gave workshops at for instance Dutch Design Week and for Serious Request, which were structurally sold out. In these workshops we teach people how to solder, after which they make the Lunchbox. When their synth is done, the participants circuit bend the instrument to get the whole sound making experience. If there is time left, they can hack the device by adding controls for the bends they found, so their synth will be completely personalized. (Someone modified the Lunchbox to be controlled with a sequencer.) People really like the workshops. The youngest participant was 7 and the oldest in his late 50s!

We want people to completely destroy the Lunchbox to get even more crazy sounds. The idea is that through the limitations of the instrument, it causes people to do even more interesting things; moving the borders of what is possible. Breaking down the Lunchbox and making it function in a completely different way would be the biggest honor we could have. It is our goal to have everybody building their own personal instruments.

edited all photov2

We’ve sold over 100 lunchboxes in six months. Maybe not a super huge amount, but it takes a lot of time to do everything by hand. Except for the circuit boards, we handle all the production ourselves; the design process, distribution, printing, cutting, sorting etc. Our process is now made for a small number of units, the advantage is that we can be flexible and won’t be stuck with big batches of products to sell. If we come up with improvements or if someone comes with a genius idea, we can immediately bring out a new version.

Some people are scared of making and soldering the Lunchbox, but we’ve made a manual, slowly and clearly explaining the process, so you can make it in one and a half hour. And you’ll enjoy the device for the rest of your life, so just try it.  For the people who want to buy a Lunchbox, we’re updating the website right now and are making video tutorials to demonstrate assembly. We are really happy with the people who mess around with it at home. Eventualy we hope to see artist such as Amon Tobin using the Lunchbox.

What do you think design thinking brings to electronic instruments?

The biggest difference is that someone who has studied electronics could do everything we did in half the time. But they would’ve chosen very different solutions. For instance, for the tremolo inside the Lunchbox, we’ve started making it by copying transistor based circuits like those in guitar pedals. But we felt like those were too complicated and had too many components. So we started looking for simpler methods to make a tremolo. What we found, is that we could just use the same timer as we use to generate our tones, to control a LED, which in turn shines on a light dependent resistor, modulating the sound. This also gives new possibilities for hacking, as you can now modify the sound by simply opening and closing the casing. In this way, our naivety gave us a creative solution which made the Lunchbox more interesting. It also lowered the price and amount of components, so this was an amazing solution for everyone.

We’ve started with zero knowledge about synthesizers and we went through that whole learning experience while making the Lunchbox. If you are an electronics expert making a kit, you might have forgotten the struggles of beginners of just understanding what you are making. So because we went through the same struggles as the people who will be building our synthesizers, the user basically experiences the joy of our journey of building a first synthesizer.

edit lunchbox af

What are your future plans?

Version two of the Lunchbox is currently in production. It’s made just a bit better than the first one, with different components, better alignment on the circuit board (so everything will make a lot more sense when soldering), the board is a bit more compact, it’s more beautiful because it’s black, and it has a breakout area (so you can put your hacks on the circuit board itself rather than hanging them in the air). We looked to what people were actually doing right and wrong, and we adjusted the manuals, circuit boards and components to make everything work better. It’s a growing process in getting feedback from users and making adjustments. But by doing the workshops, we have a lot of contact with our users. We feel like the Lunchbox is basically finished, there might be subtle changes, but we’re quite satisfied and proud with what we have now.

We are now starting development with Pim, who recently joined us,  for small amplifiers mainly for guitar and bass. A guitar amplifier kit, again in a cardboard box, weighing a kilogram, you build it yourself and it gives a bit of a tube sound. We’ve got the first prototypes and within now and March we should get the first circuit board samples. These can be pre-ordered through our website.

bentobox

Whether we will continue for a long time will depend on the amount of feasible ideas we’ll get. It is a difficult blend to find things which are producible on a small scale, but are accessible enough for people to pick up and cheap enough to buy. I would love to go to a bigger scale, but while I’m still at the university, we simply don’t have the time to do that. It is a dream to make synthesizers of which people will say “Do you have that one from Unit Unlikely? It’s the shit.” Or if some of our idols would make an album with our instrument.

Why do you choose to be independent? How do you deal with investors?

As we’re just students, we don’t have much money to invest, all the money we make, we put back into the company. We’re not losing anything, but we won’t get rich doing this. We just want to be able to throw our ideas into the world. We hope to inspire the analog synthesizer community, by making playing and building synthesizers available to younger people or at least people with a smaller wallet.

editblack2orange

Is your product Open-Source?

We’re working on it. The Lunchbox was based on the Atari Punk Console, so we won’t be able to patent it anyways. It’s a difficult balance how to make something open source so that we can teach people things, without people losing their need to buy something. We should find a way not to scare newcomers, because if you publish all schematics, people might think it’s not a finished product; That you really have to be a nerd to make it work.  We want to show that everybody, whatever skill level, can make it. That it’s a finished product. We want to show how we put our blood and sweat (not that many tears) into the company, and that we don’t do it for the money.  We buy and use a lot of open source things so we would love to make our product open source as well.

How is Eindhoven for you?

We’re bound here because we’re still in university. We don’t have an office; we build a lot at the university and at our own student rooms, which we rebuilt as a temporary workshop. There is a presence of an technology and music scene in Eindhoven. There are the Geluidsdrug electronic jam sessions, creating a great scene. Dutch Design Week is here of course. But I won’t say that these things are what keeps us in Eindhoven. At this point it is mostly a practical that we can’t just pack our bags and move to say Berlin. But it’s good to be here, a lot of friends and enough music around us.

dsc_0459

What is the future of music?

What I noticed is that analog synthesizers are getting more popular and smaller. Look at the Teenage Engineering OP-1. I think everything will become more portable. I like to see the lunchbox as an audio snack for on the road.

I secretly hope that smartphones will disappear as musical controllers, because I feel like they can never become real instruments. What I think is that will happen in the future is more blends between other arts, like dancing , painting, or new synths that might make music with nature. Electronics are very useful for closing gaps between disciplines. Because they are getting smaller, it becomes more easy to use them for all sorts of tasks. You can make whole new sounds and whole new ways of creating sounds. I could combine an accelerometer and a lunchbox on a spoon, and create a whole new experience of eating soup.

It’s not the question whether that is music, but to what are the new possibilities. It could take some time to hatch, but then we get truly new music. Designers and scientist will have to make the new tools for this first, and at some point artists will rise whom can make great new music with it. It is not that we are stuck now, but there is still a whole lot more to be gained. There are infinite sounds, but we can discover a whole lot that has not been heard. I am interested in moving away from the established norms. I think we’ll keep looking for new sounds. I’m excited for it!

The post Inside the 18€ Lunchbox Synthesizer Kit with Unit Unlikely appeared first on Create Digital Music.

by Arvid Jense at July 03, 2015 12:02 PM

Mold Sound with Tingle, a Music Controller That Looks Like Pin Art

Click here to view the embedded video.

It looks like Pin Art or Pinscreens – those moldable frames full of pins popularized in the 80s. But the result is something that lets you dig your hands into sound and musical structures in new ways. It looks expressive and, let’s be honest, really fun.

(For the research minded, there’s also a NIME report below.)

From the edge of the Netherlands’ slick design scene, industrial designer and music technologist Arvid Jense joins CDM for a series of interviews with Eindhoven Music Startups. Here’s his encounter with Nupky.

Eindhoven Music Startups: Nupky

Rhys Duindam is a graduated Industrial Designer from TU/e. Through Nupky, he is creating a tangible music controller which aims to bring back a the acoustic touch and feel to digital music creation. Inspired by a pinscreen, the Tingle will let you mold sounds with your hands or anything else. A release date is not yet available.

How did you come to make your product?

If you look at most digital music gear it uses sliders, knob and buttons to control sound. These were basically the only available interface elements at the time synthesizers were developed. But because of this, we have lost most of the acoustic qualities of music instruments. Digital instruments have their own strengths, but the acoustic experience of a piano or guitar is priceless. With Tingle I am trying to recapture that acoustic experience in electronic instruments.

Most of the product I developed myself, but how I got there was through the help of my coach Hans Leeuw. He pointed me towards the right sources and pushed me to continue Tingle rather than moving on to a new project. For this I am grateful.

Tingle consists of:

  • pressure sensitive pins (which are spring loaded so that they push back on your fingers)
  • an accelerometer (to detect things like shakes and thereby create whammy bar-like effects)
  • and vibration motors (so you feel what’s happening with the sound, a bit like the vibrations in the body of an acoustic guitar against your own body).

What I want is for a Tinglist to have a specific role in a band. For example; the soundscape player of the band. This would be lost if I would make Tingle an all-in-one device. So I am orchestrating specific software synthesizers to be made, which the Tingle then controls. We might add MIDI control later as a secondary function, once all the control subtlety has been brought in.

Tingle

It can certainly be interesting to combine all components of music under one controller, like DJ’s have it, but then that would be the specific characteristic of that controller. But if a player wants to be in control of a specific role in the song composition (like a guitarist would), you’re going to feel very limited. Personally I think that more digital instruments should find their specific sound/play character.

A good example is Ableton Push. It might initially look like it is just a grid of buttons, but it is very well thought out. There is a specific character with which it integrates with the software, so that music production finally feels like you are playing a musical instrument again, and not controlling variables. I think this is a huge step into the right direction.

What are your future plans?

There is no fixed deadline to the release Tingle, but we hope to make the five looks-like feels-like prototypes with a synthesizer within a month. These will be fully functional and will be given to a number of musicians to see what can still be improved before Tingle goes into production. Hopefully before the end of the year I can sell the first units. But things always take more time than you would expect, so who knows it might be next summer.

I want to sell Tingle for about €400. It should be a lot cheaper than specialty controllers like the Haaken Continuum, and more in the price range of a multi-effects pedal, because I want everybody to be able to use it. But first I have some hurdles to conquer before that is possible. The biggest issue right now is that each Tingle needs 512 pins. For 5000 tingles, that would mean we have to make over 2.5 million pins, put springs on each pin and insert them into Tingles. It takes a lot manual labor to do this.

In the meantime, we are looking at different mappings of the grid to sound; be it zoned or more blob/molding-like. We hope to be able to switch from a sound-building mode to a sound-playing mode. In build mode, you’ll be able to mold the synthesis parameter with your hands, and following this you can play your sounds in play mode. So if you want to switch to a solo sound, you just have to remember the shape to play it.

Mark IJzerman is one of the sound designers working with me on Tingle. He made the very first soundscape for Tingle, which at that time was a plugin for Ableton in which you had a grid that was coupled to a musical scale. This meant that wherever you pushed, you got a bunch of complementary notes and that always sounded good. This was important as a demo because we wanted to show that everyone could make great sounds with Tingle.

Mark is now working with Andreas Lo-A-Njoe, our sound programmer, to transform everything you do with Tingle into directly logical sounds. So that you feel like you are getting the sounds you intended; such as subtle sounds when you use the tips of your fingers or bombastic sounds when you push your full hand into it with force. This very likely would mean that we will step away from the grid mechanic, as it is too static for such a dynamic interface as Tingle.

Diemo Swarz, researcher / developer at IRCAM, modified CataRT for Tingle. CataRT is a software he wrote which splits a sample into many grains, and then places similar grains next to each other in a 2D grid (much like the pins are oriented on Tingle). So when you press somewhere in Tingle, you will get a group of sounds which all sound similar. For example, a sample of fire crackling will make it feel like you can really play and control fire. Super cool stuff.

Click here to view the embedded video.

The creative team Ethno Tekh, from Melbourne, is also writing something for Tingle using their own granular synthesizer – Grain Plane. With this it will feel like you are playing moving echo’s. Really great stuff.

But this is only in music. Since Tingle is a sensor, it is a tool. It can be used for anything that takes queues from a computer. I know I will be working on some VJing applications in the near future.

Why are you doing this?

It might sound silly, but one of my main motivators was seeing that a lot of [industrial design] student projects just stay as ideas. A lot of people have had super awesome concepts, which just died. So I felt like we needed role-models who succeed in bringing their projects to market. And I must admit, by doing it I understand why it doesn’t happen more often; it’s just really difficult.

It’s difficult because what I’m doing is what they call a boot-strapped startup, which basically means you’ve got no money at all. You have to manage everything yourself. I’ve invested more than €18.000 into Tingle up until now, which is paid for by teaching, making videos and doing other jobs on the side. The only things I pay for are food and rent. And everything else goes into my company.

9

Next to this, my vision is about helping people with their self-esteem through playful and magical interactions. I used to be very introverted and nerdy. I was bullied and had terrible self-esteem. Over the years I got past this, but when I look back, I think, why did I live like this? Most people suffer from self-esteem, and this holds them back. So many people with great talent, who underestimated themselves, never fulfill their potential. Design is just my medium, through which I hope to show people that they are better than they know.  I like to quote Edmund Burke: “The only thing necessary for the triumph of evil is for good men to do nothing.”

What do you think design thinking brings to electronic instruments?

When I look at the electrical engineers, I really feel like I’m not smart enough. Engineers are really smart people. But my focus is on the beauty of interaction, on the ways people use things. Engineers have a talent with programming and building the most fantastic and crazy technological things, but quite often these things miss the human aspect. Some even embrace non-humanness. For instance I recently saw an instrument which had a body frame with connected gloves, arms, head, going all around the body. Which is cool! But most people in the world are not looking forward to putting on a robot suit to play music. Engineers often work from what is possible, “yes this is possible and this and that”, while a designer will say “Why this? And why that?”.  I guess that is the difference.

But I think a lot of designers can be a bit arrogant, thinking our way is the Holy Grail to save the world. Bullshit. It’s through partnerships of different people that you get truly awesome things. Put aside the ego. Technical people make crazy innovations, we designers bring the human aspects to technology and business people ensure that those things succeed in the real world.

Tingle (1)

How do you deal with investors?

I wanted to start with a Kickstarter, but I didn’t feel confident that I could get enough people interested in a short time.  It’s not like people stumble upon your Kickstarter and spontaneously decide to invest. It’s only when two thirds of your project is funded that it gets traction. And at the time I tought, I’m no salesman. I’m a designer and an inventor.

So to ensure the project arrives on the market, I’m now working with Ad van Berlo and Joost van Dijk to fine-tune the product and business. Joost will help with the business plan and negotiations, Ad will get Tingle manufacture ready, and I will take care of the experience, service and vision.

To prepare for this, we teamed up with two young entrepreneurs (FRANS prototyping) to developed a new sensor for Tingle; and these guys are wunderkinds. They’ve transformed the old sensor I’ve developed into something six times faster, making it zero latency, having a 100% improvement in signal-noise reduction, and removing a lot of the earlier bugs. Also our two sound designers Mark IJzerman and Andreas Lo-A-Njoe are hard at work!

7

Is your product Open-Source?

I’ve gotten a patent on the technology of the Tingle; which takes a lot time & money and I don’t really agree with the principle, but I need it as a negotiation tool. I would like to let my patent be open to use for experimentation and the furtherment of knowledge, but malicious companies who just want to copycat my product also need to be considered.

All in all I’m a big supporter of open-source technology. All software will be published as open max/msp or puredate objects, so users can make their own patches with it. The danger however when making open-source products is that I won’t get a return on my investment, so I won’t be able to continue making more products like this. I’m still figuring out how to do this correctly. I might need to find a job on the side. I always choose for my vision over money, but at some point money will become an issue towards that vision.

Together with Diemo Schwarz  and Hans Leeuw, I’m writing a paper for NIME. In the article I explain all the design and technical aspects of Tingle; how it works and how you can build it yourself. All theories of giving electronic instruments more acoustic properties are also discussed. Basically a summary of the one and a half years of knowledge I’ve gained on this project so other people can also make use of it.

I publish it because I want to see the things made by the crazy genius of technology savvy people who can take my ideas to a level which I can’t reach. I believe in the power of many, and the more people who have access to a technology, the more interesting the results will be. To keep this alive I will be making a website on which you can share the creations you make with the Tingle, whether it is a soundscape or a VJ controller. Should be great!

How is Eindhoven for you?

I’ve often considered other places. In fact, just after graduating I wanted to go to San Francisco, just for skateboarding and the sun. The Dutch weather doesn’t really match with my sports passion. I stayed because I have a great network in Eindhoven. The Dutch government supports young companies decently and Eindhoven is quite often seen as a next technological world center. We’ve got all creative and skilled people around us.  I’ve joined the Designers collective DOK.PUNT and I could 100% recommend joining a collective like this if you are an independent designer. Because this way you will always have people around you to discuss ideas with, or find out things if you don’t know the answer, and this actually happens constantly.

Eindhoven is also crazy full of starting companies; you can feel the energy in the air like electricity. There is a bubble of creative energy here which will explode at some day. OWOW and LunchBox synths are some of the other people making instruments here in Eindhoven. So there is always someone to spar with.

shop1web

What is the future of music?

We can break our need for traditional instruments now, because we as generation Y have grown up with technology. We fight for our individuality, and we are constantly looking to the future. There are a lot of artists also looking for new ways to make their style unique. So I don’t think it’ll be a problem for new instruments to be accepted. But we do have to take care that it won’t become a gadget economy. A box with sixteen knobs and samples won’t be enough anymore. The objects will have to become real musical instruments, which allow you to use a range of skills to make music.

Tingle has the advantage in this because it a ‘wanna-have’ object; you just want to touch it. Some children at a demo recently were playing with Tingle for at least half an hour whilst telling their parents that they would rather have a Tingle than an iPad for Christmas. A pretty good indication I would say that they liked it.

Tingle at NIME

Tingle was a featured presentation at this year’s international New Instruments for Musical Expression (NIME) conference, held a few weeks ago at Louisiana State University in the USA. The project is available as part of the NIME proceedings (with a free PDF) if you care to learn more:

Tingle: A Digital Music Controller Re-Capturing the Acoustic Instrument Experience

Rhys Duindam, Nupky, Eindhoven University of Technology,
Diemo Schwarz, ISMM team, Ircam–CNRS–UPMC
Hans Leeuw, Electrumpet, University of the Arts Utrecht, University of Huddersfield

The post Mold Sound with Tingle, a Music Controller That Looks Like Pin Art appeared first on Create Digital Music.

by Arvid Jense at July 03, 2015 12:00 PM

July 01, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] ANNOUNCEMENT: csound.node integrates Csound with HTML5

Please pardon cross-posting. I am pleased to announce the availability of
csound.node. This addon for NW.js implements the complete integration of
Csound and HTML5 on desktop platforms. It has been tested on WIndows and
Linux.

The same capabilities are available in current versions of CsoundQt and
Csound for Android, but csound.node is easier to build and supports the
development of standalone applications such as sound art and computer music
installations, visual music pieces, self-contained interactive
compositions, kiosk-type applications, and so on.

For for more information, including build instructions and configuration,
see https://github.com/csound/csound/tree/develop/frontends/nwjs.

Prebuilt binaries and examples are available in the Windows installer at
http://sourceforge.net/projects/csound/files/csound6/Csound6.05/Setup_Csound6_6.05.3beta.exe/download
(this still requires installing NW.js and some configuration). On other
platforms, building csound.node should be simple.

A version of this Windows installer with all VST features of Csound enabled
(Cabbage, vst4cs for hosting VST plugins in Csound, and CsoundVST) will
soon be available on my Web site, http://michaelgogins.tumblr.com.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

by gmail.com at July 01, 2015 08:39 PM

June 29, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] OSC2MIDI Version 0.2.1 Released

With many many bugfix and improvement patches from Albert Graef, it's time
for a new release! We absolutely recommend updating to take advantage of
the new features.

Notable improvements include:
-OSC messages can now "remember" variable values when an incoming MIDI
message only contains part of the data (i.e.converting 2 different CCs to
an OSC message for an XY controller)
-MIDI values are now limited if they attempt to exceed max or below min
-better handling of "exotic" types like 'm'
-more consistent printing formatting in verbose mode
-better feedback on parse errors in mapping files
-inclusion of maps for all the default interfaces of touchOSC
-project move to github
-sundry bugfixes

Please download and give it a try:
https://github.com/ssj71/OSC2MIDI/releases
(note the link has changed since last release)

Enjoy!
_Spencer Jackson

by gmail.com at June 29, 2015 04:33 PM

June 27, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Ardour 4.1 released

The Ardour project is pleased to announce the release of version 4.1.

Full details of the new features, fixes and so on can be found at:

https://community.ardour.org/node/8894

and the program can be downloaded as usual from

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

by linuxaudiosystems.com at June 27, 2015 11:20 PM

[LAA] OSC2MIDI Version 0.2.0 Released!

With many many bugfixes and improvements from Albert Graef, it's time for a
new release! We absolutely recommend updating to take advantage of these
new features.

Notable improvements include:
-OSC messages can now "remember" variable values when an incoming MIDI
message only contains part of the data (i.e.converting 2 different CCs to
an OSC message for an XY controller)
-MIDI values are now limited if they attempt to exceed max or below min
-better handling of "exotic" types like 'm'
-more consistent printing formatting in verbose mode
-better feedback on errors in mapping files
-inclusion of maps for all the default interfaces of touchOSC
-project move to github
-sundry bugfixes

Please download and give it a try:
https://github.com/ssj71/OSC2MIDI
<">https://sourceforge.net/projects/osc2midi/files/>
(note the link has changed since last release)

Enjoy!
Spencer Jackson

by gmail.com at June 27, 2015 10:22 AM

June 26, 2015

GStreamer News

GStreamer development release binary builds

Pre-built binary images of the 1.5.2 development release of GStreamer are now available for Windows 32/64-bit, iOS and Mac OS X and Android.

The builds are available for download from: Android, iOS, Mac OS X and Windows.

June 26, 2015 10:30 PM

Libre Music Production - Articles, Tutorials and News

Ardour 4.1 is released!

Ardour 4.1 has just been released. This release sees the addition of some interesting new features, along with the usual bug fixes.

Here's a rundown of some of the new features -

Input gain control - Audio and bus mixer strips now have an input gain control, allowing you to increase or attenuate the input signal by up to 20 dB.

by Conor at June 26, 2015 12:35 AM

June 25, 2015

ardour

Ardour 4.1 released

The Ardour project is pleased to announce the release of 4.1 with a great line-up of new features such as input gain control, Save As for projects, click-free changes to processor order and meter position, relative snapping, faster waveform rendering, Hi-DPI/Retina support and more! As usual, quite a few bugs have been mercilessly slayed. Encouragingly, we also have one of our longest ever contributor lists for this release.

read more

by paul at June 25, 2015 04:09 PM

June 24, 2015

GStreamer News

GStreamer Core, Plugins, RTSP Server, Python, Editing Services, Validate 1.5.2 development release

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

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

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

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

June 24, 2015 11:59 PM

June 23, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] Radium 3.1.3

Radium is a music editor with a new type of interface. It's inspired by
trackers, but uses graphics to show musical data.


Most important changes between 3.0 and 3.1.3:
* Many stability issues fixed
* Fixed automation
* Pianoroll
* Option to record MIDI line by line and monophonic in the MIDI menu. (as
before)
* Add options to multiply the number of lines to scroll by the "Edit lines"
value
* MIDI: Option to always record velocity
* A new sound object called "Midi Messages" which can be used to send MIDI
messages to other sound objects. Can for instance be used to send pitch
bend changes to VST plugins.
* Option to show line numbers instead of bars/beats
* Sort notes by pitch for same-positioned notes.
* VST: Fix for plugins using "main" instead of "VSTPluginMain".

by gmail.com at June 23, 2015 10:47 PM

June 18, 2015

Pid Eins

The new sd-bus API of systemd

With the new v221 release of systemd we are declaring the sd-bus API shipped with systemd stable. sd-bus is our minimal D-Bus IPC C library, supporting as back-ends both classic socket-based D-Bus and kdbus. The library has been been part of systemd for a while, but has only been used internally, since we wanted to have the liberty to still make API changes without affecting external consumers of the library. However, now we are confident to commit to a stable API for it, starting with v221.

In this blog story I hope to provide you with a quick overview on sd-bus, a short reiteration on D-Bus and its concepts, as well as a few simple examples how to write D-Bus clients and services with it.

What is D-Bus again?

Let's start with a quick reminder what D-Bus actually is: it's a powerful, generic IPC system for Linux and other operating systems. It knows concepts like buses, objects, interfaces, methods, signals, properties. It provides you with fine-grained access control, a rich type system, discoverability, introspection, monitoring, reliable multicasting, service activation, file descriptor passing, and more. There are bindings for numerous programming languages that are used on Linux.

D-Bus has been a core component of Linux systems since more than 10 years. It is certainly the most widely established high-level local IPC system on Linux. Since systemd's inception it has been the IPC system it exposes its interfaces on. And even before systemd, it was the IPC system Upstart used to expose its interfaces. It is used by GNOME, by KDE and by a variety of system components.

D-Bus refers to both a specification, and a reference implementation. The reference implementation provides both a bus server component, as well as a client library. While there are multiple other, popular reimplementations of the client library – for both C and other programming languages –, the only commonly used server side is the one from the reference implementation. (However, the kdbus project is working on providing an alternative to this server implementation as a kernel component.)

D-Bus is mostly used as local IPC, on top of AF_UNIX sockets. However, the protocol may be used on top of TCP/IP as well. It does not natively support encryption, hence using D-Bus directly on TCP is usually not a good idea. It is possible to combine D-Bus with a transport like ssh in order to secure it. systemd uses this to make many of its APIs accessible remotely.

A frequently asked question about D-Bus is why it exists at all, given that AF_UNIX sockets and FIFOs already exist on UNIX and have been used for a long time successfully. To answer this question let's make a comparison with popular web technology of today: what AF_UNIX/FIFOs are to D-Bus, TCP is to HTTP/REST. While AF_UNIX sockets/FIFOs only shovel raw bytes between processes, D-Bus defines actual message encoding and adds concepts like method call transactions, an object system, security mechanisms, multicasting and more.

From our 10year+ experience with D-Bus we know today that while there are some areas where we can improve things (and we are working on that, both with kdbus and sd-bus), it generally appears to be a very well designed system, that stood the test of time, aged well and is widely established. Today, if we'd sit down and design a completely new IPC system incorporating all the experience and knowledge we gained with D-Bus, I am sure the result would be very close to what D-Bus already is.

Or in short: D-Bus is great. If you hack on a Linux project and need a local IPC, it should be your first choice. Not only because D-Bus is well designed, but also because there aren't many alternatives that can cover similar functionality.

Where does sd-bus fit in?

Let's discuss why sd-bus exists, how it compares with the other existing C D-Bus libraries and why it might be a library to consider for your project.

For C, there are two established, popular D-Bus libraries: libdbus, as it is shipped in the reference implementation of D-Bus, as well as GDBus, a component of GLib, the low-level tool library of GNOME.

Of the two libdbus is the much older one, as it was written at the time the specification was put together. The library was written with a focus on being portable and to be useful as back-end for higher-level language bindings. Both of these goals required the API to be very generic, resulting in a relatively baroque, hard-to-use API that lacks the bits that make it easy and fun to use from C. It provides the building blocks, but few tools to actually make it straightforward to build a house from them. On the other hand, the library is suitable for most use-cases (for example, it is OOM-safe making it suitable for writing lowest level system software), and is portable to operating systems like Windows or more exotic UNIXes.

GDBus is a much newer implementation. It has been written after considerable experience with using a GLib/GObject wrapper around libdbus. GDBus is implemented from scratch, shares no code with libdbus. Its design differs substantially from libdbus, it contains code generators to make it specifically easy to expose GObject objects on the bus, or talking to D-Bus objects as GObject objects. It translates D-Bus data types to GVariant, which is GLib's powerful data serialization format. If you are used to GLib-style programming then you'll feel right at home, hacking D-Bus services and clients with it is a lot simpler than using libdbus.

With sd-bus we now provide a third implementation, sharing no code with either libdbus or GDBus. For us, the focus was on providing kind of a middle ground between libdbus and GDBus: a low-level C library that actually is fun to work with, that has enough syntactic sugar to make it easy to write clients and services with, but on the other hand is more low-level than GDBus/GLib/GObject/GVariant. To be able to use it in systemd's various system-level components it needed to be OOM-safe and minimal. Another major point we wanted to focus on was supporting a kdbus back-end right from the beginning, in addition to the socket transport of the original D-Bus specification ("dbus1"). In fact, we wanted to design the library closer to kdbus' semantics than to dbus1's, wherever they are different, but still cover both transports nicely. In contrast to libdbus or GDBus portability is not a priority for sd-bus, instead we try to make the best of the Linux platform and expose specific Linux concepts wherever that is beneficial. Finally, performance was also an issue (though a secondary one): neither libdbus nor GDBus will win any speed records. We wanted to improve on performance (throughput and latency) -- but simplicity and correctness are more important to us. We believe the result of our work delivers our goals quite nicely: the library is fun to use, supports kdbus and sockets as back-end, is relatively minimal, and the performance is substantially better than both libdbus and GDBus.

To decide which of the three APIs to use for you C project, here are short guidelines:

  • If you hack on a GLib/GObject project, GDBus is definitely your first choice.

  • If portability to non-Linux kernels -- including Windows, Mac OS and other UNIXes -- is important to you, use either GDBus (which more or less means buying into GLib/GObject) or libdbus (which requires a lot of manual work).

  • Otherwise, sd-bus would be my recommended choice.

(I am not covering C++ specifically here, this is all about plain C only. But do note: if you use Qt, then QtDBus is the D-Bus API of choice, being a wrapper around libdbus.)

Introduction to D-Bus Concepts

To the uninitiated D-Bus usually appears to be a relatively opaque technology. It uses lots of concepts that appear unnecessarily complex and redundant on first sight. But actually, they make a lot of sense. Let's have a look:

  • A bus is where you look for IPC services. There are usually two kinds of buses: a system bus, of which there's exactly one per system, and which is where you'd look for system services; and a user bus, of which there's one per user, and which is where you'd look for user services, like the address book service or the mail program. (Originally, the user bus was actually a session bus -- so that you get multiple of them if you log in many times as the same user --, and on most setups it still is, but we are working on moving things to a true user bus, of which there is only one per user on a system, regardless how many times that user happens to log in.)

  • A service is a program that offers some IPC API on a bus. A service is identified by a name in reverse domain name notation. Thus, the org.freedesktop.NetworkManager service on the system bus is where NetworkManager's APIs are available and org.freedesktop.login1 on the system bus is where systemd-logind's APIs are exposed.

  • A client is a program that makes use of some IPC API on a bus. It talks to a service, monitors it and generally doesn't provide any services on its own. That said, lines are blurry and many services are also clients to other services. Frequently the term peer is used as a generalization to refer to either a service or a client.

  • An object path is an identifier for an object on a specific service. In a way this is comparable to a C pointer, since that's how you generally reference a C object, if you hack object-oriented programs in C. However, C pointers are just memory addresses, and passing memory addresses around to other processes would make little sense, since they of course refer to the address space of the service, the client couldn't make sense of it. Thus, the D-Bus designers came up with the object path concept, which is just a string that looks like a file system path. Example: /org/freedesktop/login1 is the object path of the 'manager' object of the org.freedesktop.login1 service (which, as we remember from above, is still the service systemd-logind exposes). Because object paths are structured like file system paths they can be neatly arranged in a tree, so that you end up with a venerable tree of objects. For example, you'll find all user sessions systemd-logind manages below the /org/freedesktop/login1/session sub-tree, for example called /org/freedesktop/login1/session/_7, /org/freedesktop/login1/session/_55 and so on. How services precisely label their objects and arrange them in a tree is completely up to the developers of the services.

  • Each object that is identified by an object path has one or more interfaces. An interface is a collection of signals, methods, and properties (collectively called members), that belong together. The concept of a D-Bus interface is actually pretty much identical to what you know from programming languages such as Java, which also know an interface concept. Which interfaces an object implements are up the developers of the service. Interface names are in reverse domain name notation, much like service names. (Yes, that's admittedly confusing, in particular since it's pretty common for simpler services to reuse the service name string also as an interface name.) A couple of interfaces are standardized though and you'll find them available on many of the objects offered by the various services. Specifically, those are org.freedesktop.DBus.Introspectable, org.freedesktop.DBus.Peer and org.freedesktop.DBus.Properties.

  • An interface can contain methods. The word "method" is more or less just a fancy word for "function", and is a term used pretty much the same way in object-oriented languages such as Java. The most common interaction between D-Bus peers is that one peer invokes one of these methods on another peer and gets a reply. A D-Bus method takes a couple of parameters, and returns others. The parameters are transmitted in a type-safe way, and the type information is included in the introspection data you can query from each object. Usually, method names (and the other member types) follow a CamelCase syntax. For example, systemd-logind exposes an ActivateSession method on the org.freedesktop.login1.Manager interface that is available on the /org/freedesktop/login1 object of the org.freedesktop.login1 service.

  • A signature describes a set of parameters a function (or signal, property, see below) takes or returns. It's a series of characters that each encode one parameter by its type. The set of types available is pretty powerful. For example, there are simpler types like s for string, or u for 32bit integer, but also complex types such as as for an array of strings or a(sb) for an array of structures consisting of one string and one boolean each. See the D-Bus specification for the full explanation of the type system. The ActivateSession method mentioned above takes a single string as parameter (the parameter signature is hence s), and returns nothing (the return signature is hence the empty string). Of course, the signature can get a lot more complex, see below for more examples.

  • A signal is another member type that the D-Bus object system knows. Much like a method it has a signature. However, they serve different purposes. While in a method call a single client issues a request on a single service, and that service sends back a response to the client, signals are for general notification of peers. Services send them out when they want to tell one or more peers on the bus that something happened or changed. In contrast to method calls and their replies they are hence usually broadcast over a bus. While method calls/replies are used for duplex one-to-one communication, signals are usually used for simplex one-to-many communication (note however that that's not a requirement, they can also be used one-to-one). Example: systemd-logind broadcasts a SessionNew signal from its manager object each time a user logs in, and a SessionRemoved signal every time a user logs out.

  • A property is the third member type that the D-Bus object system knows. It's similar to the property concept known by languages like C#. Properties also have a signature, and are more or less just variables that an object exposes, that can be read or altered by clients. Example: systemd-logind exposes a property Docked of the signature b (a boolean). It reflects whether systemd-logind thinks the system is currently in a docking station of some form (only applies to laptops …).

So much for the various concepts D-Bus knows. Of course, all these new concepts might be overwhelming. Let's look at them from a different perspective. I assume many of the readers have an understanding of today's web technology, specifically HTTP and REST. Let's try to compare the concept of a HTTP request with the concept of a D-Bus method call:

  • A HTTP request you issue on a specific network. It could be the Internet, or it could be your local LAN, or a company VPN. Depending on which network you issue the request on, you'll be able to talk to a different set of servers. This is not unlike the "bus" concept of D-Bus.

  • On the network you then pick a specific HTTP server to talk to. That's roughly comparable to picking a service on a specific bus.

  • On the HTTP server you then ask for a specific URL. The "path" part of the URL (by which I mean everything after the host name of the server, up to the last "/") is pretty similar to a D-Bus object path.

  • The "file" part of the URL (by which I mean everything after the last slash, following the path, as described above), then defines the actual call to make. In D-Bus this could be mapped to an interface and method name.

  • Finally, the parameters of a HTTP call follow the path after the "?", they map to the signature of the D-Bus call.

Of course, comparing an HTTP request to a D-Bus method call is a bit comparing apples and oranges. However, I think it's still useful to get a bit of a feeling of what maps to what.

From the shell

So much about the concepts and the gray theory behind them. Let's make this exciting, let's actually see how this feels on a real system.

Since a while systemd has included a tool busctl that is useful to explore and interact with the D-Bus object system. When invoked without parameters, it will show you a list of all peers connected to the system bus. (Use --user to see the peers of your user bus instead):

$ busctl
NAME                                       PID PROCESS         USER             CONNECTION    UNIT                      SESSION    DESCRIPTION
:1.1                                         1 systemd         root             :1.1          -                         -          -
:1.11                                      705 NetworkManager  root             :1.11         NetworkManager.service    -          -
:1.14                                      744 gdm             root             :1.14         gdm.service               -          -
:1.4                                       708 systemd-logind  root             :1.4          systemd-logind.service    -          -
:1.7200                                  17563 busctl          lennart          :1.7200       session-1.scope           1          -
[…]
org.freedesktop.NetworkManager             705 NetworkManager  root             :1.11         NetworkManager.service    -          -
org.freedesktop.login1                     708 systemd-logind  root             :1.4          systemd-logind.service    -          -
org.freedesktop.systemd1                     1 systemd         root             :1.1          -                         -          -
org.gnome.DisplayManager                   744 gdm             root             :1.14         gdm.service               -          -
[…]

(I have shortened the output a bit, to make keep things brief).

The list begins with a list of all peers currently connected to the bus. They are identified by peer names like ":1.11". These are called unique names in D-Bus nomenclature. Basically, every peer has a unique name, and they are assigned automatically when a peer connects to the bus. They are much like an IP address if you so will. You'll notice that a couple of peers are already connected, including our little busctl tool itself as well as a number of system services. The list then shows all actual services on the bus, identified by their service names (as discussed above; to discern them from the unique names these are also called well-known names). In many ways well-known names are similar to DNS host names, i.e. they are a friendlier way to reference a peer, but on the lower level they just map to an IP address, or in this comparison the unique name. Much like you can connect to a host on the Internet by either its host name or its IP address, you can also connect to a bus peer either by its unique or its well-known name. (Note that each peer can have as many well-known names as it likes, much like an IP address can have multiple host names referring to it).

OK, that's already kinda cool. Try it for yourself, on your local machine (all you need is a recent, systemd-based distribution).

Let's now go the next step. Let's see which objects the org.freedesktop.login1 service actually offers:

$ busctl tree org.freedesktop.login1
└─/org/freedesktop/login1
  ├─/org/freedesktop/login1/seat
  │ ├─/org/freedesktop/login1/seat/seat0
  │ └─/org/freedesktop/login1/seat/self
  ├─/org/freedesktop/login1/session
  │ ├─/org/freedesktop/login1/session/_31
  │ └─/org/freedesktop/login1/session/self
  └─/org/freedesktop/login1/user
    ├─/org/freedesktop/login1/user/_1000
    └─/org/freedesktop/login1/user/self

Pretty, isn't it? What's actually even nicer, and which the output does not show is that there's full command line completion available: as you press TAB the shell will auto-complete the service names for you. It's a real pleasure to explore your D-Bus objects that way!

The output shows some objects that you might recognize from the explanations above. Now, let's go further. Let's see what interfaces, methods, signals and properties one of these objects actually exposes:

$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/session/_31
NAME                                TYPE      SIGNATURE RESULT/VALUE                             FLAGS
org.freedesktop.DBus.Introspectable interface -         -                                        -
.Introspect                         method    -         s                                        -
org.freedesktop.DBus.Peer           interface -         -                                        -
.GetMachineId                       method    -         s                                        -
.Ping                               method    -         -                                        -
org.freedesktop.DBus.Properties     interface -         -                                        -
.Get                                method    ss        v                                        -
.GetAll                             method    s         a{sv}                                    -
.Set                                method    ssv       -                                        -
.PropertiesChanged                  signal    sa{sv}as  -                                        -
org.freedesktop.login1.Session      interface -         -                                        -
.Activate                           method    -         -                                        -
.Kill                               method    si        -                                        -
.Lock                               method    -         -                                        -
.PauseDeviceComplete                method    uu        -                                        -
.ReleaseControl                     method    -         -                                        -
.ReleaseDevice                      method    uu        -                                        -
.SetIdleHint                        method    b         -                                        -
.TakeControl                        method    b         -                                        -
.TakeDevice                         method    uu        hb                                       -
.Terminate                          method    -         -                                        -
.Unlock                             method    -         -                                        -
.Active                             property  b         true                                     emits-change
.Audit                              property  u         1                                        const
.Class                              property  s         "user"                                   const
.Desktop                            property  s         ""                                       const
.Display                            property  s         ""                                       const
.Id                                 property  s         "1"                                      const
.IdleHint                           property  b         true                                     emits-change
.IdleSinceHint                      property  t         1434494624206001                         emits-change
.IdleSinceHintMonotonic             property  t         0                                        emits-change
.Leader                             property  u         762                                      const
.Name                               property  s         "lennart"                                const
.Remote                             property  b         false                                    const
.RemoteHost                         property  s         ""                                       const
.RemoteUser                         property  s         ""                                       const
.Scope                              property  s         "session-1.scope"                        const
.Seat                               property  (so)      "seat0" "/org/freedesktop/login1/seat... const
.Service                            property  s         "gdm-autologin"                          const
.State                              property  s         "active"                                 -
.TTY                                property  s         "/dev/tty1"                              const
.Timestamp                          property  t         1434494630344367                         const
.TimestampMonotonic                 property  t         34814579                                 const
.Type                               property  s         "x11"                                    const
.User                               property  (uo)      1000 "/org/freedesktop/login1/user/_1... const
.VTNr                               property  u         1                                        const
.Lock                               signal    -         -                                        -
.PauseDevice                        signal    uus       -                                        -
.ResumeDevice                       signal    uuh       -                                        -
.Unlock                             signal    -         -                                        -

As before, the busctl command supports command line completion, hence both the service name and the object path used are easily put together on the shell simply by pressing TAB. The output shows the methods, properties, signals of one of the session objects that are currently made available by systemd-logind. There's a section for each interface the object knows. The second column tells you what kind of member is shown in the line. The third column shows the signature of the member. In case of method calls that's the input parameters, the fourth column shows what is returned. For properties, the fourth column encodes the current value of them.

So far, we just explored. Let's take the next step now: let's become active - let's call a method:

# busctl call org.freedesktop.login1 /org/freedesktop/login1/session/_31 org.freedesktop.login1.Session Lock

I don't think I need to mention this anymore, but anyway: again there's full command line completion available. The third argument is the interface name, the fourth the method name, both can be easily completed by pressing TAB. In this case we picked the Lock method, which activates the screen lock for the specific session. And yupp, the instant I pressed enter on this line my screen lock turned on (this only works on DEs that correctly hook into systemd-logind for this to work. GNOME works fine, and KDE should work too).

The Lock method call we picked is very simple, as it takes no parameters and returns none. Of course, it can get more complicated for some calls. Here's another example, this time using one of systemd's own bus calls, to start an arbitrary system unit:

# busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss "cups.service" "replace"
o "/org/freedesktop/systemd1/job/42684"

This call takes two strings as input parameters, as we denote in the signature string that follows the method name (as usual, command line completion helps you getting this right). Following the signature the next two parameters are simply the two strings to pass. The specified signature string hence indicates what comes next. systemd's StartUnit method call takes the unit name to start as first parameter, and the mode in which to start it as second. The call returned a single object path value. It is encoded the same way as the input parameter: a signature (just o for the object path) followed by the actual value.

Of course, some method call parameters can get a ton more complex, but with busctl it's relatively easy to encode them all. See the man page for details.

busctl knows a number of other operations. For example, you can use it to monitor D-Bus traffic as it happens (including generating a .cap file for use with Wireshark!) or you can set or get specific properties. However, this blog story was supposed to be about sd-bus, not busctl, hence let's cut this short here, and let me direct you to the man page in case you want to know more about the tool.

busctl (like the rest of system) is implemented using the sd-bus API. Thus it exposes many of the features of sd-bus itself. For example, you can use to connect to remote or container buses. It understands both kdbus and classic D-Bus, and more!

sd-bus

But enough! Let's get back on topic, let's talk about sd-bus itself.

The sd-bus set of APIs is mostly contained in the header file sd-bus.h.

Here's a random selection of features of the library, that make it compare well with the other implementations available.

  • Supports both kdbus and dbus1 as back-end.

  • Has high-level support for connecting to remote buses via ssh, and to buses of local OS containers.

  • Powerful credential model, to implement authentication of clients in services. Currently 34 individual fields are supported, from the PID of the client to the cgroup or capability sets.

  • Support for tracking the life-cycle of peers in order to release local objects automatically when all peers referencing them disconnected.

  • The client builds an efficient decision tree to determine which handlers to deliver an incoming bus message to.

  • Automatically translates D-Bus errors into UNIX style errors and back (this is lossy though), to ensure best integration of D-Bus into low-level Linux programs.

  • Powerful but lightweight object model for exposing local objects on the bus. Automatically generates introspection as necessary.

The API is currently not fully documented, but we are working on completing the set of manual pages. For details see all pages starting with sd_bus_.

Invoking a Method, from C, with sd-bus

So much about the library in general. Here's an example for connecting to the bus and issuing a method call:

#include <stdio.h>
#include <stdlib.h>
#include <systemd/sd-bus.h>

int main(int argc, char *argv[]) {
        sd_bus_error error = SD_BUS_ERROR_NULL;
        sd_bus_message *m = NULL;
        sd_bus *bus = NULL;
        const char *path;
        int r;

        /* Connect to the system bus */
        r = sd_bus_open_system(&bus);
        if (r < 0) {
                fprintf(stderr, "Failed to connect to system bus: %s\n", strerror(-r));
                goto finish;
        }

        /* Issue the method call and store the respons message in m */
        r = sd_bus_call_method(bus,
                               "org.freedesktop.systemd1",           /* service to contact */
                               "/org/freedesktop/systemd1",          /* object path */
                               "org.freedesktop.systemd1.Manager",   /* interface name */
                               "StartUnit",                          /* method name */
                               &error,                               /* object to return error in */
                               &m,                                   /* return message on success */
                               "ss",                                 /* input signature */
                               "cups.service",                       /* first argument */
                               "replace");                           /* second argument */
        if (r < 0) {
                fprintf(stderr, "Failed to issue method call: %s\n", error.message);
                goto finish;
        }

        /* Parse the response message */
        r = sd_bus_message_read(m, "o", &path);
        if (r < 0) {
                fprintf(stderr, "Failed to parse response message: %s\n", strerror(-r));
                goto finish;
        }

        printf("Queued service job as %s.\n", path);

finish:
        sd_bus_error_free(&error);
        sd_bus_message_unref(m);
        sd_bus_unref(bus);

        return r < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
}

Save this example as bus-client.c, then build it with:

$ gcc bus-client.c -o bus-client `pkg-config --cflags --libs libsystemd`

This will generate a binary bus-client you can now run. Make sure to run it as root though, since access to the StartUnit method is privileged:

# ./bus-client
Queued service job as /org/freedesktop/systemd1/job/3586.

And that's it already, our first example. It showed how we invoked a method call on the bus. The actual function call of the method is very close to the busctl command line we used before. I hope the code excerpt needs little further explanation. It's supposed to give you a taste how to write D-Bus clients with sd-bus. For more more information please have a look at the header file, the man page or even the sd-bus sources.

Implementing a Service, in C, with sd-bus

Of course, just calling a single method is a rather simplistic example. Let's have a look on how to write a bus service. We'll write a small calculator service, that exposes a single object, which implements an interface that exposes two methods: one to multiply two 64bit signed integers, and one to divide one 64bit signed integer by another.

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <systemd/sd-bus.h>

static int method_multiply(sd_bus_message *m, void *userdata, sd_bus_error *ret_error) {
        int64_t x, y;
        int r;

        /* Read the parameters */
        r = sd_bus_message_read(m, "xx", &x, &y);
        if (r < 0) {
                fprintf(stderr, "Failed to parse parameters: %s\n", strerror(-r));
                return r;
        }

        /* Reply with the response */
        return sd_bus_reply_method_return(m, "x", x * y);
}

static int method_divide(sd_bus_message *m, void *userdata, sd_bus_error *ret_error) {
        int64_t x, y;
        int r;

        /* Read the parameters */
        r = sd_bus_message_read(m, "xx", &x, &y);
        if (r < 0) {
                fprintf(stderr, "Failed to parse parameters: %s\n", strerror(-r));
                return r;
        }

        /* Return an error on division by zero */
        if (y == 0) {
                sd_bus_error_set_const(ret_error, "net.poettering.DivisionByZero", "Sorry, can't allow division by zero.");
                return -EINVAL;
        }

        return sd_bus_reply_method_return(m, "x", x / y);
}

/* The vtable of our little object, implements the net.poettering.Calculator interface */
static const sd_bus_vtable calculator_vtable[] = {
        SD_BUS_VTABLE_START(0),
        SD_BUS_METHOD("Multiply", "xx", "x", method_multiply, SD_BUS_VTABLE_UNPRIVILEGED),
        SD_BUS_METHOD("Divide",   "xx", "x", method_divide,   SD_BUS_VTABLE_UNPRIVILEGED),
        SD_BUS_VTABLE_END
};

int main(int argc, char *argv[]) {
        sd_bus_slot *slot = NULL;
        sd_bus *bus = NULL;
        int r;

        /* Connect to the user bus this time */
        r = sd_bus_open_user(&bus);
        if (r < 0) {
                fprintf(stderr, "Failed to connect to system bus: %s\n", strerror(-r));
                goto finish;
        }

        /* Install the object */
        r = sd_bus_add_object_vtable(bus,
                                     &slot,
                                     "/net/poettering/Calculator",  /* object path */
                                     "net.poettering.Calculator",   /* interface name */
                                     calculator_vtable,
                                     NULL);
        if (r < 0) {
                fprintf(stderr, "Failed to issue method call: %s\n", strerror(-r));
                goto finish;
        }

        /* Take a well-known service name so that clients can find us */
        r = sd_bus_request_name(bus, "net.poettering.Calculator", 0);
        if (r < 0) {
                fprintf(stderr, "Failed to acquire service name: %s\n", strerror(-r));
                goto finish;
        }

        for (;;) {
                /* Process requests */
                r = sd_bus_process(bus, NULL);
                if (r < 0) {
                        fprintf(stderr, "Failed to process bus: %s\n", strerror(-r));
                        goto finish;
                }
                if (r > 0) /* we processed a request, try to process another one, right-away */
                        continue;

                /* Wait for the next request to process */
                r = sd_bus_wait(bus, (uint64_t) -1);
                if (r < 0) {
                        fprintf(stderr, "Failed to wait on bus: %s\n", strerror(-r));
                        goto finish;
                }
        }

finish:
        sd_bus_slot_unref(slot);
        sd_bus_unref(bus);

        return r < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
}

Save this example as bus-service.c, then build it with:

$ gcc bus-service.c -o bus-service `pkg-config --cflags --libs libsystemd`

Now, let's run it:

$ ./bus-service

In another terminal, let's try to talk to it. Note that this service is now on the user bus, not on the system bus as before. We do this for simplicity reasons: on the system bus access to services is tightly controlled so unprivileged clients cannot request privileged operations. On the user bus however things are simpler: as only processes of the user owning the bus can connect no further policy enforcement will complicate this example. Because the service is on the user bus, we have to pass the --user switch on the busctl command line. Let's start with looking at the service's object tree.

$ busctl --user tree net.poettering.Calculator
└─/net/poettering/Calculator

As we can see, there's only a single object on the service, which is not surprising, given that our code above only registered one. Let's see the interfaces and the members this object exposes:

$ busctl --user introspect net.poettering.Calculator /net/poettering/Calculator
NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
net.poettering.Calculator           interface -         -            -
.Divide                             method    xx        x            -
.Multiply                           method    xx        x            -
org.freedesktop.DBus.Introspectable interface -         -            -
.Introspect                         method    -         s            -
org.freedesktop.DBus.Peer           interface -         -            -
.GetMachineId                       method    -         s            -
.Ping                               method    -         -            -
org.freedesktop.DBus.Properties     interface -         -            -
.Get                                method    ss        v            -
.GetAll                             method    s         a{sv}        -
.Set                                method    ssv       -            -
.PropertiesChanged                  signal    sa{sv}as  -            -

The sd-bus library automatically added a couple of generic interfaces, as mentioned above. But the first interface we see is actually the one we added! It shows our two methods, and both take "xx" (two 64bit signed integers) as input parameters, and return one "x". Great! But does it work?

$ busctl --user call net.poettering.Calculator /net/poettering/Calculator net.poettering.Calculator Multiply xx 5 7
x 35

Woohoo! We passed the two integers 5 and 7, and the service actually multiplied them for us and returned a single integer 35! Let's try the other method:

$ busctl --user call net.poettering.Calculator /net/poettering/Calculator net.poettering.Calculator Divide xx 99 17
x 5

Oh, wow! It can even do integer division! Fantastic! But let's trick it into dividing by zero:

$ busctl --user call net.poettering.Calculator /net/poettering/Calculator net.poettering.Calculator Divide xx 43 0
Sorry, can't allow division by zero.

Nice! It detected this nicely and returned a clean error about it. If you look in the source code example above you'll see how precisely we generated the error.

And that's really all I have for today. Of course, the examples I showed are short, and I don't get into detail here on what precisely each line does. However, this is supposed to be a short introduction into D-Bus and sd-bus, and it's already way too long for that …

I hope this blog story was useful to you. If you are interested in using sd-bus for your own programs, I hope this gets you started. If you have further questions, check the (incomplete) man pages, and inquire us on IRC or the systemd mailing list. If you need more examples, have a look at the systemd source tree, all of systemd's many bus services use sd-bus extensively.

by Lennart Poettering at June 18, 2015 10:00 PM

June 17, 2015

Libre Music Production - Articles, Tutorials and News

setBfree v0.8 is released!

Version 0.8 of setBfree, the DSP Tonewheel Organ emulator, has just been released. setBfree is designed to "imitate the sound and properties of the electromechanical organs and sound modification devices that brought world-wide fame to the names and products of Laurens Hammond and Don Leslie." setBfree is available as an LV2 plugin. There is also a JACK standalone version available.

by Conor at June 17, 2015 09:39 AM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] setBfree v0.8

G'day.

setBfree is a MIDI-controlled, software synthesizer designed to imitate
the sound and properties of the electromechanical organs and sound
modification devices that brought world-wide fame to the names and
products of Laurens Hammond and Don Leslie.


http://setbfree.org
https://github.com/pantherb/setBfree


It's been over 18 months since the last release and setBfree just
reached another major milestone: It now features a proper GUI that
allows to configure various aspects that have previously only been
accessible via text config files (the config and program file-format
itself has not changed). The GUI is available as LV2 and standalone jack
application and the old tcl/tk prototype UI was removed for good.

visit https://vimeo.com/130633814 for a demo.

The 2nd big change was reworking the Leslie: The horn now spins
counter-clockwise (same as the real thing) and we finally managed to
track down the aliasing noise that was audible during acceleration and
deceleration. Since various users play guitar and some even cello
through it, an animated LV2 GUI was added for the whirl-speaker
emulation and it has also been made available as standalone jack client.
Advanced settings such as microphone angle, position, horn radius, etc
are now also exposed (both for the organ as well as the LV2). The UI
looks like
https://raw.githubusercontent.com/pantherb/setBfree/master/doc/b_whirl.png

Other notable changes include new addition of presets for Kurzweil and
Korg CX3 and updates to portability (ARM-CPU/RPi, Windows + OSX
versions). The full list of over 300 changes since 0.7.5 is available as
git log.

Binaries for Intel platform, GNU/Linux, OSX and Windows are available
from https://github.com/pantherb/setBfree/releases/latest
though for Linux most distros will pick this up as usual.


Many thanks to Axel 'the C.L.A.' M?ller and Jean-Luc Nest who provided
valuable feedback and inspiring music during the development cycle.

happy playing,
robin + will
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

by gareus.org at June 17, 2015 03:11 AM

June 16, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Vamp plugin SDK v2.6 now available

Version 2.6 of the Vamp plugin SDK is now available.

http://www.vamp-plugins.org/

Vamp is a plugin API for audio analysis and feature extraction plugins
written in C or C++. Its SDK features an easy-to-use set of C++ classes
for plugin and host developers, a reference host implementation, example
plugins, and documentation. It is supported across Linux, OS/X, and
Windows.

A documentation guide to writing plugins using the Vamp SDK can be found
at http://www.vamp-plugins.org/guide.pdf.

Version 2.6 is a bugfix and minor enhancement release. For more details,
see the changelog at

http://code.soundsoftware.ac.uk/projects/vamp-plugin-sdk/repository/entry/CHANGELOG


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

by all-day-breakfast.com at June 16, 2015 02:14 PM

blog4

Notstandskomitee remix and concert Karlsruhe 18.6.

Notstandskomitee performs in Karlsruhe the 18.June 2015 at AKK on the festival Angewandte Elektronik TV, along with Circuit Noise, Blood Vault and Benoît & the Mandelbrots:
https://www.facebook.com/events/894729943926863/
http://www.akk.org

Just released is a remix for Bitemap from Barcelona which can be heard on Bandcamp:
https://bitemap.bandcamp.com

by herrsteiner (noreply@blogger.com) at June 16, 2015 01:07 AM

June 14, 2015

OpenAV

Sonar+D and MOD UIs

Sonar+D and MOD UIs

MOD and Sonar + D OpenAV will be attending the Sonar+D event in Barcelona with MOD. The Sonar event brings together people interested in “music creativity & technology” – and that’s pretty much exactly what MOD, OpenAV and Linux-Audio are about. Needless to say, I’m very excited about this! Anybody living in Barcelona interested in OpenAV stuff – email me… Read more →

by harry at June 14, 2015 07:30 PM

June 13, 2015

Hackaday » digital audio hacks

Update: Battlezone on Vector Display Step-by-Step

When we ran the story of Battlezone played on tube displays earlier this week there were immediately questions about recreating the hack. At the time the software wasn’t available, and there is also a bit of hardware hacking necessary to get the audio working. You asked and [Eric] from Tubetime delivered. He’s posted a pair of articles that show how to get an STM32F4 Discovery board to play the classic game, along with instructions to build the firmware.

The hardware hack in this case is untangling the pinout used on the discovery board. It seems that one of the lines needed to get sound working for this hack is tied to one of the two DACs. If you read the original coverage you’ll remember that both of the DACs are used to drive X and Y on the vector display. The image above shows a cut trace on the bottom of the board. You’ll then need to route that signal to an alternate pin by soldering a jumper wire from the chip to a resistor on the board.

This (as well as one other alteration that bridges two of the chip pins) is a great example of work you should be unafraid to do on your own dev boards. We’ve had to do it with the Launchpad boards to get at the functionality we needed. We’d like to hear your own epic stories of abusing dev boards to do your bidding. Let us know in the comments.


Filed under: digital audio hacks, Microcontrollers

by Mike Szczys at June 13, 2015 11:01 AM

June 11, 2015

Nothing Special

Using LV2 atom:Path (or how to get files safely in a plugin without a GUI)

The end of last month marked 2 years since my initial commit to my first lv2 plugins. I've learned some things, but still am picking up more little by little. I was recently reminded that I don't know it all, when falkTX pointed out another stupid mistake I'd been making that prevented my GUIs from resizing correctly.

Water under the bridge though. I'm going to try to explain out how to use lv2 to have the host make a file selection dialog for you. I want all my plugins to work purely with host generated GUIs and loading files became necessary for porting the rakarrack *tron effects. The LV2 official documentation has improved a lot, but I was still struggling, so I thought I'd post this. The example to be used is rakarrack's reverbtron. Its a sort of convolution using very simplified impulse response files (which are actually text files). Instead of a constant sample rate in the IR, you just keep the most important samples and interpolate between them.

Regardless of the details, I have a module that needs files. All I need is to pass the file's path to the modules setfile() function and it takes care of the rest. How do I get that path? The whole process involves several extensions, and the most confusing part to me was figuring out what was what. But I got it, so read on...



So lets start with the ttl. Quick recap, ttl is static data that the host loads to figure out what your plugin is all about (see the official examples for some more info). So we need to indicate to the host in this ttl that we need files. Lets create a new statement that defines our .rvb files that hold the IR data. I usually just take the URI for the plugin and tack on some extra stuff with colons. Even though its not an actual website, the whole point of a URI is to keep it universally unique so its pretty unlikely any other plugin will name anything this same string:

      <http://rakarrack.sourceforge.net/effects.html#Reverbtron:rvbfile>
      a lv2:Parameter ;
      rdfs:label "rvb file" ;
      rdfs:range atom:Path ;
      . 

As you probably know already, this "sentence" in the ttl says, "I declare an lv2 parameter, labeled 'rvb file', and can be any value as long as its an atom containing a path." This is all done with URIs, but most of them are shortened using prefixes at the top of the file. Because these URIs are universal, the host knows what they mean and can interpret that as "ok, they have a parameter that will be a path" (roughly).

Now we need a port for this parameter to be passed into. Its not too different than other ports we've seen before, but we'll use an atom port like just we do for midi ports. So we have inside the plugin declaration we add:

     lv2:port [
              a lv2:InputPort, atom:AtomPort ;
              lv2:index 4 ;
              lv2:symbol "CONTROL" ;
              lv2:name "Control" ;
              atom:bufferType atom:Sequence ;
              lv2:designation lv2:control ;
              atom:supports patch:Message ;
      ] ;

This says the 4th port is an atom input. It has name and symbol "control". The host will hand us a pointer to a buffer full of a sequence of atoms (which are just structures of data). Its a designated port for the host to pass any control messages to (such as data for bpm sync, or our .rvb files). Finally, the port supports atoms carrying something called patch:message. What?

Patch is another extension that is used to read or manipulate properties between the host and plugin. I'm not extremely familiar with it, so I don't have any examples of what else you can do with it. Say for example is if the host wants to change the file path property of our plugin...

If you expand the prefix for patch the message URI is http://lv2plug.in/ns/ext/patch/#Message. The docs here aren't very verbose, but feel free to see what possibilities are there. The idea is that you can pass several properties without needing different message types for everything.

We want the host to know what property they can manipulate, so in our plugin declaration ttl we add:

   patch:writable <http://rakarrack.sourceforge.net/effects.html#Reverbtron:rvbfile> ;

saying that the plugin has a ".rvb file" property that the host can write. The host knows that URI means the .rvb file because we declared it before we declared the plugin.

See? This ttl stuff is pretty readable once you get the hang of it. You can see the full ttl but everything else in it, we've done before. 

So lets jump to the code. Assuming we've got the port connecting correctly, we just need to pull the atoms out of the buffer the host gives us, make sure they're the type of atom we want, then just grab the data (which should be the file path). So the action all happens in the run() part of the plugin, but we need a few things setup first. 

We need a way to recognize the URIDs that the atoms carry, and thats through the URID:map. I've described the map before, but I didn't really understand it then. Basically the host takes the URIs and says, "ok, how about from now on instead of calling that 'http://lv2plug.in/ns/ext/atom/#Object' we'll say its 4. So now whenever I pass an atom marked type 4, we both know what I mean." This mapping is generated arbitrarily by the host, they will call whatever URI any unique integer value, but you can count on it remaining unique this whole session. So always pay attention whether a function needs a URI (string) or a URID (int).

Anyway so its our plugin's responsibility to look through the host_features passed into our initialization function to get and save the mapping:

 for(i=0; host_features[i]; i++)
    {
        if(!strcmp(host_features[i]->;URI,LV2_URID__map))
        {
            urid_map = (LV2_URID_Map *) host_features[i]->;data;
            if(urid_map)
            {
                plug->URIDs.atom_Float = urid_map->map(urid_map->handle,LV2_ATOM__Float);
                plug->URIDs.atom_Int = urid_map->map(urid_map->handle,LV2_ATOM__Int);
                plug->URIDs.atom_Object = urid_map->map(urid_map->handle,LV2_ATOM__Object);
                plug->URIDs.atom_Path = urid_map->map(urid_map->handle,LV2_ATOM__Path);
                plug->URIDs.atom_URID = urid_map->map(urid_map->handle,LV2_ATOM__URID);
                plug->URIDs.patch_Set = urid_map->map(urid_map->handle,LV2_PATCH__Set);
                plug->URIDs.patch_property = urid_map->map(urid_map->handle,LV2_PATCH__property);
                plug->URIDs.patch_value = urid_map->map(urid_map->handle,LV2_PATCH__value);
                plug->URIDs.filetype_rvb = urid_map->map(urid_map->handle,RVBFILE_URI);
            }
        }
    }

There in the last line I use a #define I created for the URI string (for readability):

#define RVBFILE_URI "http://rakarrack.sourceforge.net/effects.html#Reverbtron:rvbfile"

See how that matches the URI in the ttl? One thing not shown here is that if the host does not give you a urid_map you need to abort the instantiation and return a 0 to the host. Now that we have that done (along with our other instantiation tasks not shown) then we're ready for the signal processing function, run(). When we're running the signal processing, we can look through the atom sequence and use the URIDs to find the atoms with data we want. This uses several LV2 macros, but they're pretty readable:

   LV2_ATOM_SEQUENCE_FOREACH(plug->atom_in_p, ev)
   {
       if (ev->body.type == plug->URIDs.atom_Object)
       {
           const LV2_Atom_Object* obj = (const LV2_Atom_Object*)&ev->body;
           if (obj->body.otype == plug->URIDs.patch_Set)
           {
               // Get the property the set message is setting
               const LV2_Atom* property = NULL;
               lv2_atom_object_get(obj, plug->URIDs.patch_property, &property,  0);
               if (property && property->type == plug->URIDs.atom_URID)
               {
                   const uint32_t key = ((const LV2_Atom_URID*)property)->body;
                   if (key == plug->URIDs.filetype_rvb)
                   {
                       // a new file! Get file path from message (the value of the set message)
                       const LV2_Atom* file_path = NULL;
                       lv2_atom_object_get(obj, plug->URIDs.patch_value, &file_path, 0);
                       if (file_path)
                       {
                           // Load sample. 
                           strcpy(plug->revtron->Filename,LV2_ATOM_BODY_CONST(file_path));
                           plug->revtron->setfile();
                       }//got file
                   }//property is rvb file
               }//property type is a URID
           }//if object is patch set
       }//if atom is abject
   }//each atom in sequence

So you see we go through each atom in the sequence. If the atom is an object containing a a patch:Set message, check if the property the patch message is setting matches our file URID. If it does then get the value the patch message is setting it to (which is really .rvb file's path the user selected).

Really thats all there is to it. Except...

File IO is NOT realtime safe. It could be reading off a USB 1.0 drive. Or an i2c drive. One thats networked over a dial-up connection. You never know. So unless the Reverbtron class's setfile() function handles it through multi-threading (and it doesn't) then this plugin is not realtime safe if we leave it like this.  If you need motivation on why you should worry about being RT safe go read the classic blogpost on the subject of realtime audio programming

So LV2 conveniently has an easy way for you to do file operations or any other non-RT stuff you want safely. Its called the worker extension. You can use it to calculate Fibonacci sequences or fractals, or download the internet, or whatever you want and it won't stop your RT code. Hey, we could make it calculate PI to n decimal places... I digress. The key here is that you schedule some function to be run by the "worker" (which is really just a separate thread, but you don't need to worry about it too much). This scheduling sends it off to another "place" to calculate whatever in however much time it will take. You can pass atoms to the work function for data or to indicate why the it is being run. This way you can do different tasks even though the worker always runs the same function. Once the work is complete the worker can execute a response function that can change your plugin. This second function must be RT safe. So the worker function will load the file into a struct or some useable form (not RT), then the worker response will put the struct into the plugin (RT). All you have to do is write these two functions then the host will handle the rest.
Well, good luck! 

Just kidding. I wouldn't leave you hangin! Lets go through it together. First we need to revisit our ttl to tell the host when they load this plugin that it needs the worker extension:

    lv2:requiredFeature urid:map , worker:schedule ;
    lv2:optionalFeature lv2:hardRTCapable ;
    lv2:extensionData worker:interface ;

The first line gets work:schedule added as the new required feature, optional features haven't changed, but we now need an extensionData struct for the worker (don't forget to add the necessary prefixes at the beginning of your ttl!). The work:interface indicates to the host that we'll use the extension_data() function of our plugin to hand over a struct called an LV2_Worker_Interface (surprise!). This struct has function pointers for the function you want the worker to run that doesn't have to be RT safe and the response function that does. Before now I haven't used the extension data in the dsp part of the plugin (just in the GUI), but it doesn't change too much. We need to define the struct, the functions, and put them in the plugin descriptor:

//forward declarations
static LV2_Worker_Status revwork(LV2_Handle handle, LV2_Worker_Respond_Function respond,
 LV2_Worker_Respond_Handle rhandle, uint32_t size, const void* data);
static LV2_Worker_Status revwork_response(LV2_Handle handle, uint32_t size, const void* data);

static const LV2_Worker_Interface worker = { revwork, revwork_response, NULL };

static const void* revtron_extension_data(const char* uri)
{
    if (!strcmp(uri, LV2_WORKER__interface)) {
            return &worker;
    }
    return NULL;
}

static const LV2_Descriptor revtronlv2_descriptor={
    REVTRONLV2_URI,
    init_revtronlv2,
    connect_rkrlv2_ports_w_atom,
    0,//activate
    run_revtronlv2,
    0,//deactivate
    cleanup_rkrlv2,
    revtron_extension_data
};

We'll get into what the work and response functions do in a bit, but for now suffice it to say they are defined, we put them in a constant struct, and pass return that when requested by the host (when the host calls revtron_extension_data(LV2_WORKER__interface);). Thats not too crazy, especially if you've read my posts on UIs where I used several extensions with extension data.

We next need to add an LV2_Worker_Schedule* member to our plugin for this will be the way to schedule the non-RT work to run. We also need to get the LV2_Worker_Schedule* that will come from the host during initialization. So:

   for(i=0; host_features[i]; i++)
    {
        if(!strcmp(host_features[i]->URI),LV2_WORKER__schedule)
        {
            plug->;scheduler = (LV2_Worker_Schedule*)host_features[i]->;data;
        }
        else if(!strcmp(host_features[i]->URI,LV2_URID__map))
        {
            //urid map stuff from earlier
...

Now that we have that, we can use it in the run() function. The code is the same part as above but in the deepest part of the if tree it changes to:
 
//going through the atoms in the sequence 
lv2_atom_object_get(obj, plug->URIDs.patch_property, &property, 0); 
if (property && property->type == plug->URIDs.atom_URID) 
{
     const uint32_t key = ((const LV2_Atom_URID*)property)->;body;
     if (key == plug->URIDs.filetype_rvb)
     {
          // a new file! pass the atom to the worker thread to load it
          plug->scheduler->schedule_work(plug->scheduler->handle, lv2_atom_total_size(&ev->body), &ev->t;body);)
     }//property is rvb file 
}//property is URID
...

So instead of pulling the file path string out of the atom and calling setfile(),  we just pass the atom to the worker. Now though, we have to be careful of multi-threading issues. If the worker is in the middle of loading the new file data while the run() executes, you might get some crazy behavior, reading half written variables etc. So I have to change the Reverbtron class to have 2 functions: loadfile() and applyfile(). The first will do the file operations and create a struct with the important data. applyfile() in turn will take the new struct and swap out the old one. loadfile() will be used in the work function, and the other in the RT-safe worker reply. This keeps everything clean and threadsafe. I'm not puting the load and apply code here because its very application specific, but thats the general idea. You can go look at the repo for the full code.

Once I have that in place I can write the function that the worker will run:

static LV2_Worker_Status revwork(LV2_Handle handle, LV2_Worker_Respond_Function respond, 
LV2_Worker_Respond_Handle rhandle, uint32_t size, const void* data)
{

    RKRLV2* plug = (RKRLV2*)handle;
    LV2_Atom_Object* obj = (LV2_Atom_Object*)data;
    const LV2_Atom* file_path;

    //work was scheduled to load a new file
    lv2_atom_object_get(obj, plug->URIDs.patch_value, &file_path, 0);
    if (file_path && file_path->type == plug->URIDs.atom_Path)
    {
        // Load file.
        char* path = (char*)LV2_ATOM_BODY_CONST(file_path);
        RvbFile filedata = plug->revtron->loadfile(path);
        respond(rhandle,sizeof(RvbFile),(void*)&filedata);
    }//got file
    else
        return LV2_WORKER_ERR_UNKNOWN;
           
    return LV2_WORKER_SUCCESS;
}

So we take that atom and just pull out the patch value, run it through loadfile() which returns a struct that holds all the important data from the file. We then pass the struct to the respond function, which looks like so:

static LV2_Worker_Status revwork_response(LV2_Handle handle, uint32_t size, const void* data)
{
    RKRLV2* plug = (RKRLV2*)handle;
    plug->revtron->applyfile((RvbFile*)data);
    return LV2_WORKER_SUCCESS;
}

This simply takes the struct with the filedata and applies it. This response function is actually run between run() calls of your plugin so you will have predictable results (you don't have to worry about the worker finishing and changing things in the middle of your signal processing). Originally I was trying to allocate the struct in loadfile() so that applyfile() just has to swap pointers, but then you must schedule the worker thread again to delete the old struct (delete/free() are not RT safe either). The other obstacle is that when the host is running these functions it copies the data that you pass, so you have to make take care you are manipulating the data you think you are when you try to pass pointers. It can be done (the official example does this), but I realized it made the code more complex than it needs to be. Premature optimization is the root of all evil. If profiling shows the extra memory copying is too expensive I'll worry about it then. For this example and many cases, just use plain old data (POD).

So, we're done, right? Unfortunately, no. If you want the user to be able to use your plugin, they'll need to be able to load it up in their session and when they reload the session it has the same file selected. This has to be done through yet another extension: state.

The state extension mechanics are similar to the worker extension, the host will pass in the state URI to extension_data() and we must return a special struct that tells the host what function to call to save and to restore the current state. Since the only state of the plugin that's not controlled by the usual controlPorts is the .rvb file thats all we need to save. So first we change the .ttl:

    lv2:requiredFeature urid:map, worker:schedule ;
    lv2:optionalFeature lv2:hardRTCapable, state:loadDefaultState ;
    lv2:extensionData worker:interface, state:interface ;


And in the extension data, add the state interface below what we did for worker:

static const LV2_Worker_Interface worker = { revwork, revwork_response, NULL };
static const LV2_State_Interface state_iface = { revsave, revrestore };

static const void* revtron_extension_data(const char* uri)
{
    if (!strcmp(uri, LV2_STATE__interface))
    {
        return &state_iface;
    }
    else if (!strcmp(uri, LV2_WORKER__interface))
    {
        return &worker;
    }
    return NULL;
}


for this extension we won't need any special mappings or anything in initialization. This is pretty much stuff we've done before, but what does the save function do? Well, something like:

static LV2_State_Status revsave(LV2_Handle handle, LV2_State_Store_Function  store, LV2_State_Handle state_handle,
        uint32_t flags, const LV2_Feature* const* features)
{
    RKRLV2* plug = (RKRLV2*)handle;
    LV2_State_Map_Path* map_path = NULL;
    for (int i = 0; features[i]; ++i)
    {
        if (!strcmp(features[i]->URI, LV2_STATE__mapPath))
        {
            map_path = (LV2_State_Map_Path*)features[i]->data;
        }
    }

    char* abstractpath = map_path->abstract_path(map_path->handle, plug->revtron->File.Filename);

    store(state_handle, plug->URIDs.filetype_rvb, abstractpath, strlen(plug->revtron->File.Filename) + 1,
 plug->URIDs.atom_Path, LV2_STATE_IS_POD | LV2_STATE_IS_PORTABLE);

    free(abstractpath);

    return LV2_STATE_SUCCESS;
}


File paths are a little unique because you don't want to store an absolute path, otherwise it won't be very portable (i.e. a preset on your machine probably won't work on mine). So there's a special part of the state extension that generates an abstract path that is more portable. Finally the big moment is calling store which comes from the state extension. You just pass in the URID for whatever you are saving, then the data you are saving, followed by the size and data type URID. The rest is just boilerplate code that you can more or less just paste and forget in most cases.

From save, restore ends up being pretty predictable:

static LV2_State_Status revrestore(LV2_Handle handle, LV2_State_Retrieve_Function retrieve,
        LV2_State_Handle state_handle, uint32_t flags, const LV2_Feature* const* features)
{
    RKRLV2* plug = (RKRLV2*)handle;

    size_t   size;
    uint32_t type;
    uint32_t valflags;

    const void* value = retrieve( state_handle, plug->URIDs.filetype_rvb, &size, &type, &valflags);

    if (value)
    {
        char* path = (char*)value;
        RvbFile f = plug->revtron->loadfile(path);
        plug->revtron->applyfile(f);
    }

    return LV2_STATE_SUCCESS;
}

On this side, just a call to retrieve which will find the data that was saved with our URID and return it.

So FINALLY we've gone from not being able to have users load files to an unsafe way to load files (patch extension), to a safe way (worker extension), to a way that allows us to reload the previous setting (state extension). Not too bad.

Hopefully this was as helpful to you as it was to me as I was writing it. I was looking through the examples, but couldn't really parse out what parts applied to my plugin and what parts were for this extension or that one. I had to break it down like this to really understand whats going on.

by Spencer (noreply@blogger.com) at June 11, 2015 10:59 AM

June 10, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Wanted before July: Ambisonics art works for Auditory Virtual Environments ...

Ambisonics has a strong community using Linux, therefore I ask the community
herein for art works:

"Pure Ambisonics" == "Ambisonics as an art form" is the hypotheses

We are searching for different works, which need not be recent ones, also
historic ones are of interest. Preferring higher order 3D, we take any order
3D or 2D as long it represents a wave-field as a spatial audio work ready for
concert. To test this thesis a concert is scheduled:

- PURE Ambisonics Concert & the Night of Ambisonics -

September 18th at ICSA 2015 in Graz

Preferring the AmbiX format, we also take other formats as long the
description has enough information to convert them to this domain.

More INFO on the CALL:

http://ambisonics.iem.at/icsa2015/pure-ambisonics-concert

mfG
winfried


--
---
Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing.
Institut 17 Elektronische Musik und Akustik
8010 Graz, Inffeldgasse 10/III
E-Mail ritsch@iem.at
Homepage http://iem.at/ritsch
Mobil ++436642439369
---


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

by iem.at at June 10, 2015 12:46 PM

June 09, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] latest Yoshimi developments

V 1.3.5-rc

I don't usually post here about release candidates, but there have been a lot
of changes since V 1.3.4

Some, like vector control were demomstrated to a handful of people at LAC 2015,
others are a direct response to suggestions there, and there is a roadmap we're
following too.

Before making a full release I'd very much like comments. What you like, what
you don't and what's just 'meh'. So please grab the current snapshot.

In brief:

User interface

Visual identification of use of any/all three synth engines

Part number and name added to all editing window title bars
Also voice number to AddSynth oscillator editor

Scroll wheel control of all rotary knobs +Ctrl for very fine control

Horizontal as well as vertical drag of rotary knobs

Revised some layouts and removed redundant controls and refreshes


System

On demand jack port creation for part outputs

NRPNs inc 14bit & increment/decrement
Also Zyn compatible ones (with some extensions)

16, 32 or 64 semi-independent parts

Vector control

Direct part control


Miscellany

The 'docs' directory now gets installed, although still scrappy text files

There is a new historical branch (currently with versions 0.010 to 0.038)

Yoshimi is now mirrored https://github.com/abrolag/yoshimi

Of course the original is still http://sourceforge.net/projects/yoshimi


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

by musically.me.uk at June 09, 2015 04:59 PM

June 08, 2015

Create Digital Music » open-source

7 Ways SONAR+D is Asking Bigger Questions About Music Tech

Lineup Sónar+D 2015 from Sónar on Vimeo.

There’s nothing inherently wrong with asking the same questions repeatedly. Cyclical inquiries are necessary in any practice. And over time, you refine answers.

But this year’s SONAR+D program promises something different.

SONAR+D is the younger, digital discourse alongside Barcelona’s massive electronic music festival. SONAR itself deserves a lot of credit for helping create the template a lot of digital music and media festivals follow today. And as that has since blurred into a parade of headliners, SONAR+D added a lot of dimension. There were good talks, hacklabs, workshops, and a showcase of makers.

Speaking as someone who either follows or participates in a lot of these things, though, I can’t wait for this year’s lineup. It seems uniquely ambitious and relevant, and I hope it sets the tone for the rest of this year.

Here are the threads I hope to follow – and why I’m glad CDM is a media partner of SONAR this year.

1. It’s not afraid to ask some hard questions. First up, I’m really curious what will come out of the discussion I’m joining, “De-westernalizing music through technology.” It’s a conversation I hope will spill over far past SONAR.

Xavi Serra is a leading researcher from one of the world’s hottest programs in music tech, the Music Technology Group at Pompeu Fabra University. And he’s in a fascinating new area, examining computational models for the world’s music. That includes delving into music from India, Turkey, Maghreb (Arabic-Andalusian), and Chinese Peking Opera idioms. Israeli producer Ariel Tagar is re-releasing rare Middle Eastern vinyl, and went to Jamaica to produce a record – sans computers, Jamaican style. Watch the trailer for a documentary that tracked them from Tel Aviv to the Kingston ghettos:

Congo Beat The Drum – Kalbata & Mixmonster // Trailer from kalbata on Vimeo.

Given the assumptions and defaults made by many music software tools are narrow even in the context of Western Classical practice, I think there’s plenty to explore here.

Speaking of asking tough questions, Holly Herndon is asking a lot of particularly timely ones. Without a hint of cynicism, her work digs into the profound interactions our computers have with privacy, surveillance, and politics – all the while keeping matters musical and personal. I’m particularly keen to hear what she’ll talk about to veteran music journalist Kate Hutchinson (The Guardian). This is a great chance to catch her live at SONAR, too.

holly

2. It’s highlighting some of our favorite music. Apart from Holly, SONAR+D is honing in on some of the music I can say at least I most love. Editions Mego, Resident Advisor meeting up with Voices from the Lake, and XL Recordings are all in the spotlight. All that and sonic reflections on Mies van der Rohe.

arduino

3. It’s directly celebrating open technologies. There’s very little discussion of open tech at these sort of events. Not so, SONAR. Arduino co-founder David Cuartielles is directly engaging open source hardware. And this is a timely moment for Arduino, given the traction of new (sometimes competing) platforms, Arduino’s entrance into MOMA, and challenges around branding. There’s a workshop with a Theremin and step sequencer, too.

littleBits are on-hand, too, complete with a workshop featuring a performance by FEZ co-developer Renaud Bédard, playing live. littleBit’s industrial design lead Jordi Borràs is a Barcelona native, since transplanted to that company’s home in New York, and will talk about how the platform can “snap into the Internet” with the Cloud bit. That should be Internet of Things buzzword-compliant, as should an appearance by Bruce Sterling, hosted by WIRED Italy.

xdj

4. It just might break some new DJ tech. DJing’s two biggest titans are each coming to show their latest stuff. In this corner, Pioneer: their PLX-100 and XDJ are the company’s latest play for the booth, covering their bases for both vinyl and computer control. Meanwhile, with the tech just about to hit users, Native Instruments are showing Stems, flanked by none other than Carl Craig, Luciano, and Kerri Chandler.

5. It could help European entrepreneurship and innovation. When I first came to SONAR, Spain was still reeling from the economic crisis. The entire European arts community was sorting out where to go next. Now, it seems, we’re getting some answers – and SONAR is unique in embracing DIY initiative as part of the solution. There’s talk of a href=”http://sonarplusd.com/activity/m-startup-barcelona/”>how Barcelona is making startups work

, and Google Creative Lab is talking about how they work.

There’s also an active role by Kickstarter, including the opening keynote – and no accident that you’ll get to see a Kickstarter-funded futuristic digital handpan as part of the event, too.

But this isn’t just about the startup-style, fend-for-yourself American model. European policy has a role, as well – one that can be more targeted and effective than perhaps it was in the past. The European Commission is a platform for neurotechnology, and in a massive talk will discuss open digital science ranging from NGOs to researchers to academics to EC wonks.

sonarworkshop

6. You might learn to build something.As in past years, there’s a 24-hour Hack Day sure to yield new stuff. As to the last point, though, this now includes European-funded building blocks to accelerate development to a new level.

Even if you’re not hacking, you can build the new synth project coming out of Mute Records.

7. It’s just generally got some cool stuff. Moldover, he of controllerism fame, is in town. Motionographer is showing eye candy. The creators of the beautiful indie game Monomument Valley are talking about their work, and Aaron Koblin and Chris Milk are going VR. The 808 movie is screening, with Arthur Baker (who’s also performing). And there’s lots more, even before we get to the artists playing the festival.

We’ll be reporting back. But:

If you’re going to Barcelona…

Discover Sónar and Sónar+D with your accreditation at a reduced price:

Thanks to the partnership between Create Digital Music and Sónar+D to promote networking opportunities among related communities around the Creative Industries, we are offering 10 professional accreditations -first come first serve- with an exclusive discount deal to attend Sónar 2015 only until 12th of June 2015

Promotional Price:

250€ – Day and Night accreditation. Price without promotion 310 euros

Find all the accreditation benefits: http://sonarplusd.com/buy-your-accreditation/

Ask for your promotional pass by contacting promotions@sonar.es

And no, we’re not getting paid for this piece – these are my opinions.

Believe me, otherwise I would happily just show up for my panel and sneak away to the beach the rest of the time!

I’m really excited! I’ll be chugging Red Bulls and trying to absorb as much as I can!

The post 7 Ways SONAR+D is Asking Bigger Questions About Music Tech appeared first on Create Digital Music.

by Peter Kirn at June 08, 2015 02:58 PM

June 06, 2015

Hackaday » digital audio hacks

ESP8266 As A Networked MP3 Decoder

Support libraries, good application notes, and worked examples from a manufacturer can really help speed us on our way in making cool stuff with new parts. Espressif Systems has been doing a good job with their ESP8266 product (of course, it doesn’t hurt that the thing makes a sub-$5 IOT device a reality). Only recently, though, have they started publishing completed, complex application examples. This demo, a networked MP3 webradio player, just popped up in Github, written by the man better known to us as Sprite_tm. We can’t wait to see more.

The MP3 decoder itself is a port of the MAD MP3 library, adapted for smaller amounts of SRAM and ported to the ESP8266. With a couple external parts, you can make an internet-connected device that you can point to any Icecast MP3 stream, for instance, and it’ll decode and play the resulting audio.

What external parts, you ask? First is something to do the digital-to-analog conversion. The application, as written, is build for an ES9023 DAC, but basically anything that speaks I2S should be workable with only a little bit of datasheet-poking and head-scratching. Of course, you could get rid of the nice-sounding DAC chip and output 5-bit PWM directly from the ESP8266, but aside from being a nice quick demo, it’s going to sound like crap.

The other suggested external IC is an SPI RAM chip to allow for buffering of the incoming MP3 file. WiFi — and TCP networks in general — being what they are, you’re going to want to buffer the MP3 files to prevent glitching. As with the dedicated DAC, you could get away without it (and there are defines in the “playerconfig.h” file to do so) but you’ll probably regret it.

In sum, an ESP8266 chip, a cheap I2S DAC, and some external RAM and you’ve got a webradio player. OK, maybe we’d also add an amplifier chip, power supply, and a speaker. Hmmm…. and a display? Or leave it all configurable over WiFi? Point is, it’s a great worked code example, and a neat DIY device to show your friends.

The downsides? So far, only the mono version of the libMAD decoder / synth has been ported over to ESP8266. The github link is begging for a pull request, the unported code is just sitting there, and we think that someone should take up the task.

Other Resources

In our search for other code examples for the ESP8266, we stumbled on three repositories that appear to be official Espressif repositories on Github: espressif, EspressifSystems, and EspressifApp (for mobile apps that connect to the ESP8266). The official “Low Power Voltage Measurement” example looks like a great place to start, and it uses the current version of the SDK and toolchain.

There’s also an active forum, with their own community Github repository, with a few “Hello World” examples and a nice walkthrough of the toolchain.

And of course, we’ve reported on a few in the past. This application keeps track of battery levels, for instance. If you’ve got the time, have a look at all the posts tagged ESP8266 here on Hackaday.

You couldn’t possibly want more resources for getting started with your ESP8266 project. Oh wait, you want Arduino IDE support?

Thanks [Sprite_tm] for the tip.


Filed under: digital audio hacks, Microcontrollers

by Elliot Williams at June 06, 2015 02:00 PM

June 05, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] io GNU/Linux 2015.03 released

Hi all,

New images are ready for testing ;)

io GNU/Linux is a Live DVD/USB based on Debian Sid and focused on multimedia.

Kernel 4.0.4 and 4.0.4-rt, Jack2+AlsaLoop as default sound server (can be
easily changed to Jack2+ZitaBridge, Jack2+PulseAudio, PulseAudio or Alsa)

e18 as desktop environment and a big collection of installed software... Full
persistence for USB install (with encryption) and more stuff...

For more infos: manual, packages list, screenshots, video etc... Visit:

-> http://io.gnu.linux.free.fr
-> https://sourceforge.net/projects/io-gnu-linux/

Installer has been rewritten, and a lot of work has been done to improve
security of live persistent users.

Feedbacks welcome, enjoy :)

MK

by free.fr at June 05, 2015 01:09 PM

June 04, 2015

Nothing Special

How to Boycott SourceForge

I was finally convinced to leave Sourceforge.net. I was holding out, trying to be true to a service that once was the best and most dedicated to free license and open source software, but finally, due largely to this editorial, have decided to join the boycott. Since I don't like doing things half-way I'm taking everything down and trying to make it as easy as possible for others to do the same.

If you are using git already, it won't take much to move your repositories to Github. Bitbucket will pretty much be the same commands. I already had an account so I won't describe how to sign up, but its pretty easy. Once signed in you can create a repository by clicking the little plus sign in the top right corner. Name the repo whatever your project name is and opt to leave it empty (I presume you already have the project hosted at sf.net). You should make sure you're up to date on every branch from sf.net first. Once that is done you can just go to your local repo and issue the command:

git push https://github.com/[USERNAME]/[PROJECTNAME].git master

and repeat for every branch besides master.

You can then delete the local repo and re-clone it using the URL github give you, or just edit .git/config to update what URL origin points to, or there's some git command to do it that I can't remember. You can also go delete your project from sf.net BUT I decided to leave the skeleton of the project with links to the new home at github.

To do so make sure you haven't pointed your repo's origin to github yet. If you have substitute the sf.net project git URL for origin. Go delete every branch but master on sf.net by entering:

 git push origin :branch

Then on master branch do (carefully):

rm -rf *
echo moved to [github project URL] to boycott sourceforge >> README
git commit -a -m "boycott sourceforge"
git push origin master


Careful, because rm -rf * deletes everything in the current directory. This makes it so your repository is now empty except a nice little statement of what we think of the new sf.net.

I only had source tarballs in the files section so I deleted them all and added the same readme as is in the repo. If you use this feature of sf.net it will be harder to find a substitute. This blogger subjectively goes through 14 alternatives and decides to stick with sourceforge. Hopefully you can find one of the alternatives workable.  I also edited the project description to say that the project had moved.

 If your project has a website you can move it to github quite easily too. Just go to your repo that is now using github for the origin and type:

git checkout -b gh-pages
rm -rf *


The name of the branch (gh-pages) is very important. Download the site source from the sourceforge ftp if you need or if you have a local copy just copy it all into the repo. Make sure you have an index.html and then just:

git add *
git commit -a -m "adding site"
git push origin gh-pages

Your new site is at http://[USERNAME].github.io.com/[PROJECTNAME]
Not too bad!

I wish I had a good answer about binaries. If you use other features like mailing lists you might have to do some more homework too. If you have found good solutions, spread the word, leave a comment.

Now, as a commentary, SourceForge hasn't done anything illegal. The GPL of most open software allows them completely to package it with adware, malware or whatever. But is that cool? Heck no! So on grounds of ethics, it has come time to boycott. Do not visit sf.net, do not download from there, and do not give them your code to host. I avoided Github for a long time because I felt they weren't as dedicated to open source, since their site code is not open (and partially because I tend to kick back when something seems trendy). But honestly it seems they've found a business model that is working for them and allows us more freedom for free software projects. SourceForge is not what it once was, and we owe the current management of it no loyalty. I don't really mind which service you move to, but don't stay.

by Spencer (noreply@blogger.com) at June 04, 2015 11:44 PM

June 02, 2015

Create Digital Music » Linux

Novation’s Launchpad Grid, Now in Color, for Ableton or iPad

launchpad

Novation’s Launchpad has seen slimmer and smaller versions. And upcoming is a Pro version with pressure/velocity and MIDI in and out.

But if you just want the grid, you can now get the base model with RGB color. It’s officially called the Launchpad mk2. No availability or pricing yet (damn you, unstable Euro), but you can sign-up for notification.

The update has the same basic design as the original, but updated with styling from its Pro sibling, and RGB color behind the pads for more visual feedback.

Here’s the obligatory video of the new model, which gets a very cute studio setup and a live performance by Buddy Peace:

That basic model does quite a lot.

Beginners: For beginners, you get a lot of bundles. Live Lite, a gig of samples, and the Bass Station plug-in are included.

Ableton Live users: In Ableton Live, you’re pre-mapped to Drum Racks, mixing, and Max for Live.

iPad owners: And this is a grid that works with just about anything. Ableton Live is the original use case, but the driverless model plugs into an iPad, too. There’s official support for Novation’s own Launchpad app.

Advanced users, customization: Linux, Windows, other apps, all work, too, because the Launchpad has class-compliant drivers. This hardware has also been well supported by the community for apps ranging from Bitwig to Renoise, partly because of its low cost. Because it’s simple to program, it’s a great choice for Max and Pd and Reaktor patchers, too.

But that’s all true of the whole family at the moment.

So, is this the Launchpad I’d get? Absolutely not.

Wait, what?

Yeah, I have to admit, I think Novation has nailed it with two models. The Launchpad Mini is incredibly small, so for a dead-simple grid to just toss in a bag, I’d opt for that model – partly because I don’t need all those colors. The Pro, meanwhile, is brilliant in that it works with MIDI, and much to my surprise will support standalone operation. It’s not necessarily the most responsive controller in terms of pressure sensitivity (I still like Push and Maschine for that, or the Linnstrument if I want to get really serious). But it may prove to be the most versatile. There’s more to say about the Pro, but expect our review as they arrive this summer. (I got to play with a prototype, alongside our own MeeBlip, this summer.)

All that said, I’m sure the RGB Launchpad will be perfect for some. And Novation has done a superb job of rounding out their lineup with options for every use case, rather than a one-size-fits-all approach. That lets you be modular and carry just what you need, and that, I think, is a very good thing.

Plus, I still can’t kill my original Launchpad (serial #7, believe it or not), even after copious amounts of abuse. So I think putting your faith in this line isn’t a big risk.

Ableton’s Push remains the hardware to beat as an expressive instrument with lots of other features. But it’s not much use outside of Ableton, it’s not available in anything other than the flagship model, and it’s heavy (which may be a good or bad thing, depending on whether you’re next DJ gig involves Ryanair).

Novation at the moment has pretty much every other possible base covered.

Now I just have to bide my time waiting for that Pro model.

http://global.novationmusic.com/launch/launchpad

The post Novation’s Launchpad Grid, Now in Color, for Ableton or iPad appeared first on Create Digital Music.

by Peter Kirn at June 02, 2015 10:31 AM

May 30, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] x42-plugins-20150530

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ahoy!

Spring cleaning is over and before the summer heat takes over here's
something to shake off the winter from the previous release.


x42-plugins is a collection of cross platform LV2 audio/midi plugins,
currently featuring over 80 plugins from 11 repositories.

https://github.com/x42/x42-plugins
http://gareus.org/misc/x42-plugins/x42-plugins-20150530.tar.xz
(sha1sum 1a16a8ceff1f279ba92b9ca5c12aeb668725794b)

enjoy,
robin


Significant changes since the last release (20141101)

* fil4.lv2 [new] (equalizer)
- 4 Band Parametric with additional High/Low shelfs and Hi/Lo Pass
and graphical display. Based on Fons Adriaensen LADSPA fil-plugins
- equivalent analog gain (zero phase shift) at nyquist
- zero latency

* meters.lv2 (measurement & visualization)
- new BBC M6 (mid/side) meter
- fix port label for true-peak meter
- combined GUI shared lib (dramatic reduction of deployment size)

* balance.lv2 (stereo conditioner)
- fix texture clamping (issues with some graphics card)
- add multisampling (nicer graphics)

* convo.lv2 (zero latency convolution)
- remember display (and announce) last/currently used IR
- tweak GUI-less mode (allows host to set/query IR file;
automatable)
- reset channel assignment when replacing the IR file
(mono, stereo, true-stereo modes)

* midifilter.lv2
- fix potential overflow of midi-delaylines

* all plugins:
- update GUI font-scaling where applicable
- various openGL fixes (GL context separation)
- portability issues all plugins now run on Linux, OSX, Windows
and various CPU architectures.
- gtk variant has been deprecated (needs explicit BUILDGTK=yes)


For a complete list of changes, please see the individual repositories:

https://github.com/x42/balance.lv2
https://github.com/x42/convoLV2
https://github.com/x42/fil4.lv2
https://github.com/x42/meters.lv2
https://github.com/x42/midifilter.lv2
https://github.com/x42/mixtri.lv2
https://github.com/x42/nodelay.lv2
https://github.com/x42/onsettrigger.lv2
https://github.com/x42/sisco.lv2
https://github.com/x42/tuna.lv2
https://github.com/x42/xfade.lv2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVaiqpAAoJEKCQvOAs9X8EVDQQAJUSH+KzFs8Jgo49yWZMRlRf
+Idc1c90DHxQbCN9l0MsAqpO00VowTfwaSu9Baw41/HAXXLHjgo+4FmODY0gT5zU
NhkLHtUgDgYIFYRPLojcTd/dZfpCD2qoS9oqpnLMcHvF4gHMy8TY0wUPMLo8ZT4w
ZFOU1cnKpnq/Su66AOPbPZDaZp1csM6qNVRNeKShq7dFKo+eu7p6Npmmtfu5/B1t
1/5TEHIxgSuq6jLPr6qRgFpGr19JQ/66QLbOaSY97VKGUCvA9tFsaNmYKZkIlvbO
MyhCIbIkCch2ero3uREYZyxht4El+HFPVQUHcIuyO6iKVg+CY6NxgVkh+8dhKuxW
Efg5o9hKi+ZpgU6VeA/he2MMoEmwWtqGkj4qWMy09mqpQac2m66Q8ghq1712MDez
tJ/D3SyIpzAY8Ygt6hHX6Tkn5wAOBBtwn742N5V2nSLHC+hqwI/Pa/LzoiSjYZFz
xsOckhDP22Xp1NZ6+1A4rJEHvgRUxkch8wga8OFyXPn/KtOIkdDyu1+nikQzsMBx
2U2jZbchEYyz5ccvrRa2Pz00ZJqbrqu6SNXOWxW+c+e8y7ejadfHlg2pDt5QVI1e
B0AAwEsMx+DXBB4qclUPfQ+EU89V0bu+yqAM5yEZ6qi+VV9LmYOKup6x7riV0ylk
giTzh+qq9kToIPJ31qv9
=boK
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

by gareus.org at May 30, 2015 09:25 PM

[LAA] MIDI programmed music box


At the Linux Audio Conference 2014 in Karlsruhe [1] there was an excursion
to the museum of mechanical music instruments in Bruchsal. [2] In the
museum they sold music boxes as a souvenir that can be programmed by punch
tapes. [3] I wrote a simple Haskell program that converts a MIDI file to
the punch tape. [4] As an example I arranged a song of a colleague for the
music box. [5,6,7]

Unfortunately, the music box is restricted to whole tones (i.e. no "black
keys") and it cannot play the same note again in a short time interval. My
prefered solution would be to print the graphics on an empty punch tape,
but I could not obtain an empty one. They are only sold with a printed
grid. Furthermore the original punch tapes are not made of paper but of
plastic. I do not know whether you can print on it using a plain laser or
ink jet. I might try thick paper instead but I suspect that it will wear
out quickly. However I already know that my laser printer cannot handle
the length of the original stripes. Thus I printed the graphics with
original width but shrunken length to regular paper and transfered the
dots from there to the punch tape manually.

[1] http://lac.linuxaudio.org/2014/
[2] http://www.dmm-bruchsal.de/
[3] http://www.amazon.de/Spieluhr/dp/B001WNZOVO/
[4] https://hackage.haskell.org/package/midi-music-box
[5] https://www.youtube.com/watch?v=SjnM-aRoYic
[6] http://www.amazon.de/Schlafaepfel/dp/B003IDM06I/
[7] http://hub.darcs.net/thielema/livesequencer-example/browse/Herbst.hs
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

by henning-thielemann.de at May 30, 2015 08:16 PM

May 29, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] LazyLimiter released.

Hi everybody,

I'm announcing the first release of my lookahead limiter: LazyLimiter v0.3.01
https://magnetophon.github.io/LazyLimiter/

This is my attempt of a clean yet fast brick-wall limiter.


Thanks to Sampo Savolainen for providing the initial inspiration.

Very special thanks to Yann Orlarey, who spent an evening at LAC2015
with me, to optimize the algorithm and make this thing actually usable.


I'm looking forward to your feedback!


Cheers,
Bart.

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

by magnetophon.nl at May 29, 2015 09:17 AM

May 28, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Qtractor 0.6.7 - The Lepton Acid beta release!

It's alive!

Qtractor 0.6.7 (lepton acid beta) is out!

Release highlights:

* MIDI instrument rendering on audio export (NEW)
* MIDI clip editor view/event criteria persistence (NEW)
* MIDI clip editor resilience on record/overdub (FIX)
* Generic plugin form position persistence (NEW)
* JACK Transport/Timebase master option (NEW)

and yet more tiny lurking critters swatted ;)

Well, the major highlight to this release is in fact this brand new and
way long overdue feature, seamlessly integrated to the faithful and
regular audio track export function: MIDI track instrument plug-in
rendering and mix-down (aka. freeze) is now real, as long their audio
output goes onto selected buses, aka. stems, mix-groups, whatever a
mix/mastering head would name it! nb. on the (very esquisite) Qtractor
arch-model parlance, those are just called "audio output buses" and that
ain't gonna change, any time soon, so stop it! A word of caution must be
told by now: dedicated (JACK) audio output ports are off-the-grid, so
sorry.

Maybe this silently makes a notch towards the DAW epitome, though
Qtractor still claims to be just a plain and honest sequencer--with yet
another DAW-like feature addition--the same as it ever was.

Nuff said.

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

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

- source package (openSUSE 13.2):

http://download.sourceforge.net/qtractor/qtractor-0.6.7-17.rncbc.suse132.src.rpm

- binary packages (openSUSE 13.2):

http://download.sourceforge.net/qtractor/qtractor-0.6.7-17.rncbc.suse132.i586.rpm

http://download.sourceforge.net/qtractor/qtractor-0.6.7-17.rncbc.suse132.x86_84.rpm

- 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 [5]) version 2 or later.

Change-log:
- MIDI clip editor (aka. piano-roll) position, size, and view/event type
criteria are now persistent, across session and user preferences
application state.
- Generic plugin form widget position is now also preserved across
open/save session cycles.
- MIDI clip editor resilience is about to get an improvement, fe. it
doesn't close on stopping record/overdub anymore.
- Introducing (JACK) Timebase master setting as an option to Transport
mode (cf. View/Options.../General/Transport/Timebase).
- LV2 plug-in MIDI/Event support now slanted for deprecation.
- Spanish (es) translation added, by avid Reyes Pucheta.
- It's live: audio track export (cf. Track/Export Tracks/Audio...) has
been deeply refactored to finally include MIDI track/instrument plugins
rendering (aka. freeze) on selected audio output buses on mix-down.
(EXPERIMENTAL)
- MIDI file player now does (N)RPN 14-bit controller events.
- Track properties dialog output bus switch fix/optimization; also fixed
multiple DSSI instance reference count on close.
- Fixed for some strict tests for Qt4 vs. Qt5 configure builds.
- German (de) translation update (by Guido Scholz, thanks).

References:

[1] Qtractor - An audio/MIDI multi-track sequencer
http://qtractor.sourceforge.net

[2] Qt framework, C++ class library and tools for
cross-platform application and UI development
http://qt.io/

[3] JACK Audio Connection Kit
http://jackaudio.org

[4] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/

[5] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html


See also:
http://www.rncbc.org/drupal/node/894


Enjoy && keep the fun.
--
rncbc aka. Rui Nuno Capela

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

by rncbc.org at May 28, 2015 03:22 PM

May 27, 2015

Create Digital Music » open-source

zMors Puts a Modular on Your iPad – Now with Pd Patch Support

modularpd

There are lots of one-off apps for iPad – a synth here, an effect there. zMors is something else: a complete modular patching environment.

And that doesn’t just mean putting some virtual patch cables onscreen. zMors does MIDI input. It works with hardware modulars (via audio and control voltage). And now, it adds Inter App Audio for use with other apps – and it loads Pd patches.

That’s right: you can put a modular patching environment inside your modular patching environment. Load a Pd patch from your computer into zMors, and combine it via other modules. That looks simply amazing for live performance.

First off, if you haven’t seen zMors yet, you do get a whole bunch of modules:

OSC, MultimodeFilter, WaveTable, ADSR, Slew, VCA, DSP, Combiner, Oscilloscope, Chords, CV Sequencer, Step Sequencer, Midi Keyboard, XYPad, Delay, Reverb, BPM CLock,4×4 MatrixMixer, Macro for complex setups

With the version released last week, zMors has added MIDI sequencing, a sampler, a MIDI filter, a motion module for making CV signals for outputs, a physical modeling (Karplus-Strong) oscillator, iCloud support (which is how you’ll load Pd patches), recording into WAV, Bluetooth MIDI support, and more.

If you know how to use Pd – even as far as downloading the odd patch – you know how to use the Pd bit. Pd patches work the way they always do, but here can be inter-connected with those other modules. You can thank libpd for making this possible – and, perhaps, ask why your favorite software doesn’t do something similar.

Here’s a short video showing what the software can do, from its fall launch (so obviously, it’s added more since then). And yes, you can customize that video:

For more:
http://www.zmors.de/zmors-modular/
a href=”http://libpd.cc”>http://libpd.cc

The post zMors Puts a Modular on Your iPad – Now with Pd Patch Support appeared first on Create Digital Music.

by Peter Kirn at May 27, 2015 07:50 PM

rncbc.org

Qtractor 0.6.7 - The Lepton Acid beta release!

It's alive!

Qtractor 0.6.7 (lepton acid beta) is out!

Release highlights:

  • MIDI instrument rendering on audio export (NEW)
  • MIDI clip editor view/event criteria persistence (NEW)
  • MIDI clip editor resilience on record/overdub (FIX)
  • Generic plugin form position persistence (NEW)
  • JACK Transport/Timebase master option (NEW)
  • and yet more tiny lurking critters swatted ;)

Well, the major highlight to this release is in fact this brand new and way long overdue feature, seamlessly integrated to the faithful and regular audio track export function: MIDI track instrument plug-in rendering and mix-down (aka. freeze) is now real, as long their audio output goes onto selected buses, aka. stems, mix-groups, whatever a mix/mastering head would name it! nb. on the (very exquisite) Qtractor arch-model parlance, those are just called "audio output buses" and that ain't gonna change, any time soon, so stop it! A word of caution must be told by now: dedicated (JACK) audio output ports are off-the-grid, so sorry.

Maybe this silently makes a notch towards the DAW epitome, though Qtractor still claims to be just a plain and honest sequencer--with yet another DAW-like feature addition--the same as it ever was.

Nuff said.

Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt 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.

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:

  • MIDI clip editor (aka. piano-roll) position, size, and view/event type criteria are now persistent, across session and user preferences application state.
  • Generic plugin form widget position is now also preserved across open/save session cycles.
  • MIDI clip editor resilience is about to get an improvement, fe. it doesn't close on stopping record/overdub anymore.
  • Introducing (JACK) Timebase master setting as an option to Transport mode (cf. View/Options.../General/Transport/Timebase).
  • LV2 plug-in MIDI/Event support now slanted for deprecation.
  • Spanish (es) translation added, by David Reyes Pucheta.
  • It's live: audio track export (cf. Track/Export Tracks/Audio...) has been deeply refactored to finally include MIDI track/instrument plugins rendering (aka. freeze) on selected audio output buses on mix-down. (EXPERIMENTAL)
  • MIDI file player now does (N)RPN 14-bit controller events.
  • Track properties dialog output bus switch fix/optimization; also fixed multiple DSSI instance reference count on close.
  • Fixed for some strict tests for Qt4 vs. Qt5 configure builds.
  • German (de) translation update (by Guido Scholz, thanks).

Enjoy && keep the fun.

by rncbc at May 27, 2015 06:30 PM

May 22, 2015

Create Digital Music » Linux

Cool Things Chrome Can Do Now, Thanks to Hardware MIDI

heisenberg

Plugging a keyboard or drum pads into your Web browser is now a thing.

One month ago, we first saw hardware MIDI support in Chrome. That was a beta; this week, Google pushed it out to all Chrome users.

So, what can you actually do with this stuff? Well, you can open a Web tab and play a synth on actual hardware, which is pretty nifty.

Support is still a little dicey, but the available examples are growing fast. Here are some of the coolest, in addition to the MIDI example and demo code we saw last month.

The examples are certainly promising, but you may want to temper expectations. Users of browser-based solutions built on Flash will find some of this old news. Audiotool, for one, has already had a really sophisticated (semi-modular, even) production tool running for some years. (It’s relevant here that Audiotool is coming to the HTML5/MIDI support, but it isn’t here yet.) And while open standards are supposed to mean more compatibility, in practice, they are presently meaning far less. Even though Safari and Chrome are pretty close to one another in rendering pages, I couldn’t get any of these examples working properly in any browser other than Chrome. And while I could get pretty low-latency functionality, none of this is anywhere near as solid in terms of sound performance as any standalone music software.

So, that leaves two challenges. One, the implementation is going to have to improve if non-developers are going to start to use this. And two, if this stuff is going to see the light of day beyond music hackathons, it’ll need some applications. That said, I could imagine educational applications, demos of apps, collaborative possibilities, and more – and those expand if the tech improves. And, of course, this also gets really interesting on inexpensive Chromebooks – which it seems are selling in some numbers these days.

But that’s the future. Here are some of the things you can do right now:

audiotool

Audiotool is coming to HTML5, and Heisenberg is here now. Heisenberg is I think the coolest option yet – more than just a tech demo, you can plug in a MIDI keyboard and it’s a really fun, free browser synth. Given the amount of pleasure we’ve gotten out of the odd Web time-waster, this is serious business.

But that’s just the appetizer. The team behind Audiotool are working on porting it to HTML5. That should be an excellent test of just how mature this technology is. Audiotool is great and – Flash or not – it’s worth having a play with if you are the kind of person who gets some inspiration from new software toys. (And if you’re reading this far, I suspect you are.)

http://www.audiotool.com/product/device/heisenberg/

http://www.audiotool.com/app [Flash for now, including screenshot above]

js106

Revisit Roland. Steven Goldberg’s 106.js reimagines the classic Roland Juno-106 in JavaScript. And it’s just added MIDI support. Plus you can check the code out, free.

http://resistorsings.com/106/

GitHub

yamahaclone

Play a 60s Yamaha combo organ. The oddest of this bunch is also my favorite sonically, just because it’s so quirky. The Foo YC20 is an emulation of Yamaha’s 1969 organ, the YC-20 combo – “features and flaws” all included. And now it feels more like an organ, since you can connect a MIDI keyboard.

Users should like it: if you’re not fond of running it in your browser, you can also run it as a VST plug-in for Mac or Windows or standalone or as an LV2 plug-in on Linux.

Developers will like it, too: apart from some surprisingly authentic open source recreations, it’s all coded in the Faust programming language, a functional language for DSP.

http://foo-yc20.codeforcode.com

hyaio

Run a full modular DAW. No need to wait on Audiotool: app.hya.io is already a full-featured semi-modular DAW built in HTML5 with MIDI support (and audio input). It’s got a full assortment of instruments and effects, too – and some interesting ones, so it complements Audiotool.

http://app.hya.io/

websynths

Run a bunch of microtonal synths. Mitch Wells’ Web Synths is a deep microtonal instrument, capable of some unique sound designs, and perhaps the richest actual synth of this bunch. Patch sharing shows one powerful feature of putting browsers on the Web – the ability to share with others.

http://www.websynths.com/

vult

Live-code your own synth. Maybe this is the application that makes the most sense. While it’s tough for the other proof-of-concept toys to compete with your desktop instruments, it’s kind of tough to beat the ability to live-code with Web tech in a browser.

And by “code,” you hardly have to be a hard-core coder. The coding is radically simplified here, spitting out JavaScript from basic commands – fun for even the most entry-level hacker to play around with.

Vult by Leonardo Laguna Ruiz was built at MIDIHACK, the hackathon I was part of here in Berlin this month.

http://modlfo.github.io/vult/demo.html

synthy

Play a synth – with colored lights and more. Synthy.io is a three-oscillator synth with some interesting extras. There’s a tracker-sequencer built in, and you can play a “live” mode with color output.

The nerdy stuff behind the scenes demonstrates some potential for other projects. Apart from the new MIDI mode, the server mode offers up other possibilities. (socket.io, Node.js, live server, NeDB database holding patterns, if you’re curious.)

What does that mean in practice? Developer Filip Hnízdo writes in comments:

“One of the features I’m most proud of is the live websocket server so any pattern that gets pushed to it is played live to a page where anyone can hear what anyone else has created in realtime. Especially fun with MIDI routed into soft synths or hardware. If enough people pushed patterns in you could just leave it on in your bedroom and constantly hear new music as it arrives. The patterns are all encoded as URLS too so easy to share.”

Having just read a history of the first networked, first first-person shooter in the 70s, it’s worth saying: this stuff can lead to unexpected places. And Filip is looking for collaborators.

http://synthy.io/

Got more for us? Let us know in comments.

And if you have any tips on audio performance or how this is developing (since I complained about that), or likely applications (since I mused about that), we’d love to hear that, too.

The post Cool Things Chrome Can Do Now, Thanks to Hardware MIDI appeared first on Create Digital Music.

by Peter Kirn at May 22, 2015 05:24 PM

May 13, 2015

Linux Audio Users & Musicians Video Blog

John Option – Where’s my Car?

Well executed Sonic Rock from John Option. Video edited in Kdenlive.

by DJ Kotau at May 13, 2015 10:02 AM

May 12, 2015

Nothing Special

Infamous Plugins are Tiling!

I'm very very excited to say this:

1000 words


Thanks to falktx helping me understand what he told me months ago, the infamous plugins are all now 100% resizable. Which means I can use them comfortably in my beloved i3.

These just may be the first rumblings of an early release... stay tuned.

by Spencer (noreply@blogger.com) at May 12, 2015 04:34 PM

May 09, 2015

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] Vee One Suite 0.6.3 - A sixth beta release

[UPDATE] As a micro dot release override, the current sixth beta release
is out and crunching the earlier fifth to oblivion ;)

Howdy,

The 'Vee One Suite' of 'old-school' software instruments, aka. the 'gang
of three' have bumped over another tiny notch: synthv1 [1], as one
polyphonic synthesizer, samplv1 [2], a polyphonic sampler and drumkv1
[3], as one drum-kit sampler, are now being released to the masses. Again ;)

There's no big audible changes, if any at all, yet this fifth beta
release is rather a probable bug fix drumkv1 LV2 on Ardour.

Anyway, it's all gone as follows:

- Sample file drag-and-drop support has been added to the note element
list widget (drumkv1 [3] only).
- Main widget layout changed as much to allow sampler display and
element list to expand or grow vertically as needed (samplv1 [2] and
drumkv1 [3]).
- Sample file path mapping has been fixed for LV2 plugin state
restoration, which were preventing Ardour to reload any of the saved
session or preset sample files in particular (drumkv1 [3] only).
- Custom knob/dial behavior mode options are now introduced: linear and
angular (aka. radial) as far to avoid abrupt changes on first mouse
click (still the default behavior).
- Fixed for some strict tests for Qt4 vs. Qt5 configure builds.

We're still available in dual form, as business as usual:

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

Enough to tell, 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.

As always, have (lots of) fun :)


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

synthv1 0.6.3 (sixth 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.6.3.tar.gz

- source package:

http://download.sourceforge.net/synthv1/synthv1-0.6.3-22.rncbc.suse132.src.rpm

- binary packages:

http://download.sourceforge.net/synthv1/synthv1-0.6.3-22.rncbc.suse132.i586.rpm

http://download.sourceforge.net/synthv1/synthv1-0.6.3-22.rncbc.suse132.x86_84.rpm


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

samplv1 0.6.3 (sixth 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.6.3.tar.gz

- source package:

http://download.sourceforge.net/samplv1/samplv1-0.6.3-22.rncbc.suse132.src.rpm

- binary packages:

http://download.sourceforge.net/samplv1/samplv1-0.6.3-22.rncbc.suse132.i586.rpm

http://download.sourceforge.net/samplv1/samplv1-0.6.3-22.rncbc.suse132.x86_84.rpm


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

drumkv1 0.6.3 (sixth official beta) is out!

drumkv1 is 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.6.3.tar.gz

- source package:

http://download.sourceforge.net/drumkv1/drumkv1-0.6.3-18.rncbc.suse132.src.rpm

- binary packages:

http://download.sourceforge.net/drumkv1/drumkv1-0.6.3-18.rncbc.suse132.i586.rpm

http://download.sourceforge.net/drumkv1/drumkv1-0.6.3-18.rncbc.suse132.x86_84.rpm


References:

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

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

[3] drumkv1 - an old-school drum-kit sampler
http://drumkv1.sourceforge.net/

[4] JACK Audio Connection Kit
http://jackaudio.org/

[5] NSM, Non Session Management
http://non.tuxfamily.org/nsm/

[6] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/

[7] LV2, Audio Plugin Standard, the extensible successor of LADSPA
http://lv2plug.in/

[8] GNU General Public License
http://www.gnu.org/copyleft/gpl.html


See also:
http://www.rncbc.org/drupal/node/886


Enjoy && keep the fun ;)
--
rncbc aka. Rui Nuno Capela
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

by rncbc.org at May 09, 2015 11:11 AM

rncbc.org

Vee One Suite 0.6.3 - A sixth beta release

As a micro dot release override, the current sixth beta release is out and crunching the earlier fifth to oblivion ;)

Howdy,

The Vee One Suite of old-school software instruments, aka. the gang of three have bumped over another tiny notch: synthv1, as one polyphonic synthesizer, samplv1, a polyphonic sampler and drumkv1, as one drum-kit sampler, are now being released to the masses. Again ;)

There's no big audible changes, if any at all, yet this sixth beta release is rather a probable bug fix for drumkv1 LV2 on Ardour (v3 and v4).

Anyway, it's all gone as follows:

  • Sample file drag-and-drop support has been added to the note element list widget (drumkv1 only).
  • Main widget layout changed as much to allow sampler display and element list to expand or grow vertically as needed (samplv1 and drumkv1).
  • Sample file path mapping has been fixed for LV2 plugin state restoration, which were preventing Ardour to reload any of the saved session or preset sample files in particular (re. drumkv1 only).
  • Custom knob/dial behavior mode options are now introduced: linear and angular (aka. radial) as far to avoid abrupt changes on first mouse click (still the default behavior).
  • Fixed for some strict tests for Qt4 vs. Qt5 configure builds.

We're still available in dual form, as business as usual:

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

Enough to tell, 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.

As always, have (lots of) fun :)

synthv1 - an old-school polyphonic synthesizer

synthv1 0.6.3 (sixth 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.6.3 (sixth 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.6.3 (sixth official beta) is out!

drumkv1 is 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 && keep the fun ;)

by rncbc at May 09, 2015 10:30 AM