Re: [LAD] preset saving in sessions
With the advent of NSM, there's a better chance than ever for autoloaded sessions when working. One of the challenges of autoswitching between sessions is loading presets for that session. In, for example LV2rack, it starts, but presets have to be loaded manually, after it gets going. Is there a mechanism for LV2rack, and other standalone plugin hosts, to have a preset automatically load with the selected preset for a session, when that session is selected? An example is lv2rack with the IR lv2 plugin, which i've been testing in NSM. LV2rack comes up ok, but the preset i've built for a specific session doesn't automatically load. I assume this is the case when using something like LV2rack in other session managers too. Where would a call for an autoloaded session saved preset come from? The session manager, or LV2rack itself? To be clear, applications do have to be patched to support NSM. The same is true of XSM, LASH, and JACK-Session. The difference is that the NSM protocol provides much more information to all parties and is therefore far more useful. Unsupportive applications behave similar to LADISH level 0, where they can only be started and stopped. That being said, the changes required are about as complex as those required by LASH and JACK-Session, but provide greater functionality. The issue of presets is one I have been thinking about and am probably going to update the NSM API documentation soon with a recommendation. I believe that presets under session management should be true copies/transformations of state. Setting a preset should alter the parameters involved in such a way that the changes are completely and permanently stored in the application specific project file/directory--independent of whatever presets the particular user may have access to. Most sensible software already works this way, so it shouldn't be a problem to enforce. LV2rack seems like a good candidate for patching. That is, it is something which I might consider useful and has a fair amount of state. I'll look into patching it, or, if the developer would like to patch it themselves, I'd be happy to offer assistance. ___ 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 11:14 PM, Emanuel Rumpf xb...@web.de wrote: Am 3. März 2012 23:29 schrieb Paul Davis p...@linuxaudiosystems.com: 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 Yes, OSC is useless as it comes out of the box. So is TCP. So is access to audio hardware. It's a transport mechanism. Look to libmapper for a way to make it generally useful. I've implemented something similar for useful OSC signaling in Non-*, but it's conceptually the same as libmapper and (currently imaginary) JACK OSC ports. Generic Input and output signals which can be connected to one another without requiring each party to be separately configured. And, for the record, liblo defines a MIDI datatype for transport of midi over OSC--although I don't see much point to doing that, as it merely combines the deficiencies of both. ___ 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, Mar 4, 2012 at 2:50 AM, Emanuel Rumpf xb...@web.de wrote: Am 4. März 2012 11:14 schrieb J. Liles malnour...@gmail.com: On Sat, Mar 3, 2012 at 11:14 PM, Emanuel Rumpf xb...@web.de wrote: 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 Yes, OSC is useless as it comes out of the box. So is TCP. So is access to audio hardware. It's a transport mechanism. Look to libmapper for a way to make it generally useful. I've implemented something similar for useful OSC signaling in Non-*, but it's conceptually the same as libmapper and (currently imaginary) JACK OSC ports. Generic Input and output signals which can be connected to one another without requiring each party to be separately configured. And, for the record, liblo defines a MIDI datatype for transport of midi over OSC--although I don't see much point to doing that, as it merely combines the deficiencies of both. True somehow. OTOH if most applications would have a _standardized_ mechanism to support musical control over OSC, there would be a small chance, that OSC could replace MIDI somewhere in the future. The chance for MIDI to improve seems very low, due to its technical limits. IRC Yamaha as an improved MIDI format for their digital pianos, but I wouldn't call that a standard. I personally don't think that the way notes are encoded is the primary limitation imposed by MIDI. A note is a frequency, an attack/decay modulation, and a duration. MIDI does an acceptable job of handling these. If you want more resolution, then the ultimate is a waveform... The way OSC is used, and in libmapper in particular, is to say things about the input device, not the music, which, as far as the input device is concerned, doesn't exist. Things like the low-resolution continuous variation of force applied to a button, or the position of a finger on the length of a resistive strip. These things have nothing to do with music, so the fact that there's no standard for notes is not a problem. The standard I propose (and use), as does libmapper, is that of Control Voltage floating point values between 0.0 and 1.0. Generally speaking, the neither the source nor the sink cares about the scale of the value, only that it varies between a minimum and a maximum. Users like to see the actual values, but it is a much more usable system if they are scaled to 0.0-1.0 on the wire. ___ 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/04/2012 03:31 AM, David Robillard wrote: 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. That makes perfect sense to me. 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. 99.% of the world population is zero, I guess that's me, thanks. ;-) That's your take on what users want, I disagree. Add OSC tracks to Ardour and people will find good uses for it, that's my take. Blindly recording events with no editing or display ability simply isn't that useful, and certainly doesn't constitute a MIDI replacement. Why should it be recorded blindly? It's not rocket science to come up with a convenient interface to edit and visually represent something like generic OSC data. In fact, Ardour automation would almost fit the bill if there was a way to record and play the data from/to external devices and applications in a way which doesn't take the MIDI detour. You can argue that OSC is too limited all day, but in any case it's better than 7 bit values with 7 bit addresses. I'd be more than happy to use any other semi-standard format which offers this and has at least some support in applications. But what we have right now for transferring control data is MIDI and OSC. If you know about anything else please do tell me. I can't drive a Pd patch with a data format that doesn't exist. I can get control data from OSC devices and feed that to Pd, however. Just bad luck that none of the major DAWs supports it directly, so I have to fit my square OSC peg into the round MIDI hole to make that work. ;-) Albert -- Dr. Albert Graf 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/04/2012 03:47 AM, David Robillard wrote: 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. That shouldn't be a real problem. OSC is already serialized after all, and uses network byte order. So you can just take those blobs and save them to a file and read them back again. 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. If it can be made to also record OSC messages and if I can pick the OSC addresses that I want, then this would probably satisfy most of my needs. Albert -- Dr. Albert Graf 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 3/4/12, J. Liles malnour...@gmail.com wrote: I personally don't think that the way notes are encoded is the primary limitation imposed by MIDI. A note is a frequency, an attack/decay modulation, and a duration. apparently you're forgetting or have not been a part of the many debates with the music technology community about how to define a note. personally i'm happy with what you wrote, but i know several people who have made cogent arguments that defining notes in terms of frequencies completely misses one of the most musical semantics. The way OSC is used, and in libmapper in particular, is to say things about the input device, not the music, which, as far as the input device is concerned, doesn't exist. as as receiver of OSC, i'd be entirely happy with such a standard. the problem for users is that it leaves the mappings unspecified, and although there are some clever solutions for this (several of them), from a user's perspective it always adds an extra layer of complexity. contrast with MIDI, where almost all the messages that most people will generate have a defined meaning even from the sender's perspective (though sure, the receiver can still map it to something else if it wants to). ___ 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 4. März 2012 14:38 schrieb Paul Davis p...@linuxaudiosystems.com: ... the problem for users is that it leaves the mappings unspecified, and although there are some clever solutions for this (several of them), from a user's perspective it always adds an extra layer of complexity. contrast with MIDI, where almost all the messages that most people will generate have a defined meaning even from the sender's perspective (though sure, the receiver can still map it to something else if it wants to). Exactly. Once upon the time, GM was helpful. If you made your sequencer play a BassDrum, on one synth, it would play a BassDrum on a different GM machine too, without any configuration. Today MIDI + GM appear too limited. We need 3 drum-kits, 10 snares, 52 channels, 64 bit spoiled musicians ;) With current OSC, one would have to configure the headstrong soup of both sender and receiver. -- E.R. ___ 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 14:14 +0100, Albert Graef wrote: On 03/04/2012 03:47 AM, David Robillard wrote: 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. That shouldn't be a real problem. OSC is already serialized after all, and uses network byte order. So you can just take those blobs and save them to a file and read them back again. I would assume that any realtime local transport via something like Jack or plugins would eschew the network byte order thing since that's quite a massive amount of overhead for no reason. You'd have to to actually send it over a network protocol or disk though, of course. Sure, given that you already have a POD serialization, inventing such a format wouldn't be hard. Perhaps just invent a RIFF chunk for them. Time stamps may be a question for sample accuracy. 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. If it can be made to also record OSC messages and if I can pick the OSC addresses that I want What do you mean by pick the OSC addresses that I want? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
On Sun, 2012-03-04 at 08:17 +, parched2099 wrote: [...] An example is lv2rack with the IR lv2 plugin, which i've been testing in NSM. LV2rack comes up ok, but the preset i've built for a specific session doesn't automatically load. I assume this is the case when using something like LV2rack in other session managers too. It should be noted that IR does some terrible kludges for saving state that make it impossible to store its state portably (it saves to a config file in a location unknown to the host and saves a hash into that file across several float control ports). However, the new LV2 state stuff is specifically designed to allow self-contained archival/export with any session manager[1]. Hopefully a future version of IR will move to it. I don't know anything about NSM's facilities for export/archival, though. -dr [1] My preferred implementation is using symlinks to refer to external files, so any tool, even tar -h, can archive correctly. KISS. ___ 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 08:38 -0500, Paul Davis wrote: On 3/4/12, J. Liles malnour...@gmail.com wrote: I personally don't think that the way notes are encoded is the primary limitation imposed by MIDI. A note is a frequency, an attack/decay modulation, and a duration. apparently you're forgetting or have not been a part of the many debates with the music technology community about how to define a note. personally i'm happy with what you wrote, but i know several people who have made cogent arguments that defining notes in terms of frequencies completely misses one of the most musical semantics. To me, one of the primary limitations about MIDI is the lack of ability to control individual notes. For example, a good protocol could let you start at C, slide up to A, do some vibrato, etc., e.g. you could draw lines in your sequencer. Identifying the note by frequency would preclude this. Note numbers are better. The way OSC is used, and in libmapper in particular, is to say things about the input device, not the music, which, as far as the input device is concerned, doesn't exist. as as receiver of OSC, i'd be entirely happy with such a standard. the problem for users is that it leaves the mappings unspecified, and although there are some clever solutions for this (several of them), from a user's perspective it always adds an extra layer of complexity. contrast with MIDI, where almost all the messages that most people will generate have a defined meaning even from the sender's perspective (though sure, the receiver can still map it to something else if it wants to). The thing is, reality has turned MIDI in practice to everything being learn-based (except notes) anyway. Most of the crap in MIDI can just go away, since the use case is send a whatever with a number(s) in it somewhere the receiver can pick up on. There are a few things that need to be standardized, like notes and transport control, but I think everything having a universal meaning is at best dubious, and likely a mistake. It is inevitable that you need learn and/or controller mappings anyway, so the protocol can be a simple description of what's happening on the *sender*. What the receiver does with it is its own business. This is a pretty controller-centric opinion, but I don't think OSC is really good for much beyond that anyway, and the only cases that it might be (controlling Pd and such) the (power) user is designing their own messages anyway so it's a non-issue. -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!
Guys, can you explain to me, who is not very well aware of OSC and MIDI debates, why not come up with at least a Linux Audio OSC standard for notes and just use that? -- Louigi Verona http://www.louigiverona.ru/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
On Sun, Mar 4, 2012 at 9:38 AM, David Robillard d...@drobilla.net wrote: On Sun, 2012-03-04 at 08:17 +, parched2099 wrote: [...] An example is lv2rack with the IR lv2 plugin, which i've been testing in NSM. LV2rack comes up ok, but the preset i've built for a specific session doesn't automatically load. I assume this is the case when using something like LV2rack in other session managers too. It should be noted that IR does some terrible kludges for saving state that make it impossible to store its state portably (it saves to a config file in a location unknown to the host and saves a hash into that file across several float control ports). However, the new LV2 state stuff is specifically designed to allow self-contained archival/export with any session manager[1]. Hopefully a future version of IR will move to it. I don't know anything about NSM's facilities for export/archival, though. -dr [1] My preferred implementation is using symlinks to refer to external files, so any tool, even tar -h, can archive correctly. KISS. We must remember not to take this to a level of absurdity. For instance, I don't believe that it is necessary to, for example, copy/symlink LADSPA or LV2 plugin binaries themselves into a session. The data is that the user selected such-and-such plugin. The plugin can be expected to exist on the same system at another time and on other systems. If it doesn't exist, it can be made to. Seems to go without saying that programs which rely on plugins should not fail horribly when one is missing, but should instead display enough information to the user for them to be able to fix the problem. Perhaps it needs saying anyway, though. This doesn't just apply to plugins, but to soundfonts, generic sample libraries, etc. What should be stored in the session is only what is specific to the session, and that sometimes includes a selection between generic external entities. Parameter presets are another matter, however, because they are often not generic but are personal libraries of saved preferences which cannot be expected to be aquirable on another system. This is why when presets are involved, all the changes that a preset makes to the parameters should be stored in the session. If you use symlinks to cover the gray-area case of a non-generic llibrary of impulse waveforms, that's fine and it would work for archiving, but the point remains that if you don't create the symlink and I attempt to load a copy of the session in a different environment, I would expect to be told by the software what exactly is missing. Obviously, solving the problem is as simple as going back to the creator of the session and saying Hey, I need this external object in order to fully load your session. BTW, I don't know if LV2 supports this, but if it allows plugins to *SAVE* non-generic (that is to say, session specific) data wherever they want on the filesystem, then that, IMHO, is badly broken. There may be nothing technical that can be done about it, but you should at the very least be able to point at a section of the API document and say to the developer of such a plugin: Fix it, it's broken. ___ 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! (Emanuel
The chance for MIDI to improve seems very low, due to its technical limits. HD-Protocol MIDI is coming, albeit with painfully slow progress. Best Regards, Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: BTW, I don't know if LV2 supports this, but if it allows plugins to *SAVE* non-generic (that is to say, session specific) data wherever they want on the filesystem, then that, IMHO, is badly broken. There its not always LV2 that is the cause of this. consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. so now create a plugin that allows the user to alter what samples are used for various note numbers or velocity values or whatever (i.e. a reasonably capable sampler) and ask it to save its current state. it gives you an SFZ file to stash away in a location of the host's own choosing. but what do the contents refer to? ___ 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/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 Graf 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] preset saving in sessions
On Sun, 2012-03-04 at 12:37 -0800, J. Liles wrote: On Sun, Mar 4, 2012 at 9:38 AM, David Robillard d...@drobilla.net wrote: [...] However, the new LV2 state stuff is specifically designed to allow self-contained archival/export with any session manager[1]. Hopefully a future version of IR will move to it. I don't know anything about NSM's facilities for export/archival, though. -dr [1] My preferred implementation is using symlinks to refer to external files, so any tool, even tar -h, can archive correctly. KISS. We must remember not to take this to a level of absurdity. For instance, I don't believe that it is necessary to, for example, copy/symlink LADSPA or LV2 plugin binaries themselves into a session. I agree. Some fancy automatic mechanism to resolve missing plugins somehow might be nice, but that's orthogonal. Plugin binaries definitely do not belong in saved sessions. (Plugins using files *whatsoever* should be discouraged, but sometimes it's truly necessary) This doesn't just apply to plugins, but to soundfonts, generic sample libraries, etc. What should be stored in the session is only what is specific to the session, and that sometimes includes a selection between generic external entities. This is only true *sometimes*. If you are saving a session locally, sure, you don't want to copy everything it touches into the save directory (possibly many times). However, the ability to completely archive a session, including samples and such, is a very important ability. Sessions aren't very useful if I can't make one, send it to you, and have us collaborate. Or make one, archive it, and load it up later on some other machine and actually have it work. If you get hundreds of unresolved file references to mysterious paths on some other machine, the system has utterly failed to do its job. Put in other terms, the session shouldn't *always* be archived, but the ability to archive sessions is crucial. If you use symlinks to cover the gray-area case of a non-generic llibrary of impulse waveforms, that's fine and it would work for archiving, but the point remains that if you don't create the symlink and I attempt to load a copy of the session in a different environment, I would expect to be told by the software what exactly is missing. In terms of the plugin interface, all that happens is the host gets the opportunity to map any paths the plugin saves to its state. This way, it can implement any behaviour. Symlinks just happen to be the best and simplest one, all things considered. Instead of inventing some new file format everyone has to deal with and erecting some bloated framework to accomplish all this, you just archive the thing and resolve symlinks. Good old fashioned tar can even do it (both full and shallow archival). It's also very convenient that what's going on is very clear at the file system level, you can see precisely what files are referred to just by looking at a directory listing, and you can even resolve broken links manually with generic tools (i.e. ln). All of this becomes a real nightmare if the paths are buried in some XML file, or whatever. I guess it's summed up nicely by the fact that you can do all of the following without any dependency on a particular API or file format whatsoever: * Report and/or resolve missing files in the session * Do a shallow archival of the session * Do a deep archival of the session which will load on other systems without any missing data * Do all of the above recursively (sessions within sessions) with zero additional effort Of course, this isn't mandated by LV2 or anything, but the friction you'd have to overcome to achieve the same with a bloated pile of unnecessary garbage is so massive it's the only realistic solution for plugins with files in hosts in session managers. It relieves the burden of session managers having to have an interface specifically for this and hosts having to implement it (which, even if you did, means you'd have to launch the host just to export an existing session). Obviously, solving the problem is as simple as going back to the creator of the session and saying Hey, I need this external object in order to fully load your session. This might be simple, but it might also be completely impossible. I agree it should be possible to implement this behaviour (to share lightweight sessions among people who do share a common set of data), but it also must be possible to do a true self-contained export. Luckily though, all of this boils down to a very simple requirement: the host must be given the opportunity to do whatever to paths. BTW, I don't know if LV2 supports this, but if it allows plugins to *SAVE* non-generic (that is to say, session specific) data wherever they want on the filesystem, then that, IMHO, is badly broken. There may be nothing technical that can be done about it, but you should at the very least be able to point at a section of
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On Sun, 2012-03-04 at 22:38 +0300, Louigi Verona wrote: Guys, can you explain to me, who is not very well aware of OSC and MIDI debates, why not come up with at least a Linux Audio OSC standard for notes and just use that? Chicken Egg problem. (Never trust a spec not actually used by anyone) -dr ___ 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 dr.gr...@t-online.de 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 Graf 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] preset saving in sessions
On Sun, 2012-03-04 at 16:17 -0500, Paul Davis wrote: On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: BTW, I don't know if LV2 supports this, but if it allows plugins to *SAVE* non-generic (that is to say, session specific) data wherever they want on the filesystem, then that, IMHO, is badly broken. There its not always LV2 that is the cause of this. Well, LV2 is never the *cause* of this, it's an inherent problem to plugins that use files. consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. so now create a plugin that allows the user to alter what samples are used for various note numbers or velocity values or whatever (i.e. a reasonably capable sampler) and ask it to save its current state. it gives you an SFZ file to stash away in a location of the host's own choosing. but what do the contents refer to? Yeah, this problem sucks. The only solution is for the plugin to map the paths inside that SFZ file. It is (inherently) necessary for the plugin to map *ALL* paths in its state for this to work. If they happen to be in some pre-existing file, well, that's probably going to be pretty annoying, but you have to map them all the same. -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 22:27 +0100, 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. Ah. 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. Indeed it would be a much easier way to bang things out, but unfortunately I won't be attending this year. Perhaps next... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
Am 4. März 2012 22:47 schrieb David Robillard d...@drobilla.net: On Sun, 2012-03-04 at 16:17 -0500, Paul Davis wrote: On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. so now create a plugin that allows the user to alter what samples are used for various note numbers or velocity values or whatever (i.e. a reasonably capable sampler) and ask it to save its current state. it gives you an SFZ file to stash away in a location of the host's own choosing. but what do the contents refer to? Yeah, this problem sucks. The only solution is for the plugin to map the paths inside that SFZ file. It is (inherently) necessary for the plugin to map *ALL* paths in its state for this to work. If they happen to be in some pre-existing file, well, that's probably going to be pretty annoying, but you have to map them all the same. For simplification, one could assume all samples had a common parent directory ? Then the user could simply re-locate that common parent directory, if the samples were not found ? example: /home /user /store /samples /shapewavs /sine.ogg moved to: /home /user /newplace /samples /shapewavs /sine.ogg common parent directory: samples/ ___ 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/04/2012 09:27 PM, Albert Graef wrote: P.S.: Rui, apologies for hitchhiking your thread. I hope that you will forgive me over a glass of good Californian wine. ;-) no worries. given the length of the thread i think i'll take two please ;) cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
On Sun, 2012-03-04 at 23:17 +0100, Emanuel Rumpf wrote: Am 4. März 2012 22:47 schrieb David Robillard d...@drobilla.net: On Sun, 2012-03-04 at 16:17 -0500, Paul Davis wrote: On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. [...] It is (inherently) necessary for the plugin to map *ALL* paths in its state for this to work. If they happen to be in some pre-existing file, well, that's probably going to be pretty annoying, but you have to map them all the same. For simplification, one could assume all samples had a common parent directory ? Unfortunate the SFZ file format does not have any such rule, so you can't make that assumption in general. Well... you can (on POSIX anyway), but in the worst case it might be the root, which means you end up with the entire file system in your session. Oops :) -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/04/2012 11:26 PM, Rui Nuno Capela wrote: no worries. given the length of the thread i think i'll take two please ;) Ok, granted. I'd even make that two bottles if you implement OSC tracks in Qtractor. ;-) Albert -- Dr. Albert Graf 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 Mon, Mar 5, 2012 at 7:47 AM, Albert Graef dr.gr...@t-online.de wrote: On 03/04/2012 11:26 PM, Rui Nuno Capela wrote: no worries. given the length of the thread i think i'll take two please ;) Ok, granted. I'd even make that two bottles if you implement OSC tracks in Qtractor. ;-) Albert I'm chiming in late here, but it is a topic I've thought about a little having experimented in the domain. Given the open-endedness of OSC, I've always thought it makes more sense to implement some kind of plugin based translators, as it were, something like the ladosc ladspa plugins but with more flexibility and eliminating the need for both a sender and receiver plugin. For instance, if one were to implement an LV2 OSC instrument, you automatically get multi-host compatibility without having to expect the host dev's to agree on a standard as such. The plugin would simply need some kind of sensible interface to define namespaces for the translated midi events that the host would be sending to the plugin via the standard sequencer interface. This way, discrete and continuous events could be mapped to OSC output within the UI of the plugin. I hope I'm making sense. Alas, this is more than I can do, but if a developer were feeling up to it I'd be more than happy to line up for testing. ___ 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 Mon, 2012-03-05 at 09:40 +0900, michael noble wrote: [...] I'm chiming in late here, but it is a topic I've thought about a little having experimented in the domain. Given the open-endedness of OSC, I've always thought it makes more sense to implement some kind of plugin based translators, as it were, something like the ladosc ladspa plugins but with more flexibility and eliminating the need for both a sender and receiver plugin. For instance, if one were to implement an LV2 OSC instrument, you automatically get multi-host compatibility without having to expect the host dev's to agree on a standard as such. The plugin would simply need some kind of sensible interface to define namespaces for the translated midi events that the host would be sending to the plugin via the standard sequencer interface. This way, discrete and continuous events could be mapped to OSC output within the UI of the plugin. I hope I'm making sense. I don't really grasp what you're getting at here, or what MIDI has to do with it, etc. However, using plugins to process/filter/whatever OSC messages is natural (same thing for Jack apps). You can use any event types in LV2. What you'd need to work with OSC in plugins is a simple implementation capable of reading and writing OSC messages in realtime. Liblo is too heavy for that. Reading is probably easy. Writing is a bit trickier, I struggled with inventing a decent API for a similar thing (LV2 atoms, not OSC, but same idea), but eventually arrived at an append-based API which works pretty well. I call this the forge API for atoms. A similar scheme could work for OSC, e.g hard real-time code to write the message /foo/bar if 1 3.0 could look something like: OSC_Forge forge; osc_forge_set_output(output_butter, n_bytes); OSC_Msg msg; osc_forge_msg_start(msg, /foo/bar); osc_forge_int(1); osc_forge_float(3.0); osc_forge_msg_finish(msg) One unfortunate thing with OSC is the size of the type string must be known in advance[1], so you might have to pass that to osc_forge_msg. Nesting (bundles) can be handled automagically, the forge maintains a stack (without allocating, of course). Such a thing can be implemented in a single smallish header. 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. -dr [1] I consider this a mistake in OSC. The type tag should precede each argument so messages can be built sequentially by simply appending successive arguments. ___ 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 Mon, Mar 5, 2012 at 10:16 AM, David Robillard d...@drobilla.net wrote: I don't really grasp what you're getting at here, or what MIDI has to do with it, etc. However, using plugins to process/filter/whatever OSC messages is natural (same thing for Jack apps). You can use any event types in LV2. That'll teach me for waffling before my morning coffee. I really meant nothing more than saying that an instrument plugin that can send OSC could be triggered via a midi sequencer. Of course, that doesn't do anything about the issue of being able to record OSC, and in the end, also isn't that much easier than sending midi from the sequencer to say PD and letting PD do the translating to OSC messages. -m ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
