/wrote Steve Harris <[EMAIL PROTECTED]> [Mon, 2 Sep 2002 18:27:50
+0100]
|On Mon, Sep 02, 2002 at 06:22:33 +0200, Tim Goetze wrote:
|> i think that Jack and its quick adoption shows the potential is
|> here, but i also think that o-o-p is a big performance burden in
|> most cases (otoh i seem t
/wrote Stefan Westerfeld <[EMAIL PROTECTED]> [Thu, 29 Aug 2002 21:16:59
+0200]
| Hi!
|
|On Wed, Aug 28, 2002 at 10:15:54AM -0400, Paul Davis wrote:
|> a side note: JACK, when run in RT mode, launches its own maximal
|> priority thread to perform exactly this function. all other RT threads
|> ru
/wrote "Stefan Nitschke" <[EMAIL PROTECTED]> [Wed, 14 Aug 2002
20:48:21 +]
|>On Wed, 14 Aug 2002 [EMAIL PROTECTED] wrote:
|>
|> > I jsut went to finally give it a try, and found out there is no more
|> > reborn, it has been shut down.
|> > I wish I hade downloaded when I hade the time
|>
|>Wh
/wrote Paul Davis <[EMAIL PROTECTED]> [Wed, 24 Jul 2002 15:05:24 -0400]
|>| thats the way to handle MIDI *input*. it doesn't really apply to
|>| output, though it would work there too.
|>
|>Yes, it's the symetrical case
|
|only theoretically. handling MIDI input is quite different than
|handling
/wrote Paul Davis
| >By the way, I remember talks around here or jack's mailing list on the
| >issue of non constant frame number passed to the process callback... I
| >don't remember if anything was decided, but i was thinking it would be
| >nice to leave it bounded but non-constant, just for be
/wrote Paul Davis
| i believe that relative nanosleep is better than absolute sleep for
| the simple reason that its how you would avoid drift in
| practice. consider a JACK callback:
|
| process (jack_nframes_t nframes)
| {
| jack_transport_info_t now;
|
/wrote Paul Davis
| >/wrote Paul Davis <|@op.net> [Tue, 23 Jul 2002 19:58:16 -0400]
| >
| >|SGI tried to solve the problem of the Unix read/write API mismatch
| >|with realtime streaming media by adding timestamps to data. CoreAudio
| >|solves it by getting rid of read/write, and acknowledging t
/wrote Paul Davis <[EMAIL PROTECTED]> [Tue, 23 Jul 2002 19:58:16 -0400]
|the most fundamental problem with SGI's approach to audio+video is
|that its not based on the desirability of achieving low latency for
|realtime processing and/or monitoring. its centered on the playback of
|existing, edite
From: Bob Ham <[EMAIL PROTECTED]>
Subject: Re: [linux-audio-dev] (no subject)
Date: 23 Jul 2002 13:14:02 +0100
Message-ID: <1027426442.2811.6.camel@insanity>
node> On Tue, 2002-07-23 at 09:45, .n++k wrote:
node>
node> > that's 15M, of which 5M (mysql-test. sql-ben
From: rm <[EMAIL PROTECTED]>
Subject: Re: [linux-audio-dev] (no subject)
Date: Tue, 23 Jul 2002 05:33:56 -0400
Message-ID: <[EMAIL PROTECTED]>
async> On Tue, Jul 23, 2002 at 10:45:55AM +0200, .n++k wrote:
async> > | > > Why not use an SQL database for storing sess
| On Tue, 23 Jul 2002 03:14:56 -0400
| Paul Winkler wrote:
|
| > On Tue, Jul 23, 2002 at 08:43:36AM +0200, n++k wrote:
| > > Just a comment on the metadata persistence:
| > >
| > > Why not use an SQL database for storing session/project metadata?
| > > (configur
Just a comment on the metadata persistence:
Why not use an SQL database for storing session/project metadata?
(configuration and such) We have the benefit of having a few quite
stable free software SQL databases. (mysql, postgresql, sapdb) so
requiring one wouldn't be too much to ask.. The persis
| the current semantics, reiterated here recently by richard f., are
| that a plugin can assume that a control port value will not change
| during the call to process(). the motivations for this are simple, and
| seemed pretty valid to me until i started to consider parameter
| automation.
|
| co
th visual 3D objects. The ability to prototype
| a usable app quickly, actually use it, then have the option of further
| streamlining certain parts of the app in C/C++ is very "natural" with
| gigahertz++ boxes these days.
merci.
sir you have no clue.
--
n
++k
[n++k <[EMAIL PROTECTED]>]
| may i interrupt?
|
| | of and interaction with visual 3D objects. The ability to prototype
| | a usable app quickly, actually use it, then have the option of further
| | streamlining certain parts of the app in C/C++ is very "natural" with
| | gigaher
orm and a patch, and at make time, patch the file?
shouldn't that work? (considering 90% of linux users should have patch around)
i don't think there's even a copyright infrigment then, since no copy is
actually made anymore once it's on the user's harddrive.
--
n
++k
(and its subjective elegance which i love)
--
n
++k
e to use emacs and framemaker period, they
| are
|
| nk> the funny part being that emacs feature those completly remapable
| hot-keys
|
| nk> --
| nk> n
| nk> ++k
|
|
|
--
n
++k
emacs feature those completly remapable hot-keys
--
n
++k
lon,
| they state that it can perform two pipelined double precision floating
| point multiplies per cycle. They do not mention any changes in this
| performance that is dependent upon the values of the numbers to be
| multiplied.
|
http://www.smartelectronix.com/musicdsp/text/other001.txt
--
n
++k
elopers and users are
necessarly mixed due to the constant changes ... so i am against
arbitrarly spliting lists between users and developers.
Just my personal point of view on the matter
--
n
++k
21 matches
Mail list logo
