Re: [LAD] LADI

Well, as a generally accepted view of simply writing songs from a
musical perspective, it's considered good practise to write the tune
from beginning to end first, then start work on polishing it. If
you're recording live, that is straight audio recording, then we're
well served in that regard with Ardour, Qtractor, and few others. Once
your recording is done, then it would be a fairly simple matter to
open one of your previously built templates, and assign your ports.

A possible use case:

You've got the guitar out and laid down a track or 2, managed to to
wake up the drummer, and after 78 takes, got something near a well
timed set of drum tracks. The bass player has got back from the
vegetarian food shop, and added his line. So you have say 12 tracks
all recorded, and ready to be polished. There are some good hosts in
Linux for lv2, and ladspa plugins, like ingen, for instance. It can
open templates you've built yourself, so you open the one named
"simple song". Now you have a dedicated plugin host, to which you port
your dozen tracks. (use sends for instance, in each track). Ardour,
for example, is terrific for "quick" recording. Simply "port up" (the
real man's terminology for setting up), and hit the red button. Ardour
remembers what you are ported to, so if you build a little 12 track
"instant" template, for example, with a basic "instant" plugin
template set in Ingen, you simply open Ingen, load the template, then
open Ardour, and load the template, and voila, you're ready to roll.

Like any working environment, setting up is important. Taking the time
to build templates for use pays dividends, as you can open your "core"
plugin set in an app like ingen, then add or subtract per project
according to need. You only need to build templates once, and then you
have an "instant" set to work with. And of course, you can build a lot
of them. In linux we have another massive advantage in multiple
workspaces, and i consider this feature essential when handling lots
of plugins, etc.. I have 8 workspaces, and i fly between them with a
pair of keybindings. So in this use case, i would have Ardour editor
in workspace 1, Ardour mixer in workspace 2, and the plugins in
workspace 3, and possibly 4.

I can say that spreading a working environment out like this is a vast
improvement over trying to handle a sequencer, and what seems like
constantly breeding plugins all in one window, or at a max 2. In my
win days when i wrote for ads, it was a nightmare trying to shift the
focus all the time between so many windows open, even over 2 monitors.
Add to that the image you were trying to write to, and the frustration
builds fairly easily, particularly when you're operating to a tight
time limit. I seemed to spend more time changing GUI focus than i did
work. :)

No such limitation in Linux, and it works so well, i'd never ever go back.

You'll need to devote some time to setup your DAW like this, and
probably ask a few questions along the way, but for reward in terms of
daily workflow satisfaction, i can say i'm in front by a long way, and
get a LOT more work done for less effort.

Thinking out of the commercially driven box is the key here, but as a
user in a linux audio environment, imho, you're more likely to enjoy
writing and working with music, for a far longer period of time.

Alex.

On Sun, Dec 20, 2009 at 11:51 AM, Louigi Verona <louigi.verona@email-addr-hidden> wrote:
> Thanks, Alex, for this lengthy explanation. I must think about it. I can
> certainly see
> the massive advantages of modular approach for complex setups and specific
> tasks.
> How good is it for simple things like making an ordinary song?
>
> Also, tell me guys, is session handling a matter of - what? Apps supporting
> it or is
> it programmatically a complex problem?
>
> Louigi Verona.
>
> On Sun, Dec 20, 2009 at 2:26 PM, alex stone <compose59@email-addr-hidden> wrote:
>>
>> I'd have to disagree with this. A modular environment makes for better
>> use of resource.
>> Plugins occupy the same memory allocation as the app, and the same is
>> true in win and mac. For all the perceived benefits of a "one stop
>> shop" as far as workflow goes, there are drawbacks. It's noted that
>> some users are ok with freezing tracks to best manage limited
>> resources, but other's aren't. I spent a large chunk of my working
>> life bouncing tracks on a constant basis, and unlike the linux
>> environment, i didn't have a choice, no matter the strength of
>> hardware i was using. It wasn't that long ago that if you wanted to
>> run a full orchestral template, plus plugins, you needed a cluster of
>> boxes, or a CRAY. I had a cluster of 5 gig boxes PRECISELY because of
>> the limitations of allocated app memory space, and i was still
>> bouncing tracks, if i wanted to run plugins as well.
>>
>> The modular environment offers a way out of this workflow killer
>> (imho), and with the massive advantage of using jack, with its
>> unlimited port structure, plugins no longer need to reside inside an
>> app, but can be effectively hosted and ported to and from, outside the
>> app, and in their own memory allocation.
>>
>> So i would vote against a push to put everything in one app. Quite the
>> contrary, based on experience, and the many many frustrating hours i
>> put into bouncing tracks, and handling a pandora's box worth of
>> workarounds, just to get the client's material done.
>>
>> Again, i perceive this drive to centralise everything into one "super"
>> app, as an intent to be "just like" win and mac, including the obvious
>> and frustrating workflow limitations, along with any
>> perceived.....advantages, when a little applied imagination on the
>> part of users would reveal a much greater use of resource, and
>> workflow satisfaction, in an unlimited workstation, where only the
>> strength of the hardware, and the corresponding depth of the user's
>> wallet, applies.
>>
>> There's also the perception that having "lots" of plugins inside an
>> app is somehow.........cool, and "the best way to work". It isn't,
>> beyond the first hour of use. Managing lots of plugins is as much, and
>> possibly more of a time killer, than setting up a multiapp template in
>> a linux audio environment. Been there, done that, and it's no
>> sinecure.
>>
>> So no to centralisation, and yes to developing dedicated external lv2
>> plugin hosting more effectively. (Multi hosts, for example.) The power
>> of JACK should not be underestimated in this regard, and the real work
>> lies (imho) in managing software resource, i.e. sessions, port
>> connections, save states across clusters, etc... This would focus any
>> technical lv2 expectations in one spot, and remove the need to hack
>> sequencers constantly, as the lv2 protocol develops further.
>>
>> As for multiple app management, you might be missing the boat a bit
>> here as well. Unlike Win and Mac, with the commerically imposed
>> limitations, linux gives you more than one to lead an elephant across
>> a pond of custard.
>>
>> Outside of the mainstream distros, who are generally more
>> commerical-like in their presentation, there's a wealth of choice for
>> users to really build a great system, unique to requirements. I run
>> Gentoo, and the fluxbox window manager, with no icons, and driven by
>> keybindings. Where an app can run without a GUI, then i do that from a
>> script, or a terminal, saving resources for something else. Linux is
>> extremely openended in that regard, and with a bit of effort of the
>> part of a user, he or she can see a direct relationship between effort
>> in/reward out. So the resources that are chewed up by endless GUI's,
>> now go where they belong, into running the DAW, for practical use. (I
>> have in a normal template 7 apps running, of which only 2 are GUI's
>> for constant use.)
>>
>> Also worth noting here that apps like Jconvolver, for instance, can be
>> run as a standalone single instance, with multiple ins and outs, each
>> one of which can be configured in a file. 1 impulse for an entire
>> project, with each in/out configurable.
>> There's 65 plugins taken care of right there, in one small cli
>> app............
>>
>> So Louigi, i disagree with you, and think it IS a personal preference,
>> and should not be an imposed workflow.
>>
>> Why walk with the rest of the turkeys, when you can soar like an eagle?
>>
>> Alex.
>>
>> On Sun, Dec 20, 2009 at 9:33 AM, Louigi Verona <louigi.verona@email-addr-hidden>
>> wrote:
>> > Modular environment is great, but integrated environment seems to be
>> > more
>> > effective. I mean, imho it is not
>> > a matter of preference and I am not saying no work should be done on
>> > session
>> > management. I am just saying that so
>> > far my observations show me that integrated environment has too many
>> > benefits over modular environment.
>> >
>> > I am relatively new to linux audio, so I would be grateful if you would
>> > explain to me the benefits of modular environment.
>> >
>> > So far I've not been able to see any special benefits of such an
>> > environment. I mean, it's curious, but it also means lots of open
>> > windows, it means the project being dependent on many-many apps. Somehow
>> > to
>> > me it means working on the problem
>> > from the outside. All the inter-application management seems to be a
>> > difficult problematic and even in the long run is doomed
>> > to have many problems due to many apps involved. A dev releases new
>> > version
>> > of his app that has a bug and session
>> > handler cannot connect it - and boom!
>> >
>> >
>> > But I also have a suggestion.
>> > Is it possible to create an integrated environment based on modules?
>> > That
>> > is, an app which would have "plugins", but not plugins in a
>> > sense like effects and synths only, but plugins as elements of the
>> > sequencer
>> > itself, like piano roll, song editor, such stuff. A person opens this
>> > app
>> > and starts adding elements he needs to it. For a particular project he
>> > might
>> > not need a piano roll, he might need only audio track arranger,
>> > for another projects he takes an audio track arranger and also adds a
>> > piano
>> > roll.
>> > Modules of such an app could be very different, like a loop player like
>> > Kluppe, etc - all the apps linux audio has to this day but remade as
>> > modules
>> > to an integrated sequencer.
>> >
>> > What do you think?
>> >
>> >
>> >
>> > Louigi Verona.
>> >
>> >
>> >
>> >
>> > On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey
>> > <pshirkey@email-addr-hidden> wrote:
>> >>
>> >> On 12/20/2009 11:48 AM, Louigi Verona wrote:
>> >>
>> >> So, as a musician, I think linux audio developers have to focus on
>> >>
>> >> 1. integrated audio environment
>> >> 2. sotware synthesizers/effects (LV2)
>> >>
>> >>
>> >>
>> >>
>> >> I prefer to work with a modular environment and want to see session
>> >> management working properly. I would be very disappointed if no further
>> >> work
>> >> was done on session management.
>> >>
>> >> I am looking forward to the progress that will be made over the next
>> >> couple of years on that front.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Patrick Shirkey
>> >> Boost Hardware Ltd
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> LMMS is an integrated environment and having Zyn inside it is great.
>> >> LMMS
>> >> is very promising.
>> >> But what isn't there are plugins and synthesizers. As an ambient
>> >> composer
>> >> I simply lack the tools
>> >> I need,
>> >>
>> >> Hope any of this was useful.
>> >>
>> >> Louigi Verona.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, Dec 20, 2009 at 1:19 AM, <fons@email-addr-hidden> wrote:
>> >>>
>> >>> On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
>> >>>
>> >>> > 1) The 'one app with plugins' group. People who are focusing on one
>> >>> > big
>> >>> > app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
>> >>> > doesn't have much interest in a session handler.
>> >>>
>> >>> And quite probably the authors of these apps are not very
>> >>> motivated to make them compatible with session handlers.
>> >>>
>> >>> > 2) The people who likes to work with different, small Jack
>> >>> > applications
>> >>> > (ams, aeolus, epichord etc.). These people are interested in a
>> >>> > session
>> >>> > handler. But they think dbus is the wrong approach, it is to limited
>> >>> > for
>> >>> > them, or it is not the right thing for the Linux platform in their
>> >>> > opinion.
>> >>>
>> >>> 'Like to work' may not be the correct interpretation. See (4)
>> >>>
>> >>> > 3) Group 3 is the same as group 2, BUT they have chosen dbus as
>> >>> > solution. It's the LADI group.
>> >>>
>> >>> 4. And there's group 4, or maybe that group is just me.
>> >>> If there are others I'd like to know. For group 4:
>> >>>
>> >>> * Sessions are multi-host since there is no other way.
>> >>> In most cases all but one of the machines involved will
>> >>> be headless, and whatever is supposed to happen there
>> >>> is by definition remote controlled instead of being
>> >>> launched from a local desktop.
>> >>>
>> >>> * There are no usable 'single app with plugins' solutions
>> >>> since none of these comes close to what would be required,
>> >>> in particular w.r.t. the multi-host situation, and also
>> >>> because all of these apps silently assume a human user
>> >>> watching them and being able to take corrective action
>> >>> if necessary. Anything that could pop up an error dialog
>> >>> and refuse to proceed until someone reacts is completely
>> >>> useless in such systems.
>> >>>
>> >>> * Any interaction between components of such a system is
>> >>> supposed to use networked communication from the start.
>> >>> Dual-layer solutions based on some local IPC system plus
>> >>> some additional layer that would connect them via a network
>> >>> are just an unnecessary complication, and probably one that
>> >>> would not provide the right semantics, since the design would
>> >>> be based on the single host assumption in blissfull ignorance
>> >>> of what it takes to make things work together via a network.
>> >>>
>> >>> * Given the potential complexity of a networked system, loading
>> >>> a 'session' would in general not mean a complete teardown and
>> >>> buildup of all apps and their connections, but could just mean
>> >>> loading a different configuration in a single app, without even
>> >>> any others being aware of this.
>> >>>
>> >>> People using such systems are *very* motivated to create
>> >>> some form session handling, since controlling this sort of
>> >>> thing manually is a real PITA, in particular if you have
>> >>> to do it a hundred times a day, or if you have to provide
>> >>> an interface usable by non-experts. Which is why I have
>> >>> been working on this. And given the quite hostile reactions
>> >>> shown in recent threads, and the probably minute potential
>> >>> user base, the chances that the results will be made public
>> >>> are rather small.
>> >>>
>> >>> Ciao,
>> >>>
>> >>> --
>> >>> FA
>> >>>
>> >>> _______________________________________________
>> >>> Linux-audio-dev mailing list
>> >>> Linux-audio-dev@email-addr-hidden
>> >>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> Linux-audio-dev mailing list
>> >> Linux-audio-dev@email-addr-hidden
>> >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> Linux-audio-dev mailing list
>> >> Linux-audio-dev@email-addr-hidden
>> >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > Linux-audio-dev mailing list
>> > Linux-audio-dev@email-addr-hidden
>> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>> >
>> >
>>
>>
>>
>> --
>> www.openoctave.org
>>
>> midi-subscribe@email-addr-hidden
>> development-subscribe@email-addr-hidden
>
>

-- 
www.openoctave.org
midi-subscribe@email-addr-hidden
development-subscribe@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev