From: Philippe C. <la-...@or...> - 2013-11-05 17:51:57
|
Hi Jonathan, in times I am tired to track the 96kHz bug with Pro 40 (I will send you another email later), I began to develop something for file saving of ffado-mixer controls setting. Before going on further, I would like your opinion. Presently (devel are restricted to globalmixer and router), I save settings data in an xml file like this: <?xml version="1.0" encoding="UTF-8"?> <version> FFADO 2.1.9999 </version> <device> <guid> 00130e0401405709 </guid> <nickname> Pro40 </nickname> <clock> 5 (Internal) </clock> <samplerate> 1 (48000) </samplerate> <router> <dimensions> 58 2 </dimensions> <connections> 1394/Out:01 Mic/Lin/Inst:01 1394/Out:02 Mic/Lin/Inst:02 1394/Out:03 Mic/Lin/In:03 1394/Out:04 Mic/Lin/In:04 1394/Out:05 Mic/Lin/In:05 ... </connections> </router> </device> As it would be better not to change radically in some future, it would be nice to plan an almost definitive scheme for such a file. This include of course the kind of file (xml ?), and the tag naming (including my poor english ability). Possibly, tag names like <device:nickname>, <device:router:connections> and so on would be better ? Regards, Phil -- Philippe Carriere <la-...@or...> |
From: Arnold K. <ar...@ar...> - 2013-11-05 19:26:28
Attachments:
signature.asc
|
On Tue, 05 Nov 2013 18:51:41 +0100 Philippe Carriere <la-...@or...> wrote: > in times I am tired to track the 96kHz bug with Pro 40 (I will send > you another email later), I began to develop something for file > saving of ffado-mixer controls setting. Before going on further, I > would like your opinion. Presently (devel are restricted to > globalmixer and router), I save settings data in an xml file like > this: > > <?xml version="1.0" encoding="UTF-8"?> > <version> > FFADO 2.1.9999 > </version> > <device> > <guid> > 00130e0401405709 > </guid> > <nickname> > Pro40 > </nickname> > <clock> > 5 (Internal) > </clock> > <samplerate> > 1 (48000) > </samplerate> > <router> > <dimensions> > 58 2 > </dimensions> > <connections> > 1394/Out:01 Mic/Lin/Inst:01 > 1394/Out:02 Mic/Lin/Inst:02 > 1394/Out:03 Mic/Lin/In:03 > 1394/Out:04 Mic/Lin/In:04 > 1394/Out:05 Mic/Lin/In:05 > ... > </connections> > </router> > </device> > > As it would be better not to change radically in some future, it would > be nice to plan an almost definitive scheme for such a file. This > include of course the kind of file (xml ?), and the tag naming > (including my poor english ability). Possibly, tag names like > <device:nickname>, <device:router:connections> and so on would be > better ? There should be two versions at the top: ffado-version and file-format-version. (ffado-version could be optional as its cosmetic.) When the file-format is versioned, changing part or everything of it is less intrusive as long as ffado-mixer keeps its possibility to load old formats. And it could be better if the file-format-version a single number or divided in attributes or tags. Examples: ---- <formatversion>14</formatversion> ---- <formatversion major="1" minor="3" /> ---- <formatversion> <major>1</major> <minor>3</minor> </formatversion> ---- 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). So for the actual tags you might even look at the dbus-tree and save/restore that? And when you compress the xml (there is a IOCompressor somewhere in/around Qt for transparent zlib-compression), you get pretty small files. Have fun, Arnold |
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 |
From: Arnold K. <ar...@ar...> - 2013-11-06 22:51:58
Attachments:
signature.asc
|
On Thu, 7 Nov 2013 08:56:02 +1030 Jonathan Woithe <jw...@ju...> wrote: > 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. Don't rely on the filename for this. As the files should be able to store the state of the full mixer also when several devices are connected, the GUID of the device(s) concerned has to be part of the xml-tree. Then one can save a setup of two synced devices and restore that without fuzz. But the next question arises: How do we allow to import settings saved with one specific device onto another device of the same type? Maybe either an extra import-function or a dialog when opening settings where not all saved devices can be found again... Have fun, Arnold |
From: Jonathan W. <jw...@ju...> - 2013-11-06 23:08:29
|
On Wed, Nov 06, 2013 at 11:51:44PM +0100, Arnold Krille wrote: > On Thu, 7 Nov 2013 08:56:02 +1030 Jonathan Woithe <jw...@ju...> > wrote: > > 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. > > Don't rely on the filename for this. I agree. I should have made it clear that I didn't like this idea (that's what you get for rushing off a reply). Files can be too easily renamed by accident - among other things. > As the files should be able to store the state of the full mixer also when > several devices are connected, the GUID of the device(s) concerned has to > be part of the xml-tree. Unless of course you store each device's state in a separate file. I still don't think that using the filename for device identification is a good idea, but separating each device into its own file might be helpful in some cases. > But the next question arises: How do we allow to import settings saved > with one specific device onto another device of the same type? A device type flag could be added to the file. This would allow the software to determine whether a file with a mismatched GUID was at least compatible with the device being used. We would obviously still require some mechanism to allow a user to direct the system to a file with mismatched GUID - but at least there's some degree of safety afforded by the device type check. > Maybe either an extra import-function or a dialog when opening settings > where not all saved devices can be found again... Probably the latter I think. There are quite a few cases where the devices one has available at any one time changes, so you don't want a dialog to bother you just because a device appears not to be on the bus at a particular time. In this case we should just restore those devices which are present. Regards jonathan |
From: Philippe C. <la-...@or...> - 2013-11-07 19:54:34
|
Hi Jonathan, Hi Arnold, Le jeudi 07 novembre 2013 à 09:38 +1030, Jonathan Woithe a écrit : > On Wed, Nov 06, 2013 at 11:51:44PM +0100, Arnold Krille wrote: > > On Thu, 7 Nov 2013 08:56:02 +1030 Jonathan Woithe <jw...@ju...> > > wrote: > > > 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. > > > > Don't rely on the filename for this. > > I agree. I should have made it clear that I didn't like this idea (that's > what you get for rushing off a reply). Files can be too easily renamed by > accident - among other things. > > > As the files should be able to store the state of the full mixer also when > > several devices are connected, the GUID of the device(s) concerned has to > > be part of the xml-tree. > As mentioned in my first email, the guid is the first information kept for device recognition. As a further comment, in my present experimental implementation: - there are as many <device>...</device> as devices present when saving settings. - on file reading, the presence of each device (based on the guid) is tested: if the device is present, saved settings are propagated. Otherwise, they are simply ignored (with a debug message). > Unless of course you store each device's state in a separate file. I still > don't think that using the filename for device identification is a good > idea, but separating each device into its own file might be helpful in some > cases. > > > But the next question arises: How do we allow to import settings saved > > with one specific device onto another device of the same type? > > A device type flag could be added to the file. This would allow the > software to determine whether a file with a mismatched GUID was at least > compatible with the device being used. We would obviously still require > some mechanism to allow a user to direct the system to a file with > mismatched GUID - but at least there's some degree of safety afforded by the > device type check. > > > Maybe either an extra import-function or a dialog when opening settings > > where not all saved devices can be found again... > > Probably the latter I think. There are quite a few cases where the devices > one has available at any one time changes, so you don't want a dialog to > bother you just because a device appears not to be on the bus at a > particular time. In this case we should just restore those devices which > are present. > I'm inclined to think about the former. Since the xml file allows editing (or command line modification), it will be easy to change the guid if required (typically, when the device has been exchanged for another similar one). Now, in the case you would like to import some settings for one device (a Pro 40, say) to another kind of device (a RME, say) because they share some potentialities (matrix mixer coefficients, for instance - even if the matrices are not exactly of the same dimensions), it would whatever be better that the user knows what he is doing (an import, not a simple read) and that they will be some limitations for the process (partial or no success). There is not necessarily good reasons that the specific functions would have to be different, if the tags are of sufficient general meaning (this was part of my first answers); but this must clearly be distinguished for the user viewpoint. This is an "extension"; not sure I will implement it soon :-) > Regards > jonathan Regards, Phil -- Philippe Carriere <la-...@or...> |
From: Jonathan W. <jw...@ju...> - 2013-11-08 00:35:56
|
Hi Phil I'm just coming back too your original email on the subject to pick up a few loose ends. On Tue, Nov 05, 2013 at 06:51:41PM +0100, Philippe Carriere wrote: > ... I save settings data in an xml file like this: > > <?xml version="1.0" encoding="UTF-8"?> > : > <device> > : > <clock> > 5 (Internal) > </clock> > <samplerate> > 1 (48000) > </samplerate> I would be inclined to reverse the priority of the values here. That is, use "Internal (5)" and "48000 (1)" instead. I think the use of the literal interpretations of the fields might make the files more resilient to future changes which might change the mapping of values to IDs. As I write this though I realise that this might be difficult to do since the source dbus controls probably only use the enumeration values. If this is the case and there's no easy way to do the reverse map (from literal to ID) then we can stick with the ID being the primary value - it's not important enough to spend lots of time on. > As it would be better not to change radically in some future, it would > be nice to plan an almost definitive scheme for such a file. This > include of course the kind of file (xml ?) I don't have a problem with the use of XML. As has been mentioned in a later post, I quite like the idea of using the dbus structure as the basis for the XML file (and thus the tage therein). The only issue I don't currently know abouut is whether dbus provides sufficient querying to make this feasible. If this could be done it will side-step a lot of the complications we are likely to encounter due to the vastly different structures between devices, and there won't be a lot of device-specific code required to make things work for a given interface. > ... and the tag naming (including my poor english ability). Possibly, tag > names like <device:nickname>, <device:router:connections> and so on would > be better ? My immediate thought is that using "device:" prefixes will just add unnecessary length to the tag names. They all exist under the <device> tag so it's inherently obvious that they relate to a device. Ok, so there might be a namespace argument which leans towards using <device:*>, but given the purpose of the file and its expected use case I'm not convinced it's worthwhile going down this path. To me, the bare tagnames in your example are clear in their meaning. Adding "device:" to all of them in my opinion would just create unnecessary clutter in the file. Regards jonathan |
From: Arnold K. <ar...@ar...> - 2013-11-08 20:06:03
|
Am Fri, 8 Nov 2013 11:05:37 +1030 schrieb Jonathan Woithe <jw...@ju...>: > Hi Phil > > I'm just coming back too your original email on the subject to pick > up a few loose ends. > > On Tue, Nov 05, 2013 at 06:51:41PM +0100, Philippe Carriere wrote: > > ... I save settings data in an xml file like this: > > > > <?xml version="1.0" encoding="UTF-8"?> > > : > > <device> > > : > > <clock> > > 5 (Internal) > > </clock> > > <samplerate> > > 1 (48000) > > </samplerate> > > I would be inclined to reverse the priority of the values here. That > is, use "Internal (5)" and "48000 (1)" instead. I think the use of > the literal interpretations of the fields might make the files more > resilient to future changes which might change the mapping of values > to IDs. If you don't go with the dbus-tags, it should probably be something like: <clock value="5" alt="Internal" /> <samplerate value="1" alt="48000" /> Be aware that this doubled information makes it harder to modify the files by hand. And during loading the files you have to decide if the value or the alt is more important. If you want the files to be easily human-editable: <clock>Internal</clock> <samplerate>48000</samplerate> Have fun, Arnold |
From: Jonathan W. <jw...@ju...> - 2013-11-09 06:45:40
|
On Fri, Nov 08, 2013 at 09:05:50PM +0100, Arnold Krille wrote: > > On Tue, Nov 05, 2013 at 06:51:41PM +0100, Philippe Carriere wrote: > > > ... I save settings data in an xml file like this: > > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > : > > > <device> > > > : > > > <clock> > > > 5 (Internal) > > > </clock> > > > <samplerate> > > > 1 (48000) > > > </samplerate> > > > > I would be inclined to reverse the priority of the values here. That > > is, use "Internal (5)" and "48000 (1)" instead. I think the use of > > the literal interpretations of the fields might make the files more > > resilient to future changes which might change the mapping of values > > to IDs. > > If you don't go with the dbus-tags, it should probably be something > like: > <clock value="5" alt="Internal" /> > <samplerate value="1" alt="48000" /> Yeah, that's a good suggestion. It's probably more XML-ish than including additional information in parentheses. > Be aware that this doubled information makes it harder to modify the > files by hand. And during loading the files you have to decide if the > value or the alt is more important. Good point. Logically the "value" field would take precedence, but if the aim is to guard against enum changes this could get tricky. > If you want the files to be easily human-editable: > <clock>Internal</clock> > <samplerate>48000</samplerate> This would certainly be my preference. However, I'm not sure whether the dbus interface includes sufficient information to enumerate all the controls in this way. Some do I think, but others may not. That's not to say the necessary information couldn't be added to facilitate this. Regards jonathan |
From: Philippe C. <la-...@or...> - 2013-11-10 16:18:30
|
-- Philippe Carriere <la-...@or...> |
From: Philippe C. <la-...@or...> - 2013-11-10 16:19:12
|
-- Philippe Carriere <la-...@or...> |
From: Philippe C. <la-...@or...> - 2013-11-10 16:20:02
|
-- Philippe Carriere <la-...@or...> |
From: Philippe C. <la-...@or...> - 2013-11-10 16:16:45
|
Hi Jonathan, enclosed are patches for the purpose, accounting for the recommendations. I included something for RME: of course, I cannot pretend anything about except it gives you a basis for debugging on your own device :-) First and last patches have nothing to do with the topic ... The former is to avoid an usual error when starting ffado-mixer after complete recompilation: only non-english install are involved; typically, in french, directory is "Répertoire" and the "é" requires the support of utf-8. The latter is an attempt to refresh the list of authors: there are probably many omissions ... Finally, I didn't yet implement the saving of the monitoring section of Pro 40. But at this point, the future presence or absence of a section in the file should not be of consequence (except that no settings are applied if they are absent, of course ...). Let me know. Le samedi 09 novembre 2013 à 17:15 +1030, Jonathan Woithe a écrit : > On Fri, Nov 08, 2013 at 09:05:50PM +0100, Arnold Krille wrote: > > > On Tue, Nov 05, 2013 at 06:51:41PM +0100, Philippe Carriere wrote: > > > > ... I save settings data in an xml file like this: > > > > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > > : > > > > <device> > > > > : > > > > <clock> > > > > 5 (Internal) > > > > </clock> > > > > <samplerate> > > > > 1 (48000) > > > > </samplerate> > > > > > > I would be inclined to reverse the priority of the values here. That > > > is, use "Internal (5)" and "48000 (1)" instead. I think the use of > > > the literal interpretations of the fields might make the files more > > > resilient to future changes which might change the mapping of values > > > to IDs. > > > > If you don't go with the dbus-tags, it should probably be something > > like: > > <clock value="5" alt="Internal" /> > > <samplerate value="1" alt="48000" /> > > Yeah, that's a good suggestion. It's probably more XML-ish than including > additional information in parentheses. > > > Be aware that this doubled information makes it harder to modify the > > files by hand. And during loading the files you have to decide if the > > value or the alt is more important. > > Good point. Logically the "value" field would take precedence, but if the > aim is to guard against enum changes this could get tricky. > > > If you want the files to be easily human-editable: > > <clock>Internal</clock> > > <samplerate>48000</samplerate> > > This would certainly be my preference. However, I'm not sure whether the > dbus interface includes sufficient information to enumerate all the controls > in this way. Some do I think, but others may not. That's not to say the > necessary information couldn't be added to facilitate this. > > Regards > jonathan > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel -- Philippe Carrière <phi...@wa...> |
From: Jonathan W. <jw...@ju...> - 2013-11-10 22:32:10
|
Hi Phil On Sun, Nov 10, 2013 at 05:16:29PM +0100, Philippe Carriere wrote: > enclosed are patches for the purpose, accounting for the > recommendations. > I included something for RME: of course, I cannot pretend anything about > except it gives you a basis for debugging on your own device :-) Thanks for these. I will review them as soon as possible and provide comments. This might be later in the week because I have a production project I need to complete first. My only comment at this stage relates to the last patch (becase it's a short patch and doesn't involve code :-) ): > <p>FFADO developers are:<ul> > <li>Pieter Palmers > <li>Daniel Wagner > <li>Jonathan Woithe > <li>Arnold Krille > +<li>Adrian Knoth > +<li>Stefan Richter > +<li>Philippe Carriere > +<li>Jano Svitok > +<li>Takashi Sakamoto > </ul> I agree with the addition of Takashi and yourself to this list. Adrian commits sporadic patches (and, AFAIK, maintains the Debian packages) so it would not be out of place to include him too (Adrian - what do you think is appropriate?). Stefan and Jano however are probably more "Contributors" rather than Developers as such. These are just my views though - I encourage feedback from the perspective of others. Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2013-11-22 11:35:56
|
Hi Phil After many delays I'm finally starting to work through the file saving patchset. I'm starting with the final patch in the series though since it's essentially a documentation patch and should be easy to get into shape and applied. Obviously the update to the year 2013 is fine. In regard to the authors etc, I suggest the following. <p>FFADO developers are:<ul> <li>Pieter Palmers <li>Daniel Wagner <li>Jonathan Woithe <li>Arnold Krille +<li>Adrian Knoth +<li>Philippe Carriere +<li>Takashi Sakamoto </ul> + +<p>Other contributions from:<ul> +<li>Stefan Richter +<li>Jano Svitok +</ul> This way anyone who submits a patch which is accepted could be listed under the "other contributions" section. I am concerned about the burden of remembering to maintain the list though; we'll have to see how it goes. We might have to set some sort of threshold, requiring 2 or 3 patches before adding names. I don't know. For the moment though this is probably fine. I'll work throught the code as time allows in the next few days I hope. Apologies for the continuing delay. Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2013-11-10 23:00:36
|
Hi Phil On Thu, Nov 07, 2013 at 08:53:28PM +0100, Philippe Carriere wrote: > Le jeudi 07 novembre 2013 à 09:38 +1030, Jonathan Woithe a écrit : > > I agree. I should have made it clear that I didn't like this idea (that's > > what you get for rushing off a reply). Files can be too easily renamed by > > accident - among other things. > > > > > As the files should be able to store the state of the full mixer also when > > > several devices are connected, the GUID of the device(s) concerned has to > > > be part of the xml-tree. > > As mentioned in my first email, the guid is the first information kept > for device recognition. > As a further comment, in my present experimental implementation: > > - there are as many <device>...</device> as devices present when > saving settings. > > - on file reading, the presence of each device (based on the guid) > is tested: if the device is present, saved settings are propagated. > Otherwise, they are simply ignored (with a debug message). That sounds ok to me. > > > Maybe either an extra import-function or a dialog when opening settings > > > where not all saved devices can be found again... > > > > Probably the latter I think. There are quite a few cases where the devices > > one has available at any one time changes, so you don't want a dialog to > > bother you just because a device appears not to be on the bus at a > > particular time. In this case we should just restore those devices which > > are present. > > I'm inclined to think about the former. Yeah: s/latter/former/. I was definitely arguing for the former. Sorry for any confusion. > Now, in the case you would like to import some settings for one device > (a Pro 40, say) to another kind of device (a RME, say) because they > share some potentialities (matrix mixer coefficients, for instance - > even if the matrices are not exactly of the same dimensions), it would > whatever be better that the user knows what he is doing (an import, not > a simple read) and that they will be some limitations for the process > (partial or no success). I think it would be difficult to come up with a reliable way to import devices settings into a totally different interface. Even if both devices have matrices one can't easily determine in an automated way whether they are compatible. Some even have multiple matrix mixers, and choosing the mapping would be hit and miss. And some use matrix controls for controls which are not a traditional matrix fader-based mixer. My view is that at least initially we shouldn't permit the restoration of mixer data from one device type to another. > This is an "extension"; not sure I will implement it soon :-) Understood - I think that it's definitely not something we need to concern ourselves with at this stage. To support this we'd have to come up with some way of tagging controls to help the system identify compatible controls. Regards jonathan |
From: Philippe C. <la-...@or...> - 2013-11-11 11:02:33
|
Hi Jonathan, Le lundi 11 novembre 2013 à 09:30 +1030, Jonathan Woithe a écrit : > I think it would be difficult to come up with a reliable way to import > devices settings into a totally different interface. Even if both devices > have matrices one can't easily determine in an automated way whether they > are compatible. Some even have multiple matrix mixers, and choosing the > mapping would be hit and miss. And some use matrix controls for controls > which are not a traditional matrix fader-based mixer. > > My view is that at least initially we shouldn't permit the restoration of > mixer data from one device type to another. > Yes; as I tried to do something for RME, I realized that importing from a device to another one is not so evident. Probably, importing from an EAP device to another EAP one could be quite easily feasible because they are based on the same chip and so share a lot of settings. But for devices with different hardware (even a Dice II to a DICE EAP, for instance), it will be very difficult and unsure. > > This is an "extension"; not sure I will implement it soon :-) > > Understood - I think that it's definitely not something we need to concern > ourselves with at this stage. To support this we'd have to come up with > some way of tagging controls to help the system identify compatible > controls. > Yes, and it was part of my previous questions; the chosen names for the tags should be sufficiently clear (and a little bit "unique") when such import functions could be introduced. Typically, I introduced some tag names specific to the RME device, but it is of course just a draft: feel absolutely free to introduce different tag names. Note that I tried not to obviate import feature in the functions at lowest level; but of course, I cannot guarantee anything. By the way, care when you will test for RME and a have a detailed look to the file produced by ffado-mixer saving first :-). Possibly, since I disabled the Open/Save_as functionality by default, you won't have access to it at all before introducing your own corrections ! :-) > Regards > jonathan Regards, Phil -- Philippe Carriere <la-...@or...> |
From: Jonathan W. <jw...@ju...> - 2013-11-17 23:43:24
|
Hi Phil Apologies for not getting onto this last week. I was doing preproduction for an upcoming event which consumed most of my spare time. This week should be better. On Mon, Nov 11, 2013 at 12:02:17PM +0100, Philippe Carriere wrote: > Le lundi 11 novembre 2013 à 09:30 +1030, Jonathan Woithe a écrit : > > > I think it would be difficult to come up with a reliable way to import > > devices settings into a totally different interface. Even if both devices > > have matrices one can't easily determine in an automated way whether they > > are compatible. Some even have multiple matrix mixers, and choosing the > > mapping would be hit and miss. And some use matrix controls for controls > > which are not a traditional matrix fader-based mixer. > > > > My view is that at least initially we shouldn't permit the restoration of > > mixer data from one device type to another. > > Yes; as I tried to do something for RME, I realized that importing from > a device to another one is not so evident. > Probably, importing from an EAP device to another EAP one could be quite > easily feasible because they are based on the same chip and so share a > lot of settings. > > But for devices with different hardware (even a Dice II to a DICE EAP, > for instance), it will be very difficult and unsure. I agree. Plus there's the question of whether, given these difficulties, it's worthwhile spending the time to make this happen. In any case, it's something for the future. > Typically, I introduced some tag names specific to the RME device, but it > is of course just a draft: feel absolutely free to introduce different tag > names. I will try to take a look through these this week and give you feedback. > By the way, care when you will test for RME and a have a detailed look > to the file produced by ffado-mixer saving first :-). Possibly, since I > disabled the Open/Save_as functionality by default, you won't have > access to it at all before introducing your own corrections ! :-) Thanks - noted. Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2013-11-25 11:24:19
|
Hi Phil On Sun, Nov 10, 2013 at 05:16:29PM +0100, Philippe Carriere wrote: > enclosed are patches for the purpose, accounting for the > recommendations. > I included something for RME: of course, I cannot pretend anything about > except it gives you a basis for debugging on your own device :-) I have finally had a chance to take a look at them. > First and last patches have nothing to do with the topic ... The former > is to avoid an usual error when starting ffado-mixer after complete > recompilation: only non-english install are involved; typically, in > french, directory is "Répertoire" and the "é" requires the support of > utf-8. The latter is an attempt to refresh the list of authors: there > are probably many omissions ... I can't see any problems with that first patch. You could commit that when ready. Regarding the bulk of the patch series, nothing in the patches jumps out at me as being problematic. I haven't had a chance to test the code with the RME and probably won't have an opportunity until after a projection is complete this coming weekend. Within the confines of the mixer application though it seems to be a workable approach. I guess the primary disadvantage is that it requires a considerable amount of code in each mixer module to handle the saving and restoration. It would be ideal if this could be handled in a way which was mostly transparent to the mixer modules, but it seems that this is not something which would come easiler. I have looked for and failed to find a generic dbus program which can read and restore a tree of settings under dbus - if something like this existed we could use it with very little addition to ffado-mixer itself. It could just walk the tree created by FFADO and read or write the settings as appropriate. The fact that nothing like this seems to exist probably means that traversing a dbus tree isn't all that trivial. So with that said the approach you've taken is probably the next best thing available to us and as such it can probably go in. My only comment in relation to this is to ponder whether the save/restore code for each mixer module should be placed in a separate file in the interests of keeping the mixer modules themselves clear of save/restore code. I'm not sure how feasible that would be, and in some ways would simply move the "clutter" into the module directory as each mixer would now comprise two files. In the long run I wonder whether we could arrange for FFADO to construct (at run time) something to do the save/restore. The structure of the mixer for a given device is set by a series of calls to buildMixer(). Would it be possible to leverage this to create something which could be used to walk the mixer tree and save/restore as necessary. Ffado-mixer would still need the menu hooks to instigate save/restore, but the bulk of the work would be handled by code which was essentially auto-generated at runtime. If this could be made to work it would remove the need to add save/restore code to every ffado-mixer module. However, I expect putting something like this together will be a considerable amount of work - assuming that it's even possible. For that reason I don't think that the possibility of something like this emerging in future should prevent this present work going in. So on balance, given that this patch series provides useful functionality which can work now, I can't see any reason not to polish it (if deemed necessary) and commit it. Apologies again for the delay in reviewing this patch series. Regards jonathan |
From: Philippe C. <la-...@or...> - 2013-12-15 11:16:44
|
Hi Jonathan, me again. Le lundi 25 novembre 2013 à 21:53 +1030, Jonathan Woithe a écrit : > > First and last patches have nothing to do with the topic ... The former > > is to avoid an usual error when starting ffado-mixer after complete > > recompilation: only non-english install are involved; typically, in > > french, directory is "Répertoire" and the "é" requires the support of > > utf-8. The latter is an attempt to refresh the list of authors: there > > are probably many omissions ... > > I can't see any problems with that first patch. You could commit that when > ready. > OK, I will probably delay because there is nothing urgent with this patch. Problems only arise for developer who like to have a non standard location for ffado (mainly because I have two co-existing versions on the same PC). > Regarding the bulk of the patch series, nothing in the patches jumps out at > me as being problematic. I haven't had a chance to test the code with the > RME and probably won't have an opportunity until after a projection is > complete this coming weekend. Within the confines of the mixer application > though it seems to be a workable approach. > > I guess the primary disadvantage is that it requires a considerable amount > of code in each mixer module to handle the saving and restoration. It would > be ideal if this could be handled in a way which was mostly transparent to > the mixer modules, but it seems that this is not something which would come > easiler. I have looked for and failed to find a generic dbus program which > can read and restore a tree of settings under dbus - if something like this > existed we could use it with very little addition to ffado-mixer itself. It > could just walk the tree created by FFADO and read or write the settings as > appropriate. The fact that nothing like this seems to exist probably means > that traversing a dbus tree isn't all that trivial. > Yes, I'm afraid not having any solution of this kind; I doubt there is one considering the ffado dbus-tree as it stands. > So with that said the approach you've taken is probably the next best thing > available to us and as such it can probably go in. My only comment in > relation to this is to ponder whether the save/restore code for each mixer > module should be placed in a separate file in the interests of keeping the > mixer modules themselves clear of save/restore code. I'm not sure how > feasible that would be, and in some ways would simply move the "clutter" > into the module directory as each mixer would now comprise two files. > > In the long run I wonder whether we could arrange for FFADO to construct (at > run time) something to do the save/restore. The structure of the mixer for > a given device is set by a series of calls to buildMixer(). Would it be > possible to leverage this to create something which could be used to walk > the mixer tree and save/restore as necessary. Ffado-mixer would still need > the menu hooks to instigate save/restore, but the bulk of the work would be > handled by code which was essentially auto-generated at runtime. If this > could be made to work it would remove the need to add save/restore code to > every ffado-mixer module. However, I expect putting something like this > together will be a considerable amount of work - assuming that it's even > possible. For that reason I don't think that the possibility of something > like this emerging in future should prevent this present work going in. > > So on balance, given that this patch series provides useful functionality > which can work now, I can't see any reason not to polish it (if deemed > necessary) and commit it. > OK, I will have a further look before the end of year. There is whatever some saving/restoring functionality missing even for Saffire Pro (monitoring part) which require some additional work. Probably I will also have a try to re-arrange the patches in a more convenient way. > Apologies again for the delay in reviewing this patch series. > > Regards > jonathan Best regards, Phil -- Philippe Carriere <la-...@or...> |