> Because somebody would need to write *and* maintain all of that > software. Keep > in mind that almost all people stepping by here are usually just > saying > feature x doesn't work, please fix it. Or feature y is nice, but > please extend > it in this and that way. >
True! > I understand that you would like to see those wav2gig patterns more > user > friendly, but wav2gig is just one of many things (and projects) I > have to take > care of and I only have two hands and 24h/day. wav2gig is out for > just 2 weeks > now and you are probably one of the first people ever having used it > at all > (yet). So that's the infamous point where I have to make clear > compromises ... I'm absolutely with you! > > Regex patterns are doing the job, including use cases that go beyond > your > personal needs, and I don't have to maintain parsing code by myself. > So the > plan is to make this feature configurable by standard regex patterns > only for > now; no self-invented formats/tags and no custom parser code on top > that would > need to be developed, documented, extended and ... fixed. Instead > some regex > examples in the man page should already be a good starting point for > new > users. As I said, that's fine with me. This could lead to a commandline switch, where for each attribute a regex would be given. That should be a relatively small patch. > > Additionally I would add a verbosity switch and maybe a --dry-run > switch for > providing users diagnostics for the individual input wav files' meta > info > being picked by wav2gig and why. But that should be really it for > foreseeable > future. Ok! > > On Sonntag, 29. August 2021 12:30:13 CEST Kolja Koch wrote: > > Having wav2gig to accept regex-patterns for each attribute is fine > > with > > me. But from a user point of view, having an interface that allows > > him > > to easily enter patterns for the attributes for (some kind of > > simple) > > filename-structures would be recommendable. > > Yes, but you can also easily over-engineer this as well. ATM I don't > see this > conversion tool being used by a huge amount of people, nor on a > frequent > basis. Hence I personally don't want to invest too much time and > focus on it, > at least not ATM. Yeah, I have the same feeling. > > People who might refrain from using the wav2gig tool because of regex > patterns > being user-unfriendly, usually neither want to use command line tools > in the > first place. So for such people you would rather want to write a GUI > app ontop > of libgig where you could really invest a *load* of development time > and > people would probably still give you suggestions how it could be > improved. > E.g. you can make a clickable pattern editor with coloured > highlighting and > nice token frames that would show you a preview of the expected > results in > real-time, and you could combine that with an automatic prescan of a > directory > and deploy an A.I. on top of the prescan for a fully automated > initial pattern > suggestion. :) Yes, I thought about these suggestions as well, including the A.I.. > > Well, if you really want to start such kind of project: I would > recommend to > reconsider the toolkit decision and no longer use gtk(mm) for new > projects > anymore, for many reasons actually. You would probably safe yourself > a load of > development time and frustration on the long run by simply picking > another > toolkit right from the start. Do you have any suggestions for one? I just picked gtk because gigedit uses it... I really appreciate your taking the time for this conversation! And I really don't want this to consume more of your time. To me, this would be just a hobby-project to see if I can make that work. I can live with implementing and using the patch noted above just for my local project. If I succeed and get something together that I feel to be ready enough to be shared, I'll let you know. Cheers, Kolja _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
