Heads up. Ardour 3.2 is now available.

[StudioDave]

...
It may be better to modify the A3 linuxVST code (in linux_vst_support.cc) perhaps it should look for 'VSTPluginMain' too? Unfortunately I don't have a machine set up to build A3 at the moment so I can't test any of this.

Thanks, Mike, I'll give it a test after I walk the dog. I'll leave message here after some tests.

Best,

dp

[urlwolf]

@studioDave: I can load triceratops fine on A3...

[linuxdsp]

@falkTX: A3 is still under development - even though they've reached the 3.0 milestone, and I think Paul and the other devs have no problem with sensible suggestions / improvements / patches - you could either submit it as a feature request (though I think it will likely get assigned a low priority - or submit the actual patch, which will likely see it implemented quicker).

[tnovelli]

I've read a lot of Paul's post on his forums he seems relatively unconcerned about a lot of things. I wish there was another option that suited me. I feel the same way about ubuntu.

Yep, open-source bloatware is just as bad as proprietary crap! Qtractor is a lot simpler than Ardour, and better at MIDI... unfortunately it still requires JACK which (IMHO) is another piece of Paul Davis insanity that doesn't play nice with other LInux apps. These damn guys with too much money and ambition and not enough sense...

[studio32]

unfortunately it still requires JACK which (IMHO) is another piece of Paul Davis insanity that doesn't play nice with other LInux apps. These damn guys with too much money and ambition and not enough sense...

It's fine to criticize the software or it's code and even support. But personal attacks are not appropriate in this case imo.

[wolftune]

…But personal attacks are not appropriate in this case imo.

Personal attacks are never appropriate in any case, unless we don't care about having an effective and productive community.

[tnovelli]

Personal attacks are never appropriate in any case, unless we don't care about having an effective and productive community.

True. I don't exactly know where to draw the line on this... but once in a while, we need to say how we feel. I am exasperated.

It's not really personal - Davis and Shuttleworth are just two prominent examples in the open-source community of the "tons of cash can be counterproductive" problem. It's more of a well-known problem in startups and corporate software projects. "We've done big things before... we have virtually unlimited resources... let's build the ultimate thing!" Years later, you've exhausted your resources and all you have to show for it is a few million lines of unmaintainable obsolete code.

It won't attract Mac and Windows users but I'm pretty sure that in the long run we'd be better off with the lean-and-mean approach.

[wolftune]

I agree mostly. The more I've learned about the FLOSS world, the more I think lean-modular-yet-integrated is ideal. We need things that work together but are in distinct modules. So the NON stuff looks like the right direction. I don't think the funding is itself the cause of the problem, but it definitely allows for problems that might not otherwise arise.

[bluebell]

I agree mostly. The more I've learned about the FLOSS world, the more I think lean-modular-yet-integrated is ideal. We need things that work together but are in distinct modules. So the NON stuff looks like the right direction. I don't think the funding is itself the cause of the problem, but it definitely allows for problems that might not otherwise arise.

It's fine to have one-job-one-tool-stuff if ...
1.) the whole setup can be saved/restored with all its settings
2.) there is a working latency compensationen overall

The second part seems to be an ever-unfulfilled wish. Even integrated DAWs don't do it properly. Rosegarden doesn't do latency compensation for audio tracks, Ardour for subgroups. When I irc'd with non's author (I guess he was it it turned out that latency isn't a problem for some programmers. For me it is. Plugins like 10 band graphical EQ or autotalent do have a noticeble delay. My solution at the moment is to live with Rosegarden's lack of latency compensation for audio tracks and shift them accordingly.

For Rosegarden users: My tiny patch to fix an off-by-one latency compensation bug will be included in the next release as I understand. It's accepted and in the source code now. See http://sourceforge.net/p/rosegarden/bugs/1358/

[raboof]

turned out that latency isn't a problem for some programmers.

Strange...

For Rosegarden users: My tiny patch to fix an off-by-one latency compensation bug will be included in the next release as I understand. It's accepted and in the source code now. See http://sourceforge.net/p/rosegarden/bugs/1358/

Cool congratulations!

[wolftune]

I must say, I agree completely! Latency compensation and being able to save the whole set of things as a unit are absolutely essential to modularity working.
Non clearly is doing what's feasible for the latter with Non Session Manager, but latency compensation is a serious and important issue!!

[male]

I agree mostly. The more I've learned about the FLOSS world, the more I think lean-modular-yet-integrated is ideal. We need things that work together but are in distinct modules. So the NON stuff looks like the right direction. I don't think the funding is itself the cause of the problem, but it definitely allows for problems that might not otherwise arise.

It's fine to have one-job-one-tool-stuff if ...
1.) the whole setup can be saved/restored with all its settings
2.) there is a working latency compensationen overall

The second part seems to be an ever-unfulfilled wish. Even integrated DAWs don't do it properly. Rosegarden doesn't do latency compensation for audio tracks, Ardour for subgroups. When I irc'd with non's author (I guess he was it it turned out that latency isn't a problem for some programmers. For me it is. Plugins like 10 band graphical EQ or autotalent do have a noticeble delay. My solution at the moment is to live with Rosegarden's lack of latency compensation for audio tracks and shift them accordingly.

For Rosegarden users: My tiny patch to fix an off-by-one latency compensation bug will be included in the next release as I understand. It's accepted and in the source code now. See http://sourceforge.net/p/rosegarden/bugs/1358/

That's not very fair. I spent a good deal of effort thinking about and working on latency compensation in Non. In the end, I ran into an unfortunate barrier: the JACK latency reporting API was completely useless for actually doing what it claimed. I believe it has been updated since then, but I have not had the time or the need to dig into it and find out if it's been sufficiently fixed to actually allow for port-level latency compensation. The fact of the matter is, there are very few programs and plugins that actually introduce any latecny at all--and, when they, do, they usually don't report it in any way that would allow it to be compensated for. Yes, it's a problem, but not a common one, and one that might never be solved completely anyway due to the requirement that programs/plugins accurately report their latency.

[wolftune]

Well, yes, perfection will never be reached. But clearly there needs to be a requirement / expectation that programs should always be designed to report their latency. Anyway, glad you are acknowledging the issue.

[bluebell]

It's fine to have one-job-one-tool-stuff if ...
1.) the whole setup can be saved/restored with all its settings
2.) there is a working latency compensationen overall

The second part seems to be an ever-unfulfilled wish. Even integrated DAWs don't do it properly. Rosegarden doesn't do latency compensation for audio tracks, Ardour for subgroups. When I irc'd with non's author (I guess he was it it turned out that latency isn't a problem for some programmers. For me it is. Plugins like 10 band graphical EQ or autotalent do have a noticeble delay. My solution at the moment is to live with Rosegarden's lack of latency compensation for audio tracks and shift them accordingly.

For Rosegarden users: My tiny patch to fix an off-by-one latency compensation bug will be included in the next release as I understand. It's accepted and in the source code now. See http://sourceforge.net/p/rosegarden/bugs/1358/

That's not very fair. I spent a good deal of effort thinking about and working on latency compensation in Non. In the end, I ran into an unfortunate barrier: the JACK latency reporting API was completely useless for actually doing what it claimed. I believe it has been updated since then, but I have not had the time or the need to dig into it and find out if it's been sufficiently fixed to actually allow for port-level latency compensation. The fact of the matter is, there are very few programs and plugins that actually introduce any latecny at all--and, when they, do, they usually don't report it in any way that would allow it to be compensated for. Yes, it's a problem, but not a common one, and one that might never be solved completely anyway due to the requirement that programs/plugins accurately report their latency.

Why not fair? You told me latency is no problem for you since plugins don't cause a noticable delay. Maybe I misunderstood you and you really meant that's just not yet at your shortlist.

I never did JACK programming but there must be some reasonable exact way of determining latency, at least for the internal processing by plugins. Rosegarden does it well for tracks with DSSI synth plugins. Maybe it's more difficult for audio tracks and even impossible for tracks that trigger external MIDI instruments.

But the need is there:
- Automatic latency compensation where it's possible
- Offset in milliseconds (most important negative one) to add some manual correction

A negative offset can - of course - not be honored for time 0 at the beginning but most people don't start their songs there.

[male]

It's fine to have one-job-one-tool-stuff if ...
1.) the whole setup can be saved/restored with all its settings
2.) there is a working latency compensationen overall

The second part seems to be an ever-unfulfilled wish. Even integrated DAWs don't do it properly. Rosegarden doesn't do latency compensation for audio tracks, Ardour for subgroups. When I irc'd with non's author (I guess he was it it turned out that latency isn't a problem for some programmers. For me it is. Plugins like 10 band graphical EQ or autotalent do have a noticeble delay. My solution at the moment is to live with Rosegarden's lack of latency compensation for audio tracks and shift them accordingly.

For Rosegarden users: My tiny patch to fix an off-by-one latency compensation bug will be included in the next release as I understand. It's accepted and in the source code now. See http://sourceforge.net/p/rosegarden/bugs/1358/

That's not very fair. I spent a good deal of effort thinking about and working on latency compensation in Non. In the end, I ran into an unfortunate barrier: the JACK latency reporting API was completely useless for actually doing what it claimed. I believe it has been updated since then, but I have not had the time or the need to dig into it and find out if it's been sufficiently fixed to actually allow for port-level latency compensation. The fact of the matter is, there are very few programs and plugins that actually introduce any latecny at all--and, when they, do, they usually don't report it in any way that would allow it to be compensated for. Yes, it's a problem, but not a common one, and one that might never be solved completely anyway due to the requirement that programs/plugins accurately report their latency.

Why not fair? You told me latency is no problem for you since plugins don't cause a noticable delay. Maybe I misunderstood you and you really meant that's just not yet at your shortlist.

I never did JACK programming but there must be some reasonable exact way of determining latency, at least for the internal processing by plugins. Rosegarden does it well for tracks with DSSI synth plugins. Maybe it's more difficult for audio tracks and even impossible for tracks that trigger external MIDI instruments.

But the need is there:
- Automatic latency compensation where it's possible
- Offset in milliseconds (most important negative one) to add some manual correction

A negative offset can - of course - not be honored for time 0 at the beginning but most people don't start their songs there.

That's not how latency compensation works. It basically introduces a variable amount of latency on the playback of all tracks in order to align them with the track that has some built in latency. The kind of compensation done with plugins in internal routing has nothing to do with the JACK latency API (which was/is known to be useless), so that latency can be compensated for internally by monolithic hosts (if and *only* if the plugins themselves report their latency accurately). The problem is--that's not necessarily all the latency. Latency compensation is an all or nothing proposal--compensating for some latency is not enough--everything must be accounted for. With the (historical?) JACK latency API, this was literally impossible. So, even if you have a monolithic host, the whole thing breaks down as soon as you add a send/return or basically any JACK connection that isn't directly to a 'system' I/O port. This is a complex issue. One that the authors of the original JACK latency API didn't even understand when they cooked it up. It is not possible to automatically detect this latency, it *must* be reported by all plugins and applications and that information must be tracable through the JACK graph (imagine how one would attempt to automatically determine the latency of an echo, reverb, delay etc...) Allowing/forcing the user to adjust these delays manually is not viable. You'd have to sit there and scope everything and you'd probably end up introducing too much latency in the process of iteratively fiddling with the delays. You're very likely talking to the person who has spent the most time to date thinking about latency compensation in Linux Audio/JACK. It isn't because I don't care about the issue or don't think it's important but when you weigh all this complexity against the simple fact that 99% of the software introduces *zero* latency, it certainly doesn't place high on the priority list.