[LAD] connect(2) call to /dev/shm/jack-0/default/jack_0 failed (err=No such file or directory) (again...)
Hi all, Sorry to bother you again with this. I’m running into the same problem again as before (see the latter part of the [LAD] jackd not using jackdrc… thread). And apparently my last fix involved some magic rather than replicable logic… :-( i.e. the problem seems to have disappeared on that system, without knowing exactly why) Now I am installing my jack client again on another fresh install of ubuntu 17.04. and a get the same error. I have installed jackd1, to be exact, these packages are current. jackd/artful,artful,now 5 all [installed,automatic] jackd1/artful,now 1:0.125.0-2 amd64 [installed] jackd1-firewire/artful,now 1:0.125.0-2 amd64 [installed,automatic] libjack0/artful,now 1:0.125.0-2 amd64 [installed] qjackctl/artful,now 0.4.5-1ubuntu1 amd64 [installed,automatic] when I start my client jackd is automatically started but i get the error: connect(2) call to /dev/shm/jack-0/default/jack_0 failed (err=No such file or directory) By browsing the jack sources i found the message seems to come from libjack/client.c in server_connect() peeking into the /dev/shm directory it seems /dev/shm/jack-0/default/jack_0 is briefly created,but disappears again, presumably just before the client is able to connect. I have been breaking my head over this, but I really have no clue why this is happening, especially as this has worked fine in the past. I would really like to know what could possibly cause this error and how to fix it. thanks, fokke ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC
On Tue, 11 Sep 2018, Thomas Brand wrote: On Tue, September 11, 2018 10:34, David Runge wrote: On 2018-09-10 19:32:52 (-0400), Mark D. McCurry wrote: On 09-09, Christopher Arndt wrote: I'd definitely be interested in helping OSC staying relevant. I guess a good first starting point is to contact the former maintainers and get them involved (and to notify them about the website status - maybe it needs a new home?). yes. Guess it would also be nice to find out what the motivations behind abandoning 1.1 were. just that the project was no longer funded. I don't think it was broken and there are projects that do use some of the 1.1 spec. it is difficult to encourage new projects (glass controlers mostly) to support 1.1 stuff when there is no spec to point at. Hey, i have collected a few OSC related documents in this repository some time ago: https://github.com/7890/osc_spec Great! This is at least somewhere to point people. -- 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] OSC
On Sun, 9 Sep 2018, Christopher Arndt wrote: From the LAU list: Am 08.09.18 um 17:23 schrieb Len Ovens: I would be willing to help with a govering body if there are others so inclined. I'd definitely be interested in helping OSC staying relevant. I've dabled with different OSC-to-X bridges in the past. [1] [2] [3]. My main interest is controlling applications, which talk to some MIDI device, running on a desktop or Raspi or similar, from another application on an Android device, since MIDI and USB-OTG support on Android devices is still somewhat a matter of luck. The protocols I've seen so far, which embed MIDI in OSC are often too simplistic. If I can't transmit Sysex, for example, it's no use to me. I agree sysex is important, as are rpn nrpn which probably can be transmitted as four events with current protocols, but should be treated as one osc event. And what is the advantage of the verbose commands MidiOSC/midioscar use over just using the MIDI data type OSC provides? It would allow a midi keyboard to perform using a synth designed for OSC performance control. That is, while in the OSC domain, the performance would have compatablitiy with a wide range SW. This does not help someone using OSC as a transport bridge at all and so maybe having two ways of dealing with this problem would make sense or at least the availablility of a raw method. Also, the MIDI specification has had a few additions in the past years and a OSC-MIDI protocol hould make sure to support those as well. There are appendages to the MIDI 1.0 spec. Supporting them is fine, but in a raw midi sense they mostly seem to take midi 1.0 events and give them new meaning which doesn't really affect data bridging so much as midi performance to OSC performance translation. MIDI 2.* is a whole new ball game and not really backwards compatable and as such doesn't seem to have caught on. Lots of people still use their pre MIDI 1.0 DX7s for example. Vintage synth use is still very common so for a new controller to be relevant, it uses MIDI 1.0. MIDI 2, if anything, shows a need for an intermediat OSC format that performance data can be converted to/from with possibly midi 1.0 on one end and midi 2 on the other. MIDI and OSC are all about controlling an application, but control for performance is very different from control of an application's parameters. OSC is better for both, but in the case of controlling parameters, much better as midi is not really designed for the ways many controllers use it. (look at the hack job mackie control uses as a great example) It is almost worth having a MCP_to_OSC bridge for such things. As a note, My personal use of both MIDI and OSC has been the control of Application parameters rather than performance control (though I have made a HW MIDI filter to allow only drum info through many years ago). I currently work on the OSC code for Ardour to control transport, mixer, and session values. So if it's broken, thats my fault. Of personal interest would be an OSC standard for mixer/transport control. I do not have an attitude that what I use now is the best. I would be ok with adding standard based controls to Ardour if such standards are available. However, I do have experience working with current controllers and their shortcoming. Of particular note in this case, most controllers are only able to deal with one control and one or two parameters per control and often only one type of parameter (float only is common but at least one is string only). There does not seem to be much in the way of one message gives all parameters for one strip for example. The exceptions are custom sw/hw such as the X32 mixers (and some parts of Ardour as happens). These experiences have shown that while some of the OSC query stuff in OSC 1.1 looks good, in practice with current controllers, it doesn't work or even really make sense. In mixer/transport control the end result is that both the controller and the DAW or other controled unit, send control messages as well as act on them. (we call this feedback) So rather than querying a value, a controller asks to start receiving feedback for a control or set of controls. The controlled device then sends the current value of the requested control(s) as well as any changes as they happen. A better use for query would be to find out what controls are available. So querying strip 1 would tell how many channels it controls and what controls it has (fader, pan, eq, plugins, etc.). Each control could be queried to find out about subcontrols and control limits and units. Showing how to access each would help too. Most controllers are are not able to deal with such things right now but if there was a standard, maybe that would change. OCA tries to do this by the way ( http://ocaalliance.com/ ) but has no performance control at all. -- Len Ovens www.ovenwerks.net ___ Linux-a
Re: [LAD] OSC
On Wed, 12 Sep 2018, Len Ovens wrote: that would change. OCA tries to do this by the way ( http://ocaalliance.com/ ) but has no performance control at all. I should have added that OSC is still much easier to trouble shoot using wireshark or similar than OCA. -- 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] OSC
FYI, there is also O2: https://github.com/rbdannenberg/o2 "O2 is a new communication protocol and implementation for music systems that aims to replace Open Sound Control (OSC). Many computer musicians routinely deal with problems of interconnection in local area networks, unreliable message delivery, and clock synchronization. O2 solves these problems, offering named services, automatic network address discovery, clock synchronization, and a reliable message delivery option, as well as interoperability with existing OSC libraries and applications. Aside from these new features, O2 owes much of its design to OSC and is mostly compatible with and similar to OSC. O2 addresses the problems of inter-process communication with a minimum of complexity." On 12/09/18 19:27, Len Ovens wrote: On Tue, 11 Sep 2018, Thomas Brand wrote: On Tue, September 11, 2018 10:34, David Runge wrote: On 2018-09-10 19:32:52 (-0400), Mark D. McCurry wrote: On 09-09, Christopher Arndt wrote: I'd definitely be interested in helping OSC staying relevant. I guess a good first starting point is to contact the former maintainers and get them involved (and to notify them about the website status - maybe it needs a new home?). yes. Guess it would also be nice to find out what the motivations behind abandoning 1.1 were. just that the project was no longer funded. I don't think it was broken and there are projects that do use some of the 1.1 spec. it is difficult to encourage new projects (glass controlers mostly) to support 1.1 stuff when there is no spec to point at. Hey, i have collected a few OSC related documents in this repository some time ago: https://github.com/7890/osc_spec Great! This is at least somewhere to point people. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev ... ...Diemo -- Diemo Schwarz, PhD -- http://diemo.concatenative.net Sound–Music–Movement Interaction Team -- http://ismm.ircam.fr IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France Phone +33-1-4478-4879 -- Fax +33-1-4478-1540 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
