The Open Movie Projects use Open software for soundtrack!?!

Discussions and feedback around the Open Projects such as Orange (Elephants Dream), Peach (Big Buck Bunny), Apricot (Yo Frankie!)...

Moderators: jesterKing, stiv

roos
Posts: 7
Joined: Tue Aug 25, 2009 8:43 pm

The Open Movie Projects use Open software for soundtrack!?!

Postby roos » Tue Aug 25, 2009 8:56 pm

Hi,

Great projects those Open Movie Projects. One thing surprised me a bit though. The makers of the soundtracks for the projects seems to use proprietary software :/

And there are so many great tools out there:

- Ardour (www.ardour.org) (you can use Qjadeo for Video, and there is even a videotrack in progress)
- Linuxsampler (http://www.linuxsampler.org/)
- openoctave (http://www.openoctave.org/)

And if I'm right the makers of the soundtracks also uses some audio synthesis environments. And also in this area are a lot of Open Source alternatives:
http://en.wikipedia.org/wiki/Comparison ... vironments

If you're a supporter of Open Source software you should not only use it for the 3d stuff but also for the music. At the end the Open Source community will benefit from it and also Blender and Open Source artists.

What do you think?

ton
Site Admin
Posts: 525
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Postby ton » Wed Aug 26, 2009 10:16 am

I'd really welcome ways to cooperate with other OS projects, like for sound or music editing. There's a couple of issues here though;

First: it's about the artist, not the tool... and music professionals, with industry quality film score portfolios who use open source, I didn't meet yet.
The musicians I talk to confirm that most OS tools - compared to commercial ones - are in an infancy stage still. Especially sample libraries seem to be a problem as well.

Obviously this is a great opportunity for Open Source communities! The development model we use for Blender is really possible to copy.
But! Why expect Blender Foundation to organize this, or expect from Blender users to finance this?

Our team can only do this for Blender because we all know this program into every detail, know exactly where problems are and how to tackle it, and our artists know perfectly what to demand, or how to bypass topics, and how to take it all into a production.

This implies that a group of sound/audio OS projects could join efforts, find a couple of great musicians who love open source, and get (pay, inspire) them to make a full new soundtrack and chore for Durian, while supporting and respecting their feature requirements and quality demands.

I'd be very happy to align this with our project, and even to include it on our dvd and websites when it's done, but I'm extremely hesitant to include this as a target our project plan... music/sound is not our bizz, and having professional quality support from Wavemange will help the 3D side of our project best now. Doing this is already extremely risky you know, let's keep it a little bit feasible too! :)

Jan Morgenstern
Posts: 9
Joined: Sat Nov 03, 2007 6:12 pm

Postby Jan Morgenstern » Wed Aug 26, 2009 10:50 am

This subject (understandably) seems to come up during every open movie project, so I thought I'd share my point of view. One thing I'd like to make clear is that I'm in no way indifferent to the advancement of free software in the audio realm; quite the opposite. I'm constantly evaluating most of the more ambitious projects, and a few of them have made it into my daily workflow. I'm also willing to embrace any realistic idea how I could actively help things move. That being said, I think you're overestimating my possibilities here.

One misconception that I think people tend to have is that Ton and his crew would set out to create a movie, with the improvement of the software being a welcome and free side effect of the process. It's the other way around: With the help of filmmakers, they're putting Blender under a massive and very targeted field test; the side effect is that this process also spawns a movie. This approach works for a number of reasons:

1. At the launch of a new project, Blender is already *almost* good enough to satisfy all needs of the production crew. There are some key features that need development, and the style of the project is tailored towards these; but more importantly, Blender already provides a solid environment for getting the everyday tasks done that make up 95% of the work.

2. For the entire course of the production, several of Blender's head developers are working paid and full-time alongside the filmmakers, their job being to make sure that any problem the crew runs into gets addressed promptly and thoroughly so that the production won't get stalled.

3. The person being in charge of the production is also Blender's maintainer, which means that new ideas and changes don't necessarily need to pass community approval processes, lengthy debates on developer mailing lists, or any of the other decision making aspects that are customary in larger free software projects.

If you think about it, none of these points apply to any free software I could be using. And if you look at the available projects pragmatically and without an ideological bias, you'll notice that most of them are still a far cry from their established commercial counterparts. I don't mean any disrespect to their developers, mind you; quite the contrary. But creating film music "in the box" with modern means – which typically encompasses hundreds of mixed MIDI and audio tracks, resource-hungry software samplers, terabytes of samples, distributed network processing, shellproof video sync, and DSP-heavy signal flows rivalling those of large scoring stages – routinely pushes even the most advanced commercial software to the brink of collapse. I'm all for not giving up and continuing to reach for the sky, but at times (precisely, when tight budgets and deadlines are involved) one has to be pragmatic and acknowledge that there's no Blender for audio yet.

My point is that with the open movies being entirely targeted at improving Blender, and the music and audio post pro merely being an aspect required to get a "complete" movie in the process, I don't see a viable way for me to partake in open source development on the same scale as Ton and the core crew do; at least not without making a terrible lot of compromises, which would neither do my role in the project, nor your or my own quality demands, nor the involved software projects any justice. I think this last point needs to be stressed: There's absolutely no benefit whatsoever in dragging an application kicking and screaming through a production scenario it's not even remotely prepared for.

I *will* try to incorporate free projects like Audacity, FLAC, sox et al into my workflow where it makes sense (as I did in ED and BBB, by the way), but don't expect me to attempt to migrate the fundamental work to, say, Ardour – that would be an academic exercise at best.

roos
Posts: 7
Joined: Tue Aug 25, 2009 8:43 pm

Postby roos » Wed Aug 26, 2009 2:01 pm

ton wrote:I'd really welcome ways to cooperate with other OS projects, like for sound or music editing.

Thanks for your reply
There's a couple of issues here though;

First: it's about the artist, not the tool... and music professionals, with industry quality film score portfolios who use open source, I didn't meet yet.

That's a good question which I have no answer for yet. I have posted the question to the Linux audio community.
The other question is whether Jan can/ want to do his job with open source tools (see later in answer).
The musicians I talk to confirm that most OS tools - compared to commercial ones - are in an infancy stage still. Especially sample libraries seem to be a problem as well.
Imo Ardour has reached a pretty grown up status. And for the sample libraries I think LinuxSampler is a good application.

Obviously this is a great opportunity for Open Source communities! The development model we use for Blender is really possible to copy.
But! Why expect Blender Foundation to organize this, or expect from Blender users to finance this?

Our team can only do this for Blender because we all know this program into every detail, know exactly where problems are and how to tackle it, and our artists know perfectly what to demand, or how to bypass topics, and how to take it all into a production.

This implies that a group of sound/audio OS projects could join efforts, find a couple of great musicians who love open source, and get (pay, inspire) them to make a full new soundtrack and chore for Durian, while supporting and respecting their feature requirements and quality demands.


I agree with you and I think its a good idea you point out.



Jan Morgenstern wrote:This subject (understandably) seems to come up during every open movie project, so I thought I'd share my point of view.


Thanks for that!
One thing I'd like to make clear is that I'm in no way indifferent to the advancement of free software in the audio realm; quite the opposite. I'm constantly evaluating most of the more ambitious projects, and a few of them have made it into my daily workflow. I'm also willing to embrace any realistic idea how I could actively help things move. That being said, I think you're overestimating my possibilities here.

One misconception that I think people tend to have is that Ton and his crew would set out to create a movie, with the improvement of the software being a welcome and free side effect of the process. It's the other way around: With the help of filmmakers, they're putting Blender under a massive and very targeted field test; the side effect is that this process also spawns a movie. This approach works for a number of reasons:

If you think about it, none of these points apply to any free software I could be using. And if you look at the available projects pragmatically and without an ideological bias, you'll notice that most of them are still a far cry from their established commercial counterparts. I don't mean any disrespect to their developers, mind you; quite the contrary. But creating film music "in the box" with modern means – which typically encompasses hundreds of mixed MIDI and audio tracks, resource-hungry software samplers, terabytes of samples, distributed network processing, shellproof video sync, and DSP-heavy signal flows rivalling those of large scoring stages – routinely pushes even the most advanced commercial software to the brink of collapse. I'm all for not giving up and continuing to reach for the sky, but at times (precisely, when tight budgets and deadlines are involved) one has to be pragmatic and acknowledge that there's no Blender for audio yet.

My point is that with the open movies being entirely targeted at improving Blender, and the music and audio post pro merely being an aspect required to get a "complete" movie in the process, I don't see a viable way for me to partake in open source development on the same scale as Ton and the core crew do; at least not without making a terrible lot of compromises, which would neither do my role in the project, nor your or my own quality demands, nor the involved software projects any justice. I think this last point needs to be stressed: There's absolutely no benefit whatsoever in dragging an application kicking and screaming through a production scenario it's not even remotely prepared for.

I *will* try to incorporate free projects like Audacity, FLAC, sox et al into my workflow where it makes sense (as I did in ED and BBB, by the way), but don't expect me to attempt to migrate the fundamental work to, say, Ardour – that would be an academic exercise at best.


I think you're right when you say that you can't do for audio tools what Ton is doing for Blender. I totally understand this.

The question is whether you are right when you say that there is no Blender for audio yet or if it is not possible to make a quality soundtrack with the OpenSource tools and OpenSource operating systems. Maybe it is possible if you get help from experts on this area.

But I'm not gonna answer these questions, I don't consider myself as a real expert on this. I would be nice to see what the devs of Ardour/Linuxsampler/... etc think of this. And maybe there are artists who agree or disagree with you.

I hope some of that people join the discussion and if the discussion will be fruitful/reasonable.

Thanks

zettberlin
Posts: 1
Joined: Wed Aug 26, 2009 3:17 pm
Location: Berlin/Germ

Postby zettberlin » Wed Aug 26, 2009 3:29 pm

Jan Morgenstern wrote:...to migrate the fundamental work to, say, Ardour – that would be an academic exercise at best.


I agree. And I will try to make such an exercise.

A friend of mine is a film director who has studied his trade in Potsdam Babelsberg (dont know if he was involved in Basterds though ;-) )
He gave me some interesting tipps regarding the free software I use from his filmmaker point of view. I can say, that he is rather positively suprised about tools like Openmovieeditor, Cinelerra and he is quite impressed with Ardour as a post-production tool.

Of course we all know, that Ardour and its comrades do not allow a workflow, that is needed for commercial feature films. But I believe, that it enabeles talented enthusiasts willing to spend enough time and care to achieve perfectly professional results.

best regs

HZN/berlin
get the details at http://lapoc.de

Jan Morgenstern
Posts: 9
Joined: Sat Nov 03, 2007 6:12 pm

Postby Jan Morgenstern » Wed Aug 26, 2009 3:34 pm

roos wrote:Imo Ardour has reached a pretty grown up status. And for the sample libraries I think LinuxSampler is a good application.


I agree that Ardour is very promising. However, there's still a lot of work to do before it becomes usable as an industrial-strength post production solution, let alone a viable film scoring tool. For starters, there's still no MIDI support, the automation system is rather basic, multichannel support is very rudimentary and (in my opinion) not viable for a real-world 5.1 production yet, AU support seems iffy, there's little in the way of destructive editing and no processing stack, no support for continuous tempo changes, no region aliases, and documentation is patchy at best. I know some of these points will be addressed in the upcoming 3.0 version, but experience suggests that those new features will take some time until they're in a state you'd rely a film production on.

As for LinuxSampler, the sad fact is that virtually all state-of-the-art libraries come either in Kontakt format or embedded into proprietary player engines. Libraries that LinuxSampler can read (namely, GigaStudio and Akai) are getting more ancient by the minute, as sampling technology is leaping forward at a break-neck speed right now. Make no mistake: I thoroughly hate the fact that every sample developer out there has switched to marrying his content to a certain piece of software, and I'd love to see LinuxSampler succeed anyway (after all, there are lots of uses for samplers besides playing commercial libraries, especially in electronica). For the time being, though, I have to go with the flow, as falling back to old libraries would be a massive step backwards for me.

Now, I have a hard time writing stuff like that, as it tends to seem as if I wanted to belittle the efforts of the developers. Nothing could be further from the truth, they have my utmost respect for creating what they did, and I'm pretty excited about the prospect of having an actual, viable open source replacement for my setup in the future. Then again, I feel that careless statements that a certain piece of software would be ready for a certain task, frequently made by people who don't really know what this task _exactly_ encompasses (not directed at you personally) not only do the software in question a disservice, but also put people like me in a defense position.

Seablade
Posts: 3
Joined: Thu Aug 27, 2009 7:26 am

Postby Seablade » Thu Aug 27, 2009 7:32 am

Jan Morgenstern wrote:Now, I have a hard time writing stuff like that, as it tends to seem as if I wanted to belittle the efforts of the developers. Nothing could be further from the truth, they have my utmost respect for creating what they did, and I'm pretty excited about the prospect of having an actual, viable open source replacement for my setup in the future.


Heh as I told you before, I don't think that the developers of Ardour, at least, take it like that anyways;)

Then again, I feel that careless statements that a certain piece of software would be ready for a certain task, frequently made by people who don't really know what this task _exactly_ encompasses (not directed at you personally) not only do the software in question a disservice, but also put people like me in a defense position.


And this I do agree with.

Seablade

alexstone
Posts: 4
Joined: Thu Aug 27, 2009 10:15 am

Postby alexstone » Thu Aug 27, 2009 10:59 am

Jan Morgenstern wrote:
roos wrote:Imo Ardour has reached a pretty grown up status. And for the sample libraries I think LinuxSampler is a good application.


I agree that Ardour is very promising. However, there's still a lot of work to do before it becomes usable as an industrial-strength post production solution, let alone a viable film scoring tool. For starters, there's still no MIDI support, the automation system is rather basic, multichannel support is very rudimentary and (in my opinion) not viable for a real-world 5.1 production yet, AU support seems iffy, there's little in the way of destructive editing and no processing stack, no support for continuous tempo changes, no region aliases, and documentation is patchy at best. I know some of these points will be addressed in the upcoming 3.0 version, but experience suggests that those new features will take some time until they're in a state you'd rely a film production on.

As for LinuxSampler, the sad fact is that virtually all state-of-the-art libraries come either in Kontakt format or embedded into proprietary player engines. Libraries that LinuxSampler can read (namely, GigaStudio and Akai) are getting more ancient by the minute, as sampling technology is leaping forward at a break-neck speed right now. Make no mistake: I thoroughly hate the fact that every sample developer out there has switched to marrying his content to a certain piece of software, and I'd love to see LinuxSampler succeed anyway (after all, there are lots of uses for samplers besides playing commercial libraries, especially in electronica). For the time being, though, I have to go with the flow, as falling back to old libraries would be a massive step backwards for me.

Now, I have a hard time writing stuff like that, as it tends to seem as if I wanted to belittle the efforts of the developers. Nothing could be further from the truth, they have my utmost respect for creating what they did, and I'm pretty excited about the prospect of having an actual, viable open source replacement for my setup in the future. Then again, I feel that careless statements that a certain piece of software would be ready for a certain task, frequently made by people who don't really know what this task _exactly_ encompasses (not directed at you personally) not only do the software in question a disservice, but also put people like me in a defense position.


I can't argue with most of this, and you've been reasonable and practical in your comments.

Let's not forget the utilities and non direct components here either. Ardour will either find its place or not, and input into developing version 3 will help this, if the devs are listening. (which i think they are, based on recent experience.) The tools need to keep up too. Jack1, and other "behind the scenes" utilities, servers, and "assistants" are as essential to the end result as anything else. I will say here that Jack1 is already at a professional standard of use, and more than capable of holding it's own in a full time working environment.
It's also been a recent experience that another project will fade away for lack of enthusiasm on the part of the most recent project leader to fix a problem or consider updating the app. Entirely his choice of course, but it doesn't add to a progressive perception of linux audio when these things happen. Blender is unique in that it's a visibly valuable application, and has a massive community driven userbase. which is driven from a professionally managed project team. (all credit to Ton and the crew here, for doing this properly.) Blender is the obvious example of what happens when we get past the emotive, and occasionally ego driven, enthusiasm of "building an app in opensource", and manage the application project with professionalism, and the evaluation of success on quality and results.

As a full timer who writes classical and some film music, i have to agree with Jan that we're not ready for primetime yet, and i say this having enthusiastically supported and tested many linux based audio/midi apps ove the last 2 years or so, continuing to do so in this present day.

The devs in our linux audio/midi community are no doubt thoroughly sick of hearing me bang the drum for more efficent workflow within their apps. But my example for the success of this approach is Blender, to which tens of thousands of users will attest. (As well as using the app.)

Sorry to state the obvious, but a professional usage mindset to building an app will result in a professional result, whether it's opensource or not. This does benefit non full time users as well, so nobody loses.

Jan has grasped the reality of the current state of linux audio/midi, and avoided the emotive, or "pleasantly surprised" expectations of some.
I will defend the usability of linuxsampler here, as it does what it's supposed to, in it's design framework. Adding Kontakt and SFZ formats will help push the app further. I'll also applaud the work going on in Ardour, as i've recently seen a massive push to improve the workflow, and add basic features that will aid film writers in a professional working environment. The addition of a dedicated video track is essential, and the midi currently under heavy development is taking shape.
I strongly disagree with Jan about the choice of weapons though. Kontakt, VST, etc have nothing to do with the process, that's just personal preference, and there's more than one way to do this. Kontakt will be useful as an additional format, but that's it, just additional. The tools we need to take this further, and have a professional audio environment, are not dependent on brand names, or personal creative style, but sound tools of use, that do what they say on the tin.

I'll also add a mention here for the openoctave project. Chris and I have pondered these very questions, and are seeking to bring together apps to achieve precisely Jan's point. A professional working environment, that supplies the tools, and workflow, a professional user would expect of a full time use environment. Very early days yet, but the intent is "Blenderlike" for project goals. We've already started modifying apps to this end. (Developers are welcome, but you'll need to contribute according to a timescale and up to a standard. Not being arrogant about this, just real.)

I will certainly agree that careless statements about the usability of a app or tool do nothing to push to a standard that could be considered professional, and do the apps a disservice. It works both ways, and users and devs alike need to know what they want, and where they want to go.

It goes without saying that we will continue to support, and test for, the linux audio community, and it's devs, in working towards a professional use standard, if they're willing to reach for the same.

Ton is right here. No one should expect the Blender community to finance linuxaudio. Great results, and a unified professional standard will perpetuate the success that will bring financial help, not the other way around.

Interesting thread, and comments,

Alex Stone.
Last edited by alexstone on Fri Aug 28, 2009 1:57 pm, edited 1 time in total.

roos
Posts: 7
Joined: Tue Aug 25, 2009 8:43 pm

Postby roos » Thu Aug 27, 2009 12:22 pm

Yeah the organization of Blender seems to be a big example for other projects. I think they do it smart to have a foundation so they also get some funds?

Ok, it seems we linux audio can't satisfy the needs of the pro's yet. All though some pro studio's have Linux in their studio and I think you can do good productions with the tools we have now.

I think stepping back to Linux audio is always a step back, like stepping from the software which is used by Pixar to Blender is also a step back, especially a few years ago. And it cost time to learn other software/workflow.

But then the question is, will there be a time when the soundtrack of Blender will be made by Open Source audio tools.... cause its always a step back and it always cost you time.

What are the criteria of the minimal state of Linux Audio to use it for a Blender soundtrack for example?

alexstone
Posts: 4
Joined: Thu Aug 27, 2009 10:15 am

Postby alexstone » Thu Aug 27, 2009 12:44 pm

roos wrote:Yeah the organization of Blender seems to be a big example for other projects. I think they do it smart to have a foundation so they also get some funds?

Ok, it seems we linux audio can't satisfy the needs of the pro's yet. All though some pro studio's have Linux in their studio and I think you can do good productions with the tools we have now.

I think stepping back to Linux audio is always a step back, like stepping from the software which is used by Pixar to Blender is also a step back, especially a few years ago. And it cost time to learn other software/workflow.

But then the question is, will there be a time when the soundtrack of Blender will be made by Open Source audio tools.... cause its always a step back and it always cost you time.

What are the criteria of the minimal state of Linux Audio to use it for a Blender soundtrack for example?


I'll carefully qualify this with use case.

There are those who enjoy the current features in linux audio, because it satisfies their professional toolset. For a wider user base, on a professional use basis, additional tools will need to be added. I would say that linux audio is professional for some, and not others.

For film, scoring, recording large ensembles, midi, etc, there's more to be added and refined.

Jan has it right in his appraisal of a toolset for film scoring. Video, midi, further development of added synths, added formats, etc will go along way towards providing a decent set of tools to write for film, or indeed large ensemble performance work that incorporates image, audio, and midi. But again, brand names and proprietary formats do not a musician make, and having a particular robustly marketed sample lib doesn't mean it will be used well, or lend the owner any added credibility.

I would disagree that the gig format is dead and gone. There's plenty of high quality sample libs out there in this format that get used on a daily basis for scoring, and will be suitable for some time to come. Garritan has bought the rights to the format, but the fact remains the libs are still there, and we have a great sampler to play them with. For synths, etc, he's certainly got something there, and the electronica base for enhancing a score needs workflow attention in particular.

I'll also say that i mean workflow to be great navigation, great editing tools, etc, not a pretty face on the app. I haven't been in a studio yet, as an orchestral muso to do recording work, that relied entirely on the mouse to produce commercial result. We don't ask sound engineers to run a hardware mixer using a mouse, or coders to code with a mouse. (Professional users will learn Keystrokes, for navigation and editing where possible, because their livelyhood depends on speed, efficiency, and getting the product out the door in a time/profit based fashion.) The tools, or lack of them, should never get in the way of efficient workflow.

Finally, not all scoring work revolves around a console (desk) mentality. The opposite is often the case. You might want to use a hardware mixer to finesse the final result, but bolting together a score in the box requires smart software more than it does a "desk paradigm". It's in this context, that i think linux audio could progress to a good result, and cater to a wider user base, including scoring in conjunction with Blender, or something similar.

Jan, Ton, i'd ask here, what, in your view, is the most pressing requirement in linux audio to take this further forward?


This is just 2 roubles worth as a personal view. Others will no doubt disagree with much of what i've written.

Alex.
Last edited by alexstone on Fri Aug 28, 2009 2:00 pm, edited 1 time in total.

Seablade
Posts: 3
Joined: Thu Aug 27, 2009 7:26 am

Postby Seablade » Thu Aug 27, 2009 5:43 pm

alexstone wrote: Ardour will either find its place or not, and input into developing version 3 will help this, if the devs are listening. (which i think they are, based on recent experience.)


Alex you may not realize this, but Jan has provided and is continuing to provide this.

Seablade

alexstone
Posts: 4
Joined: Thu Aug 27, 2009 10:15 am

Postby alexstone » Thu Aug 27, 2009 10:23 pm

Seablade wrote:
alexstone wrote: Ardour will either find its place or not, and input into developing version 3 will help this, if the devs are listening. (which i think they are, based on recent experience.)


Alex you may not realize this, but Jan has provided and is continuing to provide this.

Seablade


Good to hear, and i wasn't implying he wasn't. We all have a part to play in this, and imho, the more the merrier, across the community, whatever role we might have.

Alex.

Jan Morgenstern
Posts: 9
Joined: Sat Nov 03, 2007 6:12 pm

Postby Jan Morgenstern » Fri Aug 28, 2009 8:13 pm

alexstone wrote:I would disagree that the gig format is dead and gone. There's plenty of high quality sample libs out there in this format that get used on a daily basis for scoring, and will be suitable for some time to come.


Of course there are some timeless gems, especially when it comes to non-acoustic material. When you look at the current generation of orchestral libraries, though, the Giga situation is rather bleak. The only large library you can still get in GS format would be Sonic Implants – VSL has jumped ship long ago, and digging out their old 16bit Giga libs just to avoid using their VI would be a bit pointless, imho. EastWest was one of the earliest exclusive Kontakt supporters back in the days, and they've switched to their own player two years ago. All the recent instrumental stuff that relies on heavy scripting – LASS, Silk, the Samplemodeling stuff – couldn't be made to work on a Giga platform anyway.

As I see it, the last two or three generations of instrumental sample libraries have by and large happened exclusively on Kontakt and proprietary platforms. Unfortunately, these also happen to be the most interesting libraries for film scoring in general.

Jan, Ton, i'd ask here, what, in your view, is the most pressing requirement in linux audio to take this further forward?


The question is very broad, as "Linux audio" would include everything from a command line MP3 encoder to a full-blown DAW. For the sake of the argument, I'll stick to the latter.

Frankly, I think if you want to get more industry professionals to jump on the FOSS bandwagon, insisting on Linux would be a bad move to begin with. Linux is in a kind of chicken-and-egg situation in that there are still too few hardware drivers and too little support from plugin developers to make it viable as a professional-grade audio platform. So, my first requirement for a serious DAW would be that it runs every bit as stable and fast on OSX as it does on Linux, that it supports CoreAudio natively, and that it plays flawlessly with AU and/or VST plugins. (Disclaimer: I've been a heavy Linux advocate since 1995, and it runs on every computer I own privately, so there's no OS zealotry at work here.)

Another thing I've noticed is that developers of open source audio applications have a certain tendency to split up functionality into lots of small modules and applications, expecting their users to work with separate audio and MIDI sequencers, soft synths, samplers, signal routers, and video players. While the UNIX hacker in me certainly sees the functional benefits of that modular approach, I can't help but think that it's ultimately misplaced in applications that are directed at creative professionals. I think one of the many reasons for Blender's success is that you get everything from modelling and rendering all the way to video editing in one uniform package. And there's a good reason that all established DAWs make a point of treating audio, MIDI and video parts as uniformly as possible – it's simply the most intuitive way to work.

Finally, I see a lot of "academical" implementations, for lack of a better word, of the more advanced audio features. Case in point: Ardour's multichannel support, which to me feels more like a proof-of-concept implementation from an esoteric IRCAM project, as it has no semantical understanding of actual channel configurations that occur in the real world. I don't really care if it allows me to load 26-channel WAV files, as long as I still have to jump through burning hoops of firethorn to explain how it should handle a simple 5.1 signal or an LCR bus correctly. Another example would be the send system: It may be more powerful than primitive aux sends, but I'd happily trade that in exchange for being able to set my primitive aux sends up with a single click and actually *see* their levels during a mix. :) What I'm trying to say that there are numerous cases where development seems to be mainly driven by the technical background of the developers, which leads to implementations that are incredibly powerful on paper, but rather impractical to use in the trenches. To a certain degree, this seems to be symptomatic for a lot of open source applications.

(Paul, if you happen to be reading along here: No hard feelings. I'm picking on Ardour because it's the closest contender to the PT & Nuendo bunch.)

Seablade
Posts: 3
Joined: Thu Aug 27, 2009 7:26 am

Postby Seablade » Fri Aug 28, 2009 8:50 pm

Jan Morgenstern wrote:
Another thing I've noticed is that developers of open source audio applications have a certain tendency to split up functionality into lots of small modules and applications, expecting their users to work with separate audio and MIDI sequencers, soft synths, samplers, signal routers, and video players. While the UNIX hacker in me certainly sees the functional benefits of that modular approach, I can't help but think that it's ultimately misplaced in applications that are directed at creative professionals.


I agree and disagree at the same time personally. I say this primarily because the more I ahve done sound for animations with Ardour and Jadeo, the more I actually like having Jadeo as a seperate app instead of Video tracks contained within Ardour ala ProTools or Nuendo.

But... and this is the key I think... this approach works best if an entire ecosystem is designed from the gorund up to allow all of those pieces of software to interoperate cleanly. We have bits and pieces of this on Linux for instance, Jack obviously with transport control as well as audio routing, and LASH some for session management. But what I think would be needed is to provide an entire ecosystem based on these concepts, a Notation Editor -> MIDI Sequencer -> Audio DAW -> Hardware needs to be a simple mattter of choosing a single session and everything settings itself up correctly based off that session. From any of those pieces, you need to be able to access the others easily, and things like UI experience need to be consistent across them.

The real problem is doing this, is flat out difficult. It is much easier to maintain all of this if it is one monolithic piece of software, otherwise you get bits and pieces spread throughout that are half finished, or don't quite work correctly together, etc. But if it is done right I tend to think that it could indeed be viable.

That being said, as I mentioned above, I think a monolithic piece is much easier to implement this one sadly, so I think that you are on the right track with your comment, at least in the near future.

Finally, I see a lot of "academical" implementations, for lack of a better word, of the more advanced audio features. Case in point: Ardour's multichannel support, which to me feels more like a proof-of-concept implementation from an esoteric IRCAM project, as it has no semantical understanding of actual channel configurations that occur in the real world. I don't really care if it allows me to load 26-channel WAV files, as long as I still have to jump through burning hoops of firethorn to explain how it should handle a simple 5.1 signal or an LCR bus correctly.


Completely agree(Course I discussed this with you before) and is on my TODO list actually;) Hopefully sometime before to long I can get started on it.

Another example would be the send system: It may be more powerful than primitive aux sends, but I'd happily trade that in exchange for being able to set my primitive aux sends up with a single click and actually *see* their levels during a mix. :)


Thankfully youll be happy to know this is being completely overhauled(And a LOT of the work is already done) for Ardour 3 so that it should be MUCH better, at least in my opinion.

What I'm trying to say that there are numerous cases where development seems to be mainly driven by the technical background of the developers, which leads to implementations that are incredibly powerful on paper, but rather impractical to use in the trenches. To a certain degree, this seems to be symptomatic for a lot of open source applications.


I still look forward to being able to have a long in depth conversation with you about all of this come A3. In the meantime for everyone else, don't think he is just saying these things here, he and I have talked about them in depth a couple of times, and I have brought some of them up with Paul before as well. It is just a matter of finding time to address all of them;)

Seablade

alexstone
Posts: 4
Joined: Thu Aug 27, 2009 10:15 am

Postby alexstone » Sat Aug 29, 2009 10:14 am

Jan Morgenstern wrote:
alexstone wrote:I would disagree that the gig format is dead and gone. There's plenty of high quality sample libs out there in this format that get used on a daily basis for scoring, and will be suitable for some time to come.


Of course there are some timeless gems, especially when it comes to non-acoustic material. When you look at the current generation of orchestral libraries, though, the Giga situation is rather bleak. The only large library you can still get in GS format would be Sonic Implants – VSL has jumped ship long ago, and digging out their old 16bit Giga libs just to avoid using their VI would be a bit pointless, imho. EastWest was one of the earliest exclusive Kontakt supporters back in the days, and they've switched to their own player two years ago. All the recent instrumental stuff that relies on heavy scripting – LASS, Silk, the Samplemodeling stuff – couldn't be made to work on a Giga platform anyway.

As I see it, the last two or three generations of instrumental sample libraries have by and large happened exclusively on Kontakt and proprietary platforms. Unfortunately, these also happen to be the most interesting libraries for film scoring in general.


I'd have to disagree that Kontakt based libs are the most interesting, and i would say that the hype around 24bit versus 16bit is just that, hype, and marketing. This has been proved more than once, and an excellent film composer called TJ, just for one example, continues to use 16bit for his work, with no reduction in quality or any sense of limitation. My colleague Daryl is the same, and both prove the eternal phrase, "It's about the musician, and his ability." Kontakt have along history of being problematic to work with, and notoriously heavy on resource. So sample lib manufacturers who chose this format, and the EastWest and northern sounds forum archives will attest to this, have had problems trying to get it work effectively, with the resulting and often poor performance for customers who paid a lot of money to be, in effect, perpetual beta testers.
It's no secret that although the gig format has changed hands, a good chunk of writers in Hollywood, Bollywood, Mosfilm and Lenfilm, etc are using gig format libs, and continue to do so. So i would say that Kontakt as a format is just that, a format, and not a precursor to an assumption that it's "more interesting."
In fact you could say here that the really interesting libs are in gig format, and Kontakt is just another direction, with neither being more interesting than the other. This is just personal preference, yes?

Jan, Ton, i'd ask here, what, in your view, is the most pressing requirement in linux audio to take this further forward?


The question is very broad, as "Linux audio" would include everything from a command line MP3 encoder to a full-blown DAW. For the sake of the argument, I'll stick to the latter.

Frankly, I think if you want to get more industry professionals to jump on the FOSS bandwagon, insisting on Linux would be a bad move to begin with. Linux is in a kind of chicken-and-egg situation in that there are still too few hardware drivers and too little support from plugin developers to make it viable as a professional-grade audio platform. So, my first requirement for a serious DAW would be that it runs every bit as stable and fast on OSX as it does on Linux, that it supports CoreAudio natively, and that it plays flawlessly with AU and/or VST plugins. (Disclaimer: I've been a heavy Linux advocate since 1995, and it runs on every computer I own privately, so there's no OS zealotry at work here.)


But surely this is personal preference again. OSX has its plusses and minuses like any OS, and the user experience is a subjective one, based on their own experience. I've used all 3 OS's now, and the OSX Quad Core was just as liable to the spinning beach ball, as Win was to the blue screen of death, or "the program has stopped responding." CoreAudio is not the panacea of all things audio, it never was. It's better than Win, for sure, but i would refute that either of them touch Jack, which is of course available in all 3 OS formats.
And i would also question running flawlessly with AU or VST plugins. The interlink is replete with trainwrecks , where users cannot get that flawless plugin to work correctly, however it's marketed. One only has to read of poorly written code, and messy workarounds to realise that many plugins are akin to putting lipstick on a pig. And every plugin in an app creates an extra overhead. Each one wants a share of resources, and i think both you and I know that arbitrary limit on resource per app in Win and Mac creates special challenges for orchestral writers, as we seek to workaround those limits.
That's dangerous in itself, as any new users out there writing for film, may impose a limit on their score, based purely on the limitations of the OS. I used to have 5 "state of the art" gigboxes, and it was a daily task to keep them all running. When i bought my first Kontakt lib, with player, it crashed the box, and chewed CPU like a hungry boar when it ran. Subsequent versions fared little better.

I would also question the assumption that plugins, particularly proprietary orchestral players, are the "state of the art" weapons they're assumed to be. We only need to refer to the big studio writers to realise they're using plain old gig or akai format, because the opportunity to tweak and polish data inside a DAW with the resultant playback is more efficient than using a complex array of keyswitches, auto roundrobins, and various other "auto" devices to put info in, with the resulting generic lock in for all. John Frizzell is a great example here, as he uses a Logic template routed to several playback machines to write for TV and film. (with a full time apple logic engineer to maintain his logic template. Google will reveal more on this.)
Using plugins are not the only way to do this job, and i don't think using them is an "industry standard" that should be presented as a professional Linux requirement. That's just a working preference, and i would argue against it being viewed as a defining brick wall in the discussion of whether Linux Audio is up to the mark or not. There are extra tools we need, and workflow enhancements, but relying on AU or VST plugins isn't one of them, imho. That's just a personal financial decision, and i would say, part of the marketing fud that seeks to convince writers they "must" have them. They're not necessarily easier to use. I have a cupboard full of them, and went back to basics, because i got more work done, in a more satisfactory way. But that's just my workflow preference, and should NOT be construed as anything more than that.


Another thing I've noticed is that developers of open source audio applications have a certain tendency to split up functionality into lots of small modules and applications, expecting their users to work with separate audio and MIDI sequencers, soft synths, samplers, signal routers, and video players. While the UNIX hacker in me certainly sees the functional benefits of that modular approach, I can't help but think that it's ultimately misplaced in applications that are directed at creative professionals. I think one of the many reasons for Blender's success is that you get everything from modelling and rendering all the way to video editing in one uniform package. And there's a good reason that all established DAWs make a point of treating audio, MIDI and video parts as uniformly as possible – it's simply the most intuitive way to work.


Hmm. A case is made here for a one stop DAW, and that has its merits. I'd agree, just based on previous workflow experience that working in a multi track format DAW is an efficient way of doing the job. But after 2 years of solid Linux use, and plenty of practise, modular roles for apps is definitely something worth considering, particular for projects that have hundred of tracks to deal with. It only takes a modicum of intelligence to work with 2 or 3 apps, each with their own role, across 3 desktops with rapid KS between them to realise, the restriction of putting everything in one app isn't about workflow, but was originally borne out of the single desktop paradigm of the then available OS,s. and the apps being written for them.

And as professionals, we're going to have the experience, and constantly reassess our workflow efficiency upwards because our livelyhood, and the time/profit equation depends on it, yes? You're partly right in that Ardour isn't ready yet compared to Nuendo, or PT. but then you have the trainwreck that is PT8, and Nuendo is still limited, struggling with 64bit implementation, as well as removing several components, and repackaging them to sell to their cutomers as "extra features", when they were previously free, albeit only partially working. Not exactly state of the art, or perfect examples of what a DAW should be.

And i would also more generally question the workflow validity of working with hundred of tracks in one DAW (I've had to do this since the inception of DAWs, and it frankly sucks as a workflow. We have enough smarts as devs and users alike to do this in a better way, not just the commercially decided way as habit, or some relentlessly marketed expectation.)
Folder tracks are a workaround for this, as a result of the single desktop paradigm, but it doesn't mean it's a good way of working. Just a result of an OS restriction, in both Win and Mac.
Perhaps Paul and the Ardour team can get the jump here, and enable Ardour to distribute screensets across multiple desktops? :)



Finally, I see a lot of "academical" implementations, for lack of a better word, of the more advanced audio features. Case in point: Ardour's multichannel support, which to me feels more like a proof-of-concept implementation from an esoteric IRCAM project, as it has no semantical understanding of actual channel configurations that occur in the real world. I don't really care if it allows me to load 26-channel WAV files, as long as I still have to jump through burning hoops of firethorn to explain how it should handle a simple 5.1 signal or an LCR bus correctly. Another example would be the send system: It may be more powerful than primitive aux sends, but I'd happily trade that in exchange for being able to set my primitive aux sends up with a single click and actually *see* their levels during a mix. :) What I'm trying to say that there are numerous cases where development seems to be mainly driven by the technical background of the developers, which leads to implementations that are incredibly powerful on paper, but rather impractical to use in the trenches. To a certain degree, this seems to be symptomatic for a lot of open source applications.


Surely primitive aux sends is a personal preference? Ardour's routing isn't as intuitive as something like Reaper's, for instance, but it's certainly better than Logic's ever was, or Nuendo's, or Sequoia's for that matter. Try routing busses in Logic, and defining inputs by port, and see how much of a hack you need to get past "all ports at once" in the environment, or try creating busses, and routing sends in and out of them in Sequoia, or Nuendo. These 3 apps are considered...professional.

I would agree that seeing sends levels would be useful. That makes sense. Chalk that one up as a win, and a real workflow enhancement.

I would also agree that an academic approach to building apps doesn't always bring a good user experience. This was, and has always been the case, in Cubase and Nuendo with the notation editor, still unusable as a professional tool, and i wouldn't like to see an "all in one" daw that had a poor component like the academic afterthought that is steinberg notation dragging everything else backwards. A good case for a more modular working setup, surely.
And a good case for chaps like you and me to contribute to linux audio app development, with suggestions, ideas, component to component workflow critiques, working layouts as maps, etc, to ensure a great user experience, as well as an academically rewarding codebase for the developer, among his peers.


I think you made a couple of good points in your earlier post, but they didn't get to the actual point of the question without being smothered in several layers of personal preferences. That's fine and we all have different ways of working, but i don't think it aids in a real, professionally viewed perspective and critique of how linux audio can marry more readily with other opensource apps like Blender, if we don't stick to constructive, generic evaluation of what needs to be done, and contribute regularly to projects that have the potential to achieve a great opensource result. Just dismissing it as "not ready", because it doesn't work with AU or VST plugins, doesn't add anything.

Ton, good to hear you're up for Open Source across the board, and working with linux audio at least in discussion of the challenges that are still with us.

May i suggest you open up the blender vid project for next year, and make the vid available to others to write score for, as an additional opportunity to find out just where we are with linux audio, and what else we could do with to bring together a unified creative environment, for word, sound, and image? It seems a little sad that enthusiasm is expressed for a great all round working environment, yet the opportunity to contribute, using opensource apps, or any apps for that matter, is closed to others by default.

Perhaps a friendly competition, pick the top 5, and the users decide which one is the best, by voting?


Thanks for listening,

Alex Stone.
Last edited by alexstone on Sat Aug 29, 2009 10:42 am, edited 2 times in total.


Return to “Blender Open Projects”

Who is online

Users browsing this forum: No registered users and 0 guests