This highlights a big problem in the world of music and audio software: everyone likes the idea of standards, just so long as they control the standard. And while this problem no doubt exists in other domains, it's painfully apparent in music and audio applications because the market is too small.
Clap won't succeed longterm because of many of the factors outlined in so many of these posts. Notably, Apple aren't going to support it in Logic because Audio Units work just fine, and AUv3 spans both iDevice and Mac markets. Steinberg almost certainly won't support it; they aren't even allowing VST 2.4 plug-ins to run in the Apple Silicon version of Cubase -- and this isn't for technical reasons. Ironically, Steinberg have been trying to push VST 3 since the release of Cubase v4.1 back in 2006, and it's still a giant pain 16 years later. If you look back at VST 1/2, part of the allure was the simplicity of the API; VST 3 tried to change the game too much towards MVC given that it looked at the time you might want to run the processing part of the plug-in on a different system than the user interface part.
Pro Tools doesn't get a mention in this thread, for the most part, but for better or worse it remains something of standard in audio post-production in the US. AAX isn't a bad re-imagining of what what RTAS/TDM-based plug-ins pre v10, and Avid aren't going to relinquish any control to third parties. Not least because the need for AAX (such as it is) resolves around support for the company's hardware control surfaces. EuCon was originally envisaged as an agnostic hardware controller protocol by Euphonix, but Avid purchased Euphonix, released the S6 and associated controllers and made EuControl into something of a tolerated illegitimate child.
Plug-in developers will have to follow the money, and I would to see the results of a survey correlating money spent on plug-ins based on the main host software used. My guess is that Pro Tools AAX on the Mac probably is the most lucrative, followed by Cubase and Logic. Depressing, but for all the moaning musicians tend to indulge in regarding fair compensation against any company they feel exploited by, there's a reason why music and audio applications and plug-ins remain the most heavily copy-protected software.
I don't know of anyone who's ever ditched their host application because of a plug-in format, and I highly doubt the CLAP is going to harm Apple, Steinberg, and Avid in the longterm.
> Pro Tools doesn't get a mention in this thread, for the most part, but for better or worse it remains something of standard in audio post-production in the US. AAX isn't a bad re-imagining of what what RTAS/TDM-based plug-ins pre v10, and Avid aren't going to relinquish any control to third parties.
To everyone’s surprise (yours included, I’m sure) Avid is mentioned in the announcement as a company already involved with the project and working on using it for something. There’s a nonzero chance they could adopt it in Pro Tools and drop AAX.
It is not intended to harm Apple or Steinberg, the aim is to be less dependent of them by having a free and non-bloated common plugin api that has basically all the features of VST/AU/AAX/LV2 etc. All these proprietary apis can then be addressed with a bit of wrapping code when needed.
Right now, the de-facto most important standard is VST3, which is owned by Steinberg/Yamaha who can decide to revoke the license of any developer at their will. They have shown these last years that they can be really aggressive with their license. If clap takes over, then they won't have the same position of power on audio developers. This is good for the industry.
Even if there wasn't this licensing issue with VST3, none of the current plugin formats deserve to be the "default plugin format" , they are all terrible: very large codebases, bloated architectures, c++ api, unclear threading specifications... (exception: VST2 which is simple, with a c api, but Steinberg is not allowing it anymore for new developers).
I think this is a very negative and old-fashioned opinion, especially within HN that is usually focused on 'disrupting the industry' and 'innovation'.
Every day we see a new project written in the latest 'cool' language, and it receives praise and encouragement, yet try to suggest that a new audio plugin format has value and it's knocked back because 'industry standards'.
Just to give one simple example, if Native Instruments were to add CLAP to Kontakt player, and suddenly orchestral samples could have more variance per note, making the realism better - there would be huge demand from composers.
Would they switch DAW ? Maybe not for their current work, but you can guarantee it would have a lot of interest and they would be pressuring companies to add it.
For too long, audio software has been stuck in the monopoly of a few big companies. It's absolutely time to disrupt that even more and open it up to more independent developers, in the same way open source has helped in other industries.
Rather than doom CLAP to not being adopted, perhaps look to the benefits and help encourage diversity and change.
Your very first sentence is why CLAP is going to succeed in the long term. It is why CLAP was developed. It it an open standard that gives developers what they need in a way that LV2 never will. For many devs, it will be their primary CI/CD target of choice. It is not unlikely that the plugin devs with huge legacy code bases, such as NI, will begin to realize that CLAP provides a path forward to VST3/4/? support that will insulate them from Steinberg and Apple's decisions in the long term and save the a lot of money, and keep their legacy code bases profitable.
Avid is already evaluating CLAP support. So is Presonus. Reaper is nearly there. So in my opinion it's only a matter of time before Pro Tools, the industry mastering standard, supports CLAP. Other DAWs will follow.
I think you are underestimating just how much of a problem that Steinberg has created for the industry as a whole with their draconian limitations on the VST development. Pulling VST2 out from under everyone has created huge issues for plugin developers (like u-he) who rely on VST2 as their primary development target. Developers hate VST3, and nobody trusts Steinberg. Nor should they. VST3 is a dumpster fire that people target only because they have no choice.
CLAP may or may not succeed as a plugin format that users will use. But its greatest chance of success will be as the primary development target for developers, with all other formats wrapped around CLAP. It's a dream to develop on with its simple ABI, and a dream to wrap to other formats. This means that, over time, a large number of developers will produce CLAP plugins just to end the nightmare of maintaining VST2/3/AU/AAX versions that are feature complete.
With Avid, Bitwig, and Presonus already on board, and Reaper soon to follow, and with developers like Fabfilter and Xfer announcing interest, I think you vastly underestimate its chance of long term success.
This is even before considering what CLAP gives you. MIDI 2.0 is coming. Rich per-note expression is presently poorly supported in all DAWs except for Bitwig, (but until now, only on its internal instruments). CLAP has it, out the door, and Bitwig now supports it with its per-note modulation system. Other DAWs want this feature, but don't want to roll their own version of it. But the entire equation changes when you have major plugin developers already supporting it via CLAP.
My gentleman's bet is that CLAP will gain momentum, and the rest of the DAW world, save for Apple and Steinberg, will support it.
> there's a reason why music and audio applications and plug-ins remain the most heavily copy-protected software.
This is sadly true. I used to make a bit of music and I knew several people who would simply hoard pirated plugins and sample libraries, even if they'd never use them. I think it's an extension of "gear acquisition syndrome".
When even Kanye has been caught pirating plugins, what hope do vendors have.
Disagree. Musicians like their platforms, but they also go where the good sounds are. There will be third party wrappers for CLAP plugins that will allow them to work in Logic or Cubase, and if high quality CLAP plugins are available (highly likely given U-he's stellar DSP record) then people are going to want to use them.
Yes for some reasons the audio world doesn't speak much about figures: cost of development, revenue etc.
There is a huge market of let's say $25-$50 plugins that serve the amateurs just as well the pros and the former have been pushed out of ProTools for a while now, so I'm not so sure AAXs beat VSTs nowadays, but hard to argue volume or revenue without the data.
I and some other folks in the Rust audio community have put together some low-level bindings for the CLAP API: https://github.com/glowcoil/clap-sys
They're relatively straightforward due to the fact that CLAP is a simple, pure-C ABI, and there are already some fully functional plugins making use of them (e.g. https://github.com/robbert-vdh/nih-plug).
I'm interested to hear your take on this, as I suspect you're one of the few of us on HN actually qualified to have one.
I'm also curious (if you're comfortable answering), were you involved with "design and implementation contributions by a group of commercial and open source audio developers from across our industry."?
I don't think Ableton is that petty. They'll back this if they think they stand to gain something from it. And given the mess that the other plugin standards are I think the value proposition is clear.
Also developed by u-he thats one big player in plugin synth world already. If CLAP solves issues plugin devs have and maybe makes plugins better than customers will demand support.
I'm not big in the audio community but I thought LV2 was the open standard for plugins that people are pushing for? That being said if Cockos adopts it into Reaper I'm absolutely willing to try it.
It also never got enough support from big guys. Clap looks like it fixes a lot od LV2 stuff as well, and it can replace VST, which is good because VST is a crap technology.
Note that unlike pretty much every other c/c++ plugin API, the plugin code does not need to include any header, everything is done through reflection of struct members at compile-time. This means that it's dead easy to port plugins to e.g. microcontrollers.
since it binds directly to audio APIs at compile time, it has pretty much zero code size in itself, the smallest plugin it generates for VST2 is around 7kb IIRC
As a professional freelance mixer I must say if the programming behind CLAP is anywhere close to the quality they achieved in Bitwig, I am sold on the idea.
Bitwig does up to audio rate modulations of nearly every parameter, the stock plugins are all really top notch, the way they implemented voice stacking or polyphonic pitchbends for MPE synths etc. are all done in the way I dreamt it should have been done.
It still lacks a bit on the hardcore audio editing and mixing front (e.g. in ProTools you can edit extremely fast, just using the keyboard).
Their pricing and licensing model is fair. The price is actually quite okay given what you get in addition to just the DAW (a really good sample library with all the famous drum machines, a reaktor-like modular stock-plugin for synth, effects and midi manipulation, a powerful live-performance tool, etc.)
Is a MIT license a good fit for an open standard? What prevents any big nasty player adopting and sneakily subverting it with additions/changes in a truly EEE way?
> As we proceed beyond the initial set of extensions, we are committed to establishing a transparent process to govern the standard which allows participation from the entire audio software community. We welcome participation from the development community today, and we will share details of these processes and governing models over the second half of 2022.
Very vague and doesn't really instil confidence: "Join us now, and months later we'll share how we're going to protect your work."
Pro audio plugins have lower latency and harder constraints than graphics processing. You cannot drop a frame, and roundtrip latency is ideally below 5ms. GPU Audio (the company) has a lot of hype but it's not really clear if they gain a ton. The existing analogs to GPUs are expensive pieces of special purpose DSPs like Waves Grid, Universal Audio's UAD, and the biggest which are Avid PT HDX accelerators.
It turns out modern CPUs are plenty fast for heavy audio DSP. The point of friction is synchronization and the memory wall, most of the time.
It turns out that audio DSP algorithms don't generally benefit from the same kind of parallelism you get on a GPU, since even the basic stuff you'd like to do (filtering, algorithmic reverb, etc) is a bunch of recursive/sequential algorithms that have a non-trivial cost to convert to a parallel form for SIMD evaluation, and the gains are not linear due to repeated computation (classic example, converting an exponential moving average which is used everywhere to N lanes of SIMD is a lot less than an N times speed up).
That's not to say there isn't exciting work being done (GPU audio, for example). It's just really hard and not a magic bullet. It's not an Audio Processing Unit, after all. It also has video output, but not high fidelity audio i/o.
GPU Audio is doing it with VST 3. And it's probably possible with CLAP too?
Processing audio on a GPU is a lower level issue than a plugin standard which describes the interface between the DAW and the plugin (how audio, parameters, notes, modulation data, etc. are exchanged).
Honestly, it is an unfortunate naming choice ... no doubt it's going to lead to all kinds of double-take usages in surrounding lit. I certainly read the title to the post twice.
While not perfect, I really liked Will Pirkle’s book[1]. It describes the popular ABIs and has great intro to DSP. I would say the downsides are that the description of various interfaces takes up too many pages and that the book uses his own framework ASPiK for cross-compatability, but it’s easy enough to convert to a more popular framework like JUCE if needed.
Hopefully some people create a new "Atmos" style audio standard (eg multiple height surround sound), but OSS.
It's a pita with the current situation, where everything past ~7.1 audio channels is proprietary and needs extremely expensive hardware (eg decoders) just to direct the audio to the correct speakers. :(
Ambisonics predates Atmos by many decades, is license free and has both gratis and libre toolchains available. It can handle any number of speakers, in any configuration.
A "pure C ABI" doesn't really mean much, last I checked, seeing as how just about every combination of OS and CPU has its own quirks re: calling conventions and struct packing and such. Ain't sure what's meant here.
[+] [-] markofthew|3 years ago|reply
Clap won't succeed longterm because of many of the factors outlined in so many of these posts. Notably, Apple aren't going to support it in Logic because Audio Units work just fine, and AUv3 spans both iDevice and Mac markets. Steinberg almost certainly won't support it; they aren't even allowing VST 2.4 plug-ins to run in the Apple Silicon version of Cubase -- and this isn't for technical reasons. Ironically, Steinberg have been trying to push VST 3 since the release of Cubase v4.1 back in 2006, and it's still a giant pain 16 years later. If you look back at VST 1/2, part of the allure was the simplicity of the API; VST 3 tried to change the game too much towards MVC given that it looked at the time you might want to run the processing part of the plug-in on a different system than the user interface part.
Pro Tools doesn't get a mention in this thread, for the most part, but for better or worse it remains something of standard in audio post-production in the US. AAX isn't a bad re-imagining of what what RTAS/TDM-based plug-ins pre v10, and Avid aren't going to relinquish any control to third parties. Not least because the need for AAX (such as it is) resolves around support for the company's hardware control surfaces. EuCon was originally envisaged as an agnostic hardware controller protocol by Euphonix, but Avid purchased Euphonix, released the S6 and associated controllers and made EuControl into something of a tolerated illegitimate child.
Plug-in developers will have to follow the money, and I would to see the results of a survey correlating money spent on plug-ins based on the main host software used. My guess is that Pro Tools AAX on the Mac probably is the most lucrative, followed by Cubase and Logic. Depressing, but for all the moaning musicians tend to indulge in regarding fair compensation against any company they feel exploited by, there's a reason why music and audio applications and plug-ins remain the most heavily copy-protected software.
I don't know of anyone who's ever ditched their host application because of a plug-in format, and I highly doubt the CLAP is going to harm Apple, Steinberg, and Avid in the longterm.
[+] [-] Hemospectrum|3 years ago|reply
To everyone’s surprise (yours included, I’m sure) Avid is mentioned in the announcement as a company already involved with the project and working on using it for something. There’s a nonzero chance they could adopt it in Pro Tools and drop AAX.
[+] [-] hules|3 years ago|reply
Right now, the de-facto most important standard is VST3, which is owned by Steinberg/Yamaha who can decide to revoke the license of any developer at their will. They have shown these last years that they can be really aggressive with their license. If clap takes over, then they won't have the same position of power on audio developers. This is good for the industry.
Even if there wasn't this licensing issue with VST3, none of the current plugin formats deserve to be the "default plugin format" , they are all terrible: very large codebases, bloated architectures, c++ api, unclear threading specifications... (exception: VST2 which is simple, with a c api, but Steinberg is not allowing it anymore for new developers).
[+] [-] softfalcon|3 years ago|reply
This is literally the “it’ll takes me hours to Google it, but them 5 minutes to explain cause they’re an expert” in action.
Clearly you know your stuff and the amount of information you conveyed in such a little time is honestly really impressive.
[+] [-] mobiuscog|3 years ago|reply
Every day we see a new project written in the latest 'cool' language, and it receives praise and encouragement, yet try to suggest that a new audio plugin format has value and it's knocked back because 'industry standards'.
Just to give one simple example, if Native Instruments were to add CLAP to Kontakt player, and suddenly orchestral samples could have more variance per note, making the realism better - there would be huge demand from composers.
Would they switch DAW ? Maybe not for their current work, but you can guarantee it would have a lot of interest and they would be pressuring companies to add it.
For too long, audio software has been stuck in the monopoly of a few big companies. It's absolutely time to disrupt that even more and open it up to more independent developers, in the same way open source has helped in other industries.
Rather than doom CLAP to not being adopted, perhaps look to the benefits and help encourage diversity and change.
[+] [-] teilo|3 years ago|reply
Avid is already evaluating CLAP support. So is Presonus. Reaper is nearly there. So in my opinion it's only a matter of time before Pro Tools, the industry mastering standard, supports CLAP. Other DAWs will follow.
I think you are underestimating just how much of a problem that Steinberg has created for the industry as a whole with their draconian limitations on the VST development. Pulling VST2 out from under everyone has created huge issues for plugin developers (like u-he) who rely on VST2 as their primary development target. Developers hate VST3, and nobody trusts Steinberg. Nor should they. VST3 is a dumpster fire that people target only because they have no choice.
CLAP may or may not succeed as a plugin format that users will use. But its greatest chance of success will be as the primary development target for developers, with all other formats wrapped around CLAP. It's a dream to develop on with its simple ABI, and a dream to wrap to other formats. This means that, over time, a large number of developers will produce CLAP plugins just to end the nightmare of maintaining VST2/3/AU/AAX versions that are feature complete.
With Avid, Bitwig, and Presonus already on board, and Reaper soon to follow, and with developers like Fabfilter and Xfer announcing interest, I think you vastly underestimate its chance of long term success.
This is even before considering what CLAP gives you. MIDI 2.0 is coming. Rich per-note expression is presently poorly supported in all DAWs except for Bitwig, (but until now, only on its internal instruments). CLAP has it, out the door, and Bitwig now supports it with its per-note modulation system. Other DAWs want this feature, but don't want to roll their own version of it. But the entire equation changes when you have major plugin developers already supporting it via CLAP.
My gentleman's bet is that CLAP will gain momentum, and the rest of the DAW world, save for Apple and Steinberg, will support it.
[+] [-] Someone|3 years ago|reply
I’m asking because I wonder whether an open standard that sits ‘below’ all of them, and provides adapters to each closed standard, would make sense.
[+] [-] kibibu|3 years ago|reply
This is sadly true. I used to make a bit of music and I knew several people who would simply hoard pirated plugins and sample libraries, even if they'd never use them. I think it's an extension of "gear acquisition syndrome".
When even Kanye has been caught pirating plugins, what hope do vendors have.
[+] [-] anigbrowl|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] conradfr|3 years ago|reply
There is a huge market of let's say $25-$50 plugins that serve the amateurs just as well the pros and the former have been pushed out of ProTools for a while now, so I'm not so sure AAXs beat VSTs nowadays, but hard to argue volume or revenue without the data.
[+] [-] glowcoil|3 years ago|reply
They're relatively straightforward due to the fact that CLAP is a simple, pure-C ABI, and there are already some fully functional plugins making use of them (e.g. https://github.com/robbert-vdh/nih-plug).
[+] [-] PaulDavisThe1st|3 years ago|reply
https://librearts.org/2022/06/introducing-clap/
and from the same author, just last week, an LWN overview of CLAP:
https://lwn.net/Articles/893048/
and from the same author a few weeks before that, and overview of the state of audio plugin APIs with a particular focus on the Linux situation:
https://lwn.net/Articles/890272/
[+] [-] PaulDavisThe1st|3 years ago|reply
> what’s the point of a new standard when no DAW besides Bitwig supports it?
> Good. This is a space that could use a new, open standard. With Bitwig behind it, I’m paying attention now.
Never believe in the idea of the HN "hive mind" :)
[+] [-] r00fus|3 years ago|reply
To simplify things down to a single opinion for a population (or even a person) is reductionism.
[1] https://en.wikipedia.org/wiki/Multimodal_distribution
[+] [-] nkozyra|3 years ago|reply
One commenter is just looking at it from the perspective of the market at large and the other uses a niche DAW, looking at its value for personal use.
Even so, if it doesn't catch on more broadly there's a good chance it's not going to last. Hoping it makes it.
[+] [-] Shared404|3 years ago|reply
I'm also curious (if you're comfortable answering), were you involved with "design and implementation contributions by a group of commercial and open source audio developers from across our industry."?
[+] [-] coldtea|3 years ago|reply
Logic has Apple's own AU, wont accept others.
Cubase has Steinberg's own VST, wont accept others.
And Live (which supports both AU and VST) has a "feud" with BitWig (which was started by ex-Ableton staff), so unlikely to accept Clap.
So, what does this leaves us with? BitWig, maybe Studio One, and some even smaller players?
[+] [-] cageface|3 years ago|reply
[+] [-] conradfr|3 years ago|reply
Which is not the small player it seems to be.
[+] [-] omnimus|3 years ago|reply
[+] [-] eating555|3 years ago|reply
[+] [-] jcpst|3 years ago|reply
[+] [-] toma_caliente|3 years ago|reply
[+] [-] collegeburner|3 years ago|reply
It also never got enough support from big guys. Clap looks like it fixes a lot od LV2 stuff as well, and it can replace VST, which is good because VST is a crap technology.
[+] [-] jcelerier|3 years ago|reply
But unlike clap, targetting this also gives direct access to a few other environments, namely Max, Pd, ossia score, with the list hopefully growing.
Here is an example minimal plugin : https://github.com/celtera/avendish/blob/main/examples/Raw/M...
Note that unlike pretty much every other c/c++ plugin API, the plugin code does not need to include any header, everything is done through reflection of struct members at compile-time. This means that it's dead easy to port plugins to e.g. microcontrollers.
Here's a per-sample noise generator which uses a small library of pre-made ports: https://github.com/celtera/avendish/blob/main/examples/Helpe...
And a very naive buffer-based audio filter : https://github.com/celtera/avendish/blob/main/examples/Helpe...
UI is supported without relying on a specific UI library, only on a canvas painter concept which can then target Qt, NanoVG, and others to come: https://github.com/celtera/avendish/blob/main/examples/Helpe...
It does not only support audio but also has an "API-free" gpu abstraction since it's tailored for media arts in general:
https://github.com/celtera/avendish/blob/main/examples/Gpu/D...
since it binds directly to audio APIs at compile time, it has pretty much zero code size in itself, the smallest plugin it generates for VST2 is around 7kb IIRC
[+] [-] atoav|3 years ago|reply
Bitwig does up to audio rate modulations of nearly every parameter, the stock plugins are all really top notch, the way they implemented voice stacking or polyphonic pitchbends for MPE synths etc. are all done in the way I dreamt it should have been done.
It still lacks a bit on the hardcore audio editing and mixing front (e.g. in ProTools you can edit extremely fast, just using the keyboard).
Their pricing and licensing model is fair. The price is actually quite okay given what you get in addition to just the DAW (a really good sample library with all the famous drum machines, a reaktor-like modular stock-plugin for synth, effects and midi manipulation, a powerful live-performance tool, etc.)
[+] [-] ZoomZoomZoom|3 years ago|reply
> As we proceed beyond the initial set of extensions, we are committed to establishing a transparent process to govern the standard which allows participation from the entire audio software community. We welcome participation from the development community today, and we will share details of these processes and governing models over the second half of 2022.
Very vague and doesn't really instil confidence: "Join us now, and months later we'll share how we're going to protect your work."
[+] [-] oidar|3 years ago|reply
[+] [-] duped|3 years ago|reply
It turns out modern CPUs are plenty fast for heavy audio DSP. The point of friction is synchronization and the memory wall, most of the time.
It turns out that audio DSP algorithms don't generally benefit from the same kind of parallelism you get on a GPU, since even the basic stuff you'd like to do (filtering, algorithmic reverb, etc) is a bunch of recursive/sequential algorithms that have a non-trivial cost to convert to a parallel form for SIMD evaluation, and the gains are not linear due to repeated computation (classic example, converting an exponential moving average which is used everywhere to N lanes of SIMD is a lot less than an N times speed up).
That's not to say there isn't exciting work being done (GPU audio, for example). It's just really hard and not a magic bullet. It's not an Audio Processing Unit, after all. It also has video output, but not high fidelity audio i/o.
[+] [-] digitalslr|3 years ago|reply
Processing audio on a GPU is a lower level issue than a plugin standard which describes the interface between the DAW and the plugin (how audio, parameters, notes, modulation data, etc. are exchanged).
[+] [-] pier25|3 years ago|reply
They did this demo at NAMM recently:
https://www.youtube.com/watch?v=IFdgymosszA
[+] [-] agrover|3 years ago|reply
[+] [-] shams93|3 years ago|reply
[+] [-] stevehiehn|3 years ago|reply
.. Sorry, I'll see myself out
[+] [-] somishere|3 years ago|reply
[+] [-] stereocodes|3 years ago|reply
[+] [-] mobiuscog|3 years ago|reply
[+] [-] pixelatedindex|3 years ago|reply
[+] [-] yots|3 years ago|reply
[1] https://www.routledge.com/Designing-Audio-Effect-Plugins-in-...
[+] [-] PaulDavisThe1st|3 years ago|reply
How plugins do DSP?
The basics of most plugin APIs?
How plugin APIs differ from each other?
How the host(s) see plugin APIs?
What the difference is for user between the different APIs?
How do people actually create audio plugins?
[+] [-] jay-anderson|3 years ago|reply
[+] [-] justinclift|3 years ago|reply
It's a pita with the current situation, where everything past ~7.1 audio channels is proprietary and needs extremely expensive hardware (eg decoders) just to direct the audio to the correct speakers. :(
[+] [-] PaulDavisThe1st|3 years ago|reply
[+] [-] yellowapple|3 years ago|reply
[+] [-] atoav|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] kookamamie|3 years ago|reply
A terrible name that'll just look stupid in a couple of years from now.
[+] [-] switch007|3 years ago|reply