to be more precise:
in 10.8.3 ( mountain lion ), when jack ( last b version) is launched, the jack router is found automatically in the audio devices: no need to create an agregate device first… thats why I was looking for not necessary things…
When started via Jackpilot, Jackpilot will try to use the capture and playback devices together yes. But that isn’t the same as when Jack starts for the record.
Seabladeactually, these days it is the same - jackd itself programmatically creates an aggregate device if necessary. it has not been necessary to define this for jack for at least 18 months or more. So if you start JACK from JackPilot, QJackctl or the command line on OS X, no need to worry about aggregate devices.
HOWEVER ... ardour will only look for, find and offer duplex devices in its own audioengine startup dialog. So if you want to start JACK via Ardour, and you want to use the builtin device, you need to first create an aggregate device. This is all described at http://manual.ardour.org/
Hmm glad to be corrected of course, I wasn’t aware that Jack was automatically doing that now. I knew you could specify it on the command line, but that was all I knew about(Combined with Jackpilot of course).
SeabladeAny updates on this topic?
it would be so nice…
It is still being worked on, that is about all the update that there is right now to my knowledge.
SeabladeI guess good things takes time…
Maybe, we’ll see it in May?
I was really hoping to try it in April. Excited to try the new MIDI features.
OK, I just have to ask… Any date for full working version for Mac OS?
(reposted from the ardour-users mailing list …)
No there is no more word than what is on the page.
3.x on OS X has been inadequately tested because there are so few technical users of the app on that platform - by “technical users” I am referring to people willing and able to build the program from source and/or get useful backtraces and be involved in debugging issues.
Once there is more feedback on the state of the demo/beta copy I have released, it will be possible to assess whether this is a suitable release candidate or not. I am already aware that there are issues, for example, with various key bindings.
I will be checking the site more often then.
Thanks Paul for all your work!
I thought when I checked the site a few days ago, it said that there would be a Mac release by 9 May (did I misunderstand?). If I understand the situation correctly now, there is none, and so another release date commitment has come and gone. I would have much preferred a vague date that could be kept to a broken commitment.
FWIW, I’m sort of a “technical user” and would be happy to test and provide what info I can. However, I know that when I have reported Mac bugs in the past and offered to try to help fixing them, I’ve received little response. Perhaps this is the issue here?
I love Ardour 2, I’m really looking forward to Ardour 3 for Mac, and I think Paul and company have done some incredible work. I just wanted to point out a few issues in the interest of keeping this project viable.
There is a beta version out being tested, but the issue is testing is clsoed to the people that can really help, which essentially means those that can compile from git to test and debug. The best option is honestly not to look for a release date in my opinion, but I don’t speak for Paul:)
Seablade“testing is closed to the people that can really help” – that’s the point: I probably could really help; I could almost certainly build this thing from source and test it, but I’m not going to go through all that trouble unless I think it’s worth it.
“The best option is honestly not to look for a release date” – Perhaps so, but at this point, two dates have been promised and not met. Under these circumstances, I don’t think it’s unreasonable to ask what’s going on. This goes double now that Ardour is no longer free as in beer: if I’m paying for something, I expect a bit of a higher standard as far as support goes.
Having been involved in several industries with release dates, particularly in software, I don’t trust any of them unless I know it is ready for production. Period. This is my personal view so take it with a grain of salt.
that's the point: I probably *could* really help; I could almost certainly build this thing from source and test it, but I'm not going to go through all that trouble unless I think it's worth it.
Well if it isn’t worth the time to you, then wait for the release. Honestly this is what I am doing for the most part, and I did some of the original work to get A3 compiling on OS X, so I am well aware that I can do it, but I don’t have the time to do it right now, I am to busy making a living these days sadly.
Perhaps so, but at this point, two dates have been promised and not met.
Treat them as goals, not promises. That being said the current beta was out before the second date was met, so not met int he way many people were expecting, but there was demonstratable progress. Again my own personal opinion.
Seablade“testing” means primarily using either a self-build or a binary from ardour.org AND being involved in debugging issues that I cannot reproduce.
many people on OS X probably over-estimate the resources available for ardour on that platform. I do most of primary development and testing on Linux, randomly switching to OS X from time to time to check on how things are going for that platform. there are almost no other active developers at this time. filing bug reports for ardour on OS X is an excellent idea, but the simple act of filing is not likely to lead to much action. this is certainly the case until i get back from travels in early June.
OS X users need to understand that for a project that generates barely $50k/year of gross revenue, the absence of the kind of technical users that we see on Linux (people who are willing to really get involved with design, testing and debugging) along with the fact that Ardour gets developed primarily on Linux (which is a much friendlier environment for developers, even if not for users) means that although I want to see Ardour 3 out on OS X ASAP, the “as possible” part is highly constrained.
I’ve said it before and I’ll say it again: most OS X users expect to find the program working. Many Linux users are happy to dig in and help me and others fix up the reasons why it doesn’t. The difference in these two attitudes, combined with the low revenue, open source nature of the Ardour, accounts for a lot of the difference in how the release schedule works.
"the absence of the kind of technical users that we see on Linux (people who are willing to really get involved with design, testing and debugging) "
Really? I’m quite surprised by this. (For the record, I’m willing to get involved this way as time permits.)
It does seem to me, though, that it’s gonna be hard to find people who are both experienced developers and recording engineers, and yet have the time to contribute to a volunteer project.
"most OS X users expect to find the program working. Many Linux users are happy to dig in and help me and others fix up the reasons why it doesn’t. "
I expect to find the program working if a release is advertised as stable. If I find a bug, I’m happy to dig in and help fix it (I’m a pretty experienced developer, though I know little about working with audio); it just seems that every time I’ve asked “how can I help fix this bug that I’ve found?”, I’ve gotten no useful response, to the point where I’ve occasionally gotten the sense that you don’t really want help. I’m sure that’s not the case; it’s just worth being aware of.
Put another way, the attitude here is (or was last time I submitted a bug report, which was admittedly a whole ago) strikingly different from other open-source projects I’m involved with. In other OSS projects, when I report a bug, people are all over it making suggestions or (if I’ve offered a patch) incorporating patches. In this project, I really got the sense that the attitude was “thanks for reporting the bug, now wait for Paul to address it; don’t even try to patch”. I’m happy to hear that that’s not what you actually want, but it certainly discouraged me from trying to help in the past.
Anyway, the fact remains that lots of Ardour users are on Mac OS (I know several just in my own circle of colleagues, and I’ve been encouraging people to switch, often successfully), and we would really like to have Mac OS not be a second-class citizen when it comes to Ardour releases. I’m trying to provide constructive suggestions (including offering my own help as possible) to make that happen.
In this project, I really got the sense that the attitude was "thanks for reporting the bug, now wait for Paul to address it; don't even try to patch"
I will say the desire would be both to report the bug, and go ahead and submit a patch. The catch is that often times things are considered bugs when they are intentional, because one person doesn’t utilize it in their workflow, while another does. So just because a patch exists doesn’t mean it will be accepted of course, but it makes it FAR more likely that if it is a bug it will get fixed via such a patch:)
And if the patch sits around without anyone having seen it for a while ping me on IRC and I will look at it. The reason bug reports don’t get jumped on is because, like you said, there are very few developers with an interest in audio to help out in such a project, so there are very few people capable of jumping on the bug report so it is a matter of having to wait till there is time to address it. Patches obviously speed this up tremendously. I would, however, suggest that if you want to do work on Ardour’s code, you join the IRC channel where a lot of development and testing tends to happen.
SeabladeTreat [release dates] as goals, not promises.
I think the best way of making sure something isn’t treated as a commitment is to simply not state it as one. “FooWriter will be available on June 10” is a statement of commitment. “We hope to have a working release of FooWriter by June 10” is a statement of a goal. Other software development projects make this distinction routinely; I think Ardour probably should too.