On Thu, Aug 15, 2002 at 03:16:06PM -0400, Paul Davis wrote:
> >On Wed, Aug 14, 2002 at 05:16:43PM -0400, Paul Davis wrote:
> >> ... tempo sync a delay plugin ...
(snip)
> let me know how the host is supposed to know which ports to do this
> for.
Ah. Well, for now you'd have to tell it :-/
> yo
>On Wed, Aug 14, 2002 at 05:16:43PM -0400, Paul Davis wrote:
>> ... tempo sync a delay plugin ...
>
>Eh? can't you just have a control port on the plugin for
>tempo (a float), and apply some multiplier to that,
>invert it and bingo, delay time in seconds. what am I missing?
>you want it automatic
On Wed, Aug 14, 2002 at 05:16:43PM -0400, Paul Davis wrote:
> ... tempo sync a delay plugin ...
Eh? can't you just have a control port on the plugin for
tempo (a float), and apply some multiplier to that,
invert it and bingo, delay time in seconds. what am I missing?
you want it automatic? well,
>> in the future, it hopefully won't be necessary to do this. instead,
>> you can go and look at rosegarden, muse, ardour, ecasound etc. and ask
>> "how do they do it?"
>
>Inside 90.000 lines of code ? without doc ? , without any aparent order ?
when people like jesse chappel (who also wrote th
> Joshua Haberman writes:
>
> Building modular, reusable software is
> a noble goal, but it's extremely difficult. Things that may seem like
> they should be logically separable often require tighter coupling than
> you would like if they are to be efficient and usable.
The Propellerhead folks
* To [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> "Toni Moreno Giménez" <[EMAIL PROTECTED]> wrote:
> > You are mixing GUI features("hundreds of "regions" displayed on the screen")
> > final application features ("undo/redo") and Data Features, in my opinion a
> > good desing may study "kind" o
On Fri, 2 Aug 2002, janne halttunen wrote:
> On Fri, 2 Aug 2002 14:11:03 +0200 (MET DST)
> "Kjetil S. Matheussen" <[EMAIL PROTECTED]> wrote:
>
> > Hi, I've been on the www.eca.cx homepage many times. But each time
> > I get so confused. How about a redisign. For example to put a
> > menu on the
On Fri, 2 Aug 2002 14:11:03 +0200 (MET DST)
"Kjetil S. Matheussen" <[EMAIL PROTECTED]> wrote:
> Hi, I've been on the www.eca.cx homepage many times. But each time
> I get so confused. How about a redisign. For example to put a
> menu on the left like this:
>
> -overview (the heteca page)
> -ecas
On Fri, 2 Aug 2002, Toni Moreno [iso-8859-1] Giménez wrote:
> > at 96kHz? can the transport mechanism handle auto-looping? can you
> > punch in while playing? can undo/redo be designed in a way that makes
> > it easy to undo/redo anything in an efficient and fast manner? what
> > happens when th
On Fri, 2 Aug 2002, Kai Vehmanen wrote:
>
> As an example, for the last 5 years I've been working on libecasound,
> which is essentially a mix of an application framework and a traditional
> software library (you can extend it by both inserting custom code to
> selected configuration points and
I read:
> The kinds of things that can be usefully abstracted and factored of of
> specific applications into common libraries already have been.
.
.
agreed
> Anything more specific than this is tightly coupled to the design of the
> specific application.
not exacly for instance the idea to ha
* Toni Moreno Giménez ([EMAIL PROTECTED]) wrote:
> El Vie 02 Ago 2002 03:41, escribiste:
> > Once you have a system that exists, you can argue that your design is
> > better than another system that also exists. Until then, your criticism of
> > the design of applications that do exist is not ver
El Vie 02 Ago 2002 03:41, escribiste:
> Once you have a system that exists, you can argue that your design is
> better than another system that also exists. Until then, your criticism of
> the design of applications that do exist is not very compelling, IMO.
You have not understood what I'm doi
* Toni Moreno Giménez ([EMAIL PROTECTED]) wrote:
> El Vie 02 Ago 2002 03:41, escribiste:
> > "Toni Moreno Giménez" <[EMAIL PROTECTED]> wrote:
> > > You are mixing GUI features("hundreds of "regions" displayed on the
> > > screen") final application features ("undo/redo") and Data Features, in
> >
El Vie 02 Ago 2002 03:41, escribiste:
> "Toni Moreno Giménez" <[EMAIL PROTECTED]> wrote:
> > You are mixing GUI features("hundreds of "regions" displayed on the
> > screen") final application features ("undo/redo") and Data Features, in
> > my opinion a good desing may study "kind" of features, in
"Toni Moreno Giménez" <[EMAIL PROTECTED]> wrote:
> You are mixing GUI features("hundreds of "regions" displayed on the screen")
> final application features ("undo/redo") and Data Features, in my opinion a
> good desing may study "kind" of features, in separate way.
>
> GSound: the interact
El Jue 01 Ago 2002 22:13, Paul Davis escribió:
> >> ardour may well end up as the codebase for a bunch of libraries, but i
> >> don't think you could create ardour from a bunch of libraries.
> >
> >Well I have created a Rebirth 338 clone, can you create it ?.
> >To make a correct GSound design I m
>> ardour may well end up as the codebase for a bunch of libraries, but i
>> don't think you could create ardour from a bunch of libraries.
>
>Well I have created a Rebirth 338 clone, can you create it ?.
>To make a correct GSound design I must begin on more general and easy apps.
>(Stage 1,Simple
El Jue 01 Ago 2002 20:24, escribiste:
> >To make sure the GSound API has the needed features, we are working also
> > on diferent applications, who help us to desing, detect/fix bugs, and
> > redesing the API if needed.
> >
> >NxsTools: Something like SoX.
> >NxsAudio: A single audio editor (Simi
>To make sure the GSound API has the needed features, we are working also on
>diferent applications, who help us to desing, detect/fix bugs, and redesing
>the API if needed.
>
>NxsTools: Something like SoX.
>NxsAudio: A single audio editor (Similar to Soundforge)
>NxsrRAck: A rebirth 338 clone
El Lun 22 Jul 2002 22:18, escribiste:
> The first posture is to write big apps, with extra functionality added
> as host processing.
> This is the de-facto standard in windows & mac. Using this model, all
> kind of "extra" processing
> features (such as audio DSP, midi instruments/ports, and even
Hello. Do we have even agreed on how to organize audio/sound files
for the use in multiple applications? File formats?
We could agree on the directory structures, EDL file format,
overview file format (for waveform drawing), sequencer file format,
modular (synth) structure file format. File locki
Pretty much right. I normally broadcast on 192.168.x.255 or whatever
the broadcast address of the LAN I'm on is, but loopback works fine.
Point-to-point works as well which we use to jump from subnet to subnet
in work (not tested a cross-lan master-slave configuration but it should
work fine if
> >on every callback. If a node does internal buffering that should not affect
> >the MSCs.
>
> right, because there isn\'t really an MSC anywhere. as you noted, the
> global jack transport time isn\'t really equivalent. nothing in the
> main JACK API says anything about doing anything except han
On Thu, Jul 25, 2002 at 12:24:56AM +0100, Phil Kerr wrote:
(cut)
>It's a very simple protocol to use and it seems to work fine on a LAN. It
>can also handle the saving and restoring of app config data by broadcasting
>it's config as XML.
(cut)
Just thinking out lout :)
If you use this on the 127
/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
>MIDI is different to audio and it seems wrong to lump it in with Jack as it's
>just adding complexity. Being able to sync things up with Jack would be
>good.
right. we don't try to get JACK to do MIDI right now, but we do want
JACK to be able to provide sync'ed transport control. longer term, i
>> consider:node B
>>/\\
>> ALSA PCM -> node Anode D -> ALSA PCM
>>\\/
>> node C
>>
>> what is the latency for output of data from node A ? it depends on
>> what happens at nod
Hi all,
> I've been meaning for some time to make a universal transport control, a
> separate app whose sole purpose would be transport control.
> This would be rad (TM) for a number of reasons:
>
> 1) Get your whole rig to start at once, even if you're not using
> ecasound or ardour
Which is pr
On Wed, 24 Jul 2002, Richard Bown wrote:
>> because the transport time is the only important global time it indicates
>> what you should be playing/doing right now.
> But of course at the moment we've also got the ALSA sequencer clock running
> to schedule our MIDI alongside our JACK callbacks -
On Wed, 24 Jul 2002, Richard Bown wrote:
> What apps have an example implementation of the JACK transport controls?
> Neither ecasound or ardour appear to but I'm probably a bit out of date
> with them. And again, why should I care about the JACK transport?
http://cvs.seul.org/cgi-bin/cvsweb-1.
On Wed, 24 Jul 2002, Andy Wingo wrote:
[JACK transport control]
> I've been meaning for some time to make a universal transport control, a
> separate app whose sole purpose would be transport control.
> This would be rad (TM) for a number of reasons:
>
> 1) Get your whole rig to start at once, ev
[...]
>
> consider:node B
>/\\
> ALSA PCM -> node Anode D -> ALSA PCM
>\\/
>node C
>
> what is the latency for output of data from node A ? it depends on
> what happens at n
>> as i\'ve indicated, i think this is a
>> bad design. Defining the semantics of MSC in a processing graph is
>> hard (for some of the same reasons that jack_port_get_total_latency()
>> is hard to implement).
>
>Why? On a audio card interrupt buffers traverse the entire graph right? i.e.
>for eve
>| 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 MIDI output. there is no scheduling necessary for MIDI input
- the data arrives
> >If I use an absolute sleep there is basically no difference. The drift
> >will be the same, but instead of scheduling events from \'now\' I can
> >spcify the exact time. So a callback would then be like:
> >
> >- get the UST and MSC for the first frame of the current buffer for input
>
> MSC
>If I use an absolute sleep there is basically no difference. The drift
>will be the same, but instead of scheduling events from \'now\' I can
>spcify the exact time. So a callback would then be like:
>
>- get the UST and MSC for the first frame of the current buffer for input
MSC implies timest
/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
>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 being able to
>design an app
> nanosleep isn\'t based on time-of-day, which is what is subject to
> adjustment. nanosleep uses the schedule_timeout, which is based on
> jiffies, which i believe are monotonic.
I\'m not sure how nanosleep() is supposed to handle clock adjustment
but I agree it would probably not change its beh
Paul Davis wrote:
> because the transport time is the only important global time it indicates
> what you should be playing/doing right now.
But of course at the moment we've also got the ALSA sequencer clock running
to schedule our MIDI alongside our JACK callbacks - so external control of
our a
/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;
|
On Wed, 24 Jul 2002, Richard Bown wrote:
> Paul Davis wrote:
>
> > JACK provides both current time and information on the latency
>
> Oh right - so jack_port_get_total_latency() is working now? Excellent.
> Last time I asked it was still in the planning stage.
>
> What apps have an example im
>> JACK provides both current time and information on the latency
>
>Oh right - so jack_port_get_total_latency() is working now? Excellent.
>Last time I asked it was still in the planning stage.
no, it exists and works, but it can't handle all possible connection
graphs. it may never be able to.
>> >[...]
>> >> CLOCK_MONOTONIC doesn\\\'t change the scheduling resolution of the
>> >> kernel. its not useful, therefore, in helping with this problem.
>> >
>> >Not useful right now. CLOCK_MONOTONIC scheduling resolution will get
>> >better I hope.
>>
>> How can it? UST cannot be the clock tha
Paul Davis wrote:
> JACK provides both current time and information on the latency
Oh right - so jack_port_get_total_latency() is working now? Excellent.
Last time I asked it was still in the planning stage.
What apps have an example implementation of the JACK transport controls?
Neither ecaso
/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
> >[...]
> >> UST can be used for timestamping, but thats sort of useless, since the
> >> timestamps need to reflect audio time (see below).
> >
> >I\\\'d like to have both a frame count (MSC) and a corresponding system
time
> >(UST) for each buffer (the first frame). That way I can predict when (
[...]
> if you find the link for the
> ex-SGI video API developer\'s comment on the dmSDK, i think you may
> also see some serious grounds for concern about using this API. i\'m
> sorry i don\'t have it around right now.
is it http://www.lurkertech.com/linuxvideoio.html ?
this is about the older
>[...]
>> UST can be used for timestamping, but thats sort of useless, since the
>> timestamps need to reflect audio time (see below).
>
>I\'d like to have both a frame count (MSC) and a corresponding system time
>(UST) for each buffer (the first frame). That way I can predict when (UST)
>a certai
>[...]
>> Its worth noting that SGI\'s \"DM\" API has never really taken
>> off, and there are lots of reasons why, some technical, some
>> political.
>
>Perhaps. See http://www.khronos.org/ for where SGI\'s dmSDK might
i've seen khronos's stuff. its a group made up of current bit players
in the
>/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,
On Tue, Jul 23, 2002 at 01:51:19 -0400, Paul Winkler wrote:
> Works for me. :)
> But most people aren't used to an "edit, run sfront, run gcc, run
> executable" cycle in their composing work. It's not exactly
> RCD (Rapid Composition Development (TM)).
Yep, and thats why God^TM invented Makefil
[...]
> Its worth noting that SGI\'s \"DM\" API has never really taken
> off, and there are lots of reasons why, some technical, some
> political.
Perhaps. See http://www.khronos.org/ for where SGI\'s dmSDK might
still be going. I think this API might be good for video. So maybe
it is not that go
[...]
> UST can be used for timestamping, but thats sort of useless, since the
> timestamps need to reflect audio time (see below).
I\'d like to have both a frame count (MSC) and a corresponding system time
(UST) for each buffer (the first frame). That way I can predict when (UST)
a certain perfo
SpamAssassin was not at all hapy with this mail:
On Mon, Jul 22, 2002 at 05:18:46PM -0300, Juan Linietsky wrote:
> SPAM: Start SpamAssassin results --
> SPAM: This mail is probably spam. The original message has been altered
> SPAM: so you can recognise o
/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
>[...]
>> UST = Unadjusted System Time
>
>I believe this is a good introduction to UST/MSC:
>
>http://www.lurkertech.com/lg/time/intro.html
i read this a year or two ago. it was a major impetus in the design of
JACK, because i believe that almost all of it is based on a complete
misconception of
>> UST = Unadjusted System Time
>>
>> I haven\'t seen any implementations of UST where you could specify a
>> different source of the clock tick than the system clock/cycle timer.
>
>Well, no. Is this needed. The UST should just be an accurate unadjusted
>clock that can be used for timestamping/s
[...]
> UST = Unadjusted System Time
I believe this is a good introduction to UST/MSC:
http://www.lurkertech.com/lg/time/intro.html
--martijn
Powered by ASHosting
[...]
> UST = Unadjusted System Time
>
> I haven\'t seen any implementations of UST where you could specify a
> different source of the clock tick than the system clock/cycle timer.
Well, no. Is this needed. The UST should just be an accurate unadjusted
clock that can be used for timestamping/sc
: <[EMAIL PROTECTED]>
Sent: Tuesday, July 23, 2002 9:31 PM
Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
> On Tue, Jul 23, 2002 at 07:38:25PM +0200, Martijn Sipkema wrote:
> (cut)
> >Using UST would also enable syncing to video or some other media
>
On Tue, Jul 23, 2002 at 07:38:25PM +0200, Martijn Sipkema wrote:
(cut)
>Using UST would also enable syncing to video or some other media
>stream without it all residing in the same API.
(cut)
That would certainly make me very happy :)
vini
>> >Why not have a seperate API/daemon for MIDI and
>> >have it and JACK both use the same UST timestamps?
>>
>> you can\'t use any timestamp unless its derived from the clock master,
>> which UST by definition almost never is. the clock on your PC doesn\'t
>> run in sync with an audio interface,
On Tue, Jul 23, 2002 at 06:21:42PM +0100, Steve Harris wrote:
> On Tue, Jul 23, 2002 at 12:42:38 -0400, Paul Winkler wrote:
> > I think it's stretching things a bit to refer to
> > sfront as a midi sequencer. It *can* produce midi output...
> > but that's it. no real user interface, no way to sav
> >Does that mean that MIDI output can only be done from a callback?
>
> No, it would mean that MIDI is only actually delivered to a timing
> layer during the callback. Just as with the ALSA sequencer and with
> audio under JACK, the application can queue up MIDI at any time, but
> its only deli
On Tue, Jul 23, 2002 at 12:42:38 -0400, Paul Winkler wrote:
> I think it's stretching things a bit to refer to
> sfront as a midi sequencer. It *can* produce midi output...
> but that's it. no real user interface, no way to save or restore
> state...
Er, vi foo.orc?
What better UI could you ask
On Tue, Jul 23, 2002 at 03:58:40PM +0100, Steve Harris wrote:
> On Tue, Jul 23, 2002 at 10:23:40 -0400, Paul Davis wrote:
> > for me, its more than tempting. none of the existing ALSA MIDI
> > sequencers have JACK support (that i know of). MusE is the only MIDI
>
> The only ones I know of are iiw
>Does that mean that MIDI output can only be done from a callback?
No, it would mean that MIDI is only actually delivered to a timing
layer during the callback. Just as with the ALSA sequencer and with
audio under JACK, the application can queue up MIDI at any time, but
its only delivered at spe
>I am not sure if this is the right way to go, but then I've never used the
>alsa seqeuncer API, and write no midi software anymore.
>
>What about the maximum jack buffer size issue. Is it reasonable to make
>all the apps do thier own limiting?
thats where the work comes in. the "read" side of th
>> (some people have suggested that Rosengarden
>> does audio too, but it seems to me that its firmly oriented towards
>> MIDI).
>
>*cough*
syrup duly swallowed :)
--p
On Tue, Jul 23, 2002 at 10:23:40 -0400, Paul Davis wrote:
> for me, its more than tempting. none of the existing ALSA MIDI
> sequencers have JACK support (that i know of). MusE is the only MIDI
The only ones I know of are iiwusynth and sfront.
I am not sure if this is the right way to go, but th
On 23.07.2002 at 15:35:58, Paul Davis <[EMAIL PROTECTED]> wrote:
> >On Tue, Jul 23, 2002 at 07:48:45 -0400, Paul Davis wrote:
> >> the question is, however, to what extent is it worth it. the reason
> >> JACK exists is because there was nothing like it available for moving
> >> audio data around.
Paul Davis wrote:
> for me, its more than tempting. none of the existing ALSA MIDI
> sequencers have JACK support (that i know of).
Apart from Rosegarden-4.
> (some people have suggested that Rosengarden
> does audio too, but it seems to me that its firmly oriented towards
> MIDI).
*cough*
Ro
On Tue, Jul 23, 2002 at 02:09:32PM +0100, Steve Harris wrote:
(cut)
>Yes, It's terrible. I remeber hearing from someone a year or so ago,
>who was incharge of cleaning up the source. I never heard any more though.
Well he had to clean it up,
I guess he just escaped and ran away ;)
vini
>On Tue, Jul 23, 2002 at 09:23:27 -0400, Paul Davis wrote:
>> >If you actaully want to deal with raw MIDI (you'd be mad, but...) then its
>> >OK, as the maximum ammount of data per jack unit time is pretty small, but
>> >I agree, it's better dealt with via the alsa api.
>>
>> struct jack_mi
On Tue, Jul 23, 2002 at 09:23:27 -0400, Paul Davis wrote:
> >If you actaully want to deal with raw MIDI (you'd be mad, but...) then its
> >OK, as the maximum ammount of data per jack unit time is pretty small, but
> >I agree, it's better dealt with via the alsa api.
>
> struct jack_midi_buf
>On Tue, Jul 23, 2002 at 07:48:45 -0400, Paul Davis wrote:
>> the question is, however, to what extent is it worth it. the reason
>> JACK exists is because there was nothing like it available for moving
>> audio data around. this isn't true of the MIDI side of things, where
>
>If you actaully want
On Tue, Jul 23, 2002 at 07:48:45 -0400, Paul Davis wrote:
> the question is, however, to what extent is it worth it. the reason
> JACK exists is because there was nothing like it available for moving
> audio data around. this isn't true of the MIDI side of things, where
If you actaully want to de
>On Mon, 2002-07-22 at 22:11, Phil Kerr wrote:
>> One of the strong points of Linux, and UNIX in general, is the way small
>> app's can be strung together, this is the most flexible approach.
>
>This is true, but only of apps that can fit in to the way that Unix does
>its stringing together; ie, f
Hi all,
I've been lurking on this list for a while. I have worked mainly for various
frontends of ecasound. Currently I am in the making of a curses-based
graphical wave-editor.
On Mon, 22 Jul 2002 22:27:31 -0300
Juan Linietsky <[EMAIL PROTECTED]> wrote:
> I'm talking about a "Project" man
On Tue, 23 Jul 2002, Vincent Touquet wrote:
> On Tue, Jul 23, 2002 at 12:07:43AM -0400, Paul Winkler wrote:
> >Does this help?
> >http://developer.gnome.org/arch/sm/extension.html
> (cut)
> >"_GSM_Priority
> (cut)
>
> So their would be a dependency on gnome-session-manager
> (and what else ?)
g
On Tue, Jul 23, 2002 at 12:07:43AM -0400, Paul Winkler wrote:
>Does this help?
>http://developer.gnome.org/arch/sm/extension.html
(cut)
>"_GSM_Priority
(cut)
So their would be a dependency on gnome-session-manager
(and what else ?)
regards
vini
On Tue, 23 Jul 2002 00:07:43 -0400
Paul Winkler <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 22, 2002 at 11:14:58PM -0400, Taybin Rutkin wrote:
> > The part about managing priorities suggests that an extension of
> > the x-session API would be required. So maybe a new project is
> > needed, but it w
On Mon, Jul 22, 2002 at 11:14:58PM -0400, Taybin Rutkin wrote:
> The part about managing priorities suggests that an extension of the
> x-session API would be required. So maybe a new project is needed, but it
> would make sense to see what's been done in this area before.
Does this help?
http:
> The part about managing priorities suggests that an extension of the
> x-session API would be required. So maybe a new project is needed,
> but it would make sense to see what's been done in this area before.
>
> Taybin
>
It's not anything remotely complex to worry about doing a new project
On Mon, 22 Jul 2002, Juan Linietsky wrote:
> -Saving current status of the apps, files open, data, etc, into a file
> you choose, or even
> be smart enough to tell your apps "save all your stuff here in this
> dir" and it does a nice tar.gz
> with your project in case you want to backup it.
> -L
On Mon, 22 Jul 2002 17:36:48 -0700
John Lazzaro <[EMAIL PROTECTED]> wrote:
> http://www.ietf.org/html.charters/mmusic-charter.html
No, no, none of this is of any use. We already have the best of the
best apis for audio and midi,
so this isnt the problem. Also to Taybin, what is meant isnt a
"se
> Bob Ham writes:
>
> Unfortunately, audio work
> isn't one of them. There is no such framework to provide similar
> functionality to audio programs, yet.
The IETF multimedia stack:
http://www.ietf.org/html.charters/avt-charter.html
http://www.ietf.org/html.charters/mmusic-charter.html
http://w
On Mon, Jul 22, 2002 at 06:41:45PM -0400, Taybin Rutkin wrote:
>On Mon, 22 Jul 2002, Juan Linietsky wrote:
(cut)
>Loading all the necessary programs with the links between them restored
>and the individual program files loaded as well? I think JACK would be a
>good place for this. I proposed som
On Mon, 22 Jul 2002 18:41:45 -0400 (EDT)
Taybin Rutkin <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Jul 2002, Juan Linietsky wrote:
>
> > But what about the overall status of the apps? not only the jack
> > network..
> > the idea i was refering to is how to "save _a_ project" when you
> > are running
On 22 Jul 2002 23:10:55 +0100
Bob Ham <[EMAIL PROTECTED]> wrote:
> On Mon, 2002-07-22 at 22:11, Phil Kerr wrote:
> > One of the strong points of Linux, and UNIX in general, is the way
> > small app's can be strung together, this is the most flexible
> > approach.
>
> This is true, but only of ap
On Mon, 22 Jul 2002 23:55:37 +0200
Vincent Touquet <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 22, 2002 at 04:44:00PM -0400, Paul Winkler wrote:
> >On Mon, Jul 22, 2002 at 05:18:46PM -0300, Juan Linietsky wrote:
> >> I think this can be solved by developing a metadata protocol
> >between> apps, so t
On Mon, 22 Jul 2002, Juan Linietsky wrote:
> But what about the overall status of the apps? not only the jack
> network..
> the idea i was refering to is how to "save _a_ project" when you are
> running
> 20 different apps interconncted by different means.
Well, what *exactly* is it that you wan
On Mon, 2002-07-22 at 22:11, Phil Kerr wrote:
> One of the strong points of Linux, and UNIX in general, is the way small
> app's can be strung together, this is the most flexible approach.
This is true, but only of apps that can fit in to the way that Unix does
its stringing together; ie, filestr
On Mon, 22 Jul 2002 22:11:49 +0100
Phil Kerr <[EMAIL PROTECTED]> wrote:
> One of the strong points of Linux, and UNIX in general, is the way
> small app's can be strung together, this is the most flexible
> approach.
>
> I think the level of audio app integration is coming on strong but
> we nee
On Mon, Jul 22, 2002 at 04:44:00PM -0400, Paul Winkler wrote:
>On Mon, Jul 22, 2002 at 05:18:46PM -0300, Juan Linietsky wrote:
>> I think this can be solved by developing a metadata protocol between
>> apps, so the can intercommunicate
>> status and other things, and having a "master" app that man
On Mon, Jul 22, 2002 at 05:18:46PM -0300, Juan Linietsky wrote:
> I think this can be solved by developing a metadata protocol between
> apps, so the can intercommunicate
> status and other things, and having a "master" app that manages
> projects and things like that, by just
> retrieving/storing
One of the strong points of Linux, and UNIX in general, is the way small
app's can be strung together, this is the most flexible approach.
I think the level of audio app integration is coming on strong but we
need to think of how we can interoperate using MIDI, preferably over
TCP/IP.
Being able
On Mon, 2002-07-22 at 21:18, Juan Linietsky wrote:
> So, what do you think about this issue? I'd really like to hear views
> on this since i guess it's probably
> the biggest problem the audio community is facing.
I've started working on the first; a big app that connects "things"
using jack and
1 - 100 of 103 matches
Mail list logo
