From: Daniel W. <wa...@mo...> - 2008-09-23 22:01:38
|
Ciao Pieter, I have added support for setting the pan for the FA-101 and FA-66. The changes for this were a bit larger. Therefore, I have created new branch just for let you check if you like them in libffado-2.0 or not. I'll merge them back to trunk now. But for the libffado-2.0 branch I'm not so sure. The main thing what is different is that the names for the feature as dbus exposes them have changed. Until now it was '/Mixer/Feature_1' for all BeBoB devices. Since there was only the volume feature function block behind that was ok. Since the panning is done also over a feature function block I have modified the string to '/Mixer/Feature_Volume_1' and for the panning '/Mixer/Feature_LRBalance_1'. All bebob mixers are adapted. Though I can't test all of them. That's why I'm a bit more careful. Hmm, maybe I just wait for your answer before I do anything. What do you think? Should I merge them into both trunk and branch and we fix any mixer_*.py later? cheers, daniel |
From: Arnold K. <ar...@ar...> - 2008-09-24 09:03:59
|
Hi, Am Mittwoch, 24. September 2008 schrieb Daniel Wagner: > Until now it was '/Mixer/Feature_1' for all BeBoB devices. > Since there was only the volume feature function block behind that > was ok. Since the panning is done also over a feature function block > I have modified the string to '/Mixer/Feature_Volume_1' and for > the panning '/Mixer/Feature_LRBalance_1'. All bebob mixers are > adapted. Though I can't test all of them. That's why I'm a bit more > careful. If we name the features and give them the number of the channel, do we still have to call them feature? What I mean is that Feature_Volume_1 is longer then Volume_1 without having more information. Arnold -- visit http://www.arnoldarts.de/ --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a "rm -rf /". Or ask your administrator to do so... |
From: Daniel W. <wa...@mo...> - 2008-09-24 09:18:24
|
Arnold Krille wrote: > Hi, > > Am Mittwoch, 24. September 2008 schrieb Daniel Wagner: >> Until now it was '/Mixer/Feature_1' for all BeBoB devices. >> Since there was only the volume feature function block behind that >> was ok. Since the panning is done also over a feature function block >> I have modified the string to '/Mixer/Feature_Volume_1' and for >> the panning '/Mixer/Feature_LRBalance_1'. All bebob mixers are >> adapted. Though I can't test all of them. That's why I'm a bit more >> careful. > > If we name the features and give them the number of the channel, do we still > have to call them feature? What I mean is that Feature_Volume_1 is longer > then Volume_1 without having more information. No not really. I also noticed that only BeBoB devices use that convention, e.g motu uses '/Mixer/fader'. I do not really care what the name is. But I agree the shorter it better. Just when I change this it is possible that some mixer will break. daniel |
From: Pieter P. <pi...@jo...> - 2008-09-24 09:23:12
|
Daniel Wagner wrote: > Ciao Pieter, > > I have added support for setting the pan for the FA-101 and FA-66. The > changes for this were a bit larger. Therefore, I have created new branch > just for let you check if you like them in libffado-2.0 > or not. > > I'll merge them back to trunk now. But for the libffado-2.0 > branch I'm not so sure. > The main thing what is different is that the names for the feature as > dbus exposes them have changed. > > Until now it was '/Mixer/Feature_1' for all BeBoB devices. Since there > was only the volume feature function block behind that was ok. Since the > panning is done also over a feature function block > I have modified the string to '/Mixer/Feature_Volume_1' and for > the panning '/Mixer/Feature_LRBalance_1'. All bebob mixers are > adapted. Though I can't test all of them. That's why I'm a bit more > careful. > > Hmm, maybe I just wait for your answer before I do anything. > What do you think? Should I merge them into both trunk and branch > and we fix any mixer_*.py later? Maybe it's better to completely generalize the feature function blocks into some new control object. I.e. have the 'subfunction' as a parameter instead of in the name. If I remember correctly it's one function block that supports multiple subfunctions, no? Greets, Pieter |
From: Daniel W. <wa...@mo...> - 2008-09-24 09:58:54
|
Pieter Palmers wrote: > Daniel Wagner wrote: >> Until now it was '/Mixer/Feature_1' for all BeBoB devices. Since there >> was only the volume feature function block behind that was ok. Since >> the panning is done also over a feature function block >> I have modified the string to '/Mixer/Feature_Volume_1' and for >> the panning '/Mixer/Feature_LRBalance_1'. All bebob mixers are >> adapted. Though I can't test all of them. That's why I'm a bit more >> careful. >> >> Hmm, maybe I just wait for your answer before I do anything. >> What do you think? Should I merge them into both trunk and branch >> and we fix any mixer_*.py later? > > Maybe it's better to completely generalize the feature function blocks > into some new control object. I.e. have the 'subfunction' as a parameter > instead of in the name. I like the current approach, it is quite simple to understand and not to difficult to handle. > If I remember correctly it's one function block > that supports multiple subfunctions, no? Yes, one function block supports several features. I don't think we have to make that visible at the mixer API. This is just internal detail. Do you still want to create a complete generic mixer application? Not sure if that was my or your aim but anyway I think it is not possible to achieve. Therefore we can very good live how it is at this moment. Maybe a different naming scheme as Arnold has suggested. What do you think? cheers, daniel |
From: Pieter P. <pi...@jo...> - 2008-09-24 11:19:59
|
Daniel Wagner wrote: > Pieter Palmers wrote: >> Daniel Wagner wrote: >>> Until now it was '/Mixer/Feature_1' for all BeBoB devices. Since >>> there was only the volume feature function block behind that was ok. >>> Since the panning is done also over a feature function block >>> I have modified the string to '/Mixer/Feature_Volume_1' and for >>> the panning '/Mixer/Feature_LRBalance_1'. All bebob mixers are >>> adapted. Though I can't test all of them. That's why I'm a bit more >>> careful. >>> >>> Hmm, maybe I just wait for your answer before I do anything. >>> What do you think? Should I merge them into both trunk and branch >>> and we fix any mixer_*.py later? >> >> Maybe it's better to completely generalize the feature function blocks >> into some new control object. I.e. have the 'subfunction' as a >> parameter instead of in the name. > > I like the current approach, it is quite simple to understand and > not to difficult to handle. >> If I remember correctly it's one function block that supports multiple >> subfunctions, no? > > Yes, one function block supports several features. I don't think we > have to make that visible at the mixer API. This is just internal > detail. > Do you still want to create a complete generic mixer application? Not > sure if that was my or your aim but anyway I think it is not > possible to achieve. Therefore we can very good live how it is > at this moment. Maybe a different naming scheme as Arnold has > suggested. What do you think? Your suggestions are fine by me. After all, for most of these it will be a one-time effort. Greets, Pieter |