Planet LinuxMusicians
Friday, 27 January
I discovered the free and open source tool LMMS a few days ago via some post in the http://LinuxMusicians.com forum.The software seemed so easy to use and so inviting to experiment with that I just had to try it out.
Love it or hate it... here's my first lmms project:
In case you'd want to reuse the choral parts I wrote for this piece (one never knows :) ) you can download the entire .mmpz file here: http://www.mediafire.com/?4dfov022014coe6 (creative commons attribution share-alike v3.0 license)
The music was completely made with lmms in debian linux. It probably sounds best with decent headphones or a decent speaker set with subwoofer.
The video was made with kdenlive on debian linux.
Have fun!
(Oh and did I mention already that comments and constructive criticisms are welcome? :D )
Thursday, 26 January
One of the features of Fedora 17 is the /usr merge, put forward by Harald Hoyer and Kay Sievers[1]. In the time since this feature has been proposed repetitive discussions took place all over the various Free Software communities, and usually the same questions were asked: what the reasons behind this feature were, and whether it makes sense to adopt the same scheme for distribution XYZ, too.
Especially in the Non-Fedora world it appears to be socially unacceptable to actually have a look at the Fedora feature page (where many of the questions are already brought up and answered) which is very unfortunate. To improve the situation I spent some time today to summarize the reasons for the /usr merge independently. I'd hence like to direct you to this new page I put up which tries to summarize the reasons for this, with an emphasis on the compatibility point of view:
Note that even though this page is in the systemd wiki, what it covers is mostly orthogonal to systemd. systemd supports both systems with a merged /usr and with a split /usr, and the /usr merge should be interesting for non-systemd distributions as well.
Primarily I put this together to have a nice place to point all those folks who continue to write me annoyed emails, even though I am actually not even working on all of this...
Enjoy the read!
Footnotes:
[1] And not actually by me, I am just a supportive spectator and am not doing any work on it. Unfortunately some tech press folks created the false impression I was behind this. But credit where credit is due, this is all Harald's and Kay's work.
Streaming Museum, an international public art and online museum, will celebrate its fourth anniversary on January 31 with the US premiere of ”Emotion Forecast” and ”Occupy Wall Screens”, real-time artworks by the renowned French artist Maurice Benayoun. The exhibition will be on view for one month at Big Screen Plaza in New York City and through 2012 at StreamingMuseum.org.
The artworks have been developed by Robin Gareus, at the CiTu-Paragraphe Lab of the University Paris 8, in the frame of The Art Collider project as a part of the PUF program of the FACE Foundation in collaboration with the SFAI (San Francisco Art Institute).
Streaming Museum is the first global public space and online hybrid museum with collaborating locations and cultural centers on 7 continents. The 30 x 16.5 ft. HD format screen of Big Screen Plaza is located at 29th Street and 6th Avenue, adjacent to the Eventi Hotel.
More information: http://www.streamingmuseum.org/featured/maurice-benayoun/
linuxDSP PEQ-2A V1.01 is now available. This update adds 32 and 64Bit linuxVST versions, and Physical Control Weighting, which adds a small amount of 'weight' to the GUI controls in order to replicate the 'feel' of high quality rotary controls. In addition, this enables greater precision for small control moves while still enabling wide ranging control changes when required. This is a free update for anyone who has already purchased the original version.
See http://linuxdsp.co.uk/ for more details and downloads.
Continuing our insight into this view into electronic music performance and art through the lens of BodyControlled in Berlin, we’re joined by guest writer Kristin Trethewey. Kristin, a Canadian-born video artist and curator, takes another look at LEAP and BodyControlled, on the eve of its second installment. She gets straight at the question of what “BodyControlled” means, and what it can mean for sonic performance and creation. And I wanted to make sure to subtract myself from this write-up, seeing as I was playing – but see the excellent timelapse of the evening, above. -Ed.
LEAP is one of these spectacular Berlin venues you’ve been hearing so much about. It’s a huge, raw space with a view of Berlin’s landmark TV tower, hosting interesting art events with cheap drinks and the potential for a late-night party. But it’s unique, too, in its focus on electronic arts. And unlike other media arts centers, it’s not filled with computers and half-finished electronic projects. I’ve truly gotten lost trying to find this place (it’s tucked away in a mall), so I would recommend watching the timelapse video LEAP shot that guides you to the entrance before attempting to go there. Tonight is the second edition of BodyControlled, a new bimonthly performance series at the space. This installment, called “matter incompatible,” is held in conjunction with the Transmediale Festival under the satellite program, Vorspiel.
BodyControlled is a series focused on the intersection of performance and electronics. You can expect future programming to focus around ideas of “feedback” and “bio” related electronic performances. In its first installment back in November, a packed LEAP gallery witnessed performances by Robert Henke, Peter Kirn [editor of this site], Stephen Cornford, and Paul Whitty. The event was called “Other Spaces” and took the physical architecture of the gallery as a point of departure. Having the space filled with people made for a secondary concern of space: its use. In a series whose title mentions the body, I witnessed one performance engaging the bodies that were filling the space. Robert Henke’s twelve-hour set activated interactions between the audience, performer, and environment. He moved around, listened and mingled with the audience, even though he had this amazing, souped-up control station complete with ambient lighting.
Other artists put more emphasis on the manipulation and dislocation of space through the use and abuse of electronics. Kirn worked with a custom rig with tablet-controlled original software built in open-source software Pure Data (Pd), controlled by a tablet running Konkreet Performer. Excerpt:
Excerpt – LEAP Gallery Berlin, 26.11 by peterkirn
Whitty and Cornford actively deconstructed electronics in front of the audience:
it pays my way and it corrodes my soul (2011)
Stephen Cornford & Paul Whitty’s performance “it pays my way and it corrodes my soul” seeks out musical material by physically dismembering playback equipment. A reel-to-reel tape recorder is switched on and its mechanism amplified with a variety of microphones while it is taken to pieces. The sounds produced are then fed through an array of pedals: the machine’s belts, gears, switches and casing becoming an instrument subjected to a live audio autopsy
Excerpt:
Excerpt: Stephen Cornford & Paul Whitty, LEAP Berlin, 26 November by cdm
Cornford was also interviewed by LEAP for his installation work, featuring repurposed tape machines:
As João Pais, co-curator of the event with LEAP’s Daniel Franke, puts it:
“BodyControlled means the main direction of the series, to present performance and installation works that have a strong, corporal identity. This can be manifested in many ways, not only implying a “moving performer”. The purpose is to avoid the extreme of abstract performances made by a laptop-er, sitting down as if writing emails. In the first event, this idea was shown by interpreting/filling the space of LEAP through a sound-performance (Kirn, Henke), or an installation (Cornford, Mathy, Oliver).”
See also my write-up for ARTSCARDS from last month:
Other Spaces Generates New Spaces Through Sound at LEAP
The second event, “matter incompatible,” draws reference to the Transmediale theme: In/compatible, acknowledging the less clear, even dark forces at play in the artistic and political climate today. Matter Controlled questions the idea of the object or anti-object within sonification. See CDM’s write-up from yesterday:
Watch Artists Talk About Making Sound From Matter; Thursday Event and Stream in Transmediale Prelude
From the Transmediale podcast, some explanations of the theme of the larger festival:
Jacob Lillemose on the exhibition Dark Drives: Uneasy Energies in Technological Times by transmediale
Kristoffer Gansing elaborates on the festival theme in/compatible, as well as the in/compatible symposium: systems | publics | aesthetics.
Tatiana Bazzichelli is the curator for out new project reSource of transmedial culture and speaks about its concept.
Jacob Lillemose speaks about exhibition Dark Drives: Uneasy Energies in Technological Times which he is curating for transmediale 2012 in/compatible.
Sandra Naumann is the curator for this year’s performance programme The Ghosts in the Maschine, which she explains a bit more in detail.
And Marcel Schwierin tells us about his concept for the video programme he is curating for transmediale 2012 in/compatible.
Performances by Echo Ho, Mario De Vega, Alex Nowitz and Ignaz Schick will investigate this blurry region between the immaterial and material. I am curious to see what objects they will bring to play with. As they potentially seek liberation from the physical objects, by reimagining their sonification, I wonder how they are also reliant and maybe even drawn towards their objectification. Bringing these disparate emotions into play is at the heart of tonights investigation. In today’s climate fractures exist between so many aspects of our lives. These performances seek to bring some of them together, compatible or incompatible as we might discover.
You can watch the proceedings via live Internet stream, for the majority of you not in Berlin for the live show.
More Photos
About the Author
Kristin Trethewey is a Canadian video artist, cinema performer, and curator. She holds an MFA from Brooklyn College in Performance and Interactive Media. A multi-disciplinary curator and artist for the past ten years, she has recently completed a residency at the Node Center for Curatorial Arts, was co-Director/co-Curator of the INDEX Festival. She currently lives in Berlin.
Wednesday, 25 January
[Samimy's] latest project is a little strange, but one man’s weird is another man’s wonderful so we’re not about to start criticizing his work. Nope, we’re here to praise the fact that his rotary phone turned reading light and audio amp is very well constructed.
He started by removing the phone housing. Those old enough to have used one of these devices will remember their bulk, and there’s a lot of unused space in both the handset and body housing. [Samimy] started by removing the speaker and microphone from the handset, and drilling a ring of holes to receive white LEDs. The circuit was wired so that lifting the handset turns on the lights.
But he didn’t stop there. A set of speakers and the audio amplifier circuitry from an old tape deck are also hiding inside the base of the phone. If you look closely in the image above you can see that he’s connected his cellphone and is listening to some tunes through the antique hardware. Take a gander at the video after the break to see construction and use of the project.
Filed under: digital audio hacks, led hacks
20120124 by ioflow
solo piano improvisation. one take. experimenting with different flavors.
recorded with jack timemachine, trimmed with renoise and audacity.
if only i had some arabic fiddle, spanish guitar, and ethnic percussion mojo. could seriously rock the house with some plaintive haunting sounds from the old world.
Hi All,
We are happy to announce the Winter 2012 Issue of "Csound Journal" is now available. You can read online or download at:
http://www.csounds.com/journal/
Many thanks to the authors for submitting their wonderful articles! We hope you enjoy reading this issue as much as we did!
Jim Hearon and Steven Yi
Monday, 23 January
This was actually inspired by episode 222 of the Podcast Answer Man, when he mentioned an issue with the use of an incorrectly-set compressor-gate. I was pretty impressed when he demonstrated what his environment sounded like when bypassing the compressor gate.
Those of you using normal speakers won't notice much; maybe the second will be a little quieter. Those wearing earbuds or headphones may notice some difference... if you have studio headphones, you will likely notice everything immediately... for those who don't know, studio headphones are equalized to show every ugly truth in a playback... if there's noise, you hear it in all its glory.
I am still doing the research on what some of this means. From what I've been able to determine so far, "RMS Envelope Tracking" simply means that the device adjusts for the average signal level, thereby ensuring that the chances for a cut-in or cut-off will be lessened. When dealing with a varied signal, like the human voice, this can definitely be a boon.
Aside from that, I'm not sure what the "threshold" is referring to in these plugins, so I've left them at their default values. The ratio is very likely the decimal value of the ratio; 2:1 is .5, 4:1 is .25, and so on. The attack, decay, hold, and release values are what you would expect them to be... values in milliseconds.
For the RMS-tracking plugins, I mainly stuck to the default values. I might mention, however, that the order I present the plugins here is presented this way for a reason. By expanding and then compressing, you're making sure that none of the noise is added to the compression. By following with a gate, you're cleaning up the minor noise left over from the expansion. The amplifier is just to make sure that the followup signal is loud and clear. And the limiter is last, because if the amplifier boosts a peak up above zero, we want to limit it to prevent peaking distortion.
For the gate, I set the low frequency for 400, because the noise handling in my apartment isn't very good under that level, and using equalization means that I won't get the nice rich voice in the recording. If I were to use the default value, then this would have prematurely tripped the gate, causing the background noise to come through. I set the attack, hold, and decay to very low values; The expander is already keeping the volume down, this is just an extra level to eliminate the minor static that passes through the expander.
One of the main reasons people prefer to use Audacity is because it has this "magical" noise removal filter as one of its editing tools. With the help of this chain, you can hopefully see the possibilities of using good noise removal procedure in a real-time context, without any need for editing the final product for cleanup. Then, you can be sure that the only noise left is the noise you create!
For those of you who understand the process a little better than I do, feel free to comment if you have any corrections; anything I can do to improve the audio chain presenter here, I will appreciate (provided we keep the suggestions Linux-based).
Saturday, 21 January
Rich an Mike
Holstein talked about the dynebolic live distro, and Ubuntu Studio
12.04.
We also talked about the new Tunestorm, which is any kind of song you
like, WITH lyrics, and the lyrics have to be in Haiku form.
5 Syllables
7 Syllables
5 Syllables
We also talked about my mastering, and what I do, and then I plugged
the Linuxdsp plugs a bit. Someone got me their guitar pedal plugs for
Xmas. Talked about their new EQ which emulates the Vintage Pultecs.
Friday, 20 January
Last October we published a wishlist for plumbing related features we'd like to see added to the Linux kernel. Three months later it's time to publish a short update, and explain what has been implemented in the kernel, what people have started working on, and what's still missing.
The full, updated list is available on Google Docs.
In general, I must say that the list turned out to be a great success. It shows how awesome the Open Source community is: Just ask nicely and there's a good chance they'll fulfill your wishes! Thank you very much, Linux community!
We'd like to thank everybody who worked on any of the features on that list: Lucas De Marchi, Andi Kleen, Dan Ballard, Li Zefan, Kirill A. Shutemov, Davidlohr Bueso, Cong Wang, Lennart Poettering, Kay Sievers.
Of the items on the list 5 have been fully implemented and are already part of a released kernel, or already merged for inclusion for the next kernels being released.
For 4 further items patches have been posted, and I am hoping they'll get merged eventually. Davidlohr, Wang, Zefan, Kirill, it would be great if you'd continue working on your patches, as we think they are following the right approach[1] even if there was some opposition to them on LKML. So, please keep pushing to solve the outstanding issues and thanks for your work so far!
Footnotes
[1] Yes, I still believe that tmpfs quota should be implemented via resource limits, as everything else wouldn't work, as we don't want to implement complex and fragile userspace infrastructure to racily upload complex quota data for all current and future UIDs ever used on the system into each tmpfs mount point at mount time.
So far, I've done a lot of talking about specific programs individually. This is important, because you need to know how to use the tools before you can use them effectively. However, at this point, we can start making full-scale workflows for larger projects... after all, nobody uses just one tool, and for complex tasks, you need to have multiple tools on hand to do the work.
For this project, I will show the workflow using the flowcanvas views of Gladish and Claudia. I have a 2-channel audio interface with an XLR microphone hooked up to one, and a port with a TRS jack (the audio interface dedicates this to an electric guitar, but it should be usable with a dynamic mic if need be).
I have heard on podcast podcasts how these podcasters use two computers and a hardware mixer to allow the recording of Skype calls in their podcast. In this example, I will show the workflow for a podcast that uses Skype through the Alsa-Jack Bridge, the Ardour DAW for multitrack recording, Hydrogen as a SFX trigger, Mixxx for playing the intros and stingers, and the Internet DJ Console is used to do the streaming, while two instances of Jamin will be used to master the stream and the mixed master recording.
The end result of this setup is that anyone with Linux can use this layout to create a podcast that includes skype calls, all in one system, with no hardware beyond an audio interface for their microphone. This includes the ability to stream the podcast to live listeners using shoutcast or icecast, and keeps all audio sources on separate DAW tracks, in case postprocessing is needed for any reason.
Most of these steps can be performed using the Claudia application, but one step would need the "Raw Jack" display that Gladish has available. If you're using Claudia, in order to make including the applications easier, then you will want to also have Patchage or the QT Jack Control handy for that one step. Just a fair warning.
If the system has PulseAudio as part of it, you won't be able to use Skype with the Jack-Alsa bridge; it will detect the presence of PulseAudio and will only use that system for audio output. So if you have PulseAudio, it helps to remove it so that Skype will work with this tutorial. If you don't plan to use Skype, or if you plan to perform a double-ender, then you can leave Pulse where it is.
Due to different designs, some of the programs we will be using here will need to be manually set up; unfortunately, not all programs will use the designated folder by default, and until version 1 of Ladish is available from the repositories, the LASH and Jack Session protocols will not be available.
One more thing: Remember, this is a setup. You will only need to perform this list of steps once... once the session has been created, all applications have been added, and all connections have been made, all you need to do to return to this workflow is just load the project and move forward.
Now, Jamin, IDJC, and Ardour will attempt to make their own connections, so we want to make sure that Jack ignores all self-connection attempts in order to shut down this behavior. So, in Gladish or Claudia, you'll need to go to "Tools" and "Configure Jack." For gladish, then you click on "Jack Engine Parameters." Once you see the Self-Connect Mode, select "Ignore Self-Connect Requests."
Once Jack is ready, we will want to create a studio, if we don't already have one. If you already have one, then you can skip to the next step.
The creation of a studio is identical between Gladish and Claudia. Select "Studio" and then "New Studio." The studio name box will appear. Simply enter the desired name of your studio and accept it.
Now, you don't need to put too much thought into the studio name; the bulk of the work will be encapsulated into the room we'll create in the studio. The only reason to even make more than one studio is because you may want to have multiple rooms consisting of multiple projects as part of a larger overreaching project. Unless you plan to be using replaceable synths or encapsulated, savable filtration consisting of multiple filters with complex wiring (one of which I will show you in a future article), you won't need more than one single room.
The name of the room doesn't require much more thought, really. It is simply, like the studio, simply a generic container. This is even more the case as the room will be the only one in this studio, so I just like to call it "Room." Not very creative, am I?
However, the type of room is a bit more important. You need to have as many inputs as you have microphone channels. If you only have one or two mics, then "Basic" will do. If you have up to 4, then the "4x4x2x2". Up to 10... well, you get the pattern. For clarification, the pattern is "audio input ports"x"audio output ports"x"midi input ports"x"midi output ports". Basic will name the two channels left and right, but if you're using two mono mics, you can just name one "left" and one "right," and you'll do okay.
Since the IDJC can support up to 4 microphones, I've selected the 4x4x2x2 option, so we can provide a full demonstration. Then, I connect my audio interface to the available capture interfaces. For the output, I treated playbacks 1 and 2 as one stereo output, and 3 and 4 for the second stereo output... and just mixed them together into my stereo interface.
This is where the name becomes important. The project is what actually saves the applications to launch and the connections to make. In addition, once Ladish 1 is available for the repositories, it will be the project that sends the signal to the different apps to save their status, thereby allowing the DAW to save its session, as well as the Jamin apps to save their adjustment settings.
There are two pieces of information we'll need here. The first is the location that you'll want to save the combined configuration and audio files generated by the various tools; they are all saved together, so that you can zip the package up and move it to a different system without needing to re-setup the applications (aside from ensuring that they're installed on the target system). So you are simply selecting a folder, not a file.
The other part is the name of the project. This will appear in parentheses following the room name in the studio manifest. It will also show up in the list of names when selecting the project again later. I simply chose the name "Skype Streaming Podcast," because I'm a boring putz who can't be original to save his life. You can choose to use the name of your podcast if you want.
Now, the IDJC contains its own recording feature, and that can be good enough for our needs. However, if you intend to do any post-production work, this will limit your options, since all the audio will be merged into one single file; there is no unmixing multiple audio sources once they're mixed. So, we want to have a multitrack recorder as part of this chain, and I have always been a big fan of the Ardour DAW, so that is what we will be setting up here.
So, right-click on the room and select either "Add New" (For Claudia, which will launch the Klaudia menu) or "Add Application," which opens the following window. For the command, you use "ardour2" followed by what you want to name the project in Ardour 2 (I just chose "Podcast," to continue a rather boring trend). For the level, we'll use 0 until Level 2 (Jack Session) is available; 1 will crash Ardour if you try to save the session.
Now, if you chose the latter (Klaudia autogenerates a session name for Ardour so you don't need to), you will be presented with a session window. It will already be in "New Session," and the session name you decided on will be displayed. Go ahead and just click "New." You will now see Ardour appear with just the master bus available.
Creating the Track Buses
Now, we want to create one track for each input we intend to have, plus a track for a final recording.
The first four tracks will be mono tracks, set to "Normal." We do not want "Tape," simply because this will cause an existing track to be overwritten if the playhead is in the wrong place. Doubleplusungood. Finally, we want to select "Track," because the bus is essentially a track without recording capability.
Wha...? Why would we have a track without recording ability?!
Well, it helps to think of Ardour, not as a multitrack recorder with additional features, but as a digital mixer with the ability to record and apply plugins and inserts on each bus... and can have more buses than one would have on a $3000 hardware mixer... never mind that each bus can have a different number of channels... or that each bus can have a different number of input ports as output ports... and so on. However, if we have something else we want to record with, we can save memory by simply using buses in Ardour to mix and mold the audio.
And don't worry, we'll be covering each feature I just described as part of this project, since they will all be used. However, at this point, we want to finish making the microphone tracks, so here:
Then, click "Add." Now, you'll have four new tracks in Ardour. Go ahead and name them accordingly.
Now, we will repeat the process, but instead of mono, we want these to be stereo. I will call them "Skype," "Music," "Sound Effects," and "Final Mix."
So, now we have Ardour with 8 tracks, four of which are mono (the four microphones), and four stereo, as well as the stereo master bus. Now you have enough tracks to keep everyone and everything in your podcast recording separate, and so can be cleaned up, better mixed, and mastered during postprocessing... say in case you want to offer a higher-quality podcast feed than the streamcast can handle... or perhaps as an enticement for membership? I'll leave the reason to you.
We'll handle the connections later, since the DAW actually connects to every single other application in our session, except for one of the Jamin apps, which will be solely used by IDJC to master the streaming feed.
Now, go ahead and save the project. And, since Ardour does not save with the project, go into its Session menu and save the Ardour session as well.
Skype does not support Jack natively. This is why I latched hardcore on the idea of the Jack-Alsa bridge; it allows a persistent, independent connection to Jack, meaning that it is created, it stays there, and only Skype will be heard through it.
I have Skype set up on Alsa-Jack Bridge 1. So, the following commands will be used to connect it to this session. If you used the Jack-Alsa Bridge Kit, especially while setting up using the Ubuntu Setup article, then you can actually use these lined verbatim by copy and paste.
To Skype: alsa_out -j "To Skype" -dalsa_output_1 -q 1
From Skype: alsa_in -j "From Skype" -dalsa_input_1 -q 1
Now, keep in mind that since the bridges are a hack, Klaudia will not have entries for them, so in Claudia, you will need to use "Run Custom" to add the above bridge commands to the project. Also keep in mind that they are just links, so level 0 is all that they will ever need; this will allow them to be started and stopped.
Now, take a moment and save the project, so it will know to launch the bridges next time.
Depending on how you have your system set up, this step may not be necessary. Obviously, if you plan to take calls, having Skype itself loaded is important; the setups in the previous section created the Jack-Alsa bridges to allow Skype to make the connection, but does not actually launch Skype. If you want to launch it as part of this session, the following command should do it for you:
Skype: skype
That being said, I generally have it started from system login; it is just as useful as an IM client as a voice communication program.
Once Skype is started, however you choose to do so, you need to make sure that Skype is connected to the Jack-Alsa bridge. This will happen in the "Sound Devices" tab of the Skype options dialog:
For this workflow, make sure the microphone is set to jack_capture_1, and the speakers set to jack_playback_1, thereby linking Skype to the first Jack-Alsa bridge.
NOTE: PulseAudio MUST NOT be running when starting Skype; if PulseAudio is active, Skype will refuse to use anything else to connect, rendering the Alsa-Jack bridge useless!
Once upon a time, I wrote an article about setting up the Hydrogen drum machine in order to act as a sound effects trigger. It would not be necessary in a normal podcast, as the SFX can be added in post-production. However, in a live show, as a a streamcast would be, you want to have the SFX ready at the press of a button, so we finally, a few months later, actually have a use for that article. Additionally, this can also be used for stingers between segments. This will allow Mixxx (set up below) to limit itself to the intro and end sequences.
First, let's add Hydrogen to the project. Claudia users can skip the manual step this time.
Hydrogen SFX Machine: hydrogen -d jack -s 'PodcastSFX.h2song'
The "-d jack" means that we won't need to go into Hydrogen's settings and tell it to use Jack; it will use it automatically. The "-s 'PodcastSFX.h2song'" means that the Hydrogen session will be saved, so you will be in the same "drumkit" (SFX) when this session starts again. That way, you won't have to reselect the SFX set the next time you use this.
Hydrogen is level 1 capable, as this will allow Hydrogen to receive the "save" signal. When you save the project, Hydrogen will actually offer to save its session file (if it hasn't already been saved for the first time) when you save the project.
In fact, now that Hydrogen is running, go ahead and save the project, and save the file Hydrogen offers.
And now for some music.
Now, the IDJC has an excellent music player. However, the music player is internal to the program, and at no point can you separate it from the microphone output, which seriously limits its utility for this purpose. This means that it cannot be shunted into its own track in the DAW, so we will need another music player.
Into this mix, we bring the Mixxx. ...Where did that rimshot come from? Huh. Must've been the wind.
Mixxx is, at its core, a music player. It has to be; it is a different DJ application, more for presenting a mix to a party than a playlist to an audience. However, it has all the features we need for our purposes... Jack connections, single-shot players that we can fade using a MIDI Control Surface (which is an excellent feature by itself; if you don't have a surface, I recommend you get one), and a waveform display, which can be an absolute godsend when we are tracking our position in the ending music (perhaps timing our monologue against the end of the song).
This program will need to be set up on first run. It does not have individual sessions, just a global configuration. Additionally, it is a level 0 application.
The only command you need to know is its name, mixxx.
When Mixxx is started, you will see the following box:
Go ahead and "Reconfigure." Since I have not written an article on this program yet, we'll quickly (I hope) cover the options we will need to set here.
- Sound Hardware Tab:
- Set the sound API to "JACK Audio Connection Kit."
- Set the sample rate to match your Jack session.
- Set the master to "system." Nothing will happen in the graph (if you set the self-connection option correctly), but it makes Mixxx happy.
- Under MIDI Controllers, choose the controller name you want to set. (Skip if you don't have a control surface.)
- Set to "enabled."
- Add whichever controls you want to use, and what they will control in this program. The MIDI Learning Wizard should make this painless; just skip what we don't need to set.
- Assign a slider to [master] -> volume (allows you to adjust the music)
- Assign a button to [Channel1] -> play (serves as both play and pause for the first-loaded song)
- Assign a button to [Channel2] -> play (same for the second song)
- Under Library, choose the folder containing all of the music you plan to use with this application. If it includes music for other projects, don't worry, you can group them together later using the "Crates" feature.
- We can't see the interface, so don't worry about skin for now. The rest of the options have sane defaults, so we can keep them there.
- We don't need to set anything in "Equalizers;" we plan to handle equalization in Ardour and Jamin.
- We don't plan to be playing one song after another, so we can leave crossfader as it is.
- Recording is also not needed... we have Ardour for that.
- Beats Per Minute detection is not needed, so we can leave this as it is.
- Make sure all normalization options are enabled. The initial boost can remain as it is.
- We don't need turntables, so this page can be left alone.
- The IDJC is going to be the tool to broadcast, since Mixxx doesn't have any facility for microphone input or phone handling. We can leave the broadcast options alone.
Meh. Who am I kidding?
At any rate, let's save the Ladish project, to at least make sure that Mixx is part of the startup.
The IDJC is another not-in-Klaudia application, so it will have to be added as a custom application in Claudia. In this case, the command is:
Internet DJ Console: idjc -p Podcast
The "-p Podcast" means that the IDJC profile we'll use is the "Podcast" profile. We can set IDJC to level 0; it stays running in level 1 when saving, but the way the item in the flowcanvas blinks makes me wonder if it's just restarting when it crashes.
Next, we want to make sure we are optimizing the sound of both the stream and the sound of the final mix. So, here we will want to launch two instances of Jamin. These two instances are going to be placed as an insert on the master bus for Ardour, and as a DSP plugin for the IDJC console. In both these cases, the idea is to ensure that the sound is good enough for broadcast (IDJC) and distribution (Ardour master bus).
First, we want to bring up both instances of Jamin, and give each its own profile, in order to allow them to have independent settings (what may work for a stream might not be best for a master). To do this, we will launch the app twice from Klaudia or Gladish.
Jamin (Ardour): jamin -f "ardour.jam"
Jamin (IDJC): jamin -f "idjc.jam"
Jamin is not level-1 compatible, so we'll keep it at level 0 for now.
At this point, the next step should be obvious. Save the Ladish session to preserve the application manifest.
At this point, all the relevant applications should be available and ready to connect. Thanks to the settings made at the beginning of the process, nothing at this time should be connected, except for the outside studio. We will start to change that, but first, there is one connection we need to make that cannot be done within the studio interface.
The Internet DJ Console is a 2-part application. The first part, the player, handles all the audio playing and mixing of the microphones and auxiliary connections. The second part, the streaming connection manager, handles the communication with shoutcast and icecast servers.
Under normal circumstances, the connection should automatically be made between IDJC's player and streamer, except we explicitly set Jack to prevent this connection. Additionally, the streamer, for some reason, cannot be seen in the room environment, or even in the studio environment.
Because the streamer is only visible in the native Jack environment, we need to look at a raw Jack display to correct the issue. Claudia does not have this feature, but you can use Patchage. Alternatively, Gladish can enable the Raw Jack view by selecting the "View" menu, and then "JACK."
In any event, you will see an unholy mess. In both Gladish and Patchage, you can use the "Arrange" command in the "View" menu to straighten things up.
Now, you can see "idjc-sc" and "idjc-mx". These are the stream control and the mixer (player), respectively. What you need to do is connect the stream control's inputs to the "stream out" outputs of the player box, like this:
At this point, you can close Patchage and return to Claudia, or disable the "Jack" view in Gladish. Everything else can be done just fine from the normal session view. Make sure you save both project and studio in this case, to ensure this connection is preserved.
Now, before I begin making connections between the programs, I like to arrange the boxes to make the patterns easy to follow. On the left side, all the source boxes, including the microphones, Mixx, Hydrogen, and the "From Skype" box. Then, Ardour and its Jamin (all the audio comes through Ardour to be recorded). Following this, we have a column with the Internet DJ Console and its Jamin box. Finally, the outputs, sending the final audio (minus stream) to Skype and the headphones.
Now, we begin by sending input into their designated channels in Ardour. Save the project to store the connections.
Next, we connect all the outputs for the items we just connected to the master bus. Save the project to store the connections.
You will notice that while a number of these tracks have one single input, they have two outputs. This is because by default, a track in Ardour will have outputs equal in number to the number of channels in the master bus. This allows you to take an audio signal from a mono source, like the microphones, and adjust its panning, allowing, for example, having four different people on four different microphones, coming from slightly different positions in the stereo field.
Next, we want to create an "insert" in the master bus. This insert will treat the program connected to it like a plugin. This insert is specifically to add Jamin as a plugin in the master bus. To create the insert, we need to have the mixer window open in Ardour... if it's not already open, you can open it by clicking on the "Window" menu and then "Show Mixer."
In the bottom empty box of the "master bus" column (the one far to the right), you need to right-click and select "New Insert." This will show "(insert 1)" in the box, and in the connection graph, you will see entries appear in the Ardour box for the insert.
By right-clicking the insert in the Ardour mixer, we can rename it to "Jamin," which will make it more descriptive overall. For now, we will leave it disabled; once it is enabled, the parentheses will disappear, and the audio sent to the master bus will be piped through Jamin before leaving the bus. But this should be disabled during broadcasting/recording, and enabled once it's time for postprocessing.
Real quickly, go ahead and save Ardour's session. This will ensure that the insert control will remain present when Ardour is started again later.
Enabled or disabled, it's useless without Jamin actually being connected to it, so we will take a moment to do that now, moving the Jamin box to be closer to this section of the Ardour box.
Now, go ahead and save the Ladish session and project. We want to make sure these connections remain.
We've got one more step inside of Ardour, and we can move onto the next part of the connection process. In this case, we will be connecting the master bus to the final recording track. This is pretty simple; all you need to do is connect the master outputs to the "Final Mix" inputs. Leave the "Final Mix" outputs alone; you can connect them when you are no longer recording, in order to listen to the final product while mixing and mastering.
Once the connection is made, save the project and session, as usual.
Now, we're ready to move the signals onto the next step of their journey, the Internet DJ Console. Now, we want to connect the tracks in Ardour to their associated tracks in the IDJC.
First, we want to send the microphones. Remember that all four microphones are stereo output, but mono input. In this case, we can safely merge the two channels back into the one microphone-in channel on IDJC... if there are any gain issues, we can adjust the gain in IDJC to correct them. Now save project.
Next, the music and sound effects will need to be placed into the stream. The Auxiliary channel in IDJC can be used for this purpose, so go ahead and connect them to it. Make sure channel 1 from Ardour is connected to the left IDJC Aux channel, and the second is on the right channel. Now save project.
Next, we want our Skype caller to be heard over the stream, so we connect the Skype channel to the VoIP lines in IDJC. Save Project.
At this point, you're beginning to see a lot of spaghetti. However, if you've been following along (or are already comfortable with Jack), you should be realizing that you know what each and every connection in that graph does, and it's actually understandable... at least I hope you do.
At this point, we are completely finished with Ardour... it has been completely connected as needed until the post-processing step, when the final mix can be connected to the headphones for project work.
Next, we want the IDJC Jamin filter to be plugged in. Jamin uses the "DSP" connections in the same way that Ardour uses inserts, so we simply connect Jamin to the IDJC DSP connections. Save project.
The final connections are now ready to be made... audio output. At the beginning of this process, we connected the IDJC player to the stream controller, so all we have left is the headphones, for you to hear the stream, and the Skype control, for the caller to hear their end. So we simply connect the "DJ Out" channels to the headphones, and the VoIP Out channels to Skype. Save project.
Congratulations! You now have a complete workflow set up to allow a streaming podcast, splitting all inputs into their own tracks, mastering both broadcast and final mix, and even allowing you to take calls (or collaborate with a remote co-host) using Skype.
While doable, remember that much of the linux audio tools are still undergoing development, and some have different levels of support for Ladish, and yet others have hardcoded default locations, meaning that while a profile created with this session can start the application and link it up correctly on another system, the files that the program saves may not be transportable. This usually can be fixed by going into each program, and saving its settings to the folder containing the session profile.
Now, at the moment, you need to make sure that you go through the different programs, and make sure they save their projects to the Ladish project folder. This will ensure that consistency will be available, and that the programs will not complain that a project is not available.
When it's time to shut down, manually close the individual programs first, before unloading the project. Otherwise, it is possible that something won't get saved. Once version 1 of Ladish is released, the manual steps will likely no longer be needed, as the expanded levels will handle saving and safely shutting down applications.
...And that's it! You now have a saved workflow; you can close out of Ladish and Jack, confident that you can come back later, open the project, and Ladish will automatically launch every single program and make every single connection, at which point, you can just begin your podcast stream.
Plenty of noise for everyone!
Here's the twelfth installment of my ongoing series on systemd for Administrators:
Securing Your Services
One of the core features of Unix systems is the idea of privilege separation between the different components of the OS. Many system services run under their own user IDs thus limiting what they can do, and hence the impact they may have on the OS in case they get exploited.
This kind of privilege separation only provides very basic protection however, since in general system services run this way can still do at least as much as a normal local users, though not as much as root. For security purposes it is however very interesting to limit even further what services can do, and shut them off a couple of things that normal users are allowed to do.
A great way to limit the impact of services is by employing MAC technologies such as SELinux. If you are interested to secure down your server, running SELinux is a very good idea. systemd enables developers and administrators to apply additional restrictions to local services independently of a MAC. Thus, regardless whether you are able to make use of SELinux you may still enforce certain security limits on your services.
In this iteration of the series we want to focus on a couple of these security features of systemd and how to make use of them in your services. These features take advantage of a couple of Linux-specific technologies that have been available in the kernel for a long time, but never have been exposed in a widely usable fashion. These systemd features have been designed to be as easy to use as possible, in order to make them attractive to administrators and upstream developers:
- Isolating services from the network
- Service-private /tmp
- Making directories appear read-only or inaccessible to services
- Taking away capabilities from services
- Disallowing forking, limiting file creation for services
- Controlling device node access of services
All options described here are documented in systemd's man pages, notably systemd.exec(5). Please consult these man pages for further details.
All these options are available on all systemd systems, regardless if SELinux or any other MAC is enabled, or not.
All these options are relatively cheap, so if in doubt use them. Even if you might think that your service doesn't write to /tmp and hence enabling PrivateTmp=yes (as described below) might not be necessary, due to today's complex software it's still beneficial to enable this feature, simply because libraries you link to (and plug-ins to those libraries) which you do not control might need temporary files after all. Example: you never know what kind of NSS module your local installation has enabled, and what that NSS module does with /tmp.
These options are hopefully interesting both for administrators to secure their local systems, and for upstream developers to ship their services secure by default. We strongly encourage upstream developers to consider using these options by default in their upstream service units. They are very easy to make use of and have major benefits for security.
Isolating Services from the Network
A very simple but powerful configuration option you may use in systemd service definitions is PrivateNetwork=:
... [Service] ExecStart=... PrivateNetwork=yes ...
With this simple switch a service and all the processes it consists of are entirely disconnected from any kind of networking. Network interfaces became unavailable to the processes, the only one they'll see is the loopback device "lo", but it is isolated from the real host loopback. This is a very powerful protection from network attacks.
Caveat: Some services require the network to be operational. Of course, nobody would consider using PrivateNetwork=yes on a network-facing service such as Apache. However even for non-network-facing services network support might be necessary and not always obvious. Example: if the local system is configured for an LDAP-based user database doing glibc name lookups with calls such as getpwnam() might end up resulting in network access. That said, even in those cases it is more often than not OK to use PrivateNetwork=yes since user IDs of system service users are required to be resolvable even without any network around. That means as long as the only user IDs your service needs to resolve are below the magic 1000 boundary using PrivateNetwork=yes should be OK.
Internally, this feature makes use of network namespaces of the kernel. If enabled a new network namespace is opened and only the loopback device configured in it.
Service-Private /tmp
Another very simple but powerful configuration switch is PrivateTmp=:
... [Service] ExecStart=... PrivateTmp=yes ...
If enabled this option will ensure that the /tmp directory the service will see is private and isolated from the host system's /tmp. /tmp traditionally has been a shared space for all local services and users. Over the years it has been a major source of security problems for a multitude of services. Symlink attacks and DoS vulnerabilities due to guessable /tmp temporary files are common. By isolating the service's /tmp from the rest of the host, such vulnerabilities become moot.
For Fedora 17 a feature has been accepted in order to enable this option across a large number of services.
Caveat: Some services actually misuse /tmp as a location for IPC sockets and other communication primitives, even though this is almost always a vulnerability (simply because if you use it for communication you need guessable names, and guessable names make your code vulnerable to DoS and symlink attacks) and /run is the much safer replacement for this, simply because it is not a location writable to unprivileged processes. For example, X11 places it's communication sockets below /tmp (which is actually secure -- though still not ideal -- in this exception since it does so in a safe subdirectory which is created at early boot.) Services which need to communicate via such communication primitives in /tmp are no candidates for PrivateTmp=. Thankfully these days only very few services misusing /tmp like this remain.
Internally, this feature makes use of file system namespaces of the kernel. If enabled a new file system namespace is opened inheritng most of the host hierarchy with the exception of /tmp.
Making Directories Appear Read-Only or Inaccessible to Services
With the ReadOnlyDirectories= and InaccessibleDirectories= options it is possible to make the specified directories inaccessible for writing resp. both reading and writing to the service:
... [Service] ExecStart=... InaccessibleDirectories=/home ReadOnlyDirectories=/var ...
With these two configuration lines the whole tree below /home becomes inaccessible to the service (i.e. the directory will appear empty and with 000 access mode), and the tree below /var becomes read-only.
Caveat: Note that ReadOnlyDirectories= currently is not recursively applied to submounts of the specified directories (i.e. mounts below /var in the example above stay writable). This is likely to get fixed soon.
Internally, this is also implemented based on file system namspaces.
Taking Away Capabilities From Services
Another very powerful security option in systemd is CapabilityBoundingSet= which allows to limit in a relatively fine grained fashion which kernel capabilities a service started retains:
... [Service] ExecStart=... CapabilityBoundingSet=CAP_CHOWN CAP_KILL ...
In the example above only the CAP_CHOWN and CAP_KILL capabilities are retained by the service, and the service and any processes it might create have no chance to ever acquire any other capabilities again, not even via setuid binaries. The list of currently defined capabilities is available in capabilities(7). Unfortunately some of the defined capabilities are overly generic (such as CAP_SYS_ADMIN), however they are still a very useful tool, in particular for services that otherwise run with full root privileges.
To identify precisely which capabilities are necessary for a service to run cleanly is not always easy and requires a bit of testing. To simplify this process a bit, it is possible to blacklist certain capabilities that are definitely not needed instead of whitelisting all that might be needed. Example: the CAP_SYS_PTRACE is a particularly powerful and security relevant capability needed for the implementation of debuggers, since it allows introspecting and manipulating any local process on the system. A service like Apache obviously has no business in being a debugger for other processes, hence it is safe to remove the capability from it:
... [Service] ExecStart=... CapabilityBoundingSet=~CAP_SYS_PTRACE ...
The ~ character the value assignment here is prefixed with inverts the meaning of the option: instead of listing all capabalities the service will retain you may list the ones it will not retain.
Caveat: Some services might react confused if certain capabilities are made unavailable to them. Thus when determining the right set of capabilities to keep around you need to do this carefully, and it might be a good idea to talk to the upstream maintainers since they should know best which operations a service might need to run successfully.
Caveat 2: Capabilities are not a magic wand. You probably want to combine them and use them in conjunction with other security options in order to make them truly useful.
To easily check which processes on your system retain which capabilities use the pscap tool from the libcap-ng-utils package.
Making use of systemd's CapabilityBoundingSet= option is often a simple, discoverable and cheap replacement for patching all system daemons individually to control the capability bounding set on their own.
Disallowing Forking, Limiting File Creation for Services
Resource Limits may be used to apply certain security limits on services being run. Primarily, resource limits are useful for resource control (as the name suggests...) not so much access control. However, two of them can be useful to disable certain OS features: RLIMIT_NPROC and RLIMIT_FSIZE may be used to disable forking and disable writing of any files with a size > 0:
... [Service] ExecStart=... LimitNPROC=1 LimitFSIZE=0 ...
Note that this will work only if the service in question drops privileges and runs under a (non-root) user ID of its own or drops the CAP_SYS_RESOURCE capability, for example via CapabilityBoundingSet= as discussed above. Without that a process could simply increase the resource limit again thus voiding any effect.
Caveat: LimitFSIZE= is pretty brutal. If the service attempts to write a file with a size > 0, it will immeidately be killed with the SIGXFSZ which unless caught terminates the process. Also, creating files with size 0 is still allowed, even if this option is used.
For more information on these and other resource limits, see setrlimit(2).
Controlling Device Node Access of Services
Devices nodes are an important interface to the kernel and its drivers. Since drivers tend to get much less testing and security checking than the core kernel they often are a major entry point for security hacks. systemd allows you to control access to devices individually for each service:
... [Service] ExecStart=... DeviceAllow=/dev/null rw ...
This will limit access to /dev/null and only this device node, disallowing access to any other device nodes.
The feature is implemented on top of the devices cgroup controller.
Other Options
Besides the easy to use options above there are a number of other security relevant options available. However they usually require a bit of preparation in the service itself and hence are probably primarily useful for upstream developers. These options are RootDirectory= (to set up chroot() environments for a service) as well as User= and Group= to drop privileges to the specified user and group. These options are particularly useful to greatly simplify writing daemons, where all the complexities of securely dropping privileges can be left to systemd, and kept out of the daemons themselves.
If you are wondering why these options are not enabled by default: some of them simply break seamntics of traditional Unix, and to maintain compatibility we cannot enable them by default. e.g. since traditional Unix enforced that /tmp was a shared namespace, and processes could use it for IPC we cannot just go and turn that off globally, just because /tmp's role in IPC is now replaced by /run.
And that's it for now. If you are working on unit files for upstream or in your distribution, please consider using one or more of the options listed above. If you service is secure by default by taking advantage of these options this will help not only your users but also make the Internet a safer place.
Thursday, 19 January
We know some folks are very upset by the scrapping on vintage hardware, so let’s all observe a moment of silence for this NES controller.
Now that that’s behind us we can live vicariously through [Burger King Diamond's] project. He polished up the NES controller and repurposed it as an enclosure for a portable MP3 player.
His first step was to remove some of the yellowing of the plastic using Retr0brite. He admits it wasn’t bad to start with but now it’s sparkling like new. Next, he started planning how everything would fit in the case. Luckily the MP3 player operates with one AAA battery which leaves plenty of room.
Just above the A and B buttons you can make out an opening that he cut in the case for the MP3 player’s LCD screen. The bezel from the original case works well for cleaning the rough cut opening. The buttons on the controller have been patched into the controls on the MP3 board, and the opening for the controller’s cable now holds the headphone jack. There’s also a USB port mounted next to it for easy file transfers.
The one thing we would like to see is a rechargeable battery so you don’t need to open the case to top off the power. But all in all this is a fantastic build!
Filed under: digital audio hacks
One is a keytar. One is a master controller with touch faders and real MIDI and — control voltage, for working with analog gear. Seriously. The keyboard controller market may have faded into a dull, gray blur of nearly-identical models, but under the Alesis and Akai monikers, there’s some fresh-looking variety. Love it or hate it, these are not the same keyboards you’ll get from anybody else at the moment.
I got to meet with Alesis/Akai/Numark today at the NAMM Press Preview, get my hands on a prototype of their new Vortex keytar, and talk about what they’re doing. And I have to say, I’m impressed. (I didn’t get hands on the second model, the MAX49, but will visit their booth in the next couple of days.) Finally, we get the return of the MIDI DIN port for working with a wider range of hardware, without sacrificing USB. One model even does CV for analog equipment. And both can supply their own power so you can use them with iOS. And they at least are interesting enough to have an opinion about them – even if you hate them.
Here’s a look at each of them and what why they’ll be on our radar when they ship later this year.
Alesis Vortex Keytar
First off, let me say it, once and for all: I don’t think there’s anything dorky about a keytar, other than the name. Us keyboardists are plenty capable of being dorky on our own, but don’t blame the instrument.
What keytars are – or strap-on keyboards, if you can say that without smirking – is eminently practical for one-handed playing. For two-handed playing or more conventional piano or organ parts, of course, you’re better off without them. But the keytar lets you move around, play expressive solos, and also free up your hands if you’re using other machines, as in electronic music. Unfortunately, the options out there have been overly large, making them too unweildly for many people to play, and overly expensive, pricing them out of a lot of their market. I’ve played and advocated the Rock Band game controller because it’s lightweight, inexpensive, and nicely made, and it even has a MIDI jack. I actually hear one Harmonix veteran is now at Alesis, so that may be no coincidence. (The Vortex even has a touch strip on its neck.)
The Vortex, though, looks like the first really balanced keytar controller in the market … well, ever. Features:
- MIDI DIN and USB MIDI
- Velocity-sensitive pads in addition to the keys
- 37 velocity-sensitive keys (good number for a keytar), plus channel aftertouch (heck, yes)
- MIDI-assignable accelerometer. And this is cool – it’s not on all the time; you make a quick sweep of the neck to enable the accelerometer in a clever gesture control.
- MIDI-assignable touch strip, but also a full pitch bend wheel underneath your thumb (I rather prefer the latter, but it’s nice to have a choice).
- Assignable slider under your thumb, mapped by default to volume.
- Dedicated sustain button, plus octave selection, transport, and patch select.
With all due respect to Roland, this appears to fix effectively all of my complaints about the Roland keytars at a fraction of the price.
And you can add a strap via standard guitar strap pegs.
The best part:
Q2-2012
MSRP US$399
Estimated street US$249
Akai Pro MAX49: Touch Faders, CV
I’ve all but begged manufacturers to explore what an advanced or high-end MIDI controller would look like. The MAX49 likely won’t please everyone, but it’s one compelling-looking answer. Features:
- 49 semi-weighted keys, with channel aftertouch
- 12 MPC pads, backlit, four banks each
- 8 LED touch faders in place of physical faders, four banks each
- Control Voltage and analog Gate outputs for use with analog and vintage gear
- Arpeggiator with latch
- Step sequencer
- MPC swing, Note Repeat, Full Level, navigation – and yeah, I use this stuff, even if the software can do the same
USB MIDI, MIDI DIN, connect to anything - Control surface mappings plus full Mackie Control and HUI support – and, sorry, but for all the fancier solutions, sometimes that’s the easiest way to control a variety of software like Ableton Live, Reason, and the other DAWs
So, basically, all the features you want. My only questions are what it looks like in person and how the action feels, particularly those touch faders, as that can be tricky to pull off.
But the features are just perfect. It’s about time to bring back aftertouch and to connect with actual MIDI gear. Adding CV is a delicious addition. And honestly, features like being able to switch on an arpeggiator are far more useful and appealing to average musicians than the hard-to-configure, often-gimmicky automatic control features on many of the keyboards out there. So I’ve got my fingers crossed that the build quality and usability here are good — and that some of Akai’s rivals start taking on similar features. It’s bizarre to be applauding adding features from the 80s and 70s, but some recent progress has been steps backward, not forward.
Q2 2012
MSRP US$699
Estimated street $499
There are other new Alesis keyboards out this week, but the Akai MAX49 pretty much steals their thunder.
More Vortex Photos
Back to the Vortex, since I got to snap some shots this morning in Anaheim.
Discuss.
As you may have noticed various sites and domains that I manage went black - or rather redirected to http://protestsopa.org/ or to the Electronic Frontier Foundation.
It probably does not wag the tail of anyone, but I felt that is incumbant upon me to express my support for freedom of speech and that I am prepared to defend it.
SOPA, PIPA - What is that?
The Stop Online Piracy Act is H.R.3261, and the Protect-IP Act is S.968 both are propsed laws in the US of A.
Why is bad?
The intent of both pieces of legislation is to combat online piracy. The problem is that the legislation, as written, is vague and overly-broad. The intention may be good and justified, but the implementation would be nothing short of legal censorship and discrimination.
It'd grant the executive the power to simply shut down information sources. In fact, if the law passes, it would not even require a court order to ban a service! A simple note would suffices to censor information, unless the provider of the content can prove and assure (monitor) that his/her site does not facilitate the commission of criminal violations.
There are times that everyday reasonable activities can be construed as piracy, but the actual problematic word is facilitating, as it opens the door to condemning sites that simply link to other sites.
Since the USA directly or indirectly controls most of the internet's infrastructure, and the proposed legislation has been written in a manner in which they specifically take into account “foreign rogue sites”, the legislation will, should it pass, have an impact upon the world as a whole.
These acts could have a significant impact on the way in which we currently use the internet: Free Speech is only as strong as the weakest link.
What to do about it?
Thanks to many activist sites (see links above and below) this is easy. If you are US resident, complain at your senator(s). If you are elsewhere, there are local efforts: e.g. join contacting the German minister of foreign-affairs who is supporting the law in the US!
References
For more information about SOPA/PIPA, please see:
Wednesday, 18 January
The first release is close.
Besides polishing here and there Laborejo needs a Logo.
I don't want to release even an alpha version without a logo subsequently followed by a corporate identity.
Speaking of "Alpha": There is still much to do, especially in the GUI and performance-wise. But the first release will be far away from some "initial test". It is very functional and covers most styles of music.
If you enjoyed yesterday’s sketch, you really should check out this great remix by ioflow. He took my original loops and rearranged them in Renoise, mixing things up to great effect with some micro-edits (the little reversed bits sound awesome) and some low-key, distorted beats. Unfortunately I forgot to save the final set of loops, so he had to make do without the melody part, but it definitely hasn’t hurt things.
I very nearly neglected to post yesterday’s sketch, since the timing was rough and the whole thing was musically very simple. Needless to say, I’m glad I did post it now — chalk this up as a win for online collaboration and Creative Commons!
20120117 by ioflow
downtempo rework of pneuman's rhodes-based sooperlooper sketch. he mentioned adding bitcrushed beats one day, and i was already hearing the possibilities while listening to the original. i spent a few hours here and there in renoise sequencing and crushing beats and stems, and came up with this interpretation.
thanks to [lsd] for making the raw loops available; he's a very chill dude. go listen to his stuff.
Tuesday, 17 January
Believe it or not, the local Children’s Museum staff was happy that [Bill Porter] left this mess of wires and equipment in one of their offices. It makes up an ambient sound system for a couple of their exhibits. A movie without sound just doesn’t fully entertain, and the same can be said for these exhibits. The ambient sound that goes with a boat room, and a hospital room in the Museum really helps to snag your attention. And [Bill's] material cost came in at just over $200 for both rooms.
He started off by purchasing a speaker, amp, and MP3 breakout board (SparkFun). The speaker mounts in one of the ceiling tiles, with the wire running to a different room where the audio equipment is housed. There were a couple of problems with this; the museum staff forgot to turn on the system, and for all of its expense this only provided one room with audio. Bill figured that since only one speaker was being used he could make an audio file with a different clip on the left and right channel, then feed them to different rooms. He also added that programmable timer so the sounds will turn themselves on and off.
This isn’t the first time we’ve seen hacks end up as museum pieces. Check out this other project that rigs up some interactive telephones.
Filed under: digital audio hacks
