Re: [LAD] Specification issues in open systems
On Sat, Sep 27, 2008 at 6:49 PM, Chris Williams [EMAIL PROTECTED] wrote: I can't see this as being anything other than a specification bug. I don't think the rosegarden developers have implemented the spec correctly, necessarily, but the spec gave them ample room to do what they did. So if I understand correctly, the original requirement is to have a single plugin receive a single MIDI stream, and then output multiple audio channels which the user can treat separately with different effects in the host (according to his or her whim). And Rosegarden will not do this because, although your plugin can declare that it has any number of output channels, Rosegarden will not handle more than two; it will merge them in an undocumented and externally unpredictable way. And it doesn't allow the user to route the channels to separate effects anyway, even if there are only two. I would have said this was squarely a limitation of Rosegarden. It's one that is likely to remain, as well. The DSSI spec of course permits this -- at the moment it's basically a user problem (this plugin will not work properly in this host). If the DSSI spec was changed so as to require the host to support the behaviour you want, then Rosegarden would simply change from being a technically complete but limited DSSI host to being an incomplete or non-conformant DSSI host; its actual behaviour would not change unless some new enthusiast with lots of spare time happened to step in to completely rewire its audio architecture. (Fons is quite right to say that the Rosegarden project has suffered from worrying about audio too much already.) I think that this limitation is quite defensible -- Rosegarden just isn't a good host for any task where the words audio and routing might both appear, and that's simply the way it is. You'd surely be better off doing it in something like Ingen and just driving the resulting graph from Rosegarden if desired (unless I misunderstand the goal here). But I guess you're right that what's not really defensible is in the failure to provide any way in the protocol to negotiate this, or for the plugin to determine itself whether its host is capable. You're probably right about the cause of this as well (basing the protocol off a simplistic effects protocol -- although I think simplistic is the point rather than effects -- many effects call for more sophisticated output classification as well -- try running the Bode frequency shifter LADSPA plugin on a mono track in Rosegarden some time). My guess is that this situation -- in which a plugin may be capable of something, but just mysteriously fails in a given host -- will get worse with LV2, as well, given the potentially huge range of optional extensions that may or may not be available. I agree, it's not a very promising situation: who would want to write plugins that only might work? (Well, hey, DSSI is still at v0.9. Plenty of time!) Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sun, Sep 28, 2008 at 6:18 PM, Chris Williams [EMAIL PROTECTED] wrote: DSSI, IMO, *attempted* to get this right. Implicit in the DSSI spec is an acknowledgment that a plugin spec can't be in the business of mandating gui solutions on a platform with many to choose from, so they tried to find a way around it using a remote gui which communicates with the host via OSC. I'm not sure this is entirely correct, either, but it's at least more right than several other ways of doing it (*cough* LV2), especially the central idea of trying to abstract the gui away from the architecture. The DSSI approach has two really big problems: 1. It's hard to share significant amounts of data between GUI and plugin, and to do things like synchronising the state of user presets. It can be done using shared memory negotiated between GUI and plugin via configure calls, for example, and Lars wrote a small library to help with this, but it's always going to be a pain. 2. It's different from any other plugin system, so you can't just write the code once and wrapper it for each of your supported protocols. Take a look at the absolutely gross hack used by dssi-vst, for example, to see how much pain is involved in doing an incomplete and unsatisfactory job of wrapping a GUI written for another system. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Paul Davis wrote: i ran into quite a lot of really significant problems which could only be solved using google-fu As is natural. I have no problem with this and did a great deal of it myself. When I say the information wasn't mentioned anywhere, I mean *anywhere*. I suspect that, because of the minimal take-up of DSSI, both in host and plugin terms, I was the one of the first people to unearth it, as I was among the first to try doing what is a fairly standard operation in the Windows / Apple worlds and noticing that one host didn't behave as expected. Having scoured the web and especially rosegarden's own site both before and after finding the issue, the only thing Rosegarden's docs have to say is expressing full support for DSSI. If nothing else -- and part of the reason for doing this -- this series of posts will provide some google feedback for any people who hit the issue in future. i am really not taking you to task for your observations on DSSI - from what you've written it really does sound like a bit of mess in this repsect, and quite possibly LV2 as well. but .. i am not entirely clear why you've approached the problem in the way you have. I claimed an implementation issue was intimately bound up with a problem inherent to certain specifications, then backed it up with facts when you called me on it. Perhaps my tone was overly irritated, and for that I apologise. To the general conversation ... As regards the merits or not of writing an instrument as a plugin, that's been addressed by some other respondents. The fact is that an instrument does *not* need OS-levels of interaction; it needs timing and midi data and output audio buffers, and optionally some facility for providing a GUI -- that's about it. Implementing it as a plugin allows the instrument to take advantage of a host's facilities. For example, a non-trivial synth or sampler can use the host's ability to host effects plugins; otherwise, the instrument has to host them itself, thus also having to provide an effects GUI generator. A second reason is that the plugin host can behave as an input mediator / sequencer for the plugin. A third reason is that, by developing an instrument as a plugin, the developer can *also* develop a stub host, thus allowing the instrument to run either as a plugin or as a standalone app, which is what NI have done with a lot of their instruments. Doing it *solely* as a standalone app means you're stuck with that model forever. Fourthly, as mentioned, there's session state saving. There's a reason that ReWire (*loosely* a jack equivalent) slowly became deprecated in favour of VSTIs on Windows. The prevalence of using the OS in the linux world is more to do with with the disparate and divided state of DAWs, host support for instruments, and the (quite wonderful) state of jack than it is to do with it being inherently the best solution. Everyone writes to jack (or ALSA) because they know it's a common denominator that's guaranteed to work well (as well as the fact that jack's architecture can replicate host provision to an extent) not because it's necessarily the best model for doing it a priori. As to session state saving, it's not something that *personally* concerns me all that much, provided each component allows the facility for saving its own configuration. Paul's right, though; it really is a big deal on the other OSs. Users are used to saving their project in their DAW of choice and having the DAW remember it, rather than them having to be responsible for saving each piece individually. DSSI provided some capability for this with the 'configure' function / OSC call. It gave the host some handle on how to reconfigure the instrument in question when loading a project. LV2 doesn't even do that from what I can see. Chris Williams ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Chris Williams wrote: There's a reason that ReWire (*loosely* a jack equivalent) slowly became deprecated in favour of VSTIs on Windows. Propellerheads won't even give you the time of day unless you're a registered for-profit corporation with a real product. Even then, they give trouble. Justin Frankel (the Reaper guy) had to argue with them, and he has a registered for-profit corporation with a real product! It will continue to be tolerated, though, as long as Reason remains a popular tool for music, and it *is* quite popular. THAT's why ReWire is dying off more than anything, assuming it is. Steinberg at least made VST an open standard (notice the flame-war-avoiding quotes there), allowing anyone to be able to develop plug-ins, even if they're free. No, it's not compatible with the GPL, but that's off-topic for this conversation, I think. As to session state saving, it's not something that *personally* concerns me all that much, provided each component allows the facility for saving its own configuration. Paul's right, though; it really is a big deal on the other OSs. Users are used to saving their project in their DAW of choice and having the DAW remember it, rather than them having to be responsible for saving each piece individually. DSSI provided some capability for this with the 'configure' function / OSC call. It gave the host some handle on how to reconfigure the instrument in question when loading a project. LV2 doesn't even do that from what I can see. My understanding with LV2 is that all communications between the GUI (whether included with the plug-in or generated by the host) flow through the host, and can be captured, analyzed, serialized by the host on the fly. Someone please correct me if I'm wrong on that. I would think that that means the host definitely *can* bring up an LV2 plug-in with state information quite intact. I don't have any knowledge of how difficult it is to do any of this, though. I'm only book smart on the issue. -- Darren ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Paul Davis wrote: It might suprise you that I probably agree with this point even more than you do :) JACK exists primarily because there was not a suitable plugin API on linux and because several of us felt it unlikely that there ever would be one. The biggest obstacle of all was the still-unsolved issue of GUI toolkit compatibility. Its remarkable and cool that JACK works as well as it does, and the isolation it provides between processes can be handy. But yeah, if we had had a single GUI toolkit and a decent plugin API ... no JACK would have emerged, probably. Wasn't JACK based at least loosely upon the same concepts as CoreAudio? I seem to remember something about that some time ago. Myself, I'm watching and participating quite eagerly in this conversation, because I would like to write a plug-in or two (or three) and I still don't know what API (JACK, LV2, etc.) I want to focus my energy on. Chances are, I'll be able to choose only one. -- Darren ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
This isn't entirely addressed to Paul; I've just used his comments as a jumping point. Paul Davis wrote: Chris Williams wrote: As regards the merits or not of writing an instrument as a plugin, that's been addressed by some other respondents. The fact is that an instrument does *not* need OS-levels of interaction; it needs timing and midi data and output audio buffers, and optionally some facility for providing a GUI -- that's about it. You're thinking small :) File I/O, network interaction, interactions with different sorts of input devices ... there's more. Point taken, but there's nothing inherently non-plugin about doing this. There are plugin architectures in dozens of other application areas that do these things. Add file I/O to my original list and you've covered a very large chunk of use cases (but not all, I concede). JACK exists primarily because there was not a suitable plugin API on linux and because several of us felt it unlikely that there ever would be one. I think this is partly where my issues stem from. Nothing will ensure this happens faster than a half-dozen bad specs. LADSPA was good in the sense that it was brief, tightly defined, *relatively* simple to implement from the host side (provided the host-supplied GUI generator was up to scratch); *very* simple to implement from the plugin side. I've spent some of today reading LV2 in more detail. I'm honestly not sure what to make of it at this point. My first reaction was that it's attempting to solve certain problems by introducing worse ones, but I haven't thought it through fully yet. The biggest obstacle of all was the still-unsolved issue of GUI toolkit compatibility. LADSPA tried to cope with the GUI issue largely by handing it off to the host. This facilitates a large set of effects and a smaller set of instruments but by no means all. LV2 seeks to solve this via the extension mechanism. This is one of the areas I'm really not happy about, especially the current (admittedly tentative) extension mandating not only a gui toolkit (gtk), but also the idea that the plugin should implement the Widget interface while the host should already be running the gtk main loop. Ouch. The problem with the extensibility argument is that no host is going to implement it fully, properly or consistently (as mentioned, it's hard enough for this to happen with a tightly-defined, compact spec) which leaves client developers still not knowing what they are dealing with. DSSI, IMO, *attempted* to get this right. Implicit in the DSSI spec is an acknowledgment that a plugin spec can't be in the business of mandating gui solutions on a platform with many to choose from, so they tried to find a way around it using a remote gui which communicates with the host via OSC. I'm not sure this is entirely correct, either, but it's at least more right than several other ways of doing it (*cough* LV2), especially the central idea of trying to abstract the gui away from the architecture. Incidentally, the idea that this is necessarily easier on other platforms with a single widget set is, at best, only half-true. I was intimately involved for a few years with the development of three products at a company with modest fame in this area. What the Windows developers overwhelmingly tend to do (I spoke with devs at other outfits that did this too) is use the native windowing system to get a Frame and a graphics context -- nothing else. They then end up drawing directly on the graphics context manually (thus effectively developing their own gui-toolkit-lite). This frees them (to an extent) from issues involving implementing their plugins in other OSs, as you can generally always get at least a Frame and a GC, and any differences in coordinate systems can be overcome with a trivial spacial translation. Chris Williams ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Chris Williams [EMAIL PROTECTED] writes: Paul Davis wrote: The biggest obstacle of all was the still-unsolved issue of GUI toolkit compatibility. [snip] LV2 seeks to solve this via the extension mechanism. This is one of the areas I'm really not happy about, especially the current (admittedly tentative) extension mandating not only a gui toolkit (gtk), but also the idea that the plugin should implement the Widget interface while the host should already be running the gtk main loop. Ouch. The problem with the extensibility argument is that no host is going to implement it fully, properly or consistently (as mentioned, it's hard enough for this to happen with a tightly-defined, compact spec) which leaves client developers still not knowing what they are dealing with. DSSI, IMO, *attempted* to get this right. Implicit in the DSSI spec is an acknowledgment that a plugin spec can't be in the business of mandating gui solutions on a platform with many to choose from, so they tried to find a way around it using a remote gui which communicates with the host via OSC. I'm not sure this is entirely correct, either, but it's at least more right than several other ways of doing it (*cough* LV2), especially the central idea of trying to abstract the gui away from the architecture. AFAIK it is perfectly possible to implement LV2 UI extension that handles GUIs in DSSI way, i.e. through OSC. This is probably the best approach if plugin author wants single custom GUI that works for most hosts. The fact that only GTK variant is defined, is caused by the fact that all currently involved parties tend to like GTK and use it in their hosts/plugins. I'm one of them, but I like generated UI's more, one of the reasons I've started dynparam extension work some time ago. So, if one wants custom GUI, options are: * Write one GUI per toolkit * Write single out-of-process GUI and route it through OSC, DSSI-like, or some other IPC mechanism. * Use low level X protocol, if possible at all - see Fons Adriaensen's followup mail. If you want single GUI that could work in any host, the additional option is generating it through some UI description mechanism, with dynparams extension being one that I use. As a side note, I think Lars Luthman made some time ago a research into hosting QT plugins in GTK host or vice versa, but I'm not sure what the result was. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp4jziPtKu5J.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] Specification issues in open systems
The following is a cross-post of an exchange that took place on the rosegarden-devel mailing list. I'm posting it here because I think it hints at something fairly serious with the current state of open audio specifications and issues with their implementation. It is not my intent to start a flame war. I come at this with over twelve years of involvement (albeit chiefly at a hobbyist level) with audio development and production on windows system (predominantly VSTis). I've used linux since the late nineties, but these issues have become more important to me since fully ditching Windows about 18 months ago. The open source philosophy has always been that, if something were not to your tastes, you were completely free to build it, or alter something else. This is true, and one of the things greatly appreciated about the system. The key issue, though, is the ability to use that facility; sometimes it is not as available as it appears. There are a great many people who would offer much more to open audio, I feel, but issues like the following need to be addressed. all the best, Chris Williams Chris Williams yikyak wrote: Chris Cannam wrote: Chris Williams yikyak wrote: Hello, I've been developing a toy DSSI plugin, partly to become more familiar with the spec and partly as a platform for writing base code for use with less toy instruments. I've been using Rosegarden and jack-dssi-host as test hosts. All was going well until I increased the number of DSSI / LADSPA output audio ports in the plugin. For some reason, I expected that rosegarden would create extra synth channels in the audio mixer for these outputs, but this didn't happen. Instead, one 'synth' audio channel was maintained in the mixer for the synth, out of which all outputs could seemingly be heard and controlled globally. Does Rosegarden mix-down all the audio outputs of a given synth before feeding the signal to its own internal signal path, or am I misunderstanding something / being an idiot? The number of outputs shows up correctly in the synths 'controls' dialog along with its ID, but this seems to be the only place at which they're discernible outside of the synth. (I'm using v.1.7.0 from Arch's repository). No, you aren't misunderstanding anything. Rosegarden is very simplistic in this respect -- it mixes the number of audio outputs up or down to match the number of channels on the track, which is always either 1 or 2 depending on whether the stereo button in the instrument parameters is pushed in or not. If the aim is to accept multi-MIDI-channel input and send multi-channel output in order to support multiple effective instances on separate tracks, the DSSI way to do that is to have several actual instances (perhaps sharing data behind the scenes) and then call run_multiple_synths once for all of them instead of run_synth on each one. Rosegarden will do this if you have the same plugin set for more than one track (and it supports run_multiple_synths). Unfortunately, that mechanism is rather different from any other plugin format. Thanks Chris, that's just the information I was looking for. I was thinking more of the situation where where you have *single*-midi-channel input but, as with some synths and samplers, want to run the output to different banks of effects (e.g. LADSPA plugins) depending on the specific midi note or the range in which that note lies (output groups). This seems theoretically possible under DSSI using only run_synth() (given an idiosyncratic parsing of the DSSI spec) but not if the host routes all output ports through the same audio channel. At the same time, I can see the problem from the host developers' perspective: the DSSI spec uses LADSPA's port system and there's no good reason for an effect's output ever to be routed to multiple 'host audio channels'. The two other ways of doing it would seem to be: 1) Incorporate a 'channel' system and ladspa hosting system *internal* to the instrument which would then only ever need a stereo output to the host (the massive downside of this being that it unnecessarily replicates complex functionality already provided by the host); or 2) Use run_multiple_synths() in a hackish manner for which it probably wasn't fully intended, as you'd be writing to separate LADSPA handles but essentially using only one midi event queue (this would also have the nasty side effect of requiring multiple redundant instances simply to use their output ports). You could probably do something equally nasty by playing with the descriptor returning and instantiate functions. Anyway, thanks again. It's not a Rosegarden-specific issue, I know; more strangeness in the DSSI spec coupled with my own ignorance. I've been thinking about this some more, and can't let it lie. It seems to me that there's definitely a bug or broken implementation involved somewhere. Under jack-dssi-host, if I request n outputs, I get n
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 14:04 +0100, yikyak wrote: The following is a cross-post of an exchange that took place on the rosegarden-devel mailing list. I'm posting it here because I think it hints at something fairly serious with the current state of open audio specifications and issues with their implementation. I don't have anything particularly useful to add to this discussion, but I do want to note that I could trawl back through my archives from the vst-plugins list and dig up at least a half dozen examples of similar behaviour differences between hosts in that world. Every time, the plugin authors have to detect which host they are running under and alter their behaviour. Nobody likes it and occasionally a host author modifies their software to be more like the rest of the bunch. I don't think your issue is with open audio specifications, its with API specifications in tiny little application niches. Good luck with resolving the issue. We'll use it if and when Ardour supports DSSI :) --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, Sep 27, 2008 at 4:39 PM, Paul Davis [EMAIL PROTECTED] wrote: On Sat, 2008-09-27 at 14:04 +0100, yikyak wrote: The following is a cross-post of an exchange that took place on the rosegarden-devel mailing list. I'm posting it here because I think it hints at something fairly serious with the current state of open audio specifications and issues with their implementation. I don't have anything particularly useful to add to this discussion, but I do want to note that I could trawl back through my archives from the vst-plugins list and dig up at least a half dozen examples of similar behaviour differences between hosts in that world. Every time, the plugin authors have to detect which host they are running under and alter their behaviour. Nobody likes it and occasionally a host author modifies their software to be more like the rest of the bunch. I don't think your issue is with open audio specifications, its with API specifications in tiny little application niches. Good luck with resolving the issue. We'll use it if and when Ardour supports DSSI :) --p When the VST spec first came out, there was no such trouble (there were plenty of other problems ...) as the VST apps were the only ones that supported it. I'm not talking about a minor issue here; it's to do with how and whether plugin hosts respect the requests the plugins make of them. Requesting multiple outputs worked perfectly under steinberg's stuff, it worked perfectly under Reason, it worked perfectly under Logic (back before Apple dropped it). I don't have the VST spec to hand, but there were mechanisms (in the post-2 variants anyway) for requesting resources and then being told whether you could have them or not and, if not, how many you could have. Every single Native Instruments VI used this facility, as did many others. Furthermore, in the VST spec, there was a very easy way to determine the host under which you were running. IHostApplication::getName() and IIHostApplication::getVersion() come to mind, but I may be wrong about the exact details. There is no equivalent under DSSI (or LV2 as best I can gather). As part of the testbed application I'd been building, one of the first things I implemented was a logger in the gui so I could see what was going on. This is the output from the plugin bootstrap on Rosegarden: INTERNAL [27-09-2008 17:04:59.232 BST] : Starting ... INTERNAL [27-09-2008 17:04:59.241 BST] : Parsed Host Info: DSSI Hostname: yerupaja.yikyak.org DSSI Port: 17556 Basepath: /plugin/dssi/1/synth/phool_synth PluginLibrary: phool_synth.so PluginLabel: phool_synth PluginInstanceID: Rosegarden: Synth plugin #1 GUI (this) Hostname: yerupaja.yikyak.org GUI (this) Hostaddr: 192.168.0.2 INTERNAL [27-09-2008 17:04:59.252 BST] : Starting Listening ... INTERNAL [27-09-2008 17:04:59.266 BST] : Listener up on GUI Port 35095 INTERNAL [27-09-2008 17:04:59.269 BST] : DSSI host resolved to 192.168.0.2 SENT [27-09-2008 17:04:59.275 BST] : /plugin/dssi/1/synth/phool_synth/update osc.udp://192.168.0.2:35095/plugin/dssi/1/synth/phool_synth RECEIVED [27-09-2008 17:04:59.292 BST] : Received /configure Command: __ROSEGARDEN__:__RESERVED__:ProjectDirectoryKey /home/chris/rosegarden/ RECEIVED [27-09-2008 17:04:59.293 BST] : Received /program Command: 0 0 RECEIVED [27-09-2008 17:04:59.293 BST] : Received /show Command: and this the equivalent output from jack-dssi-host: INTERNAL [27-09-2008 17:00:13.988 BST] : Starting ... INTERNAL [27-09-2008 17:00:13.998 BST] : Parsed Host Info: DSSI Hostname: yerupaja.yikyak.org DSSI Port: 10596 Basepath: /dssi/phool_synth/phool_synth/chan00 PluginLibrary: phool_synth.so PluginLabel: phool_synth PluginInstanceID: channel 0 GUI (this) Hostname: yerupaja.yikyak.org GUI (this) Hostaddr: 192.168.0.2 INTERNAL [27-09-2008 17:00:14.009 BST] : Starting Listening ... INTERNAL [27-09-2008 17:00:14.024 BST] : Listener up on GUI Port 47687 INTERNAL [27-09-2008 17:00:14.027 BST] : DSSI host resolved to 192.168.0.2 RECEIVED [27-09-2008 17:00:14.033 BST] : Received /program Command: 0 0 RECEIVED [27-09-2008 17:00:14.033 BST] : Received /show Command: SENT [27-09-2008 17:00:14.033 BST] : /dssi/phool_synth/phool_synth/chan00/update osc.udp://192.168.0.2:47687/dssi/phool_synth/phool_synth/chan00 Now, granted, you could arguably host-detect Rosegarden from the plugin's instanceID or from the key-value sent to /configure, but there's nothing in the spec to guarantee that should be there, and there's nothing to say it won't change on a whim in future. There's *nothing* about the jack-dssi-host output, however, that would enable the client to discern where it was getting its service from. it's tricky to argue that clients should overcome holes in the spec or a given implementation if there's nothing in the spec that even guarantees having an ability to do that in the first place. I can't see this as being anything other than
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 18:49 +0100, Chris Williams wrote: [ a lot of stuff ] are you seriously asking me to pull out my examples from vst-plugins over the last 5 years? yes, VST doesn't have the particular problem you are facing, but it has plenty of others. you want the most egregious? you tell me where in the VST spec it details which functions are called from which host thread. i could continue at quite some length ... i'm not trying to push back against your complaint. i'm just pointing out that the type of issue you're facing is actually really quite common in audio apps and with plugin APIs on different platforms. in implementing AudioUnit support in Ardour i ran into quite a lot of really significant problems which could only be solved using google-fu to pull answers from the coreaudio email list. none of the issues raised on that list have been documented by Apple and none of them have changed the API for AudioUnits in at least 5 years. every host developer and quite a few plugin authors have to face these over and over. we do it, we fix (most) of the problems, and we forget about it (mostly because we have no control over what apple does). i am really not taking you to task for your observations on DSSI - from what you've written it really does sound like a bit of mess in this repsect, and quite possibly LV2 as well. but .. i am not entirely clear why you've approached the problem in the way you have. your email contained a lot other claims about linux audio in general. i think that broad claims about this little world are a bit silly. speculations on why linux audio is in whatever state it is in generally seem to miss out on a number of important details and they also tend to skip the fact that this is a story written by a relatively small number of self-admittedly imperfect and insufficiently devoted people. most of us do not have the time or inclination to focus on newbies to audio programming on linux, even if we recognize that this is a problem and wish it was otherwise. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, Sep 27, 2008 at 08:18:39PM +0200, Paul Davis wrote: most of us do not have the time or inclination to focus on newbies to audio programming on linux, even if we recognize that this is a problem and wish it was otherwise. I spend on average something like the equivalent of half a working day each week on responding to off-list requests for support on some aspect of linux audio programming. The simple fact is that creating a 'major' audio app is not a simple task *on any system* and requires a mix of skills and knowledge that take their time to build up and mature. It's just not supposed to be easy for a relative newbie - believing that it should be may fit some political agenda but is rather foolish. Linux may democratise access to audio and other media production tools, and that's a good thing, but it does not do so by creating 'instant experts'. Regarding the original topic of this thread, I'd like to make two comments. First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Second, the life of Rosegarden's developers would have been a lot easier if they had just concentrated on trying to be the best MIDI sequencer rather than also a complete multitrack audio recorder, a mixer, and a host to software instruments. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Fons Adriaensen wrote: First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Except the biggest advantage of plug-ins is session state saving: When I have one master app that stores the states of all of my plug-ins, I can save out the session, and recall it later exactly as I saved it. Where is the functionality in JACK for that? I know that LASH has been making headway into that issue, but my understanding is that it has been an uphill battle. Believe it or not, this is a major showstopper for a lot of people. When I save out a session and pull it up later, I want it to come back up the way it was when I saved it. I don't want to have to mess with bringing up every program I was using and finding the preset I was using in each one. Of course, my experience with JACK is limited, and if it turns out the session state saving is in there, then I simply haven't found it yet, and you can ignore this email. Indeed, you can take this email for all it's worth. I've just about gotten to the point where I've stopped caring. -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 22:06 +0200, Fons Adriaensen wrote: First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Fons, you know I broadly agree with you, but a substantial fraction of the world's software instrument developers appear to feel otherwise. I can't think of a single major out-of-the-box software instrument for windows or OS X that hasn't been implemented as a plugin. the things that are only stand-alone apps are generally synthesis environments or have associated h/w (examples: kyma/capybara, max/msp, reaktor, and so forth, along with all the music-N derived synthesis languages). i haven't heard a single commercial developer complain about being forced to do things as a plugin, only about the details of it. --p ps. i think that even reaktor may be available as a plugin, and max/msp patches can be implemented as plugins by combining them with a core max runtime library. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 16:35 -0400, Darren Landrum wrote: Fons Adriaensen wrote: First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Except the biggest advantage of plug-ins is session state saving: When I have one master app that stores the states of all of my plug-ins, I can save out the session, and recall it later exactly as I saved it. Where is the functionality in JACK for that? something must be going wrong with the world darren. we're in agreement with each other twice in the same month :)) --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Paul Davis wrote: something must be going wrong with the world darren. we're in agreement with each other twice in the same month :)) It must be something in the water. :-P So... Why couldn't session states be saved as part of JACK? I realize it can be argued that it isn't within the scope of JACK, but... Isn't it, kinda? It's an important feature, and it has to get implemented *somewhere*. Of course, it makes the most sense that session states should be saved and recalled by the host. Isn't that also a part of what LASH is trying to accomplish? Unfortunately, I have to plead ignorance here, as I'm no coder, just a math head trying to make some new plug-ins, and getting nowhere, I might add. I still regard LV2 as a potentially powerful system for creating and handling virtual instruments and effects, but the right extensions (events and MIDI, and UI) would have to be implemented by the popular hosts. That's my largely ignorant opinion, anyway. -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, Sep 27, 2008 at 10:39:32PM +0200, Paul Davis wrote: Fons, you know I broadly agree with you, but a substantial fraction of the world's software instrument developers appear to feel otherwise. I can't think of a single major out-of-the-box software instrument for windows or OS X that hasn't been implemented as a plugin. On of the reasons being that on Windows or OSX in their official incarnations there is nothing like Jack. A single app on those systems is completely isolated. That is not the case in Linux. i haven't heard a single commercial developer complain about being forced to do things as a plugin, only about the details of it. Well, a 'rich' plugin standard has to provide almost everything that the operating system provides: audio, midi, GUI, network,... So why not use the system as your host ? All it takes is a good session manager. Existing plugin standards on Linux have been used to to implement a number of quite different things: A. Effects, general audio processing tools. B. Soft-synth modules, as in AMS or Om. C. Complete instruments. The requirments for each of these are quite different. It's somewhat naive to expect that a *simple* plugin standard could support all of those in an optimal way. Also a host that would support all of these would be multi-headed monster. LV2 started off in the right way, but in the usual attempt to make things as simple as possible for the uneducated user, what resulted was too minimal to support anything but the simplest use cases. Porting Aeolus to LV2 would require a number of absolutely non-trivial extensions, Jconv would require a lot more, etc. So if I wanted to port any of these I'd also have to write the host. If that host has to be useful for anything else than being a shell to my own apps it should also include all extensions needed by all other plugins. And a sequencer. And an audio recorder. And in the end neither Aeolus nor Jconv would work in Rosegarden or any other host, unless those authors would include my extensions as well. And I bet a 10 bottles of Amarone they will not. Finally, users 'expect' things. Yes. They also expect, at the age of 20, a house and garden and swimming pool, two cars, a 50 TV, a fixed job, two three-week holidays in a sunny place, free health care and a pension. All for free and without any effort from their side. You can build entire belief systems on this, and even a market, but we've seen during the last weeks what is the result of doing that. As a writer of software that you provide for free, the most stupid thing you can do is to be market- driven. You just waste your time and degrade the quality of your work. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Fons Adriaensen wrote: Well, a 'rich' plugin standard has to provide almost everything that the operating system provides: audio, midi, GUI, network,... So why not use the system as your host ? All it takes is a good session manager. This is clearly a repeating theme here. Is LASH the solution to this issue, then? I remember looking at the documentation for it and thinking it didn't look too difficult to implement. Reaktor works by having a standalone app for designing new ensembles (a complete instrument, effect, or combination thereof), and the VST plug-in is basically the core engine with the GUI engine running the ensemble without all of the graph-y back-end editing features. I don't know any of the details on how they made this work. I get the impression that the Emu Emulator X/X2 sampler works the same way. Gigasampler is not a plug-in, but used Propellerhead's ReWire, perhaps the closest analog to JACK on Windows. ReWire, though, can save the state of the slave programs wired in to the host app. I don't know how they accomplish this. (Big fat lot of help I am, I know.) I'd still like to think that there is still an innovative solution to this problem, and that we are the ones destined to find it. Time for some brainstorming, perhaps? -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Darren Landrum wrote: I'd still like to think that there is still an innovative solution to this problem, and that we are the ones destined to find it. Time for some brainstorming, perhaps? Sorry for replying to my own message. If something like this is to be solved, it should be tied to the host, I think. In other words, the state of my previous session has to restore itself upon re-loading the session file in Ardour|Qtractor|Rosegarden (take your pick). That means the host has to have the ability to run the other programs and set up the JACK graph connections. Is this even remotely possible? -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 19:03 -0400, Darren Landrum wrote: Darren Landrum wrote: I'd still like to think that there is still an innovative solution to this problem, and that we are the ones destined to find it. Time for some brainstorming, perhaps? Sorry for replying to my own message. If something like this is to be solved, it should be tied to the host, I think. In other words, the state of my previous session has to restore itself upon re-loading the session file in Ardour|Qtractor|Rosegarden (take your pick). That means the host has to have the ability to run the other programs and set up the JACK graph connections. Is this even remotely possible? LASH is intended to do all this (and maybe more too). Its just that its development process has, for all kinds of reasons, not been accompanied by the same general gee, lets all jump on this that accompanied LADSPA and JACK. When its done and widely adopted, this will work the way you want it to. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
