OvertoneDSP plugins

aw this would be very strange after they just launched the linux-vst versions… can mike@overtonedsp clarify?

Linux has been taking a back seat for quite awhile with OverToneDSP. From their Facebook page, they seem to be prioritising Windows and Mac.

The fact that they have completely stripped the website of any mention of Linux and actively state “Professional Audio Software and Plug-ins for Windows and Mac OS X” is sad news, especially with no mention of dropping Linux support. They seem to have done it silently. Given their previous support of Linux, even in name, I think it is strange to drop support silently.

The zip file downloads from Overtone still have linux versions. Well, I certainly hope Overtone continues its support of linux.

By all due respect for the lamenting and mourning.
It’s impressive that mike@overtonedsp supported linux in the first place and made an effort to get his point across in an audio niche market. I am aware that software in here should be free as in free-speech, but as far as I know there are more compressors out there than DAWs. It is arguably much more difficult to generate an income with them, if they are your main income.
For Ardour, I think, there has to be a notion in how far to push the free-as-in-speech software (concept, philosophy, ?ideology?) for the resources at hand, and especially for maintaining the interconnectivity of Ardour. I’d rather see good closed source plugins appear making Ardour attractive for the time being than plugins, which are koscher code wise, but are badly maintained.
To put it another way, as long as mike@overtonedsp plugins are contained for themselves, I do not see a problem in supporting them from the open source side. However, the way of communication in the forums tell otherwise. It is ironic that a closed source developer is urged to justify his programming efforts in here in every point and is dropped in every way (I agree his tone is rough).
Nevertheless, the Ardour mindset is currently making it difficult to reach solutions with proprietary standards, it seems. This is not the main objective of open source I believe, or is ,freedom" a agenda to subvert everything ,non-free"?

@t0by: how is Ardour making it difficult to reach solutions with proprietary standards? x42 has listed several commercial + proprietary plugins using the VST API that work just fine in Ardour (and other hosts). In fact, this entire thread basically got started because of interactions between Pianoteq (a proprietary plugin which works with Ardour) and some/all OvertoneDSP plugins (also proprietary plugins which work with Ardour but not, apparently, when Pianoteq is also used).

We try to make suggestions to plugin developers and ask them questions. We can’t be responsible when they tell us “I know more about this than you do”, and basically go silent when asked questions that would us help understand their own engineering choices and considering whether or not Ardour needs changes made.

,proprietary standards" was badly phrased by myself. I meant the closed source code as mike@overtonedsp is offering.

It’s more the whole attitude on this subject that disturbs me, - which hasn’t changed very much over the years now I believe.
Going silent happens, but a conversation is more than one person. Instead of reaching an agreement where both ,parties" can gain momentum in their projects, maybe even a constructive dialogue, a nit picking lecturing frenzy has been set in place for years I’d say. And it’s tiring to see it again and again explicitly and in between the lines.

Maybe I’m a little oversensitive, but it’s kind of revealing, when person number one advertises a new EQ or updated EQ-Bundle, - who is also trying to make a living and offering it for next to nothing to get people interested, and then developer number two quickly throws in a ,free" open source EQ thereafter, to later mention in a side note that he was bothered with the closed source idea of the first plugin. In an academic bubble this is fully understandable: “Everything is free, I can program and publish whatever and whenever I want…etc.” At the at the same time when lives of people get involved, to me this behaviour is not even “Ubuntu” anymore. It’s basically using Open Source ideas for wage dumping and competing against other businesses that could have been a business partner.
Ok, maybe Adam Smith would still be happy here, but considering the work that still can be stuck into Ardour and the lack of any kind of collaboration between mike@overtonedsp and the ardour project makes certain moves and communication strategies seem arbitrary.
(I hope I am mistaken.)

We are 100% happy to communicate with Mike, and we totally understand his decision to develop proprietary code. I also personally understand his decision to de-emphasize Linux, based on the apparent size and economic value of the Linux plugin “marketplace”. I have explicitly promoted some of Mike’s past announcements about new plugin releases here on ardour.org, and we frequently point users on IRC towards his plugins.

The negative attitude that you detect comes from a sense of being lectured to, when what we are actually trying to do is to work toward an understanding of why his plugins in particular seem to have problems that other proprietary plugins do not. It has nothing to do with proprietary vs. free software. It has everything to do with a clear technical understanding of engineering choices and designs, so that if necessary and if possible Ardour can accomodate an important, useful and high quality set of plugins. We’ve had to do this for other plugins on other platforms - just a few weeks ago I did a monumentally low-level hack to fix the effect that Addictive Drums 2 from XLN has on OS X systems with Retina screens. In that particular case, we didn’t need to interact with the plugin developer because it was clear that the problem wasn’t in their code (it wasn’t in Ardour’s code either - an interesting intersection of very badly performing code from Apple with some very wierd code design in GTK+). But we can’t do it with any plugin developer unless they have a full conversation with us (in public or in private) about the engineering choices they’ve made, so that we can understand how (and if) we might accomdate them.

Mike isn’t making it easier for himself, as a businessman with developer clashes aside.

First of all he’s publicly displayed a sour and pessimistic attitude towards the linux side of his business, and those customers. There’s nothing wrong with feeling this way, but you can’t just be exuding negativity if you want people to buy your products, promote them to friends or donate to you, especially when your product is not a must-buy. As a business you need to maintain a positive and personable public front as this sentiment trickles downstream to your users.

For example, send U-He an email of any kind and see what kind of response you get. They’re a star example of how to interact with your customers and maintain positive sentiment.
A cursory glance at their linux public beta thread shows you it’s certainly not a thankless job if you do it right, even when half the plugins aren’t even working yet, and they’re asking for a lot more money than OtDSP is.

If you’re gonna run a business you need to be adaptive to the needs of the market. If people are not buying your stuff, you’re not convincing them of the value of your product.
That’s just how the world works. 95% of businesses fail in the first 5 years.

Remember when they were LinuxDSP? Dude wanted to make a bunch of money and didn’t have the chops to go head to head with Waves or UAD so he figured the Linux market was his ticket. Didn’t work out that way. Good riddance.

Ok at this point I am going to remind folks to be respectful at least. Unless you are discussing either the technical issues discussed here, the OP’s problem, or have new information about the status of LinuxDSP, I would think two or three times before posting. Like the plugins or not, Mike was one of the first people to be willing to try plugin development on Linux, was responsible for the initial LinuxVST implementation in Ardour that other plugins are using.

    Seablade

@projectMalamute: this post is severely inappropriate. Please don’t post like stuff again. There is a bit of a disagreement on display in this thread between Mike and a couple of Ardour developers, but we’re committed to keeping that professional and technically focused. Personal remarks and disparagement are not appropriate and are not welcome.

I think it’s a moot point, dude took his ball and went home, but whatever.

Good luck getting that stuff to work a couple years down the road.

I feel that I must come with some praise for OvertoneDSP. I have used the plugins for years, especially the reverbs, Black EQ and later the 210.

Everything has an end, but an end is also often a beginning. If OvertoneDSP comes back and it looks like they mean Linux-business, then I’ll be the first to use the products again and of course by new licenses when I find that that is a good thing to do.

The plugins have worked as expected time after time trough the years. This reliability is comparable with the one you experience with the studio hardware and instruments you rely on every time. OvertoneDSP has had a policy that results in plugins that work for years, I will never forget that. One or maybe the most important thing one have to know when working with studio related stuff is to know the gear. OvertoneDSP clearly appears to have the studio and workflow experience that makes me know their products.

So OvertoneDSP: -Thanks for the ride so far, you have been a big and very important part of my studio experience the last years. I hope we see each other in the Linux versions of your plugins again later. I continue to use Linux for my studio work and it’s getting easier and easier because more and more fantastic products shows up. I hope that you to find it meaningful to jump on the Linux bandwagon again later.

Thanks!

Nothing new here, basically, just some cuurent observations and a thought. In a current Mixbus 32C session (Linux Mint 17) there are 4 instances of DYN4000, one of PTC-2A. 3 instances of Harrison XT plugins, 2 u-he Uhbik-A, 2 u-he Presswrk and one u-he Satin. 7 instances of Robin’s x42 EQ, and 2 u-he Zebra HZ.

Adding any OvertoneDSP to any track will crash instantly Mixbus 32C. The kind of crash that Mixbus is not aware of since it will not report the crash at the next start-up. I would like to add more OvertoneDSP plugins but it is not possible at all.

I have removed all plugins from the session, everything. Closed Mixbus and restarted it. Added a DYN4000. Immediate crash.
I have used a lot of u-he plugins in sessions and never had this problem. Same with the Harrison plugins.

Created a new session, added one track, added a DYN4000 to it. Crash.

What if…, what if the problem remains in the machine even after Mixbus (Ardour) is terminated ?

Restarted the machine. Opened the new session. Added the track (since it crashed last time it was not saved), then added the DYN4000. Loads all right.

Whatever the problem is, it can remain present in RAM. Or temp files that are erased when rebooting.

Using Bitwig on the same Linux Mint 17, any number of OvertoneDSP plugins can be loaded in conjunction with any plugins from u-he, Harrison and DiscoDSP.

AFAICS, while there would be ‘something wrong’ with the OvertoneDSP plugins, the handling of plugins in Bitwig is seemingly more rugged.

What would be a better approach ? Would a ‘defensive’ approach be one that could guarantee stability under dire circumstances, no matter if this or that aspect of a library is rightly used or not ?

Bitwig runs at least VST plugins in seperate processes, so certain issues wouldn’t exist in the same way there, and even if a plugin crashes it won’t take down the host. There are tradeoffs with latency and performance IIRC though, so valid reasons for both approaches.

   Seablade

It might be that separate processes are always used in Bitwig. Although the in the options regarding this I have only specified the DiscoDSP plugins to run as ‘independant plug-in host process’. This can be set on a per plug-in basis. All other plugins except for the DiscoDPS ones will run using the default Bitwig way, whatever that is.

Considering the latency I have some doubts about mainly from the business aspect of it. I have exprienced how latency can be disruptive when the Linux audi system was not fine-tuned and there was discrpancy between what I heard in the headphones and the acoustic guitar I was playing. It does not take that much to make it quite difficult to record anything. Would Bitwig, a company selling software at some $300 a piece and teaming up with other companies and having substantial long term projects, make a product that professional producers would start to put down because of its latency problems or any phasing issues and thus shooting themseleves, if the default is to run every plugin as a spearate process ? Wouldn’t they already have faced thatin basic development and foudn a solution assuring the stability of their product, eg. a graceful handling at least ?

1 + 1 makes 2 and it is extremely easy to conceive that any use of ‘jails’ to isolate process is not free and because of that will be detrimental to audio processing. But is that really the final word ?

@melva

Most people do not use software monitoring of a signal they are recording these days, especially not with plugins inline. Not to say noone does it, it is not uncommon in the live sound world for instance to run effects on a seperate machine and route a console through it. But with so many audio devices supporting hardware near zero latency for monitoring purposes, and many of these even having built in processing for EQ, FX, etc. there is very little reason not to do that anymore. Aside from that when it comes to phasing etc. that is what latency compensation is for, which is much easier to do with already recorded material, and most DAWs at this point do already, including Ardour and I am fairly certain Bitwig. And yes I believe the default is to run plugins as seperate processes but am not sure.

Now I never said how much latency might be involved, I don’t know because I have never tested, I am just repeating what little I have been told about the differences at this point from people that would know. However yes certain amounts of latency are undetectable, typically under 10mS is undetectable to most, and only a few hear down to 3mS(Which equates to about the amount of time it takes sound to travel 10 ft, or 3 ft respectively in air) These are numbers typically attained these days on many modern recording rigs, even with software monitoring. If you are hearing it and it is noticable, it is likely you were dealing with latencies probably fairly significantly larger than these numbers for the record.

1 + 1 makes 2 and it is extremely easy to conceive that any use of 'jails' to isolate process is not free and because of that will be detrimental to audio processing. But is that really the final word ?

Not real sure what you are asking here?

    Seablade

@melva: I have explained so many times before that even on a modern processor, switching to a different process, executing it for a while and then switching back has costs at the hardware level that (a) you cannot escape (b) do not scale to seriously large sessions with plugin configurations approximating a mixing console.

if you don’t want to believe me, the lead developer of Ardour, the original developer of JACK and one of the 3 people who made running Windows VST plugins on Linux possible in the first place, then go ask Bitwig and get one of their developers to explain the runtime cost of executing 3 plugins per track/bus in a separate process for a 32 track session. Once you get an answer, come back and tell us.

That’s interesting that you’re getting these crashes. I have also been experiencing similar crashes but have been unable to narrow them down to any particular plugin, so far it seems to me that it is using convolution type reverbs which cause it. That said, I have been using the DYN4000 and the free de-esser plugin as well so perhaps these are causing a problem. If it is these plugins then sometimes they are ok and sometimes not. I have posted bug reports and begged for help trying to find the culprit but apparently the crash or memory corruption happens outside of what the backtrace is measuring/recording so it is impossible to see the cause.

Some kind of more robust plugin processing in ardour would be most welcome from my perspective because these types of crashes have always been a problem for me because of one plugin or another. In v5 I gave it another try and found everything much more stable but then a couple of point releases later (or different combinations of plugins used by chance) and I am back to randomly vanishing ardour with no backups saved from the opened session. To me stability would be worth almost any other sacrifice, if software crashes and you lose work then little else is important.

@seablade: yes, at 10ms and below, latency, at least in my use case when recording acoustic guitar with the headphones on (I need to hear the other tracks after all) the latency is not perceived. I have used jack_iodelay to measure this when optimizing the Linux audio subsystem.