7 Apr
2017
7 Apr
'17
2:50 p.m.
I have Pianoteq connected to Jack, then to ecasound for dsp into 6
channels, then back thru Jack to rme9652. 64 sample buffers. Should I run
ecasound in slave transport mode to make sure the pipeline runs
efficiently, with Pianoteq supplying a new sample set in lock-step while
the previous one is being processed by ecasound? The details about how all
this is getting done are fascinating, but a little murky in my head...
Thanks,
John
--
Sent from Gmail Mobile
7 Apr
7 Apr
2:57 p.m.
Apr 7 2017, john gibby has written:
I have Pianoteq connected to Jack, then to ecasound
for dsp into 6
channels, then back thru Jack to rme9652. 64 sample buffers. Should I run
ecasound in slave transport mode to make sure the pipeline runs
efficiently, with Pianoteq supplying a new sample set in lock-step while
the previous one is being processed by ecasound?
Hi John,
if I understand correctly: Pianoteq is running on your computer using
JACK in some LV2 host or maybe as a standalone application?
Does Pianoteq have a sequencer that you use? If you play live, It
wouldn't matter whether Ecasound in master or slave mode. If some sort
of sequencer is running in Pianoteq, then it's a question of your
workflow. What's the centre piece? If it's Ecasound, set Ecasound to
master (transport master) and Pianoteq as a transport slave.
From my understanding of Pianoteq, setting Ecasound to
transport Master
or leaving it open, is the right decision.
Best wishes,
Jeanette
...
--------
When you need someone, you just turn around and I will be there <3
3:23 p.m.
On Fri, 7 Apr 2017 14:57:57 +0200 (CEST), Jeanette C. wrote:
Does Pianoteq have a sequencer that you use?
To sync step sequencers/arpeggiators, delays etc. of non-Linux apps I'm
using "MIDI clock". Syncing with an external sequence would be possible
by "MIDI timecode", but IMO it doesn't make sense. What I do instead,
when using a non-Linux sequencer e.g. from my iPad, is to export audio
and after that to import audio by Ardour. When directly working with
Linux, I simply use e.g. Ardour as the sequencer and as already pointed
out, I sync step sequencers and delays by "MIDI clock".
There might be circumstances when using JACK transport, MIDI timecode
and Co. makes sense, but IMO the "all in one" approach is more
comfortable and for anything else MIDI clock does the job.
Regards,
Ralf
3:27 p.m.
Apr 7 2017, Ralf Mardorf has written:
...
To sync step sequencers/arpeggiators, delays etc. of
non-Linux apps I'm
using "MIDI clock".
But PianoTeq - if we're talking about the
physical modelling piano
application from the French manufacturer - is a native Linux
application, available as an LV2 plugin or as a standalone - if I'm not
mistaken. Just clarifying...
...
Best wishes,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
3:52 p.m.
On Fri, 7 Apr 2017 15:28:15 +0200 (CEST), Jeanette C. wrote:
Apr 7 2017, Ralf Mardorf has written:
After taking a brief look at https://www.pianoteq.com/ there seems
nothing what JACK transport might be good for. Pianoteq provide effects.
I don't know if LV2 could sync effect speeds directly, but at least
"MIDI clock" should do the job. I might be mistaken, but I guess JACK
transport is not aimed for this kind of sync.
To sync step sequencers/arpeggiators, delays etc.
of non-Linux apps
I'm using "MIDI clock".
But PianoTeq [snip] is a native Linux
application, available as an LV2
plugin or as a standalone - if I'm not mistaken. Just clarifying...
5:42 p.m.
Yes, Pianoteq is the French piano modeling program, and I am running it as
a standalone application in AVL Linux alongside ecasound and Jack. It is
for playing piano live, with low latency. (Also I recently read about vsi
plugin version of Pianoteq , and I'm wondering if it might be better to run
it that way; some posts say so.) I will read these responses more
carefully, but it seemed to me I want ecasound to be a Slave to the earlier
parts of the pipeline so everything runs in lockstep, processing the 64
sample buffers with maximum efficiency. Seems advantageous to me that I'm
avoiding d/a conversion until final step b4 the amps.
On Apr 7, 2017 9:28 AM, "Jeanette C." <julien(a)mail.upb.de> wrote:
Apr 7 2017, Ralf Mardorf has written:
...
To sync step sequencers/arpeggiators, delays etc.
of non-Linux apps I'm
using "MIDI clock".
But PianoTeq - if we're talking about the physical modelling piano
application from the French manufacturer - is a native Linux
application, available as an LV2 plugin or as a standalone - if I'm not
mistaken. Just clarifying...
...
Best wishes,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
5:56 p.m.
On Fri, April 7, 2017 10:42 am, john gibby wrote:
it seemed to me I want ecasound to be a Slave to the
earlier parts of the pipeline so everything runs in lockstep
For audio you get that no matter what you do, it is just how jackd works.
All audio applications are "slave" to the jackd server.
Jack transport is completely unrelated to the audio pipeline, so the short
answer to your original question is that for your audio processing only
application, jack transport is unrelated, it should not matter what
setting you select.
--
Chris Caudle
6:06 p.m.
On Fri, 7 Apr 2017 11:42:21 -0400, john gibby wrote:
Yes, Pianoteq is the French piano modeling program, and
I am running
it as a standalone application in AVL Linux alongside ecasound and
Jack.
IIUC everything runs on the same machine?
Seems advantageous to me that I'm avoiding d/a
conversion until final
step b4 the amps.
JACK transport has nothing to do with the audio chain.
If everything is running on the same computer, then anything is
digital. Depending on how you are doing things, resampling could be
involved, but no conversion to analog.
CPU, RAM, the mobo's bus etc. are unable to handle analog signals. Only
a sound card could convert.
If you are using Pianotec on a different computer than ecasound, then
S/PDIF, AES/EBU and ADAT are common digital formats. IOW even then you
not necessarily need to convert to/from analog. In this case sync is
important, but this more or less happens automatically. You might need
to select the clock source, but this has nothing to do with JACK, let
alone JACK transport. If you don't use a digital interface, IOW if you
convert to analog by one computer and to digital by the other, no sync
between the sound cards of the both computers at all is required.
In short, you don't need to care about anything JACK transport related.
However, I wonder if you are using QjackCtl. It's a GUI that provides
transport buttons. There are important settings, but they are equal for
anything using jack and those settings have nothing to do with a
feature named "jack transport".
Regards,
Ralf
3:59 p.m.
john gibby <johnalan.gibby(a)gmail.com> writes:
I have Pianoteq connected to Jack, then to ecasound
for dsp into 6
channels, then back thru Jack to rme9652. 64 sample buffers. Should I run
ecasound in slave transport mode to make sure the pipeline runs
efficiently, with Pianoteq supplying a new sample set in lock-step while
the previous one is being processed by ecasound? The details about how all
this is getting done are fascinating, but a little murky in my head...
Jack transport doesn't have anything to do with audio. You'll know if
you're audio isn't getting through Jack ok because the symptom of that
will be xruns. Basically, if you're not getting xruns, everything made
it through just fine.
Jack transport is kind of like Midi clock, but for situations where the
sequencers involved are all Linux apps with Jack support. In a case
like that, why bother actually sending the traditional 96 tick per
quarter note Midi clock stream through virtual Midi connections on your
computer when all the apps involved can just sync through Jack? If all
your sequencers know Jack, then you don't need Midi clock to sync them.
So, if you're not trying to sync Jack-aware sequencers on your computer,
then you don't need Jack transport for anything at all.
--
- Brent Busby + ===============================================
+ With the rise of social networking
-- Studio -- + sites, computers are making people
-- Amadeus -- + easier to use every day.
----------------+ ===============================================
4:23 p.m.
On Fri, 07 Apr 2017 08:59:36 -0500, Brent Busby wrote:
Jack transport doesn't have anything to do with
audio. You'll know if
you're audio isn't getting through Jack ok because the symptom of that
will be xruns. Basically, if you're not getting xruns, everything made
it through just fine.
I didn't understand what the OP actually asked :D. That's a good
reply :).
So semi-off-topic:
Jack transport is kind of like Midi clock
Isn't JACK transport more like MTC? IOW doesn't JACK allow to start at
what position ever and all the sequencers, drum machines etc. follow
and start at the same bar or beat?
4:23 p.m.
Am 07.04.2017 um 15:59 schrieb Brent Busby:
john gibby <johnalan.gibby(a)gmail.com> writes:
Not at all, for example, in guitarix, you can use jack transport for
toggle effects on/off (in sync).
That could be useful in special for delays/loops but any other effect as
well.
I have Pianoteq connected to Jack, then to
ecasound for dsp into 6
channels, then back thru Jack to rme9652. 64 sample buffers. Should I run
ecasound in slave transport mode to make sure the pipeline runs
efficiently, with Pianoteq supplying a new sample set in lock-step while
the previous one is being processed by ecasound? The details about how all
this is getting done are fascinating, but a little murky in my head...
Jack
transport doesn't have anything to do with audio. You'll know if
you're audio isn't getting through Jack ok because the symptom of that
will be xruns. Basically, if you're not getting xruns, everything made
it through just fine.
Jack transport is kind of like Midi clock, but for situations where the
sequencers involved are all Linux apps with Jack support. In a case
like that, why bother actually sending the traditional 96 tick per
quarter note Midi clock stream through virtual Midi connections on your
computer when all the apps involved can just sync through Jack? If all
your sequencers know Jack, then you don't need Midi clock to sync them.
So, if you're not trying to sync Jack-aware sequencers on your computer,
then you don't need Jack transport for anything at all.
2791
days inactive
2791
days old
linux-audio-user@lists.linuxaudio.org
10 comments
6 participants
participants (6)
-
Brent Busby -
Chris Caudle -
Hermann Meyer -
Jeanette C. -
john gibby -
Ralf Mardorf