Re: latest SVN commits

On Tue, Apr 17, 2007 at 06:03:28PM -0400, Paul Davis wrote:

> On Tue, 2007-04-17 at 23:50 +0200, Fons Adriaensen
wrote:
> 
> > I'm pretty sure that if you analyse the signal
flow in Ardour it will
> > turn out that it can be separated in the way I
suggested.
> 
> Sampo did a diagram of the signal flow. It shows lots
of things not
> relevant to the current point, but:
> 
> http://ardour.org/files/manual/sn-tracks-and-busses.html

> 
> the data arrives on a JACK port, where it is copied
into a ringbuffer
> for later dispatch to disk in another thread. if
software monitoring is
> in use, then the signal continues to flow through the
entire "mixer
> strip" (Route) to the output JACK port of the
Route.
> ...
> consequently, s/w monitoring requires that the signal
flow from an input
> port to an output port, optionally via the entire FX
chain in a route
> (whether the FX are enabled is a user option). this
will include bus
> sends, inserts and so forth.

Even if it's used for monitoring this is just the 'playback'
path of
the strip. The only difference is that it takes its input
not from the
diskstream but from the jack input port.

The 'recording' path is not shown in that diagram, it goes
from the
jack input port to the diskstream.

These are two separate paths, even if when monitoring they
share an
input, and the recording path is trivial. In the mixer
architecture
I described it isn't: there is a complete mixer, or at least
a gain
control, between the external inputs and the diskstreams.  
 
> basically, the only difference for signal flow when
doing playback and
> doing recording is the "switch" in the grey
box that sampo marked
> "monitoring".

Indeed, that is exactly what I expected.

> keep in mind that tracks may be producing audio even
when
> the transport is stopped, so the issue is not between
what happens when
> "recording" versus "playing", its
between "tracks that should monitor
> their inputs" and "tracks that play data from
disk".

OK, that is what I meant.
 
> > The default model in ardour is a simplification of
this: there
> > are no recording level controls and no matrix -
each input just
> > feeds its own track while recording. 
> 
> except that each "input" is connected to a
JACK output port that can be
> connected to multiple tracks,

Why would one ever record the same input on many tracks ?

> and the "input" can actually be connected to
multiple JACK output ports
> at the same time.

That's not very useful if you can't control the mix, but
that is actually
a separate issue.

> there is no gain control before the data hits the disk.
and gain control
> after that applies to every data stream within a track.
so in a sense,
> yes, but i fail to see a limitation here. JACK's
routing capabilities
> make up for anything we "took out" of
"the mixer", except gain control
> which makes little sense in a digital system (its just
a mult).

It doesn't make sense for one input, but it does it you want
to mix a
number of them into the same track. But again, that is a
separate issue.

> the track goes back and forth between playback and
recording mode at
> various times, and rearranging the distribution of
ports and clients
> each time this happens would be pretty ugly. changing
which ports and
> clients a track uses when its monitoring status changes
... ugh.

There is no need to do that. Let me rephrase my original
idea.
Is there any reason why diskstreams can't have a direct
jack
input and and output, with nothing between them and those
ports ?
Is there anything that would stop these two sets of ports
belonging
to two clients (in the same process), and connecting to
mixer ports
belonging to a third client (in the same or a separate
process) ?
There can't ever be any loops that could add latency, as the
client
that has the diskstream inputs has no outputs and the one
with the
diskstream outputs has no inputs. There is more to it, but
it becomes
difficult to explain in words. I'll make some diagrams one
of these
days (and go to sleep now .


-- 
FA

Follie! Follie! Delirio vano è questo !



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Wed, 2007-04-18 at 01:00 +0200, Fons Adriaensen wrote:
> On Tue, Apr 17, 2007 at 06:03:28PM -0400, Paul Davis
wrote:

> There is no need to do that. Let me rephrase my
original idea.
> Is there any reason why diskstreams can't have a direct
jack
> input and and output, with nothing between them and
those ports ?

mostly issues of UI design.

Routes have their own IO ports. Tracks are Routes. But
Tracks also are
associated with a Diskstream. Right now the Diskstream
simply uses the
inputs of the Track it is associated with. If Diskstreams
have their own
ports, where is that represented in the UI? This goes back
to an old
design that Ardour had about 4 years ago (exposing
Diskstreams as
distinct objects) and almost nobody but me liked it that
way. 

the alternative is to take away the ports from a Track and
make it use
the ones associated with the diskstream. this has a similar
level of
complexity to the code, if not more, because operations to
change
the input setup of a Track now have to proxy via a
diskstream, even
though all such operations are also theoretically legal on
the Track
itself (since its a Route; to make it clearer think of a
Route as being
a Bus, and a Track being a Bus + a diskstream. heh. is that
clearer?)

essentially, what you're describing makes perfectly good
sense, but
creates a usability problem by exposing the distinction
between a track
as a disk storage entity and a track as a signal processing
entity.
almost all of our users have expressed strong misgivings
when we used to
make this distinction, so we went with the crowd, and hid
it.

--p



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el