#14

I guess the best of both worlds world be nice but maybe mixbus would be more preferable for that. In reality I do think it would be nice to see ardour’s stock eq and compressor etc have its own in-line gui, not for the sake of a mixbus workflow but just flexibility considering ardour has in-line plugin vu already. But maybe the in-line is more the plugin info such as level meters, vu meters and not actual plugin usage. Does sound kinda cool but sometimes are just cool thoughts but not feasible in reality.

#15

@Ben, that’s very good to hear! Thx. With regards to the “access and integrate into our own UI” it’s simply a case of removing the elements of MB32c that I still find a nuisance. All these niggles have been addressed in the forums and I completely accept the answers - basically my mods would break the ethos.

I will say though that I do think I achieve better sounding mixes with MB32c than I do with the equivalent tools in Reaper - for whatever reason that may be. And maybe more to the point, I really try not to overthink this aspect.

For the record, as to the few niggles;

  1. I made a Lua a tool to invert the phase of a region.
  2. I find the scribble strip is too small and the colour options also too limiting (I come from an era where ‘Mix recall’ meant going to the tape store and pulling the masking tape strip off the wall).
  3. Plugins should stay green wherever they are put in the chain.
  4. I’d love Lua access to the Menu bar.

There are a few even more miniscule things I keep getting tripped up by but as I get used to Lua I’m slowly knocking them off.

#16

Re 4: everything in the menu bar is an action, and can be invoked from Lua.
Re 3: pre- and post- fader colors are a part of the theme (look for gtk_processor_{pre,post}fader)

#17

per-region ‘polarity’ is not currently supported, but it has been on my wish list for years now. I bring it up regularly at our dev meetings but it has not yet made it to the top of the priority list.

-Ben at Harrison

#18

What is the use case for that? I don’t think it would have occurred to me to switch polarity in the middle of a track.

#19

@Chris: the reason this is on my personal list is because the region could be drawn inverted so you can see it match its ‘sibling’ tracks.

I’ve never had this problem, but it is conceivable that the polarity changes during a recording. Perhaps a long session spanning several songs, and on some of the songs someone bumped the mic-preamp phase button instead of a pad, or somesuch.

Another argument for doing it on a region basis is that you could cut/copy/paste the region to another track (to apply different processing to that part) and you wouldn’t have to remember to invert that track’s polarity to match.

-Ben

#20

Harrison is a company, why not hire some contractors to implement desired features in GPL Ardour, if Paul or Robin don’t have time to work on them? And then, if Paul or Robin don’t accept to merge those features, just keep them in GPL Mixbus.

#21

It’s not worth fixing something that isn’t broken. I understand that both programs are being developed together. And Harrison has a team of people involved in the project.

I think that the work of skilled coders is welcomed, so it’s worth applying if you have that kind of skill and passion. Aren’t open source projects like that?

#22

I would agree normally but here we’re talking about adding a feature (per-region polarity). I do not understand how having per-region polarity could impact negatively Ardour, keeping aside possible refactoring issues (which could actually benefit Ardour, in the long-run).

From a programming perspective, I can understand that it is desirable to avoid merge conflicts, as they waste precious time. But on the other hand, Harrison could ask the Ardour devs if it’s OK to implement that feature and if they get the OK, Harrison could hire a contractor to implement it (else, nobody does anything).

Actually, I think a bounty system would help Ardour grow but I understand that preparing the infrastructure for it can waste Paul’s time (even if there are existing sites like BountySource and now Ardour uses Gitea, which could replace BugZilla for both feature requests and merge requests, IMHO). I’ve contributed code to FLOSS projects in the past and IMHO one big obstacle to becoming a contributor is the size and complexity of a given codebase. Getting to the level needed to be able to contribute to Ardour without breaking anything requires a time investment and without funding, only people paid to work on Ardour by third parties and (the really small subset of) committed hobbyists/musicians with solid C++ skills can realistically afford to do it, everyone in between is probably better off working on smaller projects.

#23

It is not that no one is available to work on that feature, but there are always multiple requested fixes and changes outstanding. Ben stated it clearly:

When it becomes important enough to enough users I am sure it will be added. If only DeeKay789 and Ben care it may be a while.

#24

@Paul, Re 4. I do get that, I actually want to append my own (session specific) menu bar to the existing structure. It’s a preference not a necessity!

Re. 3 Thx for the gtk… pointer. I’ll take a look this w/e.

#25

@Chris, In my case it I’ve needed it after backline rearranging after a period of time has elapsed during the session and after the drums have perhaps been cleaned and processed. An alignment check no longer works globally on tracks as they’ve been cut and chopped. If I feel the impact of the mix has lost something then I’ll usually reach for the alignment tools - and at that point I’m often then flipping and flopping bars with the bass and any augmentation FX. It’s not a hard slog to bounce the region to a new track, flip it and then reinsert over the original but I generally take the view that if I have to do something more than a couple of times then it’s time the computer did that for me - hence Lua.

#26

@fretboard, I do agree and even from my now privileged position of retired sound engineer and retired Software engineer. But, I’m sure you are aware of feature creep in s/ware design and also the black hole that is the pursuit of the ‘edge case’ feature. I don’t want that to get in the way of Ardour/Harrison core dev. I feel I should be responsible for my own edge case features, and yes I do appreciate that I can do it myself and I don’t need to be paid. It’s only possible of course because Paul et al have made it available. And to your point, yes, the code base is somewhat overwhelming when just skirting around it as I do - which would make it non viable for anyone outside the inner sanctum.

#27

There is one since at least 10 years. It never was viable.

The two largest bounties so far:

Then there are lot issues under $100 e.g.

It is a nice bonus to collect, but not really an incentive.

We do like to move to gitea for tracking issues. But when doing so there should use SSO - the user-account should be shared with the download system, nightly access, and forum. Also all bug reports from mantis (not bugzilla) need to be copied over.

Well, there are many who contribute code, without direct monetary compensation (although Paul shares some of the donations with prolific devs who regularly send pull-requests).

Besides, harrisonconsoles.com does hire contractors to work on Ardour. The problem is that there is “so much to do, and so little time” :slight_smile:

2 Likes
#28

I’ve been using Ardour for many years, not only as a user but also a packager. I consider myself a huge fan of Ardour: I paid for it when I could afford it, I actually read and modified some of its source code (and dabbled with the Lua API), I contributed to the bug tracker, I regularly read this forum and even follow your work (repositories) and Paul’s (such as his posts on sites like HN and interviews) on the web.

And despite this, I did not know about the existence of bug bounties! Turns out it’s a field (Sponsorship) on MantisBT. So maybe the idea is right, but the system (bolted-on to tickets on the issue tracker, with no certainty that the money will actually be sent!) is IMHO not suited for attracting professionally-minded contributors, because there are issues of visibility, usability and trust.

A disclaimer: I hugely appreciate that some kind users offered their money. That’s more than most users (including myself) do, really, and if everyone pledged $3 to a ticket of their liking, the cumulative amounts would be decent. So please, don’t interpret my next paragraph as against what some kind and fair people decided to offer, but rather as evidence that the current system is not working.

Once what I said above is clear, I have to say that those rates are not acceptable for any programmer and I can’t blame anyone for not taking them. One thing is volunteering your time for free (which I myself gladly did for some smaller projects), another is accepting as little as $25 for a feature which likely requires at least some hours of study of the Ardour codebase before being able to write any code. I am not saying a FLOSS project should pay market rates for programmer’s time, just that IMHO a proper bug system has to offer amounts of money which are at the very least encouraging. IMHO, the only people willing to work for that sum can either earn more on Fiverr or Upwork or work on it for free because they are hobbyists with another day job or retired.

A more structured way bounty program is also likely to attract companies and musicians who work with Ardour and not just hackers who can operate an issue tracker.

In short, volunteering is hugely noble and important but so is paid work when it contributes to the common good (GPL’d software, in this case). Some things (such as contributing to Ardour) require advanced skills, which are are highly remunerated in the job market. In order to attract professional contributors, bounties need to be at the very least proportional to the hours of work needed and parametrized (at the very least) to a programmer’s average salary in a developing country, other than trusted (so, it’s OK if a trusted entity actually collects the bounty money as soon as it posted, paying it after the commits are merged).

Besides, harrisonconsoles.com does hire contractors to work on Ardour. The problem is that there is “so much to do, and so little time” :slight_smile:

Did not know about it, I apologize for having jumped to wrong conclusions! But it’d be nice (for Harrison too, it’s good PR!) if users knew more about Harrison’s contributions to Ardour.

1 Like
#29

I see that MantisBT has a REST API, as Gitea does. I can’t promise anything because I don’t have experience with either API (and don’t know how complete they are) but I do have experience with APIs and data-plumbing; if you want, you can have my help with the ticket migration free as in beer (gotta give back to Ardour!).

#30

That is very appreciated. It is probably easier to using direct access to database rather than indirection via API. It is getting a bit off-topic here, hence I’ve opened 0009170: Migrate bug-tracker to gitea - MantisBT

PS. Since Ardour 7.2-19 there is now a per-region polarity invert control (Region > Gain, or Region > Properties).

#31

It seems that build has not got to Mixbus32C v8.1.378 yet. Maybe I’m looking in the wrong place?

#32

I agree on every point. However, from direct experience it is so so difficult to set a universal fee that ‘professionals’ in a global market place see as attractive. I do say, and with direct experience again, some bug fixing we had put out in Asia came back impressively professional, competent and functional for a fee that didn’t attract anyone from my country (UK). Point being, there can and should be more than just a financial bounty for supporting Ardour. I am also fully aware that my own position now as a free hobbyist is very privileged and I would be somewhat biased against taking a fee for myself if I thought that fee could go to someone who would make better use of it. That all sounds rather trite and philanthropic. I can assure you I’m not, I am a genuine greedy b’stard - but limited to my own little kingdom :slight_smile:

#33

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.