Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
On Wed, 29 Aug 2018 13:00:07 -0700 (PDT), Len Ovens wrote: >MIDI was designed to handle in realtime (10 events from 10 fingers) PS: Even if we reduce MIDI to one channel for real-time playing without usage of e.g. the nose as an eleventh finger, at least usage of pedals is included. The amount of data send by just one pedal easily exceeds what a human could do with ten fingers on black and white keys. A keyboarder could use one hand to control a joystick (e.g. pitch bend and modulation at the same time) and two feet to control two pedals and at the same time use 5 fingers to play black and white keys with after touch. The MIDI standard allows to do this. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
On Wed, 29 Aug 2018 13:00:07 -0700 (PDT), Len Ovens wrote: >MIDI was designed to handle in realtime (10 events from 10 fingers) That is incorrect, MIDI was designed for sequencer usage, too, so MIDI provides 16 channels ;). While I only can play 6 channels in real-time using my guitar synth, even my C64 and Atari ST could play 16 channels and more (btw. with way less MIDI jitter than any Linux PC can do). Depending on the usage, we can _not_ use one MIDI connection (one MIDI cable) for all 16 channels, but sometimes it works, let alone that from the beginning MIDI also was desgined for usage with several MIDI IOs, IOW for usage with x * 16 channels. Btw. regarding some data, e.g. pitch bend messages, not only my guitar synth allows to send "reduced" MIDI data. From keyboards we e.g. know that after touch often isn't used, but send. MIDI sometimes require thinking about the setup, to avoid issues, this is even true for an anlog audio setup or synth connected by a CV/gate "network". MIDI still requires to think about what we want to achieve. The MIDI standard isn't made to fit the needs of braindead consumers. If we think a little bit, we even could use SysEx non-real-time MIDI data in real-time, without experiencing any problem. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
On Sat, 01 Sep 2018 16:49:48 -0500, Jonathan E. Brickman wrote: >to sidestep all of the well-known MIDI limitations Without doubts MIDI has got well-known limitations, but nowadays a bad implementation of the MIDI standard often gets confused with the MIDI standard, so it's better to clearly point out a limitation instead of overgeneralizeing the issues. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
[Active Sensing] You said that you "need lossless JACK MIDI networking", but not why you need networking at all. You might have a good reason, I'm just curious. For what purpose do you need an _additional_ network? Btw. I have no experiences with MIDI over an additional network, but regarding the missing note-off issue, a standard MIDI "network" (= MIDI not over an additional network) has got the "Active Sense" (0xFE) message, that could workaround some (not all) missing note-off issues. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
On Sat, Sep 1, 2018 at 10:07 PM, Len Ovens wrote: [ etc. etc. etc. ] i wonder if sctp (the transport protocol used for web sockets) might be better for this sort of thing than either tcp or udp or raw ip ... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
On Sat, 1 Sep 2018, Jonathan E. Brickman wrote: In general I too am attracted to UDP -- but for MIDI performance transmission, 0.001% loss is still far too much, because that means one note in 1,000 might be held and never released, causing massive encruditation to the moment :-) This is because every time I press a key there's a MIDI signal for the press, and a separate one for the release, and if the release is lost, we can have massive unpleasantry. And a song can easily have thousands of notes. Some of my tests over the years actually included this behavior! All note offs must be received for good performance. I agree. I have read a lot about OSC. It has seemed to me that it would have to be an option, given that it seems to have been designed from the beginning to run over IP, and otherwise to sidestep all of the well-known MIDI limitations. But whenever I have dug into it in the past, I have found myself quite profoundly confused by the massive flexibility. Recently I ran into OSC2MIDI, and if my OSC has no "standard" for performance transmition except MIDI via OSC which ends up having all the same problems as MIDI alone. It would of course be possible to send messages that were note with length... but that would mean a delay at least as long as the note was played because the message can not be sent untill note off. understanding of what OSC is is correct, OSC2MIDI should theoretically be able to do the job if it is on both ends of the stream, correct? I'll do a bit of testing of this, see if I can figure out a bit of toolchain design, but input of experienced persons is much desired. I personally don't see how that would help. It sounds like translating an english email to french to send it and then translating back to english on the receiving end. It is UDP in both cases. Unless I am missing something. I will also look at the repos for MIDI over RTP. Sounds like it's being used in production now for loss-tolerant control surfaces though, and not performance transmission, correct? It is designed for performance as well or even first. It is a journelled setup that sends both the performance and a journel. The journel allows missing packets to be noted and replaced. It tries to be smart about what it recreates. For example, a note off is always recreated even if it ends up late. A note on that shows up after it's note off will not. So it is the better than tcp, where a note may sound obviously out of time due to a retry. rtpmidi is what apple coreaudio uses as it's midi transport. A properly "advertised" rtmidi port will show up in core audio just like any other midi port. It is however, true that some of the linux implementations have gotten it working but have never completed the journeling part of things (maybe because it worked for them well enough without) and so for them it is no better than ipmidi (which also tends to be quite good in a local network context). The transport part of the code is the easiest and the journel part would take work... at least that is my guess as the reason so many are partly done. Tcp with timing information and post analysis could do the same thing, deciding not to use late note on events. With the speed of networks inceasing and faster processing at both ends, tcp may be fast enough. A lot depends on how busy the network is... what other traffic is present. I have had both good and bad exeriences with udp both on wifi and localhost. Even using localhost, it seems too many udp packets at a time seems to result in packet loss. (I say packet loss, but it is possible the receiving OSC lib ran out of buffer too). -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
In general I too am attracted to UDP -- but for MIDI performance transmission, 0.001% loss is still far too much, because that means one note in 1,000 might be held and never released, causing massive encruditation to the moment :-) This is because every time I press a key there's a MIDI signal for the press, and a separate one for the release, and if the release is lost, we can have massive unpleasantry. And a song can easily have thousands of notes. Some of my tests over the years actually included this behavior! So it's either TCP only, or it's UDP with complete error correction. UDP with complete error correction is how NFS over UDP has been working for ages, so that is clearly an option, but it is also not exactly trivial programmatically :-) I have read a lot about OSC. It has seemed to me that it would have to be an option, given that it seems to have been designed from the beginning to run over IP, and otherwise to sidestep all of the well- known MIDI limitations. But whenever I have dug into it in the past, I have found myself quite profoundly confused by the massive flexibility. Recently I ran into OSC2MIDI, and if my understanding of what OSC is is correct, OSC2MIDI should theoretically be able to do the job if it is on both ends of the stream, correct? I'll do a bit of testing of this, see if I can figure out a bit of toolchain design, but input of experienced persons is much desired. I will also look at the repos for MIDI over RTP. Sounds like it's being used in production now for loss-tolerant control surfaces though, and not performance transmission, correct? I had not realized that TCP could produce timing errors, I do understand that now, I remember that being a challenge in the early development of streaming audio. I wonder if OSC2MIDI can use OSC time tag data to handle:http://opensoundcontrol.org/spec-1_0 I am working on compiling OSC2MIDI right now, does not appear trivial, we'll see :-) J.E.B. On Thu, 2018-08-30 at 08:11 +0300, christoph.k...@web.de wrote: > Hey Len, > > thanks for the insight. > > I never used OSC this way so far. > > I also did not know that there are existing RFCs for MIDI over RTP, > which is very nice! > > So, yeah, lets do that. > > I will take a closer look at the code repos you posted. I definitly > want to give this a try! > > But I am rather busy at the moment, so don't expect too fast progress > in this matter ;-) > > BR, > > Ck > > Mittwoch, 29 August 2018, 09:00nachm. +01:00 von Len Ovens > l...@ovenwerks.net: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 29 Aug 2018, christoph.k...@web.de > > wrote: > > > > > > > > > I would always prefer a UDP based solutions, because TCP can > > really mess up the > > > > > timing. UDP packetloss usually is below 1%. The bigger problem in > > this case are > > > > > WIFI connections, scrambled packet orders and jitter. > > > > > > > > > > Are there any objections to using Open Sound Control based > > solutions? > > > > > To me it makes more sence, because it is an IP-based protocol (32 > > bit) in > > > > > contrast to MIDI, which is designed for 8 bit serial interfaces. > > > > > > > > OSC being lossless has not been my experience. The problem I have > > had is > > > > the OSC messages are generally one message per packet which means > > that a > > > > large group of messages can overwhelm udp quite easily. OSC does > > allow for > > > > using bundles of messages to be performed at the same time, however > > MIDI > > > > to OSC cannot really determine a group of events that happen at the > > same > > > > time because of it's (slow) serial nature. > > > > > > > > Do note that the osc message "stormes" I have had trouble with are > > bigger > > > > than what MIDI was designed to handle in realtime (10 events from > > 10 > > > > fingers). I am talking about refreshing a control surface with at > > least 8 > > > > strips with each strip having 20 or so events. So well over 100 > > events. > > > > When I tried to use bundles, I found that no control surfaces > > created or > > > > understood bundled messages. I ended up adding a small delay in the > > sends > > > > to fix this... not very "real time" :) Not noticable while moving > > one > > > > control like a fader but noticable if performing music. > > > > > > > > > > > > -- > > > > Len Ovens > > > > www.ovenwerks.net > > > > > > ___ > > > > Linux-audio-dev mailing list > > > > Linux-audio-dev@lists.linuxaudio.org > > > > https://lists.linuxaudio.org/listinfo/linux-audio-dev > > > > > > > > > > > > > > > > > > > > > >
