[LAD] [ANN] Non DAW and Non Mixer 1.1.0 (now with NSM)
Greetings, I'm pleased to announce the release of Non-DAW and Non-Mixer version 1.1.0. It's been a while since the last release. But, I assure you, the project is still alive and well. This release includes a number of fixes and some minor improvements to the build system. The big changes are: * Enhancements to the spatialization controls (which are automatically provided for Ambisonics plugins). * Support for the Non Session Manager. * Enhancements to Control Sequences, OSC control signals can be sent from Non-DAW to Non-Mixer. These connections will be preserved in the session. * Non-Mixer accepts input for all Module/Plugin controls via OSC. * Non-Mixer can now import and export individual strips (including the chain of modules and all their parameters!) This allows a workflow on a higher level than presets. * Updated visual styles for both Non-Mixer and Non-DAW. The 'Flat' style has been greatly improved. * New knob styles for Non-Mixer and knob style is a configuration option rather than requiring editing the source. * New icons in an assortment of sizes. Additionally, Non now supports a robust new session management protocol called NSM. A session management daemon is provided along with a graphical interface called Non-Session-Manager. NSM represents a significant leap forward for session management in Linux audio. :: History of NSM Way back in 2008, I became frustrated with the state of the art of session management on Linux (a situation which has improved only incrementally since that time). I ditched support for LASH, wrote a lengthy post about Non-DAW's session management requirements to the LAD mailing list, and started managing my sessions with shell scripts and jack_snapshot. This eventually evolved into a session manager written in Unix shell and using Unix FIFOs and regular files for client control/communication. This system of session management was tentatively called NASH (Non Audio Session Handler) and was never released. In 2010, shortly after the release of Non-Mixer, I devised a prototype version of the NSM OSC API and have been using it, still unreleased and in prototype form, since then. The 2010 implementation did not have a user interface and was controlled via shell scripts using the `send_osc` command included in the distribution. Then, in 2012 (4 years later!), I was contacted by an enthusiastic power-user regarding implementing OSC support in Non-Mixer. Since NSM uses OSC for server<->client communication, I already had much of the OSC work done and figured I might as well release it--and, while I was at it, NSM. I then endeavored to simplify and document the NSM API, discussing it at length with, and taking many suggestions from, Nedko Arnaudov, the LADISH author. After implementing the Non-Session-Manager FLTK GUI to control the session management daemon, a new release became inevitable. :: Bullet Points for NSM: * Extremely fast and responsive control mechanism and user interface. * The only dependency for clients and server is an OSC library (I use liblo). * Smart clients are able to switch projects without restarting. * Clients can provide real-time status feedback to the server, and therefor the user. * The server stores all session data in per-session directories under a configurable session root. * Clients are forbidden to save or open files outside of the per-session directory. * The server provides simple template support in the form of whole-session duplication. * The Session management daemon is fully controllable via OSC. * Strict user interface guidelines for a uniform and predictable experience. * The abstract session management API has no architectural requirement for JACK, Xorg or any other subsystem (other than UDP networking). This means that both headless daemons and programs which are not JACK clients can be managed together in the same session. * A single session can be distributed across multiple machines on a network. * Multiple, independent, sessions can be opened on one machine at the same time. :: More About the NSM API The latest NSM API documentation can be found at: http://non.tuxfamily.org/nsm/API.html NSM is included in the Non-DAW/Non-Mixer repository. :: Ongoing and Future Development Features that are in development for future releases include an auto-learning and graphically re-mappable JACK MIDI<->OSC gateway program tentatively named Non-OSC-MIDI-Mapper, which will simplify the connection of bidirectional control surfaces such as the BCF2000 to Non-Mixer. This program relies on Non's generic Control Signal layer on top of OSC. So it's not necessarily generally useful (although, in the future, it may be possible to use the `libmapper` library to provide the same functionality in a somewhat standard way). LV2 support is a frequently asked question. For various reasons, I currently have no plans to host LV2 plugins in Non-Mixer. But if anyone can come up with a compelling a
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 07:36 AM, Albert Graef wrote: I don't see why an OSC track should make any assumptions about the semantics of OSC messages. For optimized representation and editing. Avoiding artificial restrictions can give you both freedom and clumsiness ;) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On Sat, 2012-03-03 at 07:36 +0100, Albert Graef wrote: > On 03/03/2012 06:50 AM, David Robillard wrote: > > There is also the chicken& egg problem, last I checked there wasn't an > > OSC note standard in use anywhere to have Ardour send... > > I don't see why an OSC track should make any assumptions about the > semantics of OSC messages. It should just treat it as control data and > allow to record it from an OSC client (which might also be an LV2 plugin > which produces OSC messages), edit it, and play it back to another OSC > server (or LV2 plugin which consumes OSC messages). Hm? How would a sequencer display or edit OSC data without even knowing how to represent a note or a control? Sure, you could just implement dumb raw OSC recording and playback, but there's little point in using a DAW for that (not to mention little practical musical use) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 08:25 PM, David Robillard wrote: Sure, you could just implement dumb raw OSC recording and playback, but there's little point in using a DAW for that (not to mention little practical musical use) But that's exactly what I want. For starters, even just simple messages consisting of address and POD (like a double value) would be useful. The data might originally be generated with a multitouch OSC device, say, and would be recorded by the DAW, which would also let me play back the data, sending it either to an OSC-capable plugin or an external OSC application (Pd, say) which would know what to do with it. Call it automation, if you want. But I think of it as sequencing of OSC messages; I need the data to be on its own track where I can edit, cut, copy and move it around as needed. DAW and sequencer programs are good at these things; that's what they are for. And no, I don't want to use MIDI instead, where I have to cram everything into control changes or (N)RPNS and loose both resolution and the descriptive OSC addresses. I don't know if it's of practical use for anyone else, but time and again I would have had good use for this apparently simple feature. If anyone knows a sequencer or DAW which can do what I sketched out above, please do tell me. OSC has been around since 1997, for crying out loud. It's about time that sequencers do more with it than just automatizing the transport controls. ;-) 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
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On Sat, Mar 3, 2012 at 5:20 PM, Albert Graef wrote: > On 03/03/2012 08:25 PM, David Robillard wrote: >> >> Sure, you could just implement dumb raw OSC recording and playback, but >> there's little point in using a DAW for that (not to mention little >> practical musical use) > > > But that's exactly what I want. For starters, even just simple messages > consisting of address and POD (like a double value) would be useful. The > data might originally be generated with a multitouch OSC device, say, and > would be recorded by the DAW, which would also let me play back the data, > sending it either to an OSC-capable plugin or an external OSC application this general language is the whole problem. you can't send OSC to "an OSC capable plugin" or "an external OSC application" in any generalized sense, because there is no shared format for the messages. the sequence of messages that you record may make sense to Pure Data, but make absolutely no sense to, say, CSound. the motivation to develop the infrastructure for recording, playback, disk storage and editing of such messages is not very strong when any given sequence can only target one particular OSC receiver. the motivation isn't zero, to be clear. but it just isn't that strong. > I don't know if it's of practical use for anyone else, but time and again I > would have had good use for this apparently simple feature. If anyone knows > a sequencer or DAW which can do what I sketched out above, please do tell > me. OSC has been around since 1997, for crying out loud. It's about time > that sequencers do more with it than just automatizing the transport > controls. ;-) then its about time that people using OSC start defining some standardized messages. MIDI did this from the start, and for all of its limitations, its been a wild success. the OSC community has self-consciously avoided doing this - lets queue up another pointless argument about how to represent notes/frequencies/intervals - and as a result is still only a niche protocol with every transmitter and receiver defining their own messages. double fail ... > > > 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 11:20 PM, Albert Graef wrote: > On 03/03/2012 08:25 PM, David Robillard wrote: >> Sure, you could just implement dumb raw OSC recording and playback, but >> there's little point in using a DAW for that (not to mention little >> practical musical use) > > But that's exactly what I want. For starters, even just simple messages > consisting of address and POD (like a double value) would be useful. The > data might originally be generated with a multitouch OSC device, say, > and would be recorded by the DAW, which would also let me play back the > data, sending it either to an OSC-capable plugin or an external OSC > application (Pd, say) which would know what to do with it. Call it > automation, if you want. But I think of it as sequencing of OSC > messages; I need the data to be on its own track where I can edit, cut, > copy and move it around as needed. DAW and sequencer programs are good > at these things; that's what they are for. And no, I don't want to use > MIDI instead, where I have to cram everything into control changes or > (N)RPNS and loose both resolution and the descriptive OSC addresses. > > I don't know if it's of practical use for anyone else, but time and > again I would have had good use for this apparently simple feature. If > anyone knows a sequencer or DAW which can do what I sketched out above, > please do tell me. OSC has been around since 1997, for crying out loud. > It's about time that sequencers do more with it than just automatizing > the transport controls. ;-) > > Albert > Hi Albert, I use Algoscore for sequencing OSC. http://kymatica.com/Software/AlgoScore There was a presentation at Piksel a few years back about this one: https://github.com/sentinelweb/TimeLine-OSC and http://www.iannix.org/ may do the job as well. ..but neither aims for, or comes close to "DAW" functionality. robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 11:29 PM, Paul Davis wrote: you can't send OSC to "an OSC capable plugin" or "an external OSC application" in any generalized sense, because there is no shared format for the messages. Yes, there is. It's the OSC format itself. If you want to keep it simple, you could boil it down to "atomic" OSC messages (i.e., POD payload, no bundles). If you can support that in a DAW, I'm sure that there will be plenty of applications which can make good use of this. (Actually just simple pairs of OSC addresses and double values would be good enough for a lot of stuff IMHO.) then its about time that people using OSC start defining some standardized messages. Well, what you see as a problem, I see as a virtue. It gives me the flexibility to just pick my own set of messages for the application at hand. The sequencer shouldn't have to care about the particular set of OSC addresses I'm using. MIDI did this from the start, and for all of its limitations, its been a wild success. Nobody argues that, certainly not me. For much stuff we do, MIDI is quite adequate. But there's also the more advanced stuff where OSC is better suited or maybe just more convenient. That's certainly the case if you're using an OSC device like the Lemur, or if you're building a dsp plugin with Faust and don't want to go through the tedium of handpicking MIDI controller assignments. Anyway, Paul, I understand that you have plenty of other important stuff on your TODO list for Ardour3. I'm not complaining. The reason that I brought up Ardour in this context was that I seem to recall reading something on the Ardour website, about Ardour3 already having the right infrastructure which would make it easy to add some kind of OSC tracks. Maybe I've misread that remark, though. 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
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 11:36 PM, Robin Gareus wrote: I use Algoscore for sequencing OSC. http://kymatica.com/Software/AlgoScore Hi Robin, thanks for the pointers. Yes I know about AlgoScore and Iannix, but that's not quite what I had in mind. There was a presentation at Piksel a few years back about this one: https://github.com/sentinelweb/TimeLine-OSC Interesting, I don't remember seeing this. Unfortunately, the original website is down and the video on vimeo has lousy sound, but I'll have to see whether I can get this up and running. ..but neither aims for, or comes close to "DAW" functionality. Alas. Maybe I'm a bit old-fashioned, but for recording and playing back stuff on a timeline, nothing beats a DAW-like interface for me. :) 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
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On Sat, 2012-03-03 at 23:20 +0100, Albert Graef wrote: > On 03/03/2012 08:25 PM, David Robillard wrote: > > Sure, you could just implement dumb raw OSC recording and playback, but > > there's little point in using a DAW for that (not to mention little > > practical musical use) > > But that's exactly what I want. For starters, even just simple messages > consisting of address and POD (like a double value) would be useful. The > data might originally be generated with a multitouch OSC device, say, > and would be recorded by the DAW, which would also let me play back the > data I suppose this would be useful in some limited sense. However, I doubt Ardour ever will, nor do I think it even should, support sequencing of events that are transmitted by some mechanism other than Jack. That would be a gigantic inconsistent mess for more reasons than I feel like listing, and trying to use UDP or whatever directly in a DAW raises a very large number of very deep questions for no benefit (hell, anti-benefit, Jack rules). Integration with IP based OSC transport should happen via a separate Jack program. Put in other terms, I think Ardour should support "OSC Messages". Not OSC in UDP/TCP/IP. If the community solves Jack OSC, it will get Ardour OSC pretty quickly. However, I am kind of through with OSC personally, so I don't intend to put any real effort into the Jack side of that problem. > OSC has been around since 1997, for crying out loud. > It's about time that sequencers do more with it than just automatizing > the transport controls. ;-) As Paul pointed out in his response, the reason for this lack is that OSC simply doesn't do what 99.% of the people who use a sequencer want to do. Blindly recording events with no editing or display ability simply isn't that useful, and certainly doesn't constitute a MIDI replacement. That said, it's not like a note standard would actually be difficult. It will (well, may) get actually made when someone actually needs it. Since we live in a somewhat closed and more flexible world, the Jack universe could be the place where that happens. I doubt it will elsewhere, the commercial guys have gone with custom incompatible USB protocols for hardware, and simply don't care about software interop. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On Sun, 2012-03-04 at 00:55 +0100, Albert Graef wrote: [...] > Anyway, Paul, I understand that you have plenty of other important stuff > on your TODO list for Ardour3. I'm not complaining. The reason that I > brought up Ardour in this context was that I seem to recall reading > something on the Ardour website, about Ardour3 already having the right > infrastructure which would make it easy to add some kind of OSC tracks. > Maybe I've misread that remark, though. I probably said this. Internally it's like Jack in most of the important places, i.e. the actual type of the event payload is pretty much irrelevant. The biggest problem to solve is the on-disk format. Control data (i.e. "automation") in Ardour is its own thing, not even really MIDI related. I co-opted the existing automation system as much as possible deliberately for this reason. It could be made to *send* OSC messages for curves pretty easily. It would be nice if this integrated with stuff in the plugin sphere, but I've come to the conclusion that, unfortunately, OSC is more trouble than it's worth there (though nothing is stopping anyone from using it). After countless attempts at achieving a decent more-powerful-than-MIDI mechanism, I've come to this opinion: Give me a simple data model based on primitives, lists, and dictionaries any day over some clunky command-like message format. To me, the easy integration that gives you (with e.g. the dictionary built in to pretty much every programming language ever, Turtle, JSON (and thus webby everything), key:value stores), the 'meaningfulness', a standard string serialisation, and an easy ability to describe arbitrarily complex things via nesting, is of infinitely more value than integrating with the tiny nichey collection of things that support OSC. Maybe it's just that I've tried to do some pretty advanced things on top of OSC (like 100% of GUI<=>engine control), but it's just a little too half-assed for my tastes these days. That said, I'm fully behind anything that would provide the individual note control and high controller precision that MIDI can't. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
Am 3. März 2012 23:29 schrieb Paul Davis : > >> OSC > > this general language is the whole problem. > > you can't send OSC to "an OSC capable plugin" or "an external OSC > application" in any generalized sense, because there is no shared > format for the messages. > > the sequence of messages that you record may make sense to Pure Data, > but make absolutely no sense to, say, CSound. > > the motivation to develop the infrastructure for recording, playback, > disk storage and editing of such messages is not very strong when any > given sequence can only target one particular OSC receiver. the > motivation isn't zero, to be clear. but it just isn't that strong. > >> I don't know if it's of practical use for anyone else, but time and again I >> would have had good use for this apparently simple feature. If anyone knows >> a sequencer or DAW which can do what I sketched out above, please do tell >> me. OSC has been around since 1997, for crying out loud. It's about time >> that sequencers do more with it than just automatizing the transport >> controls. ;-) > > then its about time that people using OSC start defining some > standardized messages. MIDI did this from the start, and for all of > its limitations, its been a wild success. the OSC community has > self-consciously avoided doing this - lets queue up another pointless > argument about how to represent notes/frequencies/intervals - and as a > result is still only a niche protocol with every transmitter and > receiver defining their own messages. double fail ... > > I totally agree. Actually OSC missed the point of MIDI. (Or there was no intention to acctually become a replacement !? ) There should at least be an accepted, standardized way for transmission of MIDI data over OSC ! I've started a draft: http://wiki.linuxaudio.org/wiki/user/emrum/midi-osc-map -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
