31 Aug
2009
31 Aug
'09
3:27 p.m.
Some people here (more or less) desperately need a
similar application for linux.
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world.
--
sex, bike, open source!
31 Aug
31 Aug
3:35 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Mon, Aug 31, 2009 at 1:27 PM, cunnilinux himself<cunnilinux(a)gmail.com> wrote:
The only thing I am missing in Linux are some of the virtual
instruments available in the Windows/Mac world (like IK Multimedia or
EastWest/Quantum Leap). So I run them on a separate machine and
control them remotely with Jack, Rosegarden and Ardour.
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
Some people
here (more or less) desperately need a similar application for linux.
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world. 
4:10 p.m.
New subject: off topic (was: Re: ableton live in vmware)
Nobody is going to make something more innovative than a microwave oven. It
heats and cooks based on convectional properties, it's a device, with at
least a button to start and stop. Someone invents, others follow. It's not a
deficiency to not have thought of an idea before someone else. You could sue
Paul for trying to recreate Pro Tools that way. But no, all software share
the same fundamental principles upon which they're built.
We create what's necessary. If an idea which has already been thought of and
implemented by someone else works for us, then we implement it as well.
Developers like Paul barely get sufficient funding to sit at the desk with a
pen and paper to orchestrate, design, and invent. People are paid close to 5
figures a month to do just that, while some invest and get residual income
when their ideas are recognised and patented (unfortunately).
When my dad's business needed a custom accounting program, I made one with
GPL tools. I didn't have to do it from ground up, I just had to put together
different works of others.
This is the very essence of free software - people get together with ideas,
or put ideas from somewhere else into working models. Someone does the
sketching, someone does the planning, someone does something. On occasions,
nobody does anything.
Cathedral and the bazaar.
6:08 p.m.
On Monday 31 August 2009 01:27 pm, cunnilinux himself wrote:
people in linux audio scene always DESPERATELY need
something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world.
That's exactly the same argument people were making about Linux office
applications 8 or 9 years ago, and while some may dislike their choices now
(essentially OpenOffice, Gnumeric/Abiword, Koffice and Google Docs) or find
an obscure feature missing here and there, the only ones who can't get
anything at all done with them are essentially the dimmer bulbs.
Meanwhile, back in those days, the people who claimed Linux didn't need all
those monolithic office applications espoused tools like LaTeX. There were
others, but that's the only one whose name I remember and they were all
basically the same idea, having the user insert codes into the text to tell
the processor about its structure and format during printing. Some people
referred to Emacs as a "word processor", as well. While they may very well
be technically superior in some ways to Microsoft Office or the
alternatives available to Linux (only used LaTeX once and only use emacs
for writing code), tools like LaTeX and Emacs have a hell of a learning
curve.
Ardour has a hell of a learning curve too, and is dependent upon things
like JACK and low-latency kernels. I used to have time to deal with things
like that, but it's been a long time since those days. I've never gotten a
single note recorded in Ardour. Luckily for me, there's LMMS (with inbuilt
Zyn and a bunch of soundfonts) for composition and arrangement, and
Audacity for editing and mixing, and the only thing I was unable to do when
I finally got a song done earlier this year was use a mastering compressor,
which I faked with some harmonics and a limiter. I explained my process to
a friend of mine and he basically said, "Dude, all that stuff you just
spent days on I can do in Ableton in like half an hour."
Maybe that's true, and certainly my friend is very prolific, but I've never
used Ableton so I still don't really know what I'm missing. (Of course,
what he thinks of is "Ableton" is actually Ableton plus a bunch of other
plugins, instruments and sample sets, whose cost would have been in the
five figure range if he hadn't pirated them.) But I've also been using
Linux since 1994, and exclusively since around 2002. Someone from another
operating system doesn't care about a bunch of little virtual sound boxes
connected by a bunch of little virtual cables to get everything exactly the
way they want. They want to double click on an icon and be off to the
races. They want sensible defaults. They want the equivalent of a blank
MS Word document with the cursor blinking and inviting them to type in 12-
point Times New Roman, and worry about adjusting it later.
Essentially, Ableton Live is MS Word.
I think the LMMS guys are the closest to that sort of thing now with all
their presets and the way their default project is set up (and the fact
that it actually *has* a default project), but I'm told it's still closer
to Fruityloops than Ableton. Doesn't matter to me since I haven't played
live in 21 years and I'd be okay never playing live again. I'd like the
automagical stretching and beat matching stuff I hear Ableton does. But
other people do play live and might want more of that functionality, and it
sounds to me like no current single Linux audio app is going to provide it.
If it can be provided by a number of different Linux programs, someone who
makes that kind of claim needs to write a howto and put it out there on the
web, and users who have never seen the inside of a recording booth and
never seen a bash prompt will need to be able to follow the howto without
ever taking their hands off their mice. It really doesn't matter whether
it works for people who already have a Linux solution they're happy with.
It needs to work for the people who aren't getting anything done using
Linux audio because they don't know where to start.
Rob
7:20 p.m.
Picking this out of some interesting comments :)
Has anyone here tried LMMS? What's it like?
--
Will J Godfrey
http://www.musically.me.uk
7:29 p.m.
Folderol wrote:
Has anyone here tried LMMS? What's it like?
I tried it out yesterday, couldn't figure out how to do anything. Will
try again with a manual or tutorial in front of me.
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
8:01 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Atte Andre Jensen schrieb:
Folderol wrote:
It has some conceptual strangeness but this turns out to be quite
efficient and smart once you get used to it.
Almost everything is an object similar to a file, that can be
dragged/dropped to tracks, plugins etc.So if you want a synth-plugin in
a track you just drop the plugin OR one of its presets to the plugin,
that is in the track already and the 3-oscillator-synth changes to the
bass-synth.
Besides this: trying CTRL, SHIFT and the like while working in the
editor yields astounding results sometimes ;-)
LMMS is just cool - if it only would perform better with jack it should
be in the shortlist for "app of the year"...
best regs
HZN
Has anyone here tried LMMS? What's it like?
I tried it out yesterday, couldn't figure out how to do anything. Will
try again with a manual or tutorial in front of me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqcSDkACgkQ1Aecwva1SWPu5QCffHkdzukRiKQDZkRkVt3h5XhF
dv4An1rofKutfRGBpOF+Om2txo7fzPmj
=Wy8+
-----END PGP SIGNATURE-----
7:39 p.m.
Den Monday 31 August 2009 23.20.33 skrev Folderol:
Picking this out of some interesting comments :)
Has anyone here tried LMMS? What's it like?
Yes. I use it and like it. They say it looks like Fruity Loops but I wouldn't
know. Never used FL. I mostly use it to do some groves. It takes some time to
learn but I think it's well worth the effort. You should definitely go to the
wiki for some howto's.
Here's one
http://lmms.sourceforge.net/wiki/index.php?title=Your_First_Song_with_LMMS
Main wiki page
http://lmms.sourceforge.net/wiki/index.php?title=Main_Page
/bengan
7:48 p.m.
New subject: back on topic (ableton-like tools for linux)
On Mon, Aug 31, 2009 at 11:38:47PM +0200, Bengt G?rd?n wrote:
Den Monday 31 August 2009 23.20.33 skrev Folderol:
It seemed to me like a very simple, beginner kind of looper.
Nice to have those around.
Definitely back on-topic if you're discussing Linux tools :-)
-ken
Picking this out of some interesting comments :)
Has anyone here tried LMMS? What's it like?
Yes. I use it and like it. They say it looks like Fruity Loops but I wouldn't
know. Never used FL. I mostly use it to do some groves. It takes some time to
learn but I think it's well worth the effort. You should definitely go to the
wiki for some howto's.
Here's one
http://lmms.sourceforge.net/wiki/index.php?title=Your_First_Song_with_LMMS
Main wiki page
http://lmms.sourceforge.net/wiki/index.php?title=Main_Page
11:48 p.m.
New subject: back on topic (ableton-like tools for linux)
It's really a fun app, just like FL Studio. There're even people who're
trying to rebrand and sell it.
Anyway, it's not really "simple". I've been arranging my synth tracks
all
from within LMMS, including full support for my favourite VSTi. And that was
without any SDK very early on. That is why I don't have Qtractor or
Rosegarden in my workflow, and have grown accustomed to managing MIDI with a
separate app in an ALSA-only session.
With JACK and audio recording support, this will be just as promising as
Ardour 3.
1 Sep
1 Sep
12:05 a.m.
New subject: back on topic (ableton-like tools for linux)
On 09/01/2009 11:48 AM, Ray Rashif wrote:
It's really a fun app, just like FL Studio.
There're even people
who're trying to rebrand and sell it.
Anyway, it's not really "simple". I've been arranging my synth tracks
all from within LMMS, including full support for my favourite VSTi.
And that was without any SDK very early on. That is why I don't have
Qtractor or Rosegarden in my workflow, and have grown accustomed to
managing MIDI with a separate app in an ALSA-only session.
With JACK and audio recording support, this will be just as promising
as Ardour 3.
One thing that ardour, renoise, qtractor and lmms are missing when
compared to AL is the sampler interface which is a core interface in the
live performance model that AL provides.
Seems like a big omission to me that distances these apps quite severely
from the AL model (for live performance) for anyone coming from that
system. Probably also why some people compare lmms to fruity loops
instead of AL.
I imagine it implies the apps are not designed for live object/sample
based performance for AL users.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
------------------------------------------------------------------------
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
31 Aug
31 Aug
8:11 p.m.
Folderol wrote:
Picking this out of some interesting comments :)
Has anyone here tried LMMS? What's it like?
Hi Will,
I reviewed it for LJ recently :
http://www.linuxjournal.com/content/introducing-lmms-linux-multimedia-studio
Best,
dp
1 Sep
1 Sep
8:55 p.m.
On Mon, 31 Aug 2009 18:10:56 -0400
Dave Phillips <dlphillips(a)woh.rr.com> wrote:
Folderol wrote:
Thanks for the link. It looked very interesting so I gave it a quick
spin on my office machine (nothing touches the DAW that I'm not certain
of!)
It is quite well presented and I'm sure it will suit a lot of people
but just doesn't fit in with my working style at all, so I'll pass on
it.
--
Will J Godfrey
http://www.musically.me.uk
Picking this out of some interesting comments :)
Has anyone here tried LMMS? What's it like?
Hi Will,
I reviewed it for LJ recently :
http://www.linuxjournal.com/content/introducing-lmms-linux-multimedia-studio
Best,
dp
2 Sep
2 Sep
1:34 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Mon, Aug 31, 2009 at 6:10 PM, Dave Phillips<dlphillips(a)woh.rr.com> wrote:
I gave lmms a test drive last night (on Fedora 10 + Planet CCRMA) and
think it's a step in the right direction for people who want to
experiment with something quickly and not have to setup a lot of
stuff. I've never used FL Studio and my exposure to GarageBand is
pretty minimal, so not sure if it compares well or not.
One thing that was odd about it was that when I tried to set the audio
output to ALSA, it kept defaulting back to 'Dummy', so I started up
jack and used that for the output, and it worked quite well then. It
could use some enhancements to make things a little more intuitive
(like connecting a track to a specific FX bus, it wasn't immediately
apparent), maybe something more akin to the Reaper "connect anything
to anything" style of routing, or drag a track icon onto the FX bus or
something like that.
But pretty nifty little app. I don't do looped stuff much, but would
use this if I needed something like that. I haven't tried to use it
with external MIDI routing but hopefully it supports that kind of
thing.
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
Has anyone
here tried LMMS? What's it like?
Hi Will,
I reviewed it for LJ recently :
http://www.linuxjournal.com/content/introducing-lmms-linux-multimedia-studio
31 Aug
31 Aug
7:51 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
cunnilinux himself schrieb:
The only things really needed desperately are basics like working
drivers,a flexible MIDI-system, a audioserver designed for realtime and
some apps that implement things like HD-recording, setting
FX/Synth-parameters in realtime, automatisation, pattern-based and
linear sequencing.
How they do it is a matter of individual preferences - it should work
stable is the only consensus I guess.
So no need for despair - the above-mentioned is available. ;-)
Everybody would agree, that it could be improved though and there may be
apps for Mac/Win that still have no free 1:1 competitor for
Linux(elastic audio, melodyne etc). But I agree(if this is you point):
There are no big impossibilities anymore and the stuff, that we have is
different but not inferior.
Some people
here (more or less) desperately need a similar application for linux.
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac. that's the main and only reason why linux is
(semi-)deficient in the
pro audio world.
So you think, there should be a stronger "We are what we are and you are
lamers." attitude? This thinking has some appeal to me too but still I
consider this a snobism. Why dont have a fork of Seq24 with builtin
sampler, elastic audio, a plugin interface and a mixer?
Or why not ask Rui to implement a pattern-matrix interface for Qtractor?
Or make one and submit the patch?
Somebody will do it anyway, if there is a need - needed concepts prevail
- - thats evolution.
Whoever is in such a need for an app, that implements all the
functionality currently available in a modular manner in an app as
comfortable as Live, sould go to abeltons website, check the price for
the licence, find some others the same in need and thus fund devs to do
the job ;-)
best regs
HZN
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqcRc4ACgkQ1Aecwva1SWPSnwCfb3TTnSCZcg/JH1bALLSdkv8T
mNwAoIO06oqkXMSGWt1blQvzDrPLFk3A
=V0fK
-----END PGP SIGNATURE-----
8:20 p.m.
Hartmut Noack wrote:
Or why not ask Rui to implement a pattern-matrix
interface for Qtractor?
no need to ask.
on my own confession, during lac2007 presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
fact is, it's just stuck on an old-fashion time-line sequencer form atm.
nothing to be a shame of, btw :) all that's in the scrum-master's backlog
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
10:44 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno Capela<rncbc(a)rncbc.org> wrote:
on my own confession, during lac2007 presentation,
making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime
granular (re)synthesis, all the time, everywhere (or at least it was a
while ago). i suspect that you cannot do what live does without this
as the basic model of audio output. i could be wrong.
10:56 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Mon, Aug 31, 2009 at 8:44 PM, Paul Davis<paul(a)linuxaudiosystems.com> wrote:
On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
I have to admit complete ignorance here, but what is it about Live
that makes it advantageous over DAWs like Ardour, Reaper, Sonar, Pro
Tools, etc? Is it primarily loop/clip/synth based rather than a hard
disk recorder/mixer like a traditional DAW?
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
on my own confession, during lac2007
presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime
granular (re)synthesis, all the time, everywhere (or at least it was a
while ago). i suspect that you cannot do what live does without this
as the basic model of audio output. i could be wrong.
11:19 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On 09/01/2009 10:56 AM, Brett McCoy wrote:
On Mon, Aug 31, 2009 at 8:44 PM, Paul
Davis<paul(a)linuxaudiosystems.com> wrote:
That's part of it and it also has a very efficient user interface model
that seems to be intuitive for a lot of people. it's not too "candy" to
be a toy but it's not too hard to be threatening. Although I find that
most people I know who use it do so because someone famous they know
does and they want to make music similar to that person. They often
complain about finding it time consuming to get their head around the
complete system but as they are able to quickly make baby steps that is
a big confidence builder and they feel it is worth the effort to
understand the system if they can get close to emulating their musical
heros.
Patrick Shirkey
Boost Hardware Ltd
On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
I have to admit complete ignorance here, but what is it about Live
that makes it advantageous over DAWs like Ardour, Reaper, Sonar, Pro
Tools, etc? Is it primarily loop/clip/synth based rather than a hard
disk recorder/mixer like a traditional DAW?
on my own confession, during lac2007
presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime
granular (re)synthesis, all the time, everywhere (or at least it was a
while ago). i suspect that you cannot do what live does without this
as the basic model of audio output. i could be wrong.
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
11:31 p.m.
New subject: off topic (was: Re: ableton live in vmware)
Just go Renoise and get down the production road!
thnx
ron
On Mon, Aug 31, 2009 at 6:19 PM, Patrick Shirkey <pshirkey(a)boosthardware.com
wrote:
On 09/01/2009 10:56 AM, Brett McCoy wrote:
I have to admit complete ignorance here, but what is it about Live
that makes it advantageous over DAWs like Ardour, Reaper, Sonar, Pro
Tools, etc? Is it primarily loop/clip/synth based rather than a hard
disk recorder/mixer like a traditional DAW?
That's part of it and it also has a very efficient user interface model
that seems to be intuitive for a lot of people. it's not too "candy" to
be a toy but it's not too hard to be threatening. Although I find that
most people I know who use it do so because someone famous they know
does and they want to make music similar to that person. They often
complain about finding it time consuming to get their head around the
complete system but as they are able to quickly make baby steps that is
a big confidence builder and they feel it is worth the effort to
understand the system if they can get close to emulating their musical
heros.
Patrick Shirkey
Boost Hardware Ltd
On Mon, Aug 31, 2009 at 8:44 PM, Paul
Davis<paul(a)linuxaudiosystems.com>
wrote:
> On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno Capela<rncbc(a)rncbc.org>
wrote:
on my own confession, during lac2007
presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime
granular (re)synthesis, all the time, everywhere (or at least it was a
while ago). i suspect that you cannot do what live does without this
as the basic model of audio output. i could be wrong.
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
11:36 p.m.
New subject: off topic (was: Re: ableton live in vmware)
Elastic Time is not only useful for samples/loops. In a traditional editing
session it can fix and tighten up everything from drum tracks to vocals
easily and fast. In Pro Tools (>= 7.4) it's a matter of viewing in sample
mode, analyzing, warping, and you're done. Where Beat Detective/Rhythm
Ferret slices audio, Elastic Time stretches audio. If you ever had to cut up
a region where the decay stops unnaturally, this is your salvation.
1 Sep
1 Sep
6 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
On Mon, 2009-08-31 at 20:56 -0400, Brett McCoy wrote:
I have to admit complete ignorance here, but what is
it about Live
that makes it advantageous over DAWs like Ardour, Reaper, Sonar, Pro
Tools, etc? Is it primarily loop/clip/synth based rather than a hard
disk recorder/mixer like a traditional DAW?
My knowledge is based on reading about it in magazines early on and much
later using the trial version for a bit.
When it came out, using software for live performance was seen as novel
idea (there might have been an "underground" scene thinking
differently).
The minimalistic graphics optimized for clearness were a revelation.
Dialogs are avoided, it's all in one window.
AFAIK it allows tempo changes and immediately stretches/shrinks all
audio to fit. Sony Acid might have been earlier with that.
You can also add markers on clips and then move these markers and the
material between markers will be stretched/shrunken to accommodate. The
version I tried would do so "only" linearly :)
I think the central new concept was having a matrix view, where you have
columns for tracks/instruments and rows for "Scenes".
Have a look at:
http://digisound.files.wordpress.com/2008/06/3-big-rocker.jpg
All those rectangles with play symbols are patterns.
If you look down the "Master" column, it should become clear what scenes
are about. Note that you can trigger any of the patterns any time.
There's a sync feature that can make sure patterns will be started on
the beat/next-measure.
There's also a "traditional" arrangement view:
http://www.kaosaudio.com/images/software/ableton-live-7-le-arrangement.png
Nowadays there's a collection of deeply integrated synth "plugins".
GUI-wise, you could always add such a matrix to an existing
DAW/sequencer (not a small project, of course). But you need a backend
that can play any pattern any time, with a sync-to-beat trigger feature.
And live time stretching.
So, none of the linux audio apps comes even close.
A set of separate tools can never be a replacement (except with a
not-seen-before sophisticated level of optional integration, perhaps).
People can talk about the real or perceived shortcomings of linux audio
tools all day. Doesn't change a thing. The vague and sometimes silly
comparisons and the very foggy ideas what some commercial apps actually
offer are damn frustrating. Would surprise me to read something *new*.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
6:13 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
Hallo,
Thorsten Wilms hat gesagt: // Thorsten Wilms wrote:
People can talk about the real or perceived
shortcomings of linux audio
tools all day. Doesn't change a thing. The vague and sometimes silly
comparisons and the very foggy ideas what some commercial apps actually
offer are damn frustrating. Would surprise me to read something *new*.
If you want something really *new*, I'd say check this out: http://rjdj.me
I'm biased because I work there. Its main target platform on the customer side
is the iPhone/iPod touch, but Android/Linux would be possible, too. As it uses
Pd inside, it's perfectly possible to produces Scenes for RjDj on Linux. In
fact, some of the popular scenes have been produced on Linux, like the ones by
Chris McCormick and me.
Ciao
--
Frank
8:24 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
On 09/01/2009 06:13 PM, Frank Barknecht wrote:
Hallo,
Thorsten Wilms hat gesagt: // Thorsten Wilms wrote:
That is a perfect use of the pd synth engine. Who needs a time limit
when the music is just good (tm)
Very cool.
Patrick Shirkey
Boost Hardware Ltd
People can talk about the real or perceived
shortcomings of linux audio
tools all day. Doesn't change a thing. The vague and sometimes silly
comparisons and the very foggy ideas what some commercial apps actually
offer are damn frustrating. Would surprise me to read something *new*.
If you want something really *new*, I'd say check this out:
http://rjdj.me
I'm biased because I work there. Its main target platform on the customer side
is the iPhone/iPod touch, but Android/Linux would be possible, too. As it uses
Pd inside, it's perfectly possible to produces Scenes for RjDj on Linux. In
fact, some of the popular scenes have been produced on Linux, like the ones by
Chris McCormick and me.
8:10 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
On 09/01/2009 06:00 PM, Thorsten Wilms wrote:
GUI-wise, you could always add such a matrix to an
existing
DAW/sequencer (not a small project, of course). But you need a backend
that can play any pattern any time, with a sync-to-beat trigger feature.
And live time stretching.
This is a useful comparison. IMO we don't need to implement the second
and third features but they would be nice additions and are definitely
useful.
So, none of the linux audio apps comes even close.
Several apps are closer than you are suggesting. What we need is
momentum being built not the complete opposite.
A set of separate tools can never be a replacement
(except with a
not-seen-before sophisticated level of optional integration, perhaps).
I believe this is where the thread is going already.
People can talk about the real or perceived
shortcomings of linux audio
tools all day. Doesn't change a thing.
Often progress only happens in very small increments.
The vague and sometimes silly
comparisons and the very foggy ideas what some commercial apps actually
offer are damn frustrating. Would surprise me to read something*new*.
Charming. Do you kiss your mother with that mouth?
Patrick Shirkey
Boost Hardware Ltd
9:26 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
On Tue, 2009-09-01 at 20:09 +1000, Patrick Shirkey wrote:
> But you need a backend
> that can play any pattern any time, with a sync-to-beat trigger feature.
> And live time stretching.
This is a useful comparison. IMO we don't need to
implement the second
and third features but they would be nice additions and are definitely
useful.
Sure. Just leave one essential feature out.
Several apps are closer than you are suggesting. What
we need is
momentum being built not the complete opposite.
Explain which apps are closer than I would be suggesting. List which of
the features I mentioned are present or lacking for each one.
Or let it become clear your statement has no basis.
Momentum? How about a direction, first?
> A set of separate tools can never be a
replacement (except with a
> not-seen-before sophisticated level of optional integration, perhaps).
I believe this is where the thread is going already.
Outline how a set of specialized applications would offer an experience
similar to that of AL.
A few issues I see:
- Window management hassle
- Need for global save/restore
- Friction do to differences in interface/interaction design
> People can talk about the real or perceived
shortcomings of linux audio
> tools all day. Doesn't change a thing.
Often progress only happens in very small increments.
Adding zero is no increment.
Supporting development (by own effort or financially) of:
- Qtractor to reach its goal (I guess Rui is very content with how
things go, though, and why shouldn't he?)
- Addition of per-pattern play and a track/scene matrix to Ardour (if
Paul agrees generally and on specifics)
- Development of a backend that offers a set of features containing
those outlined earlier, to then continue with adjusting one or the other
existing app or writing a new frontend.
would be somewhat realistic courses of action, IMO.
Breaking out of the conceptual limitations of Hydrogen, LMMS,
Sooperlooper much less so. In all those cases I think what's lacking
weights much more than what is present. I mean this solely in the
context of AL-likeness.
> The vague and sometimes silly
> comparisons and the very foggy ideas what some commercial apps actually
> offer are damn frustrating. Would surprise me to read something *new*.
Charming. Do you kiss your mother with that mouth?
Oh, excuse me for calling out on the obvious fact that some here don't
even know the applications they are comparing (and thus can't actually
gain any insight from the comparisons).
Is Foo more like Bar or like Lorem?
It has this Ipsum-ness about it, so it's more like Lorem.
Suddenly we are all wiser!
But yes, I do. She generally likes a based-on-reality, goal-driven,
no-frills approach and acts acordingly ;p
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
9:41 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
On Tue, Sep 1, 2009 at 12:26 PM, Thorsten Wilms<t_w_(a)freenet.de> wrote:
On Tue, 2009-09-01 at 20:09 +1000, Patrick Shirkey
wrote:
Doesn't FreeWheelin do this already? Not sure about SooperLooper - but
I would guess the same?
James
> But you need a backend
> that can play any pattern any time, with a sync-to-beat trigger feature.
> And live time stretching.
> This is a useful comparison. IMO we don't need to implement the second
> and third features but they would be nice additions and are definitely
> useful.
11:14 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
On 09/01/2009 09:26 PM, Thorsten Wilms wrote:
On Tue, 2009-09-01 at 20:09 +1000, Patrick Shirkey
wrote:
You are contradicting yourself here. You say you not to build on
existing apps that are identified as being similar to parts of the AL
model yet you also say to implement a new backend for the purpose of
integrating with existing apps.
You complain about this topic being discussed but you inform us to
discuss it and implement a solution.
Patrick Shirkey
Boost Hardware Ltd
Often progress only happens in very small
increments.
Adding zero is no increment.
Supporting development (by own effort or financially) of:
- Qtractor to reach its goal (I guess Rui is very content with how
things go, though, and why shouldn't he?)
- Addition of per-pattern play and a track/scene matrix to Ardour (if
Paul agrees generally and on specifics)
- Development of a backend that offers a set of features containing
those outlined earlier, to then continue with adjusting one or the other
existing app or writing a new frontend.
would be somewhat realistic courses of action, IMO.
Breaking out of the conceptual limitations of Hydrogen, LMMS,
Sooperlooper much less so. In all those cases I think what's lacking
weights much more than what is present. I mean this solely in the
context of AL-likeness.
11:41 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
On Tue, 2009-09-01 at 23:13 +1000, Patrick Shirkey wrote:
Would you please use reply-to-list?
You are contradicting yourself here. You say you not
to build on
existing apps that are identified as being similar to parts of the AL
model yet you also say to implement a new backend for the purpose of
integrating with existing apps.
No, what I'm saying is that it's not a good idea to build on apps that
have one tiny part of the functionality, but are otherwise entirely
different in scope and architecture. Because the bit doesn't help if you
need to completely change everything from the bottom up.
It is a better idea to build on something that might seem quite
different regarding the current user experience, but has suitable
architecture.
Starting with the backend is simply another sensible and obvious
approach.
You complain about this topic being discussed but you
inform us to
discuss it and implement a solution.
I complain not about it being discussed, but the way it is discussed.
Your ignorance of the other parts my mail imply that you don't have much
substance to offer.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
8:40 a.m.
New subject: What Live is about (was: Re: ableton live in vmware)
Thorsten Wilms wrote:
The minimalistic graphics optimized for clearness were
a revelation.
Dialogs are avoided, it's all in one window.
AFAIK it allows tempo changes and immediately stretches/shrinks all
audio to fit. Sony Acid might have been earlier with that.
You can also add markers on clips and then move these markers and the
material between markers will be stretched/shrunken to accommodate. The
version I tried would do so "only" linearly :)
I think the central new concept was having a matrix view, where you have
columns for tracks/instruments and rows for "Scenes".
Have a look at:
http://digisound.files.wordpress.com/2008/06/3-big-rocker.jpg
All those rectangles with play symbols are patterns.
If you look down the "Master" column, it should become clear what scenes
are about. Note that you can trigger any of the patterns any time.
There's a sync feature that can make sure patterns will be started on
the beat/next-measure.
I've been working like that with my own sequencer (just midi though)
since 1995. I designed that because of the shortcomings of cubase for
playing in a live fashion. When I play live I load patterns and songs as
I go during the liveset while staying in sync.
http://www.sensoryoverload.nl/images/HYBRID2K.png
Like AL it was designed with no popups or menus, everything you need to
see is already there on the screen. This makes it easy when you are on
stage when you probably already have a hard time focusing to what's on
the screen.
Ableton started out without midi if I recall correctly and when I saw a
demo of v1.0 I really did not like it as it could only do samples and
effects.
The only real innovation (IMHO) they did is the interaction between the
session view and the arrangement view. And of course the integration of
all this stuff.
Robbert
11:01 p.m.
New subject: What Live is about (was: Re: ableton live in vmware)
My personal experience is that I've been able to create and record more
music, by a factor of about one thousand, using FOSS/Linux tools than with
commercial apps. Also, the music I've made is stranger and richer, which I
like.
On Tue, Sep 1, 2009 at 1:00 AM, Thorsten Wilms <t_w_(a)freenet.de> wrote:
On Mon, 2009-08-31 at 20:56 -0400, Brett McCoy wrote:
I have to admit complete ignorance here, but what
is it about Live
that makes it advantageous over DAWs like Ardour, Reaper, Sonar, Pro
Tools, etc? Is it primarily loop/clip/synth based rather than a hard
disk recorder/mixer like a traditional DAW?
My knowledge is based on reading about it in magazines early on and much
later using the trial version for a bit.
When it came out, using software for live performance was seen as novel
idea (there might have been an "underground" scene thinking
differently).
The minimalistic graphics optimized for clearness were a revelation.
Dialogs are avoided, it's all in one window.
AFAIK it allows tempo changes and immediately stretches/shrinks all
audio to fit. Sony Acid might have been earlier with that.
You can also add markers on clips and then move these markers and the
material between markers will be stretched/shrunken to accommodate. The
version I tried would do so "only" linearly :)
I think the central new concept was having a matrix view, where you have
columns for tracks/instruments and rows for "Scenes".
Have a look at:
http://digisound.files.wordpress.com/2008/06/3-big-rocker.jpg
All those rectangles with play symbols are patterns.
If you look down the "Master" column, it should become clear what scenes
are about. Note that you can trigger any of the patterns any time.
There's a sync feature that can make sure patterns will be started on
the beat/next-measure.
There's also a "traditional" arrangement view:
http://www.kaosaudio.com/images/software/ableton-live-7-le-arrangement.png
Nowadays there's a collection of deeply integrated synth "plugins".
GUI-wise, you could always add such a matrix to an existing
DAW/sequencer (not a small project, of course). But you need a backend
that can play any pattern any time, with a sync-to-beat trigger feature.
And live time stretching.
So, none of the linux audio apps comes even close.
A set of separate tools can never be a replacement (except with a
not-seen-before sophisticated level of optional integration, perhaps).
People can talk about the real or perceived shortcomings of linux audio
tools all day. Doesn't change a thing. The vague and sometimes silly
comparisons and the very foggy ideas what some commercial apps actually
offer are damn frustrating. Would surprise me to read something *new*.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
31 Aug
31 Aug
11:14 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On 09/01/2009 10:44 AM, Paul Davis wrote:
On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
This is interesting info but imo the question is whether it is necessary
to completely emulate the AL system in order to enable AL like live
performance or is it more a case of taking their ui model and
integrating it with our existing apps to provide a similar experience
that AL users can easily grok? One of the things that AL users are
attached to is the ability to quickly get up and running. I think we
have a lot of that ground covered already but from a n00b pov it's a
daunting task to get started with a pure jack'ed setup using multiple
apps each designed for a specific purpose. Mostly because they have
been taught a unified approach from using the dominant monolithic
products like AL, Pro Tools, Logic etc.
I feel that cleanly integrating a sampler interface with existing apps
will provide a competitive Linux based solution.
However this raises the question of is the jack system flexible enough
to allow one app to control multiple apps asyncronously. Should a
controller app be pure midi/osc based and bypass jack completely so that
all integrated apps are just receiving trigger commands and dealing with
playback through jack independantly? This would still allow for jack
transport control and sync when required.
I guess the time stretching functionality of AL is built on the
synthesis engine but does it have a trade off for cpu cycles? In my
experience AL is incredibly stable. It would be interesting to know how
many people use the time stretching functionality in AL and if they
apply it across the board or just to sample based loops.
Is there another way to enable the time stretching on the fly?
BTW, Rui I will try to find some time to get an overview of qtractor
codebase as some of the work I intend to do for hydrogen may also apply
there since both apps are using qt4.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
on my own confession, during lac2007
presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime
granular (re)synthesis, all the time, everywhere (or at least it was a
while ago). i suspect that you cannot do what live does without this
as the basic model of audio output. i could be wrong.
1 Sep
1 Sep
2:51 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Tue, 1 Sep 2009, Patrick Shirkey wrote:
This is interesting info but imo the question is
whether it is
necessary to completely emulate the AL system in order to enable AL
like live performance or is it more a case of taking their ui model
and integrating it with our existing apps to provide a similar
experience that AL users can easily grok? One of the things that AL
users are attached to is the ability to quickly get up and running.
I think we have a lot of that ground covered already but from a n00b
pov it's a daunting task to get started with a pure jack'ed setup
using multiple apps each designed for a specific purpose. Mostly
because they have been taught a unified approach from using the
dominant monolithic products like AL, Pro Tools, Logic etc.
I feel that cleanly integrating a sampler interface with existing apps
will provide a competitive Linux based solution.
Probably the only thing that's confusing to them is the process of
starting everything up and getting it communicating. I can't imagine
that having multiple apps running on the same desktop is that
confounding to the average Windows user.
Maybe what's needed isn't so much an app with an integrated UI as some
kind of wrapper that launches everything and offers some sane default
profiles (which can be saved and edited also)? It's nothing that
someone familiar with scripting couldn't do themselves, but maybe that's
the assumption that's causing trouble -- that all of this is so simple
to do in a 5-minute bash script that it'd be silly to provide as a
package? It might not be silly to some users. That package could
depend or recommend others through dependency. Installing it could
trigger everything necessary to get up and running for a new user.
These are just suggestions, just in case someone here feels on the verge
of writing some Live-like program that tries to roll all of the common
tools into one GUI...maybe it's not necessary for some purposes.
Of course, a realtime-enabled kernel should also be part of that
recommended set of packages that get triggered. In theory, that's
already being done by music-oriented distros, but after seeing Ubuntu
Studio get that so horribly wrong, it can't be taken for granted. It's
the other hindrance: In 2009, realtime is still an issue. It shouldn't
be, but it is. I even have a tendency to want to consider it solved
myself now that I've got my own system working (someone else's problem
now for me...buhahaha!), but if you look at the forum posts over the
years, it's the one subject that keeps coming up. If it wasn't true,
talking about latency would be boring, but instead it's almost all LAU
is about. People come here and they talk about achieving low
latency...still.
Give them a out-of-the-box realtime kernel and a GUI launch/interconnect
manager for their audio apps and they will come...
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
5:35 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Tue, 1 Sep 2009 11:51:13 -0500 (CDT)
Brent Busby <brent(a)keycorner.org> wrote:
On Tue, 1 Sep 2009, Patrick Shirkey wrote:
That's why lash would be a good thing.
But now that the efforts got divided it probably slipped even further
into the future.
This is interesting info but imo the question is
whether it is
necessary to completely emulate the AL system in order to enable AL
like live performance or is it more a case of taking their ui model
and integrating it with our existing apps to provide a similar
experience that AL users can easily grok? One of the things that AL
users are attached to is the ability to quickly get up and running.
I think we have a lot of that ground covered already but from a
n00b pov it's a daunting task to get started with a pure jack'ed
setup using multiple apps each designed for a specific purpose.
Mostly because they have been taught a unified approach from using
the dominant monolithic products like AL, Pro Tools, Logic etc.
I feel that cleanly integrating a sampler interface with existing
apps will provide a competitive Linux based solution.
Probably the only thing that's confusing to them is the process of
starting everything up and getting it communicating. I can't imagine
that having multiple apps running on the same desktop is that
confounding to the average Windows user.
Maybe what's needed isn't so much an app with an integrated UI as
some kind of wrapper that launches everything and offers some sane
default profiles (which can be saved and edited also)? It's nothing
that someone familiar with scripting couldn't do themselves, but
maybe that's the assumption that's causing trouble -- that all of
this is so simple to do in a 5-minute bash script that it'd be silly
to provide as a package? It might not be silly to some users. That
package could depend or recommend others through dependency.
Installing it could trigger everything necessary to get up and
running for a new user. These are just suggestions, just in case someone here
feels on the
verge of writing some Live-like program that tries to roll all of the
common tools into one GUI...maybe it's not necessary for some
purposes.
Of course, a realtime-enabled kernel should also be part of that
recommended set of packages that get triggered. In theory, that's
already being done by music-oriented distros, but after seeing Ubuntu
Studio get that so horribly wrong, it can't be taken for granted.
It's the other hindrance: In 2009, realtime is still an issue. It
shouldn't be, but it is. I even have a tendency to want to consider
it solved myself now that I've got my own system working (someone
else's problem now for me...buhahaha!), but if you look at the forum
posts over the years, it's the one subject that keeps coming up. If
it wasn't true, talking about latency would be boring, but instead
it's almost all LAU is about.
To me it looks like LAU just mutated to ALA, Ableton Live Advertisement.
People come here and they talk about
achieving low latency...still.
Nope, it's not all about low-latencies, for many the stock kernels work
pretty well and are often more stable and I guess performancewise
similar to what other OSes provide
Give them a out-of-the-box realtime kernel and a GUI
launch/interconnect manager for their audio apps and they will come...
Those are all there, just a real session management is missing, and I'm
quite sure that it won't ever happen as long as it stays a one-man-show
or multiple one-man-shows. Instead it would need a collaborative
effort, including those developers who actively develop the main linux
audio applications, nothing less.
Philipp
5:51 p.m.
New subject: off topic (was: Re: ableton live in vmware)
hollunder(a)gmx.at wrote:
Give them a out-of-the-box realtime kernel and a GUI
I think I agree with you. A Lash kind of thing is good for all LAU
users, but also for devs of other (main) apps, like Ardour for instance.
It will make Linux more attractive for pro audio usage, user base will
grow and that could be good for donations/documentation/promotion etc.
And yes, Lash seems to be a one-man-show now... but it seems it wasn't
developing well before that... (I don't know the ins and outs of it).
Would be better if more people will help to develop a Lash kind of thing.
\r
launch/interconnect manager for their audio apps
and they will come...
Those are all there, just a real session management is missing, and I'm
quite sure that it won't ever happen as long as it stays a one-man-show
or multiple one-man-shows. Instead it would need a collaborative
effort, including those developers who actively develop the main linux
audio applications, nothing less.
2 Sep
2 Sep
7:04 a.m.
New subject: off topic (was: Re: ableton live in vmware)
On Tue, 01 Sep 2009 21:51:35 +0200
Grammostola Rosea <rosea.grammostola(a)gmail.com> wrote:
hollunder(a)gmx.at wrote:
Afaik it went through three pairs of hands since it exists, and now we
have a fork that I think won't be the solution either, mainly because
it can't restore the clients internal state and needs dbus enabled
jack, which is either a patched jack1 or jack2, both having it's share
of problems.
Give them a out-of-the-box realtime kernel and a
GUI
I think I agree with you. A Lash kind of thing is good for all LAU
users, but also for devs of other (main) apps, like Ardour for
instance. It will make Linux more attractive for pro audio usage,
user base will grow and that could be good for
donations/documentation/promotion etc.
And yes, Lash seems to be a one-man-show now... but it seems it
wasn't developing well before that... (I don't know the ins and outs
of it). launch/interconnect manager for their audio apps
and they will
come...
Those are all there, just a real session management is missing, and
I'm quite sure that it won't ever happen as long as it stays a
one-man-show or multiple one-man-shows. Instead it would need a
collaborative effort, including those developers who actively
develop the main linux audio applications, nothing less.
Would be better if more people will help to develop a
Lash kind of
thing.
\r
Yep, I think so, but it would need to be used by high profile apps like
ardour and a bunch of others to encourage application developers to
integrate it in their apps as well.
Philipp
9:25 a.m.
New subject: off topic (was: Re: ableton live in vmware)
<hollunder(a)gmx.at> writes:
Afaik it went through three pairs of hands since it
exists, and now we
have a fork that I think won't be the solution either, mainly because
it can't restore the clients internal state and needs dbus enabled
jack, which is either a patched jack1 or jack2, both having it's share
of problems.
How you came to conclusion that it wont be able to restore the clients
internal state? If you are talking about ladish - this is just not the
case.
Moreover, jack2 can be dbus enabled without patching.
Are you spreading FUD?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:52 a.m.
New subject: off topic (was: Re: ableton live in vmware)
Nedko Arnaudov <nedko(a)arnaudov.name> writes:
How you came to conclusion that it wont be able to
restore the clients
internal state? If you are talking about ladish - this is just not the
case.
Moreover, jack2 can be dbus enabled without patching.
Are you spreading FUD?
It looks I've not understoon what hollunder said. Sorry for FUD :)
To make things clear: saving internal state of jack apps is a goal of
ladish project. What is different from LASH is that it will be able to
restore JACK connections of applications that are not linked to
libladish/liblash. Only external state will be saved/restored in this
case. External state includes JACK connections and application
commandline.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
1 Sep
1 Sep
8:41 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On 09/02/2009 02:51 AM, Brent Busby wrote:
Give them a out-of-the-box realtime kernel and a GUI launch/interconnect
manager for their audio apps and they will come...
I agree with you that a big part of the problem seems to be a conflict
between the existing Linux workflow model and people who are not able or
prepared to work within the modular app model that jack provides for.
Various people have tried to provide this out of the box and centralised
functionality already but it seems no one has the the ark that AL users
are conditioned for. I think this discussion helps some of us to get a
good overview of what people are still missing.
Time stretching and beat matching have been worked on with varying
results over the years. I find it interesting that so many people rely
on these tools so greatly. However it's clear there is a market for
software that deals cleanly with this issue which is not being
sufficiently handled yet by the various Linux apps.
Maybe it's a good idea to also discuss the best examples we have in the
Linux apps collection for the above functionality to see where we have
missed the mark?
I find it blatently ignorant for some of the posters to say that the
jack model is not and never gonna work. That's just outright rude. For
many of us JACK works very well already. If someone doesn't like the
modular approach and requires a monolithic interface they have various
options available. No need to write off jack and all the hard work that
has been put into the apps that work within the modular framework.
Patrick Shirkey
Boost Hardware Ltd
8:47 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Tue, Sep 1, 2009 at 6:40 PM, Patrick
Shirkey<pshirkey(a)boosthardware.com> wrote:
jack model is not and never gonna work. That's
just outright rude. For
many of us JACK works very well already. If someone doesn't like the
modular approach and requires a monolithic interface they have various
options available. No need to write off jack and all the hard work that
has been put into the apps that work within the modular framework.
I can't work without Jack... on the occasions I have had to work on
Windows, not having something like Jack just drives me up the wall...
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
8:51 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Tue, 1 Sep 2009 18:46:58 -0400
Brett McCoy <idragosani(a)gmail.com> wrote:
On Tue, Sep 1, 2009 at 6:40 PM, Patrick
Shirkey<pshirkey(a)boosthardware.com> wrote:
<AOL mode = "On">
Me too!
<AOL mode = "Off">
--
Will J Godfrey
http://www.musically.me.uk
jack model is not and never gonna work.
That's just outright rude. For
many of us JACK works very well already. If someone doesn't like the
modular approach and requires a monolithic interface they have various
options available. No need to write off jack and all the hard work that
has been put into the apps that work within the modular framework.
I can't work without Jack... on the occasions I have had to work on
Windows, not having something like Jack just drives me up the wall...
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
2 Sep
2 Sep
5:43 a.m.
New subject: off topic (was: Re: ableton live in vmware)
On Wed, 2009-09-02 at 08:40 +1000, Patrick Shirkey wrote:
I find it blatently ignorant for some of the posters
to say that the
jack model is not and never gonna work. That's just outright rude. For
many of us JACK works very well already. If someone doesn't like the
modular approach and requires a monolithic interface they have various
options available. No need to write off jack and all the hard work that
has been put into the apps that work within the modular framework.
If the JACK model "works" or not depends on how you define "works".
It works great for connecting sound generators, processing stages and
recorders.
It doesn't work if you want total recall. I hope Nedko succeeds there,
but it seems no 2 developers can agree on the specifics.
It doesn't work too well if you compare with an integrated solution that
happens to offer the required features all by itself. The likely
shortcoming of integrated solutions will usually be flexibility (if not,
you will likely see internal modularity ...).
Even with having JACK around, it still makes sense to have integrated
MIDI/Audio sequencers instead using 2 and fiddling around with 2
timelines and transport sync issues.
Even if you have stand-alone synths it makes sense to run plugins in a
sequencer for the most straightforward synth and patch selection and for
total recall on loading a session.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
1:27 p.m.
New subject: off topic (was: Re: ableton live in vmware)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrick Shirkey schrieb:
On 09/02/2009 02:51 AM, Brent Busby wrote:
> Give them a out-of-the-box realtime kernel and a GUI launch/interconnect
> manager for their audio apps and they will come...
Time stretching and beat matching have been worked on
with varying
results over the years. I find it interesting that so many people rely
on these tools so greatly.
I'd consider beat-detection a tool for some specialists and a nice toy
for beginners but time-stretching is really important for many people.
Say you have 5 sessions of the same piece recorded live and in studios,
it is quite sexy to have a good sounding usable tool, that helps you to
weld the best moments of those together. Not every band performs best
when playing by a metronome and different versions could be in different
speed and still compatible.
I find it blatently ignorant for some of the posters
to say that the
jack model is not and never gonna work. That's just outright rude. For
many of us JACK works very well already. If someone doesn't like the
modular approach and requires a monolithic interface they have various
options available. No need to write off jack and all the hard work that
has been put into the apps that work within the modular framework.
101% FACK
It is fascinating to see people freak out as they see others doing the
things they do differntly....
;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqejtEACgkQ1Aecwva1SWOPZACfTcCs5GZaIGPrp4qn4G2Gd75W
kVQAmgP2Sjg2Ic01XO+E5an35o+JGO+a
=GWDe
-----END PGP SIGNATURE-----
1:58 p.m.
New subject: off topic (was: Re: ableton live in vmware)
Hartmut Noack wrote:
I'd consider beat-detection a tool for some
specialists and a nice toy
for beginners
I (still haven't run Ableton Live) read that AL is able to extract the
groove from one piece of audio and apply it to another. That sounds
handy (and neither specialist or toyish) to me.
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
3 Sep
3 Sep
5:13 a.m.
New subject: off topic (was: Re: ableton live in vmware)
Atte Andre Jensen schrieb:
Hartmut Noack wrote:
yeah, you can extract that from any midi-clip as well. or for example
cut up samples and make some fancy beat programming, join those samples
as a clip and apply the groove of it to a midi-clip (ie. straight
arpeggio) or another audio one. it's even nice for the orchestral
compositions I currently do, since you can add slight timing randomness
to the grooves.
I'd consider beat-detection a tool for some
specialists and a nice toy
for beginners
I (still haven't run Ableton Live) read that AL is able to extract the
groove from one piece of audio and apply it to another. That sounds
handy (and neither specialist or toyish) to me.
1 Sep
1 Sep
5:32 a.m.
New subject: off topic (was: Re: ableton live in vmware)
On Tue, September 1, 2009 01:44, Paul Davis wrote:
On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
by clone i was only referring to the pattern/matrix loop sequencer of the
thing, sorry, not the sampler or synth and what else that goes in the
monolith. i think, that was and probably still is imho the distinguishing
feature from the pack, giving function and merit to its own name, live.
qtractor is and will be just a sequencer. any attempt to make it an
all-in-one-wonder will get kicked out at first sight :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
on my own confession, during lac2007
presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime granular
(re)synthesis, all the time, everywhere (or at least it was a while ago).
i suspect that you cannot do what live does without this as the
basic model of audio output. i could be wrong.
2:43 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Tue, Sep 1, 2009 at 3:32 AM, Rui Nuno Capela<rncbc(a)rncbc.org> wrote:
On Tue, September 1, 2009 01:44, Paul Davis wrote:
Hey Rui - what about "just" having multiple timelines that can be
switched on the fly (with the switching quantized to a bar)?
Graphically, each timeline would be a column (tracks are still your
rows). This would give you a pattern/matrix loop sequencer of sorts.
On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
by clone i was only referring to the pattern/matrix loop sequencer of the
thing, sorry, not the sampler or synth and what else that goes in the
monolith. i think, that was and probably still is imho the distinguishing
feature from the pack, giving function and merit to its own name, live.
qtractor is and will be just a sequencer. any attempt to make it an
all-in-one-wonder will get kicked out at first sight :) on my own confession, during lac2007
presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime granular
(re)synthesis, all the time, everywhere (or at least it was a while ago).
i suspect that you cannot do what live does without this as the
basic model of audio output. i could be wrong.
1:47 p.m.
New subject: off topic (was: Re: ableton live in vmware)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Davis schrieb:
it might be worth you knowing that the heart of live
is realtime
granular (re)synthesis, all the time, everywhere (or at least it was a
while ago).
So it would take a really sophisticated sampler-engine with realtime
granular (re)synthesis and a nice, comfortable, feature-rich interface
that could be triggered by a pattern-oriented sequencer like Seq24?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkqdQf4ACgkQ1Aecwva1SWNO0wCffK9dxnJylfkyiinlLixsZfEP
xq0AmgNprSdmkr9uEFT8HrFGFjAKSlLa
=tYtd
-----END PGP SIGNATURE-----
2 Sep
2 Sep
2:02 a.m.
New subject: off topic (was: Re: ableton live in vmware)
On Mon, Aug 31, 2009 at 08:44:33PM -0400, Paul Davis wrote:
On Mon, Aug 31, 2009 at 6:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
Interesting.
I wonder why they did that.
To make beat-matching and pitch-matching easy and efficient for DJ's?
-ken
on my own confession, during lac2007
presentation, making a live clone
was indeed my initial goal for qtractor. it still is, as much of a
foundation it can be.
it might be worth you knowing that the heart of live is realtime
granular (re)synthesis, all the time, everywhere (or at least it was a
while ago). i suspect that you cannot do what live does without this
as the basic model of audio output. i could be wrong.
11:30 a.m.
cunnilinux himself schrieb:
just to add my 2 cents...
regarding monolithic vs. modular (across applications):
while the latter (theoretically) allows for more flexibility of
processing, akin to the proven unix-concepts of pipelining (and
therefore the development of something jack-alike for audio/video etc
became an obvious evolution for -primarily- LAU/D), it does not allow
for certain common concepts in the workflow of composition and dsp.
technically - or at least _without hassle_. those include nearly all
operations that:
1a) allow you to temporarily bounce (aka freezing) parts of the signal
chain (tracks, single processed clips, subchannels) - thus saving cpu
cycles in rather complex arrangements.
1b) keep sequencing and time-information on
processed/bounced/re-recorded material
1c) saving disk-space and processing time by recording only the
necessary parts of the bounce while still being a proper/correct bounce.
2) modifying a group of modules in the signal chain and the sequence
data e.g. cloning, deleting, replacing etc.
3) exchange meta-information such as the set of notes in a track to e.g.
allow samplers to efficiently just load the samples needed to play the
track, prefetching large chunks of audio-data or sub-track tempi for
sync'd f/x.
4) limit the amount of organization in 1x) and mixing units
(pre-/post-fx or mixer or sub-channels and modulation sources across tracks)
I am sure you can come up with some more. Those are all points taken
care of in halfway sane, up-to-date DAWs that are monolithic and points
like 1 & 2 are basic editing operations that - for me - increase the
efficiency by a factor of 4 in time spent fiddling with the arrangement.
The early versions of Ableton didnt do 1) for example and my time spent
on organizing heavy arrangements (30-50 tracks with lots of automated
f/x) was unbearable, not to mention that the quality of execution of the
sequencing and composition itself suffered due to that.
5) of course easy recall of chains(+sequence data) etc
These points are of conceptual nature.
regarding supercollider&csound vs ableton:
the power of sc3&csound lies exactly in their monolithic nature, the
deep integration of sequencing (and processing sequences) and signal
processing. This has nearly nothing to do with the principle of
interconnecting rather autarkic applications needles to say jack.
I don't want to comment too much on the state of LA and don't want to be
unjust to the devs. From my developer-view most technologies and
libraries are pretty much awesome, technically sound and well-written.
But even if I decided that I did not want to use my (commercial) f/x and
synths anymore and wrote my dsp stuff in supercollider I wouldnt be able
to get even close to the quality and efficiency of a workflow that is
common for me.
Now, to get to the peak of my flamboyant troll-post:
To ignorantly summarize: there are mainly two opinions of LAD, one is
about scratching your own itch and putting something together as
greatest common divisor that puts all parts into some kind of context.
The other is to create a solution for professional audio/composition and
whatnot. Both offer a solution for music-production (it does not
necessarily matter whether monolithic or modular; modular implies more
communication and specification, though) but the latter involves doing
your homework right. To state more precisely, as a dev you _have_ to
engage with commercial tools to understand the current state of art of
the music-production workflow. In fact ,I wished that most LAD-devs
produced more music that push their but more importantly the commercial
tools to their limits to see what the necessities for such a
professional F/OSS audio-production solution are. Because from judging
from most tools, I see a severe lack thereof - especially emphasizing
the workflow. Otherwise you will always have to face ppl mistaking the
set of tools as professional audio solution and wining about it or the
lack of integration (native, virtualized, whatever) of commercial tools.
Don't take me wrong, I personally don't believe in most commercial tools
as being the peak of music-technology. In fact, even conceptually, I
think that most concepts of visualizing, interacting and processing
musical events is entirely wrong.
niklas
Some people
here (more or less) desperately need a similar application for linux.
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world.
1:09 p.m.
On 09/02/2009 11:30 PM, Niklas Klügel wrote:
cunnilinux himself schrieb:
just to add my 2 cents...
regarding monolithic vs. modular (across applications):
while the latter (theoretically) allows for more flexibility of
processing, akin to the proven unix-concepts of pipelining (and
therefore the development of something jack-alike for audio/video etc
became an obvious evolution for -primarily- LAU/D), it does not allow
for certain common concepts in the workflow of composition and dsp.
technically - or at least _without hassle_. those include nearly all
operations that:
1a) allow you to temporarily bounce (aka freezing) parts of the signal
chain (tracks, single processed clips, subchannels) - thus saving cpu
cycles in rather complex arrangements.
1b) keep sequencing and time-information on
processed/bounced/re-recorded material
1c) saving disk-space and processing time by recording only the
necessary parts of the bounce while still being a proper/correct bounce.
2) modifying a group of modules in the signal chain and the sequence
data e.g. cloning, deleting, replacing etc.
3) exchange meta-information such as the set of notes in a track to e.g.
allow samplers to efficiently just load the samples needed to play the
track, prefetching large chunks of audio-data or sub-track tempi for
sync'd f/x.
4) limit the amount of organization in 1x) and mixing units
(pre-/post-fx or mixer or sub-channels and modulation sources across tracks)
I am sure you can come up with some more. Those are all points taken
care of in halfway sane, up-to-date DAWs that are monolithic and points
like 1& 2 are basic editing operations that - for me - increase the
efficiency by a factor of 4 in time spent fiddling with the arrangement.
The early versions of Ableton didnt do 1) for example and my time spent
on organizing heavy arrangements (30-50 tracks with lots of automated
f/x) was unbearable, not to mention that the quality of execution of the
sequencing and composition itself suffered due to that.
5) of course easy recall of chains(+sequence data) etc
These points are of conceptual nature.
regarding supercollider&csound vs ableton:
the power of sc3&csound lies exactly in their monolithic nature, the
deep integration of sequencing (and processing sequences) and signal
processing. This has nearly nothing to do with the principle of
interconnecting rather autarkic applications needles to say jack.
I don't want to comment too much on the state of LA and don't want to be
unjust to the devs. From my developer-view most technologies and
libraries are pretty much awesome, technically sound and well-written.
But even if I decided that I did not want to use my (commercial) f/x and
synths anymore and wrote my dsp stuff in supercollider I wouldnt be able
to get even close to the quality and efficiency of a workflow that is
common for me.
Now, to get to the peak of my flamboyant troll-post:
To ignorantly summarize: there are mainly two opinions of LAD, one is
about scratching your own itch and putting something together as
greatest common divisor that puts all parts into some kind of context.
The other is to create a solution for professional audio/composition and
whatnot. Both offer a solution for music-production (it does not
necessarily matter whether monolithic or modular; modular implies more
communication and specification, though) but the latter involves doing
your homework right. To state more precisely, as a dev you _have_ to
engage with commercial tools to understand the current state of art of
the music-production workflow. In fact ,I wished that most LAD-devs
produced more music that push their but more importantly the commercial
tools to their limits to see what the necessities for such a
professional F/OSS audio-production solution are. Because from judging
from most tools, I see a severe lack thereof - especially emphasizing
the workflow. Otherwise you will always have to face ppl mistaking the
set of tools as professional audio solution and wining about it or the
lack of integration (native, virtualized, whatever) of commercial tools.
Don't take me wrong, I personally don't believe in most commercial tools
as being the peak of music-technology. In fact, even conceptually, I
think that most concepts of visualizing, interacting and processing
musical events is entirely wrong.
Great post. You have summarised the current state of LA "things" very well..
I would like to add that state of the art is a difficult mark to keep up
with especially when you are not being paid to care about it.
What I see happening is a gradual expansion of the level of expertise
and resources available for development.
Patrick Shirkey
Boost Hardware Ltd
Some
people here (more or less) desperately need a similar application for linux.
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world.
2:57 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On Wed, Sep 2, 2009 at 11:30 PM, Niklas Klügel <niklas.kluegel(a)mytum.de>wrote;wrote:
cunnilinux himself schrieb:
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world.
just to add my 2 cents...
regarding monolithic vs. modular (across applications):
while the latter (theoretically) allows for more flexibility of
processing, akin to the proven unix-concepts of pipelining (and
therefore the development of something jack-alike for audio/video etc
became an obvious evolution for -primarily- LAU/D), it does not allow
for certain common concepts in the workflow of composition and dsp.
technically - or at least _without hassle_. those include nearly all
operations that:
1a) allow you to temporarily bounce (aka freezing) parts of the signal
chain (tracks, single processed clips, subchannels) - thus saving cpu
cycles in rather complex arrangements.
This could happen if programs could be smart enough not to do audio
processing if there is no input signal and programs are able to trace the
signal path(s) till it(they) terminate(s) (either has no output connections,
makes itself to the system output connections (speakers), or back into the
application itself. The application could then connect the terminating
output(s) to the program input - do a synchronised record (already
possible), close off the signal path for the processing version of the track
and playback the recorded audio instead.
> Some people here (more or less) desperately
need a similar application
for linux.
1b) keep sequencing and time-information on
processed/bounced/re-recorded material
if the solution for 1 is enabled then this should also be possible.
1c) saving disk-space and processing time by recording
only the
necessary parts of the bounce while still being a proper/correct bounce.
this should also be possible. for inter application stuff this would just
require some form of dead air detection. Or am I missing something here.
2) modifying a group of modules in the signal chain
and the sequence
data e.g. cloning, deleting, replacing etc.
Cloning would be an interesting feature to have at the connection and
application management layer.
But providing that the applications are smart enough not to do processing
and that groups of applications could be saved and loaded by the application
that replaces Lash (LADI?)... All this should be possible.
3) exchange meta-information such as the set of notes
in a track to e.g.
allow samplers to efficiently just load the samples needed to play the
track, prefetching large chunks of audio-data or sub-track tempi for
sync'd f/x.
This could potentially be done through dbus... and/or as an extension to LV2
etc.
4) limit the amount of organization in 1x) and mixing
units
(pre-/post-fx or mixer or sub-channels and modulation sources across
tracks)
I am sure you can come up with some more. Those are all points taken
care of in halfway sane, up-to-date DAWs that are monolithic and points
like 1 & 2 are basic editing operations that - for me - increase the
efficiency by a factor of 4 in time spent fiddling with the arrangement.
The early versions of Ableton didnt do 1) for example and my time spent
on organizing heavy arrangements (30-50 tracks with lots of automated
f/x) was unbearable, not to mention that the quality of execution of the
sequencing and composition itself suffered due to that.
5) of course easy recall of chains(+sequence data) etc
These points are of conceptual nature.
This I understand is the point of having something like LASH (LADI?)...
Anyways I am glad you brought up those points... It is something severely
lacking in the current modular implementation that we have.
Doing things in a modular way through jackd has a lot of potential but
really requires some application managment features to really compete with
proprietory workflows.
I would love to see a control application that
1) lets you group applications....
2) the ability to remove/restore connections going in or out of a group.
3) the ability to clone a group.
4) the ability to save/restore groups of applications.
3:46 p.m.
New subject: modular audio apps and control-communication was: off topic
there is one point i am not aware of:
is there a standard in jack or any other
linux-audio-interprocess-comunication for control data? (event based and
continuously)
or do i have to use midi? (7bit :-( )
for real integration between different audio apps this would be an
important feature.
I would love to see a control application that
1) lets you group applications....
2) the ability to remove/restore connections going in or out of a group.
3) the ability to clone a group.
4) the ability to save/restore groups of applications.
3:50 p.m.
New subject: modular audio apps and control-communication was: off topic
On Thu, 3 Sep 2009, sh0099 wrote:
there is one point i am not aware of:
is there a standard in jack or any other
linux-audio-interprocess-comunication for control data? (event based and
continuously)
or do i have to use midi? (7bit :-( )
Take a look at OSC.
-Gabriel
4:06 p.m.
New subject: modular audio apps and control-communication was: off topic
i know OSC
but there is no communication standard for control data like jack for audio
and i think without this you can not modularise fully.
i am not a pop musican
i use mostly supercollider, ardour and faust.
everything i want to automatise have to be some plugin (faust) or a big
workaround (osc)
and the atvantage of jack are in the global context small when you read
this:
"*Betreff: *FORUM WORKSHOPS - November 18-20, 2009 at IRCAM from 10AM to
6PM daily
...
Taking advantage of our historic collaboration with Cycling74 for
Max/MSP on the one hand and our récent collaboration with the German
company Ableton, Forum members will be able to get to know Ableton’s
*Live 8* as well as the new possibility of including Max/MSP patches
directly in *Live 8* thanks to *Max for Live*."
these blockheads seam to have also there (private) jack...
Gabriel M. Beddingfield schrieb:
On Thu, 3 Sep 2009, sh0099 wrote:
there is one point i am not aware of:
is there a standard in jack or any other
linux-audio-interprocess-comunication for control data? (event based and
continuously)
or do i have to use midi? (7bit :-( )
Take a look at OSC.
-Gabriel
10:21 p.m.
New subject: modular audio apps and control-communication was: off topic
On 09/03/2009 04:06 AM, sh0099 wrote:
i know OSC
but there is no communication standard for control data like jack for audio
and i think without this you can not modularise fully.
i am not a pop musican
i use mostly supercollider, ardour and faust.
everything i want to automatise have to be some plugin (faust) or a big
workaround (osc)
and the atvantage of jack are in the global context small when you read
this:
"*Betreff: *FORUM WORKSHOPS - November 18-20, 2009 at IRCAM from 10AM to
6PM daily
...
Taking advantage of our historic collaboration with Cycling74 for
Max/MSP on the one hand and our récent collaboration with the German
company Ableton, Forum members will be able to get to know Ableton’s
*Live 8* as well as the new possibility of including Max/MSP patches
directly in *Live 8* thanks to *Max for Live*."
these blockheads seam to have also there (private) jack...
That would be kind of sad if they have chosen not to use JACK to enable
this integration as there must have been a lot of overlap in the code
design.
However it also opens up the possibility for someone round here to use
the same api to enable integration.
Patrick Shirkey
Boost Hardware Ltd
Gabriel M. Beddingfield schrieb:
On Thu, 3 Sep 2009, sh0099 wrote:
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
there is one point i am not aware of:
is there a standard in jack or any other
linux-audio-interprocess-comunication for control data? (event based and
continuously)
or do i have to use midi? (7bit :-( )
Take a look at OSC.
-Gabriel
11:40 p.m.
New subject: modular audio apps and control-communication was: off topic
On Wed, Sep 2, 2009 at 8:20 PM, Patrick
Shirkey<pshirkey(a)boosthardware.com> wrote:
[ ableton live & max ]
That would be kind of sad if they have chosen not to
use JACK to enable
this integration as there must have been a lot of overlap in the code
design.
there isn't any really. they are embedding the max engine to live's
internals. jack's model doesn't really come into in any way. as usual,
the clever part is all in the GUI, where max-driven "objects" appear
to be exactly like "builtin" regular Live objects for processing etc.
3 Sep
3 Sep
12:11 a.m.
New subject: modular audio apps and control-communication was: off topic
On 09/03/2009 11:40 AM, Paul Davis wrote:
On Wed, Sep 2, 2009 at 8:20 PM, Patrick
Shirkey<pshirkey(a)boosthardware.com> wrote:
[ ableton live& max ]
So I guess they wanted things to be as tightly integrated as possible
for performance reasons?
Patrick Shirkey
Boost Hardware Ltd
That would be kind of sad if they have chosen not
to use JACK to enable
this integration as there must have been a lot of overlap in the code
design.
there isn't any really. they are embedding the max engine to live's
internals. jack's model doesn't really come into in any way. as usual,
the clever part is all in the GUI, where max-driven "objects" appear
to be exactly like "builtin" regular Live objects for processing etc.
12:24 a.m.
New subject: modular audio apps and control-communication was: off topic
On Wed, Sep 2, 2009 at 10:10 PM, Patrick
Shirkey<pshirkey(a)boosthardware.com> wrote:
So I guess they wanted things to be as tightly
integrated as possible for
performance reasons?
i had some extended conversations with one of ableton's founders about
this, and he talked about it in one of my classes at the TU.
basically, they wanted to tap into the "max crowd", however you
interpret that, which they felt that Live currently didn't do. they
saw/see a lot of skill and cool stuff going on with max that can't be
done in Live. their idea seems to have been to try to integrate that
as tightly as possble into Live, so that people who create cool max
patches can use them as if they were builtin processing objects in
Live. not "max connected to Live" (which is already possible with
JACK, and they know it). at present, there is no "distribution" system
for those patches, but that didn't seemed to be ruled out for the
future.
12:32 a.m.
New subject: modular audio apps and control-communication was: off topic
On Thu, Sep 3, 2009 at 12:24 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Wed, Sep 2, 2009 at 10:10 PM, Patrick
Shirkey<pshirkey(a)boosthardware.com> wrote:
That's the impression I got from the situation - they recognised that a
significant portion of the Max userbase were either already using Live +
Soundflower + Max (or some other kludge) or were interested in
interoperability.
This market seems pretty tightly pegged to the Apple platform. At least here
in Oz, Max users tend to pick it up at university, where there's pretty high
saturation of Apple hardware.
So I guess they wanted things to be as tightly
integrated as possible for
performance reasons?
i had some extended conversations with one of ableton's founders about
this, and he talked about it in one of my classes at the TU.
basically, they wanted to tap into the "max crowd", however you
interpret that, which they felt that Live currently didn't do. they
saw/see a lot of skill and cool stuff going on with max that can't be
done in Live. their idea seems to have been to try to integrate that
as tightly as possble into Live, so that people who create cool max
patches can use them as if they were builtin processing objects in
Live. not "max connected to Live" (which is already possible with
JACK, and they know it). at present, there is no "distribution" system
for those patches, but that didn't seemed to be ruled out for the
future.
12:43 a.m.
New subject: modular audio apps and control-communication was: off topic
On 09/03/2009 12:32 PM, Chris Wenn wrote:
On Thu, Sep 3, 2009 at 12:24 PM, Paul Davis
<paul(a)linuxaudiosystems.com <mailto:paul@linuxaudiosystems.com>> wrote:
On Wed, Sep 2, 2009 at 10:10 PM, Patrick
Shirkey<pshirkey(a)boosthardware.com
<mailto:pshirkey@boosthardware.com>> wrote:
So I guess as it's a market based decision then there is a slim
possibility of AL adding support for jack assuming the market is big
enough. Probalby not for another 5 years at least.
Patrick Shirkey
Boost Hardware Ltd
So I guess they wanted things to be as tightly
integrated as
possible for
performance reasons?
i had some extended conversations with one of ableton's founders about
this, and he talked about it in one of my classes at the TU.
basically, they wanted to tap into the "max crowd", however you
interpret that, which they felt that Live currently didn't do. they
saw/see a lot of skill and cool stuff going on with max that can't be
done in Live. their idea seems to have been to try to integrate that
as tightly as possble into Live, so that people who create cool max
patches can use them as if they were builtin processing objects in
Live. not "max connected to Live" (which is already possible with
JACK, and they know it). at present, there is no "distribution" system
for those patches, but that didn't seemed to be ruled out for the
future.
That's the impression I got from the situation - they recognised that
a significant portion of the Max userbase were either already using
Live + Soundflower + Max (or some other kludge) or were interested in
interoperability.
This market seems pretty tightly pegged to the Apple platform. At
least here in Oz, Max users tend to pick it up at university, where
there's pretty high saturation of Apple hardware.
------------------------------------------------------------------------
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
1:01 a.m.
New subject: modular audio apps and control-communication was: off topic
On Thu, 3 Sep 2009, sh0099 wrote:
i know OSC
but there is no communication standard for control data like jack for audio
and i think without this you can not modularise fully.
I think I see what you're getting at. Yes, would be nice to have such a
thing... and the thought has occurred to me over the past few days. I
think even Fons brought up something like this a year or two ago when he
was looking at adding JACK MIDI to Aeolus.
Peace,
Gabriel
2 Sep
2 Sep
10:08 p.m.
New subject: off topic (was: Re: ableton live in vmware)
On 09/03/2009 02:57 AM, Danni Coy wrote:
On Wed, Sep 2, 2009 at 11:30 PM, Niklas Klügel
<niklas.kluegel(a)mytum.de <mailto:niklas.kluegel@mytum.de>> wrote:
cunnilinux himself schrieb:
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world.
just to add my 2 cents...
regarding monolithic vs. modular (across applications):
while the latter (theoretically) allows for more flexibility of
processing, akin to the proven unix-concepts of pipelining (and
therefore the development of something jack-alike for audio/video etc
became an obvious evolution for -primarily- LAU/D), it does not allow
for certain common concepts in the workflow of composition and dsp.
technically - or at least _without hassle_. those include nearly all
operations that:
1a) allow you to temporarily bounce (aka freezing) parts of the signal
chain (tracks, single processed clips, subchannels) - thus saving cpu
cycles in rather complex arrangements.
This could happen if programs could be smart enough not to do audio
processing if there is no input signal and programs are able to trace
the signal path(s) till it(they) terminate(s) (either has no output
connections, makes itself to the system output connections (speakers),
or back into the application itself. The application could then
connect the terminating output(s) to the program input - do a
synchronised record (already possible), close off the signal path for
the processing version of the track and playback the recorded audio
instead.
How about having some kind of bounce notification for jack?
> Some people here (more or less) desperately
need a similar
application for linux.
Anyways I am glad you brought up those points... It is something
severely lacking in the current modular implementation that we have.
Doing things in a modular way through jackd has a lot of potential but
really requires some application managment features to really compete
with proprietory workflows.
I would love to see a control application that
1) lets you group applications....
2) the ability to remove/restore connections going in or out of a group.
3) the ability to clone a group.
4) the ability to save/restore groups of applications.
I think this is the direction we are heading so the more we can
contribute to the conceptualisation and technical aspects with this
discussion the better.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
3 Sep
3 Sep
5:23 a.m.
New subject: off topic (was: Re: ableton live in vmware)
Danni Coy schrieb:
On Wed, Sep 2, 2009 at 11:30 PM, Niklas Klügel
<niklas.kluegel(a)mytum.de <mailto:niklas.kluegel@mytum.de>> wrote:
cunnilinux himself schrieb:
off topic, but...
people in linux audio scene always DESPERATELY need something just
like a copy of some fancy (commercial) app on win/mac.
that's the main and only reason why linux is (semi-)deficient in the
pro audio world.
just to add my 2 cents...
regarding monolithic vs. modular (across applications):
while the latter (theoretically) allows for more flexibility of
processing, akin to the proven unix-concepts of pipelining (and
therefore the development of something jack-alike for audio/video etc
became an obvious evolution for -primarily- LAU/D), it does not allow
for certain common concepts in the workflow of composition and dsp.
technically - or at least _without hassle_. those include nearly all
operations that:
1a) allow you to temporarily bounce (aka freezing) parts of the signal
chain (tracks, single processed clips, subchannels) - thus saving cpu
cycles in rather complex arrangements.
This could happen if programs could be smart enough not to do audio
processing if there is no input signal and programs are able to trace
the signal path(s) till it(they) terminate(s) (either has no output
connections, makes itself to the system output connections (speakers),
or back into the application itself. The application could then
connect the terminating output(s) to the program input - do a
synchronised record (already possible), close off the signal path for
the processing version of the track and playback the recorded audio
instead.
1b) keep sequencing and time-information on
processed/bounced/re-recorded material
if the solution for 1 is enabled then this should also be possible.
1c) saving disk-space and processing time by recording only the
necessary parts of the bounce while still being a proper/correct
bounce.
this should also be possible. for inter application stuff this would
just require some form of dead air detection. Or am I missing
something here.
no nothing is missing. for external signals you might want to
follow the
volume amplitude very slowly and record until
the recorded signal has not changed for a certain period. for jack maybe
the flagging of input/output buffers as having been modified would be
sufficient.
> Some people here (more or less) desperately
need a similar
application for linux.
2) modifying a group of modules in the signal chain and the sequence
data e.g. cloning, deleting, replacing etc.
Cloning would be an interesting feature to have at the connection and
application management layer.
But providing that the applications are smart enough not to do
processing and that groups of applications could be saved and loaded
by the application that replaces Lash (LADI?)... All this should be
possible.
3) exchange meta-information such as the set of notes in a track
to e.g.
allow samplers to efficiently just load the samples needed to play the
track, prefetching large chunks of audio-data or sub-track tempi for
sync'd f/x.
This could potentially be done through dbus... and/or as an extension
to LV2 etc.
4) limit the amount of organization in 1x) and mixing units
(pre-/post-fx or mixer or sub-channels and modulation sources
across tracks)
I am sure you can come up with some more. Those are all points taken
care of in halfway sane, up-to-date DAWs that are monolithic and
points
like 1 & 2 are basic editing operations that - for me - increase the
efficiency by a factor of 4 in time spent fiddling with the
arrangement.
The early versions of Ableton didnt do 1) for example and my time
spent
on organizing heavy arrangements (30-50 tracks with lots of automated
f/x) was unbearable, not to mention that the quality of execution
of the
sequencing and composition itself suffered due to that.
5) of course easy recall of chains(+sequence data) etc
These points are of conceptual nature.
This I understand is the point of having something like LASH (LADI?)...
Anyways I am glad you brought up those points... It is something
severely lacking in the current modular implementation that we have.
Doing things in a modular way through jackd has a lot of potential but
really requires some application managment features to really compete
with proprietory workflows.
I would love to see a control application that
1) lets you group applications....
2) the ability to remove/restore connections going in or out of a group.
3) the ability to clone a group.
4) the ability to save/restore groups of applications.
technically, I
wholeheartedly agree that it is possible but my main
point was that those aren't trivial features to implement for a modular
environment :)
5603
days inactive
5606
days old
linux-audio-user@lists.linuxaudio.org
63 comments
29 participants
participants (29)
-
Atte Andre Jensen -
Bengt Gördén -
Brent Busby -
Brett McCoy -
Chris Wenn -
cunnilinux himself -
Danni Coy -
Dave Phillips -
Eric Steinberg -
Folderol -
Frank Barknecht -
Gabriel M. Beddingfield -
Grammostola Rosea -
Hartmut Noack -
hollunder＠gmx.at -
James Stone -
Ken Restivo -
Nedko Arnaudov -
Niklas Klügel -
Patrick Shirkey -
Paul Coccoli -
Paul Davis -
Ray Rashif -
Rob -
Robbert Latumahina -
Ronald Stewart -
Rui Nuno Capela -
sh0099 -
Thorsten Wilms