I really don't want to fuel the fire here, but I'd just like to speak with some experience on both sides of the patch/pull game.
You and Pedro seem to stick with only what you prefer with the Soundfont > specs and GS-specs, both of which only deal with 128 soundbanks. > I've been observing this conversation, and while I do think the reaction to the original mail (on a completely different topic by a different contributor) was overly negative, there also has to be room in a software project to say "no." My understanding of the project is that there aren't a lot of people contributing, nor do the people at the top have much time to give. Therefore, proposing drastic changes is probably not going to be feasible, even if it's theoretically a good idea. Of course, I don't expect you to waste your time on XG-stuff if that's not > your area of interest, or expertise. I have done some homework with > regarding to XG stuff and provided my patch(es) for my "observation" of the > vairous XG implementations (via Yamaha hardware instrument tables). > It's more complicated than saying to the project leads "I don't expect you to deal with this, I'll do the research and the work." The problem is that ultimately, someone who "owns" the project will need to understand this stuff in order to accept it. They will need to review your patch and understand how it fits in with the overall system and the interests of many users. For example, whether including this patch will break other users in some obscure case, or whether it will pull in too many dependencies. If you are proposing a non-trivial amount of work for yourself to do, it *will*ultimately end up becoming a non-trivial amount of work for someone else as well. There's also the fact that if you submit it, you may not be around to maintain it, and then people like David will have to understand it even better to fix it when it breaks. I'm not trying to be a nay-sayer and block progress. I just want to make the point that sometimes, as a project lead, it isn't a good idea to embark on a large new feature with a contributor you don't know well, especially if you don't have much time to give to the project yourself. In any case, getting angry doesn't help. It can be frustrating when nobody is accepting your patch. You should assume they have forgotten, as opposed to deliberately ignored you. It never hurts to wait a week and then post a follow-up: "Just checking if anybody has gotten around to looking at my patch yet?" Matt
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
