On Sun, 20 Jan 2019, Will J Godfrey wrote: The video does not add to much of what I was aware of. Not too long ago, the MMA were much more open than they are now and I could browse (without login) where MIDI2 was at and the format of commands. I have forgotten the specifics :) and so the video was a good refresher. Jackd is a data pipe, so is alsa for that matter. Audio is 32 bit (float) MIDI 2 is 32 bit as well. ALSA (so far as I know) doesn't "mix" or combine MIDI. Jackd does and so it would still need to know event breaks. I would think the way forward for both ALSA and jackd would be to use MIDI 2 internally and convert to MIDI 1.0 at the port if needed. That is stream MIDI as 32bit words and let the applications deal with negotiations with the other end. 32bit midi works well with aes67 or avb as well, it is just a different data type. So even though aes3 streams are not included in the aes67 standard, many of the aes67 boxes will deal with them just fine. MIDI2 is bdirectional, jackd and alsa are not but they don't disalow it either. in both cases there would need to be two channels to handle that... but the reality for a lot of MIDI 1 applications has been bidirectional since day one. Even with my slightly pre midi 1, midi gear, there is the idea of the two talking with each other just with two cords (for speed more than anything). OSC as in the video was not sold well to the manufactures... I would say the real reason is both OSCs strength and it's weakness... you can do anything with OSC, it is wide open. OSC did not from the start come with some standard ways of doing things (note on/off/etc. controllers) OSC has every single use is custom, there are no standards at all, each application has it's own standard. Quite the oposite to MIDI. I know of only two DAWs that share the same OSC map and that is Ardour and Mixbus ;) So there are no physical OSC control surfaces available and even the Glass counterparts like touchOSC are limited and still require someone to create a layout for everything they might control even though each application might have the very same controls. In many ways, if midi2 offers good standard ways of dealing with mixer control, lighting, transport control and other automation, OSC may just go away because MIDI 2 can offer more. It would be easy even now for me to create a Mackie control protocol to OSC converter... or almost any midi based controller out there. MIDI2 will only make this easier. MIDI2 is also more compact by virtue of being streamed. While OSC may be self documenting, for most controllers, each message/event/command requires a whole network packet. I tried using "bundles" but found none of the control surfaces I was trying to support recognised them. The feedback stream from a daw is quite heavy, A bank change that the control surface sends as one message requires the daw to send back as many as 1000 messages each one as it's own packet... udp chokes and many messages never make it there unless a small delay is added between each message. There are ways around this: Bundles is one, if the surface understands those. The X32 points to another: each channel only sends one message with enough parameters for the whole channel... there goes self documenting messages. I am thinking of offering both as options in Ardour BTW. Then there is OCA https://www.ocaalliance.com/ (now aes70 I see) which is much more tightly defined and also interactive like MIDI2. It allows the surface to find out what the device controls are and create or asign controllers to those functions. The setup expects to deal with more than one device at a time. So for example an OCA surface might show an Ardour strip with a preamp control section at the top that controls the alsa device directly as if it was all one app being controled. Yes it is possible to do this with OSC, but the setup is all manual and not all OSC surfaces are willing to talk to more than one port. MIDI1.0 already supports more than one channel internally and MIDI2 expands on that while also offering control negotiation. There was work started on an OCA library for linux... but the dev seems to have gotten a life (job maybe?). There are a number of "new" things that Linux is lacking. ALSA in particular I suppose. I would list: RTPMIDI - old code exists, but I can't make it work AES67 - I believe there is something started AES70 - See above AVB - there are some linux bits of this (connect jack on two machines) Bluetooth (in alsa) - There used to be BT in alsa now only in pulse and now MIDI2 - spec not ready a better way of dealing with HDMI audio in alsa would be nice hdmi audio for many people does not work with even medium low latency as it needs a 4k buffer. a better way of dealing with HDA audio. Pulse does this well, but jack and other audio applications that deal directly with alsa do not. For example try opening an HDA device in jack or Ardour with more ports than two (most support 6 or 8 output channels) Just as a short list. USB2.0 audio has been a gift and a curse to linux audio. It has allowed almost all audio interfaces to work with Linux out of the box (Thank you Apple!). It has also taken away from Linux the push to deal with new audio setups... linux audio is working no need to mess with it. Linux needs a new generation of developers to catch up with this. Either by adding these things to alsa, or with something new. Basically, if no one works on MIDI2 infrastructure, midi2 will only be used as direct usb drivers to applications. Honestly, Linux MIDI handling is kind of a mess right now anyway... maybe midi2 is a blessing. I sometimes wonder if all audio in Linux should be treated as if it was network audio following either aes67 or avb as a standard even internally and provide the library functions to do so. Set the base latency at 1ms (works with aes67 and avb) and allow the library to give the application whatever latency it wants. Because every application would be an endpoint, jack like routing is almost there (jackd also allows mixing two streams into one port) by default. I also wish I was 30 years younger with todays knowledge... -- Len Ovens www.ovenwerks.net

Am Samstag, 19. Januar 2019 23:40 CET, Len Ovens <len(a)ovenwerks.net> schrieb: No, those people don't use samples - we are talking full-size grand pianos here. Those Disklaviers record and play back performances on actual concert instruments. Think of it as a digital version of a Welte-Mignon player piano (the company has it's origins here in Freiburg/Germany). The local museum does regular concerts with roles recorded by famous soloist/composers from the first half of the last century. IIRC the velocity resolution on those roles is higher than the 7 bits used by midi. ??? IIRC the Roli keyboards have better resolution and those are used quite often for contemporary music performance. Some Casio E-Pianos seem to have high-resolution velocity values (14 bit), see https://support.casio.com/storage/en/manual/pdf/EN/008/PX760_860_1500_160_A… Not what our piano teachers say ;-) Cheers, RalfD

On Sat, 19 Jan 2019 18:31:29 -0800 (PST), Len Ovens wrote: I'm playing a Roland GR-55 guitar synth. It has got a MIDI input, but it does not recognize note numbers. The rational for this might be related to the way the synth is able to use the signals of the hex pickup and that apart from the PCM tones, the patches could contain modeling. Modeling doesn't just mean guitar and amp emulations, it's also for modeling an analog synth. The MIDI output provides all MIDI data, but that data can't compare to the data used by the synth. OTOH the MIDI settings provide to turn chromatic output on and off, actually it's turned off, but the output is chromatic, IOW I don't understand this setting for the MIDI output. The chromatic switch for the PCM tones is interesting. The tones are played in chromatic steps, even if a string is bend, the pitch will change in semitones, when turned on. If it's turned off, the PCM tones follow the real pitch of each string. This is very cool, but hardly usable, since each noise a string does produce has got impact, when turned off. Even the most accurate guitar player can't avoid e.g. fret noise of new strings. IOW if the sensitivity settings of the hex pickup are chosen to track nuances of the guitarists playing, it requires to turn chromatic on, since if it's turned off, it's nearly impossible to avoid unwanted notes. The current generation of guitar synth does not allow practicable usage of all provided abilities. While MIDI 2 might be able to transmit the real data that is produced when chromatic is turned off, it's not much usable and regarding modeling MIDI anyway is the wrong interface. To replace my keyboard by the guitar, MIDI 1 already does the job. At the moment I play synth most of the times via a 12.9" touch screen, usually just to produce regular MIDI 1 data. A touch screen could also produce MIDI 1 incompatible data, but it's very seldom useful. The MIDI we know has got several pitfalls and indeed some improvements are very good, but all in all it already does everything a musician does need. Yes, to control a mechanical monstrosity, such as a robot piano MIDI isn't an adequate interface and I doubt that this would change by a new MIDI standard. A guitar synth does use the guitar as an input device, via a hex pickup. It isn't a robot guitar, there are no stepper motors picking, slapping, muting etc. the strings for playback. It's not the MIDI standard that fails to play a robot piano, the designers are idiots, if they use MIDI to control this kind of robot. MIDI 2 could be useful for guitar synth, especially for guitar synth of the next generation. A new MIDI standard could also be useful to get rid of a few pitfalls, but it unlikely will become a robot interface. -- pacman -Q linux{,-rt{-securityink,-cornflower,,-pussytoes}}|cut -d\ -f2 4.20.3.arch1-1 4.19.15_rt12-0 4.19.13_rt10-0 4.19.10_rt8-0 4.18.16_rt9-1