сб, 20 апр. 2019 г. в 05:54, Georg Chini <georg@xxxxxxxx>: > But what you are basically saying is that the equalizer does > not hold what Andrea claims it can do and that it is only useful > as a 10-band equalizer. I wonder why her work was then > accepted as a master thesis. I don't know the Italian requirements for a master thesis. In Russia, rejections of this kind of thesis are rare: it's a time-boxed activity without a second chance to choose a topic (unlike the real scientific work), and rejections would make it a not-worth-it gamble in the students' eyes. And the same kind of number-of-pages stuffing (by including chapters on "considered but rejected" techniques) is common, I did it too. We do need a recheck from Italian experts not related to the government issued degrees. Probably on JACK mailing lists? And hopefully you now understand why I am inclined to reject even objectively-good scientific code submissions, if they are making something a part of PulseAudio: insufficient number of local experts that would have rejected bad submissions. OTOH, a plugin architecture that allows us to tap into the work by an existing pool of experts, without taking any responsibility, would be awesome. > >>> Besides, consumer electronic devices (TVs, HDMI receivers, Hi-Fi > >>> amplifiers) just do not have equalizers with a variable number of > >>> bands, for usability reasons. I don't see a reason for PulseAudio to > >>> be different. > >>> > >> You can't add sliders on the fly on a consumer electronic > >> device but you can do so in software. Why should we be guided > >> by a behavior that is governed by physical limits? If the algorithm > >> supports it, I see no reason why it should not be implemented. > >> (As said above naturally within some sane limits, you are right > >> that it would make no sense to have for example 50 bands.) > > Sliders in a consumer electronics device such as a TV are just virtual > > widgets on the screen, i.e. software, not physical knobs. Again, their > > number is fixed because of usable and "intuitive" UI. > I guess there are enough people who would wish for more > flexibility. > > > >> Surely you could go for several different plugins, but I do not > >> see the reason why the code should be duplicated a couple > >> of times. The goal is to have one plugin and not a collection. > >> I just don't like the idea that you have to duplicate things only > >> because of the limitation of the surrounding framework. > >> That's why I am looking for a way to dynamically adapt the > >> number of control ports or - which seems to be supported > >> by LV2 - use a control port that is an array. > > And my point is exactly that there is a reason, filter order, not > > related to any framework limitations, for different code for different > > number of bands. > > > >> Another example where an array would be useful as a control > >> port is the virtual-surround-sink. The HRIR data used by the filter > >> is an array of floats which could vary in size. > > I also disagree here. Yes, it can vary in size, but should not be > > treated as a control port at all. There is no way to usefully control > > it for a user, that's why. It should therefore be either hard-coded > > (as done in Windows) or loaded through a file. > > If you load it through a file like pulseaudio does, how do > you pass the values to the filter? Or should the plugin itself > load the file? The plugin itself should load the file. The fact that the file does not come with the plugin itself is a major bug that unfortunately exists for licensing reasons. I think we should find a free-enough data source for HRIR/HRTF and just hard-code the impulse responses, though. We can investigate reusing the data from CSound. -- Alexander E. Patrakov _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
