11 Nov
2016
11 Nov
'16
9:39 a.m.
Hi all,
I was recently thinking about how powerful, yet maybe underestimated,
the JCAK freewheel mode [1] is.
As far as I know this is used by Ardour, Qtractor and MusE for
export/bounce, 'internally'.
Call me old school, but I like to use various (lots) of audio software
on Linux in a modular way. I have stated many times that, in my humble
opinion, modularity plus inter-connectability of applications though
JACK is, from a creative point of view, a killer feature.
So, coming to the freewheel point. Wouldn't it be great if 'all jack
audio' software were freewheel-ready, so that if I activate a switch,
all applications enter freewheel mode and when I activate recording in
my favourite DAW, connected to some of my favourite (standalone!)
synths, connected to my favourite sequencer, everything is recorded
'faster than realtime' in the DAW?
Or also: isn't it startling that in the digital era one should 'record'
stuff internally in real-time??
What kind of work/burden would becoming freewheel-ready pose on existing
applications?
I do can see some cases where this just wouldn't work or might not even
be desirable: for example Pure Data and similar software which by
definition is realtime.
Hopefully this can start some (civilized!) debate on the topic and it
also includes other topics such as (creative) workflow, etc.
Lorenzo.
[1]
http://www.jackaudio.org/api/group__ServerControl.html#gad65c741a1d1d2fb09e…
11 Nov
11 Nov
10:55 a.m.
I guess the advantage of export features is, that it works around
software and user errors, when recording within a studio in the box.
This is a good thing. I guess it doesn't matter that it is faster, than
recording in real-time, at least not for music productions. Sure, to
finish a radio report, it's good, if it could be done faster than
real-time, but making art shouldn't follow this fast foot approach. IMO
making art, just using one tool is boring. If you make an airbrush
painting, you need to draw with brushes, too, otherwise it looks
uninteresting. If you use a DAW to master music, you could add artistic
quality by a real-time recording, when using external gear, too. The
reason for this is that diversity is better than inbreeding. I can't
imagine something more boring, than "done with Linux only". And when
making art, we should not care that much about saving of time. Making
music is like having sex, it's better, if it's done in real-time,
nobody wants to make love faster than real-time.
Résumé
Yes, it's good to have an export feature, because it's faster, to
finish work, such as a radio report.
Yes, it's good to have this feature for music productions, to work
around software and user errors.
No, it's counter-productive to save time, when making art.
No, while it's true that your idea is about adding external virtual
software from the same machine to the all-in-one DAW, it still
excludes external gear. You quasi could ask, should all software
available for Linux audio, also be available as a plug in for a
all-in-one DAW. Yes, this would be nice ;) and IMO the better approach
for the studio in the box.
Regards,
Ralf
11:17 a.m.
On 11/11/2016 09:39 AM, Lorenzo Sutton wrote:
Hi all,
Hi Lorenzo,
Thanks for brining this up.
[..]
So, coming to the freewheel point. Wouldn't it be
great if 'all jack
audio' software were freewheel-ready, so that if I activate a switch,
all applications enter freewheel mode and when I activate recording in
my favourite DAW, connected to some of my favourite (standalone!)
There are a couple of jack applications that do support freewheeling,
other than the big-players that you've mentioned. e.g. Carla.
synths, connected to my favourite sequencer,
everything is recorded
'faster than realtime' in the DAW?
Or also: isn't it startling that in the digital era one should 'record'
stuff internally in real-time??
What kind of work/burden would becoming freewheel-ready pose on existing
applications?
It depends on the application in question. Can range from trivial to
major-redesign.
When freewheeling the process-callback needs to block until all work is
done. It's no longer realtime, so file-I/O, locks and similar operations
are allowed. In some cases it can be relatively simple: just add a lock
and wait for the inertial work to complete.
In other cases freewheeling makes no sense (e.g. live-stream or
instrument-tuners). Most of those apps could just switch into a "don't
do anyting" mode and re-sync afterward (good example: zita-ajbridge).
The main problem will be applications that use alsa-midi to communicate
with external synths. freewheeling needs jack-midi.
I do can see some cases where this just wouldn't
work or might not even
be desirable: for example Pure Data and similar software which by
definition is realtime.
I don't think Pd is inherently linked to wall-clock, but you might be
right: the devil is the detail.
On the upside, DSP that is designed for LV2 gets this free house: the
LV2 worker-thread automatically becomes in-sync when freewheeling.
Hopefully this can start some (civilized!) debate on
the topic and it
also includes other topics such as (creative) workflow, etc.
I suggest to file feature requests specifically for projects that you
care about.
One point that I also deem important is that even if some app cannot or
will not support freewheel processing, it should at least not get in the
way of other jack apps doing so.
ciao,
robin
6:48 p.m.
On Fri, 11 Nov 2016, Lorenzo Sutton wrote:
I was recently thinking about how powerful, yet maybe
underestimated, the
JCAK freewheel mode [1] is.
As far as I know this is used by Ardour, Qtractor and MusE for export/bounce,
'internally'.
Call me old school, but I like to use various (lots) of audio software on
Linux in a modular way. I have stated many times that, in my humble opinion,
modularity plus inter-connectability of applications though JACK is, from a
creative point of view, a killer feature.
So, coming to the freewheel point. Wouldn't it be great if 'all jack audio'
software were freewheel-ready, so that if I activate a switch, all
applications enter freewheel mode and when I activate recording in my
favourite DAW, connected to some of my favourite (standalone!) synths,
connected to my favourite sequencer, everything is recorded 'faster than
realtime' in the DAW?
As far as I know, most of this should be possible right now. Jack does
tell all clients when it enters freewheel. Really what is the difference
from freewheel to real time? Each client still spends the same time
processing as based on the same SR. Jack just doesn't wait for the
hardware to catch up at the end of each cycle (or doesn't worry about
being on time for the HW) but rather starts the next cycle imediately. So
long as the client is not connected to any HW, there should not need to be
any changes. Really, all a client needs to do for freewheel is make sure
it is not connected to HW.
On the practical side, what does freewheel gain? No monitoring is
possible, and any feewheel process results in changes that in general
can't be changed without redoing whatever was done in freewheel. So the
user must listen to the input in real time and then the output in real
time for QA. So it still limits freewheel to exports or track
consolidation. The one other possibility I can see is creating a track
with a synth that requires more horsepower than the CPU provides. So MIDI
out from DAW to expensive (standalone) synth. Audio from the synth back in
to DAW to be recorded. In this case the freewheel process might be much
longer than real time and could even include swap events. making music
from a program could be done this way too. Though I would think live
programming is more common.
The way to think of this is to use Audacity for a bit. All effects are
done outside of real time. Take the audio do the effect then listen. The
result is destructive. But, there are effects such as (some) noise
reduction that can be done no other way too. There may be some effect that
requires knowing the input performance from end to end in order to
calculate it. So most freewheel stuff would take longer to do rather than
shorter. It would be possible to even use some process that requires more
than one pass to complete (don't change anything between passes).
--
Len Ovens
www.ovenwerks.net
7:37 p.m.
On 11/11/2016 06:48 PM, Len Ovens wrote:
As far as I know, most of this should be possible right now. Jack does
tell all clients when it enters freewheel. Really what is the difference
from freewheel to real time? Each client still spends the same time
processing as based on the same SR.
Every application that uses ringbuffers to decouple the process callback
from actual processing will fall over if freewheeling is not special cased.
There are more than a couple of jack-apps that process in background
thread(s) (e.g. convolvers), not to mention synths that stream from disk
or capture apps that write to disk.
On the practical side, what does freewheel gain?
e.g. Export a 90 min soundtrack (or podcast or concert,..) in just under
5 minutes (or thereabouts; ~ 1.0 / DSP-load faster, export usually also
happens with larger buffers with decreases DSP load)
ciao,
robin
7:55 p.m.
On Fri, 11 Nov 2016 19:37:32 +0100
Robin Gareus <robin(a)gareus.org> wrote:
On 11/11/2016 06:48 PM, Len Ovens wrote:
Interesting.
Presumably that means things like live mixing are out. Change a fader and
you've no idea where it will actually appear in the final audio :(
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
As far as I know, most of this should be possible right now. Jack does
tell all clients when it enters freewheel. Really what is the difference
from freewheel to real time? Each client still spends the same time
processing as based on the same SR.
Every application that uses ringbuffers to decouple the process callback
from actual processing will fall over if freewheeling is not special cased.
There are more than a couple of jack-apps that process in background
thread(s) (e.g. convolvers), not to mention synths that stream from disk
or capture apps that write to disk.
On the practical side, what does freewheel gain?
e.g. Export a 90 min soundtrack (or podcast or concert,..) in just under
5 minutes (or thereabouts; ~ 1.0 / DSP-load faster, export usually also
happens with larger buffers with decreases DSP load)
ciao,
robin
8:16 p.m.
On 11/11/2016 07:55 PM, Will Godfrey wrote:
Interesting.
Presumably that means things like live mixing are out.
Yes, in case of soundtacks you do all the mixing beforehand anyway.
On the practical side, what does freewheel gain?
e.g. Export a 90 min soundtrack (or podcast or concert,..) in just under
5 minutes (or thereabouts; ~ 1.0 / DSP-load faster, export usually also
happens with larger buffers with decreases DSP load)
ciao,
robin Change a fader and
you've no idea where it will actually appear in the final audio :(
Since freewheeling decouples jack from the hardware, the fader's signal
goes nowhere.
In Ardour's case you can't touch any GUI control while exporting, but
yes, if you could then sure. Still that's besides the point, just go and
smoke a cigarette while things are exporting.
I had this a couple of times. A Very long session, then next iteration
of sound-design a small change somewhere around 01:12:00:00 is needed ..
and I don't want to wait for 90+ min only to bounce the whole thing
again. That'd be half a a pack of cigarettes :)
2c,
robin
13 Nov
13 Nov
9:44 a.m.
Hi all,
Thanks for the great input and very interesting insights.
I think Robin nailed exactly the kind of scenario I was thinking of.
In my case it's mostly recording into Ardour for the soundtrack I've
been working on for about 10 months.
I understand my workflow is probably a bit corner case, but being able
to speed-up inter-application recording would have been nice simply
because in Ardour I would then do mixing, effects and more.
So in the sequencer I would be doing the more musical/compositional
aspects (in sync with the video), obviously trying to get the overall
timbre aspects as near as possible as my idea/feel, but usually
preferring dry instruments.
In Ardour I may be adding small sound 'design' effects/details (e.g. a
reverse cymbal sample to) and fine-synchronize stuff (I am a bit of a
maniac when it comes to syncs working with video).
So, to respond to people talking about manual mixing/listening... still
a lot of that and manual crafting down to the (video) frame!
But the general idea is that digital-to-digital would be as efficient
(and fast) as possible, exactly to concentrate on the more creative parts :)
Lorenzo.
PS: Besides the topic, I wonder if proposing something (a workshop?)
about this workflow/experinca at LAC2017 might be of interest to the
community... Saint-Etienne is an alluring location :)
On 11/11/16 20:15, Robin Gareus wrote:
On 11/11/2016 07:55 PM, Will Godfrey wrote:
Interesting.
Presumably that means things like live mixing are out.
Yes, in case of soundtacks you do all the mixing beforehand anyway.
On the practical side, what does freewheel gain?
e.g. Export a 90 min soundtrack (or podcast or concert,..) in just under
5 minutes (or thereabouts; ~ 1.0 / DSP-load faster, export usually also
happens with larger buffers with decreases DSP load)
ciao,
robin Change a fader and
you've no idea where it will actually appear in the final audio :(
Since freewheeling decouples jack from the hardware, the fader's signal
goes nowhere.
In Ardour's case you can't touch any GUI control while exporting, but
yes, if you could then sure. Still that's besides the point, just go and
smoke a cigarette while things are exporting.
I had this a couple of times. A Very long session, then next iteration
of sound-design a small change somewhere around 01:12:00:00 is needed ..
and I don't want to wait for 90+ min only to bounce the whole thing
again. That'd be half a a pack of cigarettes :)
2c,
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
15 Nov
15 Nov
6:34 p.m.
On Sun, 13 Nov 2016 09:44:08 +0100
Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote:
<snip>
Lorenzo.
PS: Besides the topic, I wonder if proposing something (a workshop?)
about this workflow/experinca at LAC2017 might be of interest to the
community... Saint-Etienne is an alluring location :)
Certainly of interest to me :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
11 Nov
11 Nov
8:32 p.m.
On Fri, Nov 11, 2016 at 07:37:32PM +0100, Robin Gareus wrote:
Every application that uses ringbuffers to decouple
the process callback
from actual processing will fall over if freewheeling is not special cased.
There are more than a couple of jack-apps that process in background
thread(s) (e.g. convolvers), not to mention synths that stream from disk
or capture apps that write to disk.
In all these cases it's not so difficult to allow freewheeling.
Jconvolver for example should not have problems with it even
when using a number of lower-priority threads to do most of the
work. Any convolution app using zita-convolver can do the same,
it's just a boolean argument to process().
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
2931
days inactive
2935
days old
linux-audio-user@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Fons Adriaensen -
Len Ovens -
Lorenzo Sutton -
Ralf Mardorf -
Robin Gareus -
Will Godfrey