planet.linuxaudio.org

April 23, 2014

linux.autostatic.com » linux.autostatic.com

Wolfson Audio Card for Raspberry Pi

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


Wolfson Audio Card for Raspberry Pi

by Jeremy at April 23, 2014 04:36 PM

GStreamer News

GNonLin and GStreamer Editing Services 1.2.1 stable release

The GStreamer team is pleased to announce a new release of the stable 1.2 release series of GStreamer Editing Services and GNonLin.

Check out the GES release notes here or download tarballs from here.

Check out the GNonLin release notes here or download tarballs from here.

April 23, 2014 02:00 PM

zthmusic

LAC14 Interview Series #3: Albert Graef

The LAC14 interview series is a series of short interviews with people who are and have been involved with the LAC throughout the years. Find all posts in the series on this link. Hi Albert! Could you give a brief … Continued

The post LAC14 Interview Series #3: Albert Graef appeared first on zthmusic.

by zth at April 23, 2014 10:00 AM

April 22, 2014

zthmusic

LAC14 Interview Series #2: Robin Gareus

The LAC14 interview series is a series of short interviews with people who are and have been involved with the LAC throughout the years. Find all posts in the series on this link. Hi Robin! Could you give a brief … Continued

The post LAC14 Interview Series #2: Robin Gareus appeared first on zthmusic.

by zth at April 22, 2014 10:00 AM

ardour

Outbound email problems (registration, etc.)

Starting sometime on April 19th 2014, ardour.org began having problems delivering email. This affected the emails sent after registering a new user account, among other things.

The problem was caused by time drifting so much that the email server we use to deliver mail was more than 5 minutes off ardour.org's own time, and this caused the server to reject mail. For some reason, ardour.org's email system appears to have discarded the email messages rather than requeued them for later delivery. The problem has now been fixed but it appears that the undelivered messages are lost for all time, like tears in the rain.

If you registered on ardour.org during the period April 19th-21st 2014 and did not get the confirmation email, please ause the "Request new password" link under the login section to generate a new password. Apologies for the inconvenience.

read more

by paul at April 22, 2014 01:53 AM

April 21, 2014

KXStudio News

The first Carla 2.0 beta is here!

Carla 2.0 is a full rework of the first Carla release.
It's currently under development with a planned release later this year.
Today the first beta is released, and we'll show you what to expect when the final version arrives.

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

DISCLAIMER: This is a beta release! Although all features mentioned here are working right now, they may be incomplete, have bugs or even eat your cat!
You've been warned.

Highlights

new-look

Canvas Integration

When using the JACK multi-client mode, plugins will be mapped to their respective canvas group.
Double-clicking the plugin group will show its UI, while pressing 'delete' will remove the actual plugin.
There's extra right-click options, and the keyboard and meters will react accordingly.


new-look

New Look

Each plugin gets its own slot skin.
Different colors are attributed to each kind of plugin (EQ, delay, distortion, etc).
Specialized skins that match the author/maker are used when appropriate.


new-look

Carla-Rack as a Plugin

Carla itself working as a plugin (rack-mode).
This allows to use several rack instances inside a single Carla instance.
Internal patch-bay mode is also planned, but probably only for 3.0.


new-look

Internal plugins as LV2

Carla internal plugins are now exported as LV2.
This includes carla-rack and zynaddsubfx!
Plugins that released separately (such as DISTRHO and ZamAudio) are not included.


new-look

Plugin Bridges

Running plugins in a separate process for crash-protection.
Using a separate process also makes it possible to load plugins with a different architecture from the host,
such as 32-bit plugins on 64-bit Carla and Windows plugins in Linux.

NOTE: This feature is currently only available within the KXStudio repos.


More stuff

  • Qt5 ready (already used in Windows builds)
  • Save and restore canvas connections
  • LV2 CV ports and Worker extension are now implemented, allowing to load ams-lv2 and setBfree among other plugins
  • VST3 and AU plugin support

There's some other things planned, but they might be delayed until 3.0 so that this release doesn't take too long to happen.
You can find the complete TODO list here:
https://raw.github.com/falkTX/Carla/master/doc/Carla-TODO.

by falkTX at April 21, 2014 11:00 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Short interview series about LAC14

From: Gabriel Nordeborn <gabbe.nord@...>
Subject: [LAA] Short interview series about LAC14
Date: Apr 21, 4:52 pm 2014

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

I'm attending the Linux Audio Conference for the first time this year,
which is going to be awesome. I decided to reincarnate the Friday Interview
by doing a short interview series with people who are or have been involved
with the LAC throughout the years, as a way of getting to know the
conference better.

I'll try and publish as many interviews as possible before LAC. Check it
out at: http://www.zthmusic.com/lac14-interview-series/

Cheers,
Gabriel/zth

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

I'm attending the Linux Audio Conference for the =
first time this year, which is going to be awesome. I decided to reincarnat=
e the Friday Interview by doing a short interview series with people who ar=
e or have been involved with the LAC throughout the years, as a way of gett=
ing to know the conference better.


I'll try and publish as many interviews as possible before LAC. Che=
ck it out at: h=
ttp://www.zthmusic.com/lac14-interview-series/


Cheers,

Gabriel/zth


--047d7b4179976a5f1404f7904b27--

read more

April 21, 2014 05:00 PM

zthmusic

LAC14 Interview Series #1: Miller Puckette

The LAC14 interview series is a series of short interviews with people who are and have been involved with the LAC throughout the years. Find all posts in the series on this link. Hi Miller! Could you give a brief … Continued

The post LAC14 Interview Series #1: Miller Puckette appeared first on zthmusic.

by zth at April 21, 2014 04:18 PM

Interview series for LAC 2014

LAC, the Linux Audio Conference, is a once-a-year conference starring the latest and the greatest of the Linux audio world. The LAC this year takes place in Karlsruhe, Germany and will be held from the 1st to the 4th of … Continued

The post Interview series for LAC 2014 appeared first on zthmusic.

by zth at April 21, 2014 04:16 PM

April 20, 2014

Linux Muso

What is going on!?

facebooktwittermail

It’s been a while since I posted anything because life just happens. My good friend Michel died this month, that is his picture. He will be missed RIP mate! No fear, I haven’t given up on this music production with Linux quest. Recording music just has been on the back burner a bit. Like everything in nature things come in waves of creation, decay, rebirth. I do have had thinking time to contemplate some directions I want to take in my art. I’m very dedicated to technology but sometimes it just seems like work and no play. Combinations of my interests, Fantasy literature, T.C.G’s, music in general, and Metal keeps me all kinds of sane, occupied and inspired. If you see me hanging around the social water tanks I’m fine with shooting the breeze for a bit. CYa

 

facebooktwitterrss

by PeteV at April 20, 2014 10:06 PM

GStreamer News

GStreamer Core and Plugins 1.2.4 stable release

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

Binaries for Android, iOS, OS X and Windows are also provided.

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

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

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

April 20, 2014 12:00 AM

April 19, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Fwd: Call for Works: SEAMUS Electroacoustic Miniatures 2014

From: Keith Kirchoff <keithkirchoff@...>
Subject: [LAA] Fwd: Call for Works: SEAMUS Electroacoustic Miniatures 2014
Date: Apr 19, 2:39 pm 2014

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

**apologies for any cross posting**

*SEAMUS Electroacoustic Miniatures 2014: Transients*

The SEAMUS Electroacoustic Miniatures Series is an annual album release of
fixed-media works addressing a specific theme which has been devised by the
adjudication committee. The albums will be made commercially available via
all major online music distributors as well as the SEAMUS website.

Works on short time scales, such as the miniature or the poem, often afford
a paradoxical potency and clarity. Or they can permit flashes of whimsy,
fancy, and oddity. This year's theme, "Transients," invites consideration
of the momentary and the succinct, but also the transitory, the ephemeral,
and the evanescent.

All SEAMUS members are eligible and invited to submit one fixed-media
composition (recordings of live performance pieces are not accepted), up to
three minutes in length, to be considered for inclusion. There is no
application fee. All submissions must be complete works (no
works-in-progress) and must be received by *June 15, 2014. *Composers are
responsible for all clearances and licensing required for materials they
use in their submissions; SEAMUS will not pay for sample licenses of
copyrighted materials. Please include brief program notes.

The adjudication committee will evaluate each submission based on the
following criteria:
- Adherence to the theme
- Creative and coherent exploration of thematic possibilities
- Musicality
- Technical quality

Submission procedures:
- Fill out all the fields in the official application
form(
goo.gl/8K9j42)
- Your submission must be a wav or aif file, with a 44.1K sample rate and
16 bit resolution
- Your submission file must be titled with only the title of the composition
- Upload the file to Dropbox or another similar file hosting service
- Post the link to the file in the appropriate field on the form
- Any submissions containing identifying information in the file name or
link will be disqualified

Questions regarding the submission process may be directed to Keith
Kirchoff at keithkirchoff@gmail.com

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


sans-serif">**apologies for any cross posting**

fault" style=3D"font-family:verdana,sans-serif">

il_quote">


rif">SEAMUS=C2=A0Electroacoustic Miniatures 2014:=C2=A0Transients
ont>

=3D"font-size:12px">



The SEAMUS Elect=
roacoustic Miniatures Series is an annual album release of fixed-media work=
s addressing a specific theme which has been devised by the adjudication co=
mmittee. The albums will be made commercially available via all major onlin=
e music distributors as well as the SEAMUS website.






pre-wrap;font-size:13px">Works on short time scales, such as the miniature =
or the poem, often afford a paradoxical potency and clarity. Or they can pe=
rmit flashes of whimsy, fancy, and oddity. This year's theme, "Tra=
nsients," invites consideration of the momentary and the succinct, but=
also the transitory, the ephemeral, [message continues]

read more

April 19, 2014 03:00 PM

April 18, 2014

Hackaday» digital audio hacks

DIY Gas Can Speakers Blast Your Tunes

Gas Can Speaker

Have you ever wanted to build your own speakers, but were a bit overwhelmed with all the information out there on cases and packaging? A recent Instructable by [Txje] goes over how to build a set of simple gas can speakers.

While using gas cans as speaker housings will not result in the best audiophile quality sound or be the cheapest option out there, it sure looks awesome, and is a great way to get started with building your own speakers. After testing out the speakers and electronics, holes in the gas cans are cut and the terminals and speakers are installed. “As an added bonus, the pour spout serves to release pressure in the speaker can. You can get everything you need for ~$69 from Amazon and/or Home Depot.” Not a bad price point for two very cool looking speakers.  Once you have built the speakers, now you can experiment with different fill material to see what results in better sound quality.

This is a simple, yet fun looking build. Something like this can make a nice gift for someone who spends a lot of time in their garage. What other crazy objects have you used for speaker enclosures?


Filed under: digital audio hacks

by Nicholas Conn at April 18, 2014 05:00 PM

Linuxaudio.org

Linux Audio Conference 2014

The 2014 edition of the Linux Audio Conference, the twelfth installment of the conference, will take place at the ZKM, Karlsruhe, Germany, the place where it all started. For all information and registration, visit the LAC 2014 website.

by robin at April 18, 2014 02:34 PM

GStreamer News

Orc 0.4.19 bug-fix release

The GStreamer team announces another maintenance bug-fix release of liborc, the Optimized Inner Loop Runtime Compiler. It contains:

  • Fix out-of-tree builds
  • Fix many memory leaks, compiler warnings and coverity warnings
  • Documentation fix for mulhsw, mulhuw

Direct tarball download: orc-0.4.19.

April 18, 2014 11:00 AM

Hackaday» digital audio hacks

Raspberry Pi Remote Audio Link

Hardware for remote audio link

 

In broadcast, lots of people are still using dedicated analog lines to connect remote sites. These operate like old telephone systems: you call up the operator and request to be patched through to a specific site. They’re also rather expensive.

For a hospital radio station, [Marc] wanted to replace the old system with something less costly. The result is his Raspberry Pi STL in a Box. Inside the box is a Raspberry Pi, PiFace display, a pair of meters, and some analog hardware for the audio.

On the software side, the system uses LiquidSoap to manage the stream. LiquidSoap uses a language to configure streams, and [Marc] has a write-up on how to configure LiquidSoap for this application. On the hardware side, SSM2142 ICs convert the signal from single-ended to balanced. The meters use the LM3915 bar drivers to control the meters.

The Python script that controls the box is provided, and could be helpful for anyone needing to build their own low-cost audio link.

 


Filed under: digital audio hacks

by Eric Evenchick at April 18, 2014 05:00 AM

April 17, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Guitarix 0.29.0 released

From: hermann meyer <brummer-@...>
Subject: [LAA] Guitarix 0.29.0 released
Date: Apr 17, 8:40 pm 2014


--------------070104090008000704030401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The Guitarix developers proudly present

Guitarix release 0.29.0

For the uninitiated, Guitarix is a tube amplifier simulation for
jack, with effect modules and an additional stereo effect chain.

Among with a couple changes in the source and some bug-fixes, this
relase comes with a couple of new plugs (gx & LV2), were most of them
comes from our new Development Member Fedor Uporov.
The Simulation plugs been developed with the new Analog Circuit
Simulation Toolkit by Andreas Degert.

new plugs:
* Record Mono/Stereo (gx)
* JCM800PRE (Preamp simulation) (gx)
* GCB_95 (WahWah simulation) (gx)
* Duck Delay Mono/Stereo (gx / LV2)
* Reverse Delay (gx)
* Graphic EQ (gx / LV2)
* Ring Modulator Mono/Stereo (gx)
* Plate Reverb (gx)
* Panorama Enhancer (gx)
* Bass Enhancer (gx)
* BarkGraphicEQ (24band LV2)

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

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

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

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




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




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



The Guitarix developers proudly present




Guitarix release 0.29.0





For the uninitiated, Guitarix is a tube amplifier simulation
for

jack, with effect modules and an additional stereo effect
chain.



Among with a couple changes in the source and some bug-fixes,
this relase comes with a couple of new plugs (gx & LV2),
were most of them comes from our new Development Member Fedor
Uporov.

The Simulation plugs been developed with the new  Analog Circuit
Simulation Toolkit by Andreas Degert.



new plugs:

                * Record Mono/Stereo (gx)

                * JCM800PRE (Preamp simulation) (gx)

                * GCB_95 (WahWah simulation) (gx)

                * Duck Delay Mono/Stereo (gx / LV2)

                * Reverse Delay (gx)

                * Graphic EQ (gx / LV2)

                * Ring Modulator Mono/Stereo (gx)

                * Plate Reverb (gx)

                * Panorama Enhancer (gx)

[message continues]

read more

April 17, 2014 09:01 PM

Ubuntu Studio » News

Ubuntu Studio 14.04 LTS Final Release is out!

We’re happy to announce our latest LTS release. Ubuntu Studio 14.04 will be supported for three years. Since it’s just out, you may experience some problems. Read about them under known issues. Short list of new features: The installer has a new plugin which allows you to choose which packages to install out of our […]

by Kaj Ailomaa at April 17, 2014 08:25 PM

Open Source Musician Podcast

Open Source Musician Podcast Episode #69 - Latency


OSMP Ep. 69 - Mearuring Latency, Gentoo Studio, and a Song
-Interested in making your own episode of the OSMP? Email: contributions@opensourcemusician.com

-Using a mic to measure real world latency,
-http://gentoostudio.org/

-1 Ton Tomato by ssj71

April 17, 2014 03:19 PM

Recent changes to blog

Guitarix 0.29.0 released

The Guitarix developers proudly present

Guitarix release 0.29.0

For the uninitiated, Guitarix is a tube amplifier simulation for
jack, with effect modules and an additional stereo effect chain.

Among with a couple changes in the source and some bug-fixes, this relase comes with a couple of new plugs (gx & LV2), were most of them comes from our new Development Member Fedor Uporov.
The Simulation plugs been developed with the new Analog Circuit Simulation Toolkit by Andreas Degert.

new plugs:
* Record Mono/Stereo (gx)
* JCM800PRE (Preamp simulation) (gx)
* GCB_95 (WahWah simulation) (gx)
* Duck Delay Mono/Stereo (gx / LV2)
* Reverse Delay (gx)
* Graphic EQ (gx / LV2)
* Ring Modulator Mono/Stereo (gx)
* Plate Reverb (gx)
* Panorama Enhancer (gx)
* Bass Enhancer (gx)
* BarkGraphicEQ (24band LV2)

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

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

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

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

by brummer at April 17, 2014 09:27 AM

April 16, 2014

Scores of Beauty

Using special characters from SMuFL fonts

Recently Joram Berger gave an introduction to Steinberg’s proposed new font standard, Standard Music Font Layout SMuFL and its possible use in LilyPond. He also compared LilyPond’s Feta font and Bravura, the only SMuFL font that is currently available. In addition I would like to expand on some specific cases where accessing specific SMuFL glyphs can become handy in solving specific notational problems. But I promise to put in some useful tips also for the LilyPond user more interested in solutions using the regular Feta font.

Bravura glyphs in a Feta context

In the music example in the mentioned post SMuFL Fonts in LilyPond there’s a niente symbol present in the Bravura part but not in the default Feta part. (This is mentioned in the comments but not in the text.) This could be good news for the engraver who needs a niente glyph and is willing to otherwise accept the appearance of the output with Bravura font. But as Joram mentions in the text: “There are still open issues with the integration of SMuFL with LilyPond, therefore the use of Bravura in LilyPond cannot be recommended for publication quality scores, yet.”

In the case of the niente symbol the problem is admittingly not huge; the symbol can quite easily be produced with an italic ‘n’ with markup. But there are other glyphs that are not so easily to achieve. In the comparison between Feta and Bravura Joram lists examples of glyphs that are present in Bravura but not in Feta. While there always seem to be a way to accomplish things natively in LilyPond, especially if you’re a competent Scheme programmer, I think it’s nice to know that almost any music-related glyph can be accessed directly in the Bravura library.

But if it’s not an alternative yet to use the Bravura font in LilyPond, why would it help if a glyph is present in that font? While it’s not recommended to use the Bravura font as an complete replacement to Feta, the main obstacle against using individual glyphs from Bravura in a Feta context is that they may not look completely compatible. Setting the problem of compability aside I think this is an interesting technique and I’ll give you some samples of it in this post.

Simple Markup

I’ll come back to some of the notational elements in Jorams list in a moment, but first I would like to discuss an example which was discussed on the LilyPond users mailing list. Urs requested a symbol which in the Bravura font map is called “Unstress” ( ˘ ), and can be compared to the sign that denotes light syllables in a poem. This then is an unusual kind of articulation not easily achieved with the Feta font but accessible in Bravura. The key how to access it is in Jorams post; he mentions two useful commands \smuflglyph and \smuflchar. With the first you use the name of the glyph and with the second you use the hexadecimal number. These commands can be put in a markup context. Here is the example with the ‘unstress’ glyph: (The include call assumes the presence of a path to the snippets repository, and will be omitted for the rest of the post.)

\include "custom-music-fonts/smufl/definitions.ily" 

\relative c'{
  \stemUp
  f4 _\markup { \smuflchar #  #xE486 } % Unstress below
  r4
  \stemDown
  f'4 ^\markup { \smuflchar ##xE485 } % Unstress above
  r4
}

unstress
In a similar way you can use any SMuFL character in a markup. This example already shows the pros and cons of the approach: It is easy to use any glyph from the comprehensive SMuFL standard this way, but the glyphs in this example don’t really go well together with the Feta articulations style. But at least you do have them available.

An alternative without using SMuFL is to look in an utf-8/unicode character table and see if you can find what you’re looking for. Then you can use the regular \char command or just paste the character directly (provided the font actually contains the respective glyphs). I found for example this ‘˘’ unstress symbol. Read more about using special characters in LilyPond’s documentation.

Changing tremolo glyph

To use SMuFL glyphs in a markup was pretty straightforward I think. Now for something more difficult. A while back I engraved a score with a tremolo symbol that’s not in the usual LilyPond repertoire. It looks like a ‘z’ across the stem, and I’ve learned that it’s called a Penderecki tremolo after the composer Krzysztof Penderecki. (You may know it as a buzz roll, but in the SMuFL library they’re actually two different glyphs.)

As this symbol is in the extensive SMuFL library my idea was to use this to achieve the requested notation. In the SMuFL library there are two glyphs, one that is just the ‘z’ and one that includes the whole stem (with the ‘z’). My initial idea was to change the whole stem. But in fact that’s unnecessary; it’s better to only change the tremolo symbol. The proper solution was given by Nathan Ho, and reads like this:

#(define (penderecki-tremolo grob) 
   (grob-interpret-markup grob 
     (markup #:vcenter #:smuflglyph "pendereckiTremolo"))) 

\new Staff { 
  \override StemTremolo.stencil = #penderecki-tremolo 
  c'4:32 d'4:32 e'4:32 f'4:32 
  c''4:32 d''4:32 e''4:32 f''4:32 
}

flz-with-z
Again as an alternative could you not just use a ‘z’ instead of the SMuFL glyph? It would be something like this :

#(define (z-tremolo grob) 
   (grob-interpret-markup grob 
     (markup #:vcenter #:halign CENTER #:bold "z"))) 

\new Staff { 
  \override StemTremolo.stencil = #z-tremolo 
  c'4:32 d'4:32 e'4:32 f'4:32 
  c''4:32 d''4:32 e''4:32 f''4:32 
}

z-tremolo
In my opinioin using an ordinary ‘z’ doesn’t look as good as the dedicated SMuFL glyph, although I’m sure there’s a better non-SMuFL solution. Please put any suggestions in the comments.

Clusters

One of the things that was mentioned in Joram’s (second) post was the possible use of SMuFL for producing cluster notation. I would like to show how this can be done in actual examples. First I will change the notehead into a cluster notehead. I use a very similar technique to the one from the previous example:

#(define (white-cluster grob)
   (grob-interpret-markup grob
     (markup #:vcenter #:smuflglyph "noteheadClusterSquareWhite")))

\new Staff {
  \override NoteHead.stencil = #white-cluster
  \time 4/2
  c''4 c''4 c''2 c''1 c''\breve
}

smufl-clustersI
The same technique can of course also be used to change the notehead to any other appropriate SMuFL glyph. Just change the glyph name, and by all means also the function name.

Next we want to have different note heads for the different note values. I then use an adaptation of the code for producing ordinary SMuFL noteheads in the snippets repository:

#(define (cluster-notehead grob)
   (let* ((log (ly:grob-property grob 'duration-log))
          (style (ly:grob-property grob 'style)))
     (grob-interpret-markup grob
       (cond
        ((<= log -1) (markup #:vcenter #:smuflglyph
                       "noteheadClusterDoubleWhole3rd"))
        ((<= log 0) (markup #:vcenter #:smuflglyph
                      "noteheadClusterWhole3rd"))
        ((<= log 1) (markup #:vcenter #:smuflglyph
                      "noteheadClusterHalf3rd"))
        (else  (markup #:vcenter #:smuflglyph
                 "noteheadClusterQuarter3rd"))))))

\new Staff {
  \override NoteHead.stencil = #cluster-notehead
  \time 4/2
  c''4 c''4 c''2 c''1 c''\breve
}

smufl-clustersII
But in the image from Joram’s post some of the clusters were covering more of the staff (and some the whole staff) – well, that’s the point of clusters, isn’t it, to be more flexible in their pitch range. But how can this be achieved? Remember the swirling vibrato spanner from the same post? These are both achieved by an additional feature of the SMuFL glyphs; they can be combined.

\markup {
  \override #'(baseline-skip . 0)
  \column {
    \smuflglyph #"noteheadClusterHalfTop"
    \smuflglyph #"noteheadClusterHalfMiddle"
    \smuflglyph #"noteheadClusterHalfMiddle"
    \smuflglyph #"noteheadClusterHalfBottom"
  }
}

smufl-clustersIII
But how on earth could I make use of this markup as an actual notehead? Not knowing exactly how to translate this to scheme readable code in a function the easiest trick is to turn to the old helper \displayMusic (which is a bit awkward when it contains no music but only markup). With its help I could determine that the necessary code is this:

#(define (big-cluster grob)
   (grob-interpret-markup grob
     (markup
      (#:override
       (cons (quote baseline-skip) 0)
       (#:column
        (#:smuflglyph
         "noteheadClusterHalfTop"
         #:smuflglyph
         "noteheadClusterHalfMiddle"
         #:smuflglyph
         "noteheadClusterHalfMiddle"
         #:smuflglyph
         "noteheadClusterHalfMiddle"
         #:smuflglyph
         "noteheadClusterHalfBottom"))))))

\new Staff {
  \override NoteHead.stencil = #big-cluster
  \time 4/2
  e''\breve
}

smufl-clustersIV
The next step beyond this is to let the user of the function decide the height of the cluster note head, i.e. how many of the middle glyphs to put in. I leave the solution for this open as a challenge for the reader (maybe it will show up in the comments). Of course it should reflect the actual range of the cluster so it should be possible to provide the top and bottom notes as arguments.

Would there be an alternative without resorting to SMuFL? Well, LilyPond is quite powerful when it comes to creating graphics in markup, so I’m sure it’s possible to achieve customized cluster noteheads and make them accessible through easy-to-use functions. I’ll give you a simple filled box as an example to end off:

#(define (boxfill-cluster grob)
   (grob-interpret-markup grob
     (markup
      (#:filled-box (cons 0 1.6) (cons -1 2) 0.3))))

\new Staff {
  \override NoteHead.stencil = #boxfill-cluster
  \time 4/4
  c''4 c''4
}

smufl-clustersV

by Peter Bjuhr at April 16, 2014 06:08 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] open call: CAC.4 Computer Art Congress - Rio de Janeiro 2014

From: Robin Gareus <robin@...>
Subject: [LAA] open call: CAC.4 Computer Art Congress - Rio de Janeiro 2014
Date: Apr 16, 5:51 pm 2014

Fourth Computer Art Congress - CAC.4: Computer Art and Design for All

School of Fine Arts of the Federal University of Rio de Janeiro

Call for papers, posters, workshops, tutorials and exhibition are open
at http://cac4.eba.ufrj.br

*Deadline: May 12th, 2014*
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

April 16, 2014 06:01 PM

[LAA] OT: Network Music Festival 2014 // OPEN CALL

From: Holger <mortuos.plango@...>
Subject: [LAA] OT: Network Music Festival 2014 // OPEN CALL
Date: Apr 16, 5:26 pm 2014

*Network Music Festival // 26-28th September 2014 // Birmingham (UK)*
http://networkmusicfestival.org/about/

The third *Network Music Festival* will take place *26-28th September
2014 *in *Birmingham (UK)*. Exploring innovative digital music, art and
research which investigates the impact of networking technology on
musical creation and performance practice, Network Music Festival will
host a weekend of musical performances, installations, workshops, talks
and other activities.

*Open Calls*
http://networkmusicfestival.org/open-call/


*DEADLINE FOR ALL SUBMISSIONS: 16th May 2014*

The Network Music Festival 2013 is now inviting submissions in the
categories of:
- *Performances (Concert, Club, Multi-channel, Telematic, Algorave)*
*- Collaborative Live Coding Environments*
*- Installations*
*- Talks*
*- Workshops*
We also include an ‘Other
’ category where you
are free to submit proposals that fall outside of the previous
categories but that you feel would be an appropriate addition to the
festival programme.

Although we aim to showcase a broad spectrum of approaches to network
music, we particularly encourage submissions that fall under the year’s
theme of *collaboration through online environments and networked live
coding*.

For more information on submission categories and for submission forms
please go to: http://networkmusicfestival.org/open-call/


Any questions email networkmusicfestival@gmail.com
with ‘OPEN CALL’ in the subject
line.

*DEADLINE FOR ALL SUBMISSIONS: 16th May 2014*
networkmusicfestival.org
// @netmusicfest
// facebook.com/networkmusicfestival

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

read more

April 16, 2014 06:01 PM

Create Digital Music » Linux

The $100 BeatStep Sequencer and Controller: Everything You Want to Know [Review, Resources]

beatstep_angled

Even if Arturia’s BeatStep did nothing other than act as a dumb controller, it might get your attention.

The compact control surface / sequencer hardware runs about $100 street. As a controller, it has both 16 pads and 16 endless encoders (with notches, so you can feel where you are), plus transport triggers and a larger encoder. With driverless USB operation, some of you will already be happy and can proceed.

But the BeatStep is more ambitious than that. It has sophisticated software customization via a companion program, and a built-in step sequencer. It operates standalone, with MIDI gadgets or analog hardware (with gate and pitch Control Voltage outputs). It could therefore be a compact part of a mobile music-making rig, and it’s at this point that our review gets much more involved. The BeatStep has an impressive lineage – veteran designers Glen Darcey, Axel Hartmann, and Morgan Perrier collaborated on its creation. So there’s a reason to set expectations high.

I’ve been testing the Arturia BeatStep with just those functions in mind. And we’ve collected some of your tips and questions, with information that might help you out whether you’re trying to decide whether to buy or curious just how deep this goes.

The BeatStep already makes a nice controller with pads and encoders. But how much more can it be? Let’s find out.

beatstep_macbook_lit

beatstep_io

Physical Form Factor, Control

Let’s start with the controller bit. The BeatStep is narrower than a 15″ MacBook Pro, as you can see in the photo, and roughly laptop thickness. It is, though, surprisingly weighty – in a good way. A metal base holds it firmly in place even if your finger drumming gets more intense.

The pads feel reasonably good; they’re smallish but feel firm and velocity response (and continuous pressure) are consistent. The encoders are likewise satisfying, with basic soft-touch caps. I’ve already taken mine on the road and it appears to hold up well; my only gripe is some sharper edges round the base, but that’s minor. All in all, this is already no contest: this feels better than any comparable controller at this price.

That said, even as a controller, you’ll immediately notice the absence of a display. While it keeps the unit small and inexpensive, this means you have no idea where you are on those endless encoders; there’s simply no visual feedback to speak of.

MIDI mapping is extensive. There’s just a whole lot you can control:

  • Custom CC mappings. Of course. Nicely, they’ve also included standard MIDI descriptions.
  • Absolute and relative modes for the knobs – either sending a range from 0-127 (or less, if you designate), or increment/decrement in ways compatible with various software. (Ableton Live is specifically supported, which is good, because Ableton’s MIDI implementation in that regard is … um … requires specific compatibility considerations. There. And this works.)
  • Knob acceleration. Fast, medium, or off (“slow”).
  • Pad velocity curves. Linear, Logarithmic, Exponential, or “Full”.
  • Scales. You can control a variety of scales/modes from the front panel of the unit, live, or set them separately in software. One scale is set to a user scale for your own collection of pitches. (Once you go octatonic…)
  • Templates. There’s preset save/recall, too, for all your templates, with up to 16 slots.

You can even set custom MIDI messages to the Play and Stop buttons, for various kinds of transport control or using them simply as MIDI Control Change triggers.

There’s very little you can’t do from software. The exceptions: LED function (red, blue, or mixed for purple) is fixed on the unit. And the six control buttons on the left are necessarily non-assignable. Everything else, though, is up for grabs, in a seriously sophisticated piece of controller software the BeatStep shares with the rest of the Arturia family.

And it has to be the nicest piece of controller software I’ve seen. Heck, there’s even a detailed MIDI message console.

In controller mode, thanks to the scale controls, the BeatStep is also a reasonable melodic input device in a pinch – though, of course, 2×8 pads is not the optimal configuration for that job with devices like Ableton Push on the market. (And, you know, keyboards.) It’s nice having the option, though, and more on those scales in a moment.

Ins and outs: you get 3.5 mm (minijack) MIDI output – the breakout to standard MIDI DIN is included right in the box – plus 3.5mm jacks for CV and gate output.

beatstep_seq

midicontrolcenter

Step Sequencer Operation

Now, on to the fun part — yes, the BeatStep can work as a step sequencer.

The good news: it’s simple and enjoyable, and it works standalone. The bad news: you may wind up doing some prep work in advance, because live modes are at the moment somewhat limited on the hardware itself. Let me explain. Here’s how it works:

Modes. The BeatStep has independent modes for its two features. In CNTRL mode, it’s a controller. In SEQ mode, it’s a step sequencer. That allows you to use these two modes as independent layers of functionality, and there’s helpful feedback to let you know where you are. In controller mode, everything lights blue; in SEQ mode, pads are red when you tap them and the active step is blue. Those lights are bright, so you may feel a little bit like you’re playing from the hood of a State Trooper’s car (shame there’s no brightness adjustment), but you can at least stay oriented.

Pitch. By default, each encoder is set to adjust pitch chromatically. The large Transpose encoder changes the pitch of the entire sequence overall. Now, because you can also set modes like major, minor, Blues, and User, you can more easily dial in the notes you want – nice.

Clock. You can receive clock messages from a computer over USB. That’s unfortunately the only clock source (analog or digital), so most likely you’ll want your BeatStep as your master if you’re using it standalone. There’s no CV input, and no MIDI input apart from USB. (One alternative would be using a box like the iConnectMIDI that acts as a USB bridge. That’s not too bad a tradeoff, given how small the Arturia piece is, and since you might want a thru box anyway.)

Pattern direction. Nothing too fancy here, but you can play patterns forward, backward, randomize the steps, or “alternate” (forward, then backward – basically ping-pong).

On-the-fly pattern storage and recall. Does what it says on the tin: save up to 16 presets, recall up to 16 presets. Where this gets interesting is again in the software. The editor displays musical notation for each pattern. That means you can get really fussy programming your patterns before a gig, and have them ready to go.

Pattern length, step length, and a really, really huge caveat. You can also change the step length (thus speeding up the pattern), by 1/4, 1/8, 1/16, 1/32, or by holding down SHIFT, change the pattern length to less than 16 steps for some syncopation.

The caveat is, with the current firmware, a pattern immediately retriggers the moment you touch any of these controls, when you touch them. So, while the pattern still clocks to the tempo of an external source, you’re now very much not in sync on a downbeat. Arturia acknowledged this issue to CDM, and suggests it should be addressed in a firmware update. For now, I’d say this is a deal-killer for certain applications. Using it was exciting – enough so that I’m saving this firmware dump in case Arturia does ever fix it. You can play elaborate syncopations live. It’s just a little too exciting: there’s a reason step sequencers of this kind normally have at least a mode that syncs either to the downbeat or at least the active step size. The BeatStep right now does neither of those, clocking patterns free and potentially causing rhythmic train wrecks.

The one fix, oddly, is recalling a pattern; that starts the pattern on the beat again.

I’ll be watching for that firmware update.

Swing. Swing is another major oversight – which also makes the BeatStep feel more like a software product rather than hardware product. Swing can be set per-sequence, but not on the hardware. You have to launch the editor and adjust it; it’s non real-time.

beatstep_scales

beatstep_litup

Bottom Line: Hugely Powerful Controller and Software, Great Value, Limited Sequencer

The BeatStep is a whole lot of fun. As a controller, I wouldn’t hesitate to recommend it. You simply can’t get better editing functions or controller feel at this price. And honestly, having been attracted to the BeatStep for its control layout and standalone sequencer functions, I’m forced to take a second look at Arturia’s whole control range; it’s that good.

Getting a sequencer, standalone operation, MIDI, and CV in the deal means it is going to be a must-buy for a lot of people.

The problem is, that sequencer experience is still incomplete. You get 16 steps: no more, no chaining, no “B” sequence. Arturia even pitches this as a companion to the iPad, but the iPad has easily half a dozen step sequencers that best this one. And the issue with being unable to change step or pattern length easily is a big minus. Add to that the inability to set swing from the main panel, and this feels like it just isn’t a fully-formed sequencer. It’s a nice extra on a fantastic controller, but not the standalone sequencer some of us hoped for.

I expect some of this to be improved in a firmware update. But the other issue is, simply, Arturia has created a very compact controller and there just isn’t room for more functionality. An LED would make programming easier; more controls would let you perform other functions or chain together more than 16 steps.

For now, I’m willing to make those tradeoffs on the BeatStep because it is so inexpensive and light. And it’s not that I wouldn’t use this as a step sequencer – I continue to do that. The powerful editor and notation view mean that you can load up 16 sequences and carry them with you, and the combination of encoders with scale modes is great.

But Arturia, a BeatStep Pro seems a logical next step. And in the meantime, I’m keeping my eyes out for a standalone device that operates together with a computer. While it has an ugly, shiny-silver faceplate, the M-Audio Trigger Finger Pro has all the layers, extra steps, visual feedback, and spacious pad and control layout that the BeatStep lacks – and it will operate standalone, too. The BeatStep has made me oddly more hungry for this kind of hybrid device, so I look forward to InMusic shipping that.

As for the BeatStep: I can’t say no to this one. Even with its drawbacks, it’s easily become an essential piece of gear. So – on to the tips.

More Tips, Tutorials, and Background

Hack: SpeedDialer. Now, I like slowly turning through values, but apparently not everyone does. From maxforlive.com, a Max patch that addresses that. Also, I expect more M4L goodness once this device gets in more hands.

speeddialer

The Arturia Beatstep is a great device, but with its current firmware the encoders are much too slow. It takes 5 turnes to get thru all 128 values.
I made this speeddialer to make fast movements possible. Just give a speedfactor (around 5 is good for me).
You see two dials – the small one shows the real value, the second, bigger one shows the multiplied value which can be mapped to any function within Ableton Live.
The values are interpolated with a ramp, so you should not hear any glitches.

BeatStep SpeedDialer @maxforlive.com

Source Distribution has a great interview with Glen about the hardware’s creation, as well as a nice Jupiter demo with a plug-in.

AudioCentral Magazine shows how this can look with a full MIDI hardware setup:

And Arturia has a series of tutorial videos/demos of their own, shot inside the load program for The Matrix:

Addendum: CV Operation

There’s not a lot to say about analog operation – this is straightforward output of gate and pitch – but here’s the basic picture.

Control Voltage (that’s the pitch output): 1 Volt/octave, from 0V to 7V
Gate output: 8 Volts

Now, if that isn’t what your gear is expecting, there are ways of converting.

What’s cool is, you can send almost anything over that CV out:

1. Pitch, as played from the pads.
2. Sequencer information, as recalled from the step sequencer.
3. Any output from your computer – meaning, like the also-very-useful QuNexus, the BeatStep is a quick-and-dirty MIDI-to-CV converter for your computer.

Also of note, you can set the CV output to go with one of your 16 presets or to “global.” That way, you can always send CV (regardless of which MIDI channel is selected), or only when you specify.

But Does it Blend?

I love the BeatStep on the road. I threw one in my suitcase and connected it to my MeeBlip anode, clocking from Ableton Live (which also clocked a KORG volca beats drum machine and Native Instruments Maschine). So, all the melodic synth patterns you hear here (and some less-melodic patterns) are the BeatStep driving the MeeBlip, from a set I did recently in an underground club in Belgrade.

The post The $100 BeatStep Sequencer and Controller: Everything You Want to Know [Review, Resources] appeared first on Create Digital Music.

by Peter Kirn at April 16, 2014 03:21 PM

April 15, 2014

Music, Programming and a Cat

General Purpose Midi Import and Convert library

This is an article of the category "Let's talk about Next-Gen. Future ideas for Linux Audio" where I elaborate(!) on realistic near future improvements or unrealistic science fiction scenarios. 

 

„Does this program import midi files?“ is a very common question. In fact it might be a FAQ for all sequencers, trackers and even wave editors(oh yes... you know that happens). 

Despite all its shortcomings (which will be described in this article in some detail) the midi format is the very devil to kill. It is still used as primitive but widespread exchange format between programs or as final format in the antique General Midi Standard. .mid in all its variants and purposes is still hip!

It would be wonderful to have a software library, open source license of course, which is capable of reading midi data and generate missing & more information to end up with a good universal file format which holds many information and is a perfect starting point to import the music data into an actual program, be it a standard piano roll sequencer or something more sophisticated, like a notation edi ... Read More

April 15, 2014 03:29 PM

April 13, 2014

blog4

workshop and concert in Athens, Greece

I will be in Athens, Greece from 24. to 27. April. On 26. April 2014 I will give a Pure Data related workshop at Frown Tails, details and registration are at their website: http://www.frowntails.com/technology/piezo-pure-data

The day before I will perform as Elektronengehirn on the Electric Nights festival in Athens: http://www.medeaelectronique.com/2014/03/electric-nights-line-up


by herrsteiner (noreply@blogger.com) at April 13, 2014 12:49 PM

April 12, 2014

blog4

Raspberry Pi, best way to program it?

Continue to experiment with Raspberry Pi, still not decided which software route I should go:
Python, C, C++ with QT, or Java. For me its necessary to have access to the Raspi Cam, accelerated graphics with OpenGL ES and OpenCV. I tried Java8 and followed this steps http://www.raspberrypi.org/forums/viewtopic.php?t=73489&p=528225to get it running and it works. Framerate is low but I have to conduct more tests, it seems to run OpenGL accelerated anyway...


by herrsteiner (noreply@blogger.com) at April 12, 2014 09:07 AM

April 11, 2014

Create Digital Music » open-source

Quick Jam: Digital Warrior, Open Source Step Sequencer, Plus KORG volca beats and Bitwig

Don’t call it a comeback. Hardware step sequencing is becoming the must-have accessory for even computer users.

And the boutique Digital Warrior controller, which neatly combines knobs with colored pads, is a great solution. I’ve been messing about with the Arturia BeatStep, as well – review coming – but the Digital Warrior has some tricks of its own. It integrates nicely with Traktor, like the still-forthcoming MIDI Fighter Twist from DJ TechTools. But the reason I wouldn’t buy or recommend the DJTT piece is – no MIDI DIN connector. And that spoils the fun.

Here, the Digital Warrior is comfortable not only integrating with your computer but with MIDI gear, as well. Note the cable making its way into the volca beats. And the volca beats I think has become most popular of the volcas with good reason: the touch strip at the bottom is ideal for quick sequencing. Some of the sounds I think are better than others, but it does have a grungy and unique sound, aided by the PCM and grain controls. And, crucially, the bass drum is deep. (I remain interested to hear what Akai’s rival Rhythm Wolf will sound like, though the tiny size of the volca is perfect when you’re cramming a live rig into cramped quarters, which always seems to happen onstage – hey, half a meter square is enough for you, right?)

You can output MIDI clock (as with volca beats), or use the MIDI port as MIDI thru, turning the box into a proper MIDI interface.

Bottom line: whether working in something like Ableton or Traktor, you can layer hardware step sequences over top so that you actually have something to play (rather than waving your arms around while some scenes or tracks play automatically – bah).

Details:

Digital Warrior a compact open source Traktor Remix deck sequencer and MIDI Controller. Sequencing Korg Volca Beats through the on-board MIDI out connector.

Designer’s blog: http://tomashg.com/
Track: Sobamonk – Back and Forth (Paul Gutschmidt Remix)

More video: here’s the box driving Bitwig Studio – and did I mention I really like how Tomash, the creator, plays?

Good stuff.

volcawarrior

The post Quick Jam: Digital Warrior, Open Source Step Sequencer, Plus KORG volca beats and Bitwig appeared first on Create Digital Music.

by Peter Kirn at April 11, 2014 09:57 AM

April 10, 2014

Talk UnafraidTalk Unafraid

Real Time kernels and audio on the Raspberry Pi

A year or two ago I posted about how you could send audio over the internet with Raspberry Pis using the OpenOB project. Since then the OpenOB project has taken off, with lots of contributions from the community and lots of improvement as a result.

What hasn’t aged well is the Pi. A firmware update to fix some keyboard compatibility issues caused some serious issues with audio over IP, as both the Ethernet controller and USB sound card shared a USB bus which couldn’t operate quickly enough to handle the precise timing demands. Fortunately, the Wolfson Audio Board has come along to save the day – and it’s certainly promising.

Sadly, the kernel support for the Wolfson device isn’t in the mainline kernel yet, so that means using their custom OS image, or building our own kernel. On top of that we’d quite like a preemptible kernel to allow us to get lower latencies in userspace. This is crucial for reliable jitter-free low-latency audio, but because it’s quite niche this also means we need to apply some non-mainline patches to the Raspberry Pi kernel. The Wolfson drivers will eventually make it to the Pi kernel by default, and hopefully someone familiar with packaging for Debian/Raspbian can contribute a package to provide a real-time patched version of the kernel; but in the meantime we need to get our hands dirty. Here’s how to get a stock Raspbian image turned into a low-latency audio capable flavour, broken down and explained a bit.

A quick note about the assumptions

What I’m describing below certainly helps according to benchmarks. In some multi-day-long tests I’ve experienced a 15mS average maximum on a non-rt kernel, whereas on a -rt kernel that drops to 110uS (that’s microseconds, not milliseconds), using the cyclictest program from the rt-tests kernel repository. Making that improvement translate to better audio performance is not automatic – there is additional work required to configure ALSA and any userspace programs you’re using.

Some other assumptions:

  • We’re building for the 3.10.25 kernel. If your Pi ships with a more up to date kernel (as it will if this post is older than a few months hopefully), you’ll need to locate alternative patches (the -rt patchsets are regularly updated, but the Wolfson drivers may not be)
  • We’ll build the kernel on the Pi – so you will need to leave this Pi switched on with a terminal on it for around 12 hours while it builds; you can also run the build in a tool like screen or tmux that will let you detatch/reattach your session while the build runs, so your PC/terminal doesn’t have to be on all the time
  • Your Pi is a model B with a Wolfson audio board attached. If you omit the Wolfson audio patches from the kernel you should have a working realtime system that can only use the onboard audio or USB devices. This may not be an issue but it’s no harm to build the Wolfson modules in any case!

With that disclaimer out of the way, let’s get cracking. I’m assuming you’re starting from a base Raspbian installation, and have unfettered internet access – if you’re behind a proxy then make sure to configure that using the SOCKS_PROXY/HTTP_PROXY/GIT_PROXY_COMMAND environment variables and a wrapper script for git.

Getting dependencies, patchsets and kernel sources

First up, let’s update the Pi and install some dependencies.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install bc libncurses5-dev

There’s two patchsets we’re going to apply – the Wolfson kernel patches, and the -rt patches, so let’s grab those first.

wget http://downloads.element14.com/wolfson/wolfson_drivers.tar.gz
tar zxf wolfson_drivers.tar.gz
wget https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.25-rt23.patch.gz
gunzip patch*

Now we’ve got those downloaded and extracted, look around a bit – you’ll note the Wolfson drivers come with a whole boatload of .sh scripts named things like Record_from_lineIn.sh. These are simple wrappers around ALSA’s configuration tools – if you run alsamixer after we’re done you’ll see why they’ve included them, as the ALSA interface their codec provides is very complicated compared to most codecs. You’ll also find a bunch of .patch files in a subfolder, which are what we’ll apply to the kernel sources next. First, though, we need to check out the sources.

mkdir kernel_sources
cd kernel_sources 
# This will take a while and download plenty of data. Go get a cup of tea! 
git init 
git fetch git://github.com/raspberrypi/linux.git rpi-3.10.y:refs/remotes/origin/rpi-3.10.y 
git checkout rpi-3.10.y 
# Go to the specific commit the patches are for 
git reset --hard c43739885d512c92c0aa443b5895b96df5141da0 
# Tell git who we are for our changes 
git config --global user.name "Your name"
git config --global user.email "your email in here"

With all of that out of the way we should now have a copy of the Linux kernel source tree suitable for the Raspberry Pi ready to build. This is where we start to configure things.

# If you're prompted by the following to skip any empty patches, do so as directed
# Skip this line for RT only (no Wolfson drivers)
git am -3 /home/pi/rpi_wlf_3.10_beta/*
cat /home/pi/patch-3.10.25-rt23.patch | patch -p1
# Copy in the default config for the Wolfson drivers
# If you're going for just RT, do 'make bcmrpi_defconfig' instead of this next line
cp arch/arm/configs/rpi_wolfson_sound_pi_defconfig .config
# Start the configuration menu
make menuconfig

Configuring and building your kernel

Your Pi should have a think and then give you a menu. Navigating in here is a bit fiddly so have a play around to get your bearings – if you mess up, just hit escape until prompted to save, don’t do so, and run make menuconfig again. Worst case if you save the config by accident, run the cp line above again to copy the default config back in for a clean slate.

You may be tempted to tinker with all the options in here – and to an extent, do so! If you can see things you know you’ll never need you can remove them. However, be aware that you can break things easily, and there’s not a huge upside to removing most things here.

What you do need to do, though, is find these options and set them as follows:

  • Kernel config -> CPU power management -> CPU frequency scaling -> Default governor -> performance
  • Kernel config -> CPU power management -> CPU frequency scaling: Disable the non-performance governor modules, we don’t want them!
  • Kernel config -> Kernel Features > Preemption Model -> Fully preemptible kernel (RT)

That’s it! Easy as that. What we’ve done there is forced the CPU to run at maximum power at all times (note that this is not something you should do in combination with a 1000MHz overclock – 950MHz seems to be stable, but lower frequencies are better if you can live with them), and enabled a fully preemptible kernel. Now we can build it and install the modules and the kernel:

make
make modules
sudo make modules_install
sudo cp arch/arm/boot/Image /boot/kernel-rt.img

Go make a cup of tea (or a few) while the build runs. We copy the kernel to a new location in the boot partition rather than overwriting the existing one – this makes it easy to switch back, and OS upgrades to the kernel package won’t wipe your changes out. What we need to do now, though, is tell the Pi about this kernel.

Configuring the bootloader

Edit /boot/config.txt with your editor of choice and add the following lines:

disable_splash=1
force_turbo=1
kernel=kernel-rt.img

We’re forcing on turbo mode and removing the splash screen for easier debugging, and telling the Pi where to look for its kernel. If you break anything in your kernel, removing that line will get you booted up again!

We also need to modify /boot/cmdline.txt to work around a bug which would mean the kernel couldn’t mount the SD card root partition. We also force the USB device speed to 1.1, as this appears to fix some stability issues; omit the second part of this if you feel lucky. Simply add this to the start of the line of text in cmdline.txt:

sdhci_bcm2708.enable_llm=0 dwc_otg.speed=1

Once we’ve done that, you should be good to go. Simply issue a ‘sudo reboot’ and wait for your Pi to come back to life! If it doesn’t, edit the config.txt to point at your old kernel.img and go from there; you’ll need to hook up a HDMI screen or serial console to debug it, though.

To check everything is working, issue a quick uname -a:

pi@openob-pi ~ $ uname -a
Linux openob-pi 3.10.25-rt23-openob+ #3 PREEMPT RT Sat Apr 5 11:04:35 UTC 2014 armv6l GNU/Linux

Note in this build I’ve added a -openob version string to my kernel configuration – but the crucial thing is the PREEMPT RT line and the -rt23 version suffix. If you’re also building the Wolfson Audio stuff and have the card connected, you can check to see if it’s being picked up by the kernel with the following:

pi@pi-jamesha-0 ~ $ cat /proc/asound/cards
 0 [sndrpiwsp      ]: snd_rpi_wsp - snd_rpi_wsp
                      snd_rpi_wsp
 1 [ALSA           ]: BRCM bcm2835 ALSbcm2835 ALSA - bcm2835 ALSA
                      bcm2835 ALSA

You can play around with the alsamixer control panel or the Wolfson scripts to set things up. Bear in mind that to make full use of the realtime features of the kernel you need to prioritize properly; this is documented elsewhere on the net in detail and is generic across all Debian/Raspbian systems in terms of configuration, so I won’t cover that here.

Hopefully this will help people get set up with low latency audio on the Raspberry Pi; I will try and keep on top of the documentation around this in future!

by James Harrison at April 10, 2014 11:40 PM

drobilla.net » LAD

Pretty names in Patchage via Jack Metadata

The much-awaited (by me, at least) Jack metadata API has arrived. This will allow us to easily achieve many new things with minimal/nonexistent API friction. One of the simplest and most obvious is pretty names for Jack clients and ports, so I’ve chosen this as the first thing to tackle (as part of a drive to get Patchage polished up for a much overdue release).

Unfortunately, as far as I can tell, there is a chicken & egg scenario here since nothing is setting this metadata yet. So, I’ve made Jalv and Ingen both set pretty names for their ports. In the case of Jalv, the “pretty name” is the label given in the plugin data (distinct from the LV2 “symbol” which is restricted and unique).

Firing up Jalv with the Tal Dub III plugin (LV2 port courtesy KXStudio), we can see the port symbols, which are a bit awkward for end users with their prefixes and underscores. Conflating strong identifiers with human-readable labels is a serious design error I learned of the hard way, but that’s a discussion for another time…

Enable “Human Names” in the view menu, or press C-h, and voilà, we see the pretty names set in Jack metadata (if present) instead.

Tal Dub III in Jalv as shown by Patchage with human names off.

Tal Dub III in Jalv as shown by Patchage with human names enabled.

The metadata API is very simple to use for ports, though there seems to be a hole in the API which makes it difficult to get the UUID for your client to set metadata (I want a simple jack_client_uuid, like jack_port_uuid, but it seems you have to get a string UUID and parse it to a jack_uuid_t, clunky enough that I just didn’t bother). In any case, I am happy to see a low-friction mechanism in Jack which apps can use to share metadata towards making a better user experience.

It will be interesting to see what sort of information proves useful and becomes established/standard. For those of us of a mad scientist bent who live in a nest of patch cables, a CV tag seems like another obvious simple step, but for everyone, a big step is finally having meaningful port grouping and channel roles. I have always liked to joke that Jack (like LADSPA) doesn’t really even do stereo, but with metadata, we can mark up stereo, 5.1, Ambisonics, etc., and other clients will be able to make sense of the channel assignments without resorting to dirty kludges based on guessing from names. All without changing the ABI one bit. Good stuff.

flattr this!

by David Robillard at April 10, 2014 01:26 AM

April 09, 2014

KXStudio News

KXStudio repositories are now ready for Debian!

The KXStudio repositories are now ready for Debian and its derivatives (including the upcoming Ubuntu 14.04).
They should work for all Debian versions since Wheezy and Ubuntu 12.04 or above.
See the Repositories section for more information and how to enable them.

There's a list of available applications in the repository here and plugins here.
These 2 lists will quickly grow as more stuff is added in the repositories.


You can request new software to be packaged in this LinuxMusicians forum topic (although things seems a bit slow now, we'll eventually get to everyone's requests).
Please report any issues regarding packages here.

If you use the repositories, please donate to help keep packager(s) motivated. See http://kxstudio.sourceforge.net/Donations.
All this month donations will go to ensure falkTX has a good trip to the Linux Audio Conference next month!

PS: AVLinux users wanting to use the KXStudio repositories should be patient.
Something cool might come up when falkTX and GMaq meet in next month's LAC. ;)

by falkTX at April 09, 2014 11:35 PM

Linux Audio Users & Musicians Video Blog

OBXD for Linux

Vytautas Jancauskas with the assistance of several contributors on the KVR forums has ported OBXD to linux.

OBXD is an old school analog synth used for Star Wars fX among many other things. Hence the name OBi-wan Kenobi…



by DJ Kotau at April 09, 2014 12:32 PM

Music, Programming and a Cat

Round 2: Meta Applications and „Out-Of-The-Box“ bundles

Last week I wrote about a near-future scenario where the idiom of Linux Audio modularity is taken to the next level. The biggest problem was to hide certain connections from the user.

After a week of research and talking to experienced JACK developers this is my current knowledge about the topic:

  1. Netjack and similar tools are not the right solution. It may considered just a lack of feature that some of them do not forward MIDI and Transport. But the real issue is that this is meant to run one server on one computer and we need one server for each bundle. This just shows that this solution would have ended in a hack with virtual IP addresses, temporary Linux user accounts and other abominations. There are doors we don‘t use :)
  2. I began to write a client that, without any networking, connected to two jack servers and then copied data from one server to another. This however turned out not to be a very solid and future proof solution either. Introducing latency etc.
  3. From that tr ... Read More

April 09, 2014 12:28 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] LoMus 2014

From: Thierry Coduys <Thierry.Coduys@...>
Subject: [LAA] LoMus 2014
Date: Apr 9, 9:31 am 2014


--Apple-Mail=_55A1FADC-F7E4-4CCA-A940-B5E30A82C058
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252

Appel =E0 contribution / Call for participation
D=E9sol=E9 en cas d=92envois multiples / Sorry for possible crossposting

LoMus 2014

=C0 la recherche des logiciels libres pour la cr=E9ation sonore et =
interm=E9dias

Pour sa cinqui=E8me =E9dition, LoMus 2014 s=92adresse =E0 tous ceux qui =
d=E9veloppent des logiciels libres musicaux ou qui peuvent contribuer au =
processus de la cr=E9ation musicale.

Un prix sera remis aux logiciels qui font preuve non seulement =
d=92innovation, mais notamment d=92inventivit=E9 face aux enjeux actuels =
de la cr=E9ation musicale.

Calendrier
31 mars 2014 - Appel =E0 soumissions
28 avril 2014 - Date limite de soumission des logiciels
16 mai 2014 - Notification d'acceptation
23 mai 2014 - Remise du prix lors des JIM 2014

Info : http://concours.afim-asso.org/
JIM 2014 : http://www.musinfo.fr/index.php/presentation-des-jim-2014/


LoMus 2014

In search of open-source software for musical and intermedia creation

For its fifth edition, LoMus 2014 invites music and audio open-source =
software creators to submit original projects that either directly or =
indirectly contribute to musical creation.

A prize will be awarded to open-source sofware that proves to be not =
only innovatory but also inventive in the present context of music and =
audio creation.

Calendar
Mars 31, 2014 - Call for submissions=20
April 28, 2014 - Submission deadline=20
May 16, 2014 - Admission notification=20
May 23, 2014 - JIM Awards Ceremony 2014

Info: http://concours.afim-asso.org/
JIM 2014 : http://www.musinfo.fr/index.php/presentation-des-jim-2014/=

--Apple-Mail=_55A1FADC-F7E4-4CCA-A940-B5E30A82C058
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252


charset=3Dwindows-1252">
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">

class=3D"">
Verdana; text-align: justify;">Appel =E0 contribution / Call for =
participation
D=E9sol=E9 en cas d=92envois multiples / Sorry =
for possible crossposting


class=3D"">LoMus 2014

class=3D"">


style=3D"font-size: 14px;">=C0 la recherche des logiciels libres pour la =
cr=E9ation sonore et interm

14px;">=E9dias


13px;">
Pour sa =
cinqui=E8me =E9dition, LoMus 2014 s=92adresse =E0 tous ceux qui =
d=E9veloppent des logiciels libres musicaux ou qui peuvent =
contribuer au processus de la cr=E9ation musicale.

style=3D"margin: 0px; min-height: 14px;">

class=3D"" style=3D"margin: 0px;">Un prix sera remis aux logiciels qui =
font preuve non seulement d=92innovation, mais notamment d=92inventivit=E9=
face aux enjeux actuels de la cr=E9ation musicale.


class=3D"">Calendrier

31 mars 2014 =
Appel =E0 soumissions
28 avril =
2014 - 
Date limite de soumission des logiciels

class=3D"">16 mai 2014 - Notification =
d'acceptationmessage continues]

read more

April 09, 2014 10:00 AM

April 07, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Vee One Suite 0.4.1 - A proto-beta bis release!

From: Rui Nuno Capela <rncbc@...>
Subject: [LAA] Vee One Suite 0.4.1 - A proto-beta bis release!
Date: Apr 7, 6:34 pm 2014

The Vee One Suite of (maybe not so anymore) old-school specialized
instruments gets an update to a new bis encore...

the changes for this second proto-beta release are:

- once so called 'Noise' wave-shapes are now being made a lot more
deterministic, read idempotent ;).
- fully alias-free/band-limited wavetable oscillators are now in place,
making it a better virtual-analog synthesizer (esp. for running
sample-rates below 96KHz; synthv1 [1] only).
- late optimizations to basic wave-table oscillators.
- make sure the LV2 plugin back-end always builds first, before its
respective LV2 UI front-end client.

all 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 plugin.

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

and there they are:

[1] synthv1 - an old-school polyphonic synthesizer

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

- source package:

http://download.sourceforge.net/synthv1/synthv1-0.4.1-15.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/synthv1/synthv1-0.4.1-15.rncbc.suse131.i586.rpm

http://download.sourceforge.net/synthv1/synthv1-0.4.1-15.rncbc.suse131.x86_84.rpm


[2] samplv1 - an old-school polyphonic sampler

samplv1 is an(other) old-school all-digital 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.4.1.tar.gz

- source package:

http://download.sourceforge.net/samplv1/samplv1-0.4.1-15.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/samplv1/samplv1-0.4.1-15.rncbc.suse131.i586.rpm

http://download.sourceforge.net/samplv1/samplv1-0.4.1-15.rncbc.suse131.x86_84.rpm


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

drumkv1 is (yet) an(other) old-school all-digital 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.4.1.tar.gz

- source package:

http://download.sourceforge.net/drumkv1/drumkv1-0.4.1-11.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/drumkv1/drumkv1-0.4.1-11.rncbc.suse131.i586.rpm

http://download.sourceforge.net/drumkv1/drumkv1-0.4.1-11.rncbc.suse131.x86_84.rpm


see also:
http://www.rncbc.org/drupal/node/775


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

read more

April 07, 2014 07:00 PM

rncbc.org

Vee One Suite 0.4.1 - A proto-beta bis release!

The Vee One Suite of (maybe not so anymore) old-school specialized instruments gets an update to a new bis encore...

the changes for this second proto-beta release are:

  • Once so called 'Noise' wave-shapes are now being made a lot more deterministic, read idempotent ;).
  • Fully alias-free/band-limited wavetable oscillators are now in place, making it a better virtual-analog synthesizer (esp. for running sample-rates below 96KHz; synthv1 only).
  • Late optimizations to basic wave-table oscillators.
  • Make sure the LV2 plugin back-end always builds first, before its respective LV2 UI front-end client.

all 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 plugin.

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

and there they are:

synthv1 - an old-school polyphonic synthesizer

synthv1 0.4.1 is released.

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

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

Flattr this

samplv1 - an old-school polyphonic sampler

samplv1 0.4.1 is released.

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

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

Flattr this

drumkv1 - an old-school drum-kit sampler

drumkv1 0.4.1 is released.

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

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

Flattr this

Enjoy && again, have fun.

by rncbc at April 07, 2014 05:30 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] [ANN] Radium 1.9.37

From: Kjetil Matheussen <k.s.matheussen@...>
Subject: [LAA] [ANN] Radium 1.9.37
Date: Apr 7, 8:51 am 2014

Radium is a music editor with a new and better interface.
It's inspired by trackers, but has fewer limitations and uses graphics
to show musical data.

Homepage:http://users.notam02.no/~kjetism/radium/
Screenshot of 1.9.37 and videos:
http://users.notam02.no/~kjetism/radium/screenshots.php

Most important changes 1.9.34 -> 1.9.37:
====================================
* Add "All files" option to the file requesters
* Proper postfix filter in filerequester when importing midi file
* text draw: Fix for crash when painting ranged notes with subpitch
* vst: Return correct samplePos in audioMasterGetTime
* Fix GFX_Menu not being able to return selection higher than 9
* Pd: radium_time message (containing time and line information)
* Non-OSX: Search for VST plugins recursively
* Get "keys" file path the same way as color and config, plus support
comment after key
* Bottom bar and mixer widget tooltips (Atte Jensen)
* Atte Jensen's patch to read key names from ~/.radium/keys
* Make left alt open menues
* Fix ESC and Arrow keys while navigating menues.
* Fix keys for non-US language setting
* Reset Font size resetted to the default font size, not user font size. Fixed
* New event keys: CALCULATOR, MAIL, HOMEPAGE
* Add missing key events, such as 0R1, LR1, etc.
* Turn off drunk velocity by default
* Changed default ADSR(+H) values to neutral
* Put the instruments first when selecting track instrument (F12)
* Always write cents if track is wide
* Fix keyboard modifier keys
* Configurable line separator opacity
* LPB line coloring (opacity can be set in edit -> global config)
* Renamed "MIDI input on/off" to "Edit On/off" (because that's what it
really is)
* Update midi input checkbutton when pressing esc
* Fix SPS spinbox focus
* Only show song files in load/save requesters
* Added $HOME/.ladspa to the list of ladspa paths, when LADSPA_PATH is
not defined
* Instructions on where radium gets menues.conf and keybindings.conf
* Use $HOME/.radium/menues.conf and $HOME/.radium/keybindings.conf if they exist
* Mapped XK_ISO_Level3_Shift to EVENT_ALT_R
* Fix open editor when editor is "emacs -nw"
* Make escape key exit string req, same as return
* Add "import radium as ra" in top of keybindings.conf, plus example
code how to make space play/stop depending on whether you are playing
* New API function: isPlaying
* Updated ubuntu/debian package list in README
* sampler instrument/crossfade: Remove debug printing in realtime code
* fast_log_exp.dsp: Fix pun_float_to_int proto in the faust "ffunction"
* build: Print out message if a command isn't found (make "which" more verbose)
* Pitch area widens when right-clicking inside it, not when moving
mouse on top of it.
* Add effect to correct track when right clicking.
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

April 07, 2014 09:00 AM

April 06, 2014

linux.autostatic.com » linux.autostatic.com

Downscaling and upgrading

For years I've used Focusrite Firewire interfaces, first the Saffire Pro 10 IO and after that its successor, the Saffire Pro 40. Both great devices but recently I decided to make the switch to USB. The reason was twofold:

  • I was barely using more than 2 ins or outs simultaneously
  • Firewire is being phased out and my notebooks don't have any Express Card slots either, only USB ports
  • The Pro 40 isn't very portable

So when switching to USB I would need:

  • Same or better quality preamps and AD/DA convertors
  • At least 2 ins and outs
  • Portability
  • Possibility to achieve similar latencies as with the Pro 40
  • Works well with Linux

This narrowed down the choice significantly. I could go for a Focusrite Scarlett but from what I found on the net there were some issues with these devices. I've also looked at some Presonus devices but actually I had already set my mind on a different device: the RME Babyface.


RME Babyface

So when I found a webshop that offered the Babyface at a reduced price (almost 15% off) I put my Focusrite up for sale and bought the Babyface. The Focusrite was sold within a week and the Babyface easily met my expectations:

  • When in CC (Class Compliant) mode it works out of the box
  • It's highly portable, the Babyface is actually specifically made for this purpose as it comes with a nice pouch
  • It has 2 ins and outs and the great thing is that it's possible to extend the IO via ADAT
  • The preamps and AD/DA converters are simply top notch, they're so good that I'm considering switching cans and studio monitors as this device is merciless, it simply doesn't work well with my current setup
  • When connected to an USB3 port (XHCI) the Babyface can run with nominal latencies of 0.5ms (this is with 8 samples), i.e. it beats the other two OS's mentioned on the RME product page

I can live with not being able to control the device from within Linux, almost all settings can be done on the device itself. Upgrading the firmware can be done with a VM so that's covered too. The only real drawbacks are that it's an USB device so it's a bit more picky with regard to your system setup and it consumes a bit more CPU compared to Firewire. But all in all this is a great sounding device that works well with Linux when in CC mode and it fits my specific user case very well.

by Jeremy at April 06, 2014 10:18 AM

April 05, 2014

linux.autostatic.com » linux.autostatic.com

The Infinite Repeat - Cala Del Aceite

Finally got around finishing a new track. And it's just 65BPM so no four to the floor this time. I posted the demo a while ago, this is more or less a definitive version (definitive is a fluid term in my dictionary).

http://theinfiniterepeat.com/music/the_ ... aceite.ogg

This song is about one of the most beautiful places I know on this
planet, Cala Del Aceite in the most southern part of Spain:

http://www.conilplaya.com/fotos/playasd ... eConil.htm

Tools used:

  • Qtractor for recording and mixing
  • seq24 for sequencing
  • The necessary plugins:
    • drumkv1 to hold the drum samples (drum samples are all from
    • http://samples.kb6.de/)
    • a lot of plugins that are part of Distrho or Carla: Noize Maker, Tal
    • Reverb III, ZynAddSubFX-LV2, Nekobi
    • MDA subsynth
    • FluidSynth DSSI for the Rhodes
    • linuxDSP plugins (EQ500, DYN500, MBC2B on the master bus)
    • Calf Vintage Delay
    • LADSPA comb filter, Fast Lookahead Limiter
    • GxZitaReverb

The background vocals for the choruses are sung by my wife. The ocean
sample is from Freesound:

http://www.freesound.org/people/dobroide/sounds/93653/

Cádiz is pretty close to Conil, hence the choice.

Thanks to everyone for making this possible. Especially falkTX and rncbc, couldn't have done this without your valuable work.

Making promises that I can't keep
It's pushing me, pushing me into a deep
State of sadness, state of doubt
A state of awareness I can't live without

Making mistakes, so hard to bear
It's driving me, driving me to a point where
I can't escape, I can't shy away
From the daemons I refuse to obey

All is forgiven, all is well...

Awaiting the day that I'll be relieved
From this burden, this burden that has grieved
So many loved ones, so many friends
All the people on which I depend

Stand up, act now, it's time for a change
Lingering won't help, help to rearrange
The current imbalance, the current state
Of things so rush now don't hesitate

All is forgiven, all is well...

Creative Commons License
Cala Del Aceite by The Infinite Repeat is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

by Jeremy at April 05, 2014 04:45 PM

April 04, 2014

Scores of Beauty

Music Functions 4: Recursion

Today we’ll come to an end with a series of posts demonstrating how to write a comparably simple music function in LilyPond. I deliberately chose to describe the stuff with such verbosity and at that gentle pace because I think that’s what is missing in LilyPond’s (otherwise excellent) documentation. At least I think I would have greatly benefitted from that kind of explanation …

In the first part we started considering how to insert a Scheme music function in a LilyPond input file, and in the second part we started writing a function that colors an arbitrary function with an arbitrary color. While this was more or less hard-coded and exposed lots of redundant code we wanted to improve it in the third part through refactoring and list processing. Unfortunately this didn’t work out as easily as expected, and finally we’ll be solving the task through recursion today.

In a comment to the previous post Jay Anderson pointed out that there is another solution that doesn’t require using recursion. However I decided not to change the post that I had already written. So just keep in mind that the following post does not demonstrate the only approach but rather one of several different options. Apart from that I think that while Jay’s solution is actually more straightforward as a programming construct it would require considerably more previous knowledge and understanding. Using local variables with Scheme is completely different from other languages’ behaviour, so it would warrant a dedicated post or even series of posts.

Recursion

Scheme is a dialect of the LISP family of programming languages. “LISP” is derived from “LISt Processing”, and therefore lists are an ubiquituos concept in Scheme as in all other LISP languages. By now I can see some of the benefits of that approach, but I do insist on saying that it can be quite difficult to get into the spirit of things with Scheme. And until you have achieved this nearly everything about it can be extremely confusing. List handling is one of these things.

To solve our task of calling the coloring function for each grob type you would write something like this in Python:

for grob in my_grob_list:
    color_grob(grob, my_color)

which can be directly translated to English as “For each grob in the list my_grob_list please call the function color_grob, passing it the current grob and the general color my_color as arguments”. In Scheme you have to take a completely different approach by calling a function recursively.

Recursive functions are functions that call themselves with a modified argument list. A very important thing is to insert a check for a state to end the recursion because otherwise the program would get stuck in an infinite loop. The general outline for such a function is:

  • check for the exit state and leave the function if this is true
  • do something with the arguments and recursively call the function itself with modified arguments.

When using recursion to iterate over lists this usually means you will do something with the first element of the list and call the function with the remaining part of the list. The exit check can then determine if there are still list elements present to be processed.

Since our current case of a LilyPond music function complicates matters we’ll have a look at a generic Scheme function first:

#(define (display-names my-names-list)
   (if 
    ;; check if there still is a list element left
    (null? my-names-list)
      ;; no: we're at the end of the recursion
      ;; simply issue a new line and exit
      (newline)
      ;; yes: we still have elements to process
      ;; begin a compound expression
      (begin
       ;; display the first element and insert a new line
       (display (car my-names-list))
       (newline)
       ;; recursively call the function 
       ;; with the rest of the list
       (display-names (cdr my-names-list))) ;; end of begin
      ) ;; end of the if expression
   )

This defines a Scheme function with the name display-names and an argument my-names-list). Other than LilyPond’s music functions this doesn’t check the type of the argument, but the function body expexts it to be a list. Actually the code comments say it all, and it’s the implementation of what has been said above. The only thing to notice is that in LilyPond’s Scheme you have to give a “then” and an “else” expression to the if clause. In other Scheme dialects this may be omitted. And you should be very familiar with the car and cdr operators and their relatives. car returns the first element of a pair or list. cdr returns the second element of a pair, or with a list it returns a new list with all the elements of the list except for the first one (the “rest” of the list). (Or with Scheme lists you can consider a list to be a pair with one first element (the car) and the second element (the cdr) being a list on its own.)

Now you can call that function with #(display-names '(NoteHead Slur Flag Beam)) and see your list of grob types printed nicely in the console output.

Applying It To Our Task

You will recall that we wanted to write a function \colorGrobs that takes a list of grob names and a color as its arguments. In the last post we already wrote the function signature and now we can apply our recursion experience to write the body of that function. Finally it looks quite concise too:

colorGrobs =
#(define-music-function (parser location my-grob-list my-color)
   (symbol-list? color?)
   (if (null? my-grob-list)
       ;; issue an empty music expression
       #{ #}
       #{
         % color the first grob type of the current list
         \colorGrob #(car my-grob-list) #my-color
         % recursively call itself with the remainder
         % of the current list.
         \colorGrobs #(cdr my-grob-list) #my-color
       #}))

We define a music function that takes a list of grob names and a color as its arguments. When the list is empty the recursion stops by issuing an empty music expression. This is very handy as this way you can write an empty part for the if clause, something you can’t do in pure Scheme code in LilyPond. If there is an element left we call \colorGrob passing it the first list element as the grob name argument and then recursively call \colorGrobsitself with the grob name list stripped of its first element. That’s what we do with the car and cdr operators.

Now we have to write a corresponding \uncolorGrobs function and put everything togehter that we have done so far. I won’t spend all the screen estate to quote it all once more, but you can download the complete LilyPond file to run and inspect.

More Cleaning Up

OK, we have achieved our goal, a function that colors an arbitrary music expression in an arbitrary color. But I won’t let you go home now because there are still some things that can be improved with regard to “code hygiene”. The first issue will be some more factoring out to get rid of redundant code, the second will make the function still more generic.

Factoring Out Even More

One thing I don’t like about our solution so far is that we have to write several things twice, for coloring and uncoloring. It would make sense to merge the respective functions into one by providing yet another argument telling which direction we are going to do.

First we update our \colorGrob function to take an additional boolean color-on argument. If that is set to #t (true) we apply the \override, otherwise we \revert it:

colorGrob =
#(define-music-function (parser location my-grob my-color color-on)
   (symbol? color? boolean?)
   (if color-on
       #{
         \temporary \override #my-grob #'color = #my-color
       #}
       #{
         \revert #my-grob #'color
       #}))

The necessary change to our outer function \colorGrobs is even smaller. We don’t need to add a new conditional clause here but can simply extend the argument list by the boolean argument color-on and pass this on to \colorGrob unchanged.

colorGrobs =
#(define-music-function (parser location my-grob-list my-color color-on)
   (symbol-list? color? boolean?)
   (if (null? my-grob-list)
       ;; issue an empty music expression
       #{ #}
       #{
         % color the first grob type of the current list
         \colorGrob #(car my-grob-list) #my-color #color-on
         % recursively call itself with the remainder
         % of the current list.
         \colorGrobs #(cdr my-grob-list) #my-color #color-on
       #}))

Now we have to update our entry function \colorMusic to call the new internal function accordingly. Here we get a little inconsistency: Instead of calling \uncolorGrobs we now call \colorGrobs and have to pass a color as an argument although uncoloring doesn’t need a color information at all. I will accept this for today because it doesn’t add too much redundancy and because it is in code that the user won’t ever have to enter. The clean solution would be to work with optional arguments but we’ll defer this topic to a future post. As before I won’t copy all the stuff but provide the complete file for download.

Use a Generic Grob List

One last thing we will improve in our function is the list of grob names that has to be passed into the function. This requires some typing and especially it makes it somewhat random whether all relevant grobs have been taken care of. Fortunately LilyPond provides a means that can give us all we need to make this really generic: the all-grob-descriptions function. This produces a nested list of pairs, where each pair consists of a grob name and a list of its properties. Now we can make use of several things we learnt during this tutorial series: map, lambda, car and cdr.

What we need is a list of all grob names, that is the first element of all pairs that make up the all-grob-descriptions list. In other words we need to map the cars of all elements of this list to a new list. You should remember that map takes the elements of a list and passes it to a function and creates a new list of the results of that function, and we can use lambda to create this inner function ad-hoc.

(map (lambda (gd) (car gd)) all-grob-descriptions)

is all we need to perform this. The inner function will produce the car of all elements it is passed, map provides the elements of the all-grob-descriptions list and will produce the new list containing all grob names that LilyPond knows. You may check the result of this by displaying it. Just put

#(display (map (lambda (gd) (car gd)) all-grob-descriptions))

in an otherwise empty LilyPond file and compile it. This won’t produce a PDF but instead lists all available grob names in the console output.

The last step to do is to enclose this line in a newly written Scheme function and call this function when we need the list of grob names:

allGrobNames =
#(define-scheme-function (parser location)()
   (map (lambda (gd) (car gd)) all-grob-descriptions))

colorMusic =
#(define-music-function (parser location my-color music)
   (color? ly:music?)
   #{
     \colorGrobs \allGrobNames #my-color ##t

     #music

     \colorGrobs \allGrobNames #my-color ##f
   #})

One thing to note with this is that using \allGrobNames significantly slows down the compilation of our test music. I didn’t check the impact on large scores, but in the end you may have to evaluate the tradeoff between a generically comprehensive solution and processing speed in the context of your own concrete project.


As a final listing I will now print the whole file – which has become comparably short by now – and the resulting score, although it’s the same score as in the previous posts.

\version "2.18.0"

colorGrob =
#(define-music-function (parser location my-grob my-color color-on)
   (symbol? color? boolean?)
   ;; check for the boolean argument
   (if color-on
       ;; either set the color for the grob type
       #{
         \temporary \override #my-grob #'color = #my-color
       #}
       ;; or revert it
       #{
         \revert #my-grob #'color
       #}))

colorGrobs =
#(define-music-function (parser location my-grob-list my-color color-on)
   (symbol-list? color? boolean?)
   (if (null? my-grob-list)
       ;; issue an empty music expression
       #{ #}
       #{
         % color the first grob type of the current list
         \colorGrob #(car my-grob-list) #my-color #color-on
         % recursively call itself with the remainder
         % of the current list.
         \colorGrobs #(cdr my-grob-list) #my-color #color-on
       #}))

allGrobNames =
#(define-scheme-function (parser location)()
   ;; create a list with all grob names from LilyPond
   (map (lambda (gd) (car gd)) all-grob-descriptions))

colorMusic =
#(define-music-function (parser location my-color music)
   (color? ly:music?)
   #{
     \colorGrobs \allGrobNames #my-color ##t

     #music

     \colorGrobs \allGrobNames #my-color ##f
   #})

music = \relative c' {
  c4. d8 e16 d r cis( d4) ~ | d1 \fermata
}

\relative c' {
  \colorMusic #blue \music
  \colorMusic #red { c4 c } d \colorMusic #green e\f
  \colorMusic #magenta \music
}
(Click to enlarge)

(Click to enlarge)

As you can see our project has turned into a number of short functions (they could have been formatted even more concisely, and some of the comments could be left out in real life). It is characteristic when using Scheme to have many functions that are defined somewhat pyramidal: from the most broad functions at the bottom up to ever more specific and small functions at the top of the file. This is due to the nature of Scheme consisting of expressions that are evaluated rather than of commands that are executed. With Scheme you don’t generally write a chain of commands or loops within one function but rather replace any compound statement with a function call.

Of course – and explicitly pointing this out may be important to a significant share of the readers – I would now put all code above the music variable definition in a library file and \include this. So using the \colorMusic function doesn’t have any bigger impact on the structure and readability of the actual music input files.


We have come to the conclusion of our little series of tutorial posts. I hope you enjoyed them and have learned something along the way. Maybe writing Scheme functions isn’t all that daunting to you anymore – that would be a great outcome of my efforts. At least for me this was the case. I think I’ve taken the next step in tackling Scheme – of course I’m now waiting for the next occasion where I feel stupid not managing to cope with seemingly simple tasks …

Feel free to improve the tutorials by asking questions or adding examples in the comments. And if you have something to say on the matter or on other Scheme related topics don’t hesitate to contribute your own tutorial.

by Urs Liska at April 04, 2014 08:10 AM

April 02, 2014

Scores of Beauty

Music functions 3: Reusing Code

In the last post We wrote a music function that took an arbitrary music expression and applied an arbitrary color to it. The problem we immediately saw is that we manually had to override all properties – and that we still didn’t manage to catch them all. In general terms, a function that redundantly calls \override for each new property isn’t exactly elegantly programmed. So today we will do better and at the same time learn something about reusing code by refactoring and by processing lists.

This was the function as we wrote it originally:

\version "2.18.0"

colorMusic =
#(define-music-function (parser location my-color music)
   (color? ly:music?)
   #{
     \temporary \override NoteHead.color = #my-color
     \temporary \override Stem.color = #my-color
     \temporary \override Flag.color = #my-color
     \temporary \override Beam.color = #my-color
     \temporary \override Rest.color = #my-color
     \temporary \override Slur.color = #my-color
     \temporary \override PhrasingSlur.color = #my-color
     \temporary \override Tie.color = #my-color
     \temporary \override Script.color = #my-color
     \temporary \override Dots.color = #my-color
     
     #music
     
     \revert NoteHead.color
     \revert Stem.color
     \revert Flag.color
     \revert Beam.color
     \revert Rest.color
     \revert Slur.color
     \revert PhrasingSlur.color
     \revert Tie.color
     \revert Script.color
     \revert Dots.color
   #})

Start factoring out common functionality

For each notation element in question we called \temporary override NNNN.color = #my-color, so the first thing we’ll do is factoring out this common functionality in a dedicated function. This will be a helper function usually not called directly. Each use of \override could be enclosed in a music expression so we’ll write a new music function that returns such a music expression.

colorGrob =
#(define-music-function (parser location my-grob my-color)
   (symbol? color?)
   #{
     \temporary \override #my-grob #'color = #my-color
   #})

As you can see this function takes two arguments: a grob name (GRaphicalOBject) and a color. The color has the type we already know for it (color?) while the grobname has to be given as a symbol?. In the function body the \temporary \override is applied to the given grob with the given color. So now we can call the function with \colorGrob NoteHead #red, and as we already have the color as the argument to our entry function \colorMusic we can use \colorGrob NoteHead #my-color in our main function.

For uncoloring the music we write a corresponding function \uncolorMusic that uses \revert instead of \override. Our modified main function and its two new helper functions now look like this:

\version "2.18.0"

colorGrob =
#(define-music-function (parser location my-grob my-color)
   (symbol? color?)
   #{
     \temporary \override #my-grob #'color = #my-color
   #})

uncolorGrob =
#(define-music-function (parser location my-grob)
   (symbol?)
   #{
     \revert #my-grob #'color
   #})

colorMusic =
#(define-music-function (parser location my-color music)
   (color? ly:music?)
   #{
     \colorGrob NoteHead #my-color
     \colorGrob Stem #my-color
     \colorGrob Flag #my-color
     \colorGrob Beam #my-color
     \colorGrob Rest #my-color
     \colorGrob Slur #my-color
     \colorGrob PhrasingSlur #my-color
     \colorGrob Tie #my-color
     \colorGrob Script #my-color
     \colorGrob Dots #my-color

     #music

     \uncolorGrob NoteHead
     \uncolorGrob Stem
     \uncolorGrob Flag
     \uncolorGrob Beam
     \uncolorGrob Rest
     \uncolorGrob Slur
     \uncolorGrob PhrasingSlur
     \uncolorGrob Tie
     \uncolorGrob Script
     \uncolorGrob Dots
   #})

music = \relative c' {
  c4. d8 e16 d r cis( d4) ~ | d1 \fermata
}

\relative c' {
  \colorMusic #blue \music
  \colorMusic #red { c4 c } d \colorMusic #green e\f
  \colorMusic #magenta \music

}

which gives the same result as in the last post:

(Click to enlarge)

(Click to enlarge)

OK, this doesn’t make our entry function that much shorter, but we have already achieved a significant first step: avoiding the repetition of the same code. This makes it possible to maintain this code in one place. For example, I told you that \temporary is a rather new command and that you may just skip that command if you want to use LilyPond 2.16 for some reason. Now that we have factored out the command into a function you can simply update this function once and have the modified code for all instances of the function. Or imagine that you want to temporarily disable the function completely, then you can simply comment out the line in the function, and everything will remain black. Nevertheless this has only been the first step …

Using a List as Argument

We haven’t yet arrived at the goal because we still need to call our helper functions for each grob type individually. The goal would be to use only a single function call, and that can be achieved by passing the grob names as a list. So we want to write a function with the following signature:

colorGrobs =
#(define-music-function (parser location my-grob-list my-color)
   (symbol-list? color?)
   #{
     
   #})

This function takes a list of grob names and the color and will then iterate over this list to apply the overrides (using the helper functions we have already written). We’d call that function like this from our main function:

\colorGrobs #'(NoteHead
               Stem
               Flag
               Beam
               Rest
               Slur
               PhrasingSlur
               Tie
               Script
               Dots
               DynamicText
               Accidental) #my-color

This will make our main function much more concise and maintainable because adding a newly noticed grob simply requires adding its name to the my-grob-list list.

Iterating Over the List

While writing the signature of the \colorGrobs function was really easy iterating over that list of grob names is something that really can drive you crazy if you’re not yet really familiar with Scheme. And I have to admit it drove me crazy while writing this post – which you can take as an indication that I won’t be able to continue this series too much further ;-)

A straightforward way to iterate over a list that is comprehensible for people coming from other programming languages is the map operation. It takes a function and a list of values and applies the function to each of the values one by one. It returns a new list of modified values.

(map colorGrob my-grob-list)

will walk over our list of grob names and pass each one to the colorGrob function. While this looks quite concise it doesn’t take the color argument into account, so we have to look further.

Seemingly the solution to this issue would be the lambda construct which creates an ad-hoc procedure (basically an unnamed function) that can use any number of arguments.

((lambda (arg) (colorGrob arg my-color)) NoteHead)

will create a function with the body (colorGrob arg my-color). arg is defined to be the argument passed into the function, and NoteHead is passed into it, so colorGrob will actually be called (colorGrob NoteHead my-color). This example is quite useless of course and only there to show how lambda can work with hard-coded and variable arguments, but can be made fruitful together with map.

(map (lambda (arg) (colorGrob arg my-color)) my-grob-list)

will walk over my-grob-list and pass the items one by one to the ad-hoc (lambda) function. This way we iterate over the list of grob names passing them each to colorGrob, accompanied by the static color argument (my-color).

Unfortunately, our journey isn’t at its end. As said map applies the elements of a list to a given function. This function evaluates to a single value (which is what each Scheme expression or function does), and map creates a new list of all these values. This is very useful for manipulating lists in general, but in our case this is a problem: we have to return a music expression, but map creates a list of music expressions. So unfortunately we can’t go that way and have to apply real recursion. (The Guile manual documents map and lambda, and is a helpful resource for Scheme in general.)

Preliminary Conclusion

Today we seemingly didn’t achieve too much: we factored out some code and then defined the goal where we want to go next. But on the way to that goal we arrived at a dead end. But of course I described this on purpose because I hope discussing these things at such a slow pace will give you an opportunity to get familiar with some of the peculiarities of how Scheme works. While map and lambda don’t help us with the current issue they are indispensable tools for your career as a LilyPond-Scheme programmer, and it’s good to get to grips with them as early as possible.

We will complete this exercise in the next post and learn about a very fundamental concept of Scheme: recursion.

by Urs Liska at April 02, 2014 08:05 AM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] AlsaModularSynth (ams) 2.1.1 released

From: Guido Scholz <guido-scholz@...>
Subject: [LAA] AlsaModularSynth (ams) 2.1.1 released
Date: Apr 2, 7:56 am 2014


--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dear all,

AlsaModularSynth (ams) is a MIDI controlled realtime modular synthesizer=20
and effect processor with support for LADSPA and JACK.

This is a "my birthday" bug fix release also providing some
enhancements:


ams-2.1.1 (2014-04-01)

Fixed Bugs
o Fix crash on loading patches with missing LADSPA libraries.

New Features
o SIGTERM handler.
o NSM support (programmed by Roy Vegard Ovesen)
o Mouse hover port highlighting.
o Full screen mode view (F11).

General Changes
o German translation update.
o Some internal cleanups.

Website:
http://alsamodular.sourceforge.net/

Project page:
https://sourceforge.net/projects/alsamodular/

Files:
https://sourceforge.net/projects/alsamodular/files/


Enjoy!

Guido Scholz

--=20
http://wie-im-flug.net/
http://www.lug-burghausen.org/

--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlM67UMACgkQk6cKJms5yBve3QCeK6SwoOEPU42vXLFqSjtI4arV
/3AAn3+tLou8XY+td/Hy89yS9zcFEbsc
=vuIL
-----END PGP SIGNATURE-----

--SUOF0GtieIMvvwua--

read more

April 02, 2014 08:00 AM

April 01, 2014

Music, Programming and a Cat

Building Meta Applications and „Out-Of-The-Box“ bundles through extended Linux Audio Session Management and a virtual Jack machine

This is an article of the category "Let's talk about Next-Gen. Future ideas for Linux Audio" where I elaborate(!) on realistic near future improvements or unrealistic science fiction scenarios.  

p, li { white-space: pre-wrap; }

Many users frequently wish for more „Out-Of-The-Box“™ experience within the Linux Audio program stack (and many users wish for the opposite). I can understand both points as a musician, user and programmer who needs both aspects while keeping the administration aspect down.

A real world comparison: A hardware based recording- or producing studio.

 

Read More

April 01, 2014 10:35 PM

March 31, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] GlassCoder v0.5.0

From: Fred Gleason <fredg@...>
Subject: [LAA] GlassCoder v0.5.0
Date: Mar 31, 9:01 pm 2014

I’m pleased to announce the initial public beta release of GlassCoder, a minimalist JACK live encoder client for Icecast and Shoutcast streaming servers. GlassCoder is available under the GNU Public License version 2. Some features available in this initial beta release:

Support for Icecast (v2) and Shoutcast (v1) streaming audio servers

Support for streaming MPEG Layer 3 (‘MP3’) audio

Support for the JACK Audio Connection Kit (http://www.jackaudio.org)

GlassCoder is a ‘minimalist’ client in the sense that it utilizes no GUI or configuration file components whatever; its entire ‘user interface’ consists of a command-line invocation, making it particularly well-suited for use cases where the encoder is driven by an external system, such as an automation system or script. Full documentation is provided by the included man page.

Further information and download links are available at https://github.com/ElvishArtisan/GlassCoder

Cheers!


|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|-------------------------------------------------------------------------|
| Research is what I'm doing when I don't know what I'm doing. |
| -- Werner von Braun |
|-------------------------------------------------------------------------|

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

read more

March 31, 2014 10:00 PM

[LAA] LAC'14 program announcement

From: Robin Gareus <robin@...>
Subject: [LAA] LAC'14 program announcement
Date: Mar 31, 5:27 pm 2014

Hi all,

We're excited about the upcoming Linux Audio Conference, featuring a
tightly packed diverse schedule with 77 events by over 100 persons!

The conference schedule has just been published at
http://lac.linuxaudio.org/2014/program

Apart from presentations, there are workshops, a poster-session and five
concerts in 3 days. The 4th day of the conference is dedicated to an
excursion: http://lac.linuxaudio.org/2014/excursion a simple overview of
the complete schedule can be found in the printable version of the program.

If you want to attend and have not yet done so, please register at
http://lac.linuxaudio.org/2014/registration

Looking forward to seeing you all in May at the ZKM.

yours truly,
robin - LAC'14 team
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-announce

read more

March 31, 2014 06:00 PM

March 30, 2014

Scores of Beauty

Music Functions 2: Start Doing Something Useful

In the previous post I demonstrated how to include Scheme code in LilyPond input files, and we saw our first music function, although it still was a static function only producing a hard-coded middle c. Today we’ll do some more by writing functions that actually do something useful and can handle arguments.

Recall: Another static function

[Please note: I use “static function” in the colloquial sense and not in the sense of object oriented programming.]

makeRedNote =
#(define-music-function (parser location)()
   #{
     \once \override NoteHead.color = #red
     \once \override Stem.color = #red
   #})

\relative c' {
  c4 \makeRedNote c c c
}

second-music-function

As in the example of the previous post this music function returns a hard-coded music expression, only that it doesn’t return actual music but rather two overrides that will color the next note red. If you’d want to cover arbitrary music you’d have to override other grobs too, e.g. Flag, Beam, Dots etc.

Making the Function More Flexible: Arguments

Of course it would be dull to copy the function for all colors we might want to apply. A better approach is to parametrize the function by accepting an argument for the color. In the last post we already saw how arguments can be added to the function definition:

colorNote =
#(define-music-function (parser location my-color)
   (color?)
   #{
     \once \override NoteHead.color = #my-color
     \once \override Stem.color = #my-color
   #})

I added my-color to the list of arguments and provided the color? predicate as the single element in the list of argument types. (By convention one writes this type list on its own line. Only when it’s empty it’s often written at the end of the first line because the empty parens on a single line looks somewhat strange. )

This now means that the function expects to be called with an argument of type color?. Inside Scheme code this argument can simply be referenced as my-color, but in our LilyPond section enclosed by #{ ... #} we have once more to change mode back to Scheme by using the # in #my-color to reference the Scheme variable.

So our function still does produce the two property overrides, but it doesn’t use the hardcoded red anymore but will apply the color provided when calling the function.

\relative c' {
  c4 \colorNote #blue c \colorNote #'(0.5 0.5 0) c c
}

third-music-function

Please have a look at how we call the function now. The function expects an argument of the Scheme type color? which is defined by LilyPond. As you will recall we tell LilyPond to switch to Scheme mode with the # character, so we can pass the Scheme value blue to the function. Alternatively we can create an arbitrary color on-the-fly by passing a list of three values (representing Red, Green, Blue) and pass this as a Scheme value.
Finding out how exactly to write Scheme values in LilyPond can be confusing for beginners. Sometimes you write them literally (as with the colors), sometimes you have to prepend a ' or enclose it in '(). Getting used to this issue is one major part of getting used to Scheme in LilyPond, and I can’t help you too much with that. Basically everything is explained or at least documented in the Scheme Tutorial of LilyPond’s documentation – maybe after having read up to this point you may want to (re-)read that now.

Making It Even More Flexible: Processing a Music Argument

As a next step we can actually pass a music expression to the function. This is done with the type predicate ly:music? (functions and predicates with the ly: prefix are not pure Scheme but defined by LilyPond).

noOp =
#(define-music-function (parser location my-music)
   (ly:music?)
   #{
     #my-music
   #})

This music function takes a music expression as its argument and returns exactly this music expression, so actually it doesn’t do anything. But there’s one interesting thing I can demonstrate with this. The ly:music? argument is a Scheme music expression, and what we want to return is exactly that. Therefore we don’t need to switch to LilyPond mode in the function body and then reference the Scheme variable from there. Instead we can simply write music as the expression inside the function body:

noOpTwo =
#(define-music-function (parser location my-music)
   (ly:music?)
   my-music)

This will return the “result of the evaluation of music” – which is exactly the same as in the previous example, and you can see that calling \noOp or \noOpTwo doesn’t make a difference:

\relative c' {
  c4 \noOp c \noOpTwo c c
}

fourth-music-function

Please note: As the second argument – the ly:music we provided the simple c here, as a single note is already a music expression for LilyPond. But often you will want to pass compound music expressions as we’ll see in the next example.

Coloring Arbitrary Music with Arbitrary Colors

As a conclusion for today’s post we’ll write a function that colors an arbitrary music expression with an arbitrary color. For this it will take two arguments, the color and the music. First we will override the color property of a number of grobs with the given color, then we produce the music given as the argument and finally we’ll revert the color property of the grobs. Please note the use of \temporary, a rather new feature that isn’t available in stable versions before LilyPond 2.18. This will ensure that reverting the property will not revert to the default value (i.e. the color black) but rather to the value that was effective immediately before. If you have to use LilyPond 2.16 you can simply leave that out.

colorMusic =
#(define-music-function (parser location my-color my-music)
   (color? ly:music?)
   #{
     \temporary \override NoteHead.color = $my-color
     \temporary \override Stem.color = $my-color
     \temporary \override Flag.color = $my-color
     \temporary \override Beam.color = $my-color
     \temporary \override Rest.color = $my-color
     \temporary \override Slur.color = $my-color
     \temporary \override PhrasingSlur.color = $my-color
     \temporary \override Tie.color = $my-color
     \temporary \override Script.color = $my-color
     \temporary \override Dots.color = $my-color
     
     $my-music
     
     \revert NoteHead.color
     \revert Stem.color
     \revert Flag.color
     \revert Beam.color
     \revert Rest.color
     \revert Slur.color
     \revert PhrasingSlur.color
     \revert Tie.color
     \revert Script.color
     \revert Dots.color
   #})

To test the function I write some more complex music in a variable and call the function in different ways.

myMusic = \relative c' {
  c4. d8 e16 d r cis( d4) ~ | d1 \fermata
}

\relative c' {
  \colorMusic #blue \myMusic 
  \colorMusic #red { c4 c } d \colorMusic #green e\f
  \colorMusic #magenta \myMusic
(Click to enlarge)

(Click to enlarge)

You can see that the function works regardless of getting the music as a single note, a compound expression with curly braces or by passing it the \music variable. But you’ll also notice that the accidentals and the dynamic letters aren’t colored. But of course there’s an easy fix: just add the respective overrides to the function.

Everything’s fine now. But looking at the last function definition it seems there’s a lot of redundancy here, and redundancy is something we usually want to get rid of. Probably it would be a good idea to factor all this out into a separate function – and that’s what we’ll do in the next post.

by Urs Liska at March 30, 2014 06:19 PM

Hackaday» digital audio hacks

DIY Bluetooth Boombox Can Take a Beating!

FZZ4CJXHRWNH8KT.MEDIUM

Looking for a nice portable audio solution that can take a beating outdoors? This RaveBOX (v1.0) might be what you’re looking for!

[Angelo] is a 15 year old high school student from the Philippines who loves making things — in fact, he has a collection over 40 Instructables that he’s written himself to share with the world. He wrote his first when he was only 10 years old.

He was inspired to build this boombox when he stumbled upon a Pelican-like rugged case at the mall, so he bought it and started planning the build around it. He’s using a pair of 2-channel audio amplifiers hooked up to a Bluetooth/FM/USB/SD card player module which has a nice face-plate for external mounting. It drives a 4″ woofer, and 4 full range speakers. To modify the case, he used a Dremel and pocket knife, and we must say, he did a great job! The 12V 2.2aH lithium polymer battery provides a surprising 18 hours of playback.

It’s a great beginner’s project to get into soldering — nothing too complex, but the resulting boombox is quite useful — and [Angelo's] got a great guide to get you started!

If you’re looking for a bit more stylish boombox, why not build one out of a briefcase?


Filed under: digital audio hacks

by James Hobson at March 30, 2014 11:00 AM

March 28, 2014

Objective Wave

Tutorial : VCOs and Detuning

A new tutorial to explain detuning VCOs in ams-lv2 and Ingen.

The tutorial shows 3 ways to play with the frequency and tuning of multiple VCOs using:

  • The Tune setting
  • A LFO and the Frequency Modulation (FM)
  • The Analog Driver

If you have any comments, don’t hesitate to add them here!


by blablack at March 28, 2014 09:43 AM

Scores of Beauty

Music Functions 1. Getting to Grips with Scheme in LilyPond

With this post I intend to start a series of posts introducing writing Scheme music functions in LilyPond input files. Please note that this is not a guru’s wisdom poured into blog posts but rather a documentation of my own thorny learning process.

Being able to include Scheme code in LilyPond files is one of the foundations of Lily’s higher powers, as this isn’t “just some scripting interface” but allows you to interact with its processing on the lowest level. Basically LilyPond works through a combination of compiled C++ code and Scheme code interpreted at runtime. Injecting Scheme code in input files is therefore literally extending LilyPond’s built-in capabilities.

Unfortunately Scheme isn’t the most straightforward language to learn, and learning how it interacts with LilyPond can be a real challenge. While LilyPond’s documentation is generally excellent and comprehensive, everything beyond the Learning manual is deliberately concise (a reference, that is), sometimes to the degree of being hardly digestible. And the part about extending LilyPond with Scheme code definitely belongs to that area. Therefore I think it might be helpful to provide a more gentle introduction to some of its aspects. However, this won’t be a comprehensive introduction to Scheme as a language – this would definitely be over my head. Instead I’ll be presenting the things that one will want to start with when extending LilyPond, trying to be more verbose and more casual than the official documentation. I’m always open for suggestions how to improve the explanations, and if others would like to join the effort and provide tutorials for specific aspects, I’d be more than happy.

Preface: Including Scheme in LilyPond

As mentioned in the manual LilyPond will interpret anything after the # hash character as inline Scheme code. To be more precise it will evaluate the single expression that follows the hash. Everything in Scheme is an expression that will be evaluated. This is quite different from the idea of a program executing commands, and this is what makes Scheme and other LISP dialects difficult to approach for people coming from other programming languages.

LilyPond very much “thinks” like Scheme. There is even a dedicated section in the manual called “Score is a (single) compound musical expression” in the learning manual – which is a direct consequence of this conceptual affinity.
Another thing to note here is that LilyPond variables are interchangeable with Scheme variables in LilyPond input files. Let’s have a look at this with a concrete example:

\version "2.18.0"

% define a variable using the usual LilyPond syntax
bpmA = 60

% define a variable using Scheme
#(define bpmB 72)

{
  % assign a tempo literally
  \tempo 8 = 54
  R1
  
  % assign tempos using the LilyPond syntax for variables
  \tempo 8 = \bpmA
  R1
  
  \tempo 8 = \bpmB
  R1
  
   % assign tempos by referencing variables using Scheme
  \tempo 8 = #bpmA
  R1
  
  \tempo 8 = #bpmB
  R1 
}

First we define a normal LilyPond variable bpmA, then we do the same thing in Scheme syntax. We tell LilyPond with the # that there will be a Scheme expression, which is enclosed in parentheses (the parens are another “hot” topic for beginners, but we may come to this at another occasion). The expression itself defines a variable with the name bpmB and assigns it the value 72. Now we have two variables, bpmA and bpmB, which have different values but are technically the same for LilyPond.

first-music-function

As you can see we can use the literal value, the LilyPond or the Scheme variable. And LilyPond doesn’t care whether we pass it as through LilyPond or Scheme syntax.

The First Basic Scheme Function

Now we’re going to write our first music function as described in the Extending manual. Actually it will be a quite useless function but at least it will work – and hopefully get you an understanding how to do it.
But let’s start with doing it the normal LilyPond way:

\version "2.18.0"

myFunction = { c2 }

\relative c' {
  c4 \myFunction c
}

first-music-function

Here we define a variable with the (unusual) name of myFunction, which we can later insert in the main music expression. As you can see it will insert a half note c into the music. But as you can also see it does so without affecting the parser – the next note will be a quarter note again, referencing the previous duration encountered in the source code.

Now we’ll do the same with a Scheme music function:

mySchemeFunction =
#(define-music-function (parser location)()
   #{
     c2
   #})

\relative c' {
  c4 \mySchemeFunction c
}

First we define a LilyPond variable mySchemeFunction and assign it – a Scheme expression (as you can see from the hash with consecutive parentheses). This expression consists of four parts:

  • The keyword define-music-function
    This isn’t a Scheme keyword but a function defined by LilyPond. As the name suggests it defines a “music function”, which is a function that returns some music. And as such it can be used like a music expression as you see it in the last line of the example. The following three items are the arguments define-music-function expects.
  • The list of arguments
    the two arguments parser and location are mandatory, and as long as you won’t need to make use of the information in them you can just forget about them and type it out for each music function you define.
    If you want your function to process individual arguments (which we’ll see in a later post) you will add telling names to this list, for example (parser location slope) for one additional argument.
  • The types of your individual arguments.
    In the example given for slope you would add a type (or “predicate”) here, e.g. (number?), but in the example we used you have to provide an empty pair of parens.
  • The actual music expression to be returned
    As we’ve said a music function returns a music expression. Scheme functions generally return what the evaluation of the last expression produces, so this is where we have to do it. Instead of having to write some Scheme code producing a LilyPond music expression (for which we don’t have any means so far) we fortunately can use the #{ ... #} construct which allows us to switch to LilyPond mode within Scheme code. Concretely this means the section enclosed in the hash+curly braces is treated as one Scheme expression but can be written with LilyPond code. In our case this returns a music expression with the content of c2. So our whole music function returns { c2 }. And so our second example produces exactly the same result as the first one: { c4 c2 c4 }.

Of course it doesn’t make much sense to write a function that returns a hard-coded value. But I think it was a good example to understand the first steps of integrating LilyPond and Scheme code. And I promise that in the next post we’ll do something useful.

by Urs Liska at March 28, 2014 09:03 AM

March 27, 2014

Ubuntu Studio » News

Ubuntu Studio Beta 2 is out

Ubuntu Studio 14.04 trusty tahr Beta 2 (final beta) is out. You can get it at http://cdimage.ubuntu.com/ubuntustudio/releases/trusty/beta-2/ Some additions since previous releases: New installer option: package selection Uninstalling most of the packages in our workflow metas will no longer uninstall the meta itself New additions, mainly for our audio workflow, including all pd libs and […]

by Kaj Ailomaa at March 27, 2014 09:05 PM

March 26, 2014

Create Digital Music » Linux

Bitwig Studio Arrives Today; What Can You Expect?

The long wait for the new production software Bitwig Studio has created anticipation and exasperation in equal measure – people were excited, people were impatient; some drooled over every tiny feature details, some dismissed them and said they’d wait until it shipped. But the wait is over; today is actually the day Bitwig Studio is something you can download, try out, and buy. It’s not a beta; this is it. 299€ / US$399 buys you the full download version; a demo is available. (Boxed versions cost more.)

So, what can you expect on today as release day?

Well, at least Bitwig has enlisted some significant third-party support.

bitwignektar

There’s hardware controller support, from Novation’s Launchpad, for instance. At Musikmesse this month, we saw hardware integration from Livid Instruments and (newly-debuted) support from the beautiful Panorama keyboards. The latter means a keyboard that integrates directly with the workflow of the software, with Bitwig joining Reason, Cubase, and Logic. Here’s a look at how that works with the very-pretty Nektar (and that installer just went live today, too):

The hardware support is partly thanks to an easier-to-script API for controllers. We’ve seen equivalents of that in software like Renoise and Reaper, but it’s notably a more difficult task to customize in most DAWs, including Ableton Live.

There’s also training available on day one, including askvideo.com, with producer Olav Basoski doing a complete 10-tutorial video course.

But that leaves the question of the actual product. I’ll be testing it. I’m actually quite looking forward to it, and know some others who feel the same way, not necessarily in that I expect to dump tools I’ve used for years, but because I find it refreshing to explore new tools.

I don’t think that’s true of everyone, though; Bitwig will likely face the uphill battle any new DAW maker has in setting their product apart – and even in getting people to know about it.

Sound on Sound did an interview with Bitwig at their booth at Messe, in which the creators talked about their perspective.

To me, the most interesting part of Bitwig is something we still won’t see today. Every effect, every instrument is built in a modular environment they’ve constructed. That approach has borne fruits – you can use the stuff they’ve built. But you can’t yet use the modular guts; that’s promised for a future release.

What you do get are some features that have a slightly more niche appeal, but that some enthusiast producers may find attractive. Bitwig has outlined them on their page, but here’s what I think is most important:

1. Linux support, in addition to OS X and Windows. Linux users have had Renoise (and some have made use of Reaper inside a Windows compatibility environment), but this is a big deal.

2. A modulation environment for everything. Okay, so it’s not modular yet – you don’t get this sort of Reaktor-inside-Ableton feeling of having a complete modular tool. But you do get semi-modular control of everything in sight, with some powerful tools for authoring complex sound designs.

3. Controller scripting. There’s no Bitwig-manufactured hardware as there is Ableton’s Push or Native Instruments’ Maschine. Instead, what you find is an easy way to build controller support, as the above examples illustrate. That’s important for any environment that emphasizes live playing, and I’m curious to try it out.

4. A refined interface. The comparison is obviously here strongly to Ableton Live, especially with four ex-Ableton employees founding the company. One thing Ableton lacks is a clean-slate tool; they started around 1999 instead of Bitwig in 2009. Bitwig therefore has some interface elements specific to their approach (like inspectors), and some Ableton users have asked for (like side-by-side clip launching and arrangement, or multiple projects open at once).

None of these to me is a radical departure from what’s in the market, but it is worth testing, and we’ll do that.

Here’s Full Compass with a look at how the workflow comes together:

You’ll see some things aren’t on the list. There isn’t a fusion of DJ-style waveform previews with this environment. There isn’t much departure from the central clip paradigm of Ableton Live. There’s no use of mobile, or touch, or truly-scalable user interfaces.

So, I think the real question is whether any of this matters much beyond a small-but-loyal enthusiast community who get deep in this sort of production software. But I’ll give it a test both from my own ‘enthusiast’ perspective and to see if it might matter beyond our niche, and we’ll see how people respond now that it’s in the market.

We’d love to know what you think, and what you’d like to know.

It also seems time to look at some other “underground” DAW rivals, like PreSonus Studio One or the latest version of Renoise.

But I’ll say this: the era of desktop software for music is far from over. There are still intense rivalries and an insane embarrassment of variety. And whether you’re impressed by those offerings or not, I think we’re blessed to work in a community of musicians so idiosyncratic in their tastes. There isn’t just one (cough) creative suite for making music. They just keep breeding. And that’s good news for those of us who enjoy playing with them.

The post Bitwig Studio Arrives Today; What Can You Expect? appeared first on Create Digital Music.

by Peter Kirn at March 26, 2014 08:42 PM

March 24, 2014

PipeManMusic

The 500 Year Farm Manifesto Part 4

Time to address ethics and how they apply to my philosophy of food production.
Ethics can be a strange beast to cover, especially as they apply to food and food production. Some think ethics are subjective, others think they are part of greater belief systems up to and including formalized beliefs in the form of an organized religion. I want, dear reader, to be assured, that my view of food ethics lay much more in scientific understanding than in a higher power. My own personal ethics stem from how I perceive life and the world around me through the lens of scientific reasoning.
The most ethical food systems, at least in my opinion, are the ones that originated out of our evolutionary history. We didn't appear on the earth out of no where. We are not, as some believe, aliens to this world, who's lot is to throw natural systems into chaos and destruction. We evolved as a part of an ecosystem. We, at least at some point in our history, where as important to a natural ecosystems survival as the grasslands and savannas we evolved out of. Where we went astray, as I see it, was when we stopped participating in the ecosystem and started dominating it with technology. Now, I'm certainly not saying that we need to go back to living in small villages in the subtropical regions of the world, far from it in fact What I'm saying is that we can use our scientific understanding of ecology and biology to create constructed ecosystems that feed humans in as close to balance with nature as possible.
So, if we are to start constructing an ecosystem around humans, we first must identify our role in it. Looking at the conclusions drawn by anthropology and paleontology we see that humans have likely been omnivorous for around 3.5 million years. This means that humans have evolved over that time to eat both plants, mostly succulents and fruits, as well as meat. I have heard some argue that humans began eating meat around the same time we discovered how to create and manage fire for cooking the meat. However, there is no current evidence of this speculation. As far a science is concerned, there is nothing to prove we cooked our meat until around 800,000 years ago. Our eating of meat seems rather to coincide with our use of tools, namely flinted stone knives. To me, this makes our role in our ecosystem as an omnivorous alpha predator and that as far as science is concerned it is part of our evolutionary history, and there for ethical, to eat meat. What I would call the line between ethically eating meat and unethically eating meat is by judging if the animals being preyed upon are living a life cycle that is at least as humane as their natural, wild one would be or, more ideally, better.
Now ecosystems rarely have one predator in them, but rather a few that compete for resources and occasionally prey on each other. Where I would put non scientifically based ethics into my constructed ecosystem would be to say that one rule is that, no humans should die or come to harm in any way from it. That is of course unnatural to evolutionary history but one I don't find much objection to from pretty much anyone. One way we can simulate a more balanced ecosystem, however, is by using domesticated predators, the most common of whom we likely convolved in a symbiotic relationship with, e.g. the domesticated dog. I also see a valuable role for the domesticated cat in this ecosystem. The dogs role is to provide protection for this protected ecosystem from outside predator pressure who's role belongs in a totally natural environment and not this constructed one. The cats role is to prey on non-predatory animals who humans would not themselves view as food. Together these predators round out the closest approximations we can make for a full compliment of predatory animals.
If we are to have prey for our predators, or for the sake of lessening confusion, livestock, we need to also provide, through as natural a means as possible, the sources for their diet as well. An ethical ecosystem as I see it can not rely on inputs from outside sources indefinably otherwise we can never achieve a balance that allows the ecosystem to survive during our hypothetical goal of 500 years.
We do have to make some concessions in order to achieve our goal, there are compromises to be made in order to be realistic but the fewer compromises we make the more resilient and less vulnerable this constructed ecosystems is as a whole.
To summarize this writing, ethical food is one that exists in some sort of balance with it's ecosystem and barring catastrophic outside forces will survive indefinitely.

by Daniel Worth (noreply@blogger.com) at March 24, 2014 12:32 PM

March 21, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Qtractor 0.6.0 - The Byte Bald Beta release!

From: Rui Nuno Capela <rncbc@...>
Subject: [LAA] Qtractor 0.6.0 - The Byte Bald Beta release!
Date: Mar 21, 7:29 pm 2014

Once again, it's springtime.

Once again, the planet revolved and stepped forward against its mother star.

Hence the three bees release... it won't be that far fetched if
you find this naming a deliberate pun riddle indeed--the wise will know
already while the clueless will get it sudden in a couple of days ;)

Well, no big surprises nor earthshaking features are being here pitched
then, just some small and otherwise humble improvements and fixes and
what not.

Nevertheless and not just for the record that is, it marks the day of a
long overdue and severely procrastinated beta phase release.
Whatever. It's dang official now: one step closer to omega, no
doubt ;)

Contrary to, maybe, newer generations, I always strive to say
the least. As to say about literal face-value meaning, as written and
read on timeless textbooks, it's all left in between the lines or, this
part is the one I like most, left over as an exercise--in some kind of
healthy masochism, perhaps :).

No wonder,

Qtractor 0.6.0 (byte bald beta) is now released!


Release highlights:

* Plugin automation high resolution option (NEW)
* Plugin 'About' page (NEW)
* Native DE dialogs option (NEW)
* Follow play-head slack time (NEW)
* MIDI RPN/NRPN 14-bit controllers input (FIX)


Website:
http://qtractor.sourceforge.net

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

Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.6.0.tar.gz

- source package (openSUSE 13.1):

http://downloads.sourceforge.net/qtractor/qtractor-0.6.0-10.rncbc.suse131.src.rpm

- binary packages (openSUSE 13.1):

http://downloads.sourceforge.net/qtractor/qtractor-0.6.0-10.rncbc.suse131.i586.rpm

http://downloads.sourceforge.net/qtractor/qtractor-0.6.0-10.rncbc.suse131.x86_64.rpm

- quick start guide & user manual (outdated):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.x-user-manual.pdf

- help wanted (on Qtractor Wiki ;))
http://sourceforge.net/p/qtractor/wiki


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

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


Change-log:

- New user option added: on whether to save plugins automation values
with higher resolution as possible, using 14-bit NRPN: cf.
View/Options.../Plugins/Experimental/High resolution plugin automation
(default=off).
- Generic native plugin dialogs now shows an additional "About" last
page where authorship credits are due.
- A new user preference option is now in place for whether to use
desktop environment's own native file requester/browser dialogs
(View/Options.../Display/Dialogs/Use native dialogs).
- A bit of slack have been introduced to put "Follow Playhead" (aka.
auto-scroll view mode) on hold, while doing in-flight selection edit moves.
- Fixed some user interface related annoyances while on the MIDI
Controllers mappings (ie. View/Controllers...).
- Fixed port origin on MIDI RPN/NRPN 14-bit controllers input.
- A discretionary plug-in unique identifier have been devised for when
more than one from the same type are inserted on a bus or track chain,
avoiding destructive clashing of automation data.
- Horizontal scrolling shift+mouse-wheel direction now reversed.
- LV2 Dyn(amic)-manifest support is now optional (default=off); cf.
View/Options.../Plugins/Experimental/LV2 Dynamic Manifest support).
- The following options, although decieved on View/O [message continues]

read more

March 21, 2014 08:00 PM

rncbc.org

Qtractor 0.6.0 - The Byte Bald Beta release!

Once again, it's springtime.

Once again, the planet revolved and stepped forward against its mother star.

Hence the three bees release... it won't be that far fetched if you find this naming a deliberate pun riddle indeed--the wise will know already while the clueless will get it sudden in a couple of days ;)

Well, no big surprises nor earthshaking features are being here pitched then, just some small and otherwise humble improvements and fixes and what not.

Nevertheless and not just for the record that is, it marks the day of a long overdue and severely procrastinated beta phase release. Whatever. It's dang official now: one step closer to omega, no doubt ;)

Contrary to, maybe, newer generations, I always strive to say the least. As to say about literal face-value meaning, as written and read on timeless textbooks, it's all left in between the lines or, this part is the one I like most, left over as an exercise--in some kind of healthy masochism, perhaps :).

No wonder,

Qtractor 0.6.0 (byte bald beta) is now released!

Release highlights:

  • Plugin automation high resolution option (NEW)
  • Plugin 'About' page (NEW)
  • Native DE dialogs option (NEW)
  • Follow play-head slack time (NEW)
  • MIDI RPN/NRPN 14-bit controllers input (FIX)

See you all on LAC2014@ZKM-Karlsruhe!

and have a happy new springtime, cheers!

Flattr this

Website:

http://qtractor.sourceforge.net

Project page:

http://sourceforge.net/projects/qtractor

Downloads:

Weblog (upstream support):

http://www.rncbc.org

License:

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

Change-log:

  • New user option added: on whether to save plugins automation values with higher resolution as possible, using 14-bit NRPN: cf. View/Options.../Plugins/Experimental/High resolution plugin automation (default=off).
  • Generic native plugin dialogs now shows an additional "About" last page where authorship credits are due.
  • A new user preference option is now in place for whether to use desktop environment's own native file requester/browser dialogs (View/Options.../Display/Dialogs/Use native dialogs).
  • A bit of slack have been introduced to put "Follow Playhead" (aka. auto-scroll view mode) on hold, while doing in-flight selection edit moves.
  • Fixed some user interface related annoyances while on the MIDI Controllers mappings (ie. View/Controllers...).
  • Fixed port origin on MIDI RPN/NRPN 14-bit controllers input.
  • A discretionary plug-in unique identifier have been devised for when more than one from the same type are inserted on a bus or track chain, avoiding destructive clashing of automation data.
  • Horizontal scrolling shift+mouse-wheel direction now reversed.
  • LV2 Dyn(amic)-manifest support is now optional (default=off); cf. View/Options.../Plugins/Experimental/LV2 Dynamic Manifest support).
  • The following options, although decieved on View/Options... as global configuration options, were always and still are proper session instance properties: (JACK) Transport mode, MMC mode, MMC device, MIDI SPP and MIDI Clock modes, are now shown there reflecting the current open session state.
  • A couple of run-time circumventions have been hacked in, both strictly related to when NSM session management is in charge: 1) the new session template feature is disabled (was aborting initial NSM new client additions); 2) the native (as from the desktop environment eg. KDE) file browser/requester dialogs are disabled (were taking too long to list the current directory on first time invocation).
  • Update current automation/curve nodes selection while changing horizontal (time axis) zoom levels.
  • One liner's attempt to make it consistent behaviour on resizing and moving multiple selected notes or events while on the MIDI clip editor (aka. piano-roll; after a ticket request from Daniel MacDonald aka. danboid, thanks).
  • Introducing tiny quarter-note/crotchet/seminima/beat icon on all snap-to-beat selection items get a new icon :).
  • Corrected some audio buffering boundary conditions that were causing dead-loops/freezes while merging some audio clips.
  • Session auto-save period was chronically reduced to one third of its user setting; non critical but fixed now.

Enjoy && Yet again, have (lots of) fun.

by rncbc at March 21, 2014 06:00 PM

A touch of music

Olivier Messiaen - a closer look at his modes of limited transposition

Olivier who?

Olivier Messiaen was a French composer (December 10, 1908 – April 27, 1992), known for inventing a new musical language. He wrote a book about his ideas on rhythm, melody and harmony and is generally regarded as one of the great innovators in music. He drew inspiration mostly from his Christian beliefs and from bird songs. I personally fell in love with this musical language after hearing his work "Vingt Regards sur l'Enfant-Jésus".


One key element of his compositions is a set of scales that he "invented" (or rather, selected from the vast space of possible scales). They consist of symmetrical note groups. While writing music he would often adhere to using only notes from one or more of his scales, leading to special music (with very rewarding harmonies).

I was curious about these special scales and wondered about the mechanisms that cause the scales to "work so well" with a listener, so
I set up my own private investigation and took a close look at his scales.
I discovered quite a number of interesting things (which may be known already in literature, I don't want to claim I found something new, but they were certainly new to me)

I've written up what I came up with so far and put it online on github. The pdf can be seen here: https://github.com/shimpe/mints/blob/master/out/document.pdf?raw=true . All the code required to reconstruct the article is available here https://github.com/shimpe/mints:

Feel free to contact me with questions or remarks about this document.


by Stefaan Himpe (noreply@blogger.com) at March 21, 2014 01:46 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] ANN: New Pd-L2Ork x86_64 and Raspberry Pi 20140319 release candidate

From: Ivica Ico Bukvic <ico@...>
Subject: [LAA] ANN: New Pd-L2Ork x86_64 and Raspberry Pi 20140319 release candidate
Date: Mar 21, 11:32 am 2014


------=_NextPart_001_02CF_01CF442E.AAE54410
Content-Type: multipart/alternative;
boundary="----=_NextPart_002_02D0_01CF442E.AAE54410"


------=_NextPart_002_02D0_01CF442E.AAE54410
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Apologies for x-posting.



It is my great pleasure to announce immediate availability of the latest
Pd-L2Ork, its K12 module, as well as the latest version of Pd-L2Ork for the
Raspberry Pi platform that includes comprehensive set of objects for
sensing, including GPIO with pulse-width-modulation support, and analog
sensor monitoring support (via MCP3008 A/D chip and SPI module). In addition
to a slew of bug-fixes and improvements, pd-l2ork's structures have seen a
significant overhaul (thanks to contributions from Jonathan Wilkes and
others) now supporting a majority of the SVG spec and allowing for some
powerful manipulations of structs inside pd patches. Please note that the
structs are still under development, so some instabilities remain. Other
notable Changelog Highlights for this release include:



*new drawimage and drawsprite structs

*improved classinfo, canvasinfo, and pdinfo objects

*proper queuing for all iemgui objects and other improvements

*New preferences dialog

*New customizable arrays and jump-on-click ability

*UI themes

*Improved sanity checks for graph-on-parent patches

*over a hundred of other bug fixes and improvements



For a complete list of changes please consult the attached git-extracted
changelog.



The new release is accompanied by a comprehensive documentation on how to
connect RPi to the computer as well as run and configure Pd-L2Ork (and its
K12 module) for operation on RPi. In addition, as part of this release, the
regular Pd-L2Ork install instructions have been also streamlined to make
them easier to navigate.



For those in Virginia Tech area, the new release candidate will be showcased
at the upcoming Institute for Creativity, Arts, and Technology community
meeting this Friday 830-930am in ICAT Sandbox.



For more info visit:

http://l2ork.music.vt.edu/main/?page_id=56 (x86_64 version with updated
how-to)

http://l2ork.music.vt.edu/main/?page_id=2288 (Raspberry Pi version download
and how-to)



Obligatory screenshots:

http://l2ork.music.vt.edu/main/?page_id=2554





ABOUT L2Ork

A contemporary intermedia ensemble, L2Ork, thrives upon the quintessential
form of collaboration found in the western classical orchestra and its
cross-pollination with increasingly accessible human-computer interaction
technologies for the purpose of exploring expressive power of gesture,
communal interaction, discipline-agnostic environment, and the
multidimensionality of arts. In addition to furthering the artistic
exploration of the newfound genre, the ensemble's particular focus is on
integration of Taiji (Tai Chi) choreography into its performance practice as
well as its philosophy.



Founded by Dr. Ivica Ico Bukvic in May 2009, and since 2014 co-directed with
Dr. Charles Nichols, L2Ork is a part of the interdisciplinary initiative by
the Virginia Tech Digital Interactive Sound & Intermedia Studio (DISIS) and
the signature initiative of the newfound Institute for Creativity, Arts, and
Technology (ICAT). As the world's first Linux-based laptop orchestra L2Ork
offers optimal infrastructure for creative research at minimal cost. By
providing a seamless integration of arts and sciences it is in part designed
t [message continues]

read more

March 21, 2014 12:00 PM

March 19, 2014

blog4

Upcoming Elektronengehirn concert performances

I perform reqPZ with my project Elektronengehirn on 21. March in Berlin at A.I.P. Galerie and 2. May at ZKM Karlsruhe on the Linux Audio Conference 2014:

Malte Steiner startete Elektronengehirn 1996 neben seinen anderen Projekten wie z.B. Das Kombinat und Notstandskomitee, um die Möglichkeiten von computergenerierten Klängen und die Verbindung mit anderen Medien auszuprobieren. Die audiovisuellen Konzerte der folgenden Jahren beinhalten auch das Experiment mit alternativen Eingabemöglichkeiten abseits der Klaviatur, so z.B. Datenhandschuh oder wie in diesem Konzert spezielle Kontaktmikrofone, die die Schwingungen einer Metallplatte in Daten umsetzen, die Computergrafiken und synthetische Klänge formen. Die Realisation erfolgte mit Pure Data

https://www.youtube.com/watch?v=bhirQYiERYw
http://elektronengehirn.bandcamp.com/
https://soundcloud.com/elektronengehirn/reqpz

http://www.achtklang.de/

a.i.p.galerie artists in progress
Suarezstraße 8 14057 Berlin




by herrsteiner (noreply@blogger.com) at March 19, 2014 02:57 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Yoshimi 1.2.0

From: Will Godfrey <willgodfrey@...>
Subject: [LAA] Yoshimi 1.2.0
Date: Mar 19, 9:57 am 2014

This is now available from:
http://sourceforge.net/projects/yoshimi/files/1.2/yoshimi-1.2.0.tar.bz2/download

Apart from a number of bug fixes we have:
Circle and Spike AddSynth waveshapes
MIDI bank and program change - with extra configuration in 'settings'
Included patch set additions and updates.

Next on the roadmap is midilearn and extra control exposure.

Our list is:
yoshimi-user@lists.sourceforge.net

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

read more

March 19, 2014 10:00 AM

March 17, 2014

Talk UnafraidTalk Unafraid

Diving into Erlang – a Rubyist’s perspective

Given what I’ve been writing for the last year and a half has been large scale distributed systems it occurred to me that I should probably look at Erlang, and in part Elixir.

Erlang, for those not in the know, is a functional programming language written by Ericsson ages back for telecoms switch programming. The key requirements were to build systems that were reliable, handled failure gracefully, and operated at huge scale with massive numbers of concurrent activities, connections and tasks.

Real reliability means distribution across hardware – you can’t do five-nines on a single computer. Erlang excels at these tasks by way of a very clever virtual machine and some interesting design choices.

The focus in Erlang is not only on functions, as you’d expect, but on processes. Erlang’s VM has a very lightweight (bytes of memory, microseconds of startup time) process and concurrency model, which distributes work across multiple cores and multiple machines almost entirely transparently. You might readily spawn a process for every single connection your service receives. Say “10,000 processes” to any developer used to practically any other language and they’ll laugh or cry. In Erlang that’s an entirely reasonable idea.

Erlang itself isn’t the whole story, though. There’s a lot of common patterns that emerge from this model and the Erlang/OTP stack was developed to encapsulate some of these. OTP stands for Open Telecoms Platform, though it’s not limited to telecoms work. This provides a simple wrapper around all this generic logic – things like making sure processes are restarted when they fail, managing state transfer to new versions of code deployed to a running system, and making hierarchies of supervisors and workers simple to implement.

Which is all well and good. These systems clearly work. So given me, a Ruby developer (mainly) who is used to the developer-friendly world of Ruby, Python and the at least well trodden territory of C/C++, how did I get on?

Erlang’s main issue for adoption is, in my mind, the lack of a friendly build tool and the lack of documentation written for mere mortals.

There are a few ways to build your code – escript, on the console with erl, erlc and so on. But taking a step back – the classic workflow for a developer writing some code is: write, compile, run, test. The latter two may be combined with unit testing etc, but manual checking is obviously something you want to do. rebar is apparently the build tool de jour, something akin to pip or a combination of bundler and rake. And indeed, ‘rebar compile’ and ‘rebar doc’ do what you’d expect. So how do we run our OTP app now we’ve built it? It’s entirely non-obvious. There’s some documentation, but it’s either so high-level you’d only be able to fully grok it after a month of picking it to bits and looking up other docs, or broken. So far I’m running things with ‘erl -pa ebin/’, then running lines like ‘application:start(testapp).’ to actually get things started. Which sort of works.

If Erlang wants to be a language people will choose to use, it really has to get its build systems sorted out to the point where human beings can go from “write some code” to “run some code” and see their system start and get a console on it without having to get lost in documentation and search the net for tips.

Elixir is a step in the right direction with its mix tool, and might be the point at which Erlang’s VM becomes approachable enough to be adopted at a larger scale. At this stage though it’s still too much like hard work for what is effectively a solved problem. It’s all the more frustrating because Erlang itself is quite approachable, straightforward and powerful, and it feels to me at least that improvements to the usual workflow to make write-build-run a simple task would improve things massively. Of course, I’m approaching this as a new Erlang developer  having only spent a few days on it, so maybe I’m missing something. In the meantime, though, I think it’s onwards to Elixir to see how that works.

by James Harrison at March 17, 2014 12:41 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] OpenAV ArtyFX 1.1 Release

From: Harry van Haaren <harryhaaren@...>
Subject: [LAA] OpenAV ArtyFX 1.1 Release
Date: Mar 17, 11:24 am 2014

--001a1134630ac7249904f4cb95bd
Content-Type: text/plain; charset=ISO-8859-1

Hey All,

It's my pleasure announce that ArtyFX 1.1 is released!

See the ArtyFX page for details on the 3 new plugins:
http://openavproductions.com/artyfx/

Source available from github:
https://github.com/harryhaaren/openAV-ArtyFX/releases

And many thanks to the contributors! -Harry

--001a1134630ac7249904f4cb95bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey All,

It's my pleasure announ=
ce that ArtyFX 1.1 is released!

See the ArtyFX page for detail=
s on the 3 new plugins:

>http://openavproductions.com/artyfx/



Source available from github:

rryhaaren/openAV-ArtyFX/releases">https://github.com/harryhaaren/openAV-Art=
yFX/releases


And many thanks to the contributors! -Harry
r>


--001a1134630ac7249904f4cb95bd--

read more

March 17, 2014 12:00 PM

March 16, 2014

Linux Audio Announcements - laa@linuxaudio.org

Re: [LAA] [LAU] AlsaModularSynth (ams) 2.1.0 released

From: Guido Scholz <guido-scholz@...>
Subject: Re: [LAA] [LAU] AlsaModularSynth (ams) 2.1.0 released
Date: Mar 16, 11:16 am 2014


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Am Sat, 15. Mar 2014 um 23:21:09 +0100 schrieb Guido Scholz:

> Dear all,

=2E.. and yes, the files are at the usual place:

https://sourceforge.net/projects/alsamodular/

Guido

--=20
http://wie-im-flug.net/
http://www.lug-burghausen.org/

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlMk034ACgkQk6cKJms5yBt4LACeKhZlLR0Pr9kv2SqEv3Qji9aj
1NUAnjH4ERW4dV+WrCXDId08mfWpUaW5
=yxpP
-----END PGP SIGNATURE-----

--YiEDa0DAkWCtVeE4--

read more

March 16, 2014 12:00 PM

[LAA] AlsaModularSynth (ams) 2.1.0 released

From: Guido Scholz <guido-scholz@...>
Subject: [LAA] AlsaModularSynth (ams) 2.1.0 released
Date: Mar 16, 11:16 am 2014


--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dear all,

AlsaModularSynth is a MIDI controlled realtime modular synthesizer
and effect processor with support for LADSPA and JACK.

After several years of collecting fixes and enhancements the new
release provides a long list of changes:


ams-2.1.0 (2014-03-15)


Fixed Bugs

o Linker error "undefined reference to symbol 'dlsym@@GLIBC_2.2.5'"
on Fedora 13.
o Crash on using looped signal paths
o Armel compile error (debian #570848)
o Prevent crash if jack handle is NULL (lp #553366)
o Fix preferences dialog to show current color setup
o Fix broken Yes/No/Cancel response on program exit
o Fix memory leak in preferences widget
o Fix triggered reset of LFO saw signals, patch provided by Bill
Yerazunis
o Reorganized commandline options for input and output to
be valid for Alsa and JACK

New Features

o SIGUSR1 handler added to enable LADI session handling on
application level 1.
o Support for libclalsadrv API version 2.0.0
o Support for libzita-alsa-pcmi as an alternative for libclalsadrv
o Improved port selection handling, patch provided by Sebastien
Alaiwan
o New context menu to disconnect module output ports
o Support for JACK session handling
o Rewritten preferences dialog
o New about dialog
o New option for saving window geometry (session handling)
o New option hiding recently used files menu (keep secrets)
o Add new menu item to open demo patch files directly
o Add new menu item to open demo instrument patch files directly
o Add keyboard shortcuts for module configuration dialogs
o New option for module position grid (snap to grid)
o New V8 Sequencer module, provided by Bill Yerazunis
o New Analog Memory module, provided by Bill Yerazunis
o New Bitgrinder module, provided by Bill Yerazunis
o New Hysteresis module, provided by Bill Yerazunis
o New VC-Delay module, provided by Bill Yerazunis
o Add Pulsetrain Noise type to Noise 2 module, patch provided by
Bill Yerazunis
o New FFT Vocoder module, provided by Bill Yerazunis
o Make control center window position and MIDI settings persistent
o Add support for Qt5 (configure option --enable-qt5)

General Changes
=20
o Separate handling of color scheme directory from patch file
directoy.
o Improved handling of CXXFLAGS variables
o Add check for Ladspa header file.
o Obsolete commandline option -l (preset file) removed
o New commandline option for program version (--version)


Have fun!

Guido

--=20
http://wie-im-flug.net/
http://www.lug-burghausen.org/

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlMk0lUACgkQk6cKJms5yBsrHQCeOnYnmYi9vIh3b9QK5L7Nzyqm
g20AnieIbqLWNerAqjxpc3Nc1M/M6ofQ
=zINU
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--

read more

March 16, 2014 12:00 PM

GStreamer News

Gst Python, GNonLin and GStreamer Editing Services 1.2.0 stable release

The GStreamer project is pleased to announce the very first release of the new API and ABI-stable 1.x series of gst-python, GNonLin, and Gstreamer Editing Services.

Check out the GES release notes here or download tarballs from here.

Check out the GNonLin release notes here or download tarballs from here.

Check out the gst-python release notes here or download tarballs from here.

March 16, 2014 01:10 AM

March 14, 2014

Scores of Beauty

One Day At the Messe

Travelling sixteen hours by bus and having a whole day of fun can actually make you tired.

Travelling sixteen hours by bus and having a whole day of fun can actually make you quite tired.

We had lots of fun at the Frankfurt Musikmesse :-) .
It has been a great experience for both of us, me having most of Thursday and Janek joining for Friday. Actually we were so excited that we forgot to make pictures during the Messe ;-) – sorry for that!
We were lucky to share a small part of the booth of SCORA which turned out to be a very nice thing. First of all: SCORA rocks. I think it actually does what it promises and will be a very interesting solution for orchestras to update to the future. As it seems publishers have a very similar impression. And it turned out that it actually was a quite matching complement because when it came to the “system behind it” the SCORA people could gently pass on their potential clients to us – which led to some very interesting conversations.

What else can we say? Well, we had the ceremony where we received the BEST EDITION award today. As announced it was a rather modest event, interestingly without any audible music. But of course it was great to be there, and to meet representatives of some of the major publishing houses.

Another of the more official events we participated in was the annual MusicXML community meeting which was quite interesting. We were informed about the current state of work towards MusicXML 4.0 and how the approaching SMuFL 1.0 release relates to that. It’s nice to see that the music notation software community is really interested in developing open standards and to see that others are concerned with similar problems as we (for example providing reliable contexts for correctly aligning notation symbols when used in markups). Actually LilyPond, Frescobaldi and openLilyLib have been explicitly mentioned on the slides, and in general we have the impression that we are acknowledged in the scene. It also was an opportunity to meet a few people that we had only known as cryptic mailing list short names ;-) .

Apart from that we had a number of very interesting talks with people from various publishers, and it was exciting how this award brings us in a completely new position. Actually it seems that a number of the (particularly younger) representatives can be made attentive for some future oriented aspects of what LilyPond can do for them.

Of course we’ll have to see what time will tell when all the buzz has calmed down and we’ll know which of the enthusiastic conctacts may actually lead to some concrete projects or cooperations. As a conclusion it has been very good for us to be there, actually I think it would have been useful if we’d had an “official” representation at the Musikmesse, be it as beautifulScores.net or as LilyPond – because we have the impression that the time is ripe to really push LilyPond into the minds of the representatives of the music publishing business.

We would also like to thank everyone who already backed our crowdfunding campaign – after three days we already are at 533 Euro, and it would be great if the funds continue to flow in at this rate :-) Spread the word!

by Urs Liska at March 14, 2014 10:58 PM

Create Digital Music » open-source

microGranny 2.0 is a New Handmade Granular Sampler from the Czech Republic

bastl_messe

“Bastl” is Czech slang that’s roughly equivalent to the maker culture or DIY. And now, from the makers of the glitchy, odd, and wonderful world of Standuino, comes a new granular sampler, a follow-up to a terrific earlier kit.

The Bastl crew are showing off the microGranny 2.0 among lots of other new gear here at Musikmesse. They’ve added some functionality to the instrument (copy/paste, more presets), and put it in a very attractive housing.

But as before, you get a hackable, happily lo-fi sample mangler. Load up your sounds on SD card, then manipulate them with hands-on controls or via MIDI. You can loop, change the sample rate, crush, and add envelopes. And check out the code; it’s built from open libraries.

The whole project is made in the Czech Republic:

Most of the components we get are from local distributor, PCBs are produced in small town Blansko 20km north from Brno, laser cut parts are made by our friends in Razzia in Brno. All of this comes to our tiny “factory” office, gets sorted into kits and the assembled instruments are made by locals who are partly from the Bastl generation (50+).

And with that in mind, the very short first run (just thirty units) will have some special Czech touches. You get vintage knob caps – the orange models look strikingly modern and stylish – plus a sample bank from 80s pop music, each salvaged from the former Czechoslovakia.

microgranny2

Future Music paid the creators a visit and shot some lovely video:

Full specs:

monophonic mono sampler
microSD card (storing + recording samples, storing presets)
6 sounds with full adjustments storable in a preset at once
60 presets in 10 banks (6 preset per bank), stored as .txt files on microSD card
wav sample playback from microSD card (mono, 22050 Hz, 8 or 16 bit, two letter file name)
8-bit 22050Hz wav recording via line input or onboard microphone
hold button
sample rate (tuned or free run)
crush
start, end position with repeat, instant loop
granular settings: grain size and shift speed (positive or negative)
amplitude envelope attack and release
MIDI Input – responds to note, cc and clock (synchronize loop and grains)
MIDI side chain envelope restart
copy, paste
input & output volume knob
power switch – plug / battery
hackable – arduino based

More – and direct preorder link:

http://www.bastl-instruments.com/instruments/microgranny/

The post microGranny 2.0 is a New Handmade Granular Sampler from the Czech Republic appeared first on Create Digital Music.

by Peter Kirn at March 14, 2014 04:54 PM

March 12, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] aubio 0.4.1

From: Paul Brossier <piem@...>
Subject: [LAA] aubio 0.4.1
Date: Mar 12, 7:15 pm 2014

Hi all,

A new version of aubio, 0.4.1, is out.

aubio is a library of functions to perform audio feature extractions
such as:

- note onset detection
- pitch detection
- beat tracking
- MFCC computation
- spectral descriptors

This version is mostly focusing on media file input and output. Here is
a quick overview of the changes.

The most interesting feature in this release concerns aubiocut. Thanks
to the sponsoring of Mark Suppes, the python script to slice sound
steams was extended to be sample accurate, cut overlapping segments, and
work on multiple channels.

New source and sink objects have been added to let aubio read and write
WAV files, even when built with no external libraries. This should
simplify the use of aubio on platforms such as Android or Windows.

Existing sources and sinks have been extended to read and write from and
to multiple channels. This makes python-aubio one of the fastest and
most versatile Python module to read and write media files.

This release also comes with a stack of bug fixes and code clean-ups.

Note: this version is API and ABI compatible with 0.4.0. Since it only
adds new features to the existing interface, your existing source and
binary code will keep working without any modifications.

To find out more about aubio and this release:

Project homepage:
http://aubio.org/

Post announcing aubio 0.4.1:
http://aubio.org/news/20140312-1953_aubio_0.4.1

ChangeLog for aubio 0.4.1:
http://aubio.org/pub/aubio-0.4.1.changelog

Source tarball, signature and digests:
http://aubio.org/pub/aubio-0.4.1.tar.bz2
http://aubio.org/pub/aubio-0.4.1.tar.bz2.asc
http://aubio.org/pub/aubio-0.4.1.tar.bz2.md5
http://aubio.org/pub/aubio-0.4.1.tar.bz2.sha1

API Documentation:
http://aubio.org/doc/latest/

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

read more

March 12, 2014 08:00 PM

aubio

0.4.1 is out

A new version of aubio has been published. This version is mostly focusing on media file input and output. Here is a quick overview of the changes.

  • The most interesting feature in this release concerns aubiocut. Thanks to the sponsoring of Mark Suppes, the python script to slice sound streams was extended to be sample accurate, cut overlapping segments, and work on multiple channels.
  • New source and sink objects have been added to let aubio read and write WAV files, even when built with no external libraries. This should simplify the use of aubio on platforms such as Android or Windows.
  • Existing sources and sinks have been extended to read and write from and to multiple channels. This makes python-aubio one of the fastest and most versatile Python module to read and write media files.
  • This release also comes with a stack of bug fixes and code clean-ups.

Read the changelog to find out more details about what 0.4.1 brings.

Note: this version is API and ABI compatible with 0.4.0. Since it only adds new features to the existing interface, your existing source and binary code will keep working without any modifications.

Download aubio 0.4.1

Happy hacking!

March 12, 2014 06:53 PM

March 11, 2014

Scores of Beauty

Oskar Fried: the Big Bang

It seems the circle is going to close now.
Nearly three and a half years ago Janek introduced himself to the lilypond-user mailing list with this message – and see who were his first two contacts from the LilyPond community :-) .
In the meantime we had several projects, exchanged thousands of emails (not including on-list communication), even talked a few times over Skype – but never had the opportunity to see us in natura (and I think our Avatars aren’t exactly revealing). Now’s the time to change this: On Friday we’ll finally meet at the Musikmesse Frankfurt! Let’s hope the blind date won’t be a disappointment ;-) .

But this isn’t the Big Bang promised in this post’s title. ;)

The Big Bang is that…

… (drum roll) …

This Friday we’ll receive the BEST EDITION 2014 award of the German Music Publishers’ Association for our edition of Oskar Fried’s songs!! :) :) :)
BEST-EDITION-small

Of course we were absolutely thrilled when we heard about the election, and it was hard to keep it private until today. It seems the hard work that we put in this project finally paid off :) . I think we continued to strive for perfection even after the point when most publishers would have been satisfied with the results – and also when we ran out of budget. We also worked hard to refine our innovative collaborative workflows and to promote them publicly. Considering what I wrote on this blog alone it’s hard to imagine that it was only in the course of this project that I learned about version control with Git and finally decided to use LaTeX.

Thank You!!

This is an opportunity to express our deeply felt gratitude. Towards the people who developed such great tools as LilyPond, LaTeX, Git and also Frescobaldi, but also towards the community that was so helpful for our work. So many issues wouldn’t have been solved without competent assistance on lilypond-user and on StackExchange. Additionally there are numerous tools in our function library that have been created or updated by others on our request. We are very happy – and to some extent also proud – that a number of them are by now an integral part of LilyPond itself. Updating our edition to current LilyPond versions will to a significant degree mean removing our library functions because they aren’t necessary anymore :-) .

Another way of expressing our gratitude towards the community is our intention to open up the edition to make it available under a free license. This will allow anybody to investigate the sources, make modifications (e.g. personal transpositions) or even improve the edition – be sure to read on!

volume-front-600

beautifulScores.net

We found it cute to invent a wannabe company name and a logo for inclusion in the Fried edition, and now it turns out that it has been a really nice idea. As a reaction to the award we’re going public now with this and present beautifulScores.net, our engravers’ collective offering innovative solutions around scores and music books. Of course this is initially Janek’s and my “baby”, but if you’re interested in joining us don’t hesitate to write us an email. We’ll probably need a certain number of copyists for one or more Crowd Engraving projects, and we’ll be also happy to collaborate with people with higher and perhaps specific skillsets (e.g. historic or contemporary notation, Scheme or Python skills, management of a Git server etc.).

Meet us in Frankfurt

If you have the opportunity to go to Frankfurt we’d be happy to meet you there. We’ll be at the Messe from Thursday (March 13) noon throughout Friday evening. Janek will stay in Frankfurt for Saturday too. Our base camp will be the Booth of SCORA, a company offering exciting LilyPond based digital music stands (3.1 B34). This looks really interesting, and I’m looking forward to seeing it in action. Parts of our Fried edition will be displayed in SCORA’s hardware.
If you intend to come it’s advisable to drop us an email in advance so we can exchange mobile phone numbers.

If you come to Frankfurt you can browse the other 126 pages too ...)

If you come to Frankfurt you can browse the other 126 pages too …)

Freely Created… and Freely Available?

While we worked on the project we were very conscious about the fact that the edition was created nearly exclusively with free software. Nearly. There are two exceptions to this, one fundamental and one more or less accidental. As I felt unable to create a good-looking cover with LaTeX (at least in the given timeframe) I deferred this to our fellow collaborator, Alexander Gurdon, who created it using InDesign. Today I wouldn’t go that route anymore and would do this with LaTeX too.
A more serious “flaw” is the use of non-free text fonts. Even after some research and a widely-discussed survey on lilypond-user I did not find a satisfying replacement for Adobe’s Minion Pro. Apart from its elegant appearance this font really scores with its wealth of different weights and widths, which made it possible to find font faces for all kinds of text elements, ideally matching the appearance of the music engraving.

We created this edition using free software and benefitted from this freedom, through the community spirit in general, but also through the possibility to tweak and improve the tools we used. Examples for this are the mentioned improvements through others, the development of my lilyglyphs LaTeX package to use notational symbols in text, and the fact that we were able to compile our scores with a custom-built LilyPond containing some patches by Janek and by David Kastrup – try that with Finale ;-) . Now we’ve got this fantastic public acknowledgment of our work, and we want to partly redirect this attention to the tools we use. But somehow it doesn’t feel right to have all this work on and with free software resulting in a proprietary product that is only accessible through buying the printed copy, without allowing other people to improve it further, make derivative versions (e.g. transpositions, or a version using only free fonts). If this edition is to become a real “flagship” project for LilyPond, usable as a proof of its professional capabilities, usable as an object to study our – exemplary or flawed – coding techniques, or usable to trigger any sort of community project around it, then it should be a freely redistributable piece of “software”.

I have to admit that initially I wasn’t all that enthusiastic about this idea, and had to be convinced about it through a (unusually calm) discussion with a number of LilyPond’s developers. But now I think that it actually is a good idea to open up our edition and make it freely available. I’m glad that I could convince our publisher to follow us here. So we decided to open up the edition and make their sources available under a free license – as soon as all expenses have been covered. Of course nobody will expect us and our publisher to do this while still having invested considerable amounts of time and money …

We need your support to make this edition Free!

By now both me and Janek are convinced that freeing the edition is a good idea and that it will be also good for LilyPond. What we need is your financial support – we must cover the publisher’s expenses before we’ll be able to free the edition.

There are two major ways of helping us with this goal: you can buy printed copies of the edition (which we consider a rewarding investment anyway if you care for beautiful scores and/or romantic music), ideally directly from the publisher, or you can support our campaign at Indiegogo (even the smallest contributions count!). There you’ll find a great number of interesting perks, ranging from PDF/Source packages over printed copies, an interview on our blog up to donating a bug fix/feature request for LilyPond. Even if you can’t support this campaign financially please spread the word :) – we really count on you, and we want to make all this a worthwile event for free culture and software :) .

by Urs Liska at March 11, 2014 10:56 AM

March 10, 2014

Create Digital Music » open-source

One Awesome Jam, Four Sequences, 32-Steps: New MTRX Hardware Sequencer Video

Fyrd Instruments’ MTRX is a beautiful-looking, boutique hardware sequencer. But its one drawback had been the 8-step sequencer. Now, this should give you steps: think four simultaneous sequences, 32 steps, and the ability to output on the MIDI port and USB port simultaneously.

Commenters frequently complain that technology for its own sake gets in the way of music. Well, that may be so, but here, the sequence sounds excellent. Our own MeeBlip (in the older SE version) joins some other great hardware and software: the Shruthi open source hardware, Native Instruments’ Monark, and Madrona Labs’ Aalto – three of my favorite synths. (By the way, hearing it again, the SE-generation MeeBlip sounds good, but I can confidently say I think anode sounds better; it’s now shipping and we’ll have it at Musikmesse this week.)

You get robust sequencing on all four sequencers:

- pitch, velocity, octave, duration
- shift (small delay of each step)
- bend (pitch wheel sequencing – Slide/Glide effect)
- active step selection, loop length
- speed (1/32th, 1/16th, 1/8th, 1/4th)
- warp (forward/backward/ping-pong/random)

And there’s a new MTRX-S, replacing the previous MTRX-8. That’s “S” as in “small” – the MTRX-S is more compact than the original, but otherwise identical. Pre-orders are now 249 €.

http://fyrd-instruments.com/

MTRX04

Curious about the MTRX sequencer? I wrote a review for DE:BUG here in Germany, which you can read in either English or German:

REVIEW: FYRD INSTRUMENTS MTRX-8 (ENGLISH)

IM TEST: FYRD INSTRUMENTS MTRX-8

Spoiler alert:

The only real issue with the MTRX-8 is that you may find the button-and-jog wheel scheme limiting, and wish that you had more controls – and less paging through menus. But if your primary application for a step sequencer is fine-tuned control of dance patterns and bass lines, the MTRX-8 is a bargain.

Now, I think those tradeoffs are even less of an issue once you have access to these four sequencers and 32 steps. Most hardware sequencers available today are pricey affairs. That makes this a really wise choice; I can see why the last run sold out.

The post One Awesome Jam, Four Sequences, 32-Steps: New MTRX Hardware Sequencer Video appeared first on Create Digital Music.

by Peter Kirn at March 10, 2014 04:08 PM

March 09, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] OpenAV : ArtyFX 1.1

From: Harry van Haaren <harryhaaren@...>
Subject: [LAA] OpenAV : ArtyFX 1.1
Date: Mar 9, 6:18 pm 2014

--001a11c26f00b8098a04f42e13fb
Content-Type: text/plain; charset=ISO-8859-1

Hey All,

Its my pleasure to announce ArtyFX 1.1, with three new plugins!
The plugin are distortion, feedback delay, and 4-band eq.

Demo video: http://www.youtube.com/watch?v=aPQOZK-yKy8
ArtyFX page: http://openavproductions.com/artyfx/

OpenAV wishes to thank Steve Harris for authoring Barry's Satan Maximizer:
Satma's DSP routine is derived from that work. OpenAV also wishes to thank
Fons Adriaensen for writing the 4-band parameteric equalizer, as Kuiza uses
his implementation as DSP routine.

Contributions to release ArtyFX 1.1 welcomed, see the ArtyFX page for
details:
http://openavproductions.com/artyfx

Cheers, -Harry

--001a11c26f00b8098a04f42e13fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey All,

Its my pleasure to announce Arty=
FX 1.1, with three new plugins!
The plugin are distortion, feedbac=
k delay, and 4-band eq.

Demo video:
m/watch?v=3DaPQOZK-yKy8">http://www.youtube.com/watch?v=3DaPQOZK-yKy8

r>
OpenAV wishes to t=
hank Steve Harris for authoring Barry's Satan Maximizer:

Satma's DSP routine is derived from that work. OpenAV also wishes to th=
ank
Fons Adriaensen for writing the 4-band parameteric equali=
zer, as Kuiza uses
his implementation as DSP routine.


Contributions to release ArtyFX 1.1 welcomed, see the ArtyFX=
page for details:
http:=
//openavproductions.com/artyfx


Cheers, -Ha=
rry



--001a11c26f00b8098a04f42e13fb--

read more

March 09, 2014 07:00 PM

March 08, 2014

Scores of Beauty

Engraving statistics: timing

This post is part of a series analyzing LilyPond’s performance during the preparation of a new edition of Oskar Fried’s songs.

Hello again!

Our regular readers must have noticed that our “blogging schedule” is recently quite spotty – we apologize for that! There’s a lot of things that are keeping us busy, and one of them is very important news for LilyPond – we’re going to announce it this Tuesday, be sure to drop by! :)

Anyway, I’ve recalled that I had written one more post draft about our Fried project, and I’ve decided to finish it because this information may be interesting for you: it’s the concluding statistic – the timing of my work.

So, how efficient time-wise is LilyPond in real-life usage? Fortunately, for the last 8 songs (out of 26) I’ve been measuring the time spent during the “beautification” process. Since we were using version control, I had a convenient place to store this metadata – commit messages:

916b88d 8-1 beautification: missed one extender (14 min)
b136ddb 8-1 beautification: fix lyric extenders (10 min)
ace7661 8-1 beautification: lyric alignment (7 min)
ac07f8d 8-1 beautification (20 min)
a7a776d 8-1 beautification: mostly slurs (10 min)
010b1e8 8-1 beautification: mostly slurs (18 min)
e769159 8-1 beautification: slurs (20 min)
02b39f7 8-1 beautification: slurs (15 min)
b060a9b 8-1 beautification: slurs (37 min)
f817400 8-1 beautification: fix melisma alignment (12 min)
5c9262b 8-1 beautification: slurs (17 min)
a6ce7af 8-1 beautification: fix voicing (14 min)
454bc2d 8-1 beautification: slurs (22 min)
d091a89 8-1 beautification: slurs (42 min)
32c0e18 8-1 beautification: cross-staff, last system (25 min)
c6baaef 8-1 beautification: mostly beams (11 min)
17d665b 8-1 beautification: ties (53 min)
a03d4a5 8-1 beautification (5 min)
55c4edc 8-1 move 3rd stanza metronome mark (4 min)
2661429 8-1 beautification: squashing to fit system (40 min)
a14f4e7 8-1 beautification: metronome mark (6 min)
7cbec4a 8-1 beautification: dashed slurs (10 min)
c38d7a5 8-1 fix lyrics alignment (was caused by a typo) (5 min)

Based on the data I gathered, average beautification time for this type of music is 85 min/page. In addition to the actual work there is always maintenance time (discussing non-trivial issues, either via email or using an issue tracker, managing the code etc.) which I estimate to be something like 32 min/page. And, of course, there is also the time needed for the input of the musical content, but unfortunately I don’t have data about this.

Taking into account additional time initially spent on discussing and setting the project up, as well as extra maintenance time lost when we hadn’t switched to version control yet – I estimate this to be about 45 hours, but it’s a very uncertain guess – we arrive at a figure of 230 hours for the beautification of all scores. Since I wasn’t timing my work in the beginning, I estimate the uncertainty of this number to +/- 30%, with 90% confidence.

230 hours translates to 6 weeks of full-time work to beautify the raw output for roughly 100 pages of music. Is this result good or bad? It’s difficult to judge without information on how other notation programs (and other engravers) would perform on similar music. I would say that 230 hours is unsatisfactory – particularly measured against LilyPond’s claim of automatic music engraving. This seems still far away, at least in the case of complex piano music.

However, we should keep in mind that for both me and Urs this was the first project of this size. I expect that with the gained experience a follow-up project would be completed about 25% faster.

Curves

As you can see in the commit listing above, I have tried to group different types of fixes together – for example, commit slur changes separately from lyrics changes and so on. This allowed me to calculate average times needed for adjusting a curve – they are:

  • 1.5 minute per slur
  • 1 minute per tie

In total, I estimate that shaping slurs and ties took about 40 hours, i.e. 25 minutes/page of music. This is 30% of all time needed for beautification – as I’ve said, it’s probably the most time-expensive part of the beautification process! It is good to know that there are improvements at the horizon, most notably the prospect of being able to edit curves graphically in Frescobaldi in the foreseeable future.

Recompiling

As a “post-scriptum”, I have to mention a small annoyance that, unfortunately, appears in all projects engraved using LilyPond: having to wait while the score recompiles. This is insignificant when preparing a small piece, but when dealing with a bigger project, it results in some wasted time. Fortunately, I have just recently bought a fast laptop, and the whole Fried project consisted of many short pieces (1-8 pages each), so the recompilation times were usually in the range of 3-9 seconds. But even these seconds piled up and contributed to the total time spent. What’s more, they affected my workflow – since I did have to wait before seeing the results of my adjustments, the working process wasn’t as smooth as it could be. This may seem insignificant, but I do believe that if the times of compiling LilyPond scores went down from the rage of 5-50 seconds (for the not-so-big pieces) to the range of 0.1-1 seconds, it would mean that the experience of working with LilyPond would be totally different. And by different I don’t simply mean faster and therefore better – I mean that this would be a qualitative leap that would allow us to work in completely different, more natural ways. As an intermediate workaround we will have to look for ways to recompile only smaller parts of the complete score, the ones we’re actually interested in.

I could now write a long elaboration on this topic, but since it was already covered by smarter and more experienced people than me ;) , let me just recommend you looking at Linus Torvalds’ talk about Git and this article written by Joel Spolsky, an influential IT blogger.

See you again on Tuesday when we’ll bring this series of posts about Oskar Fried to a – preliminary – end! :)

by Janek Warchoł at March 08, 2014 11:50 PM

March 07, 2014

Create Digital Music » open-source

A Surround Sound System You Can Carry Like an Umbrella, ‘Anywhere’

anywhere

Music is transformed by context, by instrumentation and space and setting. With amplified music, thinking about content alone isn’t enough. Visualists now work with projection mapping and lighting constructions and lasers and the like. It seems electronic musicians as a scene may benefit from thinking more about speakers.

We saw recently 4DSOUND, an immersive architectural installation. But that requires carrying around columns. Here’s a multichannel system you can tote along with you, like an umbrella. The results look like a prop from a post-apocalyptic Terry Gilliam movie; it’s sound as object.

pseudo multichannel personal autonomous sound installation with 10 panning spots
- 10 speakers
- optical relays
- arduino uno
- micro sd wav player

Practical? Perhaps not. But it’s a reminder that there are many unexpected ways to get sound to a listener.

The project is the work of Moscow-based “media-artist, musician and engineer of strange-sounding mechanisms” Dmitry Morozov. He has posted plans and full Arduino source code if you’d like to try this yourself.
http://vtol.cc/filter/works/anywhere

And you can find a network of artists around Moscow doing this stuff:
http://soundartist.ru/

::vtol:: “anywhere” from ::vtol:: on Vimeo.

The post A Surround Sound System You Can Carry Like an Umbrella, ‘Anywhere’ appeared first on Create Digital Music.

by Peter Kirn at March 07, 2014 04:27 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Vee One Suite 0.4.0 - A proto-beta party!

From: Rui Nuno Capela <rncbc@...>
Subject: [LAA] Vee One Suite 0.4.0 - A proto-beta party!
Date: Mar 7, 9:50 am 2014

Howdy,

as to no surprise (rly?) the so called Vee One Suite of old-schoolyards
gets bullied down to another bump in the head: now turning into a
proto-beta party?

righto!

again as usual, all made available in dual form:

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

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


[1] synthv1 - an old-school polyphonic synthesizer

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

- source package:

http://download.sourceforge.net/synthv1/synthv1-0.4.0-14.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/synthv1/synthv1-0.4.0-14.rncbc.suse131.i586.rpm

http://download.sourceforge.net/synthv1/synthv1-0.4.0-14.rncbc.suse131.x86_84.rpm


[2] samplv1 - an old-school polyphonic sampler

samplv1 is an(other) old-school all-digital 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.4.0.tar.gz

- source package:

http://download.sourceforge.net/samplv1/samplv1-0.4.0-14.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/samplv1/samplv1-0.4.0-14.rncbc.suse131.i586.rpm

http://download.sourceforge.net/samplv1/samplv1-0.4.0-14.rncbc.suse131.x86_84.rpm


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

drumkv1 is (yet) an(other) old-school all-digital 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.4.0.tar.gz

- source package:

http://download.sourceforge.net/drumkv1/drumkv1-0.4.0-10.rncbc.suse131.src.rpm

- binary packages:

http://download.sourceforge.net/drumkv1/drumkv1-0.4.0-10.rncbc.suse131.i586.rpm

http://download.sourceforge.net/drumkv1/drumkv1-0.4.0-10.rncbc.suse131.x86_84.rpm


see also:
http://www.rncbc.org/drupal/node/770


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

read more

March 07, 2014 10:00 AM

March 06, 2014

rncbc.org

Vee One Suite 0.4.0 - A proto-beta party!

Howdy,

as to no surprise (rly?) the so called Vee One Suite of old-schoolyards gets bullied down to another bump in the head: now turning into a proto-beta party?

righto!

again as usual, all made available in dual form:

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

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

synthv1 - an old-school polyphonic synthesizer

synthv1 0.4.0 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.4.0 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.4.0 is out.

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

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

Flattr this

Enjoy.

by rncbc at March 06, 2014 06:00 PM

Linux Audio Announcements - laa@linuxaudio.org

[LAA] DrumGizmo 0.9.4 released

From: Lars Muldjord <muldjordlars@...>
Subject: [LAA] DrumGizmo 0.9.4 released
Date: Mar 6, 7:49 am 2014

New release: DrumGizmo 0.9.4

The most prominent features included in this release are:
* Floating velocity groups now enabled and working
* Multichannel sample support supported but not yet in use
* Filebrowser improvements
* Plus the usual pile of bug fixes and optimizations

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

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

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

read more

March 06, 2014 08:00 AM

Hackaday» digital audio hacks

From Wireless Soundbar to Portable Boombox

toshiba-mini-soundbar-online

[Frank] had wanted a portable Bluetooth boombox for a while, but when he did some price comparisons he found that they are pretty expensive. He decided to take matters into his own hands and modify two products he already had – into what he wanted.

The guts of his Frankenstein-boombox come from a Toshiba 3D Soundbar — a great product, but not as durable or portable as he needed. He then took an old mini guitar amp and started hacking the two together.

The soundbar features 4 speakers and a sub woofer — plus the amp and wireless capabilities of course — so [Frank] opted to just use the case of the guitar amp with the soundbar’s innards. He took some measurements and then built up a wooden support for the speakers inside the amp. He’s also sealed off the tweeters sound cavity from the main SUB to keep the sound nice and clear. 

In addition to the Bluetooth control — the unit also comes with a remote. Can you spot his cleverly hidden IR sensor?

img_20140304_111537

What we also like about this project is his colorful narrative as he explains his process — it kind of reminds us of [Arduinoversusevil's] video on his Accurate-ish Pneumatic Cylinder Positioning. You can just tell he had an absolute blast hacking this together.

For another unorthodox Bluetooth boombox — have you seen this potato cannon?


Filed under: digital audio hacks

by James Hobson at March 06, 2014 03:00 AM

March 03, 2014

Create Digital Music » open-source

Making Music Tools Free in Pd, from Hacking to Playing: Photos and Impressions, Amsterdam Thursday

Thumb piano + Pd.

Thumb piano + Pd.

Music technology: old meets new.

Music technology: old meets new.

There is something phenomenal happening in music technology right now. We usually write about the developments in the tools themselves. But if you want to see new things happening, it’s often more about the spread of knowledge around those tools.

Watching it evolve is astounding. Focus only on the tools, and the landscape hasn’t changed much in recent years. But look at the people using them, and it’s a different story. More and more diverse audiences of artists are picking up the skills to use these inventions, and they bring a wider range of aesthetics and ideas to how they’re used.

I’m fortunate to get to play even a small part in that. And that means sometimes going from being a disembodied voice on the Web to getting in a room with people to teach, experiment, and trade ideas. There’s great education happening around commercial tools, but I especially like starting people with Pure Data and Processing because they are free, and there’s a level playing field. People can show up with any laptop (or even a netbook), any OS, and get to work. (And they can still apply the same skills to other tools – working in Pd and Max for Live, for instance – if they so choose.)

We tried a new format last year co-organized with Elisabeth Neid, at an event in collaboration with Berlin’s Mindpirates. (They’re the same folks who made this free Red Bull Music Academy film making the rounds now.) The goal: go from learning to experimental hacking to playing. And I was stunned by the results, as vocalists and VJs, instrumentalists and coders all came from radically different skill levels to jam together by the third day.

Next stop, Netherlands Thursday: If you’re near Amsterdam this week, registration is still open for a more compressed workshop hosted by Fiber Festival and 5 Days Off, as part of the programming for an event I’m inspired by entitled “Coding the Club”:

THE ENCODED GROOVE: FREE SOUNDMAKERS WITH PURE DATA

I hope you can make it, if you’re in the Netherlands – advance registration is required (the earlier, the better, so we can plan).

But I also want to share the outcome of our past workshop. Czech-born sound artist and journalist Zuzana Friday Prikrylova was there as a participant, and I asked her to write a frank appraisal of what it was like learning as a beginner. I’m actually blushing a bit as it focuses on me, but my aim is actually a bit different – I’m curious to hear what the teaching and learning experience with something like Pd has been for other readers.

Friday gives us some thoughts and a nice photo essay that paints a portrait of how things went. Here she is. -Peter Kirn

laptopsonacid7

laptopsonacid8

Create Digital Music & Mindpirates: Laptops on Acid workshop
23rd – 25th May 2013, Berlin

When I got a chance to attend the workshop Laptops on Acid organized by Peter Kirn together with the arts collective Mindpirates, I got very excited. The program promised to teach us about making our own free DIY tools for beats and visuals in two programs: Pure Data (Pd) and Processing.

The process of exploring and applying what we learned was divided into three components: LEARN, which took place on Thursday and partly on Friday and provided insight into both programs; HACK (Friday and Saturday), when we used the acquired knowledge by trying our own projects (including connecting our laptops to devices we brought like MIDI keyboards or instruments), and PLAY – an open jam on Saturday, where we were free to play around together.

The whole workshop took place in the industrial spaces of Mindpirates’ Projektraum and Vereinsheim, located near Schlesisches Tor, where this artistic collective organizes exhibitions, festivals, music events, and other projects. Thanks to the fact that the building used to be a bakery, its rooms abound with factory-like yet comfortable genius loci and provided great space for our work. And when it got too dark for our strained eyes, ubiquitous candles helped us. Mindpirates also provided vegan dinners and snacks every evening, so the participants could fully concentrate on working.

Apart from me, Peter, and the organizer hosting on behalf of Mindpirates, Elisabeth Neid, there were 22 participants. Each one of us had different backgrounds and experience. Some had previous experience with building DIY synths Arduino and Pd – there was a university lecturer, a jam organiser, and a programmer from SoundCloud. Some had no previous experience in music (one VJ travelled all the way from Helsinki), or even no previous experience with music, visual art, or programming at all! And still each one of us has found his/ her place there.

laptopsonacid9

laptopsonacid6

laptopsonacid4

At the beginning, there was tabula rasa. And by that I don’t only mean the blank-white project window of Pd, which was waiting for me to be filled with patches. I also mean myself and my previous experience with Pd, Processing, or any patching program at all – there was none. The important sentence for me in description of the event actually was “No previous coding background required.” Therefore, I used myself as a guinea pig to test the truth of this claim. And the result is quite pleasing!

With limited time and so much to teach, Peter Kirn didn’t lose time by giving us a long theoretical lecture about patching or Pure Data on Thursday, but tossed us directly into open water and gave us a hand with learning how to swim. So after a brief but enticing introduction, during which he named all the different (musical and visual) instruments we can actually build in Pd – from a vocoder to a video mixer – we were confronted with creating itself and started our hands-on lesson.

At first, we learned the most-used objects in Pd, their functions and shortcuts, as well as basic functions and settings of Pd itself (connecting patches, switching modes, etc.). Peter also compared Pd and Processing in terms of how they work. The first thing we created was a simple oscillator, which sounded like an airplane or music experiments from the 50s, and, as most of the other stuff we built, worked on the basis of principles of MIDI data flow. We continued building a synthesizer with envelopes, and later on, Peter continued explaining different types of signal, including data rate (MIDI) and audio rate (for audio signal) and how to normalize ranges for each (0-127 for MIDI, 0-1 for audio signal and certain data types). Later, we learned basic information about Processing, from drawing basic geometry to moving it around the screen and adding color. Eventually, Peter connected Pd with Processing, so the picture and sound could interact.

laptopsonacid12

laptopsonacid18

laptopsonacid14

laptopsonacid11

On Friday, everybody was free to bring external devices for the HACK part of the workshop. Because most of the participants brought devices based on MIDI (plus some more unusual additions like an electric contrabass), he focused on explaining how to connect MIDI devices to Pd and create those patch structures, which would enable to manipulate and play the instruments and devices via Pd.

Later on, we divided into two groups: one focused on playing around with MIDI control as the other, including me, deepened our knowledge in patch construction, creating sequencers and other instruments. We also learned how to “cheat” by borrowing bits and pieces from the free and open source rjlib library, using this to quickly create effects for a guitar or a microphone. At the end of the evening, Peter showed us more possibilities of manipulating images in Processing, so a picture or a video texture could be fragmented live.

On a rainy Saturday, we met at 3 pm to continue playing around and discovering possibilities in our patches and instruments, eventually leading to an open jam in the Vereinsheim space. Most of the participants played improvised music and used the skills they learned during the three days, experimented with instruments, reacted to each other and created ambient and experimental potpourri of soundscapes.

Musical performance were accompanied by visual performances made by Peter Kirn in Processing, transforming from impressive urban sceneries to abstract minimalistic patterns and lines. I stayed aside though, and just played a bit of the piano for a while – not only because my unorganized mind forgot to borrow a cable to connect a microphone with my laptop, but mostly because improvised singing in the constantly changing flow of music would require too much creative concentration, which I regrettably lacked after the 3-day marathon. So I just let my mind get carried away in my colleagues’ music performances, collecting the whole experience from Thursday to Friday in my head.

laptopsonacid5

laptopsonacid3

laptopsonacid2

laptopsonacid15

laptopsonacid13

During the workshop I wrote a bunch of notes, some of them relating to the creation process, some of them describing the workshop in general because of the report; therefore, it was not that difficult for me to overlook something important and then ask about it again. But Peter was patient enough to answer our questions and repeat the useful answers out loud for the others.

Otherwise, his lecture style was very enthusiastic, it flowed smoothly and fast like a river stream, so from time to time it was a bit difficult for us to catch up. On the other hand, not only that he could explain practically everything in a very understandable way using various metaphors, but also inserts a number of killing jokes and funny comments. So listening to him was therefore both interesting and amusing at the same time.

I’m looking forward to explore the possibilities of Pd at home at my own pace, and although I think that the previous knowledge or programming is helpful and sometimes I got lost in all those ones and zeros (or ones and one hundred-twenty-sevens to be precise), this three-day long trip to Patchingland taught me, and each one of us, a lot.

Thanks to it, I got the basic insight of the functions of Pure Data and principles of patching in general, which opens the door to countless possibilities in music making (with the help of websites recommended at the end of the workshop). I also learned how to build different patches together to create a synthesizer and effects for analog instruments or microphone. And finally, it was a lot of fun and a cool occasion to meet people from all the different fields of music, art and programming. I can’t think of many better ways of how to spend a weekend in cold and rainy Berlin.

Photos: Zuzana Friday Prikrylova and Peter Kirn.

Weather is warm and sunny for Amsterdam this week, but we’ll still have fun. -PK

The post Making Music Tools Free in Pd, from Hacking to Playing: Photos and Impressions, Amsterdam Thursday appeared first on Create Digital Music.

by Zuzana Friday Prikrylova at March 03, 2014 08:18 PM

woo, tangent » Music

studio slimdown

Last weekend, almost exactly five years after I bought my Blofeld synth, I sold it. With plans to move to the US well underway, I’ve been thinking about the things I use often enough to warrant dragging them along with me, and the Blofeld just didn’t make the cut. At first, the Blofeld was the heart of my studio — in fact, if I hadn’t bought the Blofeld, I may well have given up on trying to make music under Linux — but lately, it’s spent a lot more time powered off than powered up.

Why? Well, the music I’m interested in making has changed somewhat — it’s become more sample driven and less about purely synthetic sounds — but the biggest reason is that the tools available on Linux have improved immensely in the last five years.

Bye bye Blofeld -- I guess I'll have to change my Bandcamp bio photo now

Bye bye Blofeld — I guess I’ll have to change my Bandcamp bio photo now

Back in 2009, sequencers like Qtractor and Rosegarden had no plugin automation support, and even if they had, there were few synths available as plugins that were worth using. Standalone JACK synths were more widespread, and those could at least be automated (in a fashion) via MIDI CCs, but they were often complicated and had limited CC support. With the Blofeld, I could create high-quality sounds using an intuitive interface, and then control every aspect of those sounds via MIDI.

Today, we have full plugin automation in both Ardour 3 and Qtractor, and we also have many more plugin synths to play with. LV2 has come in to its own for native Linux developers, and native VST support has become more widespread, paving the way for ports of open-source and commercial Windows VSTs. My 2012 RPM Challenge album, far side of the mün has the TAL NoiseMaker VST all over it; if you’re recording today, you also have Sorcer, Fabla, Rogue, the greatly-improved amsynth, Rui’s synthv1/samplv1/drumkv1 triumvirate, and more, alongside commercial plugins like Discovery, Aspect, and the not-quite-so-synthy-but-still-great Pianoteq.

I bought the Blofeld specifically to use it with a DAW, but I think that became its undoing. Hardware synths are great when you can fire them up and start making sounds straight away, but the Blofeld is a desktop module, so before I could play anything I had to open a DAW (or QJackCtl, at the very least) and do some MIDI and audio routing. In the end, it was easier to use a plugin synth than to set up the Blofeld.

Mystery box of mystery!

You can probably guess what’s in the box, but if not, all will be revealed soon

So, what else might not make the cut? I only use my CS2X as a keyboard, so I’ll sell that and buy a new controller keyboard after moving, and now that VST plugins are widely supported, I can replace my Behringer VM-1 analog delay with a copy of Loomer Resound. I might also downsize my audio interface — I don’t need all the inputs on my Saffire PRO40, and now that Linux supports a bunch of USB 2.0 audio devices, there are several smaller options that’ll work without needing Firewire.

I’m not getting rid of all of my hardware, though; I’ll definitely keep my KORG nanoKONTROL, which is still a great, small MIDI controller. In fact, I also have two new toys that I’ll be writing about very soon. Both are about as different from one another as you could get, but they do share one thing — they’re both standalone devices that let you make music without going anywhere near a computer.

by lsd at March 03, 2014 03:09 AM

March 02, 2014

zthmusic

Friday Interviews, new album report, and more..

It has been a while since I posted anything on this blog (including a Friday Interview). I’ve been incredibly, so time just hasn’t been available. As soon as things settle down a bit and I get some spare time, the … Continued

The post Friday Interviews, new album report, and more.. appeared first on zthmusic.

by zth at March 02, 2014 06:26 PM

March 01, 2014

Linux Audio Announcements - laa@linuxaudio.org

[LAA] Rivendell v2.8.1

From: Fred Gleason <fredg@...>
Subject: [LAA] Rivendell v2.8.1
Date: Mar 1, 4:37 pm 2014

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

>From the NEWS file:
*** snip snip ***
Changes:
New Switcher Device. Added support for the Broadcast Tools Sentinel4Web
AES Switcher.

Cart Recuing. Added a 'Recue' button in RDAirPlay's Edit Event dialog
to allow fast recuing of carts that were inadvertently started.

Various bug fixes. See the ChangeLog for details.

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

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

Further information, screenshots and download links are available at:

http://www.rivendellaudio.org/

Cheers!


|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|-------------------------------------------------------------------------|
| Never worry about theory as long as the machinery does what it's |
| supposed to do. |
| -- Robert A. Heinlein |
|-------------------------------------------------------------------------|

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

read more

March 01, 2014 05:00 PM