planet.linuxaudio.org

April 22, 2019

News – Ubuntu Studio

Ubuntu Studio at Linux Fest Northwest 2019

Council Chair Erich Eickmeyer will be in Bellingham, WA, USA this weekend for Linux Fest Northwest 2019, and will be bringing his audio setup to demonstrate Ubuntu Studio at the Ubuntu table. Check out the post on his personal blog!

by eeickmeyer at April 22, 2019 05:49 PM

April 21, 2019

News – Ubuntu Studio

Ubuntu Studio 18.04 Extended Support

Back in April 2018, Ubuntu Studio 18.04 was released as a non-LTS (Long-Term Support) version, which limited its support cycle to end January 2019. This was due to a number of factors, from the involvement of the team members at the time to the number of team members. In January 2019, the team came up […]

by eeickmeyer at April 21, 2019 01:55 AM

April 20, 2019

digital audio hacks – Hackaday

“Vintage” Radio Gets a Modern Makeover

Taking an old piece of gear and cramming it full of modern hardware is a very popular project. In fact, it’s one of the most common things we see here at Hackaday, especially in the Raspberry Pi era. The appeal is obvious: somebody has already done the hard work of designing and building an attractive enclosure, all you need to do is shoehorn your own gear into it. That being said, we know some of our beloved readers get upset when a vintage piece of gear gets sacrificed in the name of progress.

Thankfully, you can put your pitchforks down for this one. The vintage radio [Freshanator] cannibalized to build this Bluetooth speaker is actually a replica made to invoke the classic “cathedral” look. Granted it may still have been older than most of the people reading this right now, but at least it wasn’t actually from the 1930’s.

To start the process, [Freshanator] created a 3D model of the inside of the radio so all the components could be laid out virtually before anything was cut or fabricated. This included the design for the speaker box, which was ultimately 3D printed and then coated with a spray-on “liquid rubber” to seal it up. The upfront effort and time to design like this might be high, but it’s an excellent way to help ensure you don’t run into some roadblock halfway through the build.

Driving the speakers is a TPA3116-based amplifier board with integrated Bluetooth receiver, which has all of its buttons broken out to the front for easy access. [Freshanator] even went the extra mile and designed some labels for the front panel buttons to be made on a vinyl cutter. Unfortunately the cutter lacked the precision to make them small enough to actually go on the buttons, so they ended up getting placed above or next to them as space allowed.

The build was wrapped up with a fan installed at the peak of the front speaker grille to keep things cool. Oh, and there are lights. Because there’s always lights. In this case, some blue LEDs and strategically placed EL wire give the whole build an otherworldly glow.

If you’re interested in a having a frustrating quasi-conversation with your vintage looking audio equipment, you could always cram an Echo Dot in there instead. Though if you go that route, you can just 3D print a classic styled enclosure without incurring the wrath of the purists.

by Tom Nardi at April 20, 2019 08:00 PM

April 19, 2019

GStreamer News

GStreamer 1.16.0 new major stable release

The GStreamer team is excited to announce a new major feature release of your favourite cross-platform multimedia framework!

The 1.16 release series adds new features on top of the previous 1.14 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework.

Highlights:

  • GStreamer WebRTC stack gained support for data channels for peer-to-peer communication based on SCTP, BUNDLE support, as well as support for multiple TURN servers.
  • AV1 video codec support for Matroska and QuickTime/MP4 containers and more configuration options and supported input formats for the AOMedia AV1 encoder
  • Support for Closed Captions and other Ancillary Data in video
  • Support for planar (non-interleaved) raw audio
  • GstVideoAggregator, compositor and OpenGL mixer elements are now in -base
  • New alternate fields interlace mode where each buffer carries a single field
  • WebM and Matroska ContentEncryption support in the Matroska demuxer
  • new WebKit WPE-based web browser source element
  • Video4Linux: HEVC encoding and decoding, JPEG encoding, and improved dmabuf import/export
  • Hardware-accelerated Nvidia video decoder gained support for VP8/VP9 decoding, whilst the encoder gained support for H.265/HEVC encoding.
  • Many improvements to the Intel Media SDK based hardware-accelerated video decoder and encoder plugin (msdk): dmabuf import/export for zero-copy integration with other components; VP9 decoding; 10-bit HEVC encoding; video post-processing (vpp) support including deinterlacing; and the video decoder now handles dynamic resolution changes.
  • The ASS/SSA subtitle overlay renderer can now handle multiple subtitles that overlap in time and will show them on screen simultaneously
  • The Meson build is now feature-complete (with the exception of plugin docs) and it is now the recommended build system on all platforms. The Autotools build is scheduled to be removed in the next cycle.
  • The GStreamer Rust bindings and Rust plugins module are now officially part of upstream GStreamer.
  • The GStreamer Editing Services gained a gesdemux element that allows directly playing back serialized edit list with playbin or (uri)decodebin
  • Many performance improvements

Full release notes can be found here.

Binaries for Android, iOS, Mac OS X and Windows will be provided in the next days.

You can download release tarballs directly here: gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, gst-rtsp-server, gst-python, gst-editing-services, gst-validate, gstreamer-vaapi, gstreamer-sharp, or gst-omx.

April 19, 2019 11:00 AM

April 18, 2019

digital audio hacks – Hackaday

Bone Conducting Headphones Built Into Eye Glasses

There are times when being seen to listen to music through headphones might get you into trouble. For these moments, reach for a handy solution: bone conduction speakers that discreetly pipe the music to your eardrums through the bone of your skull. [Samuel] wanted just such a covert music listening device, so created his own in a set of 3D-printed glasses.

He first tried using an Adafruit bone-conducting transducer but found that to be too bulky. What you see here is a smaller module that [Samuel] found on AliExpress (search for bone conduction module). The GD-02 is much smaller and thus more suitable for hiding in the arm of a pair of glasses. For the rest of the electronics he used a PCB and battery from a donated set of broken Bluetooth headphones, a space for which he was able to conceal easily in the 3D-printed frame of the glasses. The battery is in one arm and the board in the other, and he says the wiring was extremely fiddly.

The result is a surprisingly svelte set of specs that you might not immediately think concealed some electronics. His choice of bright yellow filament might give the game away, but overall he’s done a great job. This certainly isn’t the first bone conduction project we’ve shown you, some of the others have used motors instead of bone conduction transducers.

by Jenny List at April 18, 2019 08:01 AM

April 16, 2019

Talk Unafraid

Adventures in Differential Flexure

How’s that for a thrilling title? But this topic really does encapsulate a lot of what I love about astrophotography, despite the substantial annoyance it’s caused me lately…

Long exposure of M51 in Hydrogen Alpha – 900s

My quest for really nice photos of galaxies has, inevitably, driven me towards narrowband imaging, which can help bring out detail in galaxies and minimise light pollution. I bought a hydrogen alpha filter not long ago – a filter that removes all of the light except from a hydrogen emission line, a deep red narrow band of light. This filter has the unfortunate side effect of reducing the total amount of light hitting the sensor, meaning that long exposures are really required to drive the signal far above the noise floor. In the single frame above, the huge glow from the right is amplifier glow – an issue with the camera that grows worse the longer my exposures. Typically, this gets removed by taking dozens of dark frames with a lens cap on and subtracting the fixed amplifier glow from the frames, a process called calibration. The end result is fairly clean – but what about these unfortunate stars?

Oblong stars are a problem – they show that the telescope failed to accurately track the target for the entire period. Each pixel in this image (and you can see pixels here, in the hot pixels that appear as noise in the close-up) equates to 0.5″ of sky (0.5 arc-seconds). This is about two to four times my seeing limit (the amount of wobble introduced by the atmosphere) on a really good night, meaning I’m over-sampling nicely (Nyquist says we should be oversampling 2x to resolve all details). My stars are oblong by a huge amount – 6-8″, if not more!

My guide system – the PHD2 software package, an ASI120MC camera and a 60mm guidescope – reported no worse than 0.5″ tracking all night, meaning I should’ve seen perfectly round stars. So what went wrong?

The most likely culprit is a slightly loose screw on my guidescope’s guiding rings, which I found after being pointed at a thing called “differential flexure” by a fantastic chap on the Stargazer’s Lounge forums (more on that later). But this is merely a quite extreme example of a real problem that can occur, and a nice insight into the tolerances and required precision of astronomical telescopes for high-resolution imaging. As I’m aiming for 0.5″ pixel accuracy, but practically won’t get better seeing than 1-2″, my guiding needs to be fairly good. The mount, with excellent guiding, is mechanically capable of 0.6-0.7″ accuracy; this is actually really great, especially for a fairly low-cost mount (<£1200). You can easily pay upwards of £10,000 for a mount, and not get much better performance.

Without guiding though it’s not terribly capable – mechanical tolerances aren’t perfect in a cheap mount, and periodic error from the rotation of worm gears creeps in. While you can program the mount to correct for this it won’t be perfect. So we have to guide the mount. While the imaging camera takes long, 5-10 minute exposures, the guiding camera takes short 3-5 second exposures and feeds software (in my case, PHD2) which tracks a star’s centre over time, using the changes in that centre to generate a correction impulse which is sent to the mount’s control software (in my case, INDI and the EQmod driver). This gets us down to the required stability over time.

My Primaluce Lab 60mm guidescope and ASI120MC guide camera on the “bench”, in PLL 80mm guidescope rings on ADM dovetails

The reason why my long exposures sucked, despite all this, is simple – my guide camera was not always changing its orientation as the imaging camera was. That is to say, when the mount moved a little bit, or failed to move, while the imaging camera was affected the guiding camera was not. This is called differential flexure – the difference in movement between two optical systems. Fundamentally, this is because my guidescope is a completely separate optical system to my main telescope – if it doesn’t move when my main scope does, the guiding system doesn’t know to correct! The inverse applies, too – maybe the guidescope moves and overcorrects for an imaging system that hasn’t moved at all.

With a refractor telescope, if you just secure your guidescope really well to the main telescope, all is (generally) well. That is the only practical potential source of error, outside of focuser wobble. In a Newtonian such as the one I use, though, there’s plenty of other sources. At the end of a Newtonian telescope is a large mirror – 200mm across, in my case. This is supported by a mirror cell – pinching the mirror can cause huge deviation (dozens or hundreds of nanometers, which is unacceptable), so just clamping it up isn’t practical. This means that as the telescope moves the mirror can move a little bit – not much, but enough to move the image slightly on the sensor. While moving the mount isn’t an ideal way to fix this movement – better mirror cells reduce this movement – it’s better than doing nothing at all. The secondary mirror has similar problems. The tube itself can also expand or contract, being quite large – carbon fibre tubes minimise this but are expensive. Refractors have, broadly, all their lenses securely held in place without issue and so don’t suffer these problems.

And so the answer seems to be a solution called “Off Axis Guiding”. In this system, rather than using a separate guide scope, you use a small prism inserted in the optical train (after the focuser but before the camera) to “tap” a bit of the light off – usually the sensor is a rectangle in a circular light path meaning this is pretty easy to achieve without any impact to the light that the sensor receives. This light is bounced into a camera mounted at 90 degrees to the optical train, which performs the guiding function. There are issues with this approach – you have a narrower (and hard to move) field of view, and you need a more sensitive guide camera to find stars – but the resolution is naturally far higher (0.7″ rather than 2.5″) due to the longer focal length and so the potential accuracy of guide corrections improves. But more importantly, your guiding light shares fate with the imaging light – you use the same mirrors, tube, and so on. If your imaging light shifts, so does the guiding light, optically entwined.

The off-axis guiding route is appealing, but complex. I’ll undoubtedly explore it – I want to improve my guide camera regardless, and the OAG prism is “only” £110 or thereabouts. The guide camera is the brunt of the cost – weighing in at around £500-700 for a quality high-sensitivity guide camera.

But in the immediate future my budgets don’t allow for either of these solutions and so I’ve done what I can to minimise the flexure of the guidescope relative to the main telescope. This has focused on the screws used to hold the guidescope in place – they’re really poorly machined, along with the threads in the guidescope rings, and the plastic tips can lead to flexure.

Before and after – plastic-tipped screws

I’ve cut the tips almost back to the metal to minimise the amount of movement in compression, and used Loctite to secure two of the three screws in each ring. The coarse focus tube and helical focuser on the Primaluce guide scope also have some grub screws which I’ve adjusted – this has helped considerably in reducing the ability for the camera to move.

Hopefully that’ll help for now! I’m also going to ask a friend with access to CNC machines about machining some more solid tube rings for the guidescope; that would radically improve things, and shouldn’t cost much. However, practically the OAG route is going to be favourite for a Newtonian setup – so that’s going to be the best route in the long run.

Despite all this I managed a pretty good stab at M51, the Whirlpool Galaxy. I wasn’t suffering from differential flexure so much on these exposures – it’s probably a case of the pointing of the scope being different and so not hitting the same issue. I had two good nights of really good seeing, and captured a few hours of light. This image does well to highlight the benefits of the Newtonian setup – with a 1000mm focal length with a fast focal ratio, paired with my high-resolution camera, I can achieve some great detail in a short period of time.

M51, imaged over two nights at the end of March
Detail, showing some slightly overzealous deconvolution of stars and some interesting features

Alongside my telescope debugging, I’m working on developing my observatory plans into a detailed, budgeted design – more on that later. I’ve also been tinkering with some CCDinspector-inspired Python scripts to analyse star sharpness across a large number of images and in doing so highlight any potential issues with the optical train or telescope in terms of flatness, tilt, and so on. So far this tinkering hasn’t lead anywhere interesting, which either suggests my setup is near perfect (which I’m sure it isn’t) or I’m missing something – more tinkering to be done!

Map of sharpness across 50 or so luminance frames, showing a broadly even distribution and no systemic sharpness deviance

by James Harrison at April 16, 2019 10:51 PM

rncbc.org

Qtractor 0.9.7 - Spring-Break'19 Release batch #3


Hi there, trice again,

Like some post-LAC2019 frenzy hangover, here comes the third and final batch-of-one:

Qtractor 0.9.7 (spring-break'19) is out!

The changes for this seasonal release are as follows:

  • Re-defined all main application UNIX signal handling.
  • Fixed possible crash in drawing clips while rare loop-recording/takes situations.
  • Main window stabilizing is now kind of asynchronous re. menus, tools and status bars.
  • MIDI Controller's Latch Trice again,
    mode attribute on tracks and plugins are now properly saved/loaded as meant to be.

Description:

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

Website:

http://qtractor.org
https://qtractor.sourceforge.io
http://qtractor.sourceforge.net

Project page:

http://sourceforge.net/projects/qtractor

Downloads:

https://sourceforge.net/projects/qtractor/files

Git repos:

https://git.code.sf.net/p/qtractor/code
https://github.com/rncbc/qtractor.git
https://gitlab.com/rncbc/qtractor.git
https://bitbucket.org/rncbc/qtractor.git

Wiki (help still wanted!):

http://sourceforge.net/p/qtractor/wiki/

License:

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

Enjoy && Please, have (lots of) fun.

Donate to rncbc.org

by rncbc at April 16, 2019 06:00 PM

April 15, 2019

GStreamer News

Orc 0.4.29 bug-fix release

The GStreamer team is pleased to announce another maintenance bug-fix release of liborc, the Optimized Inner Loop Runtime Compiler. Main changes since the previous release:

  • PowerPC: Support ELFv2 ABI (A. Wilcox) and ppc64le
  • Mips backend: only enable if the DSPr2 ASE is present
  • Windows and MSVC build fixes
  • orccpu-arm: Allow 'cpuinfo' fallback on non-android
  • pkg-config file for orc-test library
  • orcc: add --decorator command line argument to add function decorators in header files
  • meson: Make orcc detectable from other subprojects
  • meson: add options to disable tests, docs, benchmarks, examples, tools, etc.
  • meson: misc. other fixes

Direct tarball download: orc-0.4.29.

April 15, 2019 12:00 PM

KXStudio News

Carla 2.0.0 is finally here!

After many years, Carla version 2.0.0 is finally here!

Carla is an audio plugin host, with support for many audio drivers and plugin formats.
It has some nice features like automation of parameters via MIDI CC (and send output back as MIDI too) and full OSC control.

Version 2.0 took this long because I was never truly happy with its current state, often pushing new features but not fully finishing them.
So the "solution" was to put everything that is not considered stable yet behind an experimental flag in the settings.
This way we can have our stable Carla faster, while upcoming features get developed and tagged as experimental during testing.

Preparations for version 2.1 are well under way, a beta for it will be out soon.
But that is a topic for another day.

Changes since 2.0-RC4

  • Fix missing argument in note-on/off osc example
  • Fix word-wrap in add-plugin dialog
  • Fix Windows README.txt line endings
  • Build windows binaries with -mstackrealign
  • Don't show side panel in carla-control
  • Show "Label/URI" instead of just "Label"
  • Keep application signals alive (so Ctrl+C works even while engine is closed)
  • Update copyright year

Downloads

To download Carla binaries or source code, jump on over to the KXStudio downloads section.
Carla v2.0.0 is available pre-packaged in the KXStudio repositories and UbuntuStudio backports, plus on ArchLinux and Ubuntu since 19.04. On those you can simply install the carla package.
Bug reports and feature requests are welcome! Jump on over to the Carla's Github project page for those.

Videos

There is no manual or quick-start guide for Carla yet, apologies for that.
But there are some videos of presentations I did regarding Carla's features and workflows, those should give you an introduction of its features and what you can do with it:

@ Sonoj 2017

@ LAC 2018

by falkTX at April 15, 2019 06:17 AM

April 14, 2019

rncbc.org

Vee One Suite 0.9.7 - Spring-Break'19 Release batch #2


Wholly cheers!

The Vee One Suite of old-school software instruments are here again and now released for the second QStuff* Spring Break'19 batch post-LAC2019 frenzy:

All still delivered in dual form:

  • a pure stand-alone JACK client with JACK-session, NSM (Non Session management) and both JACK MIDI and ALSA MIDI input support;
  • a LV2 instrument plug-in.
  • Changes are that there are quite a few fixes since previous releases:

    • Corrected sample offset and loop range internal reset (samplv1 and drumkv1 only).
    • All audio input now get through without being processed by any or whole effects stage anymore.
    • Re-defined all JACK stand-alone client application UNIX signal handling.
    • Probable fix to sample offset and loop range changes across native UI and loading and saving state. (samplv1 and drumkv1 only).

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

    Make the fun great again!

     

    synthv1 - an old-school polyphonic synthesizer

    synthv1 0.9.7 (spring-break'19) 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:
    https://synthv1.sourceforge.io
    http://synthv1.sourceforge.net

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

    git repos:
    http://git.code.sf.net/p/synthv1/code
    https://github.com/rncbc/synthv1.git
    https://gitlab.com/rncbc/synthv1.git
    https://bitbucket.org/rncbc/synthv1.git

     

    samplv1 - an old-school polyphonic sampler

    samplv1 0.9.7 (spring-break'19) is out!

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

    LV2 URI: http://samplv1.sourceforge.net/lv2

    website:
    https://samplv1.sourceforge.io
    http://samplv1.sourceforge.net

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

    git repos:
    http://git.code.sf.net/p/samplv1/code
    https://github.com/rncbc/samplv1.git
    https://gitlab.com/rncbc/samplv1.git
    https://bitbucket.org/rncbc/samplv1.git

     

    drumkv1 - an old-school drum-kit sampler

    drumkv1 0.9.7 (spring-break'19) is out!

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

    LV2 URI: http://drumkv1.sourceforge.net/lv2

    website:
    https://drumkv1.sourceforge.io
    http://drumkv1.sourceforge.net

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

    git repos:
    http://git.code.sf.net/p/drumkv1/code
    https://github.com/rncbc/drumkv1.git
    https://gitlab.com/rncbc/drumkv1.git
    https://bitbucket.org/rncbc/drumkv1.git

     

    padthv1 - an old-school polyphonic additive synthesizer

    padthv1 0.9.7 (spring-break'19) is out!

    padthv1 is an old-school polyphonic additive synthesizer with stereo fx

    padthv1 is based on the PADsynth algorithm by Paul Nasca, as a special variant of additive synthesis.

    LV2 URI: http://padthv1.sourceforge.net/lv2

    website:
    https://padthv1.sourceforge.io
    http://padthv1.sourceforge.net

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

    git repos:
    https://git.code.sf.net/p/padthv1/code
    https://github.com/rncbc/padthv1.git
    https://gitlab.com/rncbc/padthv1.git
    https://bitbucket.org/rncbc/padthv1.git

     

    Donate to rncbc.org

    Enjoy.

    by rncbc at April 14, 2019 06:00 PM

    April 03, 2019

    Linux – CDM Create Digital Music

    Alternative modular: pd knobs is a Pure Data-friendly knob controller

    pd knobs is a knob controller for MIDI. It’s built with Teensy with open source code – or you can get the pre-built version, with some pretty, apparently nice-feeling knobs. And here it is with the free software Pd + AUTOMATONISM – proof that you don’t need to buy Eurorack just to go modular.

    And that’s relevant, actually. Laptops can be had for a few hundred bucks; this controller is reasonably inexpensive, or you could DIY it. Add Automatonism, and you have a virtually unlimited modular of your own making. I love that Eurorack is supporting builders, but I don’t think the barrier to entry for music should be a world where a single oscillator costs what a lot of people spend in a month on rent.

    And, anyway, this sounds really cool. Check the demo:

    From the creator, Sonoclast:

    pd knobs is a 13 knob MIDI CC controller. It can control any software that recognizes MIDI CC messages, but it was obviously designed with Pure Data in mind. I created it because I wanted a knobby interface with nice feeling potentiometers that would preserve its state from session-to-session, like a hardware instrument would. MIDI output is over a USB cable.

    For users of the free graphical modular Pd, there are some ready-to-use abstractions for MIDI or even audio-rate control. You can also easily remap the controllers with some simple code.

    More:

    http://sonoclast.com/products/pd-knobs/

    Buy from Reverb.com:

    https://reverb.com/item/21147215-sonoclast-pd-knobs-midi-cc-controller

    The post Alternative modular: pd knobs is a Pure Data-friendly knob controller appeared first on CDM Create Digital Music.

    by Peter Kirn at April 03, 2019 09:02 PM

    March 22, 2019

    KXStudio News

    Changes in KXStudio repos, regarding Carla and JACK2

    This is a small notice to everyone using Carla and JACK2 with the KXStudio repos.

    First, in preparation for Carla 2.0 release, the (really) old carla package is now the new v2.0 series, while carla-git now contains the development/latest version.
    If you are not interested in testing Carla's new stuff and prefer something known to be more stable, install the carla package after the latest updates.

    Second, a change in JACK2 code has made it so a restart of the server is required after the update.
    (but for a good reason, as JACK2 is finally getting meta-data support; this update fixes client UUIDs)
    If you use jackdbus (likely with KXStudio stuff), you will need to actually kill it.
    If that does not work, good old restart is your friend. :)

    One important thing to note is that the lmms package now conflicts with the carla-git one.
    This is because some code has changed in latest Carla that makes v2.0 vs development/latest ABI-incompatible.
    In simpler terms, LMMS can only either be compiled against the stable or development version of Carla.
    The obvious choice is to use the stable version, so after the updates if you notice LMMS is missing, just install it again.
    (If you have carla-git installed, carla will be installed/switched automatically)

    I tried to make the transition of these updates as smooth as possible, but note that you likely need to install updates twice to complete the process.

    In other news, we got a new domain!^-^)/
    Also Carla v2.0 release date has been set - 15th of April.
    Unless a major issue is found, expect a release announcement on that day.
    See you soon then! ;)

    by falkTX at March 22, 2019 12:58 AM

    March 19, 2019

    blog4

    walking as philosophy and artistic practice

    Tina Madsen has another lecture coming up this Wednesday in Aalborg, its about walking as philosophy and artistic practice (in Danish):
    https://bit.ly/2HMlCgG


    by herrsteiner (noreply@blogger.com) at March 19, 2019 01:56 PM

    March 06, 2019

    Linux – CDM Create Digital Music

    How to make a multitrack recording in VCV Rack modular, free

    In the original modular synth era, your only way to capture ideas was to record to tape. But that same approach can be liberating even in the digital age – and it’s a perfect match for the open VCV Rack software modular platform.

    Competing modular environments like Reaktor, Softube Modular, and Cherry Audio Voltage Modular all run well as plug-ins. That functionality is coming soon to a VCV Rack update, too – see my recent write-up on that. In the meanwhile, VCV Rack is already capable of routing audio into a DAW or multitrack recorder – via the existing (though soon-to-be-deprecated) VST Bridge, or via inter-app routing schemes on each OS, including JACK.

    Those are all good solutions, so why would you bother with a module inside the rack?

    Well, for one, there’s workflow. There’s something nice about being able to just keep this record module handy and grab a weird sound or nice groove at will, without having to shift to another tool.

    Two, the big ongoing disadvantage of software modular is that it’s still pretty CPU intensive – sometimes unpredictably so. Running Rack standalone means you don’t have to worry about overhead from the host, or its audio driver settings, or anything like that.

    A free recording solution inside VCV Rack

    What you’ll need to make this work is the free NYSTHI modules for VCV Rack, available via Rack’s plug-in manager. They’re free, though – get ready, there’s a hell of a lot of them.

    Big thanks to chaircrusher for this tip and some other ones that informed this article – do go check his music.

    Type “recorder” into the search box for modules, and you’ll see different options options from NYSTHI – current at least as of this writing.

    2 Channel MasterRecorder is a simple stereo recorder.
    2 Channel MasterReocorder 2 adds various features: monitoring outs, autosave, a compressor, and “stereo massaging.”
    Multitrack Recorder is an multitrack recorder with 4- or 8-channel modes.

    The multitrack is the one I use the most. It allows you to create stems you can then mix in another host, or turn into samples (or, say, load onto a drum machine or the like), making this a great sound design tool and sound starter.

    This is creatively liberating for the same reason it’s actually fun to have a multitrack tape recorder in the same studio as a modular, speaking of vintage gear. You can muck about with knobs, find something magical, and record it – and then not worry about going on to do something else later.

    The AS mixer, routed into NYSTHI’s multitrack recorder.

    Set up your mix. The free included Fundamental modules in Rack will cover the basics, but I would also go download Alfredo Santamaria’s excellent selection , the AS modules, also in the Plugin Manager, and also free. Alfredo has created friendly, easy-to-use 2-, 4-, and 8-channel mixers that pair perfectly with the NYSTHI recorders.

    Add the mixer, route your various parts, set level (maybe with some temporary panning), and route the output of the mixer to the Audio device for monitoring. Then use the ‘O’ row to get a post-fader output with the level.

    (Alternatively, if you need extra features like sends, there’s the mscHack mixer, though it’s more complex and less attractive.)

    Prep that signal. You might also consider a DC Offset and Compressor between your raw sources and the recording. (Thanks to Jim Aikin for that tip.)

    Configure the recorder. Right-click on the recorder for an option to set 24-bit audio if you want more headroom, or to pre-select a destination. Set 4- or 8-track mode with the switch. Set CHOOSE FILE if you want to manually select where to record.

    There are trigger ins and outs, too, so apart from just pressing the START and STOP buttons, you can either trigger a sequencer or clock directly from the recorder, or visa versa.

    Record away! And go to town… when you’re done, you’ll get a stereo WAV file, or a 4- or 8-track WAV file. Yes, that’s one file with all the tracks. So about that…

    Splitting up the multitrack file

    This module produces a single, multichannel WAV file. Some software will know what to do with that. Reaper, for instance, has excellent multichannel support throughout, so you can just drag and drop into it. Adobe’s Audition CS also opens these files, but it can’t quickly export all the stems.

    Software like Ableton Live, meanwhile, will just throw up an error if you try to open the file. (Bad Ableton! No!)

    It’s useful to have individual stems anyway. ffmpeg is an insanely powerful cross-platform tool capable of doing all kinds of things with media. It’s completely free and open source, it runs on every platform, and it’s fast and deep. (It converts! It streams! It records!)

    Installing is easier than it used to be, thanks to a cleaned-up site and pre-built binaries for Mac and Windows (plus of course the usual easy Linux installs):

    https://ffmpeg.org/

    Unfortunately, it’s so deep and powerful, it can also be confusing to figure out how to do something. Case in point – this audio channel manipulation wiki page.

    In this case, you can use the map channel “filter” to make this happen. So for eight channels, I do this:

    ffmpeg -i input.wav -map_channel 0.0.0 0.wav -map_channel 0.0.1 1.wav -map_channel 0.0.2 2.wav -map_channel 0.0.3 3.wav -map_channel 0.0.4 4.wav -map_channel 0.0.5 5.wav -map_channel 0.0.6 6.wav -map_channel 0.0.7 7.wav

    But because this is a command line tool, you could create some powerful automated workflows for your modular outputs now that you know this technique.

    Sound Devices, the folks who make excellent multichannel recorders, also have a free Mac and Windows tool called Wave Agent which handles this task if you want a GUI instead of the command line.

    https://www.sounddevices.com/products/accessories/software/wave-agent

    That’s worth keeping around, too, since it can also mix and monitor your output. (No Linux version, though.)

    Record away!

    Bonus tutorial here – the other thing apart from recording you’ll obviously want with VCV Rack is some hands-on control. Here’s a nice tutorial this week on working with BeatStep Pro from Arturia (also a favorite in the hardware modular world):

    I really like this way of working, in that it lets you focus on the modular environment instead of juggling tools. I actually hope we’ll see a Fundamental module for the task in the future. Rack’s modular ecosystem changes fast, so if you find other useful recorders, let us know.

    https://vcvrack.com/

    Previously:

    Step one: How to start using VCV Rack, the free modular software

    How to make the free VCV Rack modular work with Ableton Link

    The post How to make a multitrack recording in VCV Rack modular, free appeared first on CDM Create Digital Music.

    by Peter Kirn at March 06, 2019 05:00 PM

    February 23, 2019

    The Ardour Youtube Channel is here

    @paul wrote:

    ardour.org is pleased to announce a new youtube channel focused on videos about Ardour.

    We decided to support Tobiasz “unfa” Karon in making some new videos, based on some of the work he has done in other contexts (both online and at meetings). unfa’s first video won’t be particularly useful for new or existing users, but if you’re looking for a “promotional video” that describes what Ardour is and what it can do, this may be the right thing to point people at.

    In the near-term future, unfa will be back with some tutorial videos, so please consider subscribing to the channel.

    Thanks to unfa for this opening video, and we look forward to more. If people have particular areas that they’d like to see covered, mention it in the comments here (or on the YT channel).

    Posts: 21

    Participants: 10

    Read full topic

    by @paul Paul Davis at February 23, 2019 06:53 PM

    February 17, 2019

    blog4

    EU about to destroy Internet

    EU are about to change the copyright in regards of internet, I wonder if that is just killing it for consumers or also academia and research on a bigger scale.

    https://www.eff.org/deeplinks/2019/02/final-version-eus-copyright-directive-worst-one-yet.

    by herrsteiner (noreply@blogger.com) at February 17, 2019 08:48 PM

    February 09, 2019

    Talk Unafraid

    How to fail at astrophotography

    This is part 1 of what I hope will become a series of posts. I’m going to focus in this post on my getting started and some mistakes I made on the way.

    So, back in 2017 I got a telescope. I fancied trying to do some astrophotography – I saw people getting great results without a lot of kit, and realised I could dip my toe in too. I live between a few towns, so get “class 4” skies – meaning that I could happily image a great many targets from home. I’ve spent plenty of time out at night just looking up, especially on a moonless night; the milky way is a clear band, and plenty of eyeball-visible targets look splendid.

    So I did some research, and concluded that:

    • Astrophotography has the potential to be done cheaply but some bits do demand some investment
    • Wide-field is cheapest to do, since a telescope isn’t needed; planetary is way cheaper than deep-sky (depending on the planet) to kit out for, but to get really good planetary images is hard
    • Good telescopes are seriously expensive, but pretty good telescopes are accessibly cheap, and produce pretty good results
    • Newtonians (Dobsonians, for visual) give the absolute best aperture-to-cash return
    • Having a good mount that can track accurately is absolutely key
    • You can spend a hell of a lot of cash on this hobby if you’re not careful, and spending too little is the fastest path there…

    So, having done my research, the then-quite-new Skywatcher EQ6-R Pro was the obvious winner for the mount. At about £1,800 it isn’t cheap, but it’s very affordable compared to some other amateur-targeted mounts (the Paramount ME will set you back £13,000, for instance) and provides comparable performance for a reasonable amount of payload – about 15kg without breaking a sweat. Mounts are all about mechanical precision and accuracy; drive electronics factor into it, of course, but much of the error in a mount comes from the gears. More expensive mounts use encoders and clever drive mechanisms to mitigate this, but the EQ6-R Pro settles for having a fairly high quality belt drive system and leaves it at that.

    Already, as I write this, the more scientific reader will be asking “hang on, how are you measuring that, or comparing like-for-like?”. This is a common problem in the amateur astrophotography scene with various bits of equipment. Measurement of precision mechanics and optics often requires expensive equipment in and of itself. Take a telescope’s mirror – to measure the flatness of the surface and accuracy of the curvature requires an interferometer. Even the cheap ones cooked up by the make-your-own-telescope communities take a lot of expensive parts and require a lot of optics know-how. Measuring a mount’s movement accurately requires really accurate encoders or other ways to measure movement very precisely – again, expensive bits, etc. The net result of this is that it’s very rare that individual amateurs do quantitative evaluation of equipment – usually, you have to compare spec sheets and call it a day. The rest of the analysis comes down to forums and hearsay.

    As an engineer tinkering with fibre optics on a regular basis, spec sheets are great when everyone agrees on the test methodology for the number. There’s a defined standard for how you measure insertion loss of a bare fibre, another for the mode field diameter, and so on. A whole host of different measurements in astrophotography products are done in a very ad-hoc fashion, vary between products and vendors, and so on. Sometimes the best analysis and comparison is being done by enthusiasts that get kit sent to them by vendors to compare! And so, most purchasing decisions involve an awful lot of lurking on forums.

    The other problem is knowing what to look for in your comparison. Sites that sell telescopes and other bits are very good at glossing over the full complexity of an imaging system, and assume you sort of know what you’re doing. Does pixel size matter? How about quantum efficiency? Resolution? The answer is always “maybe, depends what you’re doing…”.

    Jupiter; the great red spot is just about visible. If you really squint you can see a few pixels that are, I swear, moons.

    This photo is one of the first I took. I had bought, with the mount, a Skywatcher 200PDS Newtonian reflector – a 200mm or 8″ aperture telescope with a dual-speed focuser and a focal length of 1000mm. The scope has an f-ratio of 5, making it a fairly “fast” scope. Fast generally translates to forgiving – lots of light means your camera can be worse. Visual use with the scope was great, and I enjoyed slewing around and looking at various objects. My copy of Turn Left at Orion got a fair bit of use. I was feeling pretty great about this whole astrophotography lark, although my images were low-res and fuzzy; I’d bought the cheapest camera I could, near enough, a ZWO ASI120MC one-shot-colour camera.

    Working out what questions to ask

    The first realisation that I hadn’t quite “gotten” what I needed to be thinking about came when I tried to take a photo of our nearest galaxy and was reminded that my field of view was, in fact, quite narrow. All I could get was a blurry view of the core. Long focal length, small pixel sizes, and other factors conspired to give me a tiny sliver of the sky on my computer screen.

    M31 Andromeda; repaired a bit in PixInsight from my original, still kinda terrible

    Not quite the classic galaxy snapshot I’d expected. And then I went and actually worked out how big Andromeda is – and it’s huge in the sky. Bigger than the moon, by quite a bit. Knowing how narrow a view of the moon I got with my scope, I considered other targets and my equipment. Clearly my camera’s tiny sensor wasn’t helping, but fixing that would be expensive. Many other targets were much dimmer, requiring long exposures – very long, given my sensor’s poor efficiency, longer than I thought I would get away with. I tried a few others, usually failing, but sometimes getting a glimmer of what could be if I could crack this…

    Raw stack from an evening of longer-exposure imaging of NGC891; the noise is the sensor error. I hadn’t quite cracked image processing at this point.

    It was fairly clear the camera would need an upgrade for deep space object imaging, and that particular avenue of astrophotography most appealed to me. It was also clear I had no idea what I was doing. I started reading more and more – diving into forums like Stargazer’s Lounge (in the UK) and Cloudy Nights (a broader view) and digesting threads on telescope construction, imaging sensor analysis, and processing.

    My next break came from a family friend; when my father was visiting to catch up, the topic of cameras came up. My dad swears by big chunky Nikon DSLRs, and his Nikon D1x is still in active use, despite knackered batteries. This friend happened to have an old D1x, and spare batteries, no longer in use, and kindly donated the lot. With a cheap AC power adapter and F-mount adapter, I suddenly had a high resolution camera I could attach to the scope, albeit with a nearly 20-year-old sensor.

    M31/M110 Andromeda, wider field shot, Nikon D1x – first light, processed with DeepSkyStacker and StarTools

    Suddenly, with a bigger sensor and field of view, more pixels (nearly six megapixels) I felt I could see what I was doing – and suddenly saw a whole host of problems. The D1x was by no means perfect; it demanded long exposures at high gains to get anything, and fixed pattern noise made processing immensely challenging.

    M33 Triangulum, D1x, processed with DeepSkyStacker and PixInsight

    I’d previously used a host of free software to “stack” the dozens or hundreds of images I took into a single frame, and then process it. Back in 2018 I bought a copy of StarTools, which allowed me to produce some far better images but left me wanting more control over the process. And so I bit the bullet and spent £200 on PixInsight, widely regarded as being the absolute best image processing tool for astronomical imagery; aside from various Windows-specific stability issues (Linux is rock solid, happily) it’s lived up to the hype. And the hype of its learning curve/cliff – it’s one of the few software packages for which I have purchased a reference book!

    Stepping on up to mono

    And of course, I could never fully calibrate out the D1x’s pattern noise, nor magically improve the sensor quality. At this point I had a tantalisingly close-to-satisfying system – everything was working great. My Christmas present from family was a guidescope, where I reused the ASI120MC camera, and really long exposures were starting to be feasible. And so I took a bit of money I’d saved up, and bit the hefty bullet of buying a proper astrophotography camera for deep space observation.

    By this point I had a bit of clue, and had an idea of how to figure out what it was I needed and what I might do in the future, so this was the first purchase I made that involved a few spreadsheets and some data-based decisions. But I’m not one for half-arsing solutions, which became problematic shortly thereafter.

    The scope and guidescope, preparing for an evening of imaging on a rare weekend clear night
    M33 Triangulum; first light with the ASI183MM-PRO. A weird light leak artefact can be seen clearly in the middle of the image, near the top of the frame

    Of course, this camera introduces more complexity. Normal cameras have a Bayer matrix, meaning that pixels are assigned a colour and interpolation fills in the colour for adjacent pixels. For astrophotography, you don’t always want to image red, green or blue – you might want a narrowband view of the world, for instance, and you for various reasons want to avoid interpolation in processing and capture. So we introduce a monochrome sensor, add a filter wheel in front (electronic, for software control), and filters. The costs add up.

    The current finished imaging train – Baader MPCC coma corrector, Baader VariLock T2 spacer, ZWO mini filter wheel, ASI183MM-PRO

    But suddenly my images are clear enough to show the problems in the telescope. There’s optical coma in my system, not a surprise; a coma corrector is added to flatten the light reaching the filters and sensor.

    I realise – by spending an evening failing to achieve focus – that backfocus is a thing, and that my coma corrector is too close to my sensor; a variable spacer gets added, and carefully measured out with some calipers.

    I realise that my telescope tube is letting light in at the back – something I’d not seen before, either through luck or noise – so I get a cover laser cut to fix that.

    It turns out focusing is really quite difficult to achieve accurately with my new setup and may need adjusting between filters, so I buy a cheap DC focus motor – the focuser comes to bits, I spend an evening improving the tolerances on all the contact surfaces, amending the bracket supplied with the motor, and put it back together.

    To mitigate light bouncing around the focuser I dismantled the whole telescope tube and flock the interior of the scope with anti-reflective material, and add a dew shield. Amongst all this, new DC power cables and connectors were made up, an increasing pile of USB cables/hubs to and from the scope added, a new (commercial) software package added to control it all, and various other little expenses along the way – bottles of high-purity distilled water to clean mirrors, and so on.

    Once you’ve got some better software in place for automating capture sessions, being able to automatically drive everything becomes more and more attractive. I had fortunately bought most of the bits to do this in dribs and drabs in the last year, so this was mostly a matter of setup and configuration.

    It’s a slippery slope, all this. I think I’ve stopped on this iteration – the next step is a different telescope – but I’ve learned a hell of a lot in doing it. My budget expanded a fair bit from the initial purchase, but was manageable, and I have a working system that produces consistently useful results when clouds permit. I’ve got a lot to learn, still, about the best way to use it and what I can do with it; I also have a lot of learning to do when it comes to PixInsight and my image processing (thankfully not something I need clear skies for).

    … okay, maybe I’d still like to get a proper flat field generator, but the “t-shirt at dusk” method works pretty well and only cost £10 for a white t-shirt

    Settling in to new digs

    Now, of course, I have a set of parts that has brought my output quality significantly up. The images I’m capturing are good enough that I’m happy sharing them widely, and even feel proud of some. I’ve even gotten some quality-of-life improvements out all this work – my evenings are mostly spent indoors, working the scope by remote control.

    Astrophotography is a wonderful collision of precision engineering, optics, astronomy, and art. And I think that’s why getting “into” it and building a system is so hard – because there’s no right answer. I started writing this post as a “all the things I wish someone had told me to do” post, but really when I’m making decisions about things like the ideal pixel size of my camera I’m taking an artistic decision that is underpinned by science and engineering and maths – it has an impact on what pictures I can take, what they’ll look like, and so on.

    M33 Triangulum, showing clearly now the various small nebulas and colourful objects around the main galaxy. The first image I was genuinely gleeful to produce and share as widely as I could.
    The Heart Nebula, not quite centred up; the detail in the nebulosity, even with this wideband image, is helped tremendously by the pixel oversampling I achieve with my setup (0.5 arcseconds per pixel)

    But there’s still value in knowing what to think about when you’re thinking about doing this stuff. This isn’t a right answer; it’s one answer. At some point I will undoubtedly go get a different telescope – not because it’s a better solution, but because it’s a different way to look at things and capture them.

    So I will continue to blog about this – not least because sharing my thoughts on it is something I enjoy and it isn’t fair to continuously inflict it on my partner, patient as she is with my obsession – in the hopes that some other beginners might find it a useful journey to follow along.

    by James Harrison at February 09, 2019 10:03 PM

    January 10, 2019

    Bug tracker updated

    @paul wrote:

    tracker.ardour.org has been upgraded from an ancient version of Mantis to the most current stable release. The website looks very different now, but all existing bug reports and user accounts are still there. We hope to find some way to limit the bug-report spam that has recently turned into a small but annoying time waster, and ultimately to enable single-sign on with the rest of ardour.org.

    Posts: 5

    Participants: 4

    Read full topic

    by @paul Paul Davis at January 10, 2019 06:13 PM

    January 07, 2019

    linux-audio « WordPress.com Tag Feed

    Video: Aircraft battle Rosedale blaze from sky at night

    The fire at Rosedale, which has burned more than 11,500ha across an 85km perimeter, started at an is

    January 07, 2019 02:10 AM

    December 23, 2018

    Libre Music Production - Articles, Tutorials and News

    Libre Music Production is taking a break

    As the LMP crew right now only consists of one person (me) and we haven't published any new content for a year, I have decided to let LMP take a break.

    This break might be forever. I will keep the content through 2019, at least.

    If anyone would like to take over the site, please contact me: staffan.melin@oscillator.se.

    Thank you for visiting LMP!

    by admin at December 23, 2018 11:17 PM