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
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
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 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
I always thought of OSC as a product of CNMAT at UC Berkeley, which is maybe doing less now with technology since the passing of its founder David Wessel: http://cnmat.berkeley.edu/event/2015/03/22/david_wessel_1942_2014 Is there not anyone on this list from CNMAT? -- Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC
Le 2018-09-11 19:08, Len Ovens a écrit : As no one bothered to move these documents onto the OSC site proper, those documents were lost when these students pages were deleted ... https://archive.org/web/ could be of help here. Olivier ___ 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, 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 don't have much time to contribute at this point, though it would be great to know that some effort is being put into at least maintaining the existing information on the standard as well as what implementation are available for applications to use. 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?). Guess it would also be nice to find out what the motivations behind abandoning 1.1 were. The site is run by a university. They or some of their students were the original maintainers. however, it seems the funding for OSC work has been removed. The original site has been left intact but some of the links were to personal web pages of students. As no one bothered to move these documents onto the OSC site proper, those documents were lost when these students pages were deleted (when the students left the school and started working?). So lost rather than abandoned may be more reasonable, though the difference is probably arguable :) I would guess the first thing would be to clone what is there so that at least that doesn't get "lost". -- 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 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 don't have much time to contribute at this point, though it would be >> great to know that some effort is being put into at least maintaining the >> existing information on the standard as well as what implementation are >> available for applications to use. > 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?). > > Guess it would also be nice to find out what the motivations behind > abandoning 1.1 were. > Hey, i have collected a few OSC related documents in this repository some time ago: https://github.com/7890/osc_spec I've rewritten the spec to be rendered with asciidoc. I've started to try to describe the byte syntax as EBNF. I've created an OpenSoundControl organization. I've not consequently worked more on it, it's not complete etc. Just in case.. should i put you both to the org? Greetings Thomas ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC
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 don't have much time to contribute at this point, though it would be > great to know that some effort is being put into at least maintaining > the existing information on the standard as well as what implementation > are available for applications to use. 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?). Guess it would also be nice to find out what the motivations behind abandoning 1.1 were. Best, David -- https://sleepmap.de signature.asc Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC
On 09-09, Christopher Arndt wrote: > I'd definitely be interested in helping OSC staying relevant. I don't have much time to contribute at this point, though it would be great to know that some effort is being put into at least maintaining the existing information on the standard as well as what implementation are available for applications to use. --Mark signature.asc Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] OSC
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. And what is the advantage of the verbose commands MidiOSC/midioscar use over just using the MIDI data type OSC provides? 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. Chris [1] https://github.com/SpotlightKid/osc2rtmidi [2] https://github.com/SpotlightKid/osc2mqtt [3] https://github.com/SpotlightKid/touchosc2midi ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC-generating plugin?
On 06/19/2017 11:57 PM, Jörn Nettingsmeier wrote: > the customer is always right Doesn't sound like the right customer though :-) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC-generating plugin?
On 06/19/2017 10:07 PM, Diemo Schwarz wrote: ToscA! http://forumnet.ircam.fr/shop/en/forumnet/84-tosca.html "ToscA plugin can be inserted into a DAW (Digital Audio Workstation, such as ProTools, Apple Logic, Digital Performer, Ableton Live, etc.) in order to send/receive parameters’ automation. The ToscA plugin is available in the following formats: AU, VST, VST3, AAX." Thanks Diemo! I would have preferred an open-source tool, but since this whole scheme is evil anyways and you can only lose your soul once, it'll be fine :-D I will admit to having bought a used Macbook recently (the customer is always right, and he uses QLAB), so I will use that for testing. I can't believe I will be remote-controlling Ardour from Reaper :-D An exercise in futility for the sake of maintaining the client's workflow of choice... -- Jörn Nettingsmeier De Rijpgracht 8, 1055VR Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT http://stackingdwarves.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC-generating plugin?
Robin, Julius, thanks for your replies. Julius, I wasn't aware of OSC magic in faust - I recently used it to decode a mic prototype array I was testing, and it worked like a charm (lazy me just used the online compiler), so I'll definitely check it out. Will need to understand the realtime issues that Robin pointed out, though. On 06/19/2017 09:20 PM, Robin Gareus wrote: On 06/19/2017 08:07 PM, Jörn Nettingsmeier wrote: Hi *! Does anybody know of a decent free plugin that generates arbitrary OSC command streams from plugin automation data in the DAW? Preferrably (gasp!) VST? Idea is to use SomeEvilDAW to send and control smart things on a box running a friendly OS and a FriendlyDAW. Sending OSC is not rt-safe and VST parameters are rather limited. "arbitrary messages" are no fun and need all kinds of hacks (eg sending them from the UI thread). There are a couple of single-parameter VSTs though. Clarification: "arbitrary" in the sense of "freely configurable", like so: data type, lower limit, upper limit, default value, OSC string, OSC target URL. So the plugin will be pretty static once it's set up. I could even live with this being compile-time options. Along those lines there's an ancient LADSPA plugin, too: https://code.google.com/archive/p/noisesmith-linux-audio/downloads needs some CFLAGS=-fPIC but otherwise still compiles, but it probably won't run in SomeEvilDAW. A more generic solution: https://github.com/x42/jackmidi2osc Receive MIDI from someplace, generate fancy OSC based on rules. I see. So this would also circumvent the realtime issue, since the plugin would be using the host's MIDI sending mechanism? Spencer wrote a similar tool https://github.com/ssj71/OSC2MIDI/ which despite its name can also turn MIDI into OSC. Thanks for the pointers, I'll look at them. Best, Jörn -- Jörn Nettingsmeier De Rijpgracht 8, 1055VR Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT http://stackingdwarves.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC-generating plugin?
ToscA! http://forumnet.ircam.fr/shop/en/forumnet/84-tosca.html "ToscA plugin can be inserted into a DAW (Digital Audio Workstation, such as ProTools, Apple Logic, Digital Performer, Ableton Live, etc.) in order to send/receive parameters’ automation. The ToscA plugin is available in the following formats: AU, VST, VST3, AAX." ...Diemo On 19/06/17 21:20, Robin Gareus wrote: On 06/19/2017 08:07 PM, Jörn Nettingsmeier wrote: Hi *! Does anybody know of a decent free plugin that generates arbitrary OSC command streams from plugin automation data in the DAW? Preferrably (gasp!) VST? Idea is to use SomeEvilDAW to send and control smart things on a box running a friendly OS and a FriendlyDAW. Sending OSC is not rt-safe and VST parameters are rather limited. "arbitrary messages" are no fun and need all kinds of hacks (eg sending them from the UI thread). There are a couple of single-parameter VSTs though. Along those lines there's an ancient LADSPA plugin, too: https://code.google.com/archive/p/noisesmith-linux-audio/downloads needs some CFLAGS=-fPIC but otherwise still compiles, but it probably won't run in SomeEvilDAW. A more generic solution: https://github.com/x42/jackmidi2osc Receive MIDI from someplace, generate fancy OSC based on rules. Spencer wrote a similar tool https://github.com/ssj71/OSC2MIDI/ which despite its name can also turn MIDI into OSC. ciao, robin -- 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 http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC-generating plugin?
On 06/19/2017 08:07 PM, Jörn Nettingsmeier wrote: > Hi *! > > Does anybody know of a decent free plugin that generates arbitrary OSC > command streams from plugin automation data in the DAW? Preferrably > (gasp!) VST? Idea is to use SomeEvilDAW to send and control smart things > on a box running a friendly OS and a FriendlyDAW. Sending OSC is not rt-safe and VST parameters are rather limited. "arbitrary messages" are no fun and need all kinds of hacks (eg sending them from the UI thread). There are a couple of single-parameter VSTs though. Along those lines there's an ancient LADSPA plugin, too: https://code.google.com/archive/p/noisesmith-linux-audio/downloads needs some CFLAGS=-fPIC but otherwise still compiles, but it probably won't run in SomeEvilDAW. A more generic solution: https://github.com/x42/jackmidi2osc Receive MIDI from someplace, generate fancy OSC based on rules. Spencer wrote a similar tool https://github.com/ssj71/OSC2MIDI/ which despite its name can also turn MIDI into OSC. ciao, robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC-generating plugin?
Hi Jörn, That's a cool idea - I'm going to need this as well! How about using faust2faustvst to create a VST plugin having the parameters you want to automate, and using Faust's OSC support to "xmit" the automation? I have only used Faust OSC in the other direction (https://ccrma.stanford.edu/~jos/aspf/Using_FAUST_Open_Sound.html) but it looks like the xmit mode should be adaptable to our needs. We might have to manually (with an architecture-file edit) link receive to transmit, since it appears from the doc that the xmit option is only for emitting manual manipulations of the GUI elements: http://faust.grame.fr/docs/faust-quick-reference.pdf - it's not clear to me that received OSC messages will be subject to xmit forwarding. - Julius On Mon, Jun 19, 2017 at 11:07 AM, Jörn Nettingsmeier wrote: > Hi *! > > Does anybody know of a decent free plugin that generates arbitrary OSC > command streams from plugin automation data in the DAW? Preferrably (gasp!) > VST? Idea is to use SomeEvilDAW to send and control smart things on a box > running a friendly OS and a FriendlyDAW. > > Best, > > Jörn > > > -- > Jörn Nettingsmeier > De Rijpgracht 8, 1055VR Amsterdam, Nederland > Tel. +49 177 7937487 > > Meister für Veranstaltungstechnik (Bühne/Studio) > Referent für Beschallung im VDT > > -- > Jörn Nettingsmeier > De Rijpgracht 8, 1055VR Amsterdam, Nederland > Tel. +49 177 7937487 > > Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT > http://stackingdwarves.net > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev -- Julius O. Smith III Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] OSC-generating plugin?
Hi *! Does anybody know of a decent free plugin that generates arbitrary OSC command streams from plugin automation data in the DAW? Preferrably (gasp!) VST? Idea is to use SomeEvilDAW to send and control smart things on a box running a friendly OS and a FriendlyDAW. Best, Jörn -- Jörn Nettingsmeier De Rijpgracht 8, 1055VR Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Referent für Beschallung im VDT -- Jörn Nettingsmeier De Rijpgracht 8, 1055VR Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT http://stackingdwarves.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC direct communication with non-session-manager clients
On 07.10.2016 16:35, Maurizio Berti wrote: > Hello, > I need to find a way to communicate via OSC with a non-session-manager client > (non-mixer) by using a fixed port number. > > I'm developing a "midi proxy" based on mididings, which allows me to use a > Novation Launch Control XL as a controller for various midi devices. > Now, I wanted to use it with non-mixer, and since mididings supports osc this > is > ok. Its interface is pretty basic, there's only a SendOSC function which > accepts > the destination address, the osc path and optional arguments. > My program creates a configuration file with mapping for every physical > controller, each of them has a different patch assigned; once the program is > loaded in "live" mode it creates a mididing configuration on the fly and runs > it. > When using non-mixer in standalone mode I can set a fixed port and I'm able to > send messages without any problem, since the controllers have their SendOSC > command with the "hardcoded" port number. > The problem comes when using non-mixer within a non-session, because > obviously I > cannot manually set the port number for clients. > I really tried and looked around for solution on how to communicate with the > non-mixer through nsm, but with no luck. > I even tried using the /nsm/server/broadcast using the format sf > "Non-Mixer.nKWUR/strip/Pianoteq/Gain/Mute" 1.0. > > The only way I can access the non-mixer is through its randomly created port, > which I can find in the log when adding non-midi-mapper to the session. But > this > is not practical, first of all because I'd have to change the port number in > the > configuration file every time non-mixer is started, and also because I'd need > to > add non-midi-mapper and sniff its log. > In case you were wandering, I cannot use the midi mapper with mididings, > because > I need to control other parameters which are not available to it (plugin > values). > I could try to create an OSC "router", using a fixed receiving port (but I > don't > know how to find the client port, a part from looking in the nsm log), but I > don't like this solution. > > Am I missing something? Does anybody here have any idea? I don't think you're missing anything. I believe to have hit the same wall in the past. How about not directly adding non-mixer to non-session-manager but a shell-script proxy (e.g. non-mixer-fixed) with your desired command line arguments? --- ~/bin/non-mixer-fixed--- #!/usr/bin/bash exec \ -a non-mixer-fixed \ non-mixer --osc-port 9090 $* ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] OSC direct communication with non-session-manager clients
Hello, I need to find a way to communicate via OSC with a non-session-manager client (non-mixer) by using a fixed port number. I'm developing a "midi proxy" based on mididings, which allows me to use a Novation Launch Control XL as a controller for various midi devices. Now, I wanted to use it with non-mixer, and since mididings supports osc this is ok. Its interface is pretty basic, there's only a SendOSC function which accepts the destination address, the osc path and optional arguments. My program creates a configuration file with mapping for every physical controller, each of them has a different patch assigned; once the program is loaded in "live" mode it creates a mididing configuration on the fly and runs it. When using non-mixer in standalone mode I can set a fixed port and I'm able to send messages without any problem, since the controllers have their SendOSC command with the "hardcoded" port number. The problem comes when using non-mixer within a non-session, because obviously I cannot manually set the port number for clients. I really tried and looked around for solution on how to communicate with the non-mixer through nsm, but with no luck. I even tried using the /nsm/server/broadcast using the format sf "Non-Mixer.nKWUR/strip/Pianoteq/Gain/Mute" 1.0. The only way I can access the non-mixer is through its randomly created port, which I can find in the log when adding non-midi-mapper to the session. But this is not practical, first of all because I'd have to change the port number in the configuration file every time non-mixer is started, and also because I'd need to add non-midi-mapper and sniff its log. In case you were wandering, I cannot use the midi mapper with mididings, because I need to control other parameters which are not available to it (plugin values). I could try to create an OSC "router", using a fixed receiving port (but I don't know how to find the client port, a part from looking in the nsm log), but I don't like this solution. Am I missing something? Does anybody here have any idea? Thank you in advance, Maurizio ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC vs LV2 atoms (was: [ANN] Qtractor 0.5.4 - Echo Victor shouts out!)
On Tue, 2012-03-06 at 14:07 +0100, Stefan Kersten wrote:
> On 05.03.12 21:50, David Robillard wrote:
[...]
> > I have been idly wondering if a round-trip OSC<=>Atom bridge would be
> > possible. Atoms are essentially primitives (int, float, string, etc)
> > with a few simple collections, all POD (vector, dictionary). You can
> > think of it as sort of a JSONish approach, but low-level rather than
> > text.
>
> it seems to be rather similar to bson [1] actually.
Interesting. I was unaware of this spec. Yes, very similar, though
Atoms have 64-bit alignment, and more extensibility (we use URID
integers for type rather than a byte).
Atoms also lack a real "dictionary", objects always have URID keys
because that 'meaningfulness' is very useful, and its fast. A
dictionary type with flexible keys could be added...
It would be nice if an existing spec could be used (I looked in to
protocol buffers as well), but none quite fit.
> > I wonder how one would express a dictionary in OSC?
[...]
> > /foo/adict {sssi} "name" "David" "id" 42
> >
> > =
> >
> > { "name": "David"
> > "id":42 }
>
> without the need for new types you could also "abuse" the bundle system, by
> interpreting bundles within the top-level bundle as dictionaries with messages
> as key/value pairs; this changed semantics would need to be explicitly
> supported
> by other applications, of course.
Sounds like maybe "Enables encoding of structured content by using
nested bundles" (from [2]) would facilitate this without have to kludge
the semantics.
> there's some talk about this in a thread on OSC 2.0 [2], but i couldn't find a
> draft document of the new protocol revision.
Interesting. Looks like they have the right goals. I am tempted to
follow this, but the very last thing I need is to be involved in yet
another spec :)
-dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] OSC vs LV2 atoms (was: [ANN] Qtractor 0.5.4 - Echo Victor shouts out!)
On 05.03.12 21:50, David Robillard wrote:
> On Mon, 2012-03-05 at 12:13 +0100, Stefan Kersten wrote:
>> On 3/5/12 2:16 AM, David Robillard wrote:
>>> I think a very simple stand-alone API to deal with OSC message would go
>>> a long way towards making OSC more feasible for plugins or Jack apps.
>>
>> there are at least two options: a header library i've been using in a
>> couple of projects [1] and oscpack [2]. both c++ though ...
>
> OSCPack uses the stream-style << abuse syntax, arguably (though not
> really) the most awful thing about C++.
it's probably an attempt to provide a nicer syntax for packet creation and i
can't say i dislike it - if c++ had first class functions it probably wouldn't
be necessary. anyway, it's only syntax, and as far as i can tell packet creation
and parsing is realtime safe in oscpack.
> OSCPP looks pretty good though. Basically a C++ey version of what I was
> talking about. Thanks for the pointers.
>
> The "require a size before constructing a message" thing sucks for
> certain cases of generic construction, however this might only be really
> much of an issue for bundles which don't have that problem, so maybe
> it's not such a big deal.
>
> I have been idly wondering if a round-trip OSC<=>Atom bridge would be
> possible. Atoms are essentially primitives (int, float, string, etc)
> with a few simple collections, all POD (vector, dictionary). You can
> think of it as sort of a JSONish approach, but low-level rather than
> text.
it seems to be rather similar to bson [1] actually.
> I wonder how one would express a dictionary in OSC?
>
> Assuming for the moment embracing and extending types is fine, there is
> one easy cop-out solution, make a type-tagged-blob type, the same as the
> normal one except it starts with a type int, but that's pretty opaque.
> Maybe something like [] for arrays? {kvkv...}, e.g.
>
> /foo/adict {sssi} "name" "David" "id" 42
>
> =
>
> { "name": "David"
> "id":42 }
without the need for new types you could also "abuse" the bundle system, by
interpreting bundles within the top-level bundle as dictionaries with messages
as key/value pairs; this changed semantics would need to be explicitly supported
by other applications, of course.
there's some talk about this in a thread on OSC 2.0 [2], but i couldn't find a
draft document of the new protocol revision.
[1] http://en.wikipedia.org/wiki/BSON
[2]
http://lists.create.ucsb.edu/pipermail/osc_dev/2011-November/thread.html#1964
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC sequencer idea (was: Qtractor 0.5.4 - Echo Victor shouts out!)
On 03/04/2012 10:44 PM, Stephen Sinclair wrote: It seems this debate is how to represent OSC messages in a sequencer. Hi Stephen, thanks for chiming in, so far I felt a bit like a lone voice in the wilderness. :) It's nice to see that there are others who see the need for this and are actually working on related software. Thanks also for the link to the MappingTools project, this looks very interesting. I'll have to give this a whirl asap, it looks like it will be very useful for some things I'm working on. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] OSC sequencer idea (was: Qtractor 0.5.4 - Echo Victor shouts out!)
It seems this debate is how to represent OSC messages in a sequencer. I've thought about this before, and the idea I always had in my head was something tracker-like, where you would assign columns (or rows..) to a message path, and specify whether the arguments are ints, floats, etc. For each argument the column would contain subcolumns with fields allowing editing of these values. Any row that is all "nil" would mean "do not send a message." The editor might allow a special column type called "note" which is represented on-screen as a note name (A#3 or whatever) but sends out the value as an integer or float. Alternatively the editor could be told the min/max values of the subcolumn and represent it as horizontal bars or a line plot, etc. I even started working on such a thing once, with the intention of controlling sequences for custom synths written in e.g. Chuck or PureData. However, I never got far with it as I had other things to do. In any case, in this paradigm, the user would define a patch in Pd (or) which accepts certain control or trigger messages, and therefore the sequencer would need to be told what messages to send it. No need to "standardize" the messages for any particular representation, since it would be different for each patch anyways. (The "sequence + patch" would be considered together as the music file.) What I like about this is that it would allow a user to use whatever program he/she wants for sound synthesis, but have keep a consistent sequencer interface. You could even use multiple back-ends for sound synthesis in the same track. p.s. thanks Jonathan for bringing up libmapper. For those who don't know, libmapper is an attempt to create a "glue" layer for OSC-supporting programs. Instead of standardizing on a set of messages, the idea is to instruct sending programs to translate their messages into the format required by the receiver, including any data transformation (scaling, etc). This allows programs to use any message names they want, keeping the usefulness of readable, program-specific semantic naming schemes, while still being able to connect to each other. Still under heavy development, but it's quite functional, web site is at http://libmapper.org Steve On Sun, Mar 4, 2012 at 4:27 PM, Albert Graef wrote: > On 03/04/2012 06:32 PM, David Robillard wrote: >> >> What do you mean by "pick the OSC addresses that I want"? > > > I mean those symbols with the slashes that are the first part of any atomic > OSC message like /foo/bar 4711.0. Usually such a symbol would denote the > particular control that the value applies to. When using OSC as input to or > output from automation, obviously I'd have to specify which OSC addresses I > want to be mapped to which automation parameter. > > However, I'd actually prefer a kind of separate OSC track which would be > connected to OSC inputs and outputs and listens for all OSC messages on its > OSC inputs, no matter what the addresses are. So (an ASCII representation > of) the contents of such a track might look like > > # delta OSC addr value > 0 /foo/bar 0.78 > 10 /reverb1/wet 0.3 > 5 /foo/bar 0.66 > etc. etc. > > By these means the OSC track would just record any messages that it receives > on its inputs, and I might then map them to the appropriate automation > parameters on other (audio and MIDI) tracks in the DAW, or just have them > played back via the OSC outputs assigned to the track, in order to drive > some other application like Pd. > > Dave, will you be at LAC in April? I'd really like to discuss this in more > detail with you, but it's much easier to do this in a room together and with > a whiteboard and a data projector within reach. ;-) If there's enough > interest, maybe we could do a "control beyond midi" brainstorming session at > LAC? Maybe Rui wants to join us there, and I know that some guys at CCRMA > are also interested in this. I guess that the organizers can allocate us a > time slot and a room with the necessary equipment if we just ask for it. > > Albert > > P.S.: Rui, apologies for hitchhiking your thread. I hope that you will > forgive me over a glass of good Californian wine. ;-) > > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de > WWW: http://www.musikinformatik.uni-mainz.de/ag > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC for syncing
Hi Victor, On 06/18/2010 11:35 AM, Victor Lazzarini wrote: > > a question for one of your OSC gurus out there: is it possible/a good > idea to use OSC for syncing? How good is it for that kind of thing? > So far I have only used it for parameter control, but is there a good > means of using it with timing accuracy? I can't pretend to be an OSC guru, but I've been thinking and working quite a lot on OSC and timing accuracy. "Syncing" can be many things, but I'll take an example: let's say that a step sequencer sends OSC messages to a sampler. The sequencer might send timestamped messages a bit before they ought to result in playback, to compensate message transport time, as well as latency and related issues on the sampler side. So sequencer sends a message at instant T-1 to tell the sampler to start playback at instant T. First a very practical consideration. If you use liblo, then you can't rely on the high-level API to receive timestamped messages, because it has its own message queues and will delay the message by itself. That forbids taking latency into account. I made a bug report about this: http://sourceforge.net/tracker/?func=detail&aid=2858774&group_id=116064&atid=673869 So you'll have to use the liblo lo-level API, which means extra work. Now, the clock issues. OSC timetags are absolute timestamps, so you need a reference clock. On a single system, that will be the system clock, and you will certainly use gettimeofday() (altough some might disagree about this). The problem is that the sound card has its own clock, so you're dealing with two clocks, which causes a variety of problems, as described by Fons in hi essay about Delay Locked loops: http://www.kokkinizita.net/papers/usingdll.pdf /Simplifying it/, those clocks do not run at the same speed, they drift. Plus, there's a jitter between soundcard hardware interrupts and the moment your (JACK or whatever) process callback gets called. It's not getting called as regularly that one would expect. To circumvent these issues, I have been working on libtimefilter (formerly libpendule), which is an implementation of Fons' proposal: http://code.google.com/p/libtimefilter/ Now, last but not least, almost all of these problems would become a souvenir, if JACK supported OSC ports, as it does for MIDI, and that of course both the sender and receiver use that. Hope that helps, -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] OSC for syncing
Hi everyone, a question for one of your OSC gurus out there: is it possible/a good idea to use OSC for syncing? How good is it for that kind of thing? So far I have only used it for parameter control, but is there a good means of using it with timing accuracy? Thanks a lot Victor ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC Practices
On 06/02/2010 12:51 AM, Paul Davis wrote: > On Tue, Jun 1, 2010 at 4:01 PM, Olivier Guilyardi wrote: > >> Whereas OSC just looks like a generic RPC mechanism, thus requiring some >> development knowledge or custom-made tools. > > this is exactly correct. > > there is no established way to send an OSC message to an arbitrary > receiver and reliably accomplish anything at all. there is no standard > message set to ask the receiver to play a note, stop playing a note. > ditto for transport control, and just about everything else you could > imagine. in short there are no standards. > > the only thing that does exist is a "meta-standard" to query the OSC > namespace, and arguably another meta-standard to get the current value > of any readable target within the namespace. This relates to I was just thinking about before reading your mail. I was telling myself that OSC is a bit like XML, which is a meta-language, thus a specification that allows to write languages. For example, RSS can be considered a such language. > as you have surmized, in its current state OSC cannot possibly be > considered as a replacement for MIDI as a generic communication > protocol for musical-related tasks. what it does to is to provide a > common transport mechanism and a standard namespace convention (the > lowly '/'), and the agreement to use text messages which makes adding > certain capabilities to a pair of receivers and transmitters just a > bit simpler than it otherwise would be. Well, maybe that it's not OSC that must evolve, just as XML is fine where it stands. But there could be a higher-level specification, (as RSS in my example), which programs and devices could choose to follow. I'm thinking about some quite open standard. Not something which is very strict, but certain rules, or better said recommendations, which try to bring some coherence into the OSC (audio) world. Some very simple primitives could be: 1. in/out symmetry, eg: send and receive from/to /path/volume %f 2. put "coordinates", such as track index in the path, not as a value 3. always use zero (or one, whatever) based indexes 4. maybe some range specification for level controls 5. some recommendation for encoding notes 6. etc... Anyway, before a such specification/standard exists, I suppose I have to look around, and draw my own conclusions.. Therefore, it's currently a matter of "practices".. So, if anyone who has a good knowledge of these can shred some light on the specific issues that I mention, I'll be glad to read about it. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC Practices
On Tue, Jun 1, 2010 at 4:01 PM, Olivier Guilyardi wrote: > Whereas OSC just looks like a generic RPC mechanism, thus requiring some > development knowledge or custom-made tools. this is exactly correct. there is no established way to send an OSC message to an arbitrary receiver and reliably accomplish anything at all. there is no standard message set to ask the receiver to play a note, stop playing a note. ditto for transport control, and just about everything else you could imagine. in short there are no standards. the only thing that does exist is a "meta-standard" to query the OSC namespace, and arguably another meta-standard to get the current value of any readable target within the namespace. as you have surmized, in its current state OSC cannot possibly be considered as a replacement for MIDI as a generic communication protocol for musical-related tasks. what it does to is to provide a common transport mechanism and a standard namespace convention (the lowly '/'), and the agreement to use text messages which makes adding certain capabilities to a pair of receivers and transmitters just a bit simpler than it otherwise would be. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC Practices
On 06/01/2010 09:55 PM, Will Light wrote: > It's interesting that you mention the Monome. There has been > discussion about how the OSC stuff is structured and there are a few > efforts to improve it. I went and dug up this thread: > http://www.vidvox.net/phpBB2/viewtopic.php?p=14786 . It talks about > how the Monome protocol is a bit non-standard and may provide a few of > the "best practices" that you're looking for. Thanks for this link. Indeed they seem to think about encoding the grid position into the path. dlublin says: "Right now the monome sends a list of arbitrary data to "/128/press" to describe a button at a physical location and its state. However, it would make a lot more sense if instead it would simply send a single value to "/128/press/x/y/", where the col and row information are encoded directly into a unique address path- this second method would work with even the most primitive implementation for receiving OSC values, without any need for an API." That makes sense to me. Nevertheless, they seem to be missing the in/out symmetry idea, which I find very interesting. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC Practices
To be honest, Ill agree with you there that the OSC details seem a little more vague (or "expandable"... whatever we call it). I found looking at what Ardour done to handle its OSC stuff useful, but im not sure that's the "PC" way to do it... Ardour guys..? On the other hand, because its so much more understandable to use, I could set up my own OSC message translator in minutes, while if I was trying to suss out MIDI CC's & Program changes, Id be pulling hair out of my head. That may be specific to me though, I'm don't have that much experience with Hardware MIDI stuff. In Response to Olivier's: > To be honest, I am very confused about the idea that OSC is some kind of > MIDI > successor. The MIDI protocol is a rather defined, with notes, CC, etc.. > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC Practices
On 06/01/2010 08:51 PM, Harry Van Haaren wrote: > Ill just say my 2 cents regarding point number 1: > > 1. the track order is reversed, the first track being at the bootom > > It seems that's the way with most physical controllers too, I've got an > Akai LPD8, > and "bottom-left" counts from pad 1, upwards. See the following image of > an Akai 16 pad: > http://www.jmsinfo.com/images/Akai_MPD18_MIDI_USB_Drumpad.jpg Okay, thanks for this info. > > I'm not sure how your program works internally as to what the best > solution is to > solving this problem. > > In my WIP project/ /I've used LibLO for OSC, and create a function in my > Sampler class which > takes an *int* parameter as for which pad to play. This seems a pretty > clean solution to me, > however as I say, I havent looked at your sources as to what's the best > implementation. Really, my question isn't about the implementation. I am asking about OSC protocol best design practices, in general. This is not Jackbeat specific at all to me. What about the in/out symmetry that I mentioned? Should the track position go into the path or be passed as a value? Should indexes be zero-based? Etc.. To be honest, I am very confused about the idea that OSC is some kind of MIDI successor. The MIDI protocol is a rather defined, with notes, CC, etc.. Whereas OSC just looks like a generic RPC mechanism, thus requiring some development knowledge or custom-made tools. -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC Practices
It's interesting that you mention the Monome. There has been discussion about how the OSC stuff is structured and there are a few efforts to improve it. I went and dug up this thread: http://www.vidvox.net/phpBB2/viewtopic.php?p=14786 . It talks about how the Monome protocol is a bit non-standard and may provide a few of the "best practices" that you're looking for. -w On Tue, Jun 1, 2010 at 5:27 AM, Olivier Guilyardi wrote: > Hi everyone, > > a Jackbeat user is currently trying to use TouchOSC, an iPhone app, as a > controller, and there is a need to translate in/out OSC messages. > > I have looked at TouchOSC messages, and the translation is nothing like > straightforward. There is a so-called BeatMachine[1] controller in TouchOSC, > which looks like a drum machine, but in the messages that it sends: > > 1. the track order is reversed, the first track being at the bootom > 2. the indexes are one-based in TouchOSC, and zero-based in Jackbeat > 3. the track/beat position is transmitted as a path element instead of a value > > The fact that some translation is needed between OSC units is quite normal to > me, but I would like to try and follow some wide-spread practices, if any, > maybe > refactoring the Jackbeat OSC dialect, to make such translation easier. > > I originally looked at some Monome messages docs[2], and that's the reason for > 2. and 3. above. The point 1. seems absolutely odd to me however. > > Now, there's another thing: currently Jackbeat features quite a few OSC > methods/commands but little OSC events[3]. This forbids using search an > external > controller as some kind of UI replacement. For instance, volume sliders can be > controlled, but no event is sent when they change. One of the reason for this > lack is that I was unsure about the right protocol to choose.. > > So, in TouchOSC, input and output messages seem to always be symmetrical, > which > looks like a clever and intuitive design to me. For instance, a slider both > sends and receives messages at /1/fader1 (example). And you just can't setup a > different prefix for in and out. > > Once again, this isn't the way Monome is doing it: it sends /40h/press, and > receives at /40h/led. > > So I'm a bit confused. What would be ideal is to follow some kind of practices > and/or standard, so that, in many cases, translation is only a matter of > changing OSC prefixes. And if that's not realistic, then I would like to avoid > some of the inconsistencies listed above with tools as TouchOSC and such. > > Is there any such standard or common/recommended practices? > > Cheers, > > [1] http://hexler.net/pub/touchosc/touchosc-manual-v1-1.pdf > [2] http://docs.monome.org/doku.php?id=tech:protocol:osc > [3] http://jackbeat.samalyse.org/wiki/BasicUsage#OSCInterface > > -- > Olivier > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC Practices
Ill just say my 2 cents regarding point number 1: 1. the track order is reversed, the first track being at the bootom It seems that's the way with most physical controllers too, I've got an Akai LPD8, and "bottom-left" counts from pad 1, upwards. See the following image of an Akai 16 pad: http://www.jmsinfo.com/images/Akai_MPD18_MIDI_USB_Drumpad.jpg I'm not sure how your program works internally as to what the best solution is to solving this problem. In my WIP project* *I've used LibLO for OSC, and create a function in my Sampler class which takes an *int* parameter as for which pad to play. This seems a pretty clean solution to me, however as I say, I havent looked at your sources as to what's the best implementation. HTH, -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] OSC Practices
Hi everyone, a Jackbeat user is currently trying to use TouchOSC, an iPhone app, as a controller, and there is a need to translate in/out OSC messages. I have looked at TouchOSC messages, and the translation is nothing like straightforward. There is a so-called BeatMachine[1] controller in TouchOSC, which looks like a drum machine, but in the messages that it sends: 1. the track order is reversed, the first track being at the bootom 2. the indexes are one-based in TouchOSC, and zero-based in Jackbeat 3. the track/beat position is transmitted as a path element instead of a value The fact that some translation is needed between OSC units is quite normal to me, but I would like to try and follow some wide-spread practices, if any, maybe refactoring the Jackbeat OSC dialect, to make such translation easier. I originally looked at some Monome messages docs[2], and that's the reason for 2. and 3. above. The point 1. seems absolutely odd to me however. Now, there's another thing: currently Jackbeat features quite a few OSC methods/commands but little OSC events[3]. This forbids using search an external controller as some kind of UI replacement. For instance, volume sliders can be controlled, but no event is sent when they change. One of the reason for this lack is that I was unsure about the right protocol to choose.. So, in TouchOSC, input and output messages seem to always be symmetrical, which looks like a clever and intuitive design to me. For instance, a slider both sends and receives messages at /1/fader1 (example). And you just can't setup a different prefix for in and out. Once again, this isn't the way Monome is doing it: it sends /40h/press, and receives at /40h/led. So I'm a bit confused. What would be ideal is to follow some kind of practices and/or standard, so that, in many cases, translation is only a matter of changing OSC prefixes. And if that's not realistic, then I would like to avoid some of the inconsistencies listed above with tools as TouchOSC and such. Is there any such standard or common/recommended practices? Cheers, [1] http://hexler.net/pub/touchosc/touchosc-manual-v1-1.pdf [2] http://docs.monome.org/doku.php?id=tech:protocol:osc [3] http://jackbeat.samalyse.org/wiki/BasicUsage#OSCInterface -- Olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC: Divide & Conquer, or build a Stronghold?
Greetings, I have no idea if this is useful: http://www.niallmoody.com/otherprograms.htm Check out Mouse2OSC. Niall's made some other nice software. He graciously updated Mouse2OSC so I could test it with Common Music/GRACE. I haven't got around to those tests yet, but I did check it out with AVSynthesis. It worked perfectly. Best, dp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] OSC: Divide & Conquer, or build a Stronghold?
On Fri, Dec 18, 2009 at 9:53 AM, nescivi wrote: > On Thursday 17 December 2009 18:41:31 Harry Van Haaren wrote: >> Hey all, >> >> I've been keeping myself busy lately, mostly with Python and OSC, >> and I'm using multiple clients/controllers to send messages to a >> sampler with an OSC interface. >> >> From this experience it seems to me a good idea, to have a kind of >> "central" >> >> place where all Audio programs "Announce" thier OSC port & program name & >> version, >> so the linux-audio-desktop can be a little more "coherent" for lack of a >> better word.. ;-) >> >> We could create a kind of "Master OSC Host" which would keep track of >> which clients are running, and which ports they are using. This would be >> easiest >> to do if EACH client, would "register" itself on an agreed port. >> >> So if a client wants to read some information, they could query the >> "Master OSC Host" with a standardised set of questions about the current >> state of QTractor/Ardour/. > > > I think the OSC protocol in and of itself is too general for this to make > sense on a global level. > > It seems you have already in mind a specific subset of kinds of data to > exchange between programs. > > > There have already been several approaches for this on specific topics. > > Such as the Digital Orchestra Toolkit Mapping tools, > http://idmil.org/software/mappingtools, for mapping data between digital > instruments/controllers, and software synths. There they define how to > announce your controller and how to announce your synth, and then you can > create arbitrary mappings. > > Personally, I have worked on an osc-based data-exchange framework for > exchanging data (such as sensor data, but basically any data) between > different collaborators, creating light, sound, video or other media with > their programs, that work on interactive performances or installations. > See http://sensestage.hexagram.ca > > In the WONDER software (http://swonder.sourceforge.net) we created a central > control host which transfers and translates OSC data between the different > components of the software. Some of that concept could be generalized for > programs to share any kind of osc messages with each other. > > There are also some attempts amongst livecoders to share clocks for playing > together... > > > To summarise, it could be an interesting project, but be aware that, since the > OSC standard is so open - in principle it doesn't even specify the method of > transport, though most often UDP (in most cases) or TCP/IP (fewer cases) is > used, but there are also implementations that use a serial port transmission > (very few cases) - (getting back to my sentence) and the implementation and > use of it in various programs varies a lot, some are only taking incoming > transmissions and don't send messages, if based on UDP and TCP/IP, some send > from a fixed port, some don't, some can listen to multicast messages, others > don't. You have to consider whether you want to require them to adhere to a > specific namespace, or whether you want to work with their existing > namespaces. > > That being said... a general purpose osc-mapping program could be really > useful... something you can put between two programs (one sending, one > receiving), that translates from one namespace to another, and possibly does > the required translations. Just to add... I am one of the contributors for the Digital Orchestra Toolkit (hi Marije!) and I am currently working on a C implementation, so this might be of interest once it's ready. (It's coming along well, should be public in January.. but I can make sources public sooner if there's any interest.) This solution is somewhat domain-specific, designed for creating arbitrary mappings between controllers (input devices) and synthesizers. So, not necessarily an answer to the proposal of this thread, but perhaps interesting nonetheless. Basically we found ourselves in a situation where we were making Max/MSP patches to read input from digital gestural controllers, usually by reading serial data from Arduinos, and we wished to perform signal condition and connect these values to inputs to sensors. We decided to try and design an approach which would _not_ require maintaining some kind of central database, and that would work across a network. So the Digital Orchestra Mapper as we'll call it is basically a set of standard messages which are communicated on a multicast port. Each device (either controller or synth) announces itself on this common bus, and then we made a Max/MSP GUI which can be used to assign connections between outputs and inputs for known devices. These connections may have arbitrary operations applied to them. From the controller's point of view it is simply outputting signals, but they pass through a "router" which converts these signals into different messages before actually sending them on the network. There is one router per connection, and the router is assigned to a specific d
Re: [LAD] OSC: Divide & Conquer, or build a Stronghold?
On Thursday 17 December 2009 18:41:31 Harry Van Haaren wrote: > Hey all, > > I've been keeping myself busy lately, mostly with Python and OSC, > and I'm using multiple clients/controllers to send messages to a > sampler with an OSC interface. > > From this experience it seems to me a good idea, to have a kind of > "central" > > place where all Audio programs "Announce" thier OSC port & program name & > version, > so the linux-audio-desktop can be a little more "coherent" for lack of a > better word.. ;-) > > We could create a kind of "Master OSC Host" which would keep track of > which clients are running, and which ports they are using. This would be > easiest > to do if EACH client, would "register" itself on an agreed port. > > So if a client wants to read some information, they could query the > "Master OSC Host" with a standardised set of questions about the current > state of QTractor/Ardour/. I think the OSC protocol in and of itself is too general for this to make sense on a global level. It seems you have already in mind a specific subset of kinds of data to exchange between programs. There have already been several approaches for this on specific topics. Such as the Digital Orchestra Toolkit Mapping tools, http://idmil.org/software/mappingtools, for mapping data between digital instruments/controllers, and software synths. There they define how to announce your controller and how to announce your synth, and then you can create arbitrary mappings. Personally, I have worked on an osc-based data-exchange framework for exchanging data (such as sensor data, but basically any data) between different collaborators, creating light, sound, video or other media with their programs, that work on interactive performances or installations. See http://sensestage.hexagram.ca In the WONDER software (http://swonder.sourceforge.net) we created a central control host which transfers and translates OSC data between the different components of the software. Some of that concept could be generalized for programs to share any kind of osc messages with each other. There are also some attempts amongst livecoders to share clocks for playing together... To summarise, it could be an interesting project, but be aware that, since the OSC standard is so open - in principle it doesn't even specify the method of transport, though most often UDP (in most cases) or TCP/IP (fewer cases) is used, but there are also implementations that use a serial port transmission (very few cases) - (getting back to my sentence) and the implementation and use of it in various programs varies a lot, some are only taking incoming transmissions and don't send messages, if based on UDP and TCP/IP, some send from a fixed port, some don't, some can listen to multicast messages, others don't. You have to consider whether you want to require them to adhere to a specific namespace, or whether you want to work with their existing namespaces. That being said... a general purpose osc-mapping program could be really useful... something you can put between two programs (one sending, one receiving), that translates from one namespace to another, and possibly does the required translations. sincerely, Marije ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] OSC: Divide & Conquer, or build a Stronghold?
Harry, > From this experience it seems to me a good idea, to have a kind of "central" > place where all Audio programs "Announce" thier OSC port & program name > & version, > so the linux-audio-desktop can be a little more "coherent" for lack of a > better word.. ;-) You want service discovery. There is already something out there that does that, it's called DNS-SD - and it is probably already running on your system :) Flo -- Machines can do the work, so people have time to think. public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] OSC: Divide & Conquer, or build a Stronghold?
On Thu, Dec 17, 2009 at 6:41 PM, Harry Van Haaren wrote: > This would mean that any program that wants to find out which Jack B:B:T or > Frame were on > or if there's been XRuns, wouldnt have to be a JACK client, because its been > abstracted to > the "Master OSC Host". i don't many comments on this overall idea, but i do find the notion that a program wants to know about the internal state of JACK without being a JACK client, and yet, unlike a simple shell script, is willing to participate in a 2 way IPC protocol to find out a little odd. also, please keep in mind that the basic semantics of OSC make query:response interactions really rather tricky to implement in a robust way. meaning that they will work in 98% of cases, and the other 2% will just either unfathomable and/or unfixable. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] OSC: Divide & Conquer, or build a Stronghold?
Hey all, I've been keeping myself busy lately, mostly with Python and OSC, and I'm using multiple clients/controllers to send messages to a sampler with an OSC interface. >From this experience it seems to me a good idea, to have a kind of "central" place where all Audio programs "Announce" thier OSC port & program name & version, so the linux-audio-desktop can be a little more "coherent" for lack of a better word.. ;-) We could create a kind of "Master OSC Host" which would keep track of which clients are running, and which ports they are using. This would be easiest to do if EACH client, would "register" itself on an agreed port. So if a client wants to read some information, they could query the "Master OSC Host" with a standardised set of questions about the current state of QTractor/Ardour/. This would mean that any program that wants to find out which Jack B:B:T or Frame were on or if there's been XRuns, wouldnt have to be a JACK client, because its been abstracted to the "Master OSC Host". I think this method would allow better inter program operability, as any "useful" information that one program could share, other could read. This would be most effective, if we also requested that programs followed a specific naming convention for features that each program has. EG: Save : //save_state Load: //load_state etc I'd like to get the communities feelings towards an initiative like this, feedback/criticism/opinions welcomed! -Harry Haaren ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
