Re: [LAD] Potential MIDI headaches?
On Sun, 20 Jan 2019 14:29:46 -0800 (PST), Len Ovens wrote: >I also wish I was 30 years younger with todays knowledge... In my opinion knowledge means less. More important IMO is the motivation, the skills to use free time. I wish I would be 30 years younger with the gear I own today. For example, Floyd Rose and active Humbuckers already existed when I was 30 years younger, but I didn't had the money to pay for it. I was young, highly motivated and a very good guitarist. Today I'm less motivated and as a consequence, in relation to back then, I'm a lousy guitarist today, but today I own this and other gear, some of what even didn't exist that time. For example, for some time the best synth "workstation" I owned was a Roland MT-32, fortunately with software to program it, but since it had only one MIDI in, data overflow that could cause a missing hi-hat now and then was a serious limitation. As for knowledge I could be 30 years younger, even without nowadays knowledge, since as a consequence of my highly motivation, I was very fast in learning. The issue today is motivation. I don't use my time as good as I was able to use it, when I was young. The young man was able to manage the time for women for a lot of friends for programming audio software for making music with a band for making music on his own to go to school or work The old man is unable to manage the time just for a few friends to make music on his own to go to school or work ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Potential MIDI headaches?
On Sun, 20 Jan 2019, Will J Godfrey wrote: More details https://www.youtube.com/watch?v=iDyXDeLbmeE Following on, I think our biggest problem is going to be actually getting the data into a computer. I can't imagine a practical way either ALSA or JACK can be modified to accept it. 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 would only work if the data source was sending it, otherwise you'd still need a translation level within the machine (in which case you might as well work with the protocol directly). The big synth names are not likely to put any effort into OSC support, as they have already thrown their hats in for MIDI 2. I was actually surprised that the MMA managed to get both Apple and Microsoft on board. 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?). I've now watched that vid. a second time (very much recommend looking at it if you haven't
Re: [LAD] [LAA] [LAU] GxPlugins.lv2 release v0.6
Am 20.01.19 um 18:44 schrieb Christopher Arndt: In file included from plugin/gx_AxisFace.cpp:66: plugin/gx_AxisFace.h:25:10: fatal error: lv2.h: No such file or directory #include strange, works like expected here, you've installed the LV2 development files, I guess. So, the question is, were do you've installed lv2.h, and is it in the default gcc include path? (check with "cpp -v" were gcc search for include files and ensure lv2.h is in on of those paths. regards hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAA] [LAU] GxPlugins.lv2 release v0.6
Am 20.01.19 um 18:44 schrieb Christopher Arndt: > Previously a "make INSTALL_ROOT=/usr/lib/lv2" at the root level was > enough, err, I mean "make INSTALL_DIR=..." 0x1E0D97B33A4E1F31.asc Description: application/pgp-keys ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAA] [LAU] GxPlugins.lv2 release v0.6
Hi Hermann, Am 20.01.19 um 13:12 schrieb Hermann Meyer: > I like to announce a new release of GxPlugins.lv2 has something changed with the compilation procedure? Previously a "make INSTALL_ROOT=/usr/lib/lv2" at the root level was enough, but now I get: make[1]: Entering directory '/home/chris/src/arch/aur/gxplugins-lv2/src/GxPlugins.lv2/GxAxisFace.lv2' make[1]: Entering directory '/home/chris/src/arch/aur/gxplugins-lv2/src/GxPlugins.lv2/GxHeathkit.lv2' make[1]: Entering directory '/home/chris/src/arch/aur/gxplugins-lv2/src/GxPlugins.lv2/GxVoodoFuzz.lv2' make[1]: Entering directory '/home/chris/src/arch/aur/gxplugins-lv2/src/GxPlugins.lv2/GxSlowGear.lv2' . . \033[1;34m, clean up\033[0m . . \033[1;34m, clean up\033[0m g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -I. -I./dsp -I./plugin -fPIC -DPIC -O2 -Wall -funroll-loops -ffast-math -fomit-frame-pointer -fstrength-reduce -fdata-sections -Wl,--gc-sections -msse3 -mfpmath=sse plugin/gx_AxisFace.cpp -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -I. -shared -lm -o gx_AxisFace.so g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -I. -I./dsp -I./plugin -fPIC -DPIC -O2 -Wall -funroll-loops -ffast-math -fomit-frame-pointer -fstrength-reduce -fdata-sections -Wl,--gc-sections -msse3 -mfpmath=sse plugin/gx_slowgear.cpp -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -I. -shared -lm -o gx_slowgear.so . . \033[1;34m, clean up\033[0m g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -I. -I./dsp -I./plugin -fPIC -DPIC -O2 -Wall -funroll-loops -ffast-math -fomit-frame-pointer -fstrength-reduce -fdata-sections -Wl,--gc-sections -msse3 -mfpmath=sse plugin/gx_voodoo.cpp -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -I. -shared -lm -o gx_voodoo.so . . \033[1;34m, clean up\033[0m g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -I. -I./dsp -I./plugin -fPIC -DPIC -O2 -Wall -funroll-loops -ffast-math -fomit-frame-pointer -fstrength-reduce -fdata-sections -Wl,--gc-sections -msse3 -mfpmath=sse plugin/gx_Heathkit.cpp -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -I. -shared -lm -o gx_Heathkit.so In file included from plugin/gx_AxisFace.cpp:66: plugin/gx_AxisFace.h:25:10: fatal error: lv2.h: No such file or directory #include 0x1E0D97B33A4E1F31.asc Description: application/pgp-keys ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [LAA] [LAU] GxPlugins.lv2 release v0.6
Hi I like to announce a new release of GxPlugins.lv2 GxPlugins.lv2 is a set of mostly analogue guitar pedal simulations as LV2 plugins, simulated with the guitarix ampsim toolkit. This release add the GxCreamMachine, GXValveCaster and the GxBoobTube to the set, and fix a issue with the bypass state under automation conditions. I hope they may be useful for the one or the other. Build instruction and screenshots may be found here: https://github.com/brummer10/GxPlugins.lv2 the release tar.gz file is located here: https://github.com/brummer10/GxPlugins.lv2/releases regards hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Potential MIDI headaches?
On Sat, 19 Jan 2019 21:39:59 + Will J Godfrey wrote: >On Sat, 19 Jan 2019 13:26:55 -0800 (PST) >Len Ovens wrote: > >>In fact MIDI 2 seems to be a thing mostly for non-kb instruments or computer >>generated material (most of which is probably using CV instead of MIDI >>anyway). >> >>MIDI 1 was huge, My DX7 supported MIDI before the spec was complete. It is >>easy >>to show off in the music store and sell. I expect the switch to MIDI 2 will >>be >>a much longer road, very hard to show off from a keyboard. >> >>Well thats my opinion anyway. >> >>-- >>Len Ovens >>www.ovenwerks.net > >More details >https://www.youtube.com/watch?v=iDyXDeLbmeE > >I watched this earlier. It seems the MMA have indeed done their homework. MIDI >1.0 is definitely not going away. The new system will be fully backward >compatible, and will negotiate for the improvements, falling back to 1.0 if no >response is seen. > Following on, I think our biggest problem is going to be actually getting the data into a computer. I can't imagine a practical way either ALSA or JACK can be modified to accept it. OSC would only work if the data source was sending it, otherwise you'd still need a translation level within the machine (in which case you might as well work with the protocol directly). The big synth names are not likely to put any effort into OSC support, as they have already thrown their hats in for MIDI 2. I was actually surprised that the MMA managed to get both Apple and Microsoft on board. I've now watched that vid. a second time (very much recommend looking at it if you haven't already) and I'm even more impressed with the way they've designed the new extensions. Also, to some degree they've split the more 'engineering' aspects away from the more musician/performance focused ones. My guess is we've got about 2 years to get up to speed before source instruments become mainstream. Although I'd like to be involved myself, I really don't think I've the skills to add anything useful :( -- It wasn't me! (Well actually, it probably was) ... the hard part is not dodging what life throws at you, but trying to catch the good bits. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Potential MIDI headaches?
PS regarding robot pianos:
A workaround for one issue would be to select different velocity curves
by a CC message, to fit to different parts of a song played by a piano
master class. Software even could transmit measuring probe data from
the robot piano to the software via MIDI 1 to determine an appropriate
velocity curve. Even within the limits of MIDI 1 the problem with
robots is that robots need a completely different approach. A better
MIDI standard would improve the situation for robots, too, but never
ever does solve the robot problem.
--
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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
