I have a Yamaha keyboard with USB MIDI out, and I'd like to get that MIDI signal wirelessly to JACK running on my synth. What is the simplest way right now? I could connect the keyboard to an RPi and then netjack it to the synth via wifi, but that does not sound very simple to me :-)
--
Jonathan E. Brickman | jeb(a)ponderworthy.com | (785)233-9977
Ponderworthy | http://ponderworthy.com
Music of compassion; fire, and life!!!
Hi,
are there any good (binary) alternative kernels usable with the recent
versions of Linux Mint? I have Linux Mint 17.1 on an oldish (~2007)
laptop, and the stock low-latency kernel is not adequate for audio and
MIDI work on this machine even with LXDE.
Artem
"Robust Session Management" has now been replaced with something much better:
http://lsn.ponderworthy.com/doku.php/concurrent_patch_management
All patches are now kept running all the time, are switched by MIDI channel from the MIDI controller, and can be played simultaneously.
Process control, for reliable and controlled startup of all of those patch elements, is done by a peculiar own-grown Python library; if anyone has a better way, please do let me know :-)
--
Jonathan E. Brickman | jeb(a)ponderworthy.com | (785)233-9977
Ponderworthy | http://ponderworthy.com
Music of compassion; fire, and life!!!
On Mon, 16 Feb 2015, Rick Green wrote:
> On Mon, 16 Feb 2015, Len Ovens wrote:
>
>> I think OSC is missing parts though (just like AES67?). I should be able to
>> add a control surface/keyboard to a network and the unit should show me
>> every other unit (SW or HW) that it can talk to. From that list I should be
>> able to connect my output to a number of inputs and connect my input to
>> whatever output. Then if I play notes on a keyboard I should get the right
>> sounds, or move a control the right thing should change. That is a lot of
>> things to happen. My controller has to be able to set it's networking up
>> and then discover what other OSC stuff is around. OSC right now seems to be
>> totally manual. The user has to know the target IP and port (99% musicians
>> just blanked out) and have the server running and enter those things just
>> to have a connection. Even with a standard set of commands this is already
>> a fail.
>>
> Sorry for the off-list reply, but the list server is rejecting my posts
> today. It seems that my buddy who hosts the aapsc.com domain for me has
> gotten himself dropped into a dnsrbl hole...
>
> I think you're on the right track here. MIDI isn't extensible. OSC is too
> open. It looks like XML to me - very wordy with all the 'label=value' pairs,
> and ASCII to boot. The extra bandwidth of ethernet is eaten up by the
> wordiness of the command structure, so you don't really gain any
> commands/second advantage over MIDI.
> WHat if we had a protocol more like SNMP: Generalized like OSC, but with a
> MIB or DTD-like dictionary delivered once at initialization by the controlled
> device. The controller could use this to configure itself for the
> application, and then the actual datastream would be in a compact binary
> 'bytecode' more like MIDI. Best of both worlds?
considering the variety of uses for a control protocol, I think there is
room for more than one. There are varying amounts of acceptable latency.
What is low latency for audio, Synth control, lighting control, video, DAW
control, are all different. MIDI for synth control is well known and the
biggest thing it needs is a faster transport... Can't beat Jack for this.
It will be interesting to see the new HD MIDI to see if it is a help or
hinderance and how well supported it gets. If it allows standard MIDI
transport over IP, that alone may make it worth while, just because it
would give us a standard way of doing MIDI over net. However, from reading
the blurbs on HD, it seems they have gone beyond one step up. More
channels yes... merely changing 8 bit to 16 would go from 16 channels to
256, but they are talking "thousands". This would indicate to me that they
are increasing the bit width by 4x. A 16 bit word would be used just for
channel, another just for velocity, another for release velocity, another
for presure, another for tuning of the note (can change on a pre note hit
basis... maybe during the note hold too... not to mention the note
itself... SOunds like 12 bytes per key press already (by my guess). Not
exactly compact, but perhaps more so than some OSC.
One thing to remember though, Ethernet does have minimum packet size. (42
bytes or so as happens... minus a few more for udp/ip headers) So a single
note on in MIDI would take the same ethernet traffic as an OSC message in
many cases. OSC does have a sort of running status where a PWD can be set
and can also use wild cards to send the same message to a number of
different addresses. There is an OSC standard set of performance (note
on/off/whatever/etc.) in the works as well that seems to be very close to
what HD MIDI is doing. The reality is that GB ethernet is what makes
lowlatency audio/midi possible or at least stable, not because it is
designed for low latency work, but because it is fast enough that a small
packet has a low latency... and on GB, MTU1500 is small packets. 100M
networks can, if they are real quiet, do very well too. But to be reliable
one has to design for at least moderately busy networks.
OSC does have (or can) self documenting signals. The path name tells the
intended destination program, channel (by name or number), what is to be
controled, and how much... all in english (or greek or whatever). The
language could even be possibly multi-lingual without changing bandwidth.
OSC has a query setup so the sending client can find out what commands are
available and what they do... I have more to read on this part :)
Using ethernet as a transport for anything has to assume that the
transport is not locked to our use. This is new to the audio/music world
which is used to having it's own MIDI line and it's own audio port/card.
Sharing resources has been something we have tried to avoid for years and
now with networking, sharing has to be assumed... sort of like plugging
one's USB audio into a hub that also has a USB drive, mouse, keyboard and
wireless dongle using it. Fun stuff, and really not that different than
sharing a PCI bus.
--
Len Ovens
www.ovenwerks.net
Ralf Mardorf wrote:
> A PPA, perhaps kxstudio, might provide linux-rt for the OP's distro.
Tried that, haven't found anything like rt or preepmt kernel there.
> <A nice detailed Debian-specific instruction and explanation skipped>
Thank you, the make-kpkg procedure looks convenient, since that way I'm
getting a native deb. If there's no binary alternative, that's probably
the way I'll be building my kernel.
Artem
Gene Heskett wrote:
> Look in the repo for a kernel with rt-preempt in its name string.
Unfortunately, no such thing here.
> <A nice detailed instruction and explanation skipped>
Thanks, if I don't find a suitable ready-made kernel, I'll try building
my own, though I haven't done that in quite a while.
Artem
Beware old building with additions :P It appears we have power coming
from two power entrances with two different earth grounds to the panels. I
had found two power cords with the ground pin pulled which I replaced...
big ground loop noise. I tried (as read from a number of sources) making
unballanced cables with a small resitor in the ground path but this made
things worse not better. I will be running a power cord from the stage
back to the mixer next. All of our signal in paths are already isolated.
It is only the two monitor mixes to powered monitors that are unballanced
and causing problems. The outputs from the mixer are ballanced, but the
lines to the stage are not... I may make cables to allow me to use two of
the input ballanced lines instead and two more isolation boxes as a longer
term fix. There will be a new stage going in and I have already been
asking that power and grounding be corrected for the whole signal flow.
--
Len Ovens
www.ovenwerks.net
Hi
The topic say’s it all, any Graphic designer around here, who like to
create a new, overall design for the guitarix project?
If so, please contact me.
regards
hermann
Hi Daniel. Sorry for late followup here.
I'm changing the thread (was "LAU: OpenMusic 6.9 - new build for Ubuntu
(.deb) and Fedora (.rpm)") - it's sliding sideways now.
>>>>> On Thu, 5 Feb 2015 11:54:48 +0100, Daniel Appelt said:
D> Maybe you could try to run the small programs I provided as
D> attachments to the GDK bug report? They should just work on your 64bit
D> system.
D> https://bugzilla.gnome.org/show_bug.cgi?id=735995
Checking both 64 and 32-versions of the programs, doesn't show the
errors you reported w. bugzilla:
What does this mean?
-anders
