20 Nov
2011
20 Nov
'11
4:15 a.m.
Just wondering if I understand this correctly. I making a loop based app
for step sequencing. When I previously did this in Csound, I clocked it off
a phasor, so the timing was sample accurate ( but that brought all it's own
issues to be sure ). I'm wondering whether I should do the same thing in
jack app, or use the jack transport clock, or some hybrid.
My question, am I correct in understanding that if I use the jack transport
position to rewind in time, I'll get:
C) any other clients with running audio looping back to ( may or may not be
desirable )
B) a jitter based on the amount of time left between when the loop should
end and the end of the frame buffer in which the loop length runs out?
Has anyone solved B? Could it be done by some complex tempo cheating trick?
Does anyone have any methods they've used for tight timing of looping in a
jack app?
Pointers at code appreciated of course. =)
thank!
Iain
20 Nov
20 Nov
4:19 a.m.
On Sat, Nov 19, 2011 at 10:15 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Just wondering if I understand this correctly. I
making a loop based app for
step sequencing. When I previously did this in Csound, I clocked it off a
phasor, so the timing was sample accurate ( but that brought all it's own
issues to be sure ). I'm wondering whether I should do the same thing in
jack app, or use the jack transport clock, or some hybrid.
there was a proposal many (*many*) years ago from jesse chappell that
fully covered looping with JACK. it was never implemented. as it
stands, it is not possible to get seamless looping with jack
transport. in practice it might sound right for a given user with a
given set of clients, but change any aspect of the configuration and
it would no longer be seamless.
4:23 a.m.
On Sat, Nov 19, 2011 at 7:19 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Sat, Nov 19, 2011 at 10:15 PM, Iain Duncan
<iainduncanlists(a)gmail.com>
wrote:
Thanks, I know you did some stuff with this with your old step sequencer.
Do you think it's better to just ignore moving around the jack transport
and do my looping internally to my app only? If there are known issues that
I'm just going to discover the hard ware, might as well save time not
barking up the wrong tree.
thanks
iain
Just wondering if I understand this correctly. I
making a loop based app
for
step sequencing. When I previously did this in
Csound, I clocked it off a
phasor, so the timing was sample accurate ( but that brought all it's own
issues to be sure ). I'm wondering whether I should do the same thing in
jack app, or use the jack transport clock, or some hybrid.
there was a proposal many (*many*) years ago from jesse chappell that
fully covered looping with JACK. it was never implemented. as it
stands, it is not possible to get seamless looping with jack
transport. in practice it might sound right for a given user with a
given set of clients, but change any aspect of the configuration and
it would no longer be seamless.
4:34 a.m.
On Sat, Nov 19, 2011 at 7:23 PM, Iain Duncan <iainduncanlists(a)gmail.com>wrote;wrote:
On Sat, Nov 19, 2011 at 7:19 PM, Paul Davis
<paul(a)linuxaudiosystems.com>wrote;wrote:
Also, is that proposal a dead duck now? Seems to me like if it worked, it
would be a pretty killer feature given the popularity of the Ableton Live
style of working these days.
Has anyone else looked into it since then?
thanks
iain
On Sat, Nov 19, 2011 at 10:15 PM, Iain Duncan
<iainduncanlists(a)gmail.com>
wrote:
Just wondering if I understand this correctly. I
making a loop based
app for
step sequencing. When I previously did this in
Csound, I clocked it off
a
phasor, so the timing was sample accurate ( but
that brought all it's
own
issues to be sure ). I'm wondering whether I
should do the same thing in
jack app, or use the jack transport clock, or some hybrid.
there was a proposal many (*many*) years ago from jesse chappell that
fully covered looping with JACK. it was never implemented. as it
stands, it is not possible to get seamless looping with jack
transport. in practice it might sound right for a given user with a
given set of clients, but change any aspect of the configuration and
it would no longer be seamless.
2:10 p.m.
On Sat, Nov 19, 2011 at 10:34 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Also, is that proposal a dead duck now?
No, its not a dead duck. But there is little to no manpower around to
do an initial implementation so that it can be evaluated beyond paper.
Seems to me like if it worked, it
would be a pretty killer feature given the popularity of the Ableton Live
style of working these days.
If you think that JACK transport looping has anything to do with the
Live workflow, then sad to say but you either don't get jack transport
or Live or both :)
Many people look at Live and do not realize the sophistication of what
they are doing. It has very little to do with the ability to set a
global loop.
--p
6:11 p.m.
On Sun, Nov 20, 2011 at 5:10 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Sat, Nov 19, 2011 at 10:34 PM, Iain Duncan
<iainduncanlists(a)gmail.com>
wrote:
I probably was not clear enough, in my attempts at brevity. In my csound
app, and to the best of my knowledge with live, you have more than one
layer of looping go at once. In my case, I had a global master loop ( that
acted somewhat like x0x song mode ) and channels that independent loops
able to change loop lenght, phasor speed, and offset on the fly. The global
loop was useful for doing things like saying, 'on to the next song'.
This is what I was imagining as the use case for jack transport looping.
All the independent looping might run simultaneously while jack sat there
thinking it was playing the first 32 bars of a piece, allowing one to use
ardour or other apps to play one shot tracks of that length using whatever
they have going.
So, yeah, I'm aware that at the least I'm going to need phasor calculations
for the individual tracks, but was wondering whether I could use some of
what was already there in jack transport for the master song-mode sequencer.
thanks
iain
Also, is that proposal a dead duck now?
No, its not a dead duck. But there is little to no manpower around to
do an initial implementation so that it can be evaluated beyond paper.
Seems to me like if it worked, it
would be a pretty killer feature given the popularity of the Ableton Live
style of working these days.
If you think that JACK transport looping has anything to do with the
Live workflow, then sad to say but you either don't get jack transport
or Live or both :)
Many people look at Live and do not realize the sophistication of what
they are doing. It has very little to do with the ability to set a
global loop.
2:17 p.m.
On Sat, Nov 19, 2011 at 10:23 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Thanks, I know you did some stuff with this with your
old step sequencer. Do
SoftWerk? It didn't use JACK at all because when I wrote it
(pre-Ardour, pre-JACK) there was no JACK MIDI and no point in using
it. One day I might do a JACK MIDI version. Or an LV2 version. Or ...
you think it's better to just ignore moving around
the jack transport and do
my looping internally to my app only? If there are known issues that I'm
just going to discover the hard ware, might as well save time not barking up
the wrong tree.
i think you may be confused about what JACK transport offers. its a
global transport. that means that when you locate (which includes to
looping) to a new position, *all* clients must be ready to continue
processing audio before it can roll again after the locate. For some
kinds of clients, the transport is totally irrelevant (e.g. a software
synthesizer). For other clients, they can be ready immediately that
the locate happens (e.g. a MIDI sequencer running instrument plugins).
For other clients, there is a delay between the locate and them being
ready to play because of the need to load any amount of data from disk
(imagine locating to a new position in a 100 track session in a DAW).
now, if the clients all knew that (a) JACK transport was in a looping
state (b) where the loop points were, they could prepare for this, and
everyone could be ready immediately after the locate. Ardour can
already do this without JACK, for example (its called "Seamless
looping" in ardour, and rather than actually locate and then do the
data i/o, it understands ahead of time the the loop point is coming up
and gets the next chunk of data from the right place).
however, JACK currently does not have a mechanism to mark the
transport state as "looping" or to convey the loop points to clients.
that's why in Ardour, for example, seamless looping is not allowed if
you are synced to JACK transport (or MTC or MIDI clock or ...)
6:26 p.m.
i think you may be confused about what JACK transport
offers. its a
global transport. that means that when you locate (which includes to
looping) to a new position, *all* clients must be ready to continue
processing audio before it can roll again after the locate. For some
kinds of clients, the transport is totally irrelevant (e.g. a software
synthesizer). For other clients, they can be ready immediately that
the locate happens (e.g. a MIDI sequencer running instrument plugins).
For other clients, there is a delay between the locate and them being
ready to play because of the need to load any amount of data from disk
(imagine locating to a new position in a 100 track session in a DAW).
now, if the clients all knew that (a) JACK transport was in a looping
state (b) where the loop points were, they could prepare for this, and
everyone could be ready immediately after the locate. Ardour can
already do this without JACK, for example (its called "Seamless
looping" in ardour, and rather than actually locate and then do the
data i/o, it understands ahead of time the the loop point is coming up
and gets the next chunk of data from the right place).
however, JACK currently does not have a mechanism to mark the
transport state as "looping" or to convey the loop points to clients.
that's why in Ardour, for example, seamless looping is not allowed if
you are synced to JACK transport (or MTC or MIDI clock or ...)
Thanks, that clarifies things a lot for me. I didn't think about the disk
seeking issue. (For my app, my intent is to have everything in RAM for live
playing ). Was the intent of the jack looping transport proposal to allow
clients to know that they were looping and do seamless looping too if they
are able?
iain
6:27 p.m.
On Sun, Nov 20, 2011 at 12:26 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Thanks, that clarifies things a lot for me. I
didn't think about the disk
seeking issue. (For my app, my intent is to have everything in RAM for live
playing ). Was the intent of the jack looping transport proposal to allow
clients to know that they were looping and do seamless looping too if they
are able?
yes.
6:33 p.m.
On Sun, Nov 20, 2011 at 9:27 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Sun, Nov 20, 2011 at 12:26 PM, Iain Duncan
<iainduncanlists(a)gmail.com>
wrote:
Off the official ardourd-jack roadmap record, do you think there's a
realistic chance of this still happening in the next few years? At least
for Ardour? I might code such that I can use ardour with it when available
if that's in the works because that would be super cool, but I totally get
that it may be a very low priority for Ardour dev.
iain
Thanks, that clarifies things a lot for me. I
didn't think about the disk
seeking issue. (For my app, my intent is to have everything in RAM for
live
playing ). Was the intent of the jack looping
transport proposal to allow
clients to know that they were looping and do seamless looping too if
they
are able?
yes.
6:34 p.m.
On Sun, Nov 20, 2011 at 12:33 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Off the official ardourd-jack roadmap record, do you
think there's a
realistic chance of this still happening in the next few years? At least for
Ardour? I might code such that I can use ardour with it when available if
that's in the works because that would be super cool, but I totally get that
it may be a very low priority for Ardour dev.
it has almost nothing to do with ardour. if it was implemented in jack
(all of the implementations), ardour would support it (it would take
about an hour of work to do so). right now, i can't say that i think
anything will or will not happen with JACK. there is nobody with
bandwidth or interest ... or so it seems.
10:45 p.m.
Hey Paul!
You said:
"Many people look at Live and do not realize the sophistication of what
they are doing."
Can you briefly speak about what kind of things they are doing, just so
that I would know how difficult it is and how realistically can we (not)
expect this to ever appear on Linux - and just to get more educated about
audio software.
--
Louigi Verona
http://www.louigiverona.ru/
11:03 p.m.
On Sun, Nov 20, 2011 at 4:45 PM, Louigi Verona <louigi.verona(a)gmail.com> wrote:
Hey Paul!
You said:
"Many people look at Live and do not realize the sophistication of what
they are doing."
Can you briefly speak about what kind of things they are doing, just so
that I would know how difficult it is and how realistically can we (not)
expect this to ever appear on Linux - and just to get more educated about
audio software.
no individual feature of live is beyond the capabilities of other
software (though they do have very, very good implementations of a few
core things like timestretch). nothing going on in live is beyond the
capabilities of some of the developers on this list.
but ... integrating all those ideas and features into a relatively
seamless, highly coherent whole is another matter entirely (as ardour
can attest to in a similar fashion).
the most important to realize about live is that everything you hear
coming out of it has been through a granular resynthesis engine. the
notion of "feed this audio to the output" doesn't really exist.
instead they have a very sophisticated architecture that is
continually, dynamically modifying multiple audio streams in dependent
and independent ways. analyse what is going with just one
clip/event/region and its all fairly straightforward. now step back
and consider the whole picture, and its much more complex and
difficult to (a) implement (b) provide nice ways to manipulate.
ableton have done both, reasonably well.
2:20 p.m.
On Sat, Nov 19, 2011 at 10:15 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Just wondering if I understand this correctly. I
making a loop based app for
step sequencing. When I previously did this in Csound, I clocked it off a
phasor, so the timing was sample accurate ( but that brought all it's own
issues to be sure ). I'm wondering whether I should do the same thing in
jack app, or use the jack transport clock, or some hybrid.
My question, am I correct in understanding that if I use the jack transport
position to rewind in time, I'll get:
C) any other clients with running audio looping back to ( may or may not be
desirable )
B) a jitter based on the amount of time left between when the loop should
end and the end of the frame buffer in which the loop length runs out?
Has anyone solved B? Could it be done by some complex tempo cheating trick?
Does anyone have any methods they've used for tight timing of looping in a
jack app?
Pointers at code appreciated of course. =)
thank!
Iain
Can you use the same approach you did in csound, using
jack_transport's BBT info to run your phasor? It would require that
some app set a tempo and time signature, of course. I use klick, or
gtklick (which has a tap tempo feature), to do this.
6:23 p.m.
Can you use the same approach you did in csound,
using
jack_transport's BBT info to run your phasor? It would require that
some app set a tempo and time signature, of course. I use klick, or
gtklick (which has a tap tempo feature), to do this.
That's precisely what I'm trying to figure out right now, and that was one
of things I was looking at jack transport for. In my csound only version,
the master clock was a master 8, ( or 16, or 32 ) bar phasor with modulo
calculations for subloops. so 120 bpm * 32 became the frequency of the
master phasor clock. This was primitive in some ways, but was a happy
surprise musically, as it turned out to be awesome that one could change
loop length and start points willy nilly, if it didn't add up nicely, you
got some truncation on the end but a hard reset at the top of the phasor,
and that *sounded great*. ( Actually that effect is the whole reason I'm
redoing it, it was a super great way to screw with loops and when I got
demo'd Live, I was like, ok we gotta do this with that cool phasor
technique again ).
Where my brain is hurting right now is making the jump between the way I
though about it Csound, and the putting in to buffer callbacks in Jack ( or
RTAudio or PortAudio for that matter ).
What I do know, is that if I'm using Jack, I might as well make sure that
the 8 bar phasor is using the exact same version of '8 bars' as jack
transport.
I suppose one option is to do it STK style and just treat it like single
sample calculations until I get some draft thing running and revisit later.
Any suggestions welcome, I can see doing the math on running counts of
individual samples, or doing it on time taken from the jack transport
clock. Not sure which to try first,
thanks for the input!
23 Nov
23 Nov
2:17 p.m.
On Sun, Nov 20, 2011 at 12:23 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
Sounds reasonable.
Can you use the same approach you did in csound,
using
jack_transport's BBT info to run your phasor? It would require that
some app set a tempo and time signature, of course. I use klick, or
gtklick (which has a tap tempo feature), to do this.
That's precisely what I'm trying to figure out right now, and that was one
of things I was looking at jack transport for. In my csound only version,
the master clock was a master 8, ( or 16, or 32 ) bar phasor with modulo
calculations for subloops. so 120 bpm * 32 became the frequency of the
master phasor clock. This was primitive in some ways, but was a happy
surprise musically, as it turned out to be awesome that one could change
loop length and start points willy nilly, if it didn't add up nicely, you
got some truncation on the end but a hard reset at the top of the phasor,
and that *sounded great*. ( Actually that effect is the whole reason I'm
redoing it, it was a super great way to screw with loops and when I got
demo'd Live, I was like, ok we gotta do this with that cool phasor technique
again ). Where my brain is hurting right now is making the jump
between the way I
though about it Csound, and the putting in to buffer callbacks in Jack ( or
RTAudio or PortAudio for that matter ).
Create a buffer with the same length as the jack frame size, and the
first thing you do in your jack callback is use jack_position_t to do
the computation of how many frames make up one cycle of your phasor.
Based on the BBT info in jack_position_t, determine what "phase" of
your phasor to start with, and fill the buffer. Then you can use that
buffer to drive your loop playback, create oscillators, etc.
What I do know, is that if I'm using Jack, I might
as well make sure that
the 8 bar phasor is using the exact same version of '8 bars' as jack
transport.
Yes, exactly. You can do this using the jack_position_t info.
I suppose one option is to do it STK style and just
treat it like single
sample calculations until I get some draft thing running and revisit later.
Any suggestions welcome, I can see doing the math on running counts of
individual samples, or doing it on time taken from the jack transport clock.
Not sure which to try first,
thanks for the input!
4545
days inactive
4548
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
4 participants
participants (4)
-
Iain Duncan -
Louigi Verona -
Paul Coccoli -
Paul Davis