18 Jan
2008
18 Jan
'08
11:02 a.m.
Phil Rhodes wrote:
It seems to me dangerously like you're running off
down a road familiar
to Linux - create something that's a fantastic engineering solution and
runs at a million miles an hour on a 286, but which is completely
pointless and unusable because it won't talk to anything.
indeed, but do you have an alternative? It's sort-of a chicken-and-egg
issue. Back when jack was conceived, there were no jack clients either.
So you didn't have anything to 'talk to' either (important exception: a
soundcard).
If we can come up with something 'better than MIDI', it could be
interesting. Especially since these days a lot of audio stuff doesn't
leave the pc anyway. The only thing tying us to MIDI are the external
devices. And if the 'better than MIDI' can be downgraded to plain MIDI
you have something to talk with.
Greets,
Pieter
18 Jan
18 Jan
12:09 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, Jan 18, 2008 at 04:02:23PM +0100, Pieter Palmers wrote:
indeed, but do you have an alternative? It's
sort-of a chicken-and-egg
issue. Back when jack was conceived, there were no jack clients either. So
you didn't have anything to 'talk to' either (important exception: a
soundcard).
Right :-)
If we can come up with something 'better than
MIDI', it could be
interesting. Especially since these days a lot of audio stuff doesn't leave
the pc anyway. The only thing tying us to MIDI are the external devices.
And if the 'better than MIDI' can be downgraded to plain MIDI you have
something to talk with.
That is exacly what I have in mind. I'll gather the bits and pieces I
have during the WE and come up with a proposal...
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
12:30 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, 2008-01-18 at 16:02 +0100, Pieter Palmers wrote:
indeed, but do you have an alternative? It's
sort-of a chicken-and-egg
issue. Back when jack was conceived, there were no jack clients either.
So you didn't have anything to 'talk to' either (important exception: a
soundcard).
i don't know that it matters, but this is not strictly how it happened.
JACK was developed out of Ardour's initial AudioEngine object. As a
result, when the first version of JACK was available, Ardour could
already use it. how much of an incentive or disincentive this was to
JACK's adoption is probably not relevant.
--p
3:43 p.m.
New subject: [Jack-Devel] JACK & MIDI
Paul Davis wrote:
On Fri, 2008-01-18 at 16:02 +0100, Pieter Palmers
wrote:
Let me rephrase my remark to make it more correct: jack itself was
probably conceived with only one client and a soundcard to talk to, and
hence could also be denoted as a 'fantastic engineering solution that
doesn't talk to anything', at least not the way it does now.
The point I'm trying to make is that sometimes things start out with a
limited use scenario, but evolve into something generally adopted. And
sometimes this evolution doesn't take place...
Thanks for the correction, I wasn't that LAD-active back then.
Incredible how old jack has become... and still no 1.0 :)...
Greets,
Pieter
indeed, but do you have an alternative? It's
sort-of a chicken-and-egg
issue. Back when jack was conceived, there were no jack clients either.
So you didn't have anything to 'talk to' either (important exception: a
soundcard).
i don't know that it matters, but this is not strictly how it happened.
JACK was developed out of Ardour's initial AudioEngine object. As a
result, when the first version of JACK was available, Ardour could
already use it. how much of an incentive or disincentive this was to
JACK's adoption is probably not relevant.
19 Jan
19 Jan
12:40 a.m.
New subject: [Jack-Devel] JACK & MIDI
Paul Davis wrote:
i don't know that it matters, but this is not
strictly how it happened.
JACK was developed out of Ardour's initial AudioEngine object. As a
result, when the first version of JACK was available, Ardour could
already use it. how much of an incentive or disincentive this was to
JACK's adoption is probably not relevant.
It surely didn't hinder it. ;-) But seriously, this is an important
point. You can't just come up with an extended protocol like this
without knowing a great deal about the demands of advanced applications
in this realm (SuperCollider et al).
Most people just talk about MIDI's resolution issues, which are
important, but there's other things that would be good to have in a
"better than MIDI" protocol:
- Dynamic voice allocation, a.k.a. a way to manage a lot of temporary
voices.
- Flexible and easy controller mapping, to make it easy to interface to
different between different hardware and software.
- Feature discovery. Something like what controller types does this
device/software understand, what are the default values and ranges of
controllers, etc.
That's from the top of my head, I'm sure there are other points to consider.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
21 Jan
21 Jan
5:24 a.m.
New subject: [Jack-Devel] JACK & MIDI
- Flexible and easy controller mapping, to make it
easy to
interface to
different between different hardware and software.
- Feature discovery. Something like what controller types does this
device/software understand, what are the default values and ranges of
controllers, etc.
All it takes to solve these two issues is an appropriate use of SYSEX
- request and dump - and some open documentation on the contents of
the headers. I've implemented XML-over-SYSEX to solve this issue in
one fell swoop, and as ugly as that sounds, it sure worked fine for
the prototypes for which the code was written .. of course that was
all for naught in favour of hacky, ugly, proprietary solutions, (such
as "Total Integration"), but hey .. it can be done, realistically.
;
--
Jay Vaughan
6148
days inactive
6151
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
Albert Graef -
Fons Adriaensen -
Jay Vaughan -
Paul Davis -
Pieter Palmers