25 Feb
2004
25 Feb
'04
2:30 p.m.
Hello.
Recently Logic 6's Freeze feature was mentioned here, and Freeze
is mentioned in a new interview at Emagic's webpage:
Q: Any other favorite feature in Logic 6, that you use most?
Boris Blank [of Yello]: I think Freeze is ingenious. [ ... ]
I'm wondering did Emagic borrow the idea from this list, as the
freeze feature was discussed here at november 2001. And soon after
that the feature stands in their software.
((Anyone has Logic 6's PDF manuals? Evoc's manual? For research purposes.))
Regards,
Juhana
25 Feb
25 Feb
2:59 p.m.
On Wednesday 25 February 2004 20.25, Juhana Sadeharju wrote:
Hello.
Recently Logic 6's Freeze feature was mentioned here, and Freeze
is mentioned in a new interview at Emagic's webpage:
Q: Any other favorite feature in Logic 6, that you use most?
Boris Blank [of Yello]: I think Freeze is ingenious. [ ... ]
I'm wondering did Emagic borrow the idea from this list, as the
freeze feature was discussed here at november 2001. And soon after
that the feature stands in their software.
Me guesses you are referring to
this:[http://www.eca.cx/lad/2001/Nov/0310.html] message I posted back then.
I'd have to say that they where probably not influenced by that, if they where
their implementation would have been much more advanced and definitely cooler
;-P.
Besides, the ideas might have been new for audio purposes but the technology
in itself is not new. The ideas suggested where adaptations of similar
features in the 3d-graphics world. Logic may very well have peeked that way
too.
I still think about this from time to time and I would really like to see a
REAL implementation of the proposal. :-)
/Robert
3:04 p.m.
Me guesses you are referring to
this:[http://www.eca.cx/lad/2001/Nov/0310.html] message I posted back then.
I'd have to say that they where probably not influenced by that
Oh, skipping through the entire thread, the post by Nelson Posse Lago comes
scaringly close to describing freeze.
Kinda makes you wonder...
/Robert
4:47 p.m.
On Wednesday 25 February 2004 01:52 pm, Robert Jonsson wrote:
On Wednesday 25 February 2004 20.25, Juhana Sadeharju
wrote:
So would I - and I'm actively working on it. After spending about a year
planning, revising, and thinking, I've finally started coding an audio
compositing system based on a hierarchal tree structure. Right now, the
program simply replicates an on-disk directory structure in memory, and then
terminates, but I've only been working on the code for a couple of weeks -
and only 1 or 2 days per week. Now that I'm over some of the initial hurdles
(such as figuring out GNU auto-tools), I'll be introducing *basic* JACK
functionality over the next couple of days. FWIW, the sf.net project page is
at:
http://sourceforge.net/projects/tinara/
As I said, there isn't much there right now, but I'd be happy to set up a
mailing list if anyone is interested. If not, I'll certainly make an
announcement when I make an alpha release. If you take a browse through CVS,
be aware that my "scratchpad" lacks some very significant design ideas and
plans, including a potential GUI design which is currently documented only on
a dry-erase board ;)
|)
|)enji
Hello.
Recently Logic 6's Freeze feature was mentioned here, and Freeze
is mentioned in a new interview at Emagic's webpage:
Q: Any other favorite feature in Logic 6, that you use most?
Boris Blank [of Yello]: I think Freeze is ingenious. [ ... ]
I'm wondering did Emagic borrow the idea from this list, as the
freeze feature was discussed here at november 2001. And soon after
that the feature stands in their software.
Me guesses you are referring to
this:[http://www.eca.cx/lad/2001/Nov/0310.html] message I posted back then.
I'd have to say that they where probably not influenced by that, if they
where their implementation would have been much more advanced and
definitely cooler ;-P.
Besides, the ideas might have been new for audio purposes but the
technology in itself is not new. The ideas suggested where adaptations of
similar features in the 3d-graphics world. Logic may very well have peeked
that way too.
I still think about this from time to time and I would really like to see a
REAL implementation of the proposal. :-) 
5:05 p.m.
> I still think about this from time to time and I
would really like to see a
> REAL implementation of the proposal. :-)
ardour basically allows this already, although it is not
automatic. there is no way to know what the user wants, so we leave up
to the user to initiate "freezing" any particular track. you cannot
"freeze" a bus since it may receive input from outside of ardour.
--p
5:32 p.m.
onsdagen den 25 februari 2004 23.00 skrev Paul Davis:
Yes, so I've heard, and that's really great.
It was, however, the automatic merits that I wished mainly to explore.
Freezing has it's merits, but it requires that you dedicate some brain cycles
to deciding when and where you wish to freeze/unfreeze something. I could
sure use those cycles for keeping creativity flowing.
... and I do think you can freeze a bus, but it requires that the app has full
knowledge of the connection graph. Mmmm, I see a jack extension forming ;))
/Robert
> I still
think about this from time to time and I would really like to
> see a REAL implementation of the proposal. :-)
ardour basically allows this already, although it is not
automatic. there is no way to know what the user wants, so we leave up
to the user to initiate "freezing" any particular track. you cannot
"freeze" a bus since it may receive input from outside of ardour.
26 Feb
26 Feb
10:09 a.m.
It was, however, the automatic merits that I wished
mainly to explore.
Freezing has it's merits, but it requires that you dedicate some brain cycles
to deciding when and where you wish to freeze/unfreeze something. I could
sure use those cycles for keeping creativity flowing.
remember: freezing has no merits at all unless you need to save CPU cycles.
the problem is that in a typical DAW session, you can potentially
freeze most tracks most of the time. so how can you tell what the user
wants frozen and what they don't? More importantly, freezing consumes
significant disk resources. Can you afford to do this without it being
initiated by the user? A typical 24 track Ardour session might consume
4-18GB of audio. Freezing all or most of it will double that disk
consumption (and its not exactly what you would call quick, either :)
thus, either you have s/w smart enough to figure out what to freeze
and then do it, which does not come without certain costs, or the user
has to play a significant role in the process.
... and I do think you can freeze a bus, but it
requires that the app has full
knowledge of the connection graph. Mmmm, I see a jack extension forming ;))
sorry, but i don't think so. if i have a bus that is channelling audio
in from an external device (say, a h/w sampler), you cannot possibly
freeze it.
--p
10:22 a.m.
On Thu, Feb 26, 2004 at 10:04:47AM -0500, Paul Davis wrote:
the problem is that in a typical DAW session, you can
potentially
freeze most tracks most of the time. so how can you tell what the user
wants frozen and what they don't? More importantly, freezing consumes
significant disk resources. Can you afford to do this without it being
initiated by the user? A typical 24 track Ardour session might consume
4-18GB of audio. Freezing all or most of it will double that disk
consumption (and its not exactly what you would call quick, either :)
No, but you can do it (semi-)transparently when the user presses play. I
dont know if that would be acceptable or not, but if you imagine adding a
few effeects, auditioning, rinse, repeat it might work out ok.
I'd always go for more CPU if possible - I'm not a huge fan of multiple
code paths :)
- Steve
11:09 a.m.
On Thursday 26 February 2004 09:04 am, Paul Davis wrote:
the problem is that in a typical DAW session, you can
potentially
freeze most tracks most of the time. so how can you tell what the user
wants frozen and what they don't?
I want my plug-ins frozen the instant I close the parameter editor. ;)
More importantly, freezing consumes
significant disk resources. Can you afford to do this without it being
initiated by the user? A typical 24 track Ardour session might consume
4-18GB of audio. Freezing all or most of it will double that disk
consumption (and its not exactly what you would call quick, either :)
Agreed, it's a very definite trade-off - storage space for CPU cycles.
It is my observation, however, that storage space is cheap, and readilly
available.
sorry, but i don't think so. if i have a bus that
is channelling audio
in from an external device (say, a h/w sampler), you cannot possibly
freeze it.
However, buses which simply contain a submix of several audio tracks can
be safely frozen, saving both processing power and disk bandwidth.
The purpose of my project is to create a working environment which
encourages songs to be organized in such a way that offline rendering can
*usually* be done transparently. Thus, the hierarchal tree structure.
When I finish comping the vocals for a chorus, I want to be left with 1
fader, and 1 editable audio track, for the chorus. If I need to make one of
the voices softer, I can bring up the underlying tracks within a second
(which is *at least* how long it usually takes me to find a single fader in a
48-channel mix). While I'm making adjustments, Tinara will read all the
separate chorus tracks off the disk, mixing them in RT. When I move back one
layer in the mix hierarchy (thereby indicating that I'm finish adjusting
things), Tinara will begin re-rendering the submix in the background whenever
the transport is idle. When the re-rendering is done, Tinara will go back to
pulling a single interleaved stereo track off the disk, instead of 6-8 mono
tracks.
The basic idea is to turn mixing into a process of simplification. When
I'm finishing up a mix, I don't want to deal with a mess of tracks and buses,
with CPU power and disk bandwidth being given to things I haven't changed in
days. I want to be able to focus on the particular element or submix that
I'm fine-tuning - and have as much DSP power to throw at it as possible.
This will also make the use of automated control surfaces much nicer,
IMHO. Since there will be fewer elements in each layer of the hierarchy,
fewer faders would be needed. Additionally, it would be easier to keep track
of what's going on. I've worked extensively with Digi Design's Control|24,
and my feeling is that things start to get messy when there are more than
about 12 faders (not to mention how easy it is to get lost when there are two
or more banks of 24 faders!).
Just for the record, please understand that any negativity I may express
toward conventional DAW systems is *not* directed toward Ardour. It's just
pent-up frustration with Pro Tools ;)
|)
|)enji
11:30 a.m.
I want my plug-ins frozen the instant I close the
parameter editor. ;)
oh, you don't want to do any graphical editing of plugin parameter
automation? :))
Agreed, it's a very definite trade-off -
storage space for CPU cycles.
It is my observation, however, that storage space is cheap, and readilly
available.
not my experience.
sorry, but i
don't think so. if i have a bus that is channelling audio
in from an external device (say, a h/w sampler), you cannot possibly
freeze it.
However, buses which simply contain a submix of several audio tracks can
be safely frozen, saving both processing power and disk bandwidth. When I finish comping the vocals for a chorus, I
want to be left with 1
fader, and 1 editable audio track, for the chorus. If I need to make one of
the voices softer, I can bring up the underlying tracks within a second
(which is *at least* how long it usually takes me to find a single fader in a
48-channel mix). While I'm making adjustments, Tinara will read all the
separate chorus tracks off the disk, mixing them in RT. When I move back one
layer in the mix hierarchy (thereby indicating that I'm finish adjusting
things), Tinara will begin re-rendering the submix in the background whenever
the transport is idle.
have you actually experienced how long it takes to "re-render"?
steve's suggestion is an interesting one (use regular playback to
render), but it seems to assume that the user will play the session
from start to finish. if you're mixing, the chances are that you will
be playing bits and pieces of of the session. so when do you get a
chance to re-render? are you going to tie up disk bandwidth and CPU
cycles while the user thinks they are just editing? OK, so you do it
when the transport is idle - my experience is that you won't be done
rendering for a long time, and you're also going to create a suprising
experience for the user at some point - CPU utilization will vary
notable over time, in ways that the user can't predict.
you also seem to assume that the transport being stopped implies no
audio streaming by the program. in ardour (and most other DAWs), this
simply isn't true. ardour's CPU utilization doesn't vary very much
whether the transport is idle or not, unless you have a lot of track
automation, in which case it will go up a bit when rolling.
The basic idea is to turn mixing into a process of
simplification. When
I'm finishing up a mix, I don't want to deal with a mess of tracks and buses,
with CPU power and disk bandwidth being given to things I haven't changed in
days. I want to be able to focus on the particular element or submix that
I'm fine-tuning - and have as much DSP power to throw at it as possible.
the focusing part seems great, but seems to be more of a GUI issue
than a fundamental backend one. it would be quite easy in ardour, for
example, to have a way to easily toggle track+strip views rather than
display them all.
the DSP power part seems like a good idea, but i think its much, much
more difficult than you are anticipating. i've been wrong many times
before though.
and btw, the reason Ardour looks a lot like PT is that it makes it
accessible to many existing users. whether or not ardour's internal
design looks like PT, i don't know. i would hope that ardour's
development process has allowed us to end up with a much more powerful
and flexible set of internal objects that can allow many different
models for editing, mixing and so forth to be constructed. the backend
isn't particularly closely connected in any sense, including the
object level, to the GUI.
--p
12:57 p.m.
On Thursday 26 February 2004 10:25 am, Paul Davis wrote:
Well then - as soon as I stop editing the automation data ;)
It's a renewable resource. When I archive a multi-gigabyte song, I have
more storage space. My CPU power stays the same, however. It's also
(generally) easy to throw in another hard drive - giving me the storage I had
before *plus* whatever I've added. If I change the CPU, the old one
(normally) can't contribute DSP anymore.
I want my
plug-ins frozen the instant I close the parameter editor.
;)
oh, you don't want to do any graphical editing of plugin parameter
automation? :)) Agreed,
it's a very definite trade-off - storage space for CPU
cycles. It is my observation, however, that storage space is cheap, and
readilly available.
not my experience. sure, but thats a subset of all busses. its not a bus
per se.
It's not terribly common right now because lots of extra aux inputs make
for a bulkier and harder-to-manage mix. Effects sends would be less
important when working with a tree structure, because the impact of the
inherent DSP savings would be diminished by offline rendering.
have you actually experienced how long it takes to
"re-render"?
steve's suggestion is an interesting one (use regular playback to
render), but it seems to assume that the user will play the session
from start to finish. if you're mixing, the chances are that you will
be playing bits and pieces of of the session. so when do you get a
chance to re-render? are you going to tie up disk bandwidth and CPU
cycles while the user thinks they are just editing? OK, so you do it
when the transport is idle - my experience is that you won't be done
rendering for a long time, and you're also going to create a suprising
experience for the user at some point - CPU utilization will vary
notable over time, in ways that the user can't predict.
You bring up some interesting points here. One thing I hadn't mentioned
is that Tinara is intended for eventual use with a render farm. I quickly
realized, however, that it needed to be capable of running on a single
machine - if only for testing purposes. Understand, therefore, that local
offline rendering in this project is little more than a stopgap measure. The
question of when rendering takes place on a local machine is one which I've
changed my mind on countless times. I'd played with the idea of writing live
playback to the disk as a rendering technique, but things like reverbs need
to be processed in an uninterrupted stream.
I admit that the idea of stopping rendering when playback starts was
short-sighted. I tend to spend a lot of time editing, and this clouded my
thinking. As previously stated, however, I've changed my mind on this kind
of thing quite often - particularly over the past couple of weeks.
you also seem to assume that the transport being
stopped implies no
audio streaming by the program. in ardour (and most other DAWs), this
simply isn't true. ardour's CPU utilization doesn't vary very much
whether the transport is idle or not, unless you have a lot of track
automation, in which case it will go up a bit when rolling.
I'm aware of this - Pro Tools is the same way. The decision to stop
processing when the transport is stopped was based on two factors:
1. It allows more DSP power for local offline rendering.
2. Things like reverb will stop with the transport anyway, once they've been
rendered. I thought the behavior should be as consistent as possible.
OTOH, it would be nice to hear the reverb tail while editing the
parameters - so maybe this wasn't such a good idea after all. In fact, I
think you've talked me out of it :)
the focusing part seems great, but seems to be more of
a GUI issue
than a fundamental backend one. it would be quite easy in ardour, for
example, to have a way to easily toggle track+strip views rather than
display them all.
There are other reasons for the tree structure. It makes it very easy to
navigate to a particular audio element, and process it with an external
program. It also allows storage and organization of non-audio data, such as
Csound instruments or Hydrogen songs, inside the same directory hierarchy.
You could, for instance, store the Hydrogen song right inside the Drums
branch, and a future version of Tinara could automatically open the file in a
future version of Hydrogen, connecting the two applications via JACK.
I looked very seriously at trying to implement the things I want in
Ardour. My conclusion, however, was that there are some fundmental design
differences which would make some of my overall goals impractical. (More on
this below).
the DSP power part seems like a good idea, but i think
its much, much
more difficult than you are anticipating. i've been wrong many times
before though.
It will be very difficult - but it's the program I've been wanting to use
for years. Now that I've started, I'm highly motivated to see it through :)
and btw, the reason Ardour looks a lot like PT is that
it makes it
accessible to many existing users. whether or not ardour's internal
design looks like PT, i don't know. i would hope that ardour's
development process has allowed us to end up with a much more powerful
and flexible set of internal objects that can allow many different
models for editing, mixing and so forth to be constructed. the backend
isn't particularly closely connected in any sense, including the
object level, to the GUI.
Part of the reason I'm skeptical of using Ardour as a foundation for what
I'm trying to do, is that I think there are some fundamental differences in
what we are trying to accomplish.
Ardour is intended to function as a real-time DAW, with offline rendering
capabilities. Tinara is intended to be an offline compositing system, with a
front-end for editing and real-time previewing - which may sometimes be lower
quality than the final rendered result.
Ardour is a DAW system with many powerful new features, which still
remains comfortably familiar to users of other high-end audio applications (I
consider this a Very Good Thing(TM) BTW). Tinara is a node-based compositing
system which would probably be of little interest to most experienced DAW
users - it will require a different working style, and it will require
thinking about editing, mixing, and processing, in a fundmentally different
way, if it is to be used effectively.
Ultimately, Ardour is what the audio industry wants, and Tinara is what I
want ;) I may yet end up deciding to use parts of Ardour for things like
live disk streaming, but I think both projects have something to offer which
is unique enough to justify separate development.
|)
|)enji
1:22 p.m.
torsdagen den 26 februari 2004 17.54 skrev Benjamin Flaming:
... and Tinara is what I want ;)
I want that too, are you a mind reader? :-o
A bit more seriously, offline rendering in a tree graph works for 3d editing,
and has worked for a number of years. I think it's a natural progression to
try the same concepts on audio.
In the end it might be that realtime resources (e.g. waiting times to get
tracks rendered) are the limiting factor and then we've won nothing. But we
won't know for sure until we test it.
I for one will be watching closely.
/Robert
1:31 p.m.
A bit more seriously, offline rendering in a tree graph
works for 3d editing,
and has worked for a number of years. I think it's a natural progression to
try the same concepts on audio.
with the greatest respect, this is how audio used to be done and still
is for some purposes. just think of working on a long Csound
composition ...
1:55 p.m.
On Thursday 26 February 2004 12:26 pm, Paul Davis wrote:
Actually, the basic concept idea of Tinara predates 3d graphics, and even
predates computer-based music production entirely, AFAIK. It's just like
ping-ponging tracks and printing effects on multi-track tape machines. The
difference now is that we don't lose any (significant) quality by doing this,
and we have the ability to go back to the original at any time.
Additionally, the tree structure would things managable, even if dealing with
a couple hundred elements.
Trees just strike me as a more natural way to organize a song. The "Mix
Window/Edit Window" style feels too linear to me. Just personal preferences,
I guess :)
|)
|)enji
A bit more
seriously, offline rendering in a tree graph works for 3d
editing, and has worked for a number of years. I think it's a natural
progression to try the same concepts on audio.
with the greatest respect, this is how audio used to be done and still
is for some purposes. just think of working on a long Csound
composition ...
1:59 p.m.
On Thursday 26 February 2004 12:22 pm, Robert Jonsson wrote:
torsdagen den 26 februari 2004 17.54 skrev Benjamin
Flaming:
Yes, and I knew you were going to ask....
In all honesty, I was thrilled when your original message was pointed out
in a thread several months ago. It was great to know that someone else was
thinking along the same lines. It gives me hope that I might not be the only
person ever to use Tinara ;)
|)
|)enji
... and Tinara is what I want ;)
I want that too, are you a mind reader? :-o
2:07 p.m.
On Thu, Feb 26, 2004 at 11:25:33AM -0500, Paul Davis wrote:
OT, pointless observation of the week:
300 bytes of 7200rpm, ATA133 etc. IDE storage cost the same as 1 grain of
sand.
sand = UKP 15.00 per tonne
disk = UKP 0.50 per GB
- Steve
I want my
plug-ins frozen the instant I close the parameter editor. ;)
oh, you don't want to do any graphical editing of plugin parameter
automation? :))
Agreed, it's a very definite trade-off -
storage space for CPU cycles.
It is my observation, however, that storage space is cheap, and readilly
available.
not my experience.
2:34 p.m.
It is my observation, however, that storage space is
cheap, and readilly
available.
not my experience.
7616
days inactive
7617
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
5 participants
participants (5)
-
Benjamin Flaming -
Juhana Sadeharju -
Paul Davis -
Robert Jonsson -
Steve Harris