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 benefit of
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 ! Another neat
| On Tue, 23 Jul 2002 03:14:56 -0400
| Paul Winkler pw_lists_AT_slinkp.com 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
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...
You
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 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 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 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 one wouldn't
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 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
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
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 deal
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 deal
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.h | gcc
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_buffer_t {
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_buffer_t {
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
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*
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. this isn\'t
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 the
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
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
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?
Also
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 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
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
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
...
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 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 save or
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, and will
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, 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 some
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 data
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
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, July
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 public
[...]
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
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
[...]
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/scheduling
[...]
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 how to
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 are
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 are
/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,
44 matches
Mail list logo
