Ardour 5.0 released

[x42]

Actually, in Ardour's case the argument for scripting is significantly diminished by the fact that you can change ANYTHING you want to because of its open source nature.

We'll politely disagree here. The value of scripting is accessibility, or greater accessibility for the larger user base. C++, or learning C++ well enough to modify an open source daw is no small task and by nature will be far beyond the skill set of 99.9% of your user base. A more accurate way to express what you said above is...

"Anyone who is skilled enough with coding in C++ can change anything they want."

... which is, relative to the user base of any daw, a rather tiny group.

The actual motivation behind adding scripting to Ardour was "one off" cases. Some examples:

• a Button in the GUI to switch studio monitors
• voice-activated transport
• batch edit multiple regions or perform complex operations easier to script
• generate custom automation

...and similar things that are unlikely to be made available directly upstream in the DAW, even if they were C++.
Then the first scriptwriters during beta-testing showed up and priorities shifted..

Still, the question "to script or not to script" definitely depends on the case at hand.

Anyway, there's still a long way to go for complete script-integration in Ardour: e.g. scripted UIs & surfaces, expose more bindings, web-site with script collection(s) etc etc. It's a gradual slow process, mostly since we try to document and write an example for every exposed binding.

[LawrenceF]

Still, the question "to script or not to script" definitely depends on the case at hand.

True. You guys are developers so you develop with the source code. If you want to demonstrate the usefulness of the script interface to the great unwashed , maybe do something (more things) with it as a demo that will grab their attention.

There are maybe (dunno yet) lots of things that can be done there that maybe (dunno yet) haven't yet been done in the source and maybe isn't even on anyone's table or short list, like RegEx track renaming, auto coloring tracks by name, maybe if not already there selecting things by properties like selecting all muted clips, etc, etc. Obviously, it's hard to know what the more immediate opportunities might be without fully knowing the current capabilities.

My uses for scripting are almost always offline things like that, things that almost nobody builds into their source code for some unknown reason. I find it puzzling personally that these daws can do so many fantastic and complex things but then ask most of them to do something relatively simple like Notepad, RegEx replace 40 track names... and they draw a blank.

That's where scripting becomes valuable to me personally, mmv as usual, doing things that (apparently) almost nobody else wants or even plans to do in the source code.

[mr.ardour]

Lawrence - those all sounds like great reasons to use scripting. We hope to show how Lua can be used for all those kinds of things (note that we already have a scripts dir and welcome contributions).

But do note one feature of the development process: the work done yesterday by one person whose real name I don't know to add a single-action toggle for markers could probably have been done as a script, and that user would have been happy with that. But instead, they wrote source code that will be a part of the next release, making their (vetted) work accessible to all, presented in the "normal" way along with other editing operations. For some things, that's not appropriate. But often, it means precisely that Ardour can accumulate a series of little-used features that are still invaluable to a specific subset of users, who may not have any idea that they all need the same things.

Unless a DAW's scripting abilities also promote and facilitate sharing (and discovery) then every user who codes up a potentially useful piece of functionality is an island. We hope to avoid that (somehow) with Lua scripting in Ardour, but ultimately, source code modifications are an even more canonical way to get "things that (apparently) almost nobody else wants to or events plan to do" into the program.

Anyway, we're better off now that we have source code and scripting options as a way for users to extend and add functionality. As x42 noted above (who implemented everything related to scripting), there's still a lot of room to improve, simplify and extend what can be done, but there's also an almost unimaginable depth to what can be done already.

[LawrenceF]

Thanks. Just to be clear, here is kinda what I meant below.

Grab any popular daw in version 3,4,5, etc, etc, and something as simple as this below apparently never occurred to most developing them, that someone might drop in 30 track stems to mix and want to run simple functions to fix the track names or something, like capitalizing all the track names as one basic example here...

for r in Session:get_tracks():iter() do

r:set_name(r:name():gsub("^%l", string.upper))

end

That took all of 60 seconds in the script interface but you'd be hard pressed to find that as a built in function in any popular daw. Same goes with stripping numbers from track names (lead vocal_00123), prefacing track names with sequential numbers so that stem exports will line up sequentially on file systems in their correct order, or anything else like that, things that (all of it together) would likely take people with the source code all of an hour (excluding the GUI dialog for it all maybe).

In most products you can't even get a basic list of common musical or instrument names to even name anything with, you have to type it all in yourself all the time, like... the pre-computer days.

It's frustrating for me because I mostly mix other people's stems and most often have to do all of that stuff manually track by track like a cave man, in modern computers no less. So yes, do your mix engineer user base a favor and just build that kinda stuff in. It shouldn't take very long.

[x42]

Wow nice. an actual Ardour lua script! Kudos.

[teacue]

Great to see that Ardour now officially supports Windows!
Also great to see that Tempo Ramps are finally supported.
Does it mean that Ardour can now import the Midi Tempo Data of a Midi file?

BTW the last Mixbus version 3.6 just came out but I do not see any mention of the new Ardour 5 features.
Any idea when these new features will be included in Mixbus?

[mr.ardour]

Ardour still does not import tempo data from MIDI files (that really has nothing to do with with tempo ramping, since MIDI files cannot specify accelerando or ritardando). It isn't hard for us to code this - the problem is defining the workflow so that it works OK for most users. There are at least 4 (and perhaps) more options about what to do with the MIDI file's tempo information, and offering these choices to users in an obvious but non-intrusive way is much harder.

Quite a few of the features in Ardour 5.0 are already in Mixbus. The big exceptions are the tabbed interface, the a-* plugins and tempo ramps. My understanding is that they will show up in version 4.0 of Mixbus.

[classic]

Just to talk about something different about it I think this DAW also sounds greate IMO.

[LawrenceF]

Wow nice. an actual Ardour lua script! Kudos.

Not sure if that was sarcasm or not but thanks anyway. Here's a better one...

function factory () return function ()

-- this script will format all track names by...
-- capitalizing all words
-- trimming leading and trailing white spaces
-- strip and replace any underscores
-- optionally prefix with numeric series (if selected)

-- var to increment the track count for numeric prefix
curTrack = 1

-- iterate all tracks
for track in Session:get_tracks():iter() do

-- put the track name into a var
str = track:name()

-- remove numeric characters
str = str:gsub("[0123456789-]", "")

-- trim leading and trailing whitespace
str = str:gsub("^%s*(.-)%s*$", "%1")

-- capitalize every word
str = str.lower(str)
str = str.gsub(" "..str, "%W%l", string.upper):sub(2)

-- replace any underscores with spaces
str = str:gsub("_", " ")

if track:is_selected() then

-- preface with track number
str = curTrack .. " - " .. str

-- increment the track count
curTrack = curTrack + 1

end

-- set the new track name
track:set_name (str)

end

end end

Back on topic to the product in general, please go teach some classes to other workstation developers on how a recording console should work. You guys obviously know and some of them clearly don't.

[teacue]

Ardour still does not import tempo data from MIDI files (that really has nothing to do with with tempo ramping, since MIDI files cannot specify accelerando or ritardando). It isn't hard for us to code this - the problem is defining the workflow so that it works OK for most users. There are at least 4 (and perhaps) more options about what to do with the MIDI file's tempo information, and offering these choices to users in an obvious but non-intrusive way is much harder.

Quite a few of the features in Ardour 5.0 are already in Mixbus. The big exceptions are the tabbed interface, the a-* plugins and tempo ramps. My understanding is that they will show up in version 4.0 of Mixbus.

Thanks for your answer.

[x42]

Wow nice. an actual Ardour lua script! Kudos.

Not sure if that was sarcasm or not but thanks anyway. Here's a better one...

No sarcasm. I was positively surprised. A neat one-liner, posted in a forum where there Ardour Community is not that prominent and also only a few hours after the initial release! That's motivating to add more script bindings rater sooner than later.

Would you mind if I add the track re-name/re-number script to the examples at https://github.com/Ardour/ardour/tree/master/scripts ?

PS. As for numbering: There's Session > Properties > FIlenames > Prefix Track Number
Though that's somewhat different your case. It won't change port-names (changing track-names will do that) and it only applies when recording (filenames, region-names) -- but it will display a nice big number in the track-header

[LawrenceF]

No sarcasm. I was positively surprised.

Would you mind if I add the track re-name/re-number script to the examples at https://github.com/Ardour/ardour/tree/master/scripts ?

Be my guest. The number prefixes need to include a leading 0 for the first 9 tracks though (assuming 99 tracks or less) something I didn't do there.

One thing I was trying to figure out (maybe you can help) was how to present the user with a dialog for things like that, to prefix or not, to trim spaces or not, etc, etc, and then (in something like the second code example) make a lot of that conditional to the user selected options. That's one thing I don't like about some scripting interfaces, no really easy GUI capabilities for things like that... like if you wanted to add check boxes for those options.

Easy enough with JS + XML forms, not so much in some other situations.

If you can show me how to do that, I can probably whip up a really nice 'renamer' script as a demo that does lots of things, including naming series of tracks with musical instrument names.

[x42]

One thing I was trying to figure out (maybe you can help) was how to present the user with a dialog for things like that, to prefix or not, to trim spaces or not, etc, etc,.

Currently lua scripts cannot present a GUI. That's on the roadmap for 6.0 though.

The closest currently are instantiation parameters `scripts/addscopes.lua` and `scripts/tomsloop.lua` are examples. One can set parameters when binding the script to an Action (Menu > Edit > Scripted Actions > Script Manager). The factory function will be called with the given parameters as lua-table. It's not a call-by-call dialog though (which is also still on the ToDo list).

PS. Preferences > GUI > Action Script Buttons allows to add buttons for 9 bound actions to the editor toolbar. And once scripted-actions are bound, keyboard shortcuts can be configured (Window > Key Bindings > Editor) for them.

[Numanoid]

Get Ardour 5.0 for Windows 64 bit

Frequently Asked Questions: I thought this was free software

Subscribe:
Your choice: $1, $4, $10 or $50 per month
Updates and downloads for as long as your subscription continues. Access to our nightly (development) builds is included.

Single Payment:
If you choose to pay less than US$45, you will get the current version and updates (e.g. buy version 4.7, get access to 4.8, 4.9, etc. but not 5.0).
If you choose to pay US$45 or more: get the current version, updates and the next major version, plus access to nightly (development) builds.

Seeing it being listed as VST Planet as freeware, I was kind of taken off guard, not just the Windows version but Linux and OSX also needs some kind of payment to unlock the "ready to run" version demo mode.

http://vstplanet.com/News/2016/ardour-v ... -linux.htm

The source code version may be free, but that aint for everybody, as it can require a lot of troubleshooting and maintenance to keep it going:

You'll need to build this yourself. That can be a challenging and complex process, especially on Windows and OS X. We don't provide help for this process, and we can't support the end result.

[mr.ardour]

Seeing it being listed as VST Planet as freeware, I was kind of taken off guard, not just the Windows version but Linux and OSX also needs some kind of payment to unlock the "ready to run" version demo mode.

It is not possible for me to control how other people talk/write about Ardour.

It is not freeware, and has never been freeware. It is free software, in the sense of the GNU public license (aka "free as in speech, not free as in beer).

You do not unlock the demo version. The demo version is the demo version. If you decide you want a version that doesn't go silent the way the demo one does, then you need to either:

• * pay for a ready-to-run-version
  * build it yourself
  * get a copy from someone else (which is entirely legal)

The source code version may be free, but that aint for everybody, as it can require a lot of troubleshooting and maintenance to keep it going:

That's right. So I created a system that tries to convince people to pay for the ready-to-run version instead. Do you have a better idea on how we can raise income to allow at least one developer to do this full-time?