7 posts were split to a new topic: Suggestion: Video Tutorials for Ardour
Just for the sake of completeness: completely means completely including compilers, libraries and all other tools required to build and run the program. In practice that means a free operating system like Linux, FreeBSD and alike.
I’m fully confident that I will be able to view a jpeg photograph or play a music file or video now and in the near future. But for complex and --for me-- valuable data (e.g. music production data, video production data, also books I’ve written) the reproduction environment must be trustworthy, not for years but decades. Preferrably centuries.
I gave this some more thought overnight and I’ve come to the view that Ardour’s ‘balance’ is probably about right… For users who have no interest in programming they can use the pre-built versions. And for users who want to dabble with coding at an introductory level, there’s lua. And for users who’d really prefer to dive in at the deep end, they can learn C++ and download the source code. I think that’s quite a good range of options.
The lack of people wanting to get involved must have some other explanation…
I was using ardour version 2 then went to ableton now I am back for this exact reason. I get tried of being locked in. I wanted to transfer my license from one computer to another but, they wouldn’t let me do that. Then I recorded at my school’s local studio in a newer version of Ableton that I own and they would not let me save it in a compatible format . I did not not use any new plugins so it was just audio tracks but, I had to export it at the studio and then reorganize the stems (ableton doesn’t support broadcast wave). I can still open my old ardour projects. That is why I switched back to a completely open source flow. When I reinstall my os I am not i trouble with the activation police. I get my work done. I have never made changes to the ardour source code but, I have built it from source successfully.
Just to +1 for the accounting of this kind of poll. Scripting is a world I know is there but never had the need of researching it, so I am very ok if everything goes on as it is now.
Now the long version: if in the future there is a script bank from where you can easily download and turn on scripts that just do cool stuff like we do with plugins then awesome, but I believe there is a big chunk of users that won’t ever complain about not having it, precisely because in the wide set of skills we have to develop, music and audio related, there is not much more space for adding even the most basic programming ability. I also see here a pyramid in which the majority would want to use something that just works, then there will be a middle group with time and some ability to dive into tweaking things, and finally the reduced group of capable and commited people that would take the steps to help a program this complex get to the next levels. And that is alright, it is also comforting to know that there are some chosen ones in charge of this, maybe better than having a lot of people developing big branches of Ardour and we users getting lost in the picking (ala Linux distros, don’t you think there are too many of them? xD)
For the philosophical part I am just glad that by contributing to this program, financially or just by using it and spreading the word, I support the **concept of open source ** so other people with the right knowledge can develop it. Hopefully we will get to the point where a third or ten more full time programmers can be hired so the development of this beautiful thing can sky rocket and beat anything in its way – in that regard it could help that just everybody with screen recording can upload one or two videos about whatever long or short Ardour matter to youtube, so it can start showing results by just entering “SIDECHAIN COMPRESSION” xD – .
We need just a bit of patience, and inspiration from looking back at the great progress made in the last few years. In the meantime we programming ignorants still get to choose working with a software that matches our values and workflow needs
Just an FYI, I have moved the discussion of Video Tutorials to Suggestion: Video Tutorials for Ardour
Nothing wrong with the discussion, but it wasn’t necessarily about this post, and while I want it to continue, I want to make sure this stays a bit on topic, so lets move that discussion to there please.
I don’t see Open Source as synonymous with the aversion of a steep learning curve. But multithreaded c++ looks Sisyphusian to the inner eye of my untrained think maker. Regardless, I don’t think you picked your poison, but maybe haven’t tended all the vine. If you want more participants then train them in a pay for mentoring program. I’d schedule sessions to grade the top off the lua curve. Maybe mentoring wouldn’t grow a line around the block, but it might produce some vintage classes. Well, that’s my 2 cents.
Disclaimer; opinions do follow:
Scripting is for subsets of users who want to do a particular set of things that may not be useful to all users of Ardour. In other words, not all scripts should be rewritten to be a part of compiled Ardour. Not all proposed features will sit well with the core developers working on the C++ code. Every additional feature is more bugs to fix and more to maintain going forward. One can maintain one’s own fork of Ardour with a set of features one requires/desires but this is a lot of cognitive/time overhead compared to developing a feature in an in-application scripting interface. Also, sharing a script vs sharing C++ source code (patches, compiled binaries etc) is accessible to almost all users.
Inspiration is a fickle thing. I have witnessed this first hand in studio where an artist/performer/band is completely in the zone but waiting on a technical issue before they can start recording. Depending on the artist, this zone may come and go in a flash. For one-person artists/bands/performers/producers, this zone fades with every technical obstacle they encounter. One almost needs to split up technical setup and performance into two separate calendar events. Professionals work around this as there are methods of getting into the zone ASAP but my gut feeling is that these are very specifically personal methods. Additionally, professional environments often have a dedicated person/team on the technical side of things, freeing the artist to focus on the art.
I bring up inspiration as I believe it relates to the scripting interface - if one knows they can have a feature deployed in their production environment in the next few minuets (assuming competency with Lua and the Ardour API/documentation) they may go for it and still retain some potential for artistry at the end of the process. This is contrasted with a scenario where one needs to kill Ardour, open up and editor, write some C++ code, compile Ardour and then open their project again. If they have any bugs (very likely with my understanding of software development) this workflow/time is multiplied by the number of bugs they fix and tests they run. They could also break the build, cause a runtime crash etc in C++ land.
As touched on above, accessibility is important. Is seems clear to me that a Lua interface is more accessible than the C++ environment. That alone warrants it’s existence, value and power. As a personal anecdote, I managed to build some audio plugins in Lua and start a journey into DSP thanks to Ardour. I tried in other environments but the cognitive overhead bested me. There were too many aspects of the problem to lean at once. Don’t get me wrong, these plugins are more proof of concept than anything as they are orders of magnitude less performant than their compiled counterparts would be. The simpler interface comes at a cost.
I guess my comments are a bit redundant as the scripting interface isn’t going away but thought I’d add some points I didn’t see above.
As always, many thanks to the developers for their devotion and dedication.
I think that Ardour and any other DAW has a different type of users as – say – an editor for programming. I myself started out as a nerd in programming, I did most programming languages that people would name, and I can say I once was a quite good Java programmer. However, I noticed that with doing more and more music and recording and, lately, video, I don’t feel much like programming anymore. It is a different focus.
DAW users focus on creating music, not on developing software. Hence, Open Source is a nice-to-have thing for them, I guess. But it’s not too relevant. Btw., I think this is one of the reasons why Open Source audio tools make such a slow progress compared to many commercial ones: it is so hard to be an audio engineer with good ears and a skilled programmer at the same time! Mostly it is either-or!
In the early days, all computer users were hackers. Open source had a lot of meaning to them. Nowadays, most users are simply users… they use computers like a cook uses his knifes. They maintain them, but they don’t forge other knives. And they do like food a lot more than forging knives.
Nevertheless, I think the LUA interface is a good thing and actually I got an upcoming project in which I might need it. I will return to my hacker self for a while… perhaps.
This post may contain opinion. Feel free to disagree.
One of my jobs is audio lead for live events. The keynote and discussion group participants are CEOs and Presidents from large corporations. During the last two years a reoccurring message from these executives is they want all their talent to be programmers.
I started looking at Ardour, yesterday, because of Lua in reaction to a three day, high stress, event with over 1000 audio cues. I’m already reading and formatting filenames and about to strip out ‘function route_setup()’ from _route_template_generic_audio.lua and hack it into something to dramatically lower my aspirin intake.
Years back, I used Ardour for production and when people talked about using it for live playback I’d think, nooooo. In the paradox, the one eyed audio engineer writes lua so he can use Ardour for playback in live events.
Actually I’m in a similar situation where I need to fire playbacks for a musical. There’s software for this out there, most prominent Qlab. I have seen Qlab in action in complex setups in theaters, but for this project, nobody would pay me the $999 plus the money for a MacBook for it. And the functionality would also not be needed.
I basically need playback recordings (stereo tracks) and a bit of smart navigation from region to region in Ardour. If ever necessary I could fire MIDI over to QLC+ to do trigger some DMX stuff.
I’m not even sure if I will need LUA for this but, as you say, it lowers the Aspirin intake when you got the possibilities you might need.
Here’s some other examples of Lua GUIs, one will take a keyboard style convert is to midi, fit the sections verse, chorus, intro, ending etc… to the chord track (chord markers) then snap the midi notes to the chords.
The another will allow live play with your keyboard, the Lua will work out the chord you are playing then go to that chord maker (not sure if Ardour has smooth seek to play smoothly from one section to another?).
As mentioned it would be a good way to create something up quickly and share it, try it test it, improve it, then if it’s popular and works well it can be hard wired.
And a Chord Sheet that just reads/edits the markers.
I don’t think anyone is arguing that what you’re asking for doesn’t have great possibilities, like the two you mention here. It’s just that at this point in the game, it would take a monumental re-working of the source code. And honestly, if it gets in the way of the goals that Paul and Robin have already announced, I rather live without it. And I think most Ardour users would agree. Better clock and expanded MIDI functionality are easily more important than recoding the GUI to allow Lua scripts a UI. I’ve heard time and time again people asking for better MIDI tools. In fact, my friend who I converted to Ardour a couple years ago just switched to Studio One because he got big into MIDI and said it was more powerful. Your suggestion is great, its just a matter of cost-analysis. This software is pretty much maintained by 2 individuals, who somehow make the time to chat with us , and there are more important priorities that involve way less overhaul of the source.
The best time to plant a tree is 20 years ago the second best time is now. Looking at the posts I would say most are in favor to add some Lua GUI elements. I think if is was assumed and taken for granted that "most Ardour users would live without it…I don’t feel like there’s a lot of us looking for this…) we would not have this thread.
The idea would bring NEW users to Ardour, if you compare the amount of of Reaper users to Ardour users. Remember Winamp ? it was made for users to be able to customize things how they like and not be a slave to how the developer thought you should use it, well, the same guy made Reaper, and it “is pretty much maintained by 2 individuals”. There is just so much potential there rather than plodding along with how it is, a lot of time and trouble has been put into all those Lua bindings and look how many users there are now because of a Windows release. This will open the door for other script developers like in the Reaper forum, rather than waiting for something to be implemented it would take the load of the Ardour developers and it can be made that same day with a script that you can make yourself or ask someone.
It matters not to me if it’s implemented or not, I’m just giving you a fresh eye perspective from what I experienced coming from Reaper to have a look at Ardour’s scripting to see if I can port ReaTrak over from Reaper to give Ardour users the same features, I’m not charging anything for it, and it would be a hard thing for me to do, so it would be an easy way out for me if Ardour is kept how you suggest.
I spent the last 11 years hard labor in the pg music Biab forum and beta development getting them out of the Delphi 90’s and help develop the vst plugin version, I just don’t have that energy anymore to worry too much about Ardour when I first went to the Biab forum there was so much defensiveness from the long time users from the Disk Operating System days and any suggestion of improvements or change was given a hard time, you saw new users come and suggest improvements and constructive criticism but they were soon got rid of as you can tell by the reply’s to their post and their number of posts. So that’s why it stayed in a time warp for so long. And those users that were got rid of for suggesting such features, well those features are now implemented and are actually being used by the users that knock their ideas and suggestion years back, true story !
But then I fell off the floor when I went to the RapidComposer beta development where just about every suggested feature was implemented virtually overnight, that was a real shock as you would wait up to 10 years for things to be implemented in the Biab forum.
This is what you have already with Lua script, what else does it need ? just a button and a couple of other things maybe.
Again, you are simplifying my argument. My argument isn’t that plenty wouldn’t want this feature. If we turned this into a binary poll: “Should a UI for Lua scripts be priority over the proposed goals or not?”, I promise you most of us would want better MIDI functionality as soon as possible. I would wager that most Ardour users do not use any Lua scripting.
So what is the better MIDI functionality you are looking for ?
I know they are working on implementing Chordimist.
So what is the better MIDI functionality you are looking for ?
I think you should start a new thread if you want to open that can of worms. We’ll quickly derail this one
Put enough developers on the case, and it’s no longer an either-or question, which brings us back to the original problem of getting more developers involved.
People contribute to open source projects that … they are capable of contributing to and that they feel passionate about. There are some (look at the commits on the kernel from intel addresses) who actually get paid by their employers for such, but that is generally because their employers use that aspect of free software.
But since ardour is unlikely to attract the attention of IBM as a critical business need at which they will throw programmers, that means people who are passionate about it.
To get people who are passionate, we have to expand the user base. Expanding the user base means concentrating on features that are most important in making the difference as to why someone would choose a different DAW over Ardour.
So those make-or-break features need to be prioritized. What those are, I have no idea. The thing is, using ANY daw proficiently is a major investment in learning curve, just as a user. So it might not be an easy sell.
However, here are some really powerful benefits Ardour already has that I think are big selling points.
Licensing. Not just that its open source, but if you have used any of the big names like ableton or any of the more pricey plugins, you are limited to node-locked or iLok licenses that absolutely suck to manage or transfer around anytime you upgrade your motherboard or switch to a larger disk drive or whatnot. And heaven forbid you should actually own two computers on which you want to use the software. You can make it work, but it is a major investment in time and fiddling. Ardour will work on whatever computer you install it on. Projects are self-contained in a folder, and you can transfer them wherever you want. The licensing schemes are major overhead. (Except for Reaper, of course.)
Signal routing. The signal routing matrix of Ardour is fantastic. IMO it is the easiest and most clear matrix available. Although other daws will let you do the same thing, Ardour does best at presenting “what goes where” and letting you control it, split the signal, and send stuff wherever you want.
This is really huge when you want to make something that sounds coherent. The best way to use reverb isn’t necessarily by putting it on a recorded track and dialing in the amount of wet you want. Instead, take your instrument tracks that belong in a certain space (say, foreground or background) and route them to two busses – the destination bus, plus the reverb bus for that space. Then route from that reverb bus to its destination. Adjust the reverb there, and it is all coherent. You CAN certainly do this in other Daws but with Ardour this is easiest.
All daws have automation, and I’m sure other daws can do something similar, but I have to say Ardour’s ability to record desired automation (or just “touch” it in that one critical spot), and then play it back is killer.
I think its existing strengths are very sellable.
The signal routing on Ardour really really is incredible. I can’t get over how clumsy it is in every other DAW I’ve used (except Mixbus).
I have seen blender mentioned a few times in the comments. While there are some similarities between the two, there is also one very big difference. Blender is not a real time platform. It does not matter if the work in progress stutters or stops, it is the render that matters. Blender is not made to take live video in, but rather video files. Ardour on the other hand, does record audio in real time with real time monitoring of previously recorded tracks or may even be used as a live mixing setup in some cases. This does limit what can be scripted and what scripting languages can be used in a way that Blender does not have to deal with.
However, a lot of the scripting people are asking for is also not real time but rather batched commands to save entering a sequence of commands with a mouse or keyboard (or control surface). The GUI and other control surfaces are already, from what I can see, not real time so much as real time-ish. The control portion suggests what needs to be done and that is taken care of the next time real time code is dealing with what is being controlled. For most scripts exposing only non-real time options would be enough and in fact using a script that has the ability to also do real time dsp may make it easier to make mistakes in this area.
In my case, while the thought of learning c++ was a hurdle, I have found it does have advantages as well. c++ will generally not allow me to build something with mistakes in it. I am probably not the average user though.