22 Jul
2006
22 Jul
'06
3:40 p.m.
Dave Robillard <drobilla(a)connect.carleton.ca>
wrote:
OSC can go over TCP to avoid the packet loss issue (and messed up
ordering which can be extremely annoying as well). liblo's TCP
support
needs some work though.
This comment illustrates an advantage for using RTP MIDI
to send MIDI over lossy networks. The recovery journal in
RTP MIDI supports graceful recovery from the loss of an arbitrary
number of packets upon the receipt of the first packet after the
loss (also works for reordering). Journalling is a feed-forward
process,
no retransmission is used -- thus, no head-of-line-blocking latency
issues as one has when running media over TCP.
See:
http://www.cs.berkeley.edu/~lazzaro/rtpmidi/index.html
The IESG approved RTP MIDI in February, so the protocol is
frozen. Hopefully the copy-edit phase will be done by autumn
and then we'll have RFC numbers for RTP MIDI.
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
22 Jul
22 Jul
11:53 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On 7/23/06, lazzaro <lazzaro(a)eecs.berkeley.edu> wrote:
Yay! i want my whole app to communicate between engine and gui via
midi! That's going to really be interesting... So what CC would i use
for add a new node named "node"? Sysex i guess? ....
Loki
Dave Robillard
<drobilla(a)connect.carleton.ca> wrote:
OSC can go over TCP to avoid the packet loss issue (and messed up
ordering which can be extremely annoying as well). liblo's TCP
support
needs some work though.
This comment illustrates an advantage for using RTP MIDI
to send MIDI over lossy networks. The recovery journal in
RTP MIDI supports graceful recovery from the loss of an arbitrary
number of packets upon the receipt of the first packet after the
loss (also works for reordering). Journalling is a feed-forward
process,
no retransmission is used -- thus, no head-of-line-blocking latency
issues as one has when running media over TCP.
See:
http://www.cs.berkeley.edu/~lazzaro/rtpmidi/index.html
The IESG approved RTP MIDI in February, so the protocol is
frozen. Hopefully the copy-edit phase will be done by autumn
and then we'll have RFC numbers for RTP MIDI.
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
--- 
23 Jul
23 Jul
6:58 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Sun, 2006-07-23 at 11:52 +1000, Loki Davison wrote:
Yay! i want my whole app to communicate between engine
and gui via
midi! That's going to really be interesting... So what CC would i use
for add a new node named "node"? Sysex i guess? ....
CC 0x06 (Data Entry) would be a good candidate for entering text,
possibly with 0x96, 0x97 (data increment, decrement) to be used as a
cursor.
The backend will "know" that you are setting the text field of a node
because you immediately before have send a Non-Registered Pararameter
Number (CC 0x98 MSB, 0x99 LSB), setting the mode or destination to
whatever you have found reasonable to represent "node-name".
Problems: Attempts at midi-merge may fail. The data-entry slider cannot
be connected to two separate destinations simultaniously in any
meaningful way, other than that the last connection wins and all of the
data goes there.
Loki
--
7:36 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On 7/23/06, Jens M Andreasen <jens.andreasen(a)chello.se> wrote:
On Sun, 2006-07-23 at 11:52 +1000, Loki Davison
wrote:
minor downside is that it sounds horrible and complicated and like
you've escaped to the 80's. Yay back to the future... You just can't
say in midi "set the sine osc to 440 hz." I.e you can say in your
message that you are setting a oscillator called something. You can in
osc, so much more human readable.
Loki
Yay! i want my whole app to communicate between
engine and gui via
midi! That's going to really be interesting... So what CC would i use
for add a new node named "node"? Sysex i guess? ....
CC 0x06 (Data Entry) would be a good candidate for entering text,
possibly with 0x96, 0x97 (data increment, decrement) to be used as a
cursor.
The backend will "know" that you are setting the text field of a node
because you immediately before have send a Non-Registered Pararameter
Number (CC 0x98 MSB, 0x99 LSB), setting the mode or destination to
whatever you have found reasonable to represent "node-name".
Problems: Attempts at midi-merge may fail. The data-entry slider cannot
be connected to two separate destinations simultaniously in any
meaningful way, other than that the last connection wins and all of the
data goes there.
Loki
--
9:41 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Sun, 2006-07-23 at 19:36 +1000, Loki Davison wrote:
On 7/23/06, Jens M Andreasen
<jens.andreasen(a)chello.se> wrote:
The implementation could be a switch on the current NRPN. Nothing
complicated or unusual here. Or with a bit of carefulness, you could
also do an array of dynamically allocated function pointers
The upside is that we can actually have (and I do have) a physical
rotary knob that sets an oscillator to, say 440Hz. As for human
readability of the message, I couldn't care less since I am not going
to read the datastream aloud to myself anyway.
To get text representations of unique NPRN's for readability in your
sources, you would typically use something like:
-- myNRPN.h ---------------
#define NODE_NAME __LINE__
#define OSC_FREQ __LINE__
... which is of course an old-fashioned technique known since the
beginning of the UNIX epoch. But it still works as intended.
On Sun, 2006-07-23 at 11:52 +1000, Loki Davison
wrote:
minor downside is that it sounds horrible and complicated and like
you've escaped to the 80's. Yay back to the future... You just can't
say in midi "set the sine osc to 440 hz." I.e you can say in your
message that you are setting a oscillator called something. You can in
osc, so much more human readable.
Yay! i want my whole app to communicate between
engine and gui via
midi! That's going to really be interesting... So what CC would i use
for add a new node named "node"? Sysex i guess? ....
CC 06 (Data Entry) would be a good candidate for entering text,
possibly with 96, 97 (data increment, decrement) to be used as a
cursor.
The backend will "know" that you are setting the text field of a node
because you immediately before have send a Non-Registered Pararameter
Number (CC 98 MSB, 99 LSB), setting the mode or destination to
whatever you have found reasonable to represent "node-name".
Problems: Attempts at midi-merge may fail. The data-entry slider cannot
be connected to two separate destinations simultaniously in any
meaningful way, other than that the last connection wins and all of the
data goes there.
Loki
-- Loki
--
7:06 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Sun, 2006-07-23 at 13:41 +0200, Jens M Andreasen wrote:
On Sun, 2006-07-23 at 19:36 +1000, Loki Davison
wrote:
... Now I know what the topic of my next nightmare is going to be :)
-DR-
On 7/23/06, Jens M Andreasen
<jens.andreasen(a)chello.se> wrote:
The implementation could be a switch on the current NRPN. Nothing
complicated or unusual here. Or with a bit of carefulness, you could
also do an array of dynamically allocated function pointers
The upside is that we can actually have (and I do have) a physical
rotary knob that sets an oscillator to, say 440Hz. As for human
readability of the message, I couldn't care less since I am not going
to read the datastream aloud to myself anyway.
To get text representations of unique NPRN's for readability in your
sources, you would typically use something like:
-- myNRPN.h ---------------
#define NODE_NAME __LINE__
#define OSC_FREQ __LINE__ On Sun, 2006-07-23 at 11:52 +1000, Loki Davison
wrote:
minor downside is that it sounds horrible and complicated and like
you've escaped to the 80's. Yay back to the future... You just can't
say in midi "set the sine osc to 440 hz." I.e you can say in your
message that you are setting a oscillator called something. You can in
osc, so much more human readable.
Yay! i want my whole app to communicate between
engine and gui via
midi! That's going to really be interesting... So what CC would i use
for add a new node named "node"? Sysex i guess? ....
CC 06 (Data Entry) would be a good candidate for entering text,
possibly with 96, 97 (data increment, decrement) to be used as a
cursor.
The backend will "know" that you are setting the text field of a node
because you immediately before have send a Non-Registered Pararameter
Number (CC 98 MSB, 99 LSB), setting the mode or destination to
whatever you have found reasonable to represent "node-name".
Problems: Attempts at midi-merge may fail. The data-entry slider cannot
be connected to two separate destinations simultaniously in any
meaningful way, other than that the last connection wins and all of the
data goes there.
Loki
--
9:14 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On 7/24/06, Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
On Sun, 2006-07-23 at 13:41 +0200, Jens M Andreasen
wrote:
The implementation could be a switch on the current NRPN. Nothing
complicated or unusual here. Or with a bit of carefulness, you could
also do an array of dynamically allocated function pointers
The upside is that we can actually have (and I do have) a physical
rotary knob that sets an oscillator to, say 440Hz. As for human
readability of the message, I couldn't care less since I am not going
to read the datastream aloud to myself anyway.
To get text representations of unique NPRN's for readability in your
sources, you would typically use something like:
-- myNRPN.h ---------------
#define NODE_NAME __LINE__
#define OSC_FREQ __LINE__
... Now I know what the topic of my next nightmare is going to be :)
-DR-
same... i know deep down Jens you are actually an intelligent guy from
your other posts, but you really must think in a very different way to
me. This looks really, really horrible compared to osc and
fantastically inflexible. Especially for the original goal of this
thread, engine and gui process separation... communicating between
engine and gui in midi just doesn't seem nice...
Loki
On Sun, 2006-07-23 at 19:36 +1000, Loki Davison
wrote:
> On 7/23/06, Jens M Andreasen <jens.andreasen(a)chello.se> wrote:
> > On Sun, 2006-07-23 at 11:52 +1000, Loki Davison wrote:
> >
> > > Yay! i want my whole app to communicate between engine and gui via
> > > midi! That's going to really be interesting... So what CC would i
use
> > > for add a new node named
"node"? Sysex i guess? ....
> >
> > CC 06 (Data Entry) would be a good candidate for entering text,
> > possibly with 96, 97 (data increment, decrement) to be used as a
> > cursor.
> >
> > The backend will "know" that you are setting the text field of a
node
> > because you immediately before have send a Non-Registered Pararameter
> > Number (CC 98 MSB, 99 LSB), setting the mode or destination to
> > whatever you have found reasonable to represent "node-name".
> >
> > Problems: Attempts at midi-merge may fail. The data-entry slider
cannot
> > be connected to two separate
destinations simultaniously in any
> > meaningful way, other than that the last connection wins and all of
the
data goes there.
> Loki
--
minor downside is that it sounds horrible and complicated and like
you've escaped to the 80's. Yay back to the future... You just can't
say in midi "set the sine osc to 440 hz." I.e you can say in your
message that you are setting a oscillator called something. You can in
osc, so much more human readable.
9:39 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
same... i know deep down Jens you are actually an
intelligent guy from
your other posts, but you really must think in a very different way to
me. This looks really, really horrible compared to osc and
fantastically inflexible.
i thought this Port Nodes inside Sysex inside MIDI inside RTP-MIDI over TCP was a
sarcastic joke. i guess everyone reads the same text differently :)
11:44 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Mon, 2006-07-24 at 09:14 +1000, Loki Davison wrote:
The thing here is that I prefer to use external knobs rather than
widgets on a screen. The only way to communicate in a way that works
across boundaries is midi.
As for flexibility. If we stick to the NRPN's for a moment, we could
think of them as a huge switch-board with 127*127 destinations (msb*lsb)
each capable of holding a 14bit value. Their meaning is what we want or
need them to be. To me this seems like a flexible enough starting point.
As for applying meaning to bit-patterns, that would depend on the
application. My own variables comes in multiples of 8 or 4 so that helps
in remembering what and where they are.
... Now I know
what the topic of my next nightmare is going to be :)
-DR-
same... i know deep down Jens you are actually an intelligent guy from
your other posts, but you really must think in a very different way to
me. This looks really, really horrible compared to osc and
fantastically inflexible. Especially for the original goal of this
thread, engine and gui process separation... communicating between
engine and gui in midi just doesn't seem nice...
Loki
--
24 Jul
24 Jul
12:43 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
As for flexibility. If we stick to the NRPN's for
a moment, we could
think of them as a huge switch-board with 127*127 destinations (msb*lsb)
each capable of holding a 14bit value. Their meaning is what we want or
need them to be. To me this seems like a flexible enough starting point.
As for applying meaning to bit-patterns, that would depend on the
application. My own variables comes in multiples of 8 or 4 so that helps
in remembering what and where they are.
I assume that RTP MIDI could be wrapped in a nice library that makes working
with it a lot more pleasant? Couldn't someone implement a protocol over RTP
MIDI sysex/NRPN/something that feels something like OSC at the code level? Or
would that just not be very useful?
-Forest
4:11 p.m.
On Mon, 2006-07-24 at 10:41 -0400, Forest Bond wrote:
Extending MIDI's domain past what it is currently used for is just
fundamentally the Wrong Thing - the need for such a library is basically
proof of that.
(I'm not saying RTP MIDI is bad at all, but it's not the solution to
every problem out there)
-DR-
As for
flexibility. If we stick to the NRPN's for a moment, we could
think of them as a huge switch-board with 127*127 destinations (msb*lsb)
each capable of holding a 14bit value. Their meaning is what we want or
need them to be. To me this seems like a flexible enough starting point.
As for applying meaning to bit-patterns, that would depend on the
application. My own variables comes in multiples of 8 or 4 so that helps
in remembering what and where they are.
I assume that RTP MIDI could be wrapped in a nice library that makes working
with it a lot more pleasant? Couldn't someone implement a protocol over RTP
MIDI sysex/NRPN/something that feels something like OSC at the code level? Or
would that just not be very useful?
23 Jul
23 Jul
1:15 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Sat, 2006-07-22 at 10:40 -0700, lazzaro wrote:
Sure, for MIDI. MIDI has a lot of built-in semantics you can use to
accomplish things like this, but OSC doesn't. As Loki pointed out, MIDI
is no OSC (eg it sucks) :)
You could do it on a per-app basis (since you actually know something
about the information being transmitted), but a parallel to RTP MIDI
can't really be done for OSC (TCP isn't the only solution though, it
just happens to be what's around and obvious to use. You can wrap OSC
in pretty much anything (and still be totally conformant))
I don't see it as much of a problem anyway. At least in all my use
cases, there's realtime crucial data (eg what MIDI tends to do,
controllers, notes, etc) and there's data that just needs to get there
sanely. The nice thing about the realtime stuff is that lost messages
don't really matter, all you care about is the most recent one anyway.
I need to do a bit of work on liblo to get TCP working better, but I'm
just going to use UDP for the former (realtime) and TCP for the latter
(reliable).
(On the local machine there's more fun possibilities like a POSIX
message queue backend for liblo or similar, but that's an aside I'm just
curious about at the moment)
-DR-
Dave Robillard
<drobilla(a)connect.carleton.ca> wrote:
OSC can go over TCP to avoid the packet loss issue (and messed up
ordering which can be extremely annoying as well). liblo's TCP
support
needs some work though.
This comment illustrates an advantage for using RTP MIDI
to send MIDI over lossy networks. The recovery journal in
RTP MIDI supports graceful recovery from the loss of an arbitrary
number of packets upon the receipt of the first packet after the
loss (also works for reordering). Journalling is a feed-forward
process,
no retransmission is used -- thus, no head-of-line-blocking latency
issues as one has when running media over TCP. 
6725
days inactive
6727
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
7 participants
participants (7)
-
carmen -
Dave Robillard -
Forest Bond -
Jens M Andreasen -
lazzaro -
Loki Davison -
Thomas Vecchione