In case you missed it in comments, amidst the news of a major pro sampling product being discontinued, reader Darren Landrum is interested in offering a free/GPL open source framework for samplers:

The LinuxSampler project offers GigaSampler 3 compatibility for Linux and Windows, so it’s already an open alternative for dealing with your orphaned Giga sampler files. (Naturally, you could also look to a number of Giga-compatibility samplers on the market.)

But the open source community has long been under fire — often rightly so — for simply copying proprietary software rather than doing something new and innovative. I enjoy "new and powerful," so that sounds like a great idea, and that’s what Darren is proposing. He writes:

What I want to do is build a code framework (not to be confused with a library) that will contain classes for handling streaming sample playback, resampling, and all that fun stuff, as well as directed graph building for DSP. From here, the framework can be used to build monolithic applications for sampling and synthesis, as well as a Reaktor-like application, if we do it right.

Yes, it would be better to split things out into libraries, but that takes a lot more work, and I’m tired of things not happening. The sooner we can get some code working, the better.

I should also mention that there are existing open source libraries we can and will leverage, like libsndfile, libsamplerate, libfftw3, and the Rubber Band library, so we won’t be starting completely from scratch.

This sounds terrific to me — not necessarily as a replacement for existing, proprietary tools, but as a framework on which new tools could be built. There are research and compositional projects that could absolutely benefit from the existence of such a library. And having this tool as an option could strengthen computer music platforms in general. (In other words, wherever you stand in terms of open source and philosophy, it could be a good thing. Hey, I’m happy all around — I couldn’t live, basically, without both systems.)

But enough theory — the idea needs developers and real code, so it’s not just an idea.

If you’re a developer, do get in touch. I’m happy to help host and support any such work in any way we can via CDM. Darren is on gmail as dmlandrum, or leave a comment here.

By the way, happy OSCON day.

Image: jagelado. (Interestingly, since the creation of that image, Microsoft has come to make more use of open source — you can argue about the reasons, but not the effect.)

  • Darren Landrum

    Wow, and to think I was worried about spamming your comments. 🙂 Thanks for the call-out, Peter.

    I would like to make it clear that I am no great coder. I am simply an overenthusiastic guy who really wants to see something great happen. My view us that synthesis and sampling in the Open Source world has, at best, been underwhelming, and I think the discontinuing of GS3 and 4 from Tascam is just the opportunity we need to breathe new life into Open Source synthesis and sampling.

  • Hey Darren, I might be interested in a project like this. I'm the author of a couple VSTs (Mopis and Pondular), plus about a trillion boring, non-audio projects. Hit me up at kevin (at) nethernet (dot) com– if nothing else I'd like to discuss your ideas in more detail.

  • smurfette

    Want Tascam to open source Giga? A petition isn't the answer. We need to come up with a dollars and sense reason to release millions of dollars in development for free — a reason that a Japanese accountant will understand.

    That seems to have a better chance of success than an open source project starting almost from scratch.

  • Darren Landrum

    There is an issue, apparently, with Tascam owning a patent on "disk streaming of samples" which will put the kibosh on both an open source solution and getting them to open source their application. They give out patents for any old shit these days, don't they?

    I might have to look up this patent to see if I can find a way around it. LinuxSampler gets around it by the developers being in Germany. I don't have that luxury.

  • gwenhwyfaer

    Don't look up the patent! Wilful infringement incurs triple damages under US law – much better to claim ignorance! There are plenty of us who aren't based in territories covered by US law, who could have a look at the patent and tell you what techniques are, er, not worth pursuing. 🙂

    On the other hand, given a 64-bit processor and a sufficiently fast disk system, the naive approach of just mmap()ing samples and letting the Linux kernel look after the details might be the quickest way to get off the ground – if just to see how far off the optimum it really performs…

  • Darren Landrum

    I'd rather not infringe at all if I can help it. There might be no getting around. Besides, the fact that I know there is a patent is enough to claim willful infringement.

    The sampler side of this project might be dead already, unless Tascam is willing to be nice, but everything else can proceed. The other option is possibly using a different technique to stream samples. In the patent office's usual overreach, though, I have a feeling we're dealing with an algorithm patent that simply states "all on-demand disk streaming, no matter the implementation."

    And for that, I need to go look it up. Not tonight, though. I have enough of a headache as it is.

  • Downpressor

    Somehow this re-enforces the stereotype of OSS as a world of carrion feeders and scavengers. Oh well, even dung beetles have a place in the biosphere.

  • Sorry, I don't think we're saying open source GigaStudio. As I said elsewhere, I doubt that that would be an easy thing to do with licensing / ownership issues. This is "life after Giga" in that I think the music software world will be a healthier one if it continues to develop a balance of open and closed code; that's what we've always been committed to on the CDMs.

    No, the idea here is to build a basic set of sampling frameworks from *scratch*. And there's no reason to copy Giga — not with other options like Kontakt, MachFive, Dimension, HALion etc., etc. I think open source projects could have other benefits. And they should make development easy. I think even if you're hard core about the "freedom" aspect of free software, there's no harm in something being useful. 😉

    I don't imagine a patent covering samples being streamed from disk as being very successful. See: almost every digital audio app ever made. If there's a specific technique that Tascam is using, that's another matter; I would avoid anything that resembles Giga. Anyway, any new application is likely to make greater use of RAM. Disk performance isn't increasing nearly as quickly as RAM, and it's totally possible to target Mac, Windows, and Linux 64-bit for 128G of accessible RAM.

    @Downpressor: I don't think Darren or the CDM readership claim to speak for "the OSS world." We're just users and casual programmers, and most of us also live with and pay for proprietary software.

  • bliss

    As PK said, just avoid disk streaming and go for 64-bit memory addressing. That sounds like the way forward.

  • Downpressor, did you have anything interesting to contribute, or are you just today's friendly neighbourhood "open sores" troll?

  • Johnny Horizon

    @Downpressor: OSS == DIY. Would you make the same remarks about the people who build their own stompboxes and share the schematics, etc.?

  • Peter Dines

    From here, the framework can be used to build monolithic applications for sampling and synthesis, as well as a Reaktor-like application, if we do it right.

    What would be exciting is if this framework could be used as a front end (both a performance view and a design view) for the Pure Data engine and objects. PD is already great but its GUI could use a bit of polish. It's one of the healthiest open source audio projects, IMHO – frequent releases, stable, tons of functionality, lots of user activity. That's the one you want to leverage if you want to take this in a Reaktor-y direction.

  • Darren Landrum

    I actually have another bone to pick with the open source world about how poorly interface design is treated. Csound is regarded as an extremely powerful synthesis environment, and it is. However, it took me 10 days of pouring over tutorials to finally get a sound that takes me 30 seconds of knob-twiddling in most other software synthesizers.

    Now imagine if we could place a point-and-click graphing interface on top of Csound. Reaktor's GUI is not pointless eye candy. It is a very carefully designed and functional interface that makes programming DSP algorithms a lot easier. It makes a huge difference to see a line drawn from one node to another, as opposed to trying to track down every instance of a variable name.

    Now imagine if you had an EQ plugin, that required you to type your desired EQ settings into a text file to be loaded in by the plugin on start-up. That's the way many Linux developers advocate interfaces to be designed. Granted, it's an exaggerated example, but I hope you see the point.

  • Darren, there have been various projects to provide graphical front ends to Csound. Csound is a special case, too, in that its origins pre-date graphical user interfaces (literally). That also means that the user base is a self-selecting group; i.e., heavily biased toward people working that way.

    I do agree in terms of open source projects in general. You know, they tend to be created by developers for other developers. And creating UIs has tended to be really time-consuming in the past. I would say code *is* a user interface, and actually some of those are very good (like the code-based Processing, for instance).

    But I do think there are reasons to suspect this situation could improve. UI development in general is easier now than it has been in the past. And it's also becoming more important to people. And at the same time, the OSS world is becoming increasingly interested in evangelizing their tools to people outside their immediate circle.

    And most important would be real designers joining the teams doing open development. It's not just about being pretty, as you say — great design is more functional. But you need great designers.

  • Pingback: Create Digital Music » Open Source GigaStudio Petition: Why It’s Unlikely()

  • Darren, approximately 10 years ago next month, I started work on "put a GUI on top of CSound". There are lots of reasons why I'm not doing that anymore. Other people have made it possible to provide FLTK-based GUIs for CSound instruments, but you are not going to succeed at turning CSound into Reaktor, or anything even close to it.

    Being a relative newcomer to the world of developing open source audio applications is both dangerous and heady. Dangerous because you don't see the way in which your goals have been shared by many people who came before you, and thus you don't spend time figuring out why those goals haven't yet been realized – instead you spend it rediscovering a bunch of stuff that has already been discovered. But its also heady because frankly, some of us have been doing this stuff for a bit too long, and its good to get some viewpoints in the mix that don't pay attention to what us olduns say is right, possible and appropriate.

    What you are hoping for is extraordinarily ambitious. You will not accomplish it without extraordinarily good programmers with a huge amount of time on their hands. As was noted earlier – far better IMO to focus on some existing cool tools (PureData being the obvious example) and figure out how to add what you want. Making a really good sample playback engine has way, way more to do with GUIs than with internal engine stuff. Doing so with PD is hard. But doing it from scratch is even harder. LinuxSampler could use some love and would save you from naively reinventing everything. Or maybe you should really strike out for the lodestone once more. Just keep in mind that you are the not the first to try, and nobody has come back holding the prize in their hands …

    Peter – I can't name names, alas, but I feel compelled to comment that (at least) one of the sample library companies you named as having their own sample playback engine originally mumbled about doing it open source. They failed to follow through for a variety of reasons, none of them technical and most of them, IMO, rather cowardly. Most of these companies do not understand open source at a level where they are qualified to assess how it could help or hinder their products, let alone their users.

  • Darren Landrum

    @Paul: It's very interesting that you bring up the point about the GUIs, as that's what I've been trying to say all along.

    I know what I'm trying to do is ambitious, and I do find it very interesting that everyone who has tried so far has failed. However, I'd like to point out that a number of single-man softsynth projects happen on the Windows side, that result in very usable software. Vember Audio and his Shortcircuit sampler is a one-man job, and is a very thorough and usable piece of software. Schwa's own Olga synthesizer is one of the single best-sounding softsynths I have ever heard. He did the entire engine, and the GUI graphics were another fellow, so a two-man job at most.

    Why are all of these one- and two-man teams cranking out such great synths and samplers on the Windows side? Is Linux really that much harder to develop for? I was hanging out in an IRC channel with Schwa when he developed Olga, and I can tell you for fact that the entire development cycle took him about three months, and that was with a day job. How come he can do it and we can't?

    I'm sorry, Paul. I have a great deal of respect for you as a developer, but I think you're wrong. I think it can be done, and that some new blood and a new approach is what's needed.

  • @Paul: Ah, interesting. I'm not making excuses for them on open source. It's just I can't imagine GigaStudio as a first choice. Maybe I'll be lucky and me ranting about how it's not going to happen will *challenge* them to prove me wrong.

    Yeah. You hear that, Tascam? If you open source GigaStudio, I'll have to *eat* one of my PCI cards.

    In all seriousness, Paul, the point of the post is an open thread — and it's perfectly reasonable for someone who does have the experience you do to say, hey, be careful not to reinvent the wheel, and take the dangers seriously. I think that can have benefit; hopefully it wouldn't dissuade people from trying something but instead would dissuade them from making a hard task harder than it needs to be / harder than they can manage.

    I do see part of this a bit differently in that I would like to see the tooling made easier. That is, it'd be great if there were better frameworks out there for doing simple audio development — not along the lines of Ardour, but if people want to, say, create a really simple sampling application. Pd, of course, is one excellent example of how to that for a certain kind of development. ChucK is another. Certainly, one promising route would be to extend these. Heck, what got described here could be implemented as a series of Pd patches.

    I would also like to see things like the Java platform, etc., take similar steps, or see continued development of underlying C++ frameworks and the like. It's going to take a long, long time, but there's already progress on things like the OpenJDK. I know we're talking about radically different projects here (OpenJDK, for instance, won't really let you build a Java-native GigaStudio or Ardour), but these are all pieces of the puzzle.

    And love it as I do, I don't see any reason to reinvent Reaktor, either.

  • @Darren, Olga looks impressive. Keep in mind that what it does is substantially simpler than handling Gig files as a sampler.

    Look, I know the two guys that "unnamed sample library" vendor hired (instead of me) to do their proprietary sampler. Both really smart guys, with existing experience at some well known audio s/w companies just before. It took them about 3 months to get 80% of the work done. Two years later, the thing is still not entirely finished. The 80/20 rule is in full force for projects like this. BTW, that wasn't for Linux, that was for Windows. The platform is not really an issue. A bigger issue is that most OSS developers do not expect to be able to make much money from their efforts. The motivation to work as hard as I imagine Schwa did on Olga goes down quite a bit under those conditions, though I also doubt that he makes much on it either. Almost nobody makes much money on audio s/w unless your name is Abelton or Waves 🙂

    Shortcircuit looks a lot closer to what you're imagining on the sampling side but I still wonder how it handles all the nuances of Gig files. Articulations, layering, and lots more. LinuxSampler had all this years ago, sort of, and its still "not quite there". Why? I am not entirely sure. But I think its very important to have a good answer to that question before starting over again.

    Finally, I would note the danger in trying to hit that sweet spot between modularity (e.g. Reaktor, Max, PD, CSound) and button-pressing new hottness. You will notice that nobody has really built any blindingly good samplers from Max or PD or Reaktor or CSound. I think its very likely that nobody will ever do this, no matter what the "generic" framework is. Its not because its technically impossible or even hard – its because its difficult to use tools designed to give a "sound designer" a lot of control and use them to produce something that gives users a lot of push-button convenience. Things like ChucK are amazingly powerful, but really not where you would start to reimplement Giga/Kontakt/Halion-like function. So I'd be careful of your dreams of assembling a "toolkit" of powerful components. It will be powerful, and useful and fun, but in all likelihood it won't be capable of being the basis for the kinds of software that so many musicians have come to expect and rely on. Not because its bad or weak or anything like that – its just a different paradigm.

    @Peter: that last paragraph was aimed at you too 🙂

    Finally, I'd like to note that my role in every organization I've ever been a part of (only the ones that refused to have me as a member, naturally 🙂 has been to verbalize and rant about why the goals are not attainable. Its been very successful to date at getting other people to take my concerns into account and go ahead and get stuff done in spite (or perhaps because of) my vocal skepticism. I don't intend to pour cold water on anyone's dreams. I just want to remind people that they are rarely the first to have those dreams, and its a good idea to figure out why earlier dreamers have fallen short before showing me what an old fart i really am.

  • @Paul, I don't disagree … I didn't think that was necessarily the goal. It depends on what you want as a sampler. The Ableton co-founders (and others) started out making Reaktor and Max patches, and wound up with Live. And it's still not a sampler (it has a sampler in it, called Sampler, but … you know what I mean). Likewise, in fact, quite a few people continue to build sampler-like stuff in Pd, Max, Reaktor, et al. Some are indeed blindingly good — they just serve a different function than, say, Kontakt.

    Now, the code framework described here is far more ambitious. I don't think it's impossible — actually, I think part of what's interesting about it is that you wouldn't even try to build the UI, etc., you'd just do some of the guts. It's far more ambitious than anything I would try to work on, but it's an interesting idea. And as you say, there's also no harm in evaluating what's been done before, whether it makes more sense to contribute to existing projects, whether it's beyond the means, etc.

    But I think there is a strong argument to be made for doing a simple set of Pd patches … given that we already have things like Kontakt, I'd say doing something simple and different could be both a more realistic and a more productive use of time.

  • Downpressor

    Johnny Horizon,

    I dont disagree with you, but in my limited experience guys who build their own stompboxes have always been seeking something unique rather than just trying to replicate the successes of the commercial world. YMMV.

  • Darren Landrum

    The framework I propose is just to give a base point for the development of other apps. It would contain things like classes for interfacing with JACK for audio and MIDI, the ability to process DSP graphs, and a few other things. It's not going to be a final app unto itself. Rather, it would provide things every synth or sampler app would need in a way that I feel makes sense. One of the guys I'm working with already has a JACK audio and MIDI class written, and he's testing it now. I'm currently working out the digraph one.

    I also wish people would stop assuming that just because my inflamed sense of self coincides with this whole GigaStudio fiasco, that all I want to do is clone it. I have many idea of my own for a sampling workstation that bear no resemblance to anything on the market. Whether they're any good or not remains to be seen, but hey, it's worth a try. I sent a link to Peter something I had written on one of my main ideas, though I did ask him to keep it under his hat for now. I'll email you a link to it, if you'd like, Paul, as I know I can count on some good feedback from you. 😉

    There are other ways of approaching the same problem, to achieve interesting results.

    And you're right, Olga is much smaller in scope than a huge sampling workstation, but it pains me to say that nothing on Linux comes even close to sounding as good as it does. I want to solve that.

  • Downpressor, exactly. My point was just to prompt discussion — the simple fact is, open source software tends to have a longer life cycle than proprietary software. (That CAN be an advantage of proprietary software for some things; it's why I think often you have a balance.) So, in other words, this was an appropriate jumping off point for a separate discussion.

    The open source software I know and use isn't simply copying proprietary software. If it were, I wouldn't be using it. OSes are a bad example, because there's so much that people ask of an OS — Mac, Windows, Linux, etc. are constantly accusing each other of copying, but that could also simply be responding to user needs. In music and audio, what I've seen from open source is very much distinct from what the proprietary software is doing. End of story.


    I made the connection here, so to whatever extent I muddied the waters by doing that, sorry.

    But then, the point here was we have a choice:

    * hope that a petition convinces a big corporation to open source a giant, app OR

    * build some simple frameworks that would make these things easier to develop

    Might the simple frameworks issue become much harder than people expect? Might you wind up with something *nothing* like Giga? Might it be something idiosyncratic and unrelated to commercial products? Absolutely. I think that's a really good thing.

  • Downpressor


    Fair `nuff.

  • Joel Hamburger

    It's always nice to see level headed discussion about open source projects.

    Though gigastudio is on the scrap heap, I doubt that tascam will be willing to forgo the fee for salvage. It's clear that they have a significant investment in the IP.

    I assume there are companies that are considering taking up the gigastudio mantle. They will probably be doing the same market analysis that Tascam is doing and will likely come to a similar conclusion, it's not very viable. However, there is another option.

    How about forming a cooperative which will attempt to raise the necessary funds to purchase the IP. Once the cooperative owns the code they would be free to make it open source as they wish.

    Rather than a petition for Tascam to give the software away we should start collecting pledges from putative coop members. A solid goal would be to gather 2000 $100 pledges. Though 200k is not a huge number it would be enough of start to be taken seriously by Tascam.

    At the very least make tascam and or other developers realize that there still is a small market for the product.

    If the co-op actually succeeds in raising capital and purchasing the IP there are a number of possible business models that could lead to sustainable development support and maintenance of the product.

    Ideally, the coop members would pledge with the full understanding that the resulting product would be open source. This would make the product essentially donation/shareware. I do think that there are enough professional users who would be willing to risk $100-$500 just for a reasonable chance to not have to port libraries !

    Once the code is open sourced, development could continue in the "usual" open source manner. However it would be wise to use the cooperative funding model to leverage the existing knowledge base, i.e. hire members of the current product team ( I believe there are a half dozen or so coders).

    A knowledgeable product manager could then designate which tasks code be handled by the existing coders and which could be crowd sourced.

    Testing and bug reporting would be handled by the coop members. Once a stable release is generated feature requests could accumulated and ranked. Another round of funding could then be raised for the next version.

    It's obvious that Tascam did not feel that there was enough of a commercial market to warrant the continued development and and support costs.

    With a cooperative open source model I think gigastudio could at least be sustained for the next 5-10 years. If something like this actually worked it might be possible to expand the product along the lines discussed above.

    If there is any interest in this idea I'd be more than happy to work on it.

    joel [ATTTT] godelstring [DOOT] com

  • Darren Landrum

    Here's the problem as I see it:

    The core technology of GigaStudio is that patent on on-demand sample streaming from disk. It's a real possibility that all of the other commercial samplers on the market license that patent. That makes the patent worth a lot more than the product.

    If they do release the product open source, it will be minus the code that the patent covers, at the very least. That would leave you with a neutered product. Creating your own streaming sample code then becomes a patent violation. This ends up leaving you in the same boat that I'm in.

    Because it's the patent that's worth the real money, getting them to sell that to a bunch of open sourcers will be a chore, and incredibly expensive, assuming they don't just laugh us out of the metaphorical room.

    Now, it could be I'm wrong, and that there is a way around these issues, and other companies have found it. But for now, I think it's best to assume the worst possible scenario until we know more.

    Personally, I'm looking to use 64-bit addressing and letting people really load up the RAM. I've also thought about seeing if I can get a version of FLAC that works on 24-bit waves, to save memory. These are just off-hand ideas for now, though.

  • Darren, I don't personally believe that the patent will stand if challenged in court. Pre-caching is a common OS technique, and in fact on *nix-style OS'es, you get about 50% of what their patent describes just by reading from the file. That is, the OS reads more than you asked for into a "buffer cache" and the next time you read it, its already in RAM and ready to be fetched very rapidly. The amount that is "read-ahead" is somewhat configurable, but not quite enough or as precisely as one would want get giga-like behaviour. There also appears to be some precedents for the patent that may or may not provide clear prior art.

    Another way to look at this is that Halion was developed after the giga patent was taken out. I am about 98% certain that Steinberg did not license the patent, and did not feel under any threat of a lawsuit (based on personal communication with Steinberg employees).

  • Darren Landrum

    In all honesty, I'm not too worried about it. I'm sure an option will present itself by the time I get that far. There's plenty to do between here and there. 🙂

  • Vladimir Senkov


    Linuxsampler doesn't get around anything and not all developers are in Germany. Linuxsampler is based "prior art" to any of those patents and I believe this is why it wasn't sued by Tascam. Although, of course, anyone can sue anybody these days for just about any reason. Btw, not looking up the patent isn't going to make you infringement less willful 🙂

    I'm not sure i understood your point about opensource simply copying commercial software. Surely you aren't talking about copying as in stealing code, are you?

    If you are talking about implementing compatible software then i must protest. If nobody implemented open software that does essentially the same thing that closed software did, having the similar form-fit-function, e.g. opening the same file formats, etc. then there would not be many users of open software. I use open software but i must interact with others who do not all use open software. It would be difficult for me to work in the office w/o an openoffice, for example. So there is nothing "uncool" about implementing something that already exists, especially if you can do it better.

    You are essentially saying that you would do something different implying that it doesn't already exist. Why are you so sure that it does not? How well did you do your research? If so, does it not exist because there isn't much of a demand for it or because it's impossible to implement properly?

  • Darren Landrum

    @Vladimir: You're right, of course, and my apologies. My contact with the LinuxSampler group has been through Benno and Christian, who are both in Germany.

    However, I'm not the one who was accusing open source software of stealing from the commercial world. I did make the point, though, that I do have a few original ideas of my own concerning the overall design for a sampler. These ideas will apply for other types of music software as well, I think. I don't want to give too many details just yet, because I want to flesh out ideas and run them past people I trust first. I actually agree with you about implementing popular functionality and open file formats.

    I've also been called worse things than a dung beetle. 🙂