Development update: 6.0-rc1 tagged

hello everyone I wanted to report to the ardor team that the Ardor-6.0.rc1.44-dbg-x86_64-gcc5.run version crashes when it tries to import audio files. As an operating system I am using 64 bit debian buster. The previous version N.34 instead works well

Bug reports to tracker.ardour.org (in this case, preferably with a backtrace as described at http://ardour.org/debugging_ardour ; if no backtrace, then a very detailed recipe for the bug)

With open-stage-control v1 around corner I’m updating it for v6: (work in progress)

3 Likes

I’ve just installed rc1.82 and the web interface still isn’t working for me, either (I’ve tried a couple of previous iterations). I’m on UbuntuStudio 18.04. It would be a hugely useful feature, so hopefully it will be sorted at some point. ETA: I figured it out: I needed to tick websockets in the list of control surfaces. Doh!

Is there a setting somewhere so that increasing the transport speed doesn’t change the pitch of midi, but only speeds it up? I’m going through some midi captures of writing/noodling in Pianoteq and it would be nice to skip through them quicker than realtime (I have a lot to get through) and the increase in pitch makes it harder to do.

There is no such setting.

When vari-speeding pitch is now unconditionally kept in sync for audio and MIDI.
Vari-speed playback is now done by resampling the I/O. It’s not something that can be disabled.

PS.
There is a plugin https://github.com/x42/repitch.lv2 (binaries are avilable from https://x42-plugins.com/x42/x42-repitch) that can counter-act the pitch-changes that are introduced by vari-speeding. Add it to the master-bus for example.

Thanks for your reply Robin. Ah, okay, understood. I’ll give your plugin a try, thanks for mentioning that :slight_smile:

Still using rc1.82 and I’ve found that changes to the Function Keys of a MCP profile (for my X-Touch) are being written to “User (edited).profile” (in /.config/ardour6/mcp) but aren’t loaded the next time the session is loaded.

Should I report this in the bug tracker?

Yes please do that. Though I might fix it before you do that (mostly joking :slight_smile:

So can this web interface be used to create a another mixer to use in Ardour, I always wanted to change the knobs on ardours mixer slider knobs but was wondering if someone can create different types of mixers to use in the mixer window, I guess you can make one using web programming language?

You can create an interface to use in addition to the current GUI. This is a control-surface, like a MIDI mixer, except instead of some hardware mixer, you can use a web-browser.

I have mixbus, and I loved the mixer but I no longer want to keep paying for mixbus versions, I want to use Ardour but I want to try making a better mixer that I would like to use.

Thank you, the network control sounds like amazing news. Some questions though:

  • is there already some documentation available about the json/websocket and how to build upon it and expand it?
  • is there a possibility to monitor input via the network, in conjunction to the control interface? I mean, will we be able to setup a remote ‘control room’ now? Or we need to look at pipewire, netJack, jack.trip or similar…
  • have you considered adding a new page on your website dedicated to this functionality? where we could read instructions and share our ‘control web pages’ and experiences with each other? :slight_smile:
  1. no documentation at this time. It is still marked “experimental”
  2. no audio/MIDI data transfer. This is a control surface only.
  3. when it moves out of experimental status, a part of that will be to figure out good ways to encourage collaboration and sharing.
1 Like

I guess it would be nice if ardour itself opened up the web browser in the program to use for the mixer so that it would feel more native when using ardour

That’s not likely to be a focus of attention - the main goal of a control surface (MIDI, OSC, JSON whatever) is to provide control over Ardour from a device other than the one on which it is actually running. You would be running a browser on e.g. a tablet, not the machine running Ardour.

Oh ic, I understand, I guess maybe it would be best to keep it as it is

Ardour surfaces depend on the Glib event loop and LWS_WITH_EXTERNAL_POLL is needed for interfacing to it. There is official support for Glib in newest libwebsockets versions but that probably will not be available on all platforms for some time (e.g. my distribution still comes with v2) so the lowest common denominator was adopted. Probably there is no universal binary-only solution right now :confused:

Also it seems libwesockets’ own Glib code calls some functions that are not available on Windows, I am wondering this means that libwebsockets+Glib does not work on that platform (haven’t tried yet). Check https://github.com/warmcat/libwebsockets/blob/e73f16b43414d8950d21621cf0eb3f3e6e84d4c8/lib/event-libs/glib/glib.c , it contains calls to “g_source_add_unix_fd()”.

The current WebSockets Server surface comes with its own Glib implementation that is fully compatible with Windows.

No docs yet but the built-in web content comes with a simple JavaScript client library and some demos that are easy to follow.

To get started include module https://github.com/Ardour/ardour/blob/master/share/web_surfaces/shared/ardour.js (exposed as /shared/ardour.js on the browser side).

The API methods can be found in:

github/Ardour/ardour/blob/master/share/web_surfaces/shared/control.js
github/Ardour/ardour/blob/master/share/web_surfaces/shared/metadata.js

As Paul mentioned this is experimental work in progress, handle with care.

It works with Ardour binary nightly build. That uses libwebsockets 3.0.99. – That version was the first available that supported Wndows at the time the project started at LAC 2017. We should probably update it to 4.x now.

I mean the Glib glue code that already comes in latest libwebsockets. Anyways I think it would be great to update to v4, there is always the possibility of falling back to the current implementation if needed. Finally adhering to v2 was not an universal solution.