<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
On 09/03/2009 02:57 AM, Danni Coy wrote:
<blockquote
 cite="mid:8459c9dc0909020957n4bd4b33bs836fb98e2a1bbfbd@mail.gmail.com"
 type="cite"><br>
  <br>
  <div class="gmail_quote">On Wed, Sep 2, 2009 at 11:30 PM, Niklas
Kl&uuml;gel <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:niklas.kluegel@mytum.de">niklas.kluegel@mytum.de</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">cunnilinux
himself schrieb:<br>
    <div class="im">&gt;&gt; Some people here (more or less)
desperately need a similar application for linux.<br>
&gt;&gt;<br>
&gt;<br>
&gt; off topic, but...<br>
&gt; people in linux audio scene always DESPERATELY need something just<br>
&gt; like a copy of some fancy (commercial) app on win/mac.<br>
&gt; that's the main and only reason why linux is (semi-)deficient in
the<br>
&gt; pro audio world.<br>
&gt;<br>
&gt;<br>
    </div>
just to add my 2 cents...<br>
    <br>
regarding monolithic vs. modular (across applications):<br>
while the latter (theoretically) allows for more flexibility of<br>
processing, akin to the proven unix-concepts of pipelining (and<br>
therefore the development of something jack-alike for audio/video etc<br>
became an obvious evolution for -primarily- LAU/D), it does not allow<br>
for certain common concepts in the workflow of composition and dsp.<br>
technically - or at least _without hassle_. those include nearly all<br>
operations that:<br>
1a) allow you to temporarily bounce (aka freezing) parts of the signal<br>
chain (tracks, single processed clips, subchannels) - thus saving cpu<br>
cycles in rather complex arrangements.<br>
  </blockquote>
  <div><br>
This could happen if programs could be smart enough not to do audio
processing if there is no input signal and programs are able to trace
the signal path(s) till it(they) terminate(s) (either has no output
connections, makes itself to the system output connections (speakers),
or back into the application itself. The application could then connect
the terminating output(s) to the program input - do a synchronised
record (already possible), close off the signal path for the processing
version of the track and playback the recorded audio instead.<br>
  </div>
  </div>
</blockquote>
<br>
<br>
<br>
How about having some kind of bounce notification for jack?<br>
<br>
<br>
<blockquote
 cite="mid:8459c9dc0909020957n4bd4b33bs836fb98e2a1bbfbd@mail.gmail.com"
 type="cite">
  <div class="gmail_quote">
  <div><br>
Anyways I am glad you brought up those points... It is something
severely lacking in the current modular implementation that we have.<br>
Doing things in a modular way through jackd has a lot of potential but
really requires some application managment features to really compete
with proprietory workflows.<br>
  <br>
I would love to see a control application that <br>
1) lets you group applications....<br>
2) the ability to remove/restore connections going in or out of&nbsp; a
group.<br>
3) the ability to clone a group.<br>
4) the ability to save/restore groups of applications.<br>
  </div>
  </div>
  <pre wrap="">
  </pre>
</blockquote>
<br>
<br>
<br>
I think this is the direction we are heading so the more we can
contribute to the conceptualisation and technical aspects with this
discussion the better.<br>
<br>
<br>
<br>
Cheers.<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">Patrick Shirkey
Boost Hardware Ltd</pre>
<br>
</body>
</html>