On 27/04/21 7:30 pm, Peter P. wrote: Yes some Behringer mixers.  That is a "no, OSC is not much of a thing"? W -- If not me then who? If not now then when? If not here then where? So, here I stand, I can do no other root(a)worik.org 021-1680650, (03) 4821804 Aotearoa (New Zealand)

On Tue, 27 Apr 2021, Jörn Nettingsmeier wrote: ... This caught my eye... hoping that "generic OSC" might be some standard for what controls should be called. But no. The biggest strength of OSC is that it can do anything... but that is also it's biggest weakness. There are many control applications that could benefit from standardized messages but every DAW and controller requires setting up a control map to fit the two together. Cool, this is much better than OSC for the X32 mixers. The OSC for X32 mixers pointed out some of the short comings of OSC over UDP: - each channel had a list of parameters in each OSC message. And these parameters had no relationship to each other aside from belonging to the same channel. - The meters were all grouped into one or two messages so the controller had to separate all the meter data and just know from it's possition in the parameter stream which one it was. This of course took away most of OSC's "built in" readability. I think this was because UDP starts to loose messages very quickly after 100 or messages at a time. This would normally not seem like a problem but when you consider that any one strip (I prefer strip to channel) may have over 100 parameters that may be transfered at once in the case of banking or a scene change. Some thing I have fought with on OSC control for Ardour. I have had to add a very small delay with each message to make things work. The Wing with TCP would not need this... but of course some OSC libs do not support TCP because OSC 1.0 is UDP and OSC 1.0 never got past OSC 1.0 due to lack of funding. There was work started on OSC 1.1 but it was never formalized and the documentation has vanished from the OSC site. This means no bundles, no TCP, no # or ? just / and so many OSC controllers are OSC 1.0 only. The Wing on the other hand is doing what I have started to do with Ardour (while leaving the old methods alone). /strip/number/send/number/control type value (ei. /strip/5/send/3/pan_azimuth f 0.75 ) Except they use /ch/5/fdr f .782 The Wing is also using the same query mechanisim I have started to implement in Ardour: send /strip/3/fader to ardour and it will replay with /strip/3/fader f .782 (it may also send /strip/3/gain f 0 if the feedback is set that way) send /strip for a list of strips send /strip/2 for a list of controls with value for that strip etc. The problem with /ch is that a strip if stereo has two channels and if MIDI has 16 channels and if a VCA has none and yet they are all handled the same way with similar controls. So much for using /ch as a standard. Anyway, a standard for mixer strip controls would be very nice... and of course mine is the best :) Actually, if there was a standard that made any kind of sense (or maybe even not), that was supported by a real physical hardware OSC controller or two, it would be enough to make it worth supporting. -- Len Ovens www.ovenwerks.net

On Wed, 28 Apr 2021 14:00:35 +0200 Jörn Nettingsmeier <nettings(a)stackingdwarves.net> wrote: Obligatory... https://xkcd.com/927/ -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

Le 2021-04-28 à 10 h 22, Fons Adriaensen a écrit : From the 1.1 paper (https://cnmat.berkeley.edu/publications/features-and-future-open-sound-cont…) : "This new specification enormously expands the range of protocols and hardware transports that can be used to communicate OSC encoded packets including Firewire, Ethernet, and USB (using TCP/IP); RS232 and RS422 and Serial USB and Serial Bluetooth and Serial Zigbee" So it looks like using SLIP is a compromise. Maybe the method you mentionned for TCP could be added, but the overhead of SLIP seems to add only 4 bytes (32 bits): https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol (disclaimer: I'm not a network specialist) Marc

True that OSC, because it is unsecure, it must be encapsulated with encrypted protocols (if required). For creative use cases on web sites (or single page apps), WebSocket (or WebRTC) is used to transmit (and receive) OSC though proxies, so there could be a considerable overhead. Despite its ambition to run on any type of network, OSC is being used mostly with UDP on reliable local networks, with some risks of loosing packets (so error correction is left as an exercise, or simply ignored). And it's not clear if the 1.1 spec is even used... Marc Le 2021-04-28 à 11 h 16, Fons Adriaensen a écrit :

Am Mittwoch, 28. April 2021, 18:07:51 CEST schrieb Len Ovens: @Lens: Do you have any reference where it is stated or referenced that "OSC 1.0 is UDP" ? I always assumed OSC 1.0 can be used over any transport, mostly I use TCP/IP, sometimes serial, so it would be good to know where this stated to argue that and why OSC 1.0 is only UDP ? I know UDP is easy: "one message - one packet", but that does not exclude the others. mfg winfried -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171

On Fri, Apr 30, 2021 at 11:10 AM Fons Adriaensen <fons(a)linuxaudio.org> wrote: I do have some experience with open source JSON decoders over HTTP, which handles state while reading the stream. I do notice the Behringer Wing uses JSON for its OSC implementation. Still, I also work a lot with udp for high volume applications and despite its shortcomings I would choose udp over MIDI if I had a choice. I get frustrated with midi often due to lack of universal MTC/MMC and note mappings support and moved into control voltage sequencing when my synths can do it ... ARP 2600 and Korg MS20M for example. Robert

On Fri, Apr 30, 2021 at 12:26 PM Paul Davis <paul(a)linuxaudiosystems.com> wrote: Going forward, I have more hope in OSC support in hardware compared to MMC/MTC. If each OSC server defines its own payload format, for example, it's still an improvement as I see it compared to a midi device that has nothing but midi clock to sync on (all my gear). The only hardware recorder I know of that supports MMC/MTC is the Joeco blackbox. The only new hardware sequencer that supports MMC/MTC is the Cirklon - with a 1 year waiting list. Using my Korg Oasys to send midi note data to my Jomox 999 drum machine, for example, requires me to implement my own code with a note_map_t, With control voltage for 1 volt per octave pitch and zero to +5VDC for gate on/off, every analog piece of gear I own supports it. Every analog sequencer will accept and send the same gate signal or can be adjusted to do so. I am just saying that OSC is another option where nothing else is available, to complement midi and CV - not replace it.

On Fri, 30 Apr 2021 17:25:18 -0600 Paul Davis <paul(a)linuxaudiosystems.com> wrote: From my point of view, the greatest weakness of OSC is that (as far as I can tell) it has no default set of common controls, so everything has to start from scratch - both ends. What made the original MIDI implementation so popular was, (for its time) a very full and useful set of such control messages, as well as the ability to then define specialist ones as well. To some degree they've kept this with MIDI 2, in that there is a fall-back to MIDI 1 if a negotiation is not achieved. -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

Am Freitag, 30. April 2021, 23:10:32 CEST schrieb Fons Adriaensen: Thank Fons I agree with you , that is why there are OSC-Bundles with Timestamps, correcting the timing, at least the jitter and if using it for continuous streams mostly an index for messages are included, in case something get lost, Jitter is best described "Best Practices OSC" [1] - best practices OSC http://lac.linuxaudio.org/2010/papers/37.pdf And just to get sure, since I pretend to teach it and want to spread no wrong information: Please disagree if you can reference: - OSC 1.0 ist not only UPD - OSC was not a intended to replace MIDI, but to use it in multidimensional musical parameter transmission, like the 3D-Postion of a violin bow.... - OSC predecessor was ZIPI not MIDI see https://web.archive.org/web/20070609125702/http://www.cnmat.berkeley.edu/ ZIPI/ (see: what next ?) BTW.: There has been an interesting paper with critics to OSC from Computermusic scientists: - https://www.cs.cmu.edu/~rbd/papers/o2-web.pdf mfG winfried [1] best practices OSC http://lac.linuxaudio.org/2010/papers/37.pdf [2] https://web.archive.org/web/20070609125702/http://www.cnmat.berkeley.edu/ ZIPI/ [3] https://www.cs.cmu.edu/~rbd/papers/o2-web.pdf -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171

Le 2021-05-02 à 20 h 48, Marc Lavallée a écrit : Oops, I meant "lossless audio streams"... Marc

Le 2021-05-03 à 15 h 05, Winfried Ritsch a écrit : There's an interesting hack to support sample-accurate OSC via Jack: https://github.com/ventosus/jack_osc Marc

Am Montag, 3. Mai 2021, 11:48:07 CEST schrieb Fons Adriaensen: true On the other side, with the type tags, you know when a message is complete if you wait for number of bytes or the the type ends(, if no bytes got lost...) The problem of UDP: UDP applications must be willing to accept some packet loss or this has to be handled by the protocol implemented with OSC. and/or it should be a "stateless" protocol. So if package loss is a problem, think of a mute action TCP/IP is more easy to handle, since we know when a connection is lost. So maybe its better to do stream parsing and a stream protocol than UDP and some handshake or failsave protocol, but of course this depends on the use case, so on a sound system critical mixer I prefer TCP/IP. mfg winfried -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171

On Mon, May 03, 2021 at 09:39:15PM +0200, Winfried Ritsch wrote: Of course the simple solution if you have a 'stream of bytes' transport is to add a 32-bit int prefix to each message, giving its length. The you wait for 4 bytes, decode to L, wait for L bytes, and you have a complete message. Ciao, -- FA

On Fri, Apr 30, 2021 at 11:50 AM worik <root(a)worik.org> wrote: No need for inserts or aux sends I suppose for your workflow. For my "live in the studio" video workflow for a trio, I record every channel with compression and effects, then hand over the wav file to a mastering engineer. The Speck Xtramix V6 is new and has 20 stereo channels but is expensive and has no digital connectivity. You can see my work in action here. https://www.youtube.com/user/robertlazarski/videos?sort=dd&shelf_id=0&a… I suggest deciding what you want to accomplish with a mixer - Live sound or post production. A lot of what you are asking about makes sense only in post, and often only a mastering engineer. > The background is we have a set of amplifiers we use for community gigs > here in Ōtepoti, New Zealand. The missing piece is a decent mixer. > In this thread there have been some interesting things, a bit > overwhelming... > * Dante This is used to connect gear over long distances, other rooms etc - up to 100 meters. It is a proprietary protocol that started about 20 years ago. > * I am a beginner but I think MIDI and OSC are for different things Some parts of MIDI can be accomplished by OSC, for example Midi Machine Control of start/stop in Ardour can be also done with oscsend. My uses of OSC are more for machine control, not for music note and timing info and TBH I prefer control voltage instead of midi due to its simplicity, flexibility and lack of latency. My primary motivation in Linux audio is automation during live performances using LTC timestamps - but that is a rabbit hole I don't recommend. > * LTC LTC is the core of my workflow but only makes sense if you are doing video. It's perhaps the oldest audio standard - invented in the 60's. It's simply an audio signal with square waves that defines a 24 hour period timestamp. It's well supported in open source. Budget gear like Zoom have embraced it, so I feel I am on safe ground going forward. > * MTC LTC encoded as MIDI. Some people use it in post production for overdubs. DAW's support it. The whole MPC drum machine line supports it to varying degrees. The Tascam 16 mixer supports it. > * MMC Some midi devices such as external sequencers require midi clock to start/stop, while instead most DAW's use MMC. > * OSC in JSON Not sure who supports this together in open source besides the Behringer Wing. JSON is an open format that largely superseded XML and is used over networks. OSC is used over udp. > * "Rendering Engine" - Sara/DS100. Not sure what this is... Looks like > more than we need, opening up possibilities we have not thought of Never heard of it. * Monome Norns, PedalinoMini, Step Audio, Lawo, You need to code in Lua to get the most out of Monome Norns, it's more of an open source synth and effects engine. PedalinoMini is a DIY project that combines OSC and midi. Step Audio is a pedal company that sends most midi features - my fallback plan in case Linux audio hits a snag for me. I am not familiar with Lawo. Robert > Awesome! > Worik > -- If not me then who? If not now then when? If not here then where? So, > here I stand, I can do no other root(a)worik.org 021-1680650, (03) 4821804 > Aotearoa (New Zealand) > -- > If not me then who? If not now then when? If not here then where? > So, here I stand, I can do no other > root(a)worik.org 021-1680650, (03) 4821804 Aotearoa (New Zealand) > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user(a)lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-user

On 1/05/21 2:32 pm, worik wrote: Sigh. Less than five minutes after I send that I find: https://codeblog.jonskeet.uk/2021/01/27/osc-mixer-control-in-c/ It says: Very encouraging. Worik -- If not me then who? If not now then when? If not here then where? So, here I stand, I can do no other root(a)worik.org 021-1680650, (03) 4821804 Aotearoa (New Zealand)

According to pictures I saw, it has knobs and sliders. On April 30, 2021 4:48:15 PM HST, Bob van der Poel <bob(a)mellowood.ca> wrote: --- David W. Jones gnome(a)hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com Sent from my Android device with F/LOSS K-9 Mail.

On Sat, 01 May 2021 11:49:40 +0200 David Kastrup <dak(a)gnu.org> wrote: I have a BCF2000, it's proved to be very reliable. Also you can set it up with the control knobs themselves, so although it's a bit involved, unlike a lot of other kit these days it is NOT tied to software. -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Sat, 1 May 2021, Bill Purvis wrote: Digital Mixer: The inputs (after preamp) directly feed an ADC, all mixing is done in DSP, outputs are a DAC feeding an analog driver. The digital mixer may have phyiscal or glass controls. There are a lot of digital mixers around (maybe more than analog?) but in the case of the 'X' series, they are all digital mixers, the X32 has a mix of physical knobs with some glass controls and the x32 rack, x18, x16, etc are all glass controls. So far as I know, they do use OSC for remote control... or at least offer some data on it: https://behringerwiki.musictribe.com/index.php?title=OSC_Remote_Protocol There used to be a pdf which is probably around if you search. The X-air mixewrs also use OSC for control which are similar but not the same... or maybe only a subset works (I have never played with them). There are some utilities on github, sf and google for sending/receiving OSC for these devices or just examining the traffic. Behringer has Linux utilities for controlling these mixers remotely for free download and I expect wireshark can teach you anything you wish to know about the OSC that the above link does not provide. All of the X mixers are meant to be remote controlled from a tablet (Mac or Android) and so those apps can be installed from the usual places. -- Len Ovens www.ovenwerks.net

Well, could be my old-guy's vision or that we're looking at different pictures ... but, I was looking at: https://www.behringer.com/product.html?modelCode=P0BI8 And I see no knobs ... well, there might be a master volume or on/off, but there don't appear to be individual pots for the different channels. On Sat, May 1, 2021 at 12:34 AM David W. Jones <gnome(a)hawaii.rr.com> wrote: -- **** Listen to my FREE CD at http://www.mellowood.ca/music/cedars **** Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: bob(a)mellowood.ca WWW: http://www.mellowood.ca

"David W. Jones" <gnome(a)hawaii.rr.com> writes: mixing and IIR-based filtering after the immediate A/D conversion stage _without_ digital antialiasing filtering and downsampling and skip the respective inverse stages for D/A conversion. That could cut down on conversion delay and phase artifacts. Whether this is actually done, I am skeptical: high-quality A/D converters have the filtering and downsampling stuff integrated and I doubt that they have a fast unfiltered parallel high-rate side-channel available. Here too, "This is based solely on my thoughts, no evidence. I've never worked with a digital mixer." is applicable. -- David Kastrup