OvertoneDSP plugins

Installation & Configuration Linux
#61

@mevla

Yes but that is a situation where proper latency compensation would allow for larger latencies as well. Unless you are recording the acoustic while listening to the plugins, there is no reason that any amount of altency should be a cause for significant issues, as you would mix your live signal with playback in your audio interface. The DAW then would compensate for the latency by shifting your recording forward, by that same amount as your latency so that when played back it is inline.

       Seablade
#62

@paul: I have mentioned that 1 plus 1 makes 2. That it is an evidence. I made embedded processor development, I know. To this though, I contrast the notion of Bitwig offering working application crash proof management of plugins and possibly a general rugged way of handling plugins.

Contrary to the the possibility of extra-terrestrials, this is a practical user observation confirmed by managment plugin options that are offered and use of the software, not a vague belief. And in doing so they are not jeopardizing their business, they are not shooting themselves in the foot.

Speaking of body parts, here is an analogy. Recently I got pain in the knees which I have resolved to my eating of large amounts of wheat gluten. Celiac type of thing. Now if I would have went to a ‘knee-doctor’ and in the diagnostic I would have mentioned that I thought gluten might be the problem he could have argued that no, I see it right here that there’s inflammation in that region between those ligaments (with some latin names) so we must treat this first, we might need to operate before its too late.

Now if the next step is for me to go and ask the Bitwig devs about a specific question, then I would not think it would be the right approach. As in everything else I have observed, in any field of life, I would like to know how they do it, not why they would mumble at answering a pointed question.

#63

@meefchaloin: Regarding the handling of plugins, a ‘simple’ handling that would allow the plugin itself to crash to its hearts content without bringing down Ardour (with Ardour 100% surpirsed by this since when restarted it is totally oblivious to the previous crash and does not offer crash recovery) would be a tremendous big step since it would first, obviously, keep Ardour running and secondly it would tell clearly the user that a specific plugin has a problem. Then it would up to the user to continue using it or not. The plugin, that is. And perhaps a third thing would be that in doing so, a way would be sketched to isolate the source of such problems, hence a step towards a ruggedized way of handling plugins.

#64

@mevla: as a DAW developer who knows other DAW developers, I can tell you confidently that plugin support is the absolute bane of all DAW development. Issues with plugins, regardless of the plugin API and style of plugin, are rampant across all DAWs. It is incorrect to think of plugins+DAWs as a “solved issue” that “just works”. The reality is that every DAW development team has to put periodic and occasionally intense effort into fixing deep and superficial problems with specific plugins, with plugin architecture and more. If I could bar the use of plugins in Ardour without adversely affecting users, I would happily do it. Obviously, however, that isn’t possible, so we continue on … all trying to find solutions that represent some acceptable compromise between conflicting goals.

#65

@paul: Yes, for any software that accepts 3rd party modules in a free manner, or according to a 3rd party specification. Without exercising total control, eg. use our libraires and go through our validation program. Hence, the point I’m making: it has to be defensive. It has to be rugged. And it has to make it clear that if ti crashes it is because of that external module, and not because the main application is buggy. Graceful handling. At least the user will know ah, that plugin has crashed but the DAW is still there, I can save my data and then I can decide if I want to continue using that plugin.

But this is not the case with Ardour. Ardour will be taken by surprise, oh crap and in a millisecond will vanish from the desktop. If at least it would let the plugin crash, tell the user, optionaly ask the user if he wants to restart the plugin, gracefully. While this could be considered as a superficial detail, it would have a good impact on users, carrying forward the notion that Ardour is solid and knows what’s going on. Don’t you think ?

#66

@seablade: Well, latency did cause a problem in recording. This is why I went to using a distro-provided real-time kernel, adjusting the scaling governors, checking out the IRQs, starting jack with various -p and -n parameters for the interface, checking with jack_iodelay, etc. It is now fine for Ardour (Mixbus 32C) Bitwig and Renoise, but there was a problem before.

#67

mevla: you will save yourself a lot of grief if you stop using troublesome plugins even if you paid for them. There are quite a few good free well behaving plugins out there. I’ve seen even Pro Tools crash because of misbehaving plugins.

I understand it is frustrating when you can not trust your tools, but Ardour is quite stable when used with well behaving plugins. And the developers here didn’t make the misbehaving plugins in question. They are not in control in this case.

#68

@ mhartzel: Grief ? I do not see any kind of distress here. If I need OvertoneDSP processing I can record the track in Bitwig with 7 OvertoneDSP plugins and then export the track for Ardour to integrate. No problem whatsoever. And this is w/o telling Bitwig to have special independent plug-in host process for each OvertoneDSP plugin.

IMHO, the most important thing is to be able to discuss. If we discuss about vampires and immediately someone gets the cross out with a bag full of garlic, then the discussion can be disrupted.

The notion put forth here, independent of whoever is, er, ‘at fault’, is ruggedization of software as a contribution to a better user experience.

The substance for this notion is the fact that Bitwig seemingly are not on a path to commit business suicide by being able to let plugins crash gracefully without bringing down the whole application. And to offer users an option to protect even more ‘against’ specific plugins, on a per plugin name basis, using what they call ‘independent plug-in host process’.

There is substance behind the notion as to assure that it does not come out of the blue, some kind of fairy thought in the land of carebears.

This is the essence of a discussion. Not the carebears, the notion of rugged software.

If it’s too demanding, then all right.

#69

@ mhartzel: I am sorry I have forgotten to comment on ‘are quite a few good free well behaving plugins out there’. The following is about Linux, not Windows or MAC. Well, we can take the Calf ones out generally speaking, can we ? Then, what’s left ? It sounds as if the most important aspect of a plugin at this point is that it behaves correctly. Does not seem to matter if it was not updated in 10 years, or if very few of these well-behaved, if any at all, replicate vintage hardware. Or offers actual musicality beyond only being well-behaved. I use Calf from time to time as they do have a nice offering on the functional side, and, there is continuous development. Although each time there is a chance that the DAW will be brought down abruptly at any time. Some Calf plugins seems more stable than others though.

So with Ardour (Mixbus 32C) I use mostly Harrison (XT, reverb, delay, etc…) and u-he (Presswerk, Uhbik, Satin, Protoverb), along with the x42 EQ (mostly subtractive at the top of the tracks) and meters. These certainly do not bring down the application. And from time to time I may sprinkle an OvertoneDSP or a Calf if I want to add spicyness:)

#70

mevla: I’m not trying to prevent discussion or downplay anything here. I’m a Ardour user and do care about stability since I use Ardour almost every day. Just two days ago I worked on a project with Ardour 4.7 for 12 hours without stopping or Ardour crashing. Just trying to say that the choice of plugins really does matter. Another constant source of problems has been Calf plugins, better steer away from those also.

The biggest commercial audio editor in the world Pro Tools has not been able to solve this problem either. I just witnessed Pro Tools 12.5.2 crashing 2 times during 30 minutes because of unstable RTW meter plugins. This happened during IBC exhibition in September. We do use the same Pro Tools 12.5.2 version where I work and it is much more stable than that, crashes maybe once a week. Avid (that makes Pro Tools) has deep pockets and dozens of full time programmers available for them. Ardour is a project with one fulltime developer and others contributing their free time. Bitwig is a commercial project that probably has much more resources that Ardour. Good for Bitwig for having found a way to isolate plugin crashes, but as I said even Pro Tools doesn’t have this feature. So for both Ardour and Pro Tools it’s just best to trash the plugins that don’t behave or file bug reports for their developers.

If you really want to help to have better plugin crash handling in Ardour you could try to help develop it or if this is not possible file a feature request on Ardour bug tracker. If you can gather information about how this feature could be made possible please include that on the feature request. You can also offer to sponsor developing this feature. This is a promise of a sum of money paid when/ if the feature is implemented. If others find the feature important they might join in and also sponsor it.

I hope you can understand that open source projects will probably never have all the features of a competing commercial project. Ardour might not have every feature under the sun, but it has all features I need.

#71

@mhartzel: Thanks for your reply. We agree that the chocie of plugins matters as far as stability is concerned, with Ardour, and very likely, Pro Tools. From what you are describing, and from a quick search I just did, it looks very much like Bitwig has hit a technical feature big time with their plugin crash protection. At the time of announcement many people sprung forth with the notion that it can’t be done, CPU cycles, the usual. Yes, there is a need to do technical research and be creative about it, and this takes time, and money. I’m interested by how they might be doing it. I do not have the time to delve into this though, as music is priority for free time usage.

But let’s do a bit of improvisation here.

Processes are an extension of the object orientention concept. Or rather, vice-versa. A process is an object. And what is being done between objects is communication. So if I wrap every plugin in an Adapter and this Adapter establishes the communication with the host then there is no concern about jails, chroots, and all that. It’s just another process and it can basically live and die on its own. The Adapter decouples the communication layers since the host does not know how that process talks, but the Adapter does. So the Adapter can talk to the process and when the process talks back to it, it will forward the message to the host in a way that both the host and the Adapter knows. And if the process goes crap, the Adapter can report to the host ah well, that thing just died, do you want me to try to restart it ? This is to say that communications are very much optimized in efficiency. This way could be I think close to how grace is added to the handling of plugins. This woudl be on the straightforward side of things.

Now, the option to have ‘independant plug-in host processes’ is something else. I do use it for DiscoDSP’s Vertigo, Discovery Pro and Bliss as well as Redux, because these guys cannot cohabit with any of the u-he synths. It’s either one company’s products or the other, not both. So I told Bitwig to apply that option to the DiscoDSP and Redux plugins only and they can run fine alongside the u-he plugins. For someone who gets irritated at the slight perception of a latency delay while recording acoustic guitar, I can say they all run just fine. That aspect of Bitwig plugin handling is the most interesting one. It might have to do with exploiting modern CPU characteristics, below the use of object-oriented concepts, I don’t know. Lightweight CPU-supported LXCs…

As for development, there would have to be a dedicated resource to explore and test in a duplicated believable test framework the options. Once the approach is tested and found solid, the implementation is another matter. It might be that the way the code is structured cannot allow for this kind of change, I don’t know. OTOH, Bitwig is a small team, coming from Ableton, but they have one advantage in that they are starting more or less from scratch in an era filled with countless previous DAW experiences, and with a fresh code base that can be immediately structured to the need of a new technical designs.

#72

@melva: I perfectly understand how to run plugins in other processes. You might recall that I also wrote JACK, which is 100% about distributing audio processing across process boundaries. There’s no technical issue to be solved. The problem is that it doesn’t scale and nobody currently writing code for Ardour is willing to put time into creating what is essentially a band-aid for misbehaving plugins. We feel that there are much more important things to work on, and limited resources (yes, less than Bitwig even) means that we have to make such choices. Would it be cool to opt to run specific individual plugins in their own processes? Sure. But if you really need to do that you can get 80% of the way there by just using JACK and a plugin host.

#73

The “rough edges” are that the configuration of the plugin host will not be a part of the Ardour session. If you use the Non Session Manager, you can restore both applications (Ardour plus the plugin host) in one step. I do not use NSM myself, but Ardour does support it.