24 Jun
2010
24 Jun
'10
2:55 p.m.
On Wed, 23 Jun 2010, Kjetil S. Matheussen wrote:
Andrew C:
0.49 has this feature implemented. Use the "-jt" option.
It should be sample sync, but I'm not sure whether the last
block (the one that received a stop message from jack transport)
should be recorded? For now it's recorded. If that's wrong,
I'll fix it in the next release.
Wow, thanks for the replies guys!
Of the software mentioned here, my biggest wish is for syncability with
JACK
transport, so I can send the output of one of the linuxsampler instruments
to the recording software, hit the play button from inside Rosegarden and
have a perfectly synced audio copy of one particular instrument output
which
I can then drop back into the sequencer timeline and continue with another
section of the song, thereby freeing up system resources.
Of course, this rules out jack_capture I'm afraid!
Sorry, I got this feature request about 4 years ago, but haven't
implemented it. It should only be about 10-20 extra lines of
code. I'll do it very soon.
24 Jun
24 Jun
9:49 p.m.
New subject: Software for recording digital audio?
On 06/24/2010 02:55 PM, Kjetil S. Matheussen wrote:
On Wed, 23 Jun 2010, Kjetil S. Matheussen wrote:
Almost. It does not yet compensate for port-latency. It is important for
both effects that introduce latency as well as to keep physical I/O in
sync with apps.
see jack_port_get_latency() and jack_port_get_total_latency()
at http://jackaudio.org/files/docs/html/group__PortFunctions.html
Andrew C:
0.49 has this feature implemented. Use the "-jt" option.
It should be sample sync,
Wow, thanks for the replies guys!
Of the software mentioned here, my biggest wish is for syncability
with JACK
transport, so I can send the output of one of the linuxsampler
instruments
to the recording software, hit the play button from inside Rosegarden
and
have a perfectly synced audio copy of one particular instrument
output which
I can then drop back into the sequencer timeline and continue with
another
section of the song, thereby freeing up system resources.
Of course, this rules out jack_capture I'm afraid!
Sorry, I got this feature request about 4 years ago, but haven't
implemented it. It should only be about 10-20 extra lines of
code. I'll do it very soon.
but I'm not sure whether the last
block (the one that received a stop message from jack transport)
should be recorded? For now it's recorded. If that's wrong,
I'll fix it in the next release.
While it's safe to just record it, i don't think it should be.
http://jackaudio.org/files/docs/html/group__TransportControl.html reads:
jack_transport_stop() [..] takes effect on the _next_ process cycle.
jack_transport_query() [..] If called from the process thread, pos
corresponds to the first frame of the _current_ cycle and the state
returned is valid for the entire cycle.
IOW: As soon as the app sees a stopped transport in the process loop it
is exactly at, or already a bit later than the actual end.
..but.. you may still need to run a bit further to compensate for
port-latencies.
Cheers!
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
5319
days inactive
5319
days old
linux-audio-dev@lists.linuxaudio.org
1 comments
2 participants
participants (2)
-
Kjetil S. Matheussen -
Robin Gareus