16 Jan
2008
16 Jan
'08
9:49 a.m.
With the release of Jack 0.109 we now have a (hopefully)
stable API for midi-over-jack. This set me to consider what
would be required to modify Aeolus to use this system.
And I did not like the conclusions.
Is it a good idea to insert a 30-year old data format
that mixes real-time and general data on a single stream
into a real-time audio processing API ? I don't think so.
1. Note on/off and controller events now can be 'sample
accurate'. That's nice to have. But a) they are not and
never will be 'sample accurate' if they come from a HW
midi device, and b) if they are generated in software then
you can have, and for some applications you actually want
much more finer grained timestamps and controller values.
So it's a solution that in one case is plain overkill,
and in the other it's just not good enough.
2. *All* MIDI data now has to pass through the RT-audio
audio thread, even if it's not related to any RT operations
at all, and in many cases, not even meant for the receiving
application. What is the poor process callback to do with
sysex memory dumps, sample downloads, and in most cases,
even program changes ? The only thing it can do is get rid
of this ballast as fast as possible, dumping it in a buffer
to be processed by some lower-priority process, and hoping
it will not be blocked or forced to discard data. Forcing
a critical RT-thread to waste its time in this way is IMHO
not good program design, not even if the overhead can be
tolerated. That sort of data should never go there.
Some sort of solution could be to let the MIDI backend do
at least part of the filtering - it could have several
jack-midi ports corresponding to a single raw midi input
and e.g. separate note on/off, controller events, and
sysex messages. An app that wants to receive all can
still do so without any significant overhead, it just
needs a few more ports.
And once e,g. note on/off and controller updates have
dedicated ports, there is no more need to keep the MIDI
format with all its limitations.
This will be enough for some flames, so I'll stop here
:-)
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
16 Jan
16 Jan
10:06 a.m.
On Wed, 2008-01-16 at 14:43 +0100, Fons Adriaensen wrote:
With the release of Jack 0.109 we now have a
(hopefully)
stable API for midi-over-jack. This set me to consider what
would be required to modify Aeolus to use this system.
And I did not like the conclusions.
Is it a good idea to insert a 30-year old data format
that mixes real-time and general data on a single stream
into a real-time audio processing API ? I don't think so.
Nobody else does either.
But: there is *no* other standard that exists to describe what MIDI
describes in a useful way that is even close to be remotely useful with
a variety of h/w and s/w.
So: we make do.
JACK MIDI was explicitly designed with the idea that it would *not* be
useful for large sysex messages. we looked at it and decided that it was
not possible to come up with an API that would serve both goals.
--p
1:25 p.m.
Hi Paul!
Pardon me, being technically far from even OK. But I think especially this
sysex thing is important. Consider a real studio (home or pro), there are
still a lot of external devices, which occasionally need to receive sysex
(special program banks, sample updates). For me this is an issue and I believe
I'm not alone there.
So: did you consider extending, pollishing the API so this is possible or
would you have an acceptable workaround up your sleve?
I'm just interested so please don't be offended. It has been great work so
far and I'm grateful for it, but I'm also interested in improving my work as a
musician, so this is of importance to me.
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
1:29 p.m.
Hi Julien!
On Jan 16, 2008 8:25 PM, Julien Claassen <julien(a)c-lab.de> wrote:
(special program banks, sample updates). For me this
is an issue and I believe
I'm not alone there.
You are perfectly right!
So: did you consider extending, pollishing the API
so this is possible or
would you have an acceptable workaround up your sleve?
I have a possible solution
and will try to specify it in a patch form
when I find time.
Plans are to do it before LAC2008.
Kind regards,
Dmitry.
12:02 p.m.
Fons Adriaensen wrote:
With the release of Jack 0.109 we now have a
(hopefully)
stable API for midi-over-jack. This set me to consider what
would be required to modify Aeolus to use this system.
And I did not like the conclusions.
Is it a good idea to insert a 30-year old data format
that mixes real-time and general data on a single stream
into a real-time audio processing API ? I don't think so.
1. Note on/off and controller events now can be 'sample
accurate'. That's nice to have. But a) they are not and
never will be 'sample accurate' if they come from a HW
midi device, and b) if they are generated in software then
you can have, and for some applications you actually want
much more finer grained timestamps and controller values.
So it's a solution that in one case is plain overkill,
and in the other it's just not good enough.
2. *All* MIDI data now has to pass through the RT-audio
audio thread, even if it's not related to any RT operations
at all, and in many cases, not even meant for the receiving
application. What is the poor process callback to do with
sysex memory dumps, sample downloads, and in most cases,
even program changes ? The only thing it can do is get rid
of this ballast as fast as possible, dumping it in a buffer
to be processed by some lower-priority process, and hoping
it will not be blocked or forced to discard data. Forcing
a critical RT-thread to waste its time in this way is IMHO
not good program design, not even if the overhead can be
tolerated. That sort of data should never go there.
Some sort of solution could be to let the MIDI backend do
at least part of the filtering - it could have several
jack-midi ports corresponding to a single raw midi input
and e.g. separate note on/off, controller events, and
sysex messages. An app that wants to receive all can
still do so without any significant overhead, it just
needs a few more ports.
And once e,g. note on/off and controller updates have
dedicated ports, there is no more need to keep the MIDI
format with all its limitations.
This will be enough for some flames, so I'll stop here
:-)
I guess you will agree if I state that it would have been better if you
performed this though experiment while the API was still in a volatile
stage. But that observation doesn't help us, so let's not go down that
path. (FWIW I didn't think about the jack-midi API either back then...)
A first note on sample-accuracy: a FireWire device provides midi events
muxed with the audio samples. These midi events have the same timestamps
as audio events. IOW firewire devices can provide sample accurate midi
timing. Whether they actually *do* is another question, but technically
it doesn't look that challenging. Also note that while the data format
might be MIDI, there doesn't have to be an actual midi cable in place.
E.g. a master controller keyboard with built-in FireWire transport.
Hence your 1.a statement is incorrect (especially the 'never be' part).
Regarding 1.b: that smells like the 'control ports' discussed on
jack-devel a while ago. I think it's a matter of what the goal is. And I
think the goal is more 'simple midi support' than complex control flow.
Which could also be implemented I guess, but that needs a rather
thorough discussion on the API.
Regarding 2: The idea you have on the backend filtering seems
reasonable, but I don't like the idea of having multiple backend ports
for the same 'midi channel'. A more general approach would IMHO be to
have some sort of subscription system where a client can specify what
type of midi events it wants at a port.
Note that doesn't solve the issue of the RT thread having to deal with
MIDI data. But that's unavoidable since there is no concept of 'non-RT
ports' in jack. And introducing that is not really easy I'd say. Or
maybe it is?
A general solution might be to have:
* an IS_RT flag on a port
* both an RT callback and a non-RT callback
* a third port type that implements the ideal fine-grained control API
But I don't want to be the person to design/implement this. The amount
of corner cases is huge.
Greets,
Pieter
12:47 p.m.
On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter Palmers wrote:
I guess you will agree if I state that it would have
been better if you
performed this though experiment while the API was still in a volatile
stage. But that observation doesn't help us, so let's not go down that
path. (FWIW I didn't think about the jack-midi API either back then...)
Well, IIRC, I did raise my voice then, saying it was a pity
that it was actually MIDI that was being implemented, with all
its limitations, and not some extended format that midi could
be trivially and losslessly translated to, using e.g. 32-bit
controller numbers, and floating point note numbers and
controller values.
But, as I was sad to note then, some people are horrified by the
idea of having to round a float to an int *** for each and every
note *** if their app only supports semitones... It's 'too complex
for beginners' and also 'inefficient'. The fact that the int will
later be converted to thousands of FP values anyway is conveniently
forgotten. I don't remember if this turned up in the jack-midi
discussion or in the one about LV2, but that sort of arguments
have been used, and repeated, and that makes me bail out at some
point.
I only picked up the thread yesterday when considering how to adapt
Aeolus to midi-over-jack. The audio thread only handles note on/off
directly, all the rest will have to be diverted to the 'model' thread
somehow. Not a clean thing.
... E.g. a master controller keyboard with built-in
FireWire transport.
Hence your 1.a statement is incorrect (especially the 'never be' part).
I stand by the 'never' -:) By HW MIDI devices I mean those that
use the MIDI electrical format rather than just the data encoding.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
1:53 p.m.
Fons Adriaensen wrote:
Well, let's say that jack-midi allows for a more broad interpretation of
'midi', one that matches the firewire one better.
And even with HW midi devices thing can be sample accurate. The fact
that the MIDI link is low-bandwidth doesn't rule out that it can have
strictly controlled timing. If a device has a constant latency between
the time instant a key is pressed and the first (or last) message byte
is sent, sample accurate timestamping at the receive side does make
sense since it preserves the relative timing information between events
(albeit quantized rather rough). I don't think however that such
behavior is part of the spec, and hence it's probably a non-argument.
In short, I still contest the 'never' part :P.
Greets,
Pieter
On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter
Palmers wrote:
I withdraw my remark, I'm sorry.
I guess you will agree if I state that it would
have been better if you
performed this though experiment while the API was still in a volatile
stage. But that observation doesn't help us, so let's not go down that
path. (FWIW I didn't think about the jack-midi API either back then...)
Well, IIRC, I did raise my voice then, saying it was a pity
that it was actually MIDI that was being implemented, with all
its limitations, and not some extended format that midi could
be trivially and losslessly translated to, using e.g. 32-bit
controller numbers, and floating point note numbers and
controller values.
But, as I was sad to note then, some people are horrified by the
idea of having to round a float to an int *** for each and every
note *** if their app only supports semitones... It's 'too complex
for beginners' and also 'inefficient'. The fact that the int will
later be converted to thousands of FP values anyway is conveniently
forgotten. I don't remember if this turned up in the jack-midi
discussion or in the one about LV2, but that sort of arguments
have been used, and repeated, and that makes me bail out at some
point.
I only picked up the thread yesterday when considering how to adapt
Aeolus to midi-over-jack. The audio thread only handles note on/off
directly, all the rest will have to be diverted to the 'model' thread
somehow. Not a clean thing.
How would you solve it otherwise? As I see it you have
(a) only the need to capture (certain) realtime midi messages
(b) the need to capture both realtime and non-realtime messages (program
change ?).
in the (a) case you simply drop every event that's not a note-on/off. No
need to send things to a low-prio thread
in the (b) case, a separate backend port for non-rt data won't help you
since ports are assumed to be handled in the process() callback (AFAIK).
... E.g. a master controller keyboard with
built-in FireWire transport.
Hence your 1.a statement is incorrect (especially the 'never be' part).
I stand by the 'never' -:) By HW MIDI devices I mean those that
use the MIDI electrical format rather than just the data encoding.
2:33 p.m.
On Wed, 2008-01-16 at 17:41 +0100, Fons Adriaensen wrote:
Well, IIRC, I did raise my voice then, saying it was a pity
that it was actually MIDI that was being implemented, with all
its limitations, and not some extended format that midi could
be trivially and losslessly translated to, using e.g. 32-bit
controller numbers, and floating point note numbers and
controller values.
so, fons, you're proposing one or both of:
1) that this community somehow magically defines a new standard
for musical information, despite the complete failure of
the entire field of music technology to do this for the
last 30 years.
2) that the relatively few pieces of s/w (and in all likelihood,
absolutely no hardware) that actually use this new
standard internally get to save a few cycles at the
expense of the dozens and dozens of existing s/w and h/w
implementations of MIDI itself.
Neither makes any sense to me.
When a wide enough community embraces a new serial data protocol for
music data, it will be implemented in JACK very quickly. Until that new
protocol emerges, we are not going to waste cycles converting from float
to int in the vast majority of apps just so that a handful of apps can
save the convertion.
As far as greater-than-sample-accurate timing - yes, I understand it has
its uses, but there is no concept of fractional sample time in JACK at
present, and introducing it just to allow something that again forces
the vast majority of apps to do *more* work (the dreaded float->int
conversion) in order to facilitate some interesting corner cases to work
more efficiently ... well, I just don't see the justification.
I stand by the 'never' -:) By HW MIDI devices
I mean those that
use the MIDI electrical format rather than just the data encoding.
these are becoming less and less significant every day. MIDI over USB,
MIDI over ethernet, MIDI over firewire etc etc.
17 Jan
17 Jan
8:49 a.m.
On Wed, Jan 16, 2008 at 01:32:32PM -0500, Paul Davis wrote:
so, fons, you're proposing one or both of:
1) that this community somehow magically defines a new standard
for musical information, despite the complete failure of
the entire field of music technology to do this for the
last 30 years.
2) that the relatively few pieces of s/w (and in all likelihood,
absolutely no hardware) that actually use this new
standard internally get to save a few cycles at the
expense of the dozens and dozens of existing s/w and h/w
implementations of MIDI itself.
Neither makes any sense to me.
And neither I propose.
Using wider data types internally (we are running on 32 and 64-bit
machines today !) is not 'defining a new standard for the entire
field of music technology'. Jack *has* actually taken this step
for audio data, by representing all samples as floats while the
hardware world, including almost all sound cards I know of, is
still using 16 and 24 bit integers.
It would at least allow software apps to use more fine grained
musical parameters. It *could* create a problem when you have
to convert back to plain old 8-bit MIDI to be sent to a physical
port. But that's the same one we have for audio samples - if you
go back from float to 16-bit you can have clipping and you need
to dither. Nobody makes any fuss about that. Jack just does it
behind the scenes.
And no, I'm not concerned about a few more cycles, but it seems
others are, if they have round a float note number to an int.
Which is completely silly once you consider the number of cycles
that will be required to calculate the actual samples for the
same note.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
4:39 p.m.
On Wed, 2008-01-16 at 17:41 +0100, Fons Adriaensen wrote:
On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter
Palmers wrote:
What it /really/ should be is a generic event transport mechanism (only
arbitrary FonsControls(TM) is just as bad as only arbitrary MIDI, and
jack doesn't need to care what the actual events are whatsoever).
I proposed this - in patch form - to the jack list ages ago and it was
shot down. I don't recall there ever being a legitimate "why".
-DR-
I guess you will agree if I state that it would
have been better if you
performed this though experiment while the API was still in a volatile
stage. But that observation doesn't help us, so let's not go down that
path. (FWIW I didn't think about the jack-midi API either back then...)
Well, IIRC, I did raise my voice then, saying it was a pity
that it was actually MIDI that was being implemented, with all
its limitations, and not some extended format that midi could
be trivially and losslessly translated to, using e.g. 32-bit
controller numbers, and floating point note numbers and
controller values.
5 p.m.
On Wed, 2008-01-16 at 17:41 +0100, Fons Adriaensen wrote:
On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter
Palmers wrote:
Indeed, but if you look at the actual implementation, the only thing
that even knows or cares it's MIDI is the drivers.
I guess you will agree if I state that it would
have been better if you
performed this though experiment while the API was still in a volatile
stage. But that observation doesn't help us, so let's not go down that
path. (FWIW I didn't think about the jack-midi API either back then...)
Well, IIRC, I did raise my voice then, saying it was a pity
that it was actually MIDI that was being implemented But, as I was sad to note then, some people are
horrified by the
idea of having to round a float to an int *** for each and every
note *** if their app only supports semitones... It's 'too complex
for beginners' and also 'inefficient'. The fact that the int will
later be converted to thousands of FP values anyway is conveniently
forgotten. I don't remember if this turned up in the jack-midi
discussion or in the one about LV2, but that sort of arguments
have been used, and repeated, and that makes me bail out at some
point.
For the record, LV2 events are going with a fixed frames/subframes
timestamp, for several reasons. Namely it's both easier and more
accurate, works for tempo based or frame based or time based time, and
is binary compatible with every timestamp spec anyone cares about.
If anyone is seriously considering throwing Jack MIDI API out the
window, look at the LV2 event header here (just LV2_Event, ignoring the
type number mapping to URI bit):
http://svn.drobilla.net/lad/lv2/extensions/events/lv2_events.h
- Sub-sample accurate
- Which you can blissfully ignore and just use frames if you like
- And happens to be incredibly convenient inside apps (I know)
- Event type agnostic
An API nearly identical to the Jack MIDI one could transport something
like that around, and __any__ kind of event (including MIDI, or whatever
else people come up with) can be easily transported around, without
changing the API for new events at all (other than picking a number for,
say, OSC).
Of course, it doesn't, and probably won't, because this discussion is
happening now instead of months or years ago when it should have.
No modifications to the Jack MIDI API are going to happen in anything
that isn't called "Jack 2.0". We just _finally_ got the damn API out
there, and there is NO way in hell it's going to break again.
That said, the events should clearly be generic, unless someone can come
up with a good idea otherwise.
-DR-
6:13 p.m.
and the technical ignorant again.
Correct if I'm far wrong: lv2 does roughly contain what you were looking
for.
The LV2 API is (at least mechanically or whatevfer) not to far from the JACK
MIDI approach.
About the format being float or what, having to be converted to 7BIT
MIDI-controls: JACK has audio-ditherin, it could contain functions for
"MIDI-control"-dithering. At least ones the programmer could decide to call,
activate. Doesn't really matter which one. At least, it would be something the
app needs to do. If each author writes it himself or if JACK offers some
simple standard functions to do it is - pardon my French - shit. A function
like this would be so simple even _I_ could write it. - About spending
CPU-cycles: you'd know more than me. But with a simple well-designed plan it's
not too bad.
Why can't those people who discussed it here (Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API - as
it is - and try to work this new concept around it.
As I'm aware - I might be wrong, but probably not - there are still very few
clients, which really support JACK MIDI. And if you all can agree, that
there's still work to be done, others would most certainly obstain
frommigrating to JACK MIDI until those problems are solved to a point of a
stable API at least.
I may be far wrong: But to me it seems like more religeous than scientific
dispute. And oppinions can always be shared, negotiated and partially be built
into existing concepts.
Besides in the main part it seems like the proposals of this discussion are
more an extension to the existing system, than a counter-proposal. Why not try
to get together perhaps ask around who wants to be in it, get an IRC-channel,
meet at LAC 2008 (for whom it's possible) and try to exchange oppinions. As
we've seen earlier, such meetings, private real discussions (take the phone if
all else lacks), have resulted in changes for the better. I intend to offend
noone, but see Csound. It stood still for so long, and a few words spoken from
one person to another, and soon after csound moved on and they discovered,
they all had roughly the same thing in mind.
Please excuse me for the length and probably the impertinence of this mail.
But I like to see moving. I can't really code anything myself, but I just
hoped I could cool down the mood a bit.
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
9:28 p.m.
On Thu, 2008-01-17 at 23:13 +0100, Julien Claassen wrote:
and the technical ignorant again.
Correct if I'm far wrong: lv2 does roughly contain what you were looking
for.
The LV2 API is (at least mechanically or whatevfer) not to far from the JACK
MIDI approach.
Well, if you were to wrap functions around it it would be about the same
anyway (there's no event "API" for LV2 really, but Jack of course
wouldn't have exposed structs like the header I pointed to)
As I'm aware - I might be wrong, but probably
not - there are still very few
clients, which really support JACK MIDI. And if you all can agree, that
there's still work to be done, others would most certainly obstain
frommigrating to JACK MIDI until those problems are solved to a point of a
stable API at least.
There are plenty of people using it, and the API is stable as of 0.109.0
- it's definitely not changing (again) in Jack 1. The existing one is
fine for the uses intended anyway (if you're doing massive sysex dumps,
don't use Jack)
But there will be a Jack 2 at some point...
-DR-
18 Jan
18 Jan
9:06 a.m.
Am Freitag, 18. Januar 2008 01:28:28 schrieb Dave Robillard:
There are plenty of people using it, and the API is
stable as of 0.109.0
- it's definitely not changing (again) in Jack 1. The existing one is
fine for the uses intended anyway (if you're doing massive sysex dumps,
don't use Jack)
But there will be a Jack 2 at some point...
Sorry for throwing myself into this discussion, but why does that proposal
issue sound like an either or question? Actually I understand both positions,
the current JACK MIDI implementation should be fine for most of us and is
already in use by couple of apps, on the other hand I definitely agree with
Fons that it's really time to get rid of those ancient old MIDI constraints.
So why not having both solutions in the JACK API at the same time? JACK could
automatically do the conversion (where possible of course) for clients that
use the different two "MIDI" APIs in JACK. So that would provide a smooth
transition for the JACK universe from old MIDI to .... uhm whatever it would
be called ...
CU
Christian
8:14 a.m.
On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien Claassen wrote:
Why can't those people who discussed it here
(Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API - as
it is - and try to work this new concept around it.
Well, the two you mention have a long history of not having radically
different views... :-)
Seriously, there are three things that I profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
2. Note events are identified by their frequency.
3. The only thing that can actually refer back to a note on event
is it's corresponding 'note off' message. It's not possible to
send a controller value that refers to a previous note-on event.
The worst result of all this, and what really drives me nuts is that
the same limits get built-in, carved in stone, into each and every
piece of sequencing software. They all perpetuate what is in fact
a form of cultural poverty "there's not quarter tones in pop music,
so they don't exist" while technically there is no more reason to
do so.
Midi-over-jack has missed the chance to fix 1) which would have
been relatively easy. And even 2) and 3) are not so difficult to
get rid of.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
9:05 a.m.
Fons Adriaensen wrote:
Seriously, there are three things that I profoundly
dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
Agreed. The MIDI Tuning Standard (MTS) was invented to fix that, but it
doesn't really help with the "12 notes per octave" limitation and, being
sysex, isn't really realtime, so it wouldn't be suitable to tune Aeolus
on the fly anyway.
So I guess the only real option for Aeolus right now would be to support
both MIDI (possibly via Jack) for the basic "I'm a 16 part MIDI organ
with 12 notes per octave" interface and OSC for dynamic voice allocation
and the advanced "I can play any n-tone temperament and even change them
on the fly" stuff. (I vaguely recall that this has been dicussed here
before, so maybe Aeolus already has an OSC interface?)
Just my 0.0002 semitones. :)
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
9:32 a.m.
On Fri, Jan 18, 2008 at 02:07:26PM +0100, Albert Graef wrote:
Fons Adriaensen wrote:
The limits I referred to don't affect Aeolus, except that there's
no MIDI concept of 'stops' or anything near to it.
They affect anyone who wants to use sequencing tools and/or soft synths,
while not being limited by MIDI's 'culturally challenged' idea what music
is or could be.
Retuning Aeolus is very non-real-time operation anyway, and currently
Aeolus doesn't accept MTS.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
Seriously, there are three things that I
profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
Agreed. The MIDI Tuning Standard (MTS) was invented to fix that, but it
doesn't really help with the "12 notes per octave" limitation and, being
sysex, isn't really realtime, so it wouldn't be suitable to tune Aeolus
on the fly anyway.
1:45 p.m.
On Fri, 2008-01-18 at 14:27 +0100, Fons Adriaensen wrote:
On Fri, Jan 18, 2008 at 02:07:26PM +0100, Albert Graef
wrote:
This is why Jack MIDI is being used by people despite the limitations.
Everyone /knows/ about them, they just don't care about huge sysex dumps
(etc) for what they're doing - namely realtime control (notes and CC and
such), what Jack MIDI was designed for.
I for one would love to see a Jack MIDI version (and doubt I'm alone),
Aeolus is great. Don't let these issues stop you if they don't
immediately matter, they'll get fixed eventually...
-DR-
Fons Adriaensen wrote:
The limits I referred to don't affect Aeolus, except that there's
no MIDI concept of 'stops' or anything near to it.
They affect anyone who wants to use sequencing tools and/or soft synths,
while not being limited by MIDI's 'culturally challenged' idea what music
is or could be.
Retuning Aeolus is very non-real-time operation anyway, and currently
Aeolus doesn't accept MTS. Seriously, there are three things that I
profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
Agreed. The MIDI Tuning Standard (MTS) was invented to fix that, but it
doesn't really help with the "12 notes per octave" limitation and, being
sysex, isn't really realtime, so it wouldn't be suitable to tune Aeolus
on the fly anyway.
9:38 a.m.
Fons Adriaensen wrote:
On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien
Claassen wrote:
If someone comes up with a decent 'event protocol' I'm volunteer to
implement it in jack, alongside the current jack-midi API (as an
experimental feature). From an implementations perspective it's a
no-brainer.
But can someone please tell me what to implement. And not in a vague
way. IMHO that's the real issue, and the 3 points you now mention are
only the first steps along that path. Please don't stop there. Take the
time to write a funded proposal that can be discussed, and then implemented.
Greets,
Pieter
Why can't those people who discussed it
here (Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API - as
it is - and try to work this new concept around it.
Well, the two you mention have a long history of not having radically
different views... :-)
Seriously, there are three things that I profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
2. Note events are identified by their frequency.
3. The only thing that can actually refer back to a note on event
is it's corresponding 'note off' message. It's not possible to
send a controller value that refers to a previous note-on event.
The worst result of all this, and what really drives me nuts is that
the same limits get built-in, carved in stone, into each and every
piece of sequencing software. They all perpetuate what is in fact
a form of cultural poverty "there's not quarter tones in pop music,
so they don't exist" while technically there is no more reason to
do so.
Midi-over-jack has missed the chance to fix 1) which would have
been relatively easy. And even 2) and 3) are not so difficult to
get rid of. 
1:37 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, 2008-01-18 at 14:38 +0100, Pieter Palmers wrote:
Fons Adriaensen wrote:
I know this has been hashed to death but I agree with Fons and his
"cultural poverty" remark. How true. We got lucky with Jack, most
probably we are not going to get lucky a second time but we could
try :-)
Is there anything inherently wrong with OSC as a _transport_ protocol?
Anything that makes it unsuitable for that purpose within the framework
of jack? (I know there have been threads about this before)
If not, implementing it within jack would be a good first step. It would
then be easy (just kidding[1]) for all of us to agree on some added
semantics that would emulate the functionality of midi on top of it (ie:
a set of predetermined messages with known semantics). No need to even
reinvent the wheel, start of with SKINI for example[2] :-)
-- Fernando
[1] after all, lv2 was a piece of cake to get out the door!
[2] http://ccrma.stanford.edu/software/stk/skini.html
On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien
Claassen wrote:
If someone comes up with a decent 'event protocol' I'm volunteer to
implement it in jack, alongside the current jack-midi API (as an
experimental feature). From an implementations perspective it's a
no-brainer.
But can someone please tell me what to implement. And not in a vague
way. IMHO that's the real issue, and the 3 points you now mention are
only the first steps along that path. Please don't stop there. Take the
time to write a funded proposal that can be discussed, and then implemented. Why can't those people who discussed it
here (Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API - as
it is - and try to work this new concept around it.
Well, the two you mention have a long history of not having radically
different views... :-)
Seriously, there are three things that I profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
2. Note events are identified by their frequency.
3. The only thing that can actually refer back to a note on event
is it's corresponding 'note off' message. It's not possible to
send a controller value that refers to a previous note-on event.
The worst result of all this, and what really drives me nuts is that
the same limits get built-in, carved in stone, into each and every
piece of sequencing software. They all perpetuate what is in fact
a form of cultural poverty "there's not quarter tones in pop music,
so they don't exist" while technically there is no more reason to
do so.
Midi-over-jack has missed the chance to fix 1) which would have
been relatively easy. And even 2) and 3) are not so difficult to
get rid of.
1:54 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, 2008-01-18 at 09:37 -0800, Fernando Lopez-Lezcano wrote:
On Fri, 2008-01-18 at 14:38 +0100, Pieter Palmers
wrote:
Is there anything inherently wrong with OSC as a _transport_ protocol?
Anything that makes it unsuitable for that purpose within the framework
of jack? (I know there have been threads about this before)
To transport OSC around in something like Jack, you can just use the
messages part of OSC and ignore the "transport" part of it (which is in
practise UDP and such, but if you read the spec you'll see this isn't
actually part of the OSC spec at all)*.
I do this successfully in LV2 in a virtually identical way to MIDI,
which is analogous to how it works in Jack.
A MIDI event and an OSC message are just a sequence of bytes at the end
of the day.
-DR-
(* P.S. Compatibility with networkey OSC stuff is elegantly possible,
but a long digression best ignored right now. Jack itself is just
concerned with messages.)
1:58 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, 2008-01-18 at 09:37 -0800, Fernando Lopez-Lezcano wrote:
Is there anything inherently wrong with OSC as a
_transport_ protocol?
Anything that makes it unsuitable for that purpose within the framework
of jack? (I know there have been threads about this before)
OSC is not a bus-oriented protocol, its 100% point-to-point. That is,
you do not put messages on a bus and all listeners pick it up. You have
to explicitly dispatch each OSC message to each target. this makes it
fundamentally different from MIDI, which, independent of the actual
physical transport layer, is bus oriented.
7:53 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, 2008-01-18 at 12:58 -0500, Paul Davis wrote:
On Fri, 2008-01-18 at 09:37 -0800, Fernando
Lopez-Lezcano wrote:
This is simply not true (I know who convinced you of this, because he
tried to convince me too, but I actually read the spec ;) )
There's no reason not to truck around OSC messages just like MIDI
messages, semantics are a separate issue (that is a "problem" with OSC
no matter how you transport it). That is, the problem you are
describing is just as present with OSC via UDP as via Jack.
Standard for messages (ie /note_on) are the solution to this, and are
also transport agnostic.
If you read the OSC specification, it very precisely defines exactly
what a message is as a sequence of bytes (ditto bundles). It also says
absolutely nothing about /requiring/ messages be sent around in packet
based addressed protocols like UDP (namely because this is silly, and
would violate the hell out of the network layer model).
The messages themselves are quite good as a generic message system.
Simple, flexible, has several types you can use as arguments (including
several floating point formats), and you can even easily extend it with
new types (which the main spec document does itself, only 4 are truly
"standard" OSC types).
When anyone talks about OSC in Jack, what they really mean is
transporting "OSC Messages" in Jack, and there's no problem with that.
-DR-
P.S. OSC messages are an awful lot like D-Bus messages, if anyone cares.
(/paths/like/this "with" 1.0 "whatever" 5 "arguments") is a
natural
message format, if we reinvented it (just because a particular developer
likes TCP/IP too much) we'd be reinventing the exact same thing except
by a different name, completely unknown, and slightly incompatible. I
hope it's obvious that this is.... less than wise
Is there anything inherently wrong with OSC as a
_transport_ protocol?
Anything that makes it unsuitable for that purpose within the framework
of jack? (I know there have been threads about this before)
OSC is not a bus-oriented protocol, its 100% point-to-point. That is,
you do not put messages on a bus and all listeners pick it up. You have
to explicitly dispatch each OSC message to each target. this makes it
fundamentally different from MIDI, which, independent of the actual
physical transport layer, is bus oriented.
19 Jan
19 Jan
2:11 a.m.
New subject: [Jack-Devel] JACK & MIDI
Paul Davis wrote:
OSC is not a bus-oriented protocol, its 100%
point-to-point. That is,
you do not put messages on a bus and all listeners pick it up.
Well, actually OSC uses a server/client model (at least the OSC apps I
know do). In any case, OSC clients just connect to servers, and that
server might well be Jack. OSC servers like SC3 would have to adapted,
though, that's true.
But first and foremost, OSC is just a way to cram data with attached
type information into a buffer, so, as Dave already pointed out, you can
just ignore the transport layer and provide your own API instead. Audio
applications also need to be Jack'ified to work with Jack after all...
What jack could maybe do, in addition to provide a transport mechanism
for both OSC and MIDI, is to allow connections between MIDI and OSC and
do the translation on the fly (using some set of MIDI-over-OSC
messages). That would be cool. Jack'ified apps could then just happily
use OSC as their control protocol and never worry about MIDI any more. I
don't know whether it's practical to add that functionality to Jack;
otherwise there could be a Jack client doing that kind of thing.
Also, implementing something like OSC in Jack would vastly expand its
scope. Want to process sensor data from your Gizmo ABC(TM) measuring
equipment or your brandnew "I Robot" Mark II vacuum cleaner? Sure, why
not, just write a Jack client which reads the data and translates it to
OSC, now you can pipe it into any Jack application, maybe via another
Jack client which does the necessary controller mapping. This might
sound like a pipedream now, but with cpu speeds always on the rise and
manycores in every PC soon the processing power will be there.
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
6:12 a.m.
New subject: [Jack-Devel] JACK & MIDI
Am Freitag, 18. Januar 2008 schrieb Paul Davis:
On Fri, 2008-01-18 at 09:37 -0800, Fernando
Lopez-Lezcano wrote:
Nope! (I have read the specs...)
The implementations make OSC a point-to-point protocol, because most
implementations use UDP (and maybe some use TCP) for the transport. But the
transport is actually _not_ part of the spec. The osc-spec only defines the
messages passed around. And they are typically "I send them without knowing
who receives them and what it does to them".
I think it would be pretty easy and very good if jack got extended to JACK-OSC
by providing ports to send and receive osc-messages similar to audio and
midi. I don't know about the internal of the jack-code, but probably the
message-passing of midi could be factored out to be used with any kind of
messages...
++osc_in_jack
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Is there anything inherently wrong with OSC as a
_transport_ protocol?
Anything that makes it unsuitable for that purpose within the framework
of jack? (I know there have been threads about this before)
OSC is not a
bus-oriented protocol, its 100% point-to-point. That is,
you do not put messages on a bus and all listeners pick it up. You have
to explicitly dispatch each OSC message to each target. this makes it
fundamentally different from MIDI, which, independent of the actual
physical transport layer, is bus oriented.
1:02 a.m.
New subject: [Jack-Devel] JACK & MIDI
Fernando Lopez-Lezcano wrote:
Is there anything inherently wrong with OSC as a
_transport_ protocol?
Anything that makes it unsuitable for that purpose within the framework
of jack? (I know there have been threads about this before)
I second that. Why invent yet another protocol when there's already a
kind of standard available? But, besides the lack of out-of-the-box
semantics, there's another potential issue with OSC, namely that OSC
packets can get arbitrarily large. That might be a problem with Jack. I
don't know enough about Jack's internals to assess the impacts of this,
but I imagine that a realtime-capable gc would be needed to deal with this.
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
18 Jan
18 Jan
1:44 p.m.
some of the things mentioned could be done by simply extending the
midi specification.
for example, if one needed a higher resolution for a note-on events velocity,
the event could be followed by a sysex data with one or two additional
7-bit values. (kind like it's already done with MSB and LSB for some
controller values)
sequencers, that supported the midi extension would provide a flag or logo:
midi OX (midi open extension)
a complete new definition would likely be more clean
but less supported, since midi is already build-in in hard/software
and could more easily be adjusted to send,receive and handle the
addition info.
afaict midi doesn't say anything about frequencies, you could map the
middle C nr 0x60 to any frequency you want
there's just no consensus/spec how to do it, how to handle it, how to
tell/inform other apps about it, etc...
20 Jan
20 Jan
5:26 a.m.
for example, if one needed a higher resolution for a
note-on events
velocity,
the event could be followed by a sysex data with one or two additional
7-bit values. (kind like it's already done with MSB and LSB for some
controller values)
one word: NRPN. thats what its there for.
;
--
Jay Vaughan
18 Jan
18 Jan
1:48 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, 2008-01-18 at 14:38 +0100, Pieter Palmers wrote:
If someone comes up with a decent 'event
protocol' I'm volunteer to
implement it in jack, alongside the current jack-midi API (as an
experimental feature). From an implementations perspective it's a
no-brainer.
But can someone please tell me what to implement. And not in a vague
way. IMHO that's the real issue, and the 3 points you now mention are
only the first steps along that path. Please don't stop there. Take the
time to write a funded proposal that can be discussed, and then implemented.
I don't think bloating Jack up with umpteen different event protocols is
a very good idea when they can all be transported with virtually
identical APIs.
An event in Jack is just a certain length of bytes with a timestamp
anyway, you /could/ theoretically just cram OSC messages into a Jack
MIDI port if the receiving app was expecting it... there's just no type
field in events, and the names of the functions in the API imply it's
MIDI specific (which it isn't, really)
-DR-
3:55 p.m.
New subject: [Jack-Devel] JACK & MIDI
Dave Robillard wrote:
On Fri, 2008-01-18 at 14:38 +0100, Pieter Palmers
wrote:
The similarity is why I indicate it at as a no-brainer btw. As fair as I
can see it comes down to introducing a type field in the event structure
and generalizing the current _midi_ functions to _event_ ones. And
providing _midi_ wrappers. That on itself would allow people to
experiment with whatever event they prefer, without interfering with
normal jack behavior.
It is also something that should be 'experimental' in the sense that it
would be there for the adventurous to fool around with and see what
happens, in order to gain experience for jack 2.0. Maybe that will help
to do it in a decent way from the start.
Greets,
Pieter
If someone comes up with a decent 'event
protocol' I'm volunteer to
implement it in jack, alongside the current jack-midi API (as an
experimental feature). From an implementations perspective it's a
no-brainer.
But can someone please tell me what to implement. And not in a vague
way. IMHO that's the real issue, and the 3 points you now mention are
only the first steps along that path. Please don't stop there. Take the
time to write a funded proposal that can be discussed, and then implemented.
I don't think bloating Jack up with umpteen different event protocols is
a very good idea when they can all be transported with virtually
identical APIs.
An event in Jack is just a certain length of bytes with a timestamp
anyway, you /could/ theoretically just cram OSC messages into a Jack
MIDI port if the receiving app was expecting it... there's just no type
field in events, and the names of the functions in the API imply it's
MIDI specific (which it isn't, really)
7:58 p.m.
New subject: [Jack-Devel] JACK & MIDI
On Fri, 2008-01-18 at 20:54 +0100, Pieter Palmers wrote:
Dave Robillard wrote:
It is indeed a no-brainer: no downside, and a heck of a lot of wins. I
was very disappointed when it was rejected the first time around :/
Nitpick:
I realized an oops on my part here. (Unlike LV2) Jack /events/
themselves don't need a type field, since a port would presumably only
transport events of one type. So all events can use the same
(conceptual) "struct" and API, the /port/ type would say what the type
of the events actually are.
Cheers,
-DR-
An event in Jack is just a certain length of
bytes with a timestamp
anyway, you /could/ theoretically just cram OSC messages into a Jack
MIDI port if the receiving app was expecting it... there's just no type
field in events, and the names of the functions in the API imply it's
MIDI specific (which it isn't, really)
The similarity is why I indicate it at as a no-brainer btw. As fair as I
can see it comes down to introducing a type field in the event structure
and generalizing the current _midi_ functions to _event_ ones. And
providing _midi_ wrappers. That on itself would allow people to
experiment with whatever event they prefer, without interfering with
normal jack behavior.
1:39 p.m.
On Fri, 2008-01-18 at 13:09 +0100, Fons Adriaensen wrote:
On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien
Claassen wrote:
Perhaps from time to time, like any people discussing/debating things..
this is not a schoolyard ;)
I mostly agree with Fons on this, just trying to make clear that this
discussion is about what MIDI may be like in a future Jack - the current
one is here to stay in Jack 1.
Why can't those people who discussed it
here (Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API - as
it is - and try to work this new concept around it.
Well, the two you mention have a long history of not having radically
different views... :-) Seriously, there are three things that I profoundly
dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
2. Note events are identified by their frequency.
3. The only thing that can actually refer back to a note on event
is it's corresponding 'note off' message. It's not possible to
send a controller value that refers to a previous note-on event.
I consider the contents of the actual events themselves to be a
completely orthogonal problem. Yes, MIDI sucks. It's almost as stupid
as not supporting MIDI at all. Almost. :)
The worst result of all this, and what really drives
me nuts is that
the same limits get built-in, carved in stone, into each and every
piece of sequencing software. They all perpetuate what is in fact
a form of cultural poverty "there's not quarter tones in pop music,
so they don't exist" while technically there is no more reason to
do so.
Fully agreed, but the solution isn't to try and define the Perfect MIDI
Replacement (we can't, and there's OSC which is pretty good and
widespread anyway) and grind it into Jack just like MIDI. Noone outside
of the extremely Jack focused niche community would want to use
JackEvents anyway.
Subframe accuracy and large messages (e.g. sysex) are problems that
would be nice to see resolved in Jack. People not liking MIDI itself
should simply be solved by not forcing MIDI (or anything else) at all.
Translation: the limitations of, and possible replacements for, MIDI
are well outside the scope of discussion of the Jack event system IMO.
-DR-
7:18 a.m.
On Thu, Jan 17, 2008 at 04:00:01PM -0500, Dave Robillard wrote:
If anyone is seriously considering throwing Jack MIDI
API out the
window, look at the LV2 event header here (just LV2_Event, ignoring the
type number mapping to URI bit):
I'm NOT proposing to throw it out, in fact my ramblings are
the result of sitting down with a glass of Italian wine and
considering what would be required to USE it in Aeolus.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
17 Jan
17 Jan
4:36 p.m.
On Wed, 2008-01-16 at 14:43 +0100, Fons Adriaensen wrote:
With the release of Jack 0.109 we now have a
(hopefully)
stable API for midi-over-jack. This set me to consider what
would be required to modify Aeolus to use this system.
And I did not like the conclusions.
Is it a good idea to insert a 30-year old data format
that mixes real-time and general data on a single stream
into a real-time audio processing API ? I don't think so.
1. Note on/off and controller events now can be 'sample
accurate'. That's nice to have. But
[...]
2. *All* MIDI data now has to pass through the
RT-audio
audio thread, even if it's not related to any RT operations
at all
[...]
So, after this long wait of things being different and incompatible in
SVN and a release /finally/ coming out, you NOW decide to bring all this
up?
Large SYSEX is a difficult problem that was deliberately not considered.
Sub-sample accurate stamps would be great though, and I bet they would
have gotten in too - but it's a little late for that now, isn't it?
-DR-
5948
days inactive
5952
days old
linux-audio-dev@lists.linuxaudio.org
33 comments
12 participants
participants (12)
-
Albert Graef -
Arnold Krille -
Christian Schoenebeck -
Dave Robillard -
Dmitry Baikov -
Emanuel Rumpf -
Fernando Lopez-Lezcano -
Fons Adriaensen -
Jay Vaughan -
Julien Claassen -
Paul Davis -
Pieter Palmers