From: Jonathan W. <jw...@ju...> - 2013-11-06 22:26:21
|
Hi Phil I like the idea of being able save and restore the mixer state. This provides a lot more flexibility when it comes to device setups since most interfaces support only a limited number of configuration snapshots. > > The use of xml might seem as an strange compromise between human- and > > machine-readability, but its actually easy to save/restore when you > > have tree-like structures as you have in the dbus-tree (which btw uses > > xml itself). > > Yes, and it let the possibility for a human to modify the file by hand, > if required. I think XML is fine for this. For the most part it'll be handled by the computer so it is of no consequence to the user at all. In the rare cases where manual intervention is required then, as you said, it is possible to edit it by hand. > > So for the actual tags you might even look at the > > dbus-tree and save/restore that? > > Sure, I will have to work with the dbus-tree aside in order not to forgot > something and keep some coherence between the twos. In many respects I wonder whether this save/restore functionality shouldn't at least start out as a simple walk of the dbus tree. This way you immediately pick up as much of the device state as is available - even details which may not have a GUI control yet. It will also be easy to make this adapt to changes on the dbus side without having to involve any knowledge of the GUI at all. I don't know dbus well enough to be sure that such a tree walk is possible: it would require the ability to query dbus for the list of controls provided. If it is possible there might even be a library or utility already in existence which could be used as a starting point. There are a small number of read-only dbus controls provided by certain interfaces, and these may be a minor issue for the restore side of things. However, this could be trivially overcome by either ignoring dbus set requests which fail or adding a write stub to the respective controls. > Now, there might ba additional savings (for instance, presently, there is > the possibility of stereo treatment for outputs in the mixer section which > are purely software). True, and software-only controls won't be picked up if you rely exclusively on the dbus tree walk. However, such controls will be in the minority so it's probably fair to require that the mixer code explicitly registers these controls for inclusion, in some way. As a further comment, the saved files will probably have to be tagged with the GUID or something so the correct file is used with the right device in situations where people have multiple devices. Whether this is tagged as part of the file name or within the file's structure is probably an implementation detail. Regards jonathan |