AVL-MXE 2021.05.22 is out with Ardour 6.7 and much more!

Hi Ardour/Mixbus Friends!

For any who may be interested an updated ISO of AVL-MXE has been released:

Thanks and be well!
Glen

5 Likes

Just an FYI that I downloaded and ran “live” and unfortunately when Ardour starts scanning plugins for the first time wine-staging has a meltdown and crashes.

That’s why there is a nice Video in the release announcement… :wink:

I read manuals, remember? :wink:

1 Like

Well then I guess you didn’t read Page 68… :stuck_out_tongue_closed_eyes:

PLEASE NOTE The first time Wine-Staging runs on your computer it needs to configure itself and set
up it’s directories in a hidden ‘.wine’ directory in your User home folder. Wine-Staging does not run it’s
setup until the first time it is called to run a Windows program by the host system. If the first time Wine is
initiated is during a plugin scan within a DAW it is possible the initial Wine configuration setup will occur
as you are running the LinVST plugin scanner which ensure the renamed ‘.so’ files of the Windows VST
Plugins show up in your Linux DAW. On some systems this may cause the scan to time out, fail and not
completely finish. Once Wine has set up it’s initial config you should be able to run the plugin scan again in your DAW and it should be able to successfully complete.

I set myself up for that one :grimacing:

So question: why does this still happen on a live ISO? Does the MX snapshot stuff do something odd? Is the answer on another page of the manual? :shushing_face:

There are 2 things afoot here…

  1. Wine-Staging has always often crashed on the first run of a plugin scan especially if there are a lot of Plugins and it is mostly due to the fact that it’s juggling too much to run the scan executable and write it’s config, sometimes you get lucky and it doesn’t crash on a Live session but usually it does…

  2. I usually run LinVST just before I build my ISO’s and this time due to a last minute Plugin addition I installed an updated Plugin package (also containing the Windows example Plugins) and forgot to re-run LinVST so the pre-written LinVST ‘.so’ files in that Plugin package were stale… So LinVST would need to be re-run before the initial Ardour VST Plugin scan for the Plugins to work anyway… but the fact that Wine-Staging usually crashes on the first run in general kind of masks this and I thought it was a good teachable moment especially for new folks on how the process works anyway…

But… as you may have suspected, I am indeed an idiot! :wink:

In the future I may just pre-run ALL of Ardour’s stuff and pre-populate it in the User’s home then everything should ‘just work’ but the downside is the User won’t have those initial setup choices provided by the first run of Ardour…

1 Like

I always just breeze past those setup screens with default options knowing that I can always change them later. Experienced users who already know they need a different choice will know where to look and new users really won’t know what works until they check out the default values :wink: That’s my read on it anyway…

Hi!

Just posting a ‘quiet’ update here that fixes a few annoying issues on the last released ISO:

Oh…

And BTW the Ardour config is pre-populated in the User’s home on this last ISO update… :wink:

1 Like

That’s bugged me for so long - the first time you run ardour, you’re presented with choices which you don’t really know the answer to until you’ve already run it for the first time - and then you probably have to change them anyway :slight_smile:

The problem is that there are no good default-defaults for a lot of those things.

If there’s more than one audio interface (and thanks to HDMI, there almost always is on a desktop system these days), we have no idea which one the user plans to use.

We have no idea what their monitoring situation is, or is desired to be.

We don’t know where they might want to put sessions - some people want to use that portable USB drive, some people want them under $HOME, some have a separate internal drive … we could use some heuristic to guess, but it would be wrong at least 1/3rd of the time I think.

The core problem here is that it’s a situation with someone using a tool for the first time and hoping they don’t need to know anything about the tool (or more charitably perhaps, that they can “learn by doing”). I don’t think that’s true of a DAW. You can learn a lot by doing, but there are some basic things that you’ve got to understand a bit about. Probably. Maybe.

I understand the problem that presents - but I think that arises from an assumption (maybe going back quite deeply into the design of ardour) that it needs to know those things before you can open the application, which logically leads to asking questions even a proficient user might not know or have decided the answer to, until they have opened the application for the first time - and hence will almost certainly have to change them later anyway.
Perhaps the real solution is to approach it from the point of view that Ardour shouldn’t need to know those things in order to let you open the application for the first time with a blank session and no default audio preferences selected.

1 Like

I don’t know another DAW that requires any of this setup on first use (and it’s not because Ardour has functionality the others don’t in this regard). It’s all in the preferences once you are inside the program and start asking questions about whether certain things can or need to be changed. It’s a great way to explore and start understanding the power of the software. Samplitude, for example, will default to MME or perhaps their ASIO Magix low latency driver on the built-in soundcard. It’s perfectly fine. REAPER does something similar and I don’t think anyone complains. Think about it this way: you are offering two different ways to change preferences so you don’t think it might be confusing when the user can’t get that same dialog box back up?

I genuinely think ardour could increase its user base if things like this were addressed. Its not an exciting new feature, that’s are going to grab the interest of experienced ardour users (or maybe even the developers). But I know anecdotally of people very experienced with other DAWs who have never got past Ardour’s intro setup. Its not a case of can’t, its a case of “this is just one - extra - part of a hundred other things I have to think about in order to get my job done. If I’m spending time figuring this out, I’m not getting way more important things done”

Here’s an example of the type of thing I mean - and this is just during normal usage:

ardour6

You can see there are some odd sessions there I’ve been using during the testing of various plug-ins, but - and this is the point - the only option I’ve got - or so it seems - is to Quit. There’s nothing there to cue me that selecting anything else will change that. Perhaps that’s just a bug, but by any definition, its not intuitive - and its symptomatic of other usability issues further down the line. Ardour needs to draw people in - to give them a clue that its this amazing piece of software that they will want to use.

1 Like

Hi, In my experience building and testing Live Media, Reaper (Linux) defaults to JACK and if JACK isn’t running it throws an Audio Engine error so for first time launchers also not terribly clear what to do if you don’t know how to discern between ALSA, JACK or PulseAudio…and in the future…*shudders…Pipewire…

Yes, weird…never noticed that so it clearly hasn’t bothered me. Still, it does have a big “audio device” button it throws with the error so it’s better than nothing. I’m probably mixing up its (sane) defaults on Windows.

Is there any reason that you couldn’t run Ardour to do an initial scan so that wine completes it’s initial config and then delete the ardour config before creating the iso? I’m thinking that way, on a live session Ardour would still need to do the setup routine and scan, but it should work because wine would already be initialized.

I find it surprising that some would find this screen unintuitive, but it seems some would. To me, the layout is obvious. If I want to start a new session, I click the large button that says “New Session”. If I want to open an old session, I can either select one from the recent list or click the drop down box, which is similar to drop down boxes in other programs where you need to select a location. The fact the buttons are greyed out until you make a selection seems familiar to me as I have come across that behavior in other programs. I wonder how this could be improved as it seems as straight forward as it can get. I also wonder how a potential user who struggles getting past this screen could use Ardour at all, given how complex a program it is.

2 Likes

This is getting a bit off topic - but the point is not that anyone would necessarily struggle to get past this, and I think its unnecessarily dismissive to assume that anyone who doesn’t find this intuitive would struggle with something “as complex” as Ardour. I don’t find it intuitive, and I can assure you I work with things way more complex than Ardour, all the time.
Sure, if you randomly click things then stuff happens, but that’s not intuitive UI design by any measure. Why not simply (pre)highlight the last session for example? My point is that the application shouldn’t be putting up barriers to entry, it should be enticing new users in. On seeing the first dialogue you should be thinking “I can’t wait to see what this software can do” - and not, “well, I guess the rest of the application probably won’t get much worse than this…”

1 Like