3 Jan
2016
3 Jan
'16
3:24 a.m.
Some may remember, I tried a full-court press on MIDI over wifi about
eighteen months ago, using a couple of different methods; there were
occasional losses in realtime play, enough key-up commands lost that it
could not be used. So I gave it up for then and eventually found a
different use for my Rpi2.
But the prevalence of tablets as OSC+MIDI controllers, over wifi, has not
ceased to nag at me. I'm not interested in having a tablet -- my keyboard
is all I need -- but I am very interested in configuring an RPI2 or
equivalent in place of that tablet, so that I can wire keyboard to RPI2 and
then go wireless to the synth.
Now if I understand this Wikipedia article
<https://en.wikipedia.org/wiki/Open_Sound_Control> correctly, SLIP is
commonly used to encapsulate OSC signals. This could be a great clue,
because SLIP is very definitely a protocol which can give us verification
and recovery of lost signals, i.e., signals lost in the normal wifi
situation. And I have seen the Pure Data method of converting OSC to MIDI
and back, so that is not too much of a problem. The question I have is,
what would be the best method of verifying, configuring, and debugging SLIP
encapsulation? To do this well, for production on stage, I have not not
only be able to checkbox on for SLIP, but trigger warnings if it detects a
certain degree of errors.
Thoughts, anyone?
--
*Jonathan E. Brickman jeb(a)ponderworthy.com
<http://login.jsp/?at=02e47df3-a9af-4cd9-b951-1a06d255b48f&mailto=jeb@ponderworthy.com>
(785)233-9977*
*Hear us at http://ponderworthy.com <http://ponderworthy.com> -- CDs and
MP3s now available! <http://ponderworthy.com/ad-astra/ad-astra.html>*
*Music of compassion; fire, and life!!!*
3 Jan
3 Jan
4:21 a.m.
Jonathan Brickman:
Some may remember, I tried a full-court press on MIDI
over wifi about
eighteen months ago, using a couple of different methods; there were
occasional losses in realtime play, enough key-up commands lost that it
could not be used. So I gave it up for then and eventually found a
different use for my Rpi2.
For midi over a network have a look at
https://en.wikipedia.org/wiki/RTP_MIDI
https://code.google.com/p/midikit/
Now if I understand this Wikipedia article
<https://en.wikipedia.org/wiki/Open_Sound_Control> correctly, SLIP is
commonly used to encapsulate OSC signals.
According to the article, yes, but only over usb, and usb in this case
is used as a replacement for a rs232 serial line. Midi (over
midicables) uses the same framing as rs232, but it has its own idiotic
baudrate that complies with nothing else, perhaps so you cannot use
plain serial cables. So midi over usb is just old plain midi (with a
differnt baudrate and added framing) over a new medium which behaves
as if it were a rs232-connection.
Well, that is my guess anyhow.
This could be a great clue,
because SLIP is very definitely a protocol which can give us verification
and recovery of lost signals, i.e., signals lost in the normal wifi
situation.
No, SLIP takes the place of IP (as in TCP/IP), it only does routing
(where routing in this case is: to the other side of the cable).
Neither IP nor SLIP gives you any retransmission or guaranteed delivery,
you need TCP for that. As the article says, OSC uses UDP, which is a
minimal shim over IP. It just dumps the packet over to the other side
without any delivery check or retransmissions of lost packages.
And I have seen the Pure Data method of converting
OSC to MIDI
and back, so that is not too much of a problem. The question I have is,
what would be the best method of verifying, configuring, and debugging SLIP
encapsulation? To do this well, for production on stage, I have not not
only be able to checkbox on for SLIP, but trigger warnings if it detects a
certain degree of errors.
SLIP is defined in https://tools.ietf.org/html/rfc1055 and the first
paragraph under HISTORY is:
SLIP has its origins in the 3COM UNET TCP/IP implementation from the
early 1980's. It is merely a packet framing protocol: SLIP defines a
sequence of characters that frame IP packets on a serial line, and
nothing more. It provides no addressing, packet type identification,
error detection/correction or compression mechanisms. Because the
protocol does so little, though, it is usually very easy to
implement.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
6:14 a.m.
For midi over a network have a look at
https://en.wikipedia.org/wiki/RTP_MIDI
https://code.google.com/p/midikit/
......
Neither IP nor SLIP gives you any retransmission or guaranteed delivery,
you need TCP for that. As the article says, OSC uses UDP, which is a
minimal shim over IP. It just dumps the packet over to the other side
without any delivery check or retransmissions of lost packages.
OK. So how do we get retransmission and guaranteed delivery? Is there
a best approach? I might be able to set up Zmodem over TCP like we used
to for downloads on terminals: two Zmodems should do great for
guaranteed delivery (one upstream, one down), and Zmodem was known for
smoothness of the stream and connection recoverability. But I would
really want the two Zmodems-over-TCP to replace the UDP, not encapsulate
it, and Zmodem is such an old protocol that it might be extremely
wasteful on modern wifi.
Along the way tonight I found this:
http://mido.readthedocs.org/en/latest/socket_ports.html
which looks quite intriguing, had never seen that before, seems like
MIDI-over-TCP. But I want to use high speed as infrastructure to allow
for guaranteed delivery (the original MIDI spec is so extremely slow
that this should be a slam-dunk!), and I haven't found that as a design
feature in any code yet.
Thoughts, anyone?
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
8:25 a.m.
Just use one of the well established OSC libraries. Most of them support
OSC over TCP. I use liblo: https://github.com/radarsat1/liblo
Kind regards,
Felix
4 Jan
4 Jan
12:31 a.m.
On Sat, 2 Jan 2016, Jonathan E. Brickman wrote:
For midi over a network have a look at
https://en.wikipedia.org/wiki/RTP_MIDI
https://code.google.com/p/midikit/
RTP_midi is supposed to be standard and does (if fully
implemented) have error checking. The other standard is ipmidi (see
qmidinet) ipMIDI does not make sure of 100%... it would have to be
tunneled through tcp to get that. UDP tunneled through tcp on a local LAN
may be acceptable timing wise for your purposes, I don't know.
MIDI, unlike audio, must have 100% reliablility to be
useful. That reliablilty is first that all events must reach the other
side and second timing needs to be preserved. A small miss in timing while
anoying, is tolerable. A missing byte is not. One missing byte = either a
missing event or a malformed event that can change the meaning of that
event. (even from a note off to a note on)
Both RTP_midi and ipmidi sit on top of other IP protocols and are
therefore wifi compatible.
I am guessing ssh or telnet over wifi (if set to binary) may work just as
well too. I don't know if you need ssh or not. If you are willing to do a
bit of programming, making a jack client connected to a tcp server/client
should be easy enough though. I have not played with netjack and do not
know how reliable that is for MIDI. I have not had trouble with Xruns
though which would be the same thing.
--
Len Ovens
www.ovenwerks.net
1:27 a.m.
On 01/03/2016 05:30 PM, Len Ovens wrote:
On Sat, 2 Jan 2016, Jonathan E. Brickman wrote:
Len, thanks for the
rundown. I put a lot of effort into
ipmidi/qmidinet, and there was definite occasional loss which I could
not eliminate. Also tried both varieties of netjack; similar result. I
did not find any usable error correction therein. (Error detection is
irrelevant for this; error correction is priceless!) Latencies were very
nicely low, but indeed for instrument control any MIDI loss, even one
byte per minute, is unacceptable.
I am not certain that MIDI must have 100% reliability to be useful in
something like a tablet controller, as long as status feedback exists so
the operator knows that a signal has failed. But MIDI does have to have
100% reliability to be useful to drive a synth from a keyboard. And I
will think that for very high fidelity situations, audio transmission
does have to either have 100% reliability -- with retransmission or a
good enough setup that there simply is no audible loss -- or has to have
seriously good interpolative resampling capability to hide the losses.
According to at least one reference I found, the Ubuntu inclusions
"scenic" and "midistream" are said to be RTP-MIDI complete with
journaling, and it does sound to me like this is likely to be the
best-of-breed for remote instrument control over IP right now. I'll be
trying these next unless another option arises.
J.E.B.
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
For midi over a network have a look at
https://en.wikipedia.org/wiki/RTP_MIDI
https://code.google.com/p/midikit/
RTP_midi is supposed to be standard and does (if fully implemented)
have error checking. The other standard is ipmidi (see qmidinet)
ipMIDI does not make sure of 100%... it would have to be tunneled
through tcp to get that. UDP tunneled through tcp on a local LAN may
be acceptable timing wise for your purposes, I don't know.
MIDI, unlike audio, must have 100% reliablility to be useful. That
reliablilty is first that all events must reach the other side and
second timing needs to be preserved. A small miss in timing while
anoying, is tolerable. A missing byte is not. One missing byte =
either a missing event or a malformed event that can change the
meaning of that event. (even from a note off to a note on)
Both RTP_midi and ipmidi sit on top of other IP protocols and are
therefore wifi compatible.
I am guessing ssh or telnet over wifi (if set to binary) may work just
as well too. I don't know if you need ssh or not. If you are willing
to do a bit of programming, making a jack client connected to a tcp
server/client should be easy enough though. I have not played with
netjack and do not know how reliable that is for MIDI. I have not had
trouble with Xruns though which would be the same thing.
3:04 a.m.
On Sun, 3 Jan 2016, Jonathan E. Brickman wrote:
I am not certain that MIDI must have 100% reliability
to be useful in something
like a tablet controller, as long as status feedback exists so the operator knows
that a signal has failed. But MIDI does have to have 100% reliability to be
useful to drive a synth from a keyboard. And I will think that for very high
Even for a controller, it is quite important, maybe required. The only
place midi can be less than 100% is a string of changing values for one
controller where the next value is known to be coming or this is the last
event in a string and the change in value is very small.
fidelity situations, audio transmission does have to
either have 100% reliability
-- with retransmission or a good enough setup that there simply is no audible
loss -- or has to have seriously good interpolative resampling capability to hide
the losses.
In a performance situation, audio and high fidelity are not so important.
QOS still must be very high, but a missing sample is not like a missing
note off (or missing mute on a controller) where the effect can last till
manually corrected, possibly needing a panic reset.
According to at least one reference I found, the
Ubuntu inclusions "scenic" and
"midistream" are said to be RTP-MIDI complete with journaling, and it does
sound
to me like this is likely to be the best-of-breed for remote instrument control
over IP right now. I'll be trying these next unless another option arises.
Cool, Are they core audio compatible too? midistream does mention
journaling in the man page, scenic does not. Scenic is made to stream more
than MIDI too it seems... oh, it seems midistream is a part of scenic...
at least bugs point there. Not much work in there far a few years now
though. Could be a starting point for things though.
Some further looking says that midistream is no longer available as a
package. But:
"There is also the interesting scenic project that contains
Python based rtpmidi support (from which the now discontinued midistream
Debian package was derived). In the Scenic source tree the actual
midistream python application is here scenic/py/scripts/midistream.in, and
the associated library may be found here: scenic/py/rtpmidi"
http://www.humatic.de/htools/nmj/ is for android... maybe no help.
--
Len Ovens
www.ovenwerks.net
10:16 a.m.
On Sun, 3 Jan 2016 18:04:25 -0800 (PST), Len Ovens wrote:
Even for a controller, it is quite important, maybe
required. The only
place midi can be less than 100% is a string of changing values for
one controller where the next value is known to be coming or this is
the last event in a string and the change in value is very small.
I suspect that even this could lead to wrong results, if the byte/bites
that follows the missing byte/bites should make sense for the string.
Theoretical MIDI doesn't need to be 100% reliable for sysex data that
requires a checksum, but not all sysex data requires a checksum and
sometimes even a checksum doesn't correctly verify the data. I noticed
it, when I wrote an editor to manage DX7 sound banks in the 80s or 90s,
that even checksums sometimes could be "flexible".
In a performance situation, audio and high fidelity are
not so
important. QOS still must be very high, but a missing sample is not
like a missing note off (or missing mute on a controller) where the
effect can last till manually corrected, possibly needing a panic
reset.
For live usage active sensing and a panic button are very important ;),
especially if MIDI is used by a sequencer but one MIDI IO only. If
possible each MIDI channel should have it's individual IO ;). I'm not
talking about a thru box, I mean real IOs.
1:52 p.m.
Am 04.01.2016 um 00:30 schrieb Len Ovens:
MIDI, unlike audio, must have 100% reliablility to be
useful.
Despite all the theorizing about which network protocol works best for
MIDI, the TouchOSC appp for iOS/Android just sends MIDI messages as OSC
via UDP [1] and in practice, this works very well and reliable in my
home wifi network, even with encryption.
I use this without problems to control soft synths loaded into Carla via
my iPad using the the software touchosc2midi [2]. Works very well for
parameter control via control change messages, but the latency is even
low enough to be able to play notes on the tablet, if the timing doesn't
need to be too accurate. I haven't had any dropped messages yet.
I'm planing to give a demonstration of this setup at the next Open
Source Audio Meeting Cologne [3], if anbody wants proof that this works ;)
Chris
[1] It sends MIDI messages as an OSC packet with address pattern /midi
and data type 'm', i.e. 4 bytes, although it gets the order wrong, so
the receiving side has to take that into account. TouchOSC also has
limited support for sysex.
[2] https://github.com/SpotlightKid/touchosc2midi (This is my fork of
https://github.com/velolala/touchosc2midi and has a few important
improvements and fixes.)
[3] http://cologne.linuxaudio.org/
6:07 p.m.
On Mon, 4 Jan 2016, Christopher Arndt wrote:
Am 04.01.2016 um 00:30 schrieb Len Ovens:
I think (from what I have read of the OP setup) that this case has two
things that call for reliablility.
1) The MIDI stream is heavy. It includes the whole backing orchestration.
The use of a panic button would be very noticable. (maybe more so than the
hung note it was correcting)
2) The person controlling the playback is playing a sax over top of it and
therefore needs his hands to play that. That is he has no way of
monitoring and manually correcting things.
I can not see how adding OSC as yet another layer with no error checking
or correction could be any better than ipmidi.
rtpmidi with journaling looks to be the best bet on this because there is
no resend needed. The journaling info is sent if needed or not so there is
much less latency required for error correction. Journaling does not cover
all possibilities BTW, but it is very picky about note off events. In the
case of controllers the last value is journaled rather than the whole
string of values.
I think any of these protocols are event based so that
the likelyhood of partial events showing up is minimized. I am not sure
how sysex events longer than packet size are handled, but it would be
simple enough to add sequence numbering and not start forwarding a sysex
till the whole thing reaches the receiving end. So really it is only
performance data where one event completes another that is at issue.
--
Len Ovens
www.ovenwerks.net
MIDI, unlike audio, must have 100% reliablility
to be useful.
Despite all the theorizing about which network protocol works best for
MIDI, the TouchOSC appp for iOS/Android just sends MIDI messages as OSC
via UDP [1] and in practice, this works very well and reliable in my
home wifi network, even with encryption.
I use this without problems to control soft synths loaded into Carla via
my iPad using the the software touchosc2midi [2]. Works very well for
parameter control via control change messages, but the latency is even
low enough to be able to play notes on the tablet, if the timing doesn't
need to be too accurate. I haven't had any dropped messages yet. 
7:36 p.m.
On Mon, 4 Jan 2016 09:07:17 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
On Mon, 4 Jan 2016, Christopher Arndt wrote:
One of the things very much to our advantage is that the MIDI hardware runs at a
snails pace compared to all the likely communication systems. Even with
(usually not critical) single byte running status, that's an absolute maximum of
3kHz.
Some years ago I was involved in a networked project for a large industrial
plant that had similar speed differential and high reliability requirement
(24,358) our guys decided to go for fixed size checksummed packets, and the
network master would keep sending the same packet until either it got a valid
reply or the allotted time slot had expired. In that case the latter would
sound an alarm and attempt to set the faulty unit into a failsafe mode.
For a MIDI protocol I would imagine the failsafe would be for the receiving end
to apply an all notes off for just the non-responding channel, and for both
ends to attempt some form of silent comms reset.
I would agree with Len that sysex should only be acted upon once a fully
verified set of packets had been received.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Am 04.01.2016 um 00:30 schrieb Len Ovens:
I think (from what I have read of the OP setup) that this case has two
things that call for reliablility.
1) The MIDI stream is heavy. It includes the whole backing orchestration.
The use of a panic button would be very noticable. (maybe more so than the
hung note it was correcting)
2) The person controlling the playback is playing a sax over top of it and
therefore needs his hands to play that. That is he has no way of
monitoring and manually correcting things.
I can not see how adding OSC as yet another layer with no error checking
or correction could be any better than ipmidi.
rtpmidi with journaling looks to be the best bet on this because there is
no resend needed. The journaling info is sent if needed or not so there is
much less latency required for error correction. Journaling does not cover
all possibilities BTW, but it is very picky about note off events. In the
case of controllers the last value is journaled rather than the whole
string of values.
I think any of these protocols are event based so that
the likelyhood of partial events showing up is minimized. I am not sure
how sysex events longer than packet size are handled, but it would be
simple enough to add sequence numbering and not start forwarding a sysex
till the whole thing reaches the receiving end. So really it is only
performance data where one event completes another that is at issue.
--
Len Ovens
www.ovenwerks.net MIDI, unlike audio, must have 100% reliablility
to be useful.
Despite all the theorizing about which network protocol works best for
MIDI, the TouchOSC appp for iOS/Android just sends MIDI messages as OSC
via UDP [1] and in practice, this works very well and reliable in my
home wifi network, even with encryption.
I use this without problems to control soft synths loaded into Carla via
my iPad using the the software touchosc2midi [2]. Works very well for
parameter control via control change messages, but the latency is even
low enough to be able to play notes on the tablet, if the timing doesn't
need to be too accurate. I haven't had any dropped messages yet.
7:55 p.m.
I think (from what I have read of the OP setup) that
this case has two
things that call for reliablility.
1) The MIDI stream is heavy. It includes the whole backing
orchestration. The use of a panic button would be very noticable.
(maybe more so than the hung note it was correcting)
2) The person controlling the playback is playing a sax over top of it
and therefore needs his hands to play that. That is he has no way of
monitoring and manually correcting things.
I can not see how adding OSC as yet another layer with no error
checking or correction could be any better than ipmidi.
Agreed. A panic button,
for me (a multidevice keyboardist), is about as
useful as a power button. If my architecture needs a panic button, my
architecture isn't good enough for me.
rtpmidi with journaling looks to be the best bet on
this because there
is no resend needed. The journaling info is sent if needed or not so
there is much less latency required for error correction. Journaling
does not cover all possibilities BTW, but it is very picky about note
off events. In the case of controllers the last value is journaled
rather than the whole string of values.
Of all the current code bases in this
thread, which are all the ones I
have heard of thus far, indeed, rtpmidi with journaling does sound the
best to me. Anyone have, or know of a source of, the old midistream
source .deb for Ubuntu? It is reported as "no longer available", I
wonder if there was a patent / copyright issue or something.
But in truth, I don't want any risk of out-of-order, or missed, commands
in the stream. Delay is fine, only as a great indicator that I have to
abandon wireless and use my backup wired approach. If I'm spraying notes
around as fast as my fingers will go on my 88's for consecutive minutes,
nothing shall be out of order, or something has to get switched out.
Which, strangely enough, brings me right back to primordial methods.
After all, even audio and video streaming over a gigabit wired LAN
depends on caching if it's going to be hifi and truly flawless, TCP/UDP
was never designed to keep packets in original order.
I really do wonder. What about this for Linux-to-Linux MIDI:
- Processes on each end of the link connect to their respective MIDI
port devices via simple binary opens
- The processes set up two TCP connections over the LAN, two separate
TCP ports, one for each direction of data flow
- The processes set up two Zmodem connections, small block sizes, one
connection each direction, one per TCP port
Anyone know why this should not be maximally reliable and low-latency
too? We don't have to worry about any of the details of the data being
transmitted; Zmodem handles what history needs there are; either the
wifi rig is good enough or not.
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
8:15 p.m.
On Mon, January 4, 2016 12:55 pm, Jonathan E. Brickman wrote:
If my architecture needs a panic button, my
architecture isn't good enough for me.
...
But in truth, I don't want any risk of
out-of-order, or missed, commands
in the stream. Delay is fine, only as a great indicator that I have to
abandon wireless and use my backup wired approach.
If wired is physically possible at all, I don't understand why you are
considering WiFi if you actually need reliable real time communication.
Unless this is in an isolated building where you can completely control
the RF environment, you never know when someone is going to turn on
another WiFi device that temporarily disrupts communication, has a 2.4GHz
security camera that doesn't play well with WiFi, or even cooks something
in a microwave oven with a fraction of a percent leakage (e.g. someone
making popcorn in the green room). A typical microwave oven is around
1000 W, maximum allowed power in the 2.4GHz band in North America is 1 W,
but I have seen a lot of devices with lower than that as the maximum. It
doesn't take much leakage at all to equal the power output from a WiFi
device.
I used to have problems with the WiFi to my wife's laptop slowing greatly
if we were heating anything in the kitchen microwave. I can't conceive of
using something that fragile in a concert environment.
--
Chris Caudle
8:30 p.m.
On 01/04/2016 07:14 PM, Chris Caudle wrote:
On Mon, January 4, 2016 12:55 pm, Jonathan E. Brickman
wrote:
good grief someone raised the issue after all this time...
so you were having a uw oven (near|on) that studio of yours?
think again :)
http://www.howtogeek.com/171869/why-does-running-my-microwave-kill-my-wi-fi…
hth.
cheers
--
rncbc aka. Rui Nuno Capela
If my architecture needs a panic button, my
architecture isn't good enough for me.
...
But in truth, I don't want any risk of
out-of-order, or missed, commands
in the stream. Delay is fine, only as a great indicator that I have to
abandon wireless and use my backup wired approach.
If wired is physically possible at all, I don't understand why you are
considering WiFi if you actually need reliable real time communication.
Unless this is in an isolated building where you can completely control
the RF environment, you never know when someone is going to turn on
another WiFi device that temporarily disrupts communication, has a 2.4GHz
security camera that doesn't play well with WiFi, or even cooks something
in a microwave oven with a fraction of a percent leakage (e.g. someone
making popcorn in the green room). A typical microwave oven is around
1000 W, maximum allowed power in the 2.4GHz band in North America is 1 W,
but I have seen a lot of devices with lower than that as the maximum. It
doesn't take much leakage at all to equal the power output from a WiFi
device.
I used to have problems with the WiFi to my wife's laptop slowing greatly
if we were heating anything in the kitchen microwave. I can't conceive of
using something that fragile in a concert environment.
9:24 p.m.
On Mon, January 4, 2016 1:30 pm, Rui Nuno Capela wrote:
good grief someone raised the issue after all this
time...
I'm actually surprised that no one else has pointed out yet how fragile
WiFi is, or how non-suited for reliable stage use. Someone needed to.
so you were having a uw oven (near|on) that
studio of yours?
think again :)
Who said studio? I did point out that some of these concerns do not apply
if you control the building where you would be using WiFi, but if you look
back at Jonathon's original message from 23 December he specifically said
"for production on stage."
I take "stage" to mean a concert environment, possibly in a different
location every day, so different specific interference conditions every
day, and where you do not have the ability to control the entire
environment, such as whether someone in another band is cooking their food
in a microwave directly behind the stage, or whether half the audience has
the wifi hotspot of the phone turned on, or whether the venue has a lot of
wifi webcams streaming video at the same time, etc.
hth.
Helps me or helps Jonathon? I would never try to run my MIDI equipment
over WiFi during a concert, that's Jonathon's windmill to slay. ;)
--
Chris Caudle
10:33 p.m.
On 01/04/2016 08:23 PM, Chris Caudle wrote:
On Mon, January 4, 2016 1:30 pm, Rui Nuno Capela
wrote:
hope that helps every1 ;)
re. said studio
yes, might be yours truly qmidinet (or ipmidi) on the stake here...
now,
qmidinet/ipmidi never meant to be midi-over-the-air as far as for live,
uncajed (faraday-wise;)) open, public-address or whatever situation,
let's be certain... instead, it's always assumed an in-house flat or
home-studio situation, for x-sake :)
when in doubt, get it all wired over good old and trusty ethernet-- i
bet it might even go on par and even exceed old current-loop,
cabled-midi timing specs :P
hth2.
cheers
--
rncbc aka. Rui Nuno Capela
good grief someone raised the issue after all
this time...
I'm actually surprised that no one else has pointed out yet how fragile
WiFi is, or how non-suited for reliable stage use. Someone needed to.
so you were having a uw oven (near|on) that
studio of yours?
think again :)
Who said studio? I did point out that some of these concerns do not apply
if you control the building where you would be using WiFi, but if you look
back at Jonathon's original message from 23 December he specifically said
"for production on stage."
I take "stage" to mean a concert environment, possibly in a different
location every day, so different specific interference conditions every
day, and where you do not have the ability to control the entire
environment, such as whether someone in another band is cooking their food
in a microwave directly behind the stage, or whether half the audience has
the wifi hotspot of the phone turned on, or whether the venue has a lot of
wifi webcams streaming video at the same time, etc.
hth.
Helps me or helps Jonathon? I would never try to run my MIDI equipment
over WiFi during a concert, that's Jonathon's windmill to slay. ;)
5 Jan
5 Jan
1:42 a.m.
On Mon, 4 Jan 2016, Rui Nuno Capela wrote:
yes, might be yours truly qmidinet (or ipmidi) on the
stake here...
Any tool is designed for a purpose. None are really designed for low
latency over wifi.
qmidinet/ipmidi never meant to be midi-over-the-air as
far as for live,
uncajed (faraday-wise;)) open, public-address or whatever situation, let's be
certain... instead, it's always assumed an in-house flat or home-studio
situation, for x-sake :)
I am not sure RTPMidi is that much better in this situation, at least
latency wise. Probably better than TCP though.
when in doubt, get it all wired over good old and
trusty ethernet-- i bet it
might even go on par and even exceed old current-loop, cabled-midi timing
specs :P
Even on an old 10M line. It would not be hard to put two cards in each end
and set up failover too. I suppose two APs set to two channels could do
the same for wireless.
--
Len Ovens
www.ovenwerks.net
1:49 a.m.
On 01/04/2016 01:14 PM, Chris Caudle wrote:
I used to have problems with the WiFi to my wife's
laptop slowing
greatly if we were heating anything in the kitchen microwave. I can't
conceive of using something that fragile in a concert environment.
I'll have
to think that there are lots of factors; we used to have an
early 1980's microwave, huge and powerful, about six feet away from our
WAP and there was never a problem. Maybe the laptop's chipset was
sensitive in unusual ways, or something.
And I have to agree, 2.4GHz wifi is dangerous right now...but not really
with directional antennas, banks are still using 2.4GHz for ATMs across
quite a lot of space outdoors, with directionals. And there's always
5GHz...IR...UV...visible...:-)
The motivation for me is simple. I have worn out too many USB ports to
be happy about it!!! I have thought of trying to throw USB over three
1/4" phone jack cables (using the _extremely_ __durable traditional
Switchcraft hardware), but have thought that I would probably run into
impedance, isolation, or something else hidden in USB. I have also
spent quite a lot of time looking for adapter combos which would let me
use microUSB for the common detachments, but it seems that the parts
builders just haven't had me in mind.
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
2:49 a.m.
On Monday 04 January 2016 19:49:44 Jonathan E. Brickman wrote:
On 01/04/2016 01:14 PM, Chris Caudle wrote:
If your microwave interferes with the wifi. there is no way in hell it
will pass an rf leakage test. If the door is sprung a teeny bit, or
isn't closing because of cooked on spilled food, it can leak, a lot.
I am a retired television engineer, and one of the things we have to do
every 5 years is rent a Holiday (sp?) certified broadband leakage
measureing meter and survey all around our transmitters to show the FCC
that its safe for humans to work around. The field strength allowed is
equ to 10 milliwatts per cubic centimeter of flesh for continuous
exposure a 90MHz. That is actually quite strong, but in the range of
wifi or a microwave oven, both of which are adjacent in the 2.4 and 2.5
GHz bands ISTR its dropped to 1 milliwatt per cubic centimeter. Our
elderly GE transmitter on channel 5 passed, no problem.
The engineer at WOAY is where I sent the meter that we have to use, also
had to do his renewal. So when he unpacked it, checked the batteries and
turned it on, then walked into the lunch room for a warmer cup of
coffee, leaving it on the table 10+ feet from the microwave still turned
on. Putting the cup in the oven and setting it for one minute, as soon
as the magnetron reached operating temps, typically not more than 1
second, the alarm on the meter went off. Scrambling back to the table,
it was offscale and didn't come back to zero until the microwave timed
out & shut off. He looked at the door, and one hinge was bent so one
edge had a gap of about 5 sheets of copy paper width. Since it was a
vendors unit, you can guess where the next phone call was to, and he had
a brand new one an hour later, which was invisible to the meter.
Moral is, it doesn't take much to make one leak rf like a fire hose.
That was far enough down in the used calendar pile that we had no wifi,
else I expect we would have been alerted sooner. Now almost everyone is
using it, so we've all a built in to the house alarm when the wifi dies
when the coffee is cold and being warmed up.
I used to have problems with the WiFi to my
wife's laptop slowing
greatly if we were heating anything in the kitchen microwave. I
can't conceive of using something that fragile in a concert
environment.
I'll have to think that there are lots of factors; we used to have an
early 1980's microwave, huge and powerful, about six feet away from
our WAP and there was never a problem. Maybe the laptop's chipset was
sensitive in unusual ways, or something. And I have to agree, 2.4GHz wifi is dangerous right
now...but not
really with directional antennas, banks are still using 2.4GHz for
ATMs across quite a lot of space outdoors, with directionals. And
there's always 5GHz...IR...UV...visible...:-)
The motivation for me is simple. I have worn out too many USB ports
to be happy about it!!! I have thought of trying to throw USB over
three 1/4" phone jack cables (using the _extremely_ __durable
traditional Switchcraft hardware), but have thought that I would
probably run into impedance, isolation, or something else hidden in
USB. I have also spent quite a lot of time looking for adapter combos
which would let me use microUSB for the common detachments, but it
seems that the parts builders just haven't had me in mind.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
7 Jan
7 Jan
1:12 a.m.
On Mon, January 4, 2016 6:49 pm, Jonathan E. Brickman wrote:
The motivation for me is simple. I have worn out too
many USB ports to
be happy about it!!!
You're jumping through hoops to get WiFi to work because you want a
connector saver?
Wait, I thought this was about MIDI. Is it MIDI, or USB? Or MIDI data
which is being generated by a USB connected device?
Anyway, connector saver is what we called an adapter to be used in
situations where a connector was going to be mated much more than designed
for.
For example, say you are worried about wearing out the USB connector on
your laptop. You make a cable that connects to the laptop, with a USB A
female on the other end (extension cable, in other words). Make a way to
keep the cable attached permanently to the laptop (tricky since the
connector sticks out). Say for example the connector can tolerate 500
mating cycles, so previously you would wear out the laptop connector after
500 times of connecting and disconnecting your device. Now with the
extension mounted, the end of the extension wears out after 500 times, so
you get a new one, that is 2 mating cycles for the computer. After 500
more times of connecting and removing your device the cable wears out
again, so you change it, 3 cycles on the laptop. This way you can get
500*500=250 000 mating cycles before you wear out the connector on the
laptop.
Of course for a portable system it isn't quite so simple, since the
connector sticks out, so you can't really carry around something like a
permanently attached extension cable without risking breaking the
connector by bumping into something. The technique is more useful for
something fixed, say you have a computer on work bench in a repair shop
that you use to test out devices, so you are inserting and removing a lot
more than usual.
I don't remember if you said what was at each end of the wireless
connection. Will that be a computer running Linux at both ends, or only
at one end?
I didn't hear anyone mention it before, but the rtp-MIDI specification
says you can run over TCP, which should take care of most packet loss
issues, although the variable latency of WiFi would still make it not
recommended for real time use.
https://tools.ietf.org/html/rfc4695
The scenic tools mentioned earlier implement rtp-MIDI, but I don't have
any idea whether it supports all the options to allow you to pick that you
want TCP rather than UDP transport of the RTP packets.
--
Chris Caudle
4 Jan
4 Jan
9:19 p.m.
Jonathan Brickman:
...
Which, strangely enough, brings me right back to
primordial methods.
After all, even audio and video streaming over a gigabit wired LAN
depends on caching if it's going to be hifi and truly flawless, TCP/UDP
was never designed to keep packets in original order.
UDP is what you are talking about.
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
TCP provides reliable, ordered, and error-checked delivery
of a stream of octets between applications running on hosts
communicating over an IP network.
so TCP solves the in order reliable thing, but might give you jitter
and latency.
I really do wonder. What about this for
Linux-to-Linux MIDI:
- Processes on each end of the link connect to their respective MIDI
port devices via simple binary opens
- The processes set up two TCP connections over the LAN, two separate
TCP ports, one for each direction of data flow
- The processes set up two Zmodem connections, small block sizes, one
connection each direction, one per TCP port
Anyone know why this should not be maximally reliable and low-latency
too? We don't have to worry about any of the details of the data being
transmitted; Zmodem handles what history needs there are; either the
wifi rig is good enough or not.
Two processes, one at each end, just pushing a midi byte stream over a
TCP connection (socketpair) "should work", but you might need some kind
of session control. Everything you put in on one should get out on the
other side, barring something that makes the socketpair to go down.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
5 Jan
5 Jan
1:34 a.m.
On Mon, 4 Jan 2016, Jonathan E. Brickman wrote:
rtpmidi with journaling looks to be the best bet
on this because
there is no resend needed. The journaling info is sent if needed or
not so there is much less latency required for error correction.
Journaling does not cover all possibilities BTW, but it is very picky
about note off events. In the case of controllers the last value is
journaled rather than the whole string of values.
Of all the current code bases in this thread, which are all the ones I have heard
of thus far, indeed, rtpmidi with journaling does sound the best to me. Anyone
have, or know of a source of, the old midistream source .deb for Ubuntu? It is
reported as "no longer available", I wonder if there was a patent / copyright
issue or something.
midistreamer seems to have been a part of scenic that was pulled into a
separate package in debian. midistream is still a part of scenic and will
be built as part of that. That is building scenic will build midistream as
a separate file still. scenic seems to be the GUI that controls this. The
README does not indicate if it is possible to just build midistream on
it's own... (which you may have to do as gtk has moved on since the last
updates)
So I would try a git clone
https://code.sat.qc.ca/redmine/unsupported/scenic.git
./configure
make midistream
and see if it gets you there.
- Processes on each end of the link connect to their
respective MIDI port devices
via simple binary opens
- The processes set up two TCP connections over the LAN, two separate TCP ports,
one for each direction of data flow
- The processes set up two Zmodem connections, small block sizes, one connection
each direction, one per TCP port
If you use TCP it will give you right ordered no missing parts streaming,
no need for z/xmodem to do that. I would add a bit of code to make sure to
only use full events in any packet. Making it a jack client would do that
by default. (Even for sysex... it just won't handle very big sysex events
:)
Anyone know why this should not be maximally reliable
and low-latency too? We
don't have to worry about any of the details of the data being transmitted;
Zmodem handles what history needs there are; either the wifi rig is good enough
or not.
The lowlatency part is based on collisions, something most of us have
forgotten (younger ones may have never had any) in this age of switches.
Ethernet deals with collisions by both sending systems waiting a random
amount of time and trying again. WIFI does the same, but in crowded
airspace you have not only collisions between you and your AP (which you
can control) but also between you and (as mentioned) everyone else's AP
and cell phone and... whatever. That retry can end up being in seconds...
which is ok for streaming video with a big buffer and error correction
stuff that fakes it when things are missing. Not for stage.
WIFI does use some methods of dealing with more than one signal at a time
(frequency hopping etc.), but it is not really a low latency thing. But
you might get lucky sometimes in some venues.
Anyway, it sounds like a fun project. If my laptop was working right I
would play with it.
--
Len Ovens
www.ovenwerks.net
3 Jan
3 Jan
9:28 a.m.
On 03.01.2016 03:24, Jonathan Brickman wrote:
Some may remember, I tried a full-court press on MIDI
over wifi about
eighteen months ago, using a couple of different methods; there were
occasional losses in realtime play, enough key-up commands lost that it
could not be used. So I gave it up for then and eventually found a
different use for my Rpi2.
But the prevalence of tablets as OSC+MIDI controllers, over wifi, has
not ceased to nag at me. I'm not interested in having a tablet -- my
keyboard is all I need -- but I am very interested in configuring an
RPI2 or equivalent in place of that tablet, so that I can wire keyboard
to RPI2 and then go wireless to the synth.
Now if I understand this Wikipedia article
<https://en.wikipedia.org/wiki/Open_Sound_Control> correctly, SLIP is
commonly used to encapsulate OSC signals. This could be a great clue,
because SLIP is very definitely a protocol which can give us
verification and recovery of lost signals, i.e., signals lost in the
normal wifi situation. And I have seen the Pure Data method of
converting OSC to MIDI and back, so that is not too much of a problem.
The question I have is, what would be the best method of verifying,
configuring, and debugging SLIP encapsulation? To do this well, for
production on stage, I have not not only be able to checkbox on for
SLIP, but trigger warnings if it detects a certain degree of errors.
Thoughts, anyone?
As others have pointed out already, SLIP is merely used as a means of
framing packet data (e.g. IP, OSC) on 'unreliable' streams (e.g. serial
lines). Some clients (e.g. PureData) even use it for 'reliable' streams
(e.g. TCP).
First decision you have to take is if you want to go UDP or TCP. As you
want to do live input, TCP may be too slow on wireless because of
frequent retransmissions.
Depending on what you want to do, TCP may just be good enough. Thus
simply use any of the available OSC and network MIDI libraries
(RTP-MIDI, ipMIDI, ...) in TCP mode (if the library should support it).
If you need it to be more responsive, you want to use UDP. As you have
seen, UDP packets tend to get lost on wireless. The solution is to use a
means of transport insusceptible to lost packets.
For OSC, you can use TUIO1 [1] or TUIO2 [2]. They quite elegantly
circumvent the problem of lost packets by transmitting (almost) full
state information. There are numerous implementations out there [3].
[1] http://www.tuio.org/?specification
[2] http://www.tuio.org/?tuio20
[3] http://www.tuio.org/?software
For MIDI, use RTP-MIDI [4] with enabled journaling. The RTP-MIDI journal
enables clients to recover from lost packets (the journal contains
critical state information). I am not sure whether there is a readily
available implementation of RTP-MIDI journaling for GNU/Linux, though.
[4] https://tools.ietf.org/html/rfc4695
As a workaround, it may be fun to encode MIDI to TUIO at the sender and
decode it back at the receiver...
10:06 a.m.
Hanspeter Portner <dev(a)open-music-kontrollers.ch> schrieb am So., 3. Jan.
2016 um 09:28 Uhr:
As others have pointed out already, SLIP is merely
used as a means of
framing packet data (e.g. IP, OSC) on 'unreliable' streams (e.g. serial
lines). Some clients (e.g. PureData) even use it for 'reliable' streams
(e.g. TCP).
SLIP is mandatory for OSC over TCP in OSC protocol version 1.1. Hence, you
should use it when using OSC over TCP. IIRC it is optional in liblo.
12:21 p.m.
On 03.01.2016 10:06, Felix Homann wrote:
Hanspeter Portner <dev(a)open-music-kontrollers.ch
<mailto:dev@open-music-kontrollers.ch>> schrieb am So., 3. Jan. 2016 um
09:28 Uhr:
As others have pointed out already, SLIP is merely used as a means of
framing packet data (e.g. IP, OSC) on 'unreliable' streams (e.g. serial
lines). Some clients (e.g. PureData) even use it for 'reliable' streams
(e.g. TCP).
SLIP is mandatory for OSC over TCP in OSC protocol version 1.1. Hence,
you should use it when using OSC over TCP. IIRC it is optional in liblo.
Indeed, if you are in control of both server and client implementation,
you should very well do that.
I merley wanted to state that there are still different framing schemes
for OSC via streams (e.g. TCP) out there as of today. My wording was a
bit unlucky, I guess.
Let us put it this way:
If you need to talk to some existing OSC TCP server implementation you
are forced to use whatever framing scheme the server expects.
* SuperCollider expects size-prefixed OSC via TCP (OSC-1.0)
* PureData expects SLIP encoded OSC via TCP (OSC-1.1)
* Renoise (3.1) expects SLIP encoded OSC via TCP (OSC-1.1)
* Renoise (<3.1) expects raw OSC via TCP, with no framing at all ;-)
12:41 p.m.
Hanspeter Portner <dev(a)open-music-kontrollers.ch> schrieb am So., 3. Jan.
2016 um 12:21 Uhr:
If you need to talk to some existing OSC TCP server implementation you
are forced to use whatever framing scheme the server expects.
Yes, sure.
* SuperCollider expects size-prefixed OSC via TCP (OSC-1.0)
* PureData expects SLIP encoded OSC via TCP (OSC-1.1)
* Renoise (3.1) expects SLIP encoded OSC via TCP (OSC-1.1)
* Renoise (<3.1) expects raw OSC via TCP, with no framing at all ;-)
So I guess it's time for SuperCollider to adopt the new standard ;-)
3:34 p.m.
As others have pointed out already, SLIP is merely
used as a means of
framing packet data (e.g. IP, OSC) on 'unreliable' streams (e.g. serial
lines). Some clients (e.g. PureData) even use it for 'reliable' streams
(e.g. TCP).
Got it. SLIP frames the data, but does not do retransmission.
First decision you have to take is if you want to go
UDP or TCP. As you
want to do live input, TCP may be too slow on wireless because of
frequent retransmissions.
Depending on what you want to do, TCP may just be good enough. Thus
simply use any of the available OSC and network MIDI libraries
(RTP-MIDI, ipMIDI, ...) in TCP mode (if the library should support it).
Why,
exactly, is existing MIDI/OSC-over-TCP due to retransmissions?
We're talking about a 31.5 kHz real data stream, why is that necessarily
slow in response when encapsulated in a wireless connection whose speeds
start in the megabit range? Is timeout detection really that long? It
is sounding like we need a much shorter timeout for this, something a
lot more like DNS-over-TCP?
If you need it to be more responsive, you want to use
UDP. As you have
seen, UDP packets tend to get lost on wireless. The solution is to use a
means of transport insusceptible to lost packets.
For OSC, you can use TUIO1 [1] or TUIO2 [2]. They quite elegantly
circumvent the problem of lost packets by transmitting (almost) full
state information. There are numerous implementations out there [3].
[1] http://www.tuio.org/?specification
[2] http://www.tuio.org/?tuio20
[3] http://www.tuio.org/?software
For MIDI, use RTP-MIDI [4] with enabled journaling. The RTP-MIDI journal
enables clients to recover from lost packets (the journal contains
critical state information). I am not sure whether there is a readily
available implementation of RTP-MIDI journaling for GNU/Linux, though.
[4] https://tools.ietf.org/html/rfc4695
As a workaround, it may be fun to encode MIDI to TUIO at the sender and
decode it back at the receiver...
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Will be studying, thanks!
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
4 Jan
4 Jan
12:17 a.m.
Tracing several rabbit-trails, I landed on these:
http://manpages.ubuntu.com/manpages/precise/man1/scenic.1.html
http://manpages.ubuntu.com/manpages/precise/man1/midistream.1.html
Looks like they are working on the ALSA level, MIDI and audio. Anyone
have experiences?
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
3277
days inactive
3281
days old
linux-audio-user@lists.linuxaudio.org
27 comments
12 participants
participants (12)
-
Chris Caudle -
Christopher Arndt -
Felix Homann -
Gene Heskett -
Hanspeter Portner -
Jonathan Brickman -
Jonathan E. Brickman
-
karl＠aspodata.se -
Len Ovens -
Ralf Mardorf -
Rui Nuno Capela -
Will Godfrey