View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006237 | ardour | features | public | 2015-04-05 18:47 | 2020-04-19 20:17 |
| Reporter | fulup | Assigned To | paul | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Summary | 0006237: Alsa JSON interface UI | ||||
| Description | Would it be possible to control ALSA board directly from Ardour, like we do for JACK ? | ||||
| Additional Information | Music oriented board like Scarlett and others have a lot nice functionalities, and it would be nice to control them directly from Ardour, on the same model as what Ardour proposes for Jack, where you can control either from QjackCtrl or directly. I posted on github an ALSA-JSON gateway that provides full control of music oriented sound boards through a REST/API with a sessions load/store https://github.com/fulup-bzh/AlsaJsonGateway Question: would it be possible to create an extra tab like we have for Midi devices to control Alsa ? | ||||
| Tags | No tags attached. | ||||
|
|
Ardour does not control hardware directly. Ardour on OSX and Window offers a button to launch an external control application (from the engine dialog). In case of Focusrite/Scarlette the Scarlett MixControll app is started. A similar solution could work on GNU/linux: in your case (REST) I suppose opening a browser window could work. However as opposed to OSX and Windows, I don't think there is a way for ardour to discover which control interface to launch in the first place. |
|
|
Opening an external tool is always possible but does not provide a consistent user experience. In order to really provide a consistent user experience a soundboard abstraction is needed. Every soundboard works more or less the same model. You have a numbers of control that you activate. Each control as a unique ID and accept values. Those values can be integer, boolean, enumeration, etc ... What is really specific is how you map those controls as input/ouput channels, mixes, volumes, balances, etc... At the end it should not be very complex to provide an abstract description in XML/JSON that allow a generic smart Mixer on Ardour to drive any cardcards. Such a model would be independent of the operating system, and would enable the specific part of each sound card to remain outside of Ardour. |
|
|
The external tool is the ONLY viable option. On other platforms, nobody tries to write a single app to control all hardware. Each vendor creates their own, for each device (often), specifically tailored to the design of the device. alsamixer and amixer are representations of what happens when you try to do this generically - very capable but extremely unusable software. Trying to use either of these program to control a semi-pro or pro audio interface is close to absurd and it is not just because of the lack of any relevant naming. we are not going to clutter ardour with this sort of h/w specific nonsense. Contrary to your claim, different audio interfaces work in VERY different ways. Just take a look at something like RME's TotalMix application (or even just the settings editor, which is mirrored on Linux by hdspconf). Both of these require very specific, detailed knowledge of the device topology and intended use. So again: Ardour does not control hardware directly and it isn't going to. |
|
|
I listen to your arguments and agree that a 100% generic solution is not an option. Nevertheless, a simple configuration file would allow to drive almost any sound board in a very smart way. Alsa driver provide a very clean description of individual controls, what is missing is a a description on how those controls should be organised and grouped. I started to work on a generic UI in HTML5 http://breizhme.net/alsajson/mixers/ajg#/scarlett?card=2 and while HTML5 has is own limits, I really think that a simple configuration file in between a low level driver like ALSA and a UI should enable a generic UI with a nice user experience. I understand that Ardour is not willing to control hardware, but the functionalities you propose with JACKd and sessions save/restore is so nice that it would be great to extend them to the sound card, and if board description remains outside Ardour, then Ardour would not have to handle directly the hardware. |
|
|
If this was true, why do you think that such a tool has failed to materialize, some 15 years AFTER the ALSA control API was standardized? The ALSA description of individual controls provides absolutely zero semantics for any control. It also cannot describe matrices in any sane way. The problem here is that "almost any sound board" can be interpreted in two different ways. As a flat percentage of audio interfaces in use by users, probably a large majority use an Intel HDA builtin audio chipset. For these chipsets, it probably is possible to do something as you suggest. But for the audio interfaces actually in use by people for whom a tool like Ardour is important, this is much less true. This is particularly so because the controls that typically need tweaking on these devices tend to be precisely the ones whose semantics are non-standard. An example would be word clock source. There are at least 4 different variations on how devices allow the selection and use of different word clock sources; depending on how you view it, maybe as many as 12. This is just one single type of control. The generic UI you've shown the screenshot of is basically an extended replacement for tools like gamix or qamix, and I think that it would be a very valuable thing to implement, but it is part of ALSA, and not part of JACK (which can operate without ALSA) and not part of Ardour. |
|
|
I agree it's a shame that musics oriented boards is not within ALSA top priorities, but I'm afraid that it's not going to change any time soon. I had to write and ALSA/JSON gateway while I would have expected that after 15years, someone should have built either a DBUS or REST ALSA API. Unfortunately the waste majority of users are happy with to live within Pulse audio limits. Even if controls semantics is 100% board specific; if Ardour had a normalized virtual music oriented board, building the mapping from ALSA to this abstraction should remains simple enough,and furthermore this abstraction should be independent on ALSA or any other low level mechanism. The problem of not having a consistent user interface is that it's hard for non technical people to use a solution like Ardour. While I use and appreciate it, I still fail to convince any of my friend musicians to use it. For the UI I'm working on, while it is based on an ALSA abstraction and will hopefully allows to drive music oriented board, more easily than Qmixer or other existing mixer. It unfortunately cannot have the level of refinement of a native QT interface. |
|
|
You do realize that the other DAWs don't do this either, right? You can't do what you're describing in Logic, Nuendo, Sonar, Cubase, Live, Reaper etc. You can't do it in Pro Tools unless you use digidesign hardware. So if this is a blocking issue that stops your friends from using Ardour, I am not clear what they choose to use instead. |
|
|
I'm surely not the only one who has friends that are reluctant to replace there old gears with a laptop+soundcard :) I would expect that the biggest opening for Ardour is not to convincing Cubase users to switch from Cubase to Ardour, but more to convince people with old gears to replace all there existing "EndOfLife" equipment with a laptop+Ardour+soundcard. I do not know well enough competition to produce a serious analysis. Nevertheless I get the impression that most of existing DAW rely on plugins to enable external tools [including the one with UI]. While historically plugins was the only option to cooperate with external products. Plugins have many unpleasant constrains and today everyone is moving toward API, either based on HTTP/REST or using a generic service from the operating system [For Linux DBUS]. Conclusion: I understand that you have a lot work on you plate, and that affing more on your todolist is not top priority. But if one day you consider moving toward the API world for interaction with sound cards. I will be happy to write an ALSA gateway service that respond to Ardour specification. |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-04-05 18:47 | fulup | New Issue | |
| 2015-04-05 19:08 | x42 | Note Added: 0016550 | |
| 2015-04-06 09:10 | fulup | Note Added: 0016555 | |
| 2015-04-07 01:29 | paul | Note Added: 0016558 | |
| 2015-04-07 01:29 | paul | Status | new => resolved |
| 2015-04-07 01:29 | paul | Resolution | open => no change required |
| 2015-04-07 01:29 | paul | Assigned To | => paul |
| 2015-04-07 07:53 | fulup | Note Added: 0016561 | |
| 2015-04-07 12:37 | paul | Note Added: 0016562 | |
| 2015-04-07 15:05 | fulup | Note Added: 0016563 | |
| 2015-04-07 15:10 | paul | Note Added: 0016564 | |
| 2015-04-07 16:51 | fulup | Note Added: 0016566 | |
| 2020-04-19 20:17 | system | Note Added: 0023434 | |
| 2020-04-19 20:17 | system | Status | resolved => closed |
