/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
>> 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 how to do this stuff, and some of it is just plain wrong. Its worth
>> noting that SGI's "DM" API has never really taken off, and th
> 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 how to do this stuff, and some of it is just plain wrong. Its worth
> noting that SGI's "DM" API has never really taken off, and there
>[...]
>> 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
Yamaha has a large NDA tradition,
making lots of things impossible.
As another example: the filesystem
format of their A series samples storage.
It would be so nice if you could mount
these disks in Linux too, but yammy
refuses without an NDA ...
Ask them the question though :)
They have to com
[...]
> 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
> > What about Yamaha's mLan ?
> > I thought that was some kind of midi over firewire,
> > but maybe they didn't grab it as an opportunity
> > to improve on midi ...
>
> It's midi and audio over firewire.
> I think it's plain vanilla midi messages, though.
> not sure.
mLAN is built on top of the
There is no royalty fee for mLan. You just have to register with Yamaha to
become a Licensee (the process is lengthy because of the distance, it took
not far from 2 month for me).
Sebastien
- Original Message -
From: "Paul Davis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday,
Then you'd have to provide a way to do offline processing to. The clock
source can't be the system clock in that case... (offline processing IS
important for the musicians :-))
Sebastien
- Original Message -
From: "Vincent Touquet" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesda
On Tue, Jul 23, 2002 at 12:31:13PM +0100, Steve Harris wrote:
> Yes, this is important, it should be possible to mail the tarball to a
> friend who can then start up the project (assuming he has all the apps
> installed of course).
That would be one hell of a mail message. :)
Now, an rsync server
They don't even touch the idea of changing midi. (i'm registered with them
as an mLan Licensee).
Sebastien
- Original Message -
From: "Vincent Touquet" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 23, 2002 9:30 PM
Subject: Re: [linux-audio-dev] App metadata intercomuni
On Tue, Jul 23, 2002 at 09:30:10PM +0200, Vincent Touquet wrote:
> What about Yamaha's mLan ?
> I thought that was some kind of midi over firewire,
> but maybe they didn't grab it as an opportunity
> to improve on midi ...
It's midi and audio over firewire.
I think it's plain vanilla midi message
>On Tue, Jul 23, 2002 at 02:00:15PM -0300, Juan Linietsky wrote:
>(cut)
>>Yes, I agree that midi sucks. I'm wondering why dont we have
>>a newer protocol by now, but we dont. So there's nothing else
>>than having to stick to that archaic crap :)
>(cut)
>
>What about Yamaha's mLan ?
>I thought tha
On Tue, Jul 23, 2002 at 01:14:18PM -0500, Arthur Peters wrote:
(cut)
>I think there might be problems with option 1 when the apps are running
>on different machines (as was mensioned earlier). Maybe a hybrid would
>work: provide an API for each app to pass it's data to the project
>server. This da
On Tue, Jul 23, 2002 at 02:00:15PM -0300, Juan Linietsky wrote:
(cut)
>Yes, I agree that midi sucks. I'm wondering why dont we have
>a newer protocol by now, but we dont. So there's nothing else
>than having to stick to that archaic crap :)
(cut)
What about Yamaha's mLan ?
I thought that was som
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
On Tue, 2002-07-23 at 05:11, .n++k wrote:
>
> Anyway, as a summary, what is the be solved:
> . defining, naming, identifying a session (= project)
> . communicating with the apps to request loading and saving
> session associated data.
> . 1. each app is passed enough knowledge to store
>> >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
On Tue, Jul 23, 2002 at 02:00:15PM -0300, Juan Linietsky wrote:
> Yes, I agree that midi sucks. I'm wondering why dont we have
> a newer protocol by now, but we dont. So there's nothing else
> than having to stick to that archaic crap :)
Because the hardware music device market moves a lot more
On Tue, Jul 23, 2002 at 12:43:32PM +0100, Steve Harris wrote:
> One hard thing is how to deal with communication interdependencies, eg.
> app A talks jack to app B and app B talks alsa sequencer to app A.
Why is this hard?
ensure ALSA is up
start jackd
start jack client 1
start jack client 2
...
> >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:11:23PM +0200, .n++k wrote:
> But aren't musicians a different kind of users than desktop users?
how so? more technical? I don't really think so.
we just had a guy on linux-audio-user who says he's been
familiar with unix since at least the early eighties,
and he's b
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, 23 Jul 2002 11:28:01 +0200
Vincent Touquet <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 23, 2002 at 02:30:22AM -0300, Juan Linietsky wrote:
> >ok, but the question is, what for? What else do you need other than
> >start/stop/seek ? doesnt midi proovide that already? then why
> >something else
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
On Tue, Jul 23, 2002 at 11:24:03AM +0200, Vincent Touquet wrote:
> On Tue, Jul 23, 2002 at 01:17:53AM -0400, Paul Winkler wrote:
> >actually zipi and skini.
> >tooskini has something to do with perry cook's STK.
>
> I though skini is just readable MIDI ?
> Hit me if I'm wrong though.
it's mostly
>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 01:14:02 +0100, Bob Ham wrote:
> On Tue, 2002-07-23 at 09:45, .n++k wrote:
>
> > that's 15M, of which 5M (mysql-test. sql-bench) are useless
> >
> > i would hardly call that big
>
> 28K /usr/local/include/ladspa.h
And that includes comments:
$ cat /usr/include/ladspa
>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
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-bench) are useless
node> >
node> >
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 Tue, 2002-07-23 at 09:45, .n++k wrote:
> that's 15M, of which 5M (mysql-test. sql-bench) are useless
>
> i would hardly call that big
28K /usr/local/include/ladspa.h
It's big. Don't get over-zealous here. Complexity is the inverse of
reliability, remember.
--
Bob Ham: [EMAIL PROTECT
>Well i don't see it as unnecessary, just for the reason that you NEED
>a database. so any objection is either a practical one or a theorical
>one. Maybe the hidden objection is that it's too complicated for an
>application writer to relationalize his application's data
>model.. Myself i find it d
>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
On RDMSs
Look, I like SQL as much as the next man, but its really not appropraite
for storing application state. RDMSs have loads of features that we just
dont need for this.
Most applications allready handle saving (some of) thier state to a file,
we just need to define a way to instruct them t
On Tue, Jul 23, 2002 at 04:56:06 -0300, Juan Linietsky wrote:
> > > 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
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
Using a DB for such a job has no real advantage because saving a project is
just the begining of the story. After having been able to save your project
you'll want to have a simple way to backup it simply, to move it to another
computer (for exemple from a laptop computer to a desktop computer in
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
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 session/project metadata?
async> > |
> Yep, think of 0-127 ranges for controller data :(
> That is too coarse;
MIDI provides 14bit controller resolution by having controller
pairs. That should be enough for controller since most sliders/knobs
on hardware have much less than that.
Pitch bend is 14bit also, allthough there is a lot of
On Tue, Jul 23, 2002 at 10:45:55AM +0200, .n++k wrote:
> | > > 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 on
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, Jul 23, 2002 at 04:56:06AM -0300, Juan Linietsky wrote:
>And also you cant do the neat thing of asking all your apps to save
>all their data
>to a directory so you can create a targzip with the project :)
That point is irrelevant,
you can extract everything from
the database and tar gzip
On Tue, Jul 23, 2002 at 08:43:36AM +0200, n++k wrote:
>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
On Tue, Jul 23, 2002 at 02:30:22AM -0300, Juan Linietsky wrote:
>ok, but the question is, what for? What else do you need other than
>start/stop/seek ? doesnt midi proovide that already? then why
>something else?
>Also using midi you make sure that what you do is synced to external
>devices...
Yo
On Tue, Jul 23, 2002 at 01:17:53AM -0400, Paul Winkler wrote:
>actually zipi and skini.
>tooskini has something to do with perry cook's STK.
I though skini is just readable MIDI ?
Hit me if I'm wrong though.
regards
vini
On Mon, Jul 22, 2002 at 11:21:56PM -0500, Arthur Peters wrote:
(cut)
>MIDI is very powerful, but it is also very
>restrictive in some ways.
Yep, think of 0-127 ranges for controller data :(
That is too coarse;
>Just a thought. I don't know much about these subjects.
Well I'm not an expert either
| 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?
| > > (configuration and such) We have the benef
Dave Phillips wrote:
>
> Steve Harris wrote:
>
> > http://plugin.org.uk/releases/0.2.8/
> >
> > New stuff:
> >[snip]
> >Plate reverb phsical model, full of platey goodness
>
> Oooh, plate reverb ! I love plate reverbs, so I wired this one up in
> Snd, applied it, and... hey, not bad ! A
Using a SQL DB with XML is less than optimal partly for the reasons Paul
mentions below.
http://xml.apache.org/xindice/
Xindice is a fully native XML DB and is cross-platform (thinking
cross-platform goes together with a distributed architecture).
Although having to use a DB to store metadata c
On Tue, 23 Jul 2002 03:14:56 -0400
Paul Winkler <[EMAIL PROTECTED]> 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?
> > (configuration and such) We have the be
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?
> (configuration and such) We have the benefit of having a few quite
> stable free software SQL databases. (mysql, postgresql,
64 matches
Mail list logo
